ll
drivers, and most importantly we'll break that assumption in a later
patch.
It can also be argued that we shouldn't even reach the point where we're
calling clk_core_set_rate_nolock().
Let's make an explicit check for disjoints range before we're doing
anything.
Signed
ork will always clamp the rate to the current
range found on the clock, which will fix both these inconsistencies.
Signed-off-by: Maxime Ripard
---
drivers/clk/clk.c | 2 ++
drivers/clk/clk_test.c | 50 +++---
2 files changed, 34 insertions(+), 18 deletions(-
-by: Stephen Boyd
Signed-off-by: Maxime Ripard
---
drivers/clk/clk.c | 45
drivers/clk/clk_test.c | 58 +++---
2 files changed, 49 insertions(+), 54 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index c
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
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
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
pi to get clk consumer from clk_hw")
Signed-off-by: Maxime Ripard
---
drivers/clk/clk.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 8de6a22498e7..fff5edb89d6d 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -3773
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
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
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
Hi Melissa,
On Tue, Feb 01, 2022 at 08:26:51PM -0100, Melissa Wen wrote:
> Trace submit_cl_ioctl and related IRQs for CL submission and bin/render
> jobs execution. It might be helpful to get a rendering timeline and
> track job throttling.
>
> Signed-off-by: Melissa Wen
I'm not really sure wha
On Mon, 21 Feb 2022 10:59:09 +0100, Maxime Ripard wrote:
> The nouveau KMS driver will call drm_plane_create_zpos_property() with
> an init value depending on the plane purpose.
>
> Since the initial value wasn't carried over in the state, the driver had
> to set it agai
On Mon, 21 Feb 2022 10:59:00 +0100, Maxime Ripard wrote:
> While the omap_plane_init() function calls
> drm_plane_create_zpos_property() with an initial value of 0,
> omap_plane_reset() will force it to another value depending on the plane
> type.
>
> Fix the discrepancy by s
On Mon, 21 Feb 2022 10:59:03 +0100, Maxime Ripard wrote:
> From: Dave Stevenson
>
> The drm_plane_create_zpos_property() function asks for an initial value,
> and will set the associated plane state variable with that value if a
> state is present.
>
> However, that funct
On Mon, 21 Feb 2022 10:59:11 +0100, Maxime Ripard wrote:
> The rcar-du KMS driver will call drm_plane_create_zpos_property() with an
> init value depending on the plane type.
>
> Since the initial value wasn't carried over in the state, the driver had
> to set it again in
On Mon, 21 Feb 2022 10:59:10 +0100, Maxime Ripard wrote:
> The omap KMS driver will call drm_plane_create_zpos_property() with an
> init value of the plane index and the plane type.
>
> Since the initial value wasn't carried over in the state, the driver had
> to set it again
On Mon, 21 Feb 2022 10:59:08 +0100, Maxime Ripard wrote:
> The mdp KMS driver will call drm_plane_create_zpos_property() with an
> init value depending on the plane purpose.
>
> Since the initial value wasn't carried over in the state, the driver had
> to set it again
On Mon, 21 Feb 2022 10:59:12 +0100, Maxime Ripard wrote:
> The sti KMS driver will call drm_plane_create_zpos_property() with an
> init value depending on the plane type.
>
> Since the initial value wasn't carried over in the state, the driver had
> to set it again in sti_plan
On Mon, 21 Feb 2022 10:59:13 +0100, Maxime Ripard wrote:
> The sun4i KMS driver will call drm_plane_create_zpos_property() with an
> init value depending on the plane type.
>
> Since the initial value wasn't carried over in the state, the driver had
> to set it again in sun4i
On Mon, 21 Feb 2022 10:59:02 +0100, Maxime Ripard wrote:
> From: Dave Stevenson
>
> Some functions to create properties (drm_plane_create_zpos_property or
> drm_plane_create_color_properties for example) will ask for a range of
> acceptable value and an initial one.
>
>
On Mon, 21 Feb 2022 10:59:14 +0100, Maxime Ripard wrote:
> From: Dave Stevenson
>
> The drm_plane_create_color_properties() function asks for an initial
> value for the color encoding and range, and will set the associated
> plane state variable with that value if a s
On Mon, 21 Feb 2022 10:59:18 +0100, Maxime Ripard wrote:
> The omap KMS driver will call drm_plane_create_color_properties() with
> a default encoding and range values of BT601 and Full Range,
> respectively.
>
> Since the initial value wasn't carried over in the state, the dr
On Sun, 27 Feb 2022 13:47:09 +0100, Noralf Trønnes wrote:
> Add binding for MIPI DBI compatible SPI panels.
>
> v6:
> - Fix indentation (Rob)
>
> v5:
> - Add sainsmart18 to compatible items (Rob)
> - Expand write-only description (Sam)
>
> [...]
Applied to drm/drm-misc (drm-misc-next).
Thanks!
On Sun, 27 Feb 2022 13:47:11 +0100, Noralf Trønnes wrote:
> Add a function to get a drm_display_mode from a panel-timing
> device tree subnode.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Sun, 27 Feb 2022 13:47:10 +0100, Noralf Trønnes wrote:
> Remove trailing whitespace from a comment.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Sun, 27 Feb 2022 13:47:12 +0100, Noralf Trønnes wrote:
> devm_drm_dev_alloc() can't allocate structures that embed a structure
> which then again embeds drm_device. Workaround this by adding a
> driver_private pointer to struct mipi_dbi_dev which the driver can use for
> its additional state.
>
On Sun, 27 Feb 2022 13:47:13 +0100, Noralf Trønnes wrote:
> Add a driver that will work with most MIPI DBI compatible SPI panels.
> This avoids adding a driver for every new MIPI DBI compatible controller
> that is to be used by Linux. The 'compatible' Device Tree property with
> a '.bin' suffix wi
Hi,
On Sun, Feb 27, 2022 at 01:47:08PM +0100, Noralf Trønnes wrote:
> Hi,
>
> This patchset adds a driver that will work with most MIPI DBI compatible
> SPI panels out there.
>
> One change this time: Fix indentation in the DT binding.
>
> All patches are reviewed now so I will apply this after
On Fri, Feb 25, 2022 at 01:29:03PM -0800, Daniel Latypov wrote:
> On Fri, Feb 25, 2022 at 5:23 AM Maxime Ripard wrote:
> >
> > Hi Daniel,
> >
> > On Wed, Feb 23, 2022 at 02:50:59PM -0800, Daniel Latypov wrote:
> > > On Wed, Feb 23, 2022 at 2:56 AM Maxime Ripar
On Fri, Feb 25, 2022 at 02:44:04PM -0800, Stephen Boyd wrote:
> Quoting Maxime Ripard (2022-02-25 06:26:06)
> > Hi Stephen,
> >
> > On Thu, Feb 24, 2022 at 02:54:20PM -0800, Stephen Boyd wrote:
> > > Quoting Daniel Latypov (2022-02-23 14:50:59)
> > > &
i/ICN6211-Configurator
>
> Fixes: ce517f18944e3 ("drm: bridge: Add Chipone ICN6211 MIPI-DSI to RGB
> bridge")
> Signed-off-by: Marek Vasut
> Cc: Jagan Teki
> Cc: Maxime Ripard
> Cc: Robert Foss
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
> To: dri-devel@lists
8944e3 ("drm: bridge: Add Chipone ICN6211 MIPI-DSI to RGB
> bridge")
> Signed-off-by: Marek Vasut
> Cc: Jagan Teki
> Cc: Maxime Ripard
> Cc: Robert Foss
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
> To: dri-devel@lists.freedesktop.org
Acked-by: Maxime Ripard
Maxime
signature.asc
Description: PGP signature
by: Marek Vasut
> Cc: Jagan Teki
> Cc: Maxime Ripard
> Cc: Robert Foss
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
> To: dri-devel@lists.freedesktop.org
> ---
> V2: Rebase on next-20220214
> ---
> drivers/gpu/drm/bridge/chipone-icn6211.c | 16 +++-
&g
igned-off-by: Marek Vasut
> Cc: Jagan Teki
> Cc: Maxime Ripard
> Cc: Robert Foss
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
> To: dri-devel@lists.freedesktop.org
> ---
> V2: Rebase on next-20220214
> ---
> drivers/gpu/drm/bridge/chipone-icn6211.c | 21 +
han one hard-coded pixel clock
> value anyway.
>
> [1]
> https://github.com/rockchip-linux/kernel/blob/develop-4.19/drivers/gpu/drm/bridge/icn6211.c
> [2] https://github.com/tdjastrzebski/ICN6211-Configurator
>
> Signed-off-by: Marek Vasut
> Cc: Jagan Teki
> Cc: M
itting it.
> Enable transmission of data in LP mode, otherwise register read via DSI
> does not work with this chip.
>
> Signed-off-by: Marek Vasut
> Cc: Jagan Teki
> Cc: Maxime Ripard
> Cc: Robert Foss
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
> To: dri-devel@lists.f
by: Marek Vasut
> Cc: Jagan Teki
> Cc: Maxime Ripard
> Cc: Robert Foss
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
> To: dri-devel@lists.freedesktop.org
Acked-by: Maxime Ripard
Maxime
signature.asc
Description: PGP signature
mple code.
>
> [1]
> https://github.com/rockchip-linux/kernel/blob/develop-4.19/drivers/gpu/drm/bridge/icn6211.c
> [2] https://github.com/tdjastrzebski/ICN6211-Configurator
>
> Signed-off-by: Marek Vasut
> Cc: Jagan Teki
> Cc: Maxime Ripard
> Cc: Robert Foss
> Cc: Sam
loser to the scanout engine.
>
> Signed-off-by: Marek Vasut
> Cc: Jagan Teki
> Cc: Maxime Ripard
> Cc: Robert Foss
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
> To: dri-devel@lists.freedesktop.org
Acked-by: Maxime Ripard
Maxime
signature.asc
Description: PGP signature
able only on chips which have additional MCU on
> the panel/bridge board which preconfigures the ICN6211, while the
> I2C configuration mode added by this patch does not require any
> such MCU.
>
> Signed-off-by: Marek Vasut
> Cc: Jagan Teki
> Cc: Maxime Ripard
> Cc: R
On Thu, Feb 17, 2022 at 01:25:29AM +0100, Marek Vasut wrote:
> Rename and inline macro ICN6211_DSI() into function chipone_writeb()
> to keep all function names lower-case. No functional change.
>
> Signed-off-by: Marek Vasut
> Cc: Jagan Teki
> Cc: Maxime Ripard
> Cc: R
, since that tends to be broken on various bridges.
>
> Signed-off-by: Marek Vasut
> Cc: Jagan Teki
> Cc: Maxime Ripard
> Cc: Robert Foss
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
> To: dri-devel@lists.freedesktop.org
Acked-by: Maxime Ripard
Maxime
signature.asc
Description: PGP signature
Hi,
Please try to avoid top posting
On Wed, Feb 23, 2022 at 04:25:19PM +0100, Max Krummenacher wrote:
> The goal here is to set the element bus_format in the struct
> panel_desc. This is an enum with the possible values defined in
> include/uapi/linux/media-bus-format.h.
>
> The enum values are
Hi,
Back at XDC we floated the idea of creating a test suite for IGT that we
expect any KMS driver to pass, similar to what v4l2-compliance and
cec-compliance provide for v4l2 and CEC respectively.
I was looking at the list of tests, and it's fairly massive, so it's not
clear to me what tests we
On Wed, Mar 02, 2022 at 04:17:04PM +0100, Marek Vasut wrote:
> On 3/2/22 11:01, Maxime Ripard wrote:
> > On Thu, Feb 17, 2022 at 01:25:22AM +0100, Marek Vasut wrote:
> > > The driver currently hard-codes DSI lane count to two, however the chip
> > > is capable of opera
Hi Paul,
On Thu, Mar 03, 2022 at 09:26:30PM +0100, Paul Kocialkowski wrote:
> On Wed 02 Feb 22, 21:34, Jagan Teki wrote:
> > Devices can also be child nodes when we also control that device
> > through the upstream device (ie, MIPI-DCS for a MIPI-DSI device).
> >
> > drm_of_find_panel_or_bridge c
On Fri, Mar 04, 2022 at 12:05:14PM +0100, Paul Kocialkowski wrote:
> On Fri 04 Mar 22, 12:00, Paul Kocialkowski wrote:
> > Hi Maxime,
> >
> > On Fri 04 Mar 22, 09:54, Maxime Ripard wrote:
> > > Hi Paul,
> > >
> > > On Thu, Mar 03, 2022 at 09:26:30P
Hi,
The writeback-check-output is currently broken on vc4.
It's in part due to a bug in the kernel driver that results in a page
flip timeout, but once that's fixed the test is still broken, and I'm
not sure how to solve this one.
Indeed, the frame comparison is done between the (XRGB) buffe
On Mon, 28 Feb 2022 19:14:36 +0100, Jernej Skrabec wrote:
> It turns out that DE3 manual has inverted YUV and YVU format numbers for
> P010 and P210. Invert them.
>
> This was tested by playing video decoded to P010 and additionally
> confirmed by looking at BSP driver source.
>
>
> [...]
Appli
On Mon, 21 Feb 2022 10:58:57 +0100, Maxime Ripard wrote:
> komeda_plane_reset() does the state initialisation by copying a lot of
> the code found in the __drm_atomic_helper_plane_reset(). Let's switch to
> that helper and reduce the boilerplate.
>
>
Applied to drm/drm
On Mon, 21 Feb 2022 10:59:05 +0100, Maxime Ripard wrote:
> The komeda KMS driver will call drm_plane_create_zpos_property() with an
> init value of the plane index.
>
> Since the initial value wasn't carried over in the state, the driver had
> to set it again in komeda_plane_r
On Mon, 21 Feb 2022 10:59:15 +0100, Maxime Ripard wrote:
> The komeda KMS driver will call drm_plane_create_color_properties() with
> a default encoding and range values of BT601 and Limited Range,
> respectively.
>
> Since the initial value wasn't carried over in the state,
ation for each connector or
use that helper and iterate over all connectors all the time.
Since both are suboptimal, let's create a helper that will only perform
the status detection on a single connector.
Signed-off-by: Maxime Ripard
---
Changes from v1:
- Rename the shared function
t
Cc: Sam Ravnborg
Cc: Thierry Reding
Signed-off-by: Maxime Ripard
---
.../display/panel/advantech,idk-1110wr.yaml | 69 ---
.../bindings/display/panel/lvds.yaml | 22 --
2 files changed, 15 insertions(+), 76 deletions(-)
delete mode 100644
Documentation/
data-mapping
requirement to a conditional.
Let's move it to the generic panel-lvds binding
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart
Cc: Sam Ravnborg
Cc: Thierry Reding
Signed-off-by: Maxime Ripard
---
.../display/panel/advantech,idk-2121wr.yaml
ned-off-by: Maxime Ripard
---
.../display/panel/innolux,ee101ia-01d.yaml| 31 ---
.../bindings/display/panel/lvds.yaml | 1 +
2 files changed, 1 insertion(+), 31 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
rg
Cc: Laurent Pinchart
Cc: Sam Ravnborg
Cc: Thierry Reding
Signed-off-by: Maxime Ripard
---
.../bindings/display/panel/mitsubishi,aa104xd12.yaml | 5 -
1 file changed, 5 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
b/Document
The Mitsubishi AA140XD12 Device Tree Binding was requiring a
data-mapping property value which was set to another value in the
existing Device Trees. Fix this.
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart
Cc: Sam Ravnborg
Cc: Thierry Reding
Signed-off-by: Maxime Ripard
t
Cc: Sam Ravnborg
Cc: Thierry Reding
Signed-off-by: Maxime Ripard
---
.../bindings/display/panel/lvds.yaml | 12
.../display/panel/mitsubishi,aa104xd12.yaml | 70 ---
2 files changed, 12 insertions(+), 70 deletions(-)
delete mode 100644
Documentation/devicetre
rg
Cc: Laurent Pinchart
Cc: Sam Ravnborg
Cc: Thierry Reding
Signed-off-by: Maxime Ripard
---
.../bindings/display/panel/mitsubishi,aa121td01.yaml | 5 -
1 file changed, 5 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
b/Document
The Mitsubishi AA121TD01 Device Tree Binding was requiring a
data-mapping property value which was set to another value in the
existing Device Trees. Fix this.
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart
Cc: Sam Ravnborg
Cc: Thierry Reding
Signed-off-by: Maxime Ripard
t
Cc: Sam Ravnborg
Cc: Thierry Reding
Signed-off-by: Maxime Ripard
---
.../bindings/display/panel/lvds.yaml | 5 +-
.../display/panel/mitsubishi,aa121td01.yaml | 69 ---
2 files changed, 4 insertions(+), 70 deletions(-)
delete mode 100644
Documentation/devicetre
A few panel-lvds compatibles were never documented. Let's add them.
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart
Cc: Sam Ravnborg
Cc: Thierry Reding
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/display/panel/lvds.yaml | 2 ++
1 file changed, 2 inser
top.org
Cc: Laurent Pinchart
Cc: Sam Ravnborg
Cc: Thierry Reding
Signed-off-by: Maxime Ripard
---
.../bindings/display/panel/lvds.yaml | 2 +
.../display/panel/sgd,gktw70sdae4se.yaml | 68 ---
2 files changed, 2 insertions(+), 68 deletions(-)
delete mode 100644
Doc
On Tue, Aug 31, 2021 at 09:59:03PM +0800, Cai Huoqing wrote:
> Use the devm_platform_ioremap_resource() helper instead of
> calling platform_get_resource() and devm_ioremap_resource()
> separately
>
> Signed-off-by: Cai Huoqing
Applied, thanks
Maxime
signature.asc
Description: PGP signature
On Tue, Aug 31, 2021 at 09:57:39PM +0800, Cai Huoqing wrote:
> Use the devm_platform_ioremap_resource() helper instead of
> calling platform_get_resource() and devm_ioremap_resource()
> separately
>
> Signed-off-by: Cai Huoqing
Applied, thanks
Maxime
signature.asc
Description: PGP signature
On Wed, Sep 01, 2021 at 11:13:01AM +0800, Chen-Yu Tsai wrote:
> On Wed, Sep 1, 2021 at 2:48 AM Jernej Skrabec
> wrote:
> >
> > Macros SUN8I_CSC_CTRL() and SUN8I_CSC_COEFF() don't follow usual
> > recommendation of having arguments enclosed in parenthesis. While that
> > didn't change anything for
Hi Sudip,
On Thu, Sep 02, 2021 at 10:08:19AM +0100, Sudip Mukherjee wrote:
> Hi All,
>
> Our last night's test on rpi4 had a nasty trace. The test was with
> 7c636d4d20f8 ("Merge tag 'dt-5.15' of
> git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc"). Previous test
> was on 9e9fb7655ed5 ("Merg
On Fri, Sep 03, 2021 at 09:09:50PM +0100, Sudip Mukherjee wrote:
> Hi Maxime,
>
> On Fri, Sep 3, 2021 at 5:03 PM Maxime Ripard wrote:
> >
> > Hi Sudip,
> >
> > On Thu, Sep 02, 2021 at 10:08:19AM +0100, Sudip Mukherjee wrote:
> > > Hi All,
> >
the two patches that were
reverting that commit
- Add some documentation
- Make drm_panel_attach and _detach succeed when no callback is there
Maxime Ripard (24):
drm/bridge: Add documentation sections
drm/bridge: Document the probe issue with MIPI-DSI bridges
drm/mipi-dsi: Create
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.
Reviewed-by: Andrzej Hajda
Reviewed-by: Sam Ravnborg
Signed-off-by
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 consider, and the solution to support all the cases.
Signed-off-by: Maxime R
call to mipi_dsi_device_unregister().
Let's create a device-managed variant of the registration function that
will automatically unregister the device at unbind.
Reviewed-by: Andrzej Hajda
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_mipi_dsi.c
will automatically detach the device at unbind.
Reviewed-by: Andrzej Hajda
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_mipi_dsi.c | 35 ++
include/drm/drm_mipi_dsi.h | 1 +
2 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_ds
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.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/adv7511/adv7511.h | 1 -
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
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.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 13 ++---
1 file ch
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 20 +---
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ana
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.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/analogix/anx7625.c | 20 ++--
1
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/lontium-lt8912b.c | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lo
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.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/lontium-lt8912b.c | 11 +++
1 file chang
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 24
1 file changed, 4 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lo
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.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/lontium-lt9611.c | 38 -
1
Let's switch to the new devm MIPI-DSI function to register and attach
our secondary device.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 38 +-
1 file changed, 8 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lo
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.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 31 +-
1
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.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/parade-ps8640.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --
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.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/parade-ps8640.c | 97 +++---
1
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.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 12 +++-
1 file
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.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 80 +++
1
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.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 22 +++---
1 file changed, 7 insertions(+
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.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/tc358775.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
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.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 74 ++-
1
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.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/tc358775.c | 37 +--
1
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.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 27 +++-
1
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
exynos to it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 19 ---
1
w what you think,
Maxime
Maxime Ripard (3):
drm/bridge: Add a function to abstract away panels
drm/vc4: dpi: Switch to devm_drm_of_get_bridge
drm/vc4: dsi: Switch to devm_drm_of_get_bridge
drivers/gpu/drm/drm_bridge.c | 42 +++
drivers/gpu/drm/drm_of.c
the boilerplate and hopefully create a path of least
resistance towards using the DRM panel bridge layer, let's create the
function devm_drm_of_get_next to reduce that boilerplate.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_bridge.c | 42
driver
The new devm_drm_of_get_bridge removes most of the boilerplate we
have to deal with. Let's switch to it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_dpi.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/dr
The new devm_drm_of_get_bridge removes most of the boilerplate we
have to deal with. Let's switch to it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.c | 2 ++
drivers/gpu/drm/vc4/vc4_dsi.c | 28
2 files changed, 6 insertions(+), 24 dele
On Thu, Aug 19, 2021 at 03:59:25PM +0200, Maxime Ripard wrote:
> Hi,
>
> This series aims at fixing a complete and silent hang when one tries to use
> CEC
> while the display output is off.
>
> This can be tested with:
>
> echo off > /sys/class/drm/card0-HDMI-A
for merging this via
> drm-intel? I think at this time we can get the merge to drm-next and
> backmerge to drm-misc fairly quickly, and a topic branch would be
> overkill.
Yep, that works for me
Acked-by: Maxime Ripard
Maxime
signature.asc
Description: PGP signature
701 - 800 of 8931 matches
Mail list logo
