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
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
Hi Lyude,
On Mon, Oct 25, 2021 at 09:30:14PM -0400, Lyude Paul wrote:
> topic/amdgpu-dp2.0-mst-2021-10-25:
> UAPI Changes:
> Nope!
>
> Cross-subsystem Changes:
> drm_dp_update_payload_part1() takes a new argument for specifying what the
> VCPI slot start is
>
> Core Changes:
> Make the DP MST he
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,
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
On Fri, Sep 17, 2021 at 03:54:23PM +0300, Jani Nikula wrote:
> On Thu, 09 Sep 2021, Jani Nikula wrote:
> > v3 of https://patchwork.freedesktop.org/series/93800/ with minor tweaks
> > and the already merged patches obviously dropped.
> >
> > Jani Nikula (13):
> > drm/dp: add DP 2.0 UHBR link rate
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
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 sense to me
> > now and seems valid. But I really *really* want to stress how locking
> > is important.
On Sun, Sep 19, 2021 at 10:19:35AM -0700, Linus Torvalds wrote:
> On Sun, Sep 19, 2021 at 4:05 AM Sudip Mukherjee
> wrote:
> >
> > And indeed, reverting 27da370e0fb3 ("drm/vc4: hdmi: Remove
> > drm_encoder->crtc usage") on top of d4d016caa4b8 ("alpha: move
> > __udiv_qrnnd library function to arch
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
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
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 +
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
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:
> > >
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
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
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
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
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
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
> >>
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:
> >
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:
> > > >
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:
> > > >
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
s Bulwahn (1):
MAINTAINERS: fix typo in DRM DRIVER FOR SAMSUNG S6D27A1 PANELS
Maxime Ripard (1):
drm/bridge: Move devm_drm_of_get_bridge to bridge/panel.c
Melissa Wen (1):
drm/v3d: fix sched job resources cleanup when a job is aborted
Souptick Joarder (2):
drm/rockchip: remov
Hi,
On Tue, Sep 21, 2021 at 03:42:05PM -0700, Rob Clark wrote:
> On Tue, Sep 21, 2021 at 3:20 PM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Mon, Sep 20, 2021 at 3:53 PM Rob Clark wrote:
> > >
> > > From: Rob Clark
> > >
> > > Slightly awkward to fish out the display_info when we aren't creatin
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
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
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
On Wed, Sep 22, 2021 at 01:25:21PM -0700, Linus Torvalds wrote:
> On Wed, Sep 22, 2021 at 1:19 PM Sudip Mukherjee
> wrote:
> >
> > I added some debugs to print the addresses, and I am getting:
> > [ 38.813809] sudip crtc
> >
> > This is from struct drm_crtc *crtc = connector->st
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
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
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
On Fri, 10 Sep 2021 12:11:56 +0200, Maxime Ripard wrote:
> Interactions between bridges, panels, MIPI-DSI host and the component
> framework are not trivial and can lead to probing issues when
> implementing a display driver. Let's document the various cases we need
> too
On Fri, 10 Sep 2021 12:11:55 +0200, Maxime Ripard wrote:
> The bridge documentation overview is quite packed already, and we'll add
> some more documentation that isn't part of an overview at all.
>
> Let's add some sections to the documentation to separate each bits
On Fri, 10 Sep 2021 12:11:58 +0200, Maxime Ripard wrote:
> MIPI-DSI devices need to call mipi_dsi_attach() when their probe is done
> to attach against their host.
>
> However, at removal or when an error occurs, that attachment needs to be
> undone through a call to mipi_dsi_detac
On Fri, 10 Sep 2021 12:11:57 +0200, Maxime Ripard wrote:
> Devices that take their data through the MIPI-DSI bus but are controlled
> through a secondary bus like I2C have to register a secondary device on
> the MIPI-DSI bus through the mipi_dsi_device_register_full() function.
>
>
There's some interactions between the SCDC setup and the disconnection /
reconnection of displays. Let's document it and a solution.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_scdc_helper.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drive
Hi,
On Mon, Sep 27, 2021 at 06:44:23PM +0200, H. Nikolaus Schaller wrote:
> It appears that dw-hdmi plugin detection is not properly
> propagated unless we call drm_kms_helper_hotplug_event().
>
> Maybe drm_bridge_hpd_notify should have been setup to
> call this.
>
> Signed-off-by: H. Nikolaus S
On Mon, Sep 27, 2021 at 06:44:24PM +0200, H. Nikolaus Schaller wrote:
> From: Paul Boddie
>
> A specialisation of the generic Synopsys HDMI driver is employed for JZ4780
> HDMI support. This requires a new driver, plus device tree and configuration
> modifications.
>
> Signed-off-by: Paul Boddie
On Thu, Sep 23, 2021 at 03:29:37AM +0300, Laurent Pinchart wrote:
> Hi Maxime,
>
> Thank you for the patch.
>
> I know this has already been merged, but I have a question.
>
> On Fri, Sep 10, 2021 at 03:09:39PM +0200, Maxime Ripard wrote:
> > Display drivers s
Hi Daniel,
On Sat, Sep 25, 2021 at 12:50:17AM +0200, Daniel Vetter wrote:
> On Fri, Sep 24, 2021 at 3:30 PM Maxime Ripard wrote:
> >
> > On Wed, Sep 22, 2021 at 01:25:21PM -0700, Linus Torvalds wrote:
> > > On Wed, Sep 22, 2021 at 1:19 PM Sudip Mukherjee
> > >
On Tue, Sep 28, 2021 at 10:59:45AM +0200, H. Nikolaus Schaller wrote:
> >> +properties:
> >> + compatible:
> >> +items:
> >> + - const: ingenic,jz4780-dw-hdmi
> >
> > This can just be a const, there's no need for the items
>
> Maybe starting with an enum is better if more compatible str
On Sun, Sep 26, 2021 at 10:31:53PM +0800, Kevin Tang wrote:
> Maxime Ripard 于2021年9月17日周五 下午11:40写道：
> > > +static void sprd_dsi_encoder_mode_set(struct drm_encoder *encoder,
> > > + struct drm_display_mode *mode,
> > > +
On Tue, 14 Sep 2021 12:17:22 +0200, Maxime Ripard wrote:
> The documentation of the drm_helper_hpd_irq_event() function didn't
> document the value that function was returning. Add that part as well.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Tue, 14 Sep 2021 12:17:23 +0200, Maxime Ripard wrote:
> The drm_helper_hpd_irq_event() function is iterating over all the
> connectors when an hotplug event is detected.
>
> During that iteration, it will call each connector detect function and
> figure out if its status change
On Tue, 14 Sep 2021 12:17:24 +0200, Maxime Ripard wrote:
> The drm_helper_hpd_irq_event() documentation states that this function
> is "useful for drivers which can't or don't track hotplug interrupts for
> each connector." and that "Drivers which support hotpl
If CONFIG_OF is disabled, devm_drm_of_get_bridge won't be compiled in
and drivers using that function will fail to build.
Add an inline stub so that we can still build-test those cases.
Reported-by: Randy Dunlap
Signed-off-by: Maxime Ripard
---
include/drm/drm_bridge.h | 13 +++
bindings
- Refactored a bit the panel registration in the tcon code.
Maxime Ripard (7):
of: Make of_graph_get_port_by_id take a const device_node
drm/of: Change the prototype of drm_of_lvds_get_dual_link_pixel_order
dt-bindings: display: sun4i: Add LVDS Dual-Link property
drm/sun4i: tcon
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/prope
operate at the endpoint level. Change slightly the arguments to allow that.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_of.c| 138 +---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 8 +-
include/drm/drm_of.h| 16 +++-
3 files changed, 121
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
sters the proper panel output.
Reviewed-by: Chen-Yu Tsai
Reviewed-by: Laurent Pinchart
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 127 +
1 file changed, 58 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon
bits to setup the TCON properly.
Reviewed-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 36 ++
drivers/gpu/drm/sun4i/sun4i_tcon.h | 4
2 files changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b
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 a/drivers/gp
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
b/arc
rm/ttm: add TTM_TT_FLAG_EXTERNAL_MAPPABLE
Maxime Ripard (7):
drm/bridge: Add documentation sections
drm/bridge: Document the probe issue with MIPI-DSI bridges
drm/mipi-dsi: Create devm device registration
drm/mipi-dsi: Create devm device attachment
drm/probe-helpe
On Tue, 28 Sep 2021 20:13:33 +0200, Maxime Ripard wrote:
> If CONFIG_OF is disabled, devm_drm_of_get_bridge won't be compiled in
> and drivers using that function will fail to build.
>
> Add an inline stub so that we can still build-test those cases.
>
>
Applied to drm/
Hi Dave, Daniel,
Here's a few patches stuck in drm-misc-fixes for some time.
Maxime
drm-misc-fixes-2022-01-14:
Two DT bindings fixes for meson, a device refcounting fix for sun4i, a
probe fix for vga16fb, a locking fix for the CMA dma-buf heap and a
compilation fix for ttm.
The following changes
On Wed, 12 Jan 2022 23:20:36 +, Colin Ian King wrote:
> The variable 'size' is being assigned a value that is never read,
> the assignment is redundant and can be removed. Cleans up clang-scan
> warning:
>
> drivers/gpu/drm/vc4/vc4_bo.c:358:2: warning: Value stored to 'size'
> is never read [d
On Thu, Jan 13, 2022 at 01:44:25PM -0800, Stephen Boyd wrote:
> Quoting Maxime Ripard (2022-01-12 03:46:52)
> > On Tue, Jan 11, 2022 at 07:37:15PM -0800, Stephen Boyd wrote:
> > > Sorry for being super delayed on response here. I'm buried in other
> > > wor
On Tue, 18 Jan 2022 01:51:26 +0100, Padmanabha Srinivasaiah wrote:
> DSI device attach to DSI host will be done with host device's lock
> held.
>
> Un-registering host in "device attach" error path (ex: probe retry)
> will result in deadlock with below call trace and non operational
> DSI display.
tests
Changes from v1:
- Return NULL in clk_request_start if clk pointer is NULL
- Test for clk_req pointer in clk_request_done
- Add another user in vc4
- Rebased on top of v5.15-rc1
Maxime Ripard (10):
clk: Add Kunit tests for rate
clk: Always clamp the rounded rate
clk: Use clamp inste
Let's test various parts of the rate-related clock API with the kunit
testing framework.
Cc: kunit-...@googlegroups.com
Suggested-by: Stephen Boyd
Signed-off-by: Maxime Ripard
---
drivers/clk/Kconfig | 7 +
drivers/clk/Makefile| 1 +
drivers/clk/clk-rate-test.c
make sure we don't have any regression there.
Signed-off-by: Maxime Ripard
---
drivers/clk/clk-rate-test.c | 46 +
drivers/clk/clk.c | 2 ++
2 files changed, 48 insertions(+)
diff --git a/drivers/clk/clk-rate-test.c b/drivers/clk/clk-rate-te
d a few new test cases to make sure that behaviour is not broken
in the future.
Suggested-by: Stephen Boyd
Signed-off-by: Maxime Ripard
---
drivers/clk/clk-rate-test.c | 281 +++-
drivers/clk/clk.c | 45 +++---
2 files changed, 303 insertions(+), 23 d
The code in clk_set_rate_range() will, if the current rate is outside of
the new range, will force it to the minimum or maximum. This is
equivalent to using clamp, while being less readable. Let's switch to
using clamp instead.
Signed-off-by: Maxime Ripard
---
drivers/clk/clk.c | 6 +---
In order to reset the range on a clock, we need to call
clk_set_rate_range with a minimum of 0 and a maximum of ULONG_MAX. Since
it's fairly inconvenient, let's introduce a clk_drop_range() function
that will do just this.
Suggested-by: Stephen Boyd
Signed-off-by: Maxime Ripard
---
d
x27;s switch to a
variant structure that defines the behaviour we need to have for a given
clock.
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 62 +++
1 file changed, 46 insertions(+), 16 deletions(-)
diff --git a/drivers/clk/bcm/clk-raspberry
controller to deal with this before, but it
makes more sense to have it in the clock driver. Move it there.
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/clk/bcm/clk-raspberrypi.c
b
The HVS core clock isn't really obvious, so let's add a bunch more
comments and some logging for easier debugging.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/g
t the clk_request minimum (which is the aggregated
minimum of all the clock users) is what we want at all times.
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 37 +++
1 file changed, 37 insertions(+)
diff --git a/drivers/clk/bcm/clk-raspberrypi
Now that the clock driver makes sure we never end up with a rate of 0,
the HDMI driver doesn't need to care anymore.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gp
true
- Fixed max_tmds_clock handling
Changes from v1:
- Fixed an EDID parsing error for YUV422
- Fixed the scrambling setup when using a bpc > 8
- Added some logging
- Fixed some build-bot warnings
- Fixed a number of HDMI specifications and EDID issues
- Try to max out the bpc every time
or YUV output is being
used.
Let's remove the inconsistency and allow for the colorspace usage by
renaming the function.
Reviewed-by: Ville Syrjälä
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_edid.c | 8
drivers/gpu/drm/i915/display/intel_hdmi.c
ea_ext(), let's just remove the code modifying the formats in
drm_parse_hdmi_deep_color_info()
Fixes: d0c94692e0a3 ("drm/edid: Parse and handle HDMI deep color modes.")
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_edid.c | 8
1 file changed, 8 deletions(-)
diff --gi
his, let's split the edid_hdmi_dc_modes field in struct
drm_display_info into two fields, one for RGB444 and one for YUV444.
Suggested-by: Ville Syrjälä
Fixes: d0c94692e0a3 ("drm/edid: Parse and handle HDMI deep color modes.")
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/amd/a
The HDMI specification mentions YCbCr everywhere, but our enums have
YCrCb. Let's rename it to match.
Signed-off-by: Maxime Ripard
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
.../drm/arm/display/komeda/d71/d71_component.c | 12 ++--
drivers/gpu/drm/bridge/ad
We're going to need to tell whether we want to run with a full or
limited range RGB output in multiple places in the code, so let's create
a helper that will return whether we need with full range or not.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/g
er to tell whether the full or limited
range RGB should be used.
Acked-by: Thomas Zimmermann
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 31 +++
drivers/gpu/drm/vc4/vc4_hdmi.h | 4 ++--
2 files changed, 13 insertions(+), 22 deletions(-)
di
901 - 1000 of 8931 matches
Mail list logo
