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

On Tue, Oct 19, 2021 at 03:02:13PM +0300, Laurent Pinchart wrote: > 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 a

Re: (subset) [PATCH] drm/sun4i: virtual CMA addresses are not needed

A_VMAP_DRIVER_OPS for GEM operations"), > but only convenient macro at the time used helpers with virtual > mapping. > > [...] Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime

Re: [PATCH v6 6/6] drm/sprd: add Unisoc's drm mipi dsi&dphy driver

Hi, On Wed, Oct 20, 2021 at 06:09:32PM +0800, Kevin Tang wrote: > Maxime Ripard 于2021年9月28日周二 下午5:28写道： > > > > > +static int sprd_dsi_find_panel(struct sprd_dsi *dsi) > > > > > +{ > > > > > + struct device *dev = dsi->host.dev; &g

Re: [PATCH v2 3/7] drm/bridge: Add drm_atomic_get_new_crtc_for_bridge() helper

> operations of struct drm_bridge_funcs. > > v2: > - Renamed to drm_atomic_get_new_crtc_for_bridge (Maxime) > - Use atomic_state, not bridge_State (Maxime) > - Drop WARN on crtc_state as it is a valid case (Maxime) > - Added small code snip to help readers > - Up

[PATCH 0/9] drm/vc4: Introduce locking and remove !KMS state access

hat you think, Maxime Maxime Ripard (9): drm/vc4: crtc: Drop feed_txp from state drm/vc4: Fix non-blocking commit getting stuck forever drm/vc4: crtc: Copy assigned channel to the CRTC drm/vc4: hdmi: Add a spinlock to protect register access drm/vc4: hdmi: Use a mutex to prevent concurr

[PATCH 1/9] drm/vc4: crtc: Drop feed_txp from state

in struct vc4_crtc if we happen to be the TXP, and drop the flag from our private state structure. Link: https://lore.kernel.org/all/YWgteNaNeaS9uWDe@phenom.ffwll.local/ Fixes: 008095e065a8 ("drm/vc4: Add support for the transposer block") Signed-off-by: Maxime Ripard --- driver

[PATCH 4/9] drm/vc4: hdmi: Add a spinlock to protect register access

rotect the register access of the HDMI controller. Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.") Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_hdmi.c | 202 ++-- drivers/gpu/drm/vc4/vc4_hdmi.h | 5 + drivers/gpu/drm/vc4/v

[PATCH 5/9] drm/vc4: hdmi: Use a mutex to prevent concurrent framework access

looks like CEC should be able to recover from this if it was to happen. Fixes: bb7d78568814 ("drm/vc4: Add HDMI audio support") Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_hdmi.c | 118 +++-- drivers/gpu/drm/vc4/vc4_hdmi.h | 14 2 files chan

[PATCH 7/9] drm/vc4: hdmi: Check the device state in prepare()

startup() to a helper and call it from prepare(). Fixes: 91e99e113929 ("drm/vc4: hdmi: Register HDMI codec") Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_hdmi.c | 35 +++--- 1 file changed, 28 insertions(+), 7 deletions(-) diff --git a/d

[PATCH 2/9] drm/vc4: Fix non-blocking commit getting stuck forever

cal/ Fixes: 56d1fe0979dc ("drm/vc4: Make pageflip completion handling more robust.") Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_crtc.c | 5 - drivers/gpu/drm/vc4/vc4_drv.h | 14 ++ drivers/gpu/drm/vc4/vc4_hvs.c | 7 +-- 3 files changed, 23 insertion

[PATCH 3/9] drm/vc4: crtc: Copy assigned channel to the CRTC

ffwll.local/ Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically") Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_crtc.c | 4 ++-- drivers/gpu/drm/vc4/vc4_drv.h | 9 + drivers/gpu/drm/vc4/vc4_hvs.c | 12 drivers/gpu/drm/vc4/vc4_t

[PATCH 6/9] drm/vc4: hdmi: Prevent access to crtc->state outside of KMS

nce that part is shared between KMS and other paths, we need to protect it using our mutex. Link: https://lore.kernel.org/all/YWgteNaNeaS9uWDe@phenom.ffwll.local/ Fixes: bb7d78568814 ("drm/vc4: Add HDMI audio support") Signed-off-by: Maxime Ripard --- drivers/gpu/drm/v

[PATCH 8/9] drm/vc4: hdmi: Introduce an output_enabled flag

in place now, let's just create a flag that we toggle to report whether the controller is currently enabled and use that instead of encoder->crtc in ALSA. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_hdmi.c | 16 drivers/gpu/drm/vc4/vc4_hdmi.h | 6 ++ 2 f

[PATCH 9/9] drm/vc4: hdmi: Introduce a scdc_enabled flag

s one user of our copy of the CRTC adjusted mode outside of KMS (since vc4_hdmi_disable_scrambling() might be called from the hotplug interrupt handler). It also removes our last user of the legacy encoder->crtc pointer. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc

Re: Regression with mainline kernel on rpi4

Hi, On Thu, Oct 14, 2021 at 03:15:36PM +0200, Daniel Vetter wrote: > On Wed, Oct 13, 2021 at 05:01:03PM +0200, Maxime Ripard wrote: > > On Thu, Sep 30, 2021 at 11:19:59AM +0200, Daniel Vetter wrote: > > > On Tue, Sep 28, 2021 at 10:34:46AM +0200, Maxime Ripard wrote:

[PATCH v6 01/21] drm/bridge: adv7533: Switch to devm MIPI-DSI helpers

Let's switch to the new devm MIPI-DSI function to register and attach our secondary device. This also avoids leaking the device when we detach the bridge. Acked-by: Sam Ravnborg Tested-by: John Stultz Signed-off-by: Maxime Ripard --- drivers/gpu/drm/bridge/adv7511/adv7511.h

[PATCH v6 00/21] drm/bridge: Make panel and bridge probe order consistent

us, so in our case that would mean moving the DSI device registration to the bridge probe. This has been tested on vc4 (with sn65dsi83 and ps8640), msm (sn65dsi86, lt9611), kirin (adv7511) and exynos. Let me know what you think, Maxime --- Changes from v5: - Collected more tags - Fixed

[PATCH v6 02/21] drm/bridge: adv7511: Register and attach our DSI device at probe

In order to avoid any probe ordering issue, the best practice is to move the secondary MIPI-DSI device registration and attachment to the MIPI-DSI host at probe time. Let's do this. Acked-by: Sam Ravnborg Tested-by: John Stultz Signed-off-by: Maxime Ripard --- drivers/gpu/drm/bridge/ad

[PATCH v6 04/21] drm/bridge: anx7625: Register and attach our DSI device at probe

In order to avoid any probe ordering issue, the best practice is to move the secondary MIPI-DSI device registration and attachment to the MIPI-DSI host at probe time. Let's do this. Acked-by: Sam Ravnborg Signed-off-by: Maxime Ripard --- drivers/gpu/drm/bridge/analogix/anx7625.c

[PATCH v6 05/21] drm/bridge: lt8912b: Switch to devm MIPI-DSI helpers

Let's switch to the new devm MIPI-DSI function to register and attach our secondary device. Acked-by: Sam Ravnborg Signed-off-by: Maxime Ripard --- drivers/gpu/drm/bridge/lontium-lt8912b.c | 20 1 file changed, 4 insertions(+), 16 deletions(-) diff --git a/drivers/gp

[PATCH v6 03/21] drm/bridge: anx7625: Switch to devm MIPI-DSI helpers

Let's switch to the new devm MIPI-DSI function to register and attach our secondary device. Acked-by: Sam Ravnborg Signed-off-by: Maxime Ripard --- drivers/gpu/drm/bridge/analogix/anx7625.c | 20 +--- 1 file changed, 5 insertions(+), 15 deletions(-) diff --git a/driver

[PATCH v6 08/21] drm/bridge: lt9611: Register and attach our DSI device at probe

In order to avoid any probe ordering issue, the best practice is to move the secondary MIPI-DSI device registration and attachment to the MIPI-DSI host at probe time. Let's do this. Acked-by: Sam Ravnborg Tested-by: John Stultz Signed-off-by: Maxime Ripard --- drivers/gpu/drm/bridge/lo

[PATCH v6 07/21] drm/bridge: lt9611: Switch to devm MIPI-DSI helpers

Let's switch to the new devm MIPI-DSI function to register and attach our secondary device. Acked-by: Sam Ravnborg Tested-by: John Stultz Signed-off-by: Maxime Ripard --- drivers/gpu/drm/bridge/lontium-lt9611.c | 24 1 file changed, 4 insertions(+), 20 dele

[PATCH v6 10/21] drm/bridge: lt9611uxc: Register and attach our DSI device at probe

In order to avoid any probe ordering issue, the best practice is to move the secondary MIPI-DSI device registration and attachment to the MIPI-DSI host at probe time. Let's do this. Acked-by: Sam Ravnborg Signed-off-by: Maxime Ripard --- drivers/gpu/drm/bridge/lontium-lt9611uxc.c

[PATCH v6 09/21] drm/bridge: lt9611uxc: Switch to devm MIPI-DSI helpers

Let's switch to the new devm MIPI-DSI function to register and attach our secondary device. Acked-by: Sam Ravnborg Signed-off-by: Maxime Ripard --- drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 38 +- 1 file changed, 8 insertions(+), 30 deletions(-) diff --git a/driver

[PATCH v6 06/21] drm/bridge: lt8912b: Register and attach our DSI device at probe

In order to avoid any probe ordering issue, the best practice is to move the secondary MIPI-DSI device registration and attachment to the MIPI-DSI host at probe time. Let's do this. Acked-by: Sam Ravnborg Signed-off-by: Maxime Ripard --- drivers/gpu/drm/bridge/lontium-lt8912b.c

[PATCH v6 17/21] drm/bridge: sn65dsi86: Register and attach our DSI device at probe

In order to avoid any probe ordering issue, the best practice is to move the secondary MIPI-DSI device registration and attachment to the MIPI-DSI host at probe time. Let's do this. Acked-by: Sam Ravnborg Signed-off-by: Maxime Ripard --- drivers/gpu/drm/bridge/ti-sn65dsi86.c

[PATCH v6 15/21] drm/bridge: sn65dsi83: Register and attach our DSI device at probe

In order to avoid any probe ordering issue, the best practice is to move the secondary MIPI-DSI device registration and attachment to the MIPI-DSI host at probe time. Let's do this. Acked-by: Sam Ravnborg Tested-by: Laurent Pinchart Signed-off-by: Maxime Ripard --- drivers/gpu/drm/brid

[PATCH v6 14/21] drm/bridge: sn65dsi83: Switch to devm MIPI-DSI helpers

Let's switch to the new devm MIPI-DSI function to register and attach our secondary device. This also avoids leaking the device when we detach the bridge but don't remove its driver. Acked-by: Sam Ravnborg Tested-by: Laurent Pinchart Signed-off-by: Maxime Ripard --- drivers/gpu/drm

[PATCH v6 12/21] drm/bridge: ps8640: Register and attach our DSI device at probe

In order to avoid any probe ordering issue, the best practice is to move the secondary MIPI-DSI device registration and attachment to the MIPI-DSI host at probe time. Let's do this. Acked-by: Sam Ravnborg Signed-off-by: Maxime Ripard --- drivers/gpu/drm/bridge/parade-ps8640.c

[PATCH v6 16/21] drm/bridge: sn65dsi86: Switch to devm MIPI-DSI helpers

Let's switch to the new devm MIPI-DSI function to register and attach our secondary device. This also avoids leaking the device when we detach the bridge. Acked-by: Sam Ravnborg Signed-off-by: Maxime Ripard --- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 22 +++--- 1 file ch

[PATCH v6 13/21] drm/bridge: sn65dsi83: Fix bridge removal

ld thus be removed as part of its remove callback. Acked-by: Sam Ravnborg Reviewed-by: Marek Vasut Fixes: 24417d5b0c00 ("drm/bridge: ti-sn65dsi83: Implement .detach callback") Signed-off-by: Maxime Ripard --- drivers/gpu/drm/bridge/ti-sn65dsi83.c | 2 +- 1 file changed, 1 insertion(+),

[PATCH v6 11/21] drm/bridge: ps8640: Switch to devm MIPI-DSI helpers

Let's switch to the new devm MIPI-DSI function to register and attach our secondary device. This also avoids leaking the device on removal. Acked-by: Sam Ravnborg Signed-off-by: Maxime Ripard --- drivers/gpu/drm/bridge/parade-ps8640.c | 15 +-- 1 file changed, 5 insertions(+

[PATCH v6 18/21] drm/bridge: tc358775: Switch to devm MIPI-DSI helpers

Let's switch to the new devm MIPI-DSI function to register and attach our secondary device. This also avoids leaking the device when we detach the bridge. Acked-by: Sam Ravnborg Signed-off-by: Maxime Ripard --- drivers/gpu/drm/bridge/tc358775.c | 13 - 1 file changed, 4 inser

[PATCH v6 21/21] drm/msm/dsi: Adjust probe order

From: Rob Clark Switch to the documented order dsi-host vs bridge probe. Tested-by: Amit Pundir Tested-by: Caleb Connolly Tested-by: John Stultz Signed-off-by: Rob Clark Signed-off-by: Maxime Ripard --- drivers/gpu/drm/msm/dsi/dsi.c | 50 --- drivers/gpu

[PATCH v6 19/21] drm/bridge: tc358775: Register and attach our DSI device at probe

In order to avoid any probe ordering issue, the best practice is to move the secondary MIPI-DSI device registration and attachment to the MIPI-DSI host at probe time. Let's do this. Acked-by: Sam Ravnborg Signed-off-by: Maxime Ripard --- drivers/gpu/drm/bridge/tc358775.c

[PATCH v6 20/21] drm/kirin: dsi: Adjust probe order

following the same conventions, resulting in various incompatibilities between DSI hosts and devices. Now that we have a sequence agreed upon and documented, let's convert kirin to it. Tested-by: John Stultz Signed-off-by: Maxime Ripard --- drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c

Re: [PATCH v5 00/21] drm/bridge: Make panel and bridge probe order consistent

Hi Sam, On Thu, Oct 21, 2021 at 05:22:55PM +0200, Sam Ravnborg wrote: > Hi Maxime, > > > Let me know what you think, > > apply the lot to drm-misc-next. Maybe wait for an r-b or a-b on the kirin > patch but the rest is IMO good to go. I had a compilation error since the r

[PATCH v8 00/10] drm/vc4: hdmi: Support the 4k @ 60Hz modes

Hi, Here is a series that enables the higher resolutions on the HDMI0 Controller found in the BCM2711 (RPi4). In order to work it needs a few adjustments to config.txt, most notably to enable the enable_hdmi_4kp60 option. Let me know what you think, Maxime --- Changes from v7: - Rebased on

[PATCH v8 01/10] drm/vc4: hdmi: Remove the DDC probing for status detection

both, the display during the HPD pulse will clear its scrambler status, and since we won't detect the disconnect/reconnect cycle we will never enable the scrambler back. As our main reason for that DDC probing is gone, let's just remove it. Signed-off-by: Maxime Ripard --- drivers/gp

[PATCH v8 04/10] drm/vc4: crtc: Add encoder to vc4_crtc_config_pv prototype

vc4_crtc_config_pv() retrieves the encoder again, even though its only caller, vc4_crtc_atomic_enable(), already did. Pass the encoder pointer as an argument instead of going through all the connectors to retrieve it again. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_crtc.c | 7

[PATCH v8 02/10] drm/vc4: hdmi: Fix HPD GPIO detection

high, and would fall back to the other methods otherwise. Since we can read the EDIDs when the HPD signal is low on some displays, we changed the detection status from disconnected to connected, and we would ignore an HPD pulse. Fixes: 6800234ceee0 ("drm/vc4: hdmi: Convert to gpiod") S

[PATCH v8 03/10] drm/vc4: Make vc4_crtc_get_encoder public

We'll need that function in vc4_kms to compute the core clock rate requirements. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_crtc.c | 8 drivers/gpu/drm/vc4/vc4_drv.h | 5 + 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_c

[PATCH v8 07/10] drm/vc4: Leverage the load tracker on the BCM2711

against them, and prevent the debugfs file to enable it from being created. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_debugfs.c | 7 +-- drivers/gpu/drm/vc4/vc4_drv.h | 3 --- drivers/gpu/drm/vc4/vc4_kms.c | 16 +--- drivers/gpu/drm/vc4/vc4_plane.c | 5 -

[PATCH v8 05/10] drm/vc4: crtc: Rework the encoder retrieval code (again)

thus our encoder retrieval code will not match on anything. We can however simplify the code by using drm_for_each_encoder_mask, the drm_crtc_state storing the encoders a given CRTC is connected to directly and without relying on any other state. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4

[PATCH v8 06/10] drm/vc4: crtc: Add some logging

The encoder retrieval code has been a source of bugs and glitches in the past and the crtc <-> encoder association been wrong in a number of different ways. Add some logging to quickly spot issues if they occur. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_crtc.c | 6 ++

[PATCH v8 10/10] drm/vc4: Increase the core clock based on HVS load

Depending on a given HVS output (HVS to PixelValves) and input (planes attached to a channel) load, the HVS needs for the core clock to be raised above its boot time default. Failing to do so will result in a vblank timeout and a stalled display pipeline. Signed-off-by: Maxime Ripard

[PATCH v8 09/10] drm/vc4: hdmi: Enable the scrambler on reconnection

s the scrambler to be enabled. Fixes: c85695a2016e ("drm/vc4: hdmi: Enable the scrambler") Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_hdmi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c index d

[PATCH v8 08/10] drm/vc4: hdmi: Raise the maximum clock rate

Reviewed-by: Dave Stevenson Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c index dde67b991ae7..d36b3b6ebed1 100644 --- a/drivers/gpu/drm/vc4

Re: [PULL] topic/amdgpu-dp2.0-mst

Changes: > Make the DP MST helpers aware of the current starting VCPI slot/VCPI total > slot count... > > Driver Changes: > ...and then add support for taking advantage of this for 128b/132b links on DP > 2.0 for amdgpu It's not really clear to me what branch it should be p

Re: [PATCH v5 00/21] drm/bridge: Make panel and bridge probe order consistent

On Mon, Oct 25, 2021 at 06:54:34PM +0200, Sam Ravnborg wrote: > Hi Maxime, > > On Mon, Oct 25, 2021 at 05:16:36PM +0200, Maxime Ripard wrote: > > Hi Sam, > > > > On Thu, Oct 21, 2021 at 05:22:55PM +0200, Sam Ravnborg wrote: > > > Hi Maxime, >

Re: (subset) [PATCH v6 01/21] drm/bridge: adv7533: Switch to devm MIPI-DSI helpers

On Mon, 25 Oct 2021 17:15:16 +0200, Maxime Ripard wrote: > Let's switch to the new devm MIPI-DSI function to register and attach > our secondary device. This also avoids leaking the device when we detach > the bridge. > > Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime

Re: (subset) [PATCH v6 02/21] drm/bridge: adv7511: Register and attach our DSI device at probe

On Mon, 25 Oct 2021 17:15:17 +0200, Maxime Ripard wrote: > In order to avoid any probe ordering issue, the best practice is to move > the secondary MIPI-DSI device registration and attachment to the > MIPI-DSI host at probe time. Let's do this. > > Applied to drm/drm

Re: (subset) [PATCH v6 03/21] drm/bridge: anx7625: Switch to devm MIPI-DSI helpers

On Mon, 25 Oct 2021 17:15:18 +0200, Maxime Ripard wrote: > Let's switch to the new devm MIPI-DSI function to register and attach > our secondary device. > > Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime

Re: (subset) [PATCH v6 04/21] drm/bridge: anx7625: Register and attach our DSI device at probe

On Mon, 25 Oct 2021 17:15:19 +0200, Maxime Ripard wrote: > In order to avoid any probe ordering issue, the best practice is to move > the secondary MIPI-DSI device registration and attachment to the > MIPI-DSI host at probe time. Let's do this. > > Applied to drm/drm

Re: (subset) [PATCH v6 05/21] drm/bridge: lt8912b: Switch to devm MIPI-DSI helpers

On Mon, 25 Oct 2021 17:15:20 +0200, Maxime Ripard wrote: > Let's switch to the new devm MIPI-DSI function to register and attach > our secondary device. > > Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime

Re: (subset) [PATCH v6 06/21] drm/bridge: lt8912b: Register and attach our DSI device at probe

On Mon, 25 Oct 2021 17:15:21 +0200, Maxime Ripard wrote: > In order to avoid any probe ordering issue, the best practice is to move > the secondary MIPI-DSI device registration and attachment to the > MIPI-DSI host at probe time. Let's do this. > > Applied to drm/drm

Re: (subset) [PATCH v6 07/21] drm/bridge: lt9611: Switch to devm MIPI-DSI helpers

On Mon, 25 Oct 2021 17:15:22 +0200, Maxime Ripard wrote: > Let's switch to the new devm MIPI-DSI function to register and attach > our secondary device. > > Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime

Re: (subset) [PATCH v6 08/21] drm/bridge: lt9611: Register and attach our DSI device at probe

On Mon, 25 Oct 2021 17:15:23 +0200, Maxime Ripard wrote: > In order to avoid any probe ordering issue, the best practice is to move > the secondary MIPI-DSI device registration and attachment to the > MIPI-DSI host at probe time. Let's do this. > > Applied to drm/drm

Re: (subset) [PATCH v6 09/21] drm/bridge: lt9611uxc: Switch to devm MIPI-DSI helpers

On Mon, 25 Oct 2021 17:15:24 +0200, Maxime Ripard wrote: > Let's switch to the new devm MIPI-DSI function to register and attach > our secondary device. > > Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime

Re: (subset) [PATCH v6 10/21] drm/bridge: lt9611uxc: Register and attach our DSI device at probe

On Mon, 25 Oct 2021 17:15:25 +0200, Maxime Ripard wrote: > In order to avoid any probe ordering issue, the best practice is to move > the secondary MIPI-DSI device registration and attachment to the > MIPI-DSI host at probe time. Let's do this. > > Applied to drm/drm

Re: (subset) [PATCH v6 11/21] drm/bridge: ps8640: Switch to devm MIPI-DSI helpers

On Mon, 25 Oct 2021 17:15:26 +0200, Maxime Ripard wrote: > Let's switch to the new devm MIPI-DSI function to register and attach > our secondary device. This also avoids leaking the device on removal. > > Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime

Re: (subset) [PATCH v6 12/21] drm/bridge: ps8640: Register and attach our DSI device at probe

On Mon, 25 Oct 2021 17:15:27 +0200, Maxime Ripard wrote: > In order to avoid any probe ordering issue, the best practice is to move > the secondary MIPI-DSI device registration and attachment to the > MIPI-DSI host at probe time. Let's do this. > > Applied to drm/drm

Re: (subset) [PATCH v6 13/21] drm/bridge: sn65dsi83: Fix bridge removal

On Mon, 25 Oct 2021 17:15:28 +0200, Maxime Ripard wrote: > Commit 24417d5b0c00 ("drm/bridge: ti-sn65dsi83: Implement .detach > callback") moved the unregistration of the bridge DSI device and bridge > itself to the detach callback. > > While this is correct for

Re: (subset) [PATCH v6 14/21] drm/bridge: sn65dsi83: Switch to devm MIPI-DSI helpers

On Mon, 25 Oct 2021 17:15:29 +0200, Maxime Ripard wrote: > Let's switch to the new devm MIPI-DSI function to register and attach > our secondary device. This also avoids leaking the device when we detach > the bridge but don't remove its driver. > > Applied to dr

Re: (subset) [PATCH v6 15/21] drm/bridge: sn65dsi83: Register and attach our DSI device at probe

On Mon, 25 Oct 2021 17:15:30 +0200, Maxime Ripard wrote: > In order to avoid any probe ordering issue, the best practice is to move > the secondary MIPI-DSI device registration and attachment to the > MIPI-DSI host at probe time. Let's do this. > > Applied to drm/drm

Re: (subset) [PATCH v6 16/21] drm/bridge: sn65dsi86: Switch to devm MIPI-DSI helpers

On Mon, 25 Oct 2021 17:15:31 +0200, Maxime Ripard wrote: > Let's switch to the new devm MIPI-DSI function to register and attach > our secondary device. This also avoids leaking the device when we detach > the bridge. > > Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime

Re: (subset) [PATCH v6 17/21] drm/bridge: sn65dsi86: Register and attach our DSI device at probe

On Mon, 25 Oct 2021 17:15:32 +0200, Maxime Ripard wrote: > In order to avoid any probe ordering issue, the best practice is to move > the secondary MIPI-DSI device registration and attachment to the > MIPI-DSI host at probe time. Let's do this. > > Applied to drm/drm

Re: (subset) [PATCH v6 18/21] drm/bridge: tc358775: Switch to devm MIPI-DSI helpers

On Mon, 25 Oct 2021 17:15:33 +0200, Maxime Ripard wrote: > Let's switch to the new devm MIPI-DSI function to register and attach > our secondary device. This also avoids leaking the device when we detach > the bridge. > > Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime

Re: (subset) [PATCH v6 19/21] drm/bridge: tc358775: Register and attach our DSI device at probe

On Mon, 25 Oct 2021 17:15:34 +0200, Maxime Ripard wrote: > In order to avoid any probe ordering issue, the best practice is to move > the secondary MIPI-DSI device registration and attachment to the > MIPI-DSI host at probe time. Let's do this. > > Applied to drm/drm

Re: (subset) [PATCH v6 20/21] drm/kirin: dsi: Adjust probe order

On Mon, 25 Oct 2021 17:15:35 +0200, Maxime Ripard wrote: > Without proper care and an agreement between how DSI hosts and devices > drivers register their MIPI-DSI entities and potential components, we can > end up in a situation where the drivers can never probe. > > Most driv

Re: (subset) [PATCH v6 21/21] drm/msm/dsi: Adjust probe order

On Mon, 25 Oct 2021 17:15:36 +0200, Maxime Ripard wrote: > From: Rob Clark > > Switch to the documented order dsi-host vs bridge probe. > > Applied to drm/drm-misc (drm-misc-next). Thanks! Maxime

Re: [PATCH v3 00/13] drm/i915/dp: dp 2.0 enabling prep work

t; drm/dp: add DP 2.0 UHBR link rate and bw code conversions > > drm/dp: use more of the extended receiver cap > > drm/dp: add LTTPR DP 2.0 DPCD addresses > > drm/dp: add helper for extracting adjust 128b/132b TX FFE preset > > Maarten, Maxime, Thomas, can I get an a

[PATCH] drm/bridge: Move devm_drm_of_get_bridge to bridge/panel.c

drm_kms_helper. Fixes: 87ea95808d53 ("drm/bridge: Add a function to abstract away panels") Reported-by: Stephen Rothwell Signed-off-by: Maxime Ripard --- Hi Stephen, I think it fixes the issue, but couldn't reproduce it here with my config for some reason. Let me know if i

Re: [git pull] drm for 5.14-rc1

nd without hdmi_force_hotplug in your config.txt? If so, can you test that branch, and let me know if it works for you https://github.com/mripard/linux/tree/rpi/bug-fixes Maxime signature.asc Description: PGP signature

Re: [git pull] drm for 5.14-rc1

hor, on a week-end, the revert is done in a single day. Even that audio bug only got a proper report yesterday, after you asked for it. Do you really expect us to work during the week end too? Maxime signature.asc Description: PGP signature

Re: [git pull] drm for 5.14-rc1

On Mon, Sep 20, 2021 at 10:55:31AM +0200, Maxime Ripard wrote: > Hi, > > On Sat, Sep 18, 2021 at 11:18:33AM +0200, Michael Stapelberg wrote: > > torvalds at linux-foundation.org (Linus Torvalds) writes: > > > Did I fix it up correctly? Who knows. The code makes more s

Re: Regression with mainline kernel on rpi4

On Sat, Sep 04, 2021 at 10:40:29AM +0100, Sudip Mukherjee wrote: > Hi Maxime, > > On Sat, Sep 4, 2021 at 10:10 AM Maxime Ripard wrote: > > > > On Fri, Sep 03, 2021 at 09:09:50PM +0100, Sudip Mukherjee wrote: > > > Hi Maxime, > > > > > > On

Re: Regression with mainline kernel on rpi4

On Mon, Sep 20, 2021 at 04:47:31PM +0200, Maxime Ripard wrote: > On Sat, Sep 04, 2021 at 10:40:29AM +0100, Sudip Mukherjee wrote: > > Hi Maxime, > > > > On Sat, Sep 4, 2021 at 10:10 AM Maxime Ripard wrote: > > > > > > On Fri, Sep 03, 2021 at 09:09:50PM +

Re: Regression with mainline kernel on rpi4

On Mon, Sep 20, 2021 at 05:43:33PM +0200, Maxime Ripard wrote: > On Mon, Sep 20, 2021 at 04:47:31PM +0200, Maxime Ripard wrote: > > On Sat, Sep 04, 2021 at 10:40:29AM +0100, Sudip Mukherjee wrote: > > > Hi Maxime, > > > > > > On Sat, Sep 4, 2

Re: Regression with mainline kernel on rpi4

On Mon, Sep 20, 2021 at 05:35:00PM +0100, Sudip Mukherjee wrote: > On Mon, Sep 20, 2021 at 4:53 PM Maxime Ripard wrote: > > > > On Mon, Sep 20, 2021 at 05:43:33PM +0200, Maxime Ripard wrote: > > > On Mon, Sep 20, 2021 at 04:47:31PM +0200, Maxime Ripard wrote: > > >

Re: [git pull] drm for 5.14-rc1

On Mon, Sep 20, 2021 at 10:10:57AM -0700, Linus Torvalds wrote: > On Mon, Sep 20, 2021 at 5:17 AM Maxime Ripard wrote: > > > > I'm sorry, but I find that situation to be a bit ridiculous. > > Honestly, the original report about the pulseaudio problem came in > ov

Re: [PULL] drm-misc-next

Hi, On Mon, Sep 20, 2021 at 05:29:41PM -0500, Rob Herring wrote: > On Thu, Sep 16, 2021 at 2:31 AM Maxime Ripard wrote: > > > > Hi Dave, Daniel, > > > > Here's the first drm-misc-next PR for 5.16 > > > > Thanks! > > Maxime > > > > d

Re: [PATCH] drm/bridge: Move devm_drm_of_get_bridge to bridge/panel.c

On Mon, Sep 20, 2021 at 10:49:55PM +0200, Heiko Stübner wrote: > Hi Maxime, > > Am Freitag, 17. September 2021, 20:09:25 CEST schrieb Maxime Ripard: > > By depending on devm_drm_panel_bridge_add(), devm_drm_of_get_bridge() > > introduces a circular dependency between t

Re: [PATCH 1/3] drm/bridge: Add a function to abstract away panels

Hi Patrik, On Tue, Sep 21, 2021 at 02:47:49PM +0200, Patrik Jakobsson wrote: > On Fri, Sep 10, 2021 at 3:10 PM Maxime Ripard wrote: > > > > Display drivers so far need to have a lot of boilerplate to first > > retrieve either the panel or bridge that they a

Re: [PATCH v3 1/6] drm/vc4: select PM (openrisc)

Hi Randy, On Sun, Sep 19, 2021 at 09:40:44AM -0700, Randy Dunlap wrote: > On 8/19/21 6:59 AM, Maxime Ripard wrote: > > We already depend on runtime PM to get the power domains and clocks for > > most of the devices supported by the vc4 driver, so let's just select it > &g

Re: [PATCH v4 24/24] drm/exynos: dsi: Adjust probe order

Hi Marek, On Fri, Sep 17, 2021 at 02:35:05PM +0200, Marek Szyprowski wrote: > Hi, > > On 13.09.2021 12:30, Andrzej Hajda wrote: > > W dniu 10.09.2021 o 12:12, Maxime Ripard pisze: > >> Without proper care and an agreement between how DSI hosts and devices > >>

Re: [PATCH v4 02/24] drm/bridge: Document the probe issue with MIPI-DSI bridges

Hi, On Tue, Sep 14, 2021 at 09:00:28PM +0200, Andrzej Hajda wrote: > > W dniu 14.09.2021 o 16:35, Maxime Ripard pisze: > > Hi, > > > > On Mon, Sep 13, 2021 at 08:29:37AM +0200, Andrzej Hajda wrote: > >> W dniu 10.09.2021 o 12:11, Maxime Ripard pisze: > >

Re: Regression with mainline kernel on rpi4

On Mon, Sep 20, 2021 at 06:21:42PM +0100, Sudip Mukherjee wrote: > On Mon, Sep 20, 2021 at 6:10 PM Maxime Ripard wrote: > > > > On Mon, Sep 20, 2021 at 05:35:00PM +0100, Sudip Mukherjee wrote: > > > On Mon, Sep 20, 2021 at 4:53 PM Maxime Ripard wrote: > > > >

Re: Regression with mainline kernel on rpi4

On Wed, Sep 22, 2021 at 11:10:34AM +0100, Sudip Mukherjee wrote: > On Wed, Sep 22, 2021 at 10:57 AM Maxime Ripard wrote: > > > > On Mon, Sep 20, 2021 at 06:21:42PM +0100, Sudip Mukherjee wrote: > > > On Mon, Sep 20, 2021 at 6:10 PM Maxime Ripard wrote: > > > >

Re: [git pull] drm for 5.14-rc1

On Mon, Sep 20, 2021 at 10:47:43AM -0700, Linus Torvalds wrote: > On Mon, Sep 20, 2021 at 10:33 AM Maxime Ripard wrote: > > > > What I was interested in was more about the context itself, and I'd > > still like an answer on whether it's ok to wait for a review for

[PULL] drm-misc-next

Hi Dave, Daniel, Here's this week PR for drm-misc-next Maxime drm-misc-next-2021-09-23: drm-misc-next for 5.15: UAPI Changes: Cross-subsystem Changes: Core Changes: Driver Changes: - Conversions to dev_err_probe() helper - rockchip: Various build improvements

Re: [PATCH v2 3/3] drm/bridge: ti-sn65dsi86: Add NO_CONNECTOR support

; rebase either patch on top of the other depending on which order they > are applied It's probably going to take a bit of time to get merged, so don't worry about this series and just go ahead, I'll rebase it on top of yours if needed. Maxime signature.asc Description: PGP signature

Re: [PATCH v3 1/6] drm/vc4: select PM (openrisc)

Hi Nathan, On Wed, Sep 22, 2021 at 08:49:50AM -0700, Nathan Chancellor wrote: > On Wed, Sep 22, 2021 at 10:41:56AM +0200, Maxime Ripard wrote: > > Hi Randy, > > > > On Sun, Sep 19, 2021 at 09:40:44AM -0700, Randy Dunlap wrote: > > > On 8/19/21 6:59 AM, Maxime Ri

Re: [PATCH v3 1/6] drm/vc4: select PM (openrisc)

On Thu, Sep 23, 2021 at 07:55:32AM -0700, Nathan Chancellor wrote: > On Thu, Sep 23, 2021 at 04:52:08PM +0200, Maxime Ripard wrote: > > Hi Nathan, > > > > On Wed, Sep 22, 2021 at 08:49:50AM -0700, Nathan Chancellor wrote: > > > On Wed, Sep 22, 2021 at 10:41:5

[PATCH] drm/vc4: crtc: Make sure the HDMI controller is powered when disabling

er properly powered while disabling it. Fixes: 875a4d536842 ("drm/vc4: drv: Disable the CRTC at boot time") Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_crtc.c | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vc4/vc4_crtc

Re: Regression with mainline kernel on rpi4

framebuffer emulation and the framebuffer console enabled, so it's likely to be enabled and something (X.org?) comes along and disables the connector right when pulseaudio calls prepare(). Maxime signature.asc Description: PGP signature

[PATCH 0/2] drm/vc4: hdmi: Get rid of encoder->crtc, take 2

ged between the time the device was opened and the time when we actually start streaming. Then, the encoder->crtc conversion patch has been changed to check on connector->state->crtc as well in that sanity check to avoid dereferencing it if it's NULL. Let me know what you think, Maxi

[PATCH 2/2] drm/vc4: hdmi: Remove drm_encoder->crtc usage

The drm_encoder crtc pointer isn't really fit for an atomic driver, let's rely on the connector state instead. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_hdmi.c | 50 -- 1 file changed, 36 insertions(+), 14 deletions(-) diff --git a/drive

[PATCH 1/2] drm/vc4: hdmi: Check the device state in prepare()

startup() to a helper and call it from prepare(). Fixes: 91e99e113929 ("drm/vc4: hdmi: Register HDMI codec") Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_hdmi.c | 31 --- 1 file changed, 24 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/dr

<    5   6   7   8   9   10   11   12   13   14   >