[PATCH] drm/amd/display: Remove unnecessary conversion to bool

Fix the following coccicheck warnings: ./drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c:270:16-21: WARNING: conversion to bool not needed here. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- drivers/gpu/drm/amd/display/dc/dce/dmub_psr.c | 3 +-- 1 file changed, 1 insertion(+), 2

[PATCH] drm/amd/display/dc/core/dc_link_ddc: Remove unnecessary conversion to bool

Fix the following coccicheck warnings: ./drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c:544:34-39: WARNING: conversion to bool not needed here. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c | 2 +- 1 file changed, 1

[PATCH v2] drm/amdgpu/swsmu/navi1x: Remove unnecessary conversion to bool

Fix the following coccicheck warnings: ./drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c:900:47-52: WARNING: conversion to bool not needed here. Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH RFC v1 5/6] xen-swiotlb: convert variables to arrays

On 2/19/21 3:32 PM, Konrad Rzeszutek Wilk wrote: > On Sun, Feb 07, 2021 at 04:56:01PM +0100, Christoph Hellwig wrote: >> On Thu, Feb 04, 2021 at 09:40:23AM +0100, Christoph Hellwig wrote: >>> So one thing that has been on my mind for a while: I'd really like >>> to kill the separate dma ops in

Re: [PATCH 01/30] drm/dp: Rewrap kdocs for struct drm_dp_aux

On 2/19/21 1:52 PM, Lyude Paul wrote: > Since we're about to be adding some more fields and update this > documentation, let's rewrap it to the new column limit of 100 beforehand. > No actual doc or functional changes are made here. > The preferred column limit is still 80. For some (exceptional)

Re: [PATCH 02/30] drm/dp: Fixup kernel docs for struct drm_dp_aux

On 2/19/21 1:52 PM, Lyude Paul wrote: > * Make sure that struct members are referred to using @, otherwise they > won't be formatted as such > * Make sure to refer to other struct types using & so they link back to > each struct's definition > * Make sure to precede constant values with % so

Re: [PATCH v2 2/2] drm/msm/dp: add supported max link rate specified from dtsi

Quoting khs...@codeaurora.org (2021-02-19 08:39:38) > On 2021-02-18 15:02, Stephen Boyd wrote: > > Quoting Kuogee Hsieh (2021-02-18 12:55:04) > >> Allow supported link rate to be limited to the value specified at > >> dtsi. If it is not specified, then link rate is derived from dpcd > >> directly.

[PATCH 29/30] drm/dp_dual_mode: Convert drm_dp_dual_mode_helper.c to using drm_err/drm_dbg_kms()

Next step in the conversion, move everything in drm_dp_dual_mode_helper.c over to using drm_err() and drm_dbg_kms(). This was done using the following cocci script: @@ expression list expr; @@ ( - DRM_DEBUG_KMS(expr); + drm_dbg_kms(dev, expr); | - DRM_ERROR(expr); +

[PATCH 30/30] drm/dp_mst: Convert drm_dp_mst_topology.c to drm_err()/drm_dbg*()

And finally, convert all of the code in drm_dp_mst_topology.c over to using drm_err() and drm_dbg*(). Note that this refactor would have been a lot more complicated to have tried writing a coccinelle script for, so this whole thing was done by hand. Signed-off-by: Lyude Paul ---

[PATCH 27/30] drm/dp_mst: Pass drm_dp_mst_topology_mgr to drm_dp_get_vc_payload_bw()

Since this is one of the few functions in drm_dp_mst_topology.c that doesn't have any way of getting access to a drm_device, let's pass the drm_dp_mst_topology_mgr down to this function so that it can use drm_dbg_kms(). Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_dp_mst_topology.c |

[PATCH 26/30] drm/dp_dual_mode: Pass drm_device to drm_lspcon_(get|set)_mode()

So that we can start using drm_dbg_*() throughout the DRM DP helpers. Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_dp_dual_mode_helper.c | 8 +--- drivers/gpu/drm/i915/display/intel_lspcon.c | 12 +++- include/drm/drm_dp_dual_mode_helper.h | 4 ++-- 3 files changed,

[PATCH 28/30] drm/dp: Convert drm_dp_helper.c to using drm_err/drm_dbg_*()

Now that we've added a back-pointer to drm_device to drm_dp_aux, made drm_dp_aux available to any functions in drm_dp_helper.c which need to print to the kernel log, and ensured all of our logging uses a consistent format, let's do the final step of the conversion and actually move everything over

[PATCH 25/30] drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_get_tmds_output()

Another function to pass drm_device * down to so we can start using the drm_dbg_*() in the DRM DP helpers. Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_dp_dual_mode_helper.c | 5 +++-- include/drm/drm_dp_dual_mode_helper.h | 2 +- 2 files changed, 4 insertions(+), 3 deletions(-) diff

[PATCH 24/30] drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_max_tmds_clock()

Another function we need to pass drm_device down to in order to start using drm_dbg_*(). Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_dp_dual_mode_helper.c | 3 ++- drivers/gpu/drm/i915/display/intel_hdmi.c | 2 +- include/drm/drm_dp_dual_mode_helper.h | 2 +- 3 files changed, 4

[PATCH 22/30] drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_detect()

Since we're about to be using drm_dbg_*() throughout the DP helpers, we'll need to be able to access the DRM device in the dual mode DP helpers as well. Note however that since drm_dp_dual_mode_detect() can be called with DDC adapters that aren't part of a drm_dp_aux struct, we need to pass down

[PATCH 23/30] drm/dp_dual_mode: Pass drm_device to drm_dp_dual_mode_set_tmds_output()

Another function that we'll need to pass a drm_device (and not drm_dp_aux) down to so that we can move over to using drm_dbg_*(). Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_dp_dual_mode_helper.c | 3 ++- drivers/gpu/drm/i915/display/intel_hdmi.c | 3 +--

[PATCH 21/30] drm/dp: Always print aux channel name in logs

Since we're about to convert everything in drm_dp_helper.c over to using drm_dbg_*(), let's also make our logging more consistent in drm_dp_helper.c while we're at it to ensure that we always print the name of the AUX channel in question. Signed-off-by: Lyude Paul ---

[PATCH 20/30] drm/dp: Pass drm_dp_aux to drm_dp*_link_train_channel_eq_delay()

So that we can start using drm_dbg_*() for drm_dp_link_train_channel_eq_delay() and drm_dp_lttpr_link_train_channel_eq_delay(). Signed-off-by: Lyude Paul --- drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +- drivers/gpu/drm/drm_dp_helper.c| 14 +-

[PATCH 16/30] drm/dp: Rewrap drm_dp_aux_register()/drm_dp_aux_init() kdocs

We're about to make a correction to these, so let's rewrap the kernel docs for these while we're at it. Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_dp_helper.c | 19 --- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c

[PATCH 15/30] drm/dp: Add backpointer to drm_device in drm_dp_aux

This is something that we've wanted for a while now: the ability to actually look up the respective drm_device for a given drm_dp_aux struct. This will also allow us to transition over to using the drm_dbg_*() helpers for debug message printing, as we'll finally have a drm_device to reference for

[PATCH 17/30] drm/dp: Clarify DP AUX registration time

The docs we had for drm_dp_aux_init() and drm_dp_aux_register() were mostly correct, except for the fact that they made the assumption that all AUX devices were grandchildren of their respective DRM devices. This is the case for most normal GPUs, but is almost never the case with SoCs and display

[PATCH 19/30] drm/dp: Pass drm_dp_aux to drm_dp_link_train_clock_recovery_delay()

So that we can start using drm_dbg_*() in drm_dp_link_train_clock_recovery_delay(). Signed-off-by: Lyude Paul --- drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +- drivers/gpu/drm/drm_dp_helper.c | 3 ++- drivers/gpu/drm/i915/display/intel_dp_link_training.c |

[PATCH 18/30] drm/print: Fixup DRM_DEBUG_KMS_RATELIMITED()

Since we're about to move drm_dp_helper.c over to drm_dbg_*(), we'll want to make sure that we can also add ratelimited versions of these macros in order to retain some of the previous debugging output behavior we had. However, as I was preparing to do this I noticed that the current rate limited

[PATCH 13/30] drm/bridge/analogix/dp_core: Unregister DP AUX channel on error in analogix_dp_probe()

Just another drive-by fix I noticed while going through the tree to cleanup DP aux adapter registration - make sure we unregister the DP AUX dev if analogix_dp_probe() fails. Signed-off-by: Lyude Paul --- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 + 1 file changed, 1 insertion(+)

[PATCH 14/30] drm/nouveau/kms/nv50-: Move AUX adapter reg to connector late register/early unregister

Since AUX adapters on nouveau have their respective DRM connectors as parents, we need to make sure that we register then after their connectors. Signed-off-by: Lyude Paul --- drivers/gpu/drm/nouveau/nouveau_connector.c | 26 ++--- 1 file changed, 18 insertions(+), 8

[PATCH 11/30] drm/bridge/analogix/anx6345: Don't link encoder until after connector registration

Another case of linking an encoder to a connector after the connector's been registered. The proper place to do this is before connector registration, so let's fix that. Signed-off-by: Lyude Paul --- drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 12 ++-- 1 file changed, 6

[PATCH 12/30] drm/bridge/analogix/anx6345: Cleanup on errors in anx6345_bridge_attach()

Another drive-by fix I found when fixing DP AUX adapter across the kernel tree - make sure we don't leak resources (and by proxy-AUX adapters) on failures in anx6345_bridge_attach() by unrolling on errors. Signed-off-by: Lyude Paul --- drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 11

[PATCH 10/30] drm/bridge/analogix/anx6345: Add missing drm_dp_aux_unregister() call

Another driver I found that seems to forget to unregister it's DP AUX device. Let's fix this by adding anx6345_bridge_detach(). Signed-off-by: Lyude Paul --- drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 6 ++ 1 file changed, 6 insertions(+) diff --git

[PATCH 03/30] drm/tegra: Don't register DP AUX channels before connectors

As pointed out by the documentation for drm_dp_aux_register(), drm_dp_aux_init() should be used in situations where the AUX channel for a display driver can potentially be registered before it's respective DRM driver. This is the case with Tegra, since the DP aux channel exists as a platform

[PATCH 08/30] drm/bridge/analogix/anx78xx: Setup encoder before registering connector

Since encoder mappings for connectors are exposed to userspace, we should be attaching the encoder before exposing the connector to userspace. Just a drive-by fix for an issue I noticed while fixing up usages of drm_dp_aux_init()/drm_dp_aux_register() across the tree. Signed-off-by: Lyude Paul

[PATCH 04/30] drm/bridge/tc358767: Don't register DP AUX channel until bridge is attached

Since this is a bridge, we don't start out with a respective DRM device. Likewise this means we don't have a connector, which also means that we should be following drm_dp_aux_register()'s documentation advice and not call drm_dp_aux_register() until we have a matching connector. Instead, call

[PATCH 07/30] drm/bridge/analogix/anx78xx: Add missing drm_dp_aux_unregister() call

Surprisingly, this bridge actually registers it's AUX adapter at the correct time already. Nice job! However, it does forget to actually unregister the AUX adapter, so let's add a bridge function to handle that. Signed-off-by: Lyude Paul --- drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c |

[PATCH 06/30] drm/bridge/ti-sn65dsi86: (Un)register aux device on bridge attach/detach

Since we're about to add a back-pointer to drm_dev in drm_dp_aux, let's move the AUX adapter registration to the first point where we know which DRM device we'll be working with - when the drm_bridge is attached. Likewise, we unregister the AUX adapter on bridge detachment by adding a

[PATCH 09/30] drm/bridge/analogix/anx78xx: Cleanup on error in anx78xx_bridge_attach()

Just another issue I noticed while correcting usages of drm_dp_aux_init()/drm_dp_aux_register() around the tree. If any of the steps in anx78xx_bridge_attach() fail, we end up leaking resources. So, let's fix that (and fix leaking a DP AUX adapter in the process) by unrolling on errors.

[PATCH 05/30] drm/bridge/cdns-mhdp8546: Register DP aux channel with userspace

Just adds some missing calls to drm_dp_aux_register()/drm_dp_aux_unregister() for when we attach/detach the bridge. Signed-off-by: Lyude Paul --- drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git

[PATCH 02/30] drm/dp: Fixup kernel docs for struct drm_dp_aux

* Make sure that struct members are referred to using @, otherwise they won't be formatted as such * Make sure to refer to other struct types using & so they link back to each struct's definition * Make sure to precede constant values with % so they're formatted correctly Signed-off-by:

[PATCH 01/30] drm/dp: Rewrap kdocs for struct drm_dp_aux

Since we're about to be adding some more fields and update this documentation, let's rewrap it to the new column limit of 100 beforehand. No actual doc or functional changes are made here. Signed-off-by: Lyude Paul --- include/drm/drm_dp_helper.h | 42 - 1

[PATCH 00/30] drm: Use new DRM printk funcs (like drm_dbg_*()) in DP helpers

Since it's been asked quite a few times on some of the various DP related patch series I've submitted to use the new DRM printk helpers, and it technically wasn't really trivial to do this before due to the lack of a consistent way to find a drm_device for an AUX channel, this patch series aims to

Re: [PATCH v3 2/2] drm/bridge: Introduce LT8912 DSI to HDMI bridge

Le ven. 19 févr. 2021 à 22:28, Robert Foss a écrit : > > On Fri, 19 Feb 2021 at 16:01, Adrien Grassein > wrote: > > > > Hey Robert, > > > > Le ven. 19 févr. 2021 à 14:27, Robert Foss a écrit > > : > > > > > > Hey Adrien, > > > > > > > > > Thanks for the quick update. > > No problem, I have

Re: [PATCH v6 3/3] drm: Add GUD USB Display driver

Hi Noralf, Noralf Trønnes wrote: > +++ b/drivers/gpu/drm/gud/gud_connector.c .. > +static int gud_connector_get_edid_block(void *data, u8 *buf, unsigned int > block, size_t len) .. > + struct gud_connector *gconn = ctx->gconn; > + size_t start = block * EDID_LENGTH; > + > + if (start

Re: [PATCH v3 2/2] drm/bridge: Introduce LT8912 DSI to HDMI bridge

On Fri, 19 Feb 2021 at 16:01, Adrien Grassein wrote: > > Hey Robert, > > Le ven. 19 févr. 2021 à 14:27, Robert Foss a écrit : > > > > Hey Adrien, > > > > > > Thanks for the quick update. > No problem, I have some free time at the moment. > > > > On Thu, 18 Feb 2021 at 22:05, Adrien Grassein >

Re: [Intel-gfx] [RFC v4 10/11] drm/dp: Extract i915's eDP backlight code into DRM helpers

On Thu, 2021-02-18 at 17:31 +0200, Ville Syrjälä wrote: > On Thu, Feb 18, 2021 at 10:35:05AM +0200, Jani Nikula wrote: > > On Fri, 12 Feb 2021, Lyude Paul wrote: > > > I think it wouldn't be a bad idea to just address this with a followup > > > series > > > instead and use the old DRM_DEBUG_*

Re: [PATCH RFC v1 5/6] xen-swiotlb: convert variables to arrays

On Sun, Feb 07, 2021 at 04:56:01PM +0100, Christoph Hellwig wrote: > On Thu, Feb 04, 2021 at 09:40:23AM +0100, Christoph Hellwig wrote: > > So one thing that has been on my mind for a while: I'd really like > > to kill the separate dma ops in Xen swiotlb. If we compare xen-swiotlb > > to swiotlb

[Bug 211501] Kernel freeze when waking monitor from blanking / DPMS (AMDGPU / DC)

https://bugzilla.kernel.org/show_bug.cgi?id=211501 --- Comment #4 from Jasen Borisov (borisovja...@protonmail.com) --- I suspect you might be experiencing a different bug from mine, because in my case the kernel recovers after some time and everything is back in a usable state. There could be

Re: [PATCH v2] drm/scheduler: Fix hang when sched_entity released

Ping Andrey On 2/18/21 11:41 AM, Andrey Grodzovsky wrote: On 2/18/21 10:15 AM, Christian König wrote: Am 18.02.21 um 16:05 schrieb Andrey Grodzovsky: On 2/18/21 3:07 AM, Christian König wrote: Am 17.02.21 um 22:59 schrieb Andrey Grodzovsky: Problem: If scheduler is already stopped by

Re: [PATCH V1 0/2] Fix WLED FSC Sync and brightness Sync settings

Hi! > The FSC (Full scale current) setting is not updated properly due to the > wrong register toggling for WLED5. Also the ILED_SYNC toggle and MOD_SYNC > toggle sequence is updated as per the hardware team recommendation to fix > the FSC update and brightness update issue. If this is phone

Re: [PATCH] drm/shmem-helper: Don't remove the offset in vm_area_struct pgoff

On Fri, Feb 19, 2021 at 5:17 PM Steven Price wrote: > > On 19/02/2021 15:13, Daniel Vetter wrote: > > On Fri, Feb 19, 2021 at 01:36:06PM +, Steven Price wrote: > >> On 18/02/2021 18:20, Daniel Vetter wrote: > >>> On Thu, Feb 18, 2021 at 6:16 PM Rob Herring wrote: > > On Thu, Feb

Re: [PATCH] drm/prime: Only call dma_map_sgtable() for devices with DMA support

On Fri, Feb 19, 2021 at 04:56:16PM +0100, Christian König wrote: > > > Am 19.02.21 um 16:53 schrieb Alan Stern: > > On Fri, Feb 19, 2021 at 02:45:54PM +0100, Christian König wrote: > > > Well as far as I can see this is a relative clear NAK. > > > > > > When a device can't do DMA and has no DMA

Re: [PATCH v2 2/2] drm/msm/dp: add supported max link rate specified from dtsi

On 2021-02-18 15:02, Stephen Boyd wrote: Quoting Kuogee Hsieh (2021-02-18 12:55:04) Allow supported link rate to be limited to the value specified at dtsi. If it is not specified, then link rate is derived from dpcd directly. Below are examples, link-rate = <162000> for max link rate limited at

[PATCH V1 1/2] backlight: qcom-wled: Fix FSC update issue for WLED5

Currently, for WLED5, after FSC register update MOD_SYNC_BIT is toggled instead of SYNC_BIT. MOD_SYNC_BIT has to be toggled after the brightness update and SYNC_BIT has to be toggled after FSC update for WLED5. Fix it. Signed-off-by: Kiran Gunda --- drivers/video/backlight/qcom-wled.c | 25

[PATCH V1 0/2] Fix WLED FSC Sync and brightness Sync settings

The FSC (Full scale current) setting is not updated properly due to the wrong register toggling for WLED5. Also the ILED_SYNC toggle and MOD_SYNC toggle sequence is updated as per the hardware team recommendation to fix the FSC update and brightness update issue. Kiran Gunda (2): backlight:

[PATCH V1 2/2] backlight: qcom-wled: Correct the sync_toggle sequence

Currently the FSC SYNC_BIT and MOD_SYNC_BIT are toggled from 1 to 0 to update the FSC and brightenss settings. Change this sequence form 0 to 1 as per the hardware team recommendation to update the FSC and brightness correctly. Signed-off-by: Kiran Gunda --- drivers/video/backlight/qcom-wled.c

Re: [PATCH] drm/shmem-helper: Don't remove the offset in vm_area_struct pgoff

On 19/02/2021 15:13, Daniel Vetter wrote: On Fri, Feb 19, 2021 at 01:36:06PM +, Steven Price wrote: On 18/02/2021 18:20, Daniel Vetter wrote: On Thu, Feb 18, 2021 at 6:16 PM Rob Herring wrote: On Thu, Feb 18, 2021 at 10:51 AM Steven Price wrote: On 18/02/2021 16:38, Rob Herring

Re: [PATCH] drm/panel: kd35t133: allow using non-continuous dsi clock

On Sat, 6 Feb 2021 at 10:50, Heiko Stuebner wrote: > > The panel is able to work when dsi clock is non-continuous, thus > the system power consumption can be reduced using such feature. > > Add MIPI_DSI_CLOCK_NON_CONTINUOUS to panel's mode_flags. > > Also the flag actually becomes necessary after

RE: [PATCH] drm/panel: elida-kd35t133: allow using non-continuous dsi clock

Yes, I just spoke with him via email. I can confirm his fix/my fix/whichever fix solves the issue on the latest 5.11 kernel. From: Ezequiel Garcia Sent: Friday, February 19, 2021 10:00 AM To: Chris Morgan Cc:

Re: [PATCH] drm/prime: Only call dma_map_sgtable() for devices with DMA support

On Fri, Feb 19, 2021 at 02:45:54PM +0100, Christian König wrote: > Well as far as I can see this is a relative clear NAK. > > When a device can't do DMA and has no DMA mask then why it is requesting an > sg-table in the first place? This may not be important for your discussion, but I'd like to

Re: [PATCH] drm/panel: elida-kd35t133: allow using non-continuous dsi clock

On Fri, 19 Feb 2021 at 00:14, Chris Morgan wrote: > > This fixes an issue with the panel not working after > commit c6d94e37bdbb ("drm/bridge/synopsys: dsi: add support for > non-continuous HS clock"). > With this change the panel inits successfully and displays an image. > > Signed-off-by:

Re: [PATCH] drm/msm/a6xx: fix for kernels without CONFIG_NVMEM

On Fri, Feb 19, 2021 at 2:44 AM Akhil P Oommen wrote: > > On 2/18/2021 9:41 PM, Rob Clark wrote: > > On Thu, Feb 18, 2021 at 4:28 AM Akhil P Oommen > > wrote: > >> > >> On 2/18/2021 2:05 AM, Jonathan Marek wrote: > >>> On 2/17/21 3:18 PM, Rob Clark wrote: > On Wed, Feb 17, 2021 at 11:08 AM

Re: [PATCH] drm/prime: Only call dma_map_sgtable() for devices with DMA support

Am 19.02.21 um 16:53 schrieb Alan Stern: On Fri, Feb 19, 2021 at 02:45:54PM +0100, Christian König wrote: Well as far as I can see this is a relative clear NAK. When a device can't do DMA and has no DMA mask then why it is requesting an sg-table in the first place? This may not be important

Re: [PATCH v2] drm/vblank: Do not store a new vblank timestamp in drm_vblank_restore()

On Fri, Feb 19, 2021 at 04:08:09PM +0100, Daniel Vetter wrote: > On Thu, Feb 18, 2021 at 06:03:05PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > drm_vblank_restore() exists because certain power saving states > > can clobber the hardware frame counter. The way it does this is > >

Re: [PATCH] drm/shmem-helper: Don't remove the offset in vm_area_struct pgoff

On Fri, Feb 19, 2021 at 01:36:06PM +, Steven Price wrote: > On 18/02/2021 18:20, Daniel Vetter wrote: > > On Thu, Feb 18, 2021 at 6:16 PM Rob Herring wrote: > > > > > > On Thu, Feb 18, 2021 at 10:51 AM Steven Price > > > wrote: > > > > > > > > On 18/02/2021 16:38, Rob Herring wrote: > > >

Re: [PATCH v3 02/11] drm: Rename plane atomic_check state names

Hi Thomas, Thanks for your review! On Fri, Feb 19, 2021 at 03:49:22PM +0100, Thomas Zimmermann wrote: > > diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c > > b/drivers/gpu/drm/imx/ipuv3-plane.c > > index 075508051b5f..1873a155bb26 100644 > > --- a/drivers/gpu/drm/imx/ipuv3-plane.c > > +++

Re: [PATCH v2] drm/vblank: Do not store a new vblank timestamp in drm_vblank_restore()

On Thu, Feb 18, 2021 at 06:03:05PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > drm_vblank_restore() exists because certain power saving states > can clobber the hardware frame counter. The way it does this is > by guesstimating how many frames were missed purely based on > the

Re: [PATCH v3 2/2] drm/bridge: Introduce LT8912 DSI to HDMI bridge

Hey Robert, Le ven. 19 févr. 2021 à 14:27, Robert Foss a écrit : > > Hey Adrien, > > > Thanks for the quick update. No problem, I have some free time at the moment. > > On Thu, 18 Feb 2021 at 22:05, Adrien Grassein > wrote: > > > > Lontium Lt8912 is a DSI to HDMI bridge. > > > > Signed-off-by:

Re: [PATCH v3 02/11] drm: Rename plane atomic_check state names

Am 19.02.21 um 13:00 schrieb Maxime Ripard: Most drivers call the argument to the plane atomic_check hook simply state, which is going to conflict with the global atomic state in a later rework. Let's rename it to new_plane_state (or new_state depending on the convention used in the driver).

Re: [PATCH] drm/prime: Only call dma_map_sgtable() for devices with DMA support

On Fri, Feb 19, 2021 at 3:35 PM Thomas Zimmermann wrote: > > Hi > > Am 19.02.21 um 14:45 schrieb Christian König: > > Well as far as I can see this is a relative clear NAK. > > > > When a device can't do DMA and has no DMA mask then why it is requesting > > an sg-table in the first place? > > > >

Re: [PATCH] drm/prime: Only call dma_map_sgtable() for devices with DMA support

Am 19.02.21 um 15:34 schrieb Thomas Zimmermann: Hi Am 19.02.21 um 14:45 schrieb Christian König: Well as far as I can see this is a relative clear NAK. When a device can't do DMA and has no DMA mask then why it is requesting an sg-table in the first place? The problem is rather in

Re: [PATCH] drm/prime: Only call dma_map_sgtable() for devices with DMA support

Hi Am 19.02.21 um 14:45 schrieb Christian König: Well as far as I can see this is a relative clear NAK. When a device can't do DMA and has no DMA mask then why it is requesting an sg-table in the first place? The problem is rather in drm_gem_prime_import_dev() which always tries to create

Re: [PATCH v2 1/4] hmm: Device exclusive memory access

On Fri, Feb 19, 2021 at 09:47:41AM +, Christoph Hellwig wrote: > > diff --git a/include/linux/hmm.h b/include/linux/hmm.h > > index 866a0fa104c4..5d28ff6d4d80 100644 > > +++ b/include/linux/hmm.h > > @@ -109,6 +109,10 @@ struct hmm_range { > > */ > > int hmm_range_fault(struct hmm_range

[PATCH v4 2/7] drm/of: Change the prototype of drm_of_lvds_get_dual_link_pixel_order

The drm_of_lvds_get_dual_link_pixel_order() function took so far the device_node of the two ports used together to make up a dual-link LVDS output. This assumes that a binding would use an entire port for the LVDS output. However, some bindings have used endpoints instead and thus we need to

[PATCH v4 6/7] drm/sun4i: tcon: Enable the A20 dual-link output

The A20 second TCON (TCON1) can be used as a secondary output to drive a dual-link LVDS output. Let's add it to our capabilities. Reviewed-by: Chen-Yu Tsai Signed-off-by: Maxime Ripard --- drivers/gpu/drm/sun4i/sun4i_tcon.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH v4 7/7] [DO NOT MERGE] ARM: dts: sun7i: Enable LVDS Dual-Link on the Cubieboard

For the sake of the example, let's enable an LVDS Dual-Link display on a Cubieboard. Signed-off-by: Maxime Ripard --- arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 69 + 1 file changed, 69 insertions(+) diff --git a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts

[PATCH v4 4/7] drm/sun4i: tcon: Refactor the LVDS and panel probing

The current code to parse the DT, deal with the older device trees, and register either the RGB or LVDS output has so far grown organically into the bind function and has become quite hard to extend properly. Let's move it into a single function that grabs all the resources it needs and registers

[PATCH v4 5/7] drm/sun4i: tcon: Support the LVDS Dual-Link

The A20 and other SoC with two TCONs (A31, R40, etc.) can use its second TCON as the secondary LVDS link in a dual-link setup, with the TCON0 being the main link. Extend a bit the parsing code to leverage the DRM dual-link code, register only the LVDS output on the primary TCON, and add the needed

[PATCH v4 3/7] dt-bindings: display: sun4i: Add LVDS Dual-Link property

The Allwinner SoCs with two TCONs and LVDS output can use both to drive an LVDS dual-link. Add a new property to express that link between these two TCONs. Signed-off-by: Maxime Ripard --- .../bindings/display/allwinner,sun4i-a10-tcon.yaml | 6 ++ 1 file changed, 6 insertions(+)

[PATCH v4 0/7] drm/sun4i: Add support for dual-link LVDS on the A20

Hi, This is a fourth attempt at supporting the LVDS dual-link output on the Allwinner A20. Let me know what you think, Maxime Changes from v3: - Reintroduce the endpoint sanity check (and make of_graph_get_port_by_id const in the process) - Make a few doc fixes - Fix device_node

[PATCH v4 1/7] of: Make of_graph_get_port_by_id take a const device_node

of_graph_get_port_by_id doesn't modify the device_node pointer it takes as argument, so we can make it const. Signed-off-by: Maxime Ripard --- drivers/of/property.c| 2 +- include/linux/of_graph.h | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/of/property.c

Re: [PATCH] drm/shmem-helpers: vunmap: Don't put pages for dma-buf

Hi Am 19.02.21 um 13:22 schrieb Noralf Trønnes: dma-buf importing was reworked in commit 7d2cd72a9aa3 ("drm/shmem-helpers: Simplify dma-buf importing"). Before that commit drm_gem_shmem_prime_import_sg_table() did set ->pages_use_count=1 and drm_gem_shmem_vunmap_locked() could call

Re: [PATCH] drm/prime: Only call dma_map_sgtable() for devices with DMA support

Well as far as I can see this is a relative clear NAK. When a device can't do DMA and has no DMA mask then why it is requesting an sg-table in the first place? The problem is rather in drm_gem_prime_import_dev() which always tries to create an sg-table to get a GEM object, even when the

[PATCH] drm/prime: Only call dma_map_sgtable() for devices with DMA support

Fixes a regression for udl and probably other USB-based drivers where joining and mirroring displays fails. Joining displays requires importing a dma_buf from another DRM driver. These devices don't support DMA and therefore have no DMA mask. Trying to map imported buffers from a DMA-able memory

Re: [PATCH] drm/shmem-helper: Don't remove the offset in vm_area_struct pgoff

On 18/02/2021 18:20, Daniel Vetter wrote: On Thu, Feb 18, 2021 at 6:16 PM Rob Herring wrote: On Thu, Feb 18, 2021 at 10:51 AM Steven Price wrote: On 18/02/2021 16:38, Rob Herring wrote: On Thu, Feb 18, 2021 at 10:15 AM Steven Price wrote: On 18/02/2021 15:45, Alyssa Rosenzweig wrote:

Re: [PATCH v3 2/2] drm/bridge: Introduce LT8912 DSI to HDMI bridge

Hey Adrien, Thanks for the quick update. On Thu, 18 Feb 2021 at 22:05, Adrien Grassein wrote: > > Lontium Lt8912 is a DSI to HDMI bridge. > > Signed-off-by: Adrien Grassein > --- > MAINTAINERS | 1 + > drivers/gpu/drm/bridge/Kconfig | 14 + >

[PATCH] drm/shmem-helpers: vunmap: Don't put pages for dma-buf

dma-buf importing was reworked in commit 7d2cd72a9aa3 ("drm/shmem-helpers: Simplify dma-buf importing"). Before that commit drm_gem_shmem_prime_import_sg_table() did set ->pages_use_count=1 and drm_gem_shmem_vunmap_locked() could call drm_gem_shmem_put_pages() unconditionally. Now without the use

[PATCH v6 3/3] drm: Add GUD USB Display driver

This adds a USB display driver with the intention that it can be used with future USB interfaced low end displays/adapters. The Linux gadget device driver will serve as the canonical device implementation. The following DRM properties are supported: - Plane rotation - Connector TV properties

[PATCH v6 1/3] drm/uapi: Add USB connector type

Add a connector type for USB connected display panels. Some examples of what current userspace will name the connector: - Weston: "UNNAMED-%d" - Mutter: "Unknown20-%d" - X: "Unknown20-%d" v2: - Update drm_connector_enum_list - Add examples to commit message Acked-by: Daniel Vetter

[PATCH v6 0/3] GUD USB Display driver

Hi, A while back I had the idea to turn a Raspberry Pi Zero into a $5 USB to HDMI/SDTV/DPI display adapter. The protocol is open so people are free to make displays implementing it and use this driver, all that's needed is to add a USB vid:pid to the driver for the display. See the wiki[1] for

[PATCH v6 2/3] drm/probe-helper: Check epoch counter in output_poll_execute()

drm_helper_hpd_irq_event() checks the epoch counter to determine connector status change. This was introduced in commit 5186421cbfe2 ("drm: Introduce epoch counter to drm_connector"). Do the same for output_poll_execute() so it can detect other changes beside connection status value changes. v2:

Re: [PATCH 2/5] drm/omap: hdmi4: switch to the cec bridge ops

Hi Hans, Thank you for the patch. On Thu, Feb 11, 2021 at 11:37:00AM +0100, Hans Verkuil wrote: > Implement the new CEC bridge ops. This makes it possible to associate > a CEC adapter with a drm connector, which helps userspace determine > with cec device node belongs to which drm connector. >

Re: [PATCH 1/5] drm: drm_bridge: add cec_init/exit bridge ops

Hi Hans, Thank you for the patch. On Thu, Feb 11, 2021 at 11:36:59AM +0100, Hans Verkuil wrote: > Add bridge cec_init/exit ops. These ops will be responsible for > creating and destroying the CEC adapter for the bridge that supports > CEC. > > Signed-off-by: Hans Verkuil > --- >

[PATCH v3 11/11] drm/todo: Remove the drm_atomic_state todo item

Only planes' prepare_fb and cleanup_fb, and encoders' atomic_check and atomic_mode_set hooks remain with an object state and not the global drm_atomic_state. prepare_fb and cleanup_fb operate by design on a given state and depending on the calling site can operate on either the old or new state,

[PATCH v3 10/11] drm: Use state helper instead of the plane state pointer

Many drivers reference the plane->state pointer in order to get the current plane state in their atomic_update or atomic_disable hooks, which would be the new plane state in the global atomic state since _swap_state happened when those hooks are run. Use the drm_atomic_get_new_plane_state helper

[PATCH v3 09/11] drm/atomic: Pass the full state to planes atomic disable and update

The current atomic helpers have either their object state being passed as an argument or the full atomic state. The former is the pattern that was done at first, before switching to the latter for new hooks or when it was needed. Let's convert the remaining helpers to provide a consistent

[PATCH v3 07/11] drm: Store new plane state in a variable for atomic_update and disable

In order to store the new plane state in a subsequent helper, let's move the plane->state dereferences into a variable. This was done using the following coccinelle script, plus some hand changes for vmwgfx: @ plane_atomic_func @ identifier helpers; identifier func; @@ ( static const struct

[PATCH v3 08/11] drm: Rename plane->state variables in atomic update and disable

Some drivers are storing the plane->state pointer in atomic_update and atomic_disable in a variable simply called state, while the state passed as an argument is called old_state. In order to ease subsequent reworks and to avoid confusing or inconsistent names, let's rename those variables to

[PATCH v3 06/11] drm: Use state helper instead of plane state pointer in atomic_check

Many drivers reference the plane->state pointer in order to get the current plane state in their atomic_check hook, which would be the old plane state in the global atomic state since _swap_state hasn't happened when atomic_check is run. Use the drm_atomic_get_old_plane_state helper to get that

[PATCH v3 05/11] drm: Use the state pointer directly in planes atomic_check

Now that atomic_check takes the global atomic state as a parameter, we don't need to go through the pointer in the plane state. This was done using the following coccinelle script: @ plane_atomic_func @ identifier helpers; identifier func; @@ static struct drm_plane_helper_funcs helpers = {

[PATCH v3 03/11] drm/atmel-hlcdc: Rename custom plane state variable

Subsequent reworks will pass the global atomic state in the function prototype, and atomic_check and atomic_update already have such a variable already. Let's change them to ease the rework. Acked-by: Sam Ravnborg Signed-off-by: Maxime Ripard --- .../gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |

[PATCH v3 04/11] drm/atomic: Pass the full state to planes atomic_check

The current atomic helpers have either their object state being passed as an argument or the full atomic state. The former is the pattern that was done at first, before switching to the latter for new hooks or when it was needed. Let's convert all the remaining helpers to provide a consistent

[PATCH v3 02/11] drm: Rename plane atomic_check state names

Most drivers call the argument to the plane atomic_check hook simply state, which is going to conflict with the global atomic state in a later rework. Let's rename it to new_plane_state (or new_state depending on the convention used in the driver). This was done using the coccinelle script below,

[PATCH v3 01/11] drm/atomic: Pass the full state to planes async atomic check and update

The current atomic helpers have either their object state being passed as an argument or the full atomic state. The former is the pattern that was done at first, before switching to the latter for new hooks or when it was needed. Let's start convert all the remaining helpers to provide a

  1   2   >