Hi
Am 18.10.21 um 21:32 schrieb Igor Matheus Andrade Torrente:
Hi Thomas,
On 10/18/21 3:06 PM, Thomas Zimmermann wrote:
Hi
Am 18.10.21 um 19:41 schrieb Igor Matheus Andrade Torrente:
Hello,
On 10/18/21 7:14 AM, Thomas Zimmermann wrote:
Hi
Am 05.10.21 um 22:16 schrieb Igor Matheus Andrade
> This one we could use. For some reason we hardcode it to
> 1 now, which is correct for our use cases but I don't really> see a reason to
> hardcode it here. We are supposed to calculate> it correctly after all, and
> chv_crtc_clock_get() also just blindly> reads it out.> > > bestm2_frac
> This one we could use. For some reason we hardcode it to
> 1 now, which is correct for our use cases but I don't really> see a reason to
> hardcode it here. We are supposed to calculate> it correctly after all, and
> chv_crtc_clock_get() also just blindly> reads it out.> > > bestm2_frac
> This one we could use. For some reason we hardcode it to
> 1 now, which is correct for our use cases but I don't really> see a reason to
> hardcode it here. We are supposed to calculate> it correctly after all, and
> chv_crtc_clock_get() also just blindly> reads it out.> > > bestm2_frac
Eliminate the following coccicheck warning:
./drivers/gpu/drm/panel/panel-novatek-nt35950.c:639:2-3: Unneeded
semicolon
Reported-by: Abaci Robot
Fixes: 623a3531e9cf ("drm/panel: Add driver for Novatek NT35950 DSI DriverIC
panels")
Signed-off-by: Yang Li
---
drivers/gpu/drm/panel/panel-novatek-
Hi
On Mon, Oct 18, 2021 at 08:48:52PM +0300, Laurent Pinchart wrote:
> Hi Maxime,
>
> On Mon, Oct 18, 2021 at 05:20:13PM +0200, Maxime Ripard wrote:
> > On Sat, Oct 16, 2021 at 05:34:59AM +0300, Laurent Pinchart wrote:
> > > On Thu, Oct 14, 2021 at 09:41:10AM +0200, Maxime Ripard wrote:
> > > > O
On Mon, 18 Oct 2021 16:26:06 -0300
Igor Matheus Andrade Torrente wrote:
> Hi Pekka,
>
> On 10/18/21 5:30 AM, Pekka Paalanen wrote:
> > On Tue, 5 Oct 2021 17:16:37 -0300
> > Igor Matheus Andrade Torrente wrote:
> >
> >> Currently the blend function only accepts XRGB_ and ARGB_
> >> a
Gma500 currently removes generic fbdev drivers, but ignores
generic DRM drivers. Use aperture helpers to remove all generic
graphics drivers before loading gma500. Makes gma500 compatible
with simpledrm.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/gma500/psb_drv.c | 12
1 f
On 18/10/2021 19:35, Umesh Nerlige Ramappa wrote:
On Mon, Oct 18, 2021 at 08:58:01AM +0100, Tvrtko Ursulin wrote:
On 16/10/2021 00:47, Umesh Nerlige Ramappa wrote:
With GuC handling scheduling, i915 is not aware of the time that a
context is scheduled in and out of the engine. Since i915 pm
Hey Dmitry,
Thanks for submitting this series.
On Sun, 3 Oct 2021 at 01:35, Dmitry Osipenko wrote:
>
> The driver assumes that reference clock is always-enabled, but this is
> hardware-dependent and not true for ASUS Transformer TF700T. Make driver
> enable / disable the reference clock.
>
> Tes
On Sun, 3 Oct 2021 at 01:35, Dmitry Osipenko wrote:
>
> Support pulse-mode synchronization which is supported and used by simple
> DSI panels like Panasonic VVX10F004B00.
>
> Tested-by: Andreas Westman Dorcsak # Asus TF700T
> Tested-by: Maxim Schwalm #TF700T
> Signed-off-by: Dmitry Osipenko
> -
From: Ran Jianping
'drm/ttm/ttm_placement.h' included in
'drivers/gpu/drm/i915/selftests/mock_region.c' is duplicated.
It is also included on the 9 line.
Reported-by: Zeal Robot
Signed-off-by: Ran Jianping
---
drivers/gpu/drm/i915/selftests/mock_region.c | 2 --
1 file changed, 2 deletions(-)
On Mon, Oct 18, 2021 at 09:54:59AM +1000, Dave Airlie wrote:
> On Thu, 14 Oct 2021 at 19:09, Ville Syrjala
> wrote:
> >
> > From: Ville Syrjälä
> >
> > Fix a pile of regression on older machines which just oops the driver
> > on load.
> >
>
> For all 4:
>
> Reviewed-by: Dave Airlie
>
> though
From: Ran Jianping
'nvif/if000c.h' included in 'drivers/gpu/drm/nouveau/nouveau_dmem.c'
is duplicated.It is also included on the 36 line.
Reported-by: Zeal Robot
Signed-off-by: Ran Jianping
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/
On 19/10/2021 10:02, cgel@gmail.com wrote:
From: Ran Jianping
'drm/ttm/ttm_placement.h' included in
'drivers/gpu/drm/i915/selftests/mock_region.c' is duplicated.
It is also included on the 9 line.
Reported-by: Zeal Robot
Signed-off-by: Ran Jianping
Commit tile should ideally be prefixe
On Sun, 3 Oct 2021 at 01:35, Dmitry Osipenko wrote:
>
> Calculate video start delay based on the display timing instead
> of hardcoding it to a default value. This fixes "trembling" display
> output on Asus Transformer TF700T which uses Panasonic VVX10F004B00
> display panel.
>
> Tested-by: Andrea
On Sun, 3 Oct 2021 at 01:35, Dmitry Osipenko wrote:
>
> Non-continuous clock mode doesn't work because driver doesn't support it
> properly. The bridge driver programs wrong bitfields that are required by
> the non-continuous mode (BTACNTRL1 register bitfields are swapped in the
> code), but fixin
On Sun, 3 Oct 2021 at 01:35, Dmitry Osipenko wrote:
>
> TXTAGOCNT and RXTASURECNT bitfields of BTACNTRL1 register are swapped in
> the code, correct them. Driver doesn't implement low power mode for now,
> so this change doesn't make a practical difference yet.
>
> Tested-by: Andreas Westman Dorcs
Applied to drm-misc-next
On Sun, 3 Oct 2021 at 01:35, Dmitry Osipenko wrote:
>
> This series adds couple improvements to the TC358768 DSI bridge driver,
> enabling Panasonic VVX10F004B00 DSI panel support. This panel is used by
> ASUS Transformer TF700T tablet, which is ready for upstream kernel
Hi all -
These are the drm dp helpers for figuring out link training delays, to
be pulled to both drm-misc-next and drm-intel-next.
topic/drm-dp-training-delay-helpers-2021-10-19:
Core Changes:
- drm dp helpers for figuring out link training delays
BR,
Jani.
The following changes since commi
Thanks for catching this Michael.
> > Working on linux-next-5.14-rc4 on px30-evb rockchip board. On top of this
> > patch for px30 dsi
> > I need to add:
> >
>
> I wrote the driver for evb px30 v11. I just need to clean up a bit.
> Anyway the video is correct.
> Using my patch. The display is not
Hi Maxime,
On Tue, Oct 19, 2021 at 09:37:28AM +0200, Maxime Ripard wrote:
> On Mon, Oct 18, 2021 at 08:48:52PM +0300, Laurent Pinchart wrote:
> > On Mon, Oct 18, 2021 at 05:20:13PM +0200, Maxime Ripard wrote:
> > > On Sat, Oct 16, 2021 at 05:34:59AM +0300, Laurent Pinchart wrote:
> > > > On Thu, O
From: chongjiapeng
This symbol is not used outside of panel-novatek-nt35950.c, so marks it
static.
Fixes the following sparse warning:
drivers/gpu/drm/panel/panel-novatek-nt35950.c:671:33: warning: symbol
'sharp_ls055d1sx04' was not declared. Should it be static?
Reported-by: Abaci Robot
Fixe
Trivial fix since we now need to grab a reference to the fence we have
added. Previously the dma_resv function where doing that for us.
Signed-off-by: Christian König
Fixes: 9c2ba265352a drm/scheduler: ("use new iterator in
drm_sched_job_add_implicit_dependencies v2")
---
drivers/gpu/drm/schedu
Am 13.10.21 um 16:07 schrieb Daniel Vetter:
On Tue, Oct 05, 2021 at 01:37:26PM +0200, Christian König wrote:
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --g
On Sun, 17 Oct 2021 at 10:38, Dmitry Osipenko wrote:
>
> 01.10.2021 18:01, Ulf Hansson пишет:
> > On Fri, 1 Oct 2021 at 16:35, Dmitry Osipenko wrote:
> >>
> >> 01.10.2021 17:24, Ulf Hansson пишет:
> >>> On Mon, 27 Sept 2021 at 00:42, Dmitry Osipenko wrote:
>
> The NAND on Tegra belongs
Am 13.10.21 um 16:14 schrieb Daniel Vetter:
On Tue, Oct 05, 2021 at 01:37:28PM +0200, Christian König wrote:
Simplifying the code a bit. Also drop the RCU read side lock since the
object is locked anyway.
Untested since I can't get the driver to compile on !ARM.
Cross-compiler install is prett
Hi Maxime,
Thank you for the patch.
On Wed, Sep 29, 2021 at 10:42:28AM +0200, Maxime Ripard wrote:
> of_graph_get_port_by_id doesn't modify the device_node pointer it takes
> as argument, so we can make it const.
>From a C point of view that's right, but conceptually speaking, is it
right to ret
On Sun, Oct 17, 2021 at 10:05 PM Marek Vasut wrote:
>
> On 10/17/21 7:52 PM, Sam Ravnborg wrote:
> > Hi Marek,
> >
> > On Wed, Sep 08, 2021 at 08:24:20PM +0200, Daniel Vetter wrote:
> >> On Tue, Sep 07, 2021 at 04:49:00AM +0200, Marek Vasut wrote:
> >>> The mxsfb->crtc.funcs may already be NULL wh
On Mon, 18 Oct 2021, Jani Nikula wrote:
> From: Stephen Rothwell
>
> Commit cd06ab2fd48f ("drm/locking: add backtrace for locking contended
> locks without backoff") added functions named __stack_depot_* in drm
> which conflict with stack depot. Rename to __drm_stack_depot_*.
>
> v2 by Jani:
> -
From: Guangming Cao
Since there is no mandatory inspection for attachments in dma_buf_release.
There will be a case that dma_buf already released but attachment is still
in use, which can points to the dmabuf, and it maybe cause
some unexpected issues.
With IOMMU, when this cases occurs, there w
On Thu, Oct 14, 2021 at 03:47:31PM +0200, Sebastian Andrzej Siewior wrote:
> On 2021-10-14 15:21:22 [+0200], Daniel Vetter wrote:
> > On Wed, Oct 13, 2021 at 07:35:48PM +0200, Sebastian Andrzej Siewior wrote:
> > > c7fcbf2513973 -> does not boot
> > > c7fcbf2513973 + 2f425cf5242a0 -> boots, 18 x DR
On Tue, Oct 19, 2021 at 10:09:42AM +0200, Thomas Zimmermann wrote:
> Gma500 currently removes generic fbdev drivers, but ignores
> generic DRM drivers. Use aperture helpers to remove all generic
> graphics drivers before loading gma500. Makes gma500 compatible
> with simpledrm.
>
> Signed-off-by:
On Tue, Oct 19, 2021 at 01:27:06PM +0200, Christian König wrote:
> Trivial fix since we now need to grab a reference to the fence we have
> added. Previously the dma_resv function where doing that for us.
>
> Signed-off-by: Christian König
> Fixes: 9c2ba265352a drm/scheduler: ("use new iterator i
On Mon, 18 Oct 2021, Maxime Ripard wrote:
> Hi Jani,
>
> On Fri, Oct 15, 2021 at 06:21:35PM +0300, Jani Nikula wrote:
>> On Thu, 14 Oct 2021, Jani Nikula wrote:
>> > The link training delays are different and/or available in different
>> > DPCD offsets depending on:
>> >
>> > - Clock recovery vs.
It was <2021-10-18 pon 21:13>, when Andrzej Hajda wrote:
> Beside updating email, the patch updates maintainers
> of Samsung drivers.
>
> Signed-off-by: Andrzej Hajda
> ---
> .mailmap| 1 +
> MAINTAINERS | 13 -
> 2 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/
On Tue, Oct 19, 2021 at 08:23:45PM +0800, guangming@mediatek.com wrote:
> From: Guangming Cao
>
> Since there is no mandatory inspection for attachments in dma_buf_release.
> There will be a case that dma_buf already released but attachment is still
> in use, which can points to the dmabuf, a
On Dienstag, 19. Oktober 2021 13:27:06 CEST Christian König wrote:
> Trivial fix since we now need to grab a reference to the fence we have
> added. Previously the dma_resv function where doing that for us.
>
> Signed-off-by: Christian König
> Fixes: 9c2ba265352a drm/scheduler: ("use new iterator
Am 13.10.21 um 16:21 schrieb Daniel Vetter:
On Tue, Oct 05, 2021 at 01:37:37PM +0200, Christian König wrote:
Simplifying the code a bit.
v2: add missing rcu_read_lock()/unlock()
v3: switch to locked version
Signed-off-by: Christian König
Reviewed-by: Tvrtko Ursulin
Please make sure you also
Am 13.10.21 um 16:23 schrieb Daniel Vetter:
On Tue, Oct 05, 2021 at 01:37:38PM +0200, Christian König wrote:
Makes the handling a bit more complex, but avoids the use of
dma_resv_get_excl_unlocked().
v2: improve coding and documentation
Signed-off-by: Christian König
---
drivers/gpu/drm/drm
Am 19.10.21 um 14:35 schrieb Daniel Vetter:
On Tue, Oct 19, 2021 at 01:27:06PM +0200, Christian König wrote:
Trivial fix since we now need to grab a reference to the fence we have
added. Previously the dma_resv function where doing that for us.
Signed-off-by: Christian König
Fixes: 9c2ba265
On 2021-10-19 14:24:29 [+0200], Daniel Vetter wrote:
>
> Ah dmesg help me understand what's going on. Does the below patch help? If
> it's this one that would also explain why intel CI hasn't hit it - it's a
> leak between tests and we run them all individually instead of once at
> boot-up.
Yes,
On Dienstag, 19. Oktober 2021 15:06:31 CEST Christian König wrote:
>
> Am 19.10.21 um 14:35 schrieb Daniel Vetter:
> > On Tue, Oct 19, 2021 at 01:27:06PM +0200, Christian König wrote:
> >> Trivial fix since we now need to grab a reference to the fence we have
> >> added. Previously the dma_resv fu
On Tue, Oct 19, 2021 at 12:59:57PM +0300, Jani Nikula wrote:
>
> Hi all -
>
> These are the drm dp helpers for figuring out link training delays, to
> be pulled to both drm-misc-next and drm-intel-next.
>
>
> topic/drm-dp-training-delay-helpers-2021-10-19:
> Core Changes:
> - drm dp helpers for
On Tue, Oct 19, 2021 at 02:54:04PM +0200, Christian König wrote:
> Am 13.10.21 um 16:21 schrieb Daniel Vetter:
> > On Tue, Oct 05, 2021 at 01:37:37PM +0200, Christian König wrote:
> > > Simplifying the code a bit.
> > >
> > > v2: add missing rcu_read_lock()/unlock()
> > > v3: switch to locked vers
Am 24.06.21 um 11:55 schrieb Thomas Zimmermann:
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
The respective rockchip functions are being removed. The file_operations
structure fops is now being created by the helper ma
On Mon, Oct 18, 2021 at 08:47:30AM +, Simon Ser wrote:
> If an hotplug event only updates a single connector, use
> drm_kms_helper_connector_hotplug_event instead of
> drm_kms_helper_hotplug_event.
>
> Changes in v4:
> - Simplify loop logic (Ville, Sam)
> - Update drm_connector_helper_hpd_irq_
On 14-10-21, 17:40, Dmitry Baryshkov wrote:
> On 07/10/2021 10:08, Vinod Koul wrote:
> > +static void dpu_hw_dsc_config(struct dpu_hw_dsc *hw_dsc,
> > + struct msm_display_dsc_config *dsc, u32 mode)
> > +{
> > + struct dpu_hw_blk_reg_map *c = &hw_dsc->hw;
> > + u32 data
Fixes screen orientation for the Aya Neo 2021 handheld gaming console.
Signed-off-by: Bryant Mairs
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
b/drivers/gpu/drm/drm_panel_orientation_
On Tue, Oct 19, 2021 at 03:02:26PM +0200, Christian König wrote:
> Am 13.10.21 um 16:23 schrieb Daniel Vetter:
> > On Tue, Oct 05, 2021 at 01:37:38PM +0200, Christian König wrote:
> > > Makes the handling a bit more complex, but avoids the use of
> > > dma_resv_get_excl_unlocked().
> > >
> > > v2:
On 10/19/21 8:49 AM, Laurent Pinchart wrote:
Hi Marek,
Hi,
diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
index 1faae3e323a4..708de84ac138 100644
--- a/Documentation/devicetree/bindings/display/
On 14-10-21, 17:11, Dmitry Baryshkov wrote:
> On 07/10/2021 10:08, Vinod Koul wrote:
> > +static int _dpu_rm_reserve_dsc(struct dpu_rm *rm,
> > + struct dpu_global_state *global_state,
> > + struct drm_encoder *enc)
> > +{
> > + struct msm_drm_pr
On Tue, 19 Oct 2021, Maxime Ripard wrote:
> On Tue, Oct 19, 2021 at 12:59:57PM +0300, Jani Nikula wrote:
>>
>> Hi all -
>>
>> These are the drm dp helpers for figuring out link training delays, to
>> be pulled to both drm-misc-next and drm-intel-next.
>>
>>
>> topic/drm-dp-training-delay-helpe
Am 19.10.21 um 14:41 schrieb Daniel Vetter:
On Tue, Oct 19, 2021 at 08:23:45PM +0800, guangming@mediatek.com wrote:
From: Guangming Cao
Since there is no mandatory inspection for attachments in dma_buf_release.
There will be a case that dma_buf already released but attachment is still
i
On Thu, 14 Oct 2021, Jani Nikula wrote:
> Use the new link training delay helpers, fixing the delays for
> 128b/132b.
>
> For existing 8b/10b functionality, this will cause additional 1-byte
> DPCD reads for LTTPR delays instead of using the cached values. It's
> just too complicated to combine ge
Am 19.10.21 um 16:30 schrieb Daniel Vetter:
On Tue, Oct 19, 2021 at 03:02:26PM +0200, Christian König wrote:
Am 13.10.21 um 16:23 schrieb Daniel Vetter:
On Tue, Oct 05, 2021 at 01:37:38PM +0200, Christian König wrote:
Makes the handling a bit more complex, but avoids the use of
dma_resv_get_ex
On Tue, 19 Oct 2021 at 18:30, Vinod Koul wrote:
>
> On 14-10-21, 17:11, Dmitry Baryshkov wrote:
> > On 07/10/2021 10:08, Vinod Koul wrote:
>
> > > +static int _dpu_rm_reserve_dsc(struct dpu_rm *rm,
> > > + struct dpu_global_state *global_state,
> > > +
On Tue, Oct 19, 2021 at 04:13:34PM +0100, Joao Martins wrote:
> On 10/19/21 00:06, Jason Gunthorpe wrote:
> > On Mon, Oct 18, 2021 at 12:37:30PM -0700, Dan Williams wrote:
> >
> >>> device-dax uses PUD, along with TTM, they are the only places. I'm not
> >>> sure TTM is a real place though.
> >>
>
Add a helper for getting the DP PHY name. In the interest of caller
simplicity and to avoid allocations and passing in of buffers, duplicate
the const strings to return. It's a minor penalty to pay for simplicity
in all the call sites.
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by:
Drop the local intel_dp_phy_name() function, and replace with
drm_dp_phy_name(). This lets us drop a number of local buffers.
v2: Rebase
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä # v1
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_dp_link_training.c | 83 ---
1 f
On 19-10-21, 18:52, Dmitry Baryshkov wrote:
> On Tue, 19 Oct 2021 at 18:30, Vinod Koul wrote:
> >
> > On 14-10-21, 17:11, Dmitry Baryshkov wrote:
> > > On 07/10/2021 10:08, Vinod Koul wrote:
> >
> > > > +static int _dpu_rm_reserve_dsc(struct dpu_rm *rm,
> > > > + struct dp
Am 2021-10-19 um 7:36 a.m. schrieb Christian König:
> Am 13.10.21 um 16:07 schrieb Daniel Vetter:
>> On Tue, Oct 05, 2021 at 01:37:26PM +0200, Christian König wrote:
>>> Simplifying the code a bit.
>>>
>>> Signed-off-by: Christian König
>>> ---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 14 ++
Hi, Nancy:
Nancy.Lin 於 2021年10月4日 週一 下午2:21寫道：
>
> Add MDP_RDMA driver for MT8195. MDP_RDMA is the DMA engine of
> the ovl_adaptor component.
>
> Signed-off-by: Nancy.Lin
> ---
> drivers/gpu/drm/mediatek/Makefile | 3 +-
> drivers/gpu/drm/mediatek/mtk_disp_drv.h | 7 +
> drivers/gpu/d
On 10/19/21 00:06, Jason Gunthorpe wrote:
> On Mon, Oct 18, 2021 at 12:37:30PM -0700, Dan Williams wrote:
>
>>> device-dax uses PUD, along with TTM, they are the only places. I'm not
>>> sure TTM is a real place though.
>>
>> I was setting device-dax aside because it can use Joao's changes to
>> g
Hey Dan,
On 10/1/2021 6:59 AM, Dan Carpenter wrote:
Hello Abhinav Kumar,
The patch d11a93690df7: "drm/msm/dp: add debugfs support to DP
driver" from Sep 12, 2020, leads to the following
Smatch static checker warning:
drivers/gpu/drm/msm/dp/dp_debug.c:194 dp_debug_read_info()
wa
8b/10b encoding format requires to reserve the first slot for
recording metadata. Real data transmission starts from the second slot,
with a total of available 63 slots available.
In 128b/132b encoding format, metadata is transmitted separately
in LLCP packet before MTP. Real data transmission sta
This code path is used during commit, and we dont expect things to fail
during the commit stage, so remove this.
Signed-off-by: Bhawanpreet Lakha
---
drivers/gpu/drm/drm_dp_mst_topology.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology
On Tue, Oct 05, 2021 at 10:40:14PM -0400, Lyude Paul wrote:
> This simply adds proper support for panel backlights that can be controlled
> via VESA's backlight control protocol, but which also require that we
> enable and disable the backlight via PWM instead of via the DPCD interface.
> We also e
Driver never uses virtual address of DRM CMA buffers. Switch to CMA
helpers which don't deal with virtual mapping.
This was actually already the case before commit ad408c766cef
("drm/sun4i: Use DRM_GEM_CMA_VMAP_DRIVER_OPS for GEM operations"),
but only convenient macro at the time used helpers wit
[Why]
Add DP2 MST and debugfs support
[How]
Update the slot info based on the link encoding format
Signed-off-by: Bhawanpreet Lakha
Signed-off-by: Fangzhi Zuo
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +++
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 3 ++
.../
From: Fangzhi Zuo
Signed-off-by: Fangzhi Zuo
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 14 +
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 280 ++
.../gpu/drm/amd/display/dc/core/dc_link_dp.c | 19 ++
drivers/gpu/drm/amd/display/dc/dc_link.h | 7 +
drivers/
On Tue, Oct 05, 2021 at 10:40:18PM -0400, Lyude Paul wrote:
> Hooray! We've managed to hit enough bugs upstream that I've been able to
> come up with a pretty solid explanation for how backlight controls are
> actually supposed to be detected and used these days. As well, having the
> rest of the P
PUD and PMD entries do not have a special bit.
get_user_pages_fast() considers any page that passed pmd_huge() as
usable:
if (unlikely(pmd_trans_huge(pmd) || pmd_huge(pmd) ||
pmd_devmap(pmd))) {
And vmf_insert_pfn_pmd_prot() unconditionally sets
On Sat, Oct 16, 2021 at 08:42:14PM +0200, Claudio Suarez wrote:
> According to the documentation, drm_add_edid_modes
> "... Also fills out the &drm_display_info structure and ELD in @connector
> with any information which can be derived from the edid."
>
> drm_add_edid_modes accepts a struct edid
On Sat, Oct 16, 2021 at 08:42:26PM +0200, Claudio Suarez wrote:
> Once EDID is parsed, the monitor HDMI support information is available
> through drm_display_info.is_hdmi. Retriving the same information with
> drm_detect_hdmi_monitor() is less efficient. Change to
> drm_display_info.is_hdmi where
Hi,
On 10/19/21 20:21, Jason Gunthorpe wrote:
PUD and PMD entries do not have a special bit.
get_user_pages_fast() considers any page that passed pmd_huge() as
usable:
if (unlikely(pmd_trans_huge(pmd) || pmd_huge(pmd) ||
pmd_devmap(pmd))) {
And vmf
On Tue, Oct 19, 2021 at 08:49:29PM +0200, Thomas Hellström wrote:
> Hi,
>
> On 10/19/21 20:21, Jason Gunthorpe wrote:
> > PUD and PMD entries do not have a special bit.
> >
> > get_user_pages_fast() considers any page that passed pmd_huge() as
> > usable:
> >
> > if (unlikely(pmd_tra
On 10/19/21 20:52, Jason Gunthorpe wrote:
On Tue, Oct 19, 2021 at 08:49:29PM +0200, Thomas Hellström wrote:
Hi,
On 10/19/21 20:21, Jason Gunthorpe wrote:
PUD and PMD entries do not have a special bit.
get_user_pages_fast() considers any page that passed pmd_huge() as
usable:
Hi Thomas,
On 10/19/21 4:17 AM, Thomas Zimmermann wrote:
Hi
Am 18.10.21 um 21:32 schrieb Igor Matheus Andrade Torrente:
Hi Thomas,
On 10/18/21 3:06 PM, Thomas Zimmermann wrote:
Hi
Am 18.10.21 um 19:41 schrieb Igor Matheus Andrade Torrente:
Hello,
On 10/18/21 7:14 AM, Thomas Zimmermann wro
From: Arnd Bergmann
The check_reserve_boundaries() function has a large array on the stack,
over 500 bytes. It gets inlined into __igt_reserve, which has multiple
other large structures as well but stayed just under the stack size
warning limit of 1024 bytes until one more member got added to str
On Tue, Oct 19, 2021 at 9:02 AM Jason Gunthorpe wrote:
>
> On Tue, Oct 19, 2021 at 04:13:34PM +0100, Joao Martins wrote:
> > On 10/19/21 00:06, Jason Gunthorpe wrote:
> > > On Mon, Oct 18, 2021 at 12:37:30PM -0700, Dan Williams wrote:
> > >
> > >>> device-dax uses PUD, along with TTM, they are the
> > >
> > > That will not help validating that new DTs are compliant with the last
> > > version of the bindings.
> > >
> > > We have one tool, and two needs. The tool should be extended to cover
> > > both, but today it can only support one. Which of these two is the most
> > > important:
> > >
Applied. thanks!
On Fri, Oct 15, 2021 at 2:48 AM Qing Wang wrote:
>
> show() must not use snprintf() when formatting the value to be
> returned to user space.
>
> Fix the following coccicheck warning:
> drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:427:
> WARNING: use scnprintf or sprintf.
>
> Signe
19.10.2021 12:47, Robert Foss пишет:
> Applied to drm-misc-next
>
> On Sun, 3 Oct 2021 at 01:35, Dmitry Osipenko wrote:
>>
>> This series adds couple improvements to the TC358768 DSI bridge driver,
>> enabling Panasonic VVX10F004B00 DSI panel support. This panel is used by
>> ASUS Transformer TF7
Hi Pekka,
On 10/19/21 5:05 AM, Pekka Paalanen wrote:
On Mon, 18 Oct 2021 16:26:06 -0300
Igor Matheus Andrade Torrente wrote:
Hi Pekka,
On 10/18/21 5:30 AM, Pekka Paalanen wrote:
On Tue, 5 Oct 2021 17:16:37 -0300
Igor Matheus Andrade Torrente wrote:
Currently the blend function only a
On Tue, Oct 19, 2021 at 05:37:27PM +0200, Christian König wrote:
>
>
> Am 19.10.21 um 14:41 schrieb Daniel Vetter:
> > On Tue, Oct 19, 2021 at 08:23:45PM +0800, guangming@mediatek.com wrote:
> > > From: Guangming Cao
> > >
> > > Since there is no mandatory inspection for attachments in dma_
On Thu, Oct 07, 2021 at 10:19:30AM +0200, AngeloGioacchino Del Regno wrote:
> Convert the Parade PS8622 eDP/DP to LVDS bridge documentation to YAML.
>
> Signed-off-by: AngeloGioacchino Del Regno
>
> ---
> .../display/bridge/parade,ps8622.yaml | 102 ++
> .../bindings/dis
This extends the Rockchip VOP driver to support setting the gamma LUT on the
RK3399 SoC. Previously, the driver supported gamma control for the RK3288
only. On the RK3399 the method for updating the LUT is slightly different.
This implementation was based on the code and description from the vendor
The VOP on RK3399 has a different approach from previous versions for
setting a gamma lookup table, using an update_gamma_lut register. As
this differs from RK3288, give RK3399 its own set of "common" register
definitions.
Signed-off-by: Hugh Cole-Baker
---
Changes from v1: no changes in this pa
The RK3399 has a 1024-entry gamma LUT with 10 bits per component on its
"big" VOP and a 256-entry, 8 bit per component LUT on the "little" VOP.
Compared to the RK3288, it no longer requires disabling gamma while
updating the LUT. On the RK3399, the LUT can be updated at any time as
the hardware has
Define the memory region on RK3399 VOPs containing the gamma LUT at
base+0x2000.
Signed-off-by: Hugh Cole-Baker
---
Changes from v1: no changes in this patch
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/roc
On Tue, Oct 19, 2021 at 09:35:08PM +0300, Ville Syrjälä wrote:
> On Sat, Oct 16, 2021 at 08:42:14PM +0200, Claudio Suarez wrote:
> > According to the documentation, drm_add_edid_modes
> > "... Also fills out the &drm_display_info structure and ELD in @connector
> > with any information which can be
Add CRC support to DPU, which is currently not supported by
this driver. Only supports CRC for CRTC for now, but will extend support
to other blocks later on.
Changes in v2:
- Added kfree() calls for return paths in dpu_crtc_get_crc()
- Propogated error code for dpu_crtc_get_crc()
- Renamed skip_c
According to the documentation, drm_add_edid_modes
"... Also fills out the &drm_display_info structure and ELD in @connector
with any information which can be derived from the edid."
drm_add_edid_modes accepts a struct edid *edid parameter which may have a
value or may be null. When it is not nu
drm_get_edid() internally calls to drm_connector_update_edid_property()
and then drm_add_display_info(), which parses the EDID.
This happens in the function intel_hdmi_set_edid() and
intel_sdvo_tmds_sink_detect() (via intel_sdvo_get_edid()).
Once EDID is parsed, the monitor HDMI support informatio
This series of patches implemented to move i915 buddy allocator
to drm root, and introduce new features include
- make drm_buddy_alloc a prime vehicle for allocation
- TOPDOWN range of address allocation support
- a function to free unused pages on contiguous allocation
- a function to allocate re
- Move i915_buddy.h to include/drm
- rename "i915" string to "drm"
- rename "I915" string to "DRM"
Signed-off-by: Arunpravin
---
drivers/gpu/drm/i915/i915_buddy.h | 143 --
include/drm/drm_buddy.h | 143 ++
2 files changed, 143 in
- Move i915_buddy.c to drm root folder
- Rename "i915" string with "drm" string wherever applicable
- Rename "I915" string with "DRM" string wherever applicable
- Fix header file dependencies
- Fix alignment issues
Signed-off-by: Arunpravin
---
.../drm/{i915/i915_buddy.c => drm_buddy.c}| 193
- Include drm buddy to DRM root Makefile
- Add drm buddy init and exit function calls
to drm core
Signed-off-by: Arunpravin
---
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_drv.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/Makefile b/drivers/
- Make drm_buddy_alloc a single function to handle
range allocation and non-range allocation demands.
- Implemented a new function alloc_range() which allocates
the requested order (in bytes) comply with range limitations
- Moved memory alignment logic from i915 driver
Signed-off-by: Arunpra
1 - 100 of 126 matches
Mail list logo
