On Thu, Apr 15, 2021 at 01:02:44PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 15.04.21 um 11:21 schrieb Maxime Ripard:
> > Hi,
> >
> > On Thu, Apr 15, 2021 at 09:31:01AM +0200, Thomas Zimmermann wrote:
> > > Am 08.04.21 um 10:13 schrieb Maxime Ripard:
> &g
xed by -supply
You also can just provide the description, you don't need the true there
> + ddc-i2c-bus: true
ditto
> +description: An I2C interface if the internal DDC I2C driver is not to
> be used
> + ports: true
If there's a single port, you don't need ports
You should also include /schemas/graph.yaml#/$defs/port-base
Maxime
signature.asc
Description: PGP signature
8 and that
prevents the 4k output from working on the RaspberryPi4.
Hopefully, we will be able to merge those patches through the DRM tree to avoid
any further disruption.
Let me know what you think,
Maxime
To: Florian Fainelli
To: Broadcom internal kernel review list
To: Ray Jui
To: Scott B
We'll need the clock IDs in more drivers than just the clock driver from
now on, so let's move them in the firmware header.
Reviewed-by: Florian Fainelli
Acked-by: Stephen Boyd
Signed-off-by: Maxime Ripard
---
drivers/clk/bcm/clk-raspberrypi.c | 19 ---
i
ned-off-by: Maxime Ripard
---
drivers/firmware/raspberrypi.c | 20
include/soc/bcm2835/raspberrypi-firmware.h | 26 ++
2 files changed, 46 insertions(+)
diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
index 93
A significant number of RaspberryPi drivers using the firmware don't
have a phandle to it, so end up scanning the device tree to find a node
with the firmware compatible.
That code is duplicated everywhere, so let's introduce a helper instead.
Signed-off-by: Maxime Ripard
---
driver
, and thus this test
wasn't reliable anymore.
Let's use the new clk_get_max_rate() function to reliably determine the
maximum rate allowed on that clock and fix the 4k@60Hz output.
Fixes: e9d6cea2af1c ("clk: bcm: rpi: Run some clocks at the minimum rate
allowed")
Sig
e.
Signed-off-by: Dom Cobley
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.h | 6 ++
drivers/gpu/drm/vc4/vc4_hdmi.c | 11 +--
drivers/gpu/drm/vc4/vc4_hvs.c | 3 +++
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drive
e are about to ask for to the maximum
rate possible on that clock.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 4419e81
poking into the HVS
structure to get our struct clk handle.
Let's make this part of the HVS bind implementation to have all the core
clock related setup in the same place.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_drv.h | 10 ++
drivers/gpu/drm/vc4/vc4_hdmi.c
Hi Noralf,
On Wed, Oct 19, 2022 at 12:43:19PM +0200, Noralf Trønnes wrote:
>
>
> Den 19.10.2022 10.48, skrev Maxime Ripard:
> > On Tue, Oct 18, 2022 at 02:29:00PM +0200, Noralf Trønnes wrote:
> >>
> >>
> >> Den 18.10.2022 11.33, skrev Maxime Ripard
Hi,
On Tue, Oct 18, 2022 at 11:28:35PM +0200, Mateusz Kwiatkowski wrote:
> W dniu 18.10.2022 o 12:00, Maxime Ripard pisze:
> > On Mon, Oct 17, 2022 at 12:31:31PM +0200, Noralf Trønnes wrote:
> >> Den 16.10.2022 20.52, skrev Mateusz Kwiatkowski:
> >>>> stati
On Tue, Oct 18, 2022 at 10:57:04PM +0200, Mateusz Kwiatkowski wrote:
> Hi Maxime,
>
> W dniu 18.10.2022 o 10:31, Maxime Ripard pisze:
> > Hi,
> >
> > On Sun, Oct 16, 2022 at 09:46:49PM +0200, Mateusz Kwiatkowski wrote:
> >> @@ -308,14 +324,15 @@
https://bugzilla.redhat.com/show_bug.cgi?id=2136234
Fixes: ae71ab585c81 ("drm/vc4: hdmi: Enforce the minimum rate at
runtime_resume")
Reported-by: Peter Robinson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 19 ---
drivers/gpu/drm/vc4/vc4_hdmi.h | 5 +
https://bugzilla.redhat.com/show_bug.cgi?id=2136234
Fixes: ae71ab585c81 ("drm/vc4: hdmi: Enforce the minimum rate at
runtime_resume")
Reported-by: Peter Robinson
Signed-off-by: Maxime Ripard
---
Changes in v2:
- Forgot one more clock to convert to the new one
---
drivers/gpu/drm/vc4/vc4_
On Fri, 21 Oct 2022 09:40:35 +0100, Colin Ian King wrote:
> There are a couple of spelling mistakes in DRM_DEBUG messages. Fix them.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Sat, 22 Oct 2022 14:07:01 +0800, wangjianli wrote:
> Delete the redundant word 'the'.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
re it
does.
Fixes: 6bed2ea3cb38 ("drm/vc4: hdmi: Reset link on hotplug")
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/
on name.
Fixes: 6bed2ea3cb38 ("drm/vc4: hdmi: Reset link on hotplug")
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 9e549fa07467..
r
igt@kms_writeback
Most of them are skipped on vc4 right now, but I could see that some of
them fail already (kms_rmfb, core_hotunplug), so it proves to be useful
already.
What do you think? Is there some more tests needed, or did I include
some tests that shouldn't have been there?
Than
xactly.
- If some of them fail, is it expected for them to fail or not. The
ci/ patch you mentioned help for that a bit, but only for platforms
where someone already did that work. When you want to do that work
in the first place, it's extremely tedious and obscure.
- And if some of them fail, is it something that I should actually fix
or not.
The mustpass list addresses all those issues by providing a baseline.
Maxime
hould move away from it.
Acked-by: Thomas Zimmermann
Reviewed-by: Lyude Paul # nouveau
Reviewed-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic_uapi.c | 8
drivers/gpu/drm/drm_connector.c | 6 +++---
drivers/gpu/drm/gud/gud_connec
ed-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
Changes in v4:
- Simplified the DRM device cleanup patch using devm_drm_dev_alloc()
---
drivers/gpu/drm/tests/Makefile| 1 +
drivers/gpu/drm/tests/drm_kunit_helpers.c | 61 +++
drivers/gpu/drm/
4 -s 53:720x480i -w 53:'TV mode':1 # NTSC
modetest -M vc4 -s 53:720x576i -w 53:'TV mode':4 # PAL
Let me know what you think,
Maxime
To: David Airlie
To: Daniel Vetter
To: Maarten Lankhorst
To: Maxime Ripard
To: Thomas Zimmermann
To: Emma Anholt
To: Jani Nikula
To: Joona
The drm_create_tv_properties() will create the TV mode property
unconditionally.
However, since we'll gradually phase it out, let's register it only if we
have a list passed as an argument. This will make the transition easier.
Acked-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
--
uce a new variant of
that function creating the property superseeding it in a later patch.
Reviewed-by: Lyude Paul # nouveau
Reviewed-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_connector.c | 12 ++--
drivers/gpu/drm/gud/gud_connector.c | 4
#x27;ll then be able to phase out the older tv mode property.
Signed-off-by: Maxime Ripard
---
Changes in v5:
- Create an analog TV properties documentation section, and document TV
Mode there instead of the csv file
Changes in v4:
- Add property documentation to kms-properties.csv
- Fi
splay usually have fairly loose timings requirements,
the only discrete parameters being the total number of lines and pixel
clock frequency. Thus, we created a function that will create a display
mode from the standard, the pixel frequency and the active area.
Signed-off-by: Maxime Ripard
---
Chang
The current construction of the named mode parsing doesn't allow to extend
it easily. Let's move it to a separate function so we can add more
parameters and modes.
In order for the tests to still pass, some extra checks are needed, so
it's not a 1:1 move.
Signed-off-by
We'll need to get the pixel clock to generate proper display modes for
all the current named modes. Let's add it to struct drm_cmdline_mode and
fill it when parsing the named mode.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_modes.c | 9 ++---
include/drm/drm_conne
drm_connector_pick_cmdline_mode() is in charge of finding a proper
drm_display_mode from the definition we got in the video= command line
argument.
Let's add some unit tests to make sure we're not getting any regressions
there.
Acked-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
-
, there's no real code to make that
translation and we rely on the drivers to guess which actual display mode
we meant.
Let's modify drm_mode_create_from_cmdline_mode() to properly generate the
drm_display_mode we mean when passing a named mode.
Signed-off-by: Maxime Ripard
---
Changes in
modes and properties. Let's
start by properly filling drm_cmdline_mode from a named mode.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_modes.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_mod
Now that we can easily extend the named modes list, let's add a few more
analog TV modes that were used in the wild, and some unit tests to make
sure it works as intended.
Signed-off-by: Maxime Ripard
---
Changes in v6:
- Renamed the tests to follow DRM test naming convention
Changes
d-off-by: Maxime Ripard
---
Changes in v6:
- Add a tv_mode_specified field
Changes in v4:
- Add Documentation of the command-line option to modedb.rst
---
Documentation/fb/modedb.rst | 2 +
drivers/gpu/drm/drm_modes.c | 37 --
drivers/gpu/drm/
The analog TV connector drivers share some atomic_check logic, and the new
TV standard property have created some boilerplate that can be be shared
across drivers too.
Let's create an atomic_check helper for those use cases.
Reviewed-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
dr
is is especially important to guarantee that a userspace stack such as
Xorg can start and pick up the preferred mode while maintaining a
working output.
Signed-off-by: Maxime Ripard
---
Changes in v6:
- New patch
---
drivers/gpu/drm/drm_probe_helper.c | 97 ++
includ
lf Trønnes
Signed-off-by: Maxime Ripard
---
Changes in v6:
- Use tv_mode_specified instead of a !0 tv_mode to set the default
---
drivers/gpu/drm/drm_atomic_state_helper.c | 75 +++
include/drm/drm_atomic_state_helper.h | 1 +
2 files changed, 76 insertions(+)
di
return its value.
Reviewed-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_connector.c | 24
include/drm/drm_connector.h | 2 ++
2 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connect
e new analog TV atomic_check helper to make sure we trigger a modeset
whenever the TV mode is updated.
Acked-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
Changes in v6:
- Use new get_modes helper
Changes in v5:
- Renamed tv_mode_names into legacy_tv_mode_names
Changes in v4:
- Removed the co
The analog TV properties created by the drm_mode_create_tv_properties() are
not properly initialised at reset. Let's switch our implementation to call
drm_atomic_helper_connector_tv_reset().
Reviewed-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_vec.
ned-off-by: Mateusz Kwiatkowski
Signed-off-by: Maxime Ripard
---
Changes in v6:
- Used htotal instead of vtotal to discriminate PAL against NTSC
---
drivers/gpu/drm/vc4/vc4_vec.c | 50 +++
1 file changed, 50 insertions(+)
diff --git a/drivers/gpu/drm/vc4/v
Now that the core can deal fine with analog TV modes, let's convert the
sun4i TV driver to leverage those new features.
Acked-by: Noralf Trønnes
Reviewed-by: Jernej Skrabec
Signed-off-by: Maxime Ripard
---
Changes in v6:
- Convert to new get_modes helper
Changes in v5:
- Removed the
The current named mode parsing relies only the mode name, and doesn't allow
to specify any other parameter.
Let's convert that string list to an array of a custom structure that will
hold the name and some additional parameters in the future.
Signed-off-by: Maxime Ripard
---
drive
and various parts of Africa and Asia.
Uses the same 576i50 timings as PAL.
Also added some comments explaining color subcarrier frequency
registers.
Acked-by: Noralf Trønnes
Signed-off-by: Mateusz Kwiatkowski
Signed-off-by: Maxime Ripard
---
Changes in v6:
- Support PAL60 again
---
drivers
id changed what clk_round_rate()
> > > was returning to always return the minimum allowed, and thus this test
> > > wasn't reliable anymore.
> > >
> > > Let's use the new clk_get_max_rate() function to reliably determine the
> > > maximum rate al
t; > + hvs->max_core_rate = max_rate;
>
> I was going to query the reason for storing this value, but it's used
> when we get to patch 7/7.
> I won't quibble about having it as an unused value for 2 patches.
Yeah, it felt natural to do it in that patch, even though it's indeed
only useful in a couple of patches.
Maxime
the new attach and detach hooks.
If the general approach is agreed upon, other drivers will obviously be
converted to drm_of_get_next.
Let me know what you think,
Maxime
Maxime Ripard (10):
Revert "drm/vc4: dsi: Only register our component once a DSI device is
attached"
drm/br
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_dsi.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index a55256ed0955..6dfcbd9e234e 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.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 | 62 +---
driver
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 separare each bits.
Signed-off-by: Maxime Ripard
---
Documentation/gpu/drm-kms-h
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
In order to make the probe order expectation more consistent between
bridges, let's create attach and detach hooks for the panels as well to
match what is there for bridges.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_panel.c | 20
include/drm/drm_panel.h
Now that we have additional attach and detach hooks for panels, make
sure that the panel bridge driver calls them when relevant.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/bridge/panel.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu
The new drm_of_get_next 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 deletions(-)
The mipi_dsi_device allocated by mipi_dsi_device_register_full() is
already free'd on release.
Fixes: 2f733d6194bd ("drm/panel: Add support for the Raspberry Pi 7"
Touchscreen.")
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c | 1
Now that we have an attach hook available for panels as well, let's use
it for the RaspberryPi 7" DSI panel.
This now mimics what all the other bridges in a similar situation are
doing, and we avoid our probe order issue entirely.
Signed-off-by: Maxime Ripard
---
.../drm/p
entirely though, resulting in a
completely empty MIPI-DSI device probe. Let's simplify the driver by
removing it entirely and just behave as a normal i2c driver.
Signed-off-by: Maxime Ripard
---
.../drm/panel/panel-raspberrypi-touchscreen.c | 25 +--
1 file changed, 1 inse
lumenstingl
Cc: Matthias Brugger
Cc: Maxime Coquelin
Cc: Maxime Ripard
Cc: Melissa Wen
Cc: Neil Armstrong
Cc: Nicolas Ferre
Cc: "Noralf Trønnes"
Cc: NXP Linux Team
Cc: Oleksandr Andrushchenko
Cc: Patrik Jakobsson
Cc: Paul Cercueil
Cc: Pekka Paalanen
Cc: Pengutronix Kernel Team
Cc
dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart
Cc: Sam Ravnborg
Cc: Thierry Reding
Signed-off-by: Maxime Ripard
---
.../bindings/display/panel/lvds.yaml | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/panel
The corpro,gm7123 was in use in a DT but was never properly documented,
let's add it.
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Laurent Pinchart
Signed-off-by: Maxime Ripard
---
Changes from v1:
- Removed the dumb-vga-dac compatible from the list
---
.../devicetree/bindings/di
atomic variants.
>
> Signed-off-by: Sam Ravnborg
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: Laurent Pinchart
> Cc: Jonas Karlman
> Cc: Jernej Skrabec
Reviewed-by: Maxime Ripard
Maxime
ferences to the dropped functions.
>
> Signed-off-by: Sam Ravnborg
> Cc: Laurent Pinchart
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: Daniel Vetter
Reviewed-by: Maxime Ripard
Maxime
rm_bridge_funcs.
>
> Signed-off-by: Sam Ravnborg
> Suggested-by: Laurent Pinchart
> Cc: Laurent Pinchart
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Robert Foss
> Cc: Daniel Ve
> were added and is seems safe to remove the call now.
>
> Signed-off-by: Sam Ravnborg
> Cc: Chun-Kuang Hu
> Cc: Philipp Zabel
> Cc: Matthias Brugger
> Cc: Dafna Hirschfeld
> Cc: linux-media...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
Reviewed-by: Maxime Ripard
Maxime
ic_bridge_check().
> Drop it.
>
> Signed-off-by: Sam Ravnborg
> Cc: Laurent Pinchart
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
Reviewed-by: Maxime Ripard
Maxime
On Thu, Jul 22, 2021 at 08:22:46AM +0200, Sam Ravnborg wrote:
> - deprecated callbacks in drm_bridge_funcs
> - move connector creation to display drivers
>
> Signed-off-by: Sam Ravnborg
> Cc: Laurent Pinchart
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas
c_helper_commit_modeset_enables only if the CRTC is active and
needs a modeset.
I guess this means that we won't have a null pointer for crtc_state
there, but wouldn't that cause some issues? I can imagine a property
like the bpc count or output format where it wouldn't imply a modeset
but would definitely affect the bridges in the chain?
Maxime
On Tue, Jul 20, 2021 at 07:19:40PM +0200, Sam Ravnborg wrote:
> Hi Maxime,
> On Tue, Jul 20, 2021 at 03:45:23PM +0200, Maxime Ripard wrote:
> > The mipi_dsi_device allocated by mipi_dsi_device_register_full() is
> > already free'd on release.
> >
> > Fixes: 2f
On Wed, Jul 21, 2021 at 04:16:13PM +0200, Sam Ravnborg wrote:
> On Wed, Jul 21, 2021 at 04:03:41PM +0200, Maxime Ripard wrote:
> > The corpro,gm7123 was in use in a DT but was never properly documented,
> > let's add it.
> >
> > Cc: dri-devel@lists.freedesk
On Tue, Jul 20, 2021 at 04:35:44PM +0200, Maxime Ripard wrote:
> New KMS properties come with a bunch of requirements to avoid each
> driver from running their own, inconsistent, set of properties,
> eventually leading to issues like property conflicts, inconsistencies
> between
Hi Daniel,
On Wed, Jul 21, 2021 at 02:05:01PM +0200, Daniel Vetter wrote:
> On Tue, Jul 20, 2021 at 03:45:19PM +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
>
On Wed, Jul 28, 2021 at 12:01:34PM +0100, Dave Stevenson wrote:
> On Wed, 7 Jul 2021 at 10:36, Maxime Ripard wrote:
> >
> > Commit 91e99e113929 ("drm/vc4: hdmi: Register HDMI codec") removed the
> > references to the vc4_hdmi_audio_component_drv structure, b
00.hdmi' with parent 'vc4-hdmi-0' already present!
>
> Signed-off-by: Ivan T. Ivanov
Thanks for your patch.
However, that part changed fairly significantly recently so you'll need
to rebase it on top of the drm-misc-next (or linux-next)
Maxime
signature.asc
Description: PGP signature
Hi,
On Tue, Jul 27, 2021 at 11:20:54AM +0200, Daniel Vetter wrote:
> On Mon, Jul 26, 2021 at 05:16:57PM +0200, Maxime Ripard wrote:
> > Hi Daniel,
> >
> > On Wed, Jul 21, 2021 at 02:05:01PM +0200, Daniel Vetter wrote:
> > > On Tue, Jul 20, 2021 at 03:45:1
the new attach and detach hooks.
If the general approach is agreed upon, other drivers will obviously be
converted to drm_of_get_next.
Let me know what you think,
Maxime
---
Changes from v1:
- Change the name of drm_of_get_next function to drm_of_get_bridge
- Mention the revert of 87154ff86
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_dsi.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_dsi.c b/drivers/gpu/drm/vc4/vc4_dsi.c
index a55256ed0955..6dfcbd9e234e 100644
--- a/drivers/gpu/drm/vc4/vc4_dsi.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 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: Sam Ravnborg
Signed-off-by: Maxime Ripard
---
Documentat
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
The new drm_of_get_bridge removes most of the boilerplate we have to deal
with. Let's switch to it.
Signed-off-by: Maxime Ripard
fixup! drm/vc4: dsi: Switch to drm_of_get_bridge
---
drivers/gpu/drm/vc4/vc4_drv.c | 2 ++
drivers/gpu/drm/vc4/vc4_dsi.c | 28
2
.
Most drivers have changed significantly since the reverted commit, so we
only brought back the calls in the panel bridge to lessen the risk of
regressions, and since panel bridge is what we're converging to these
days, it's not a big deal anyway.
Signed-off-by: Maxime Ripard
---
drive
entirely though, resulting in a
completely empty MIPI-DSI device probe. Let's simplify the driver by
removing it entirely and just behave as a normal i2c driver.
Signed-off-by: Maxime Ripard
---
.../drm/panel/panel-raspberrypi-touchscreen.c | 25 +--
1 file changed, 1 inse
Now that we have an attach hook available for panels as well, let's use
it for the RaspberryPi 7" DSI panel.
This now mimics what all the other bridges in a similar situation are
doing, and we avoid our probe order issue entirely.
Signed-off-by: Maxime Ripard
---
.../drm/p
Hi Jagan,
On Tue, Jul 27, 2021 at 03:12:09PM +0530, Jagan Teki wrote:
> On Tue, Jul 20, 2021 at 7:15 PM Maxime Ripard wrote:
> >
> > Interactions between bridges, panels, MIPI-DSI host and the component
> > framework are not trivial and can lead to probing issues when
>
i_v7_defconfig) with
> > and without this patch and it shows a lot of changes. Is this intended?
>
> just one question: does the VC4 drm driver functionally depend on
> CONFIG_FB / FRAMEBUFFER_CONSOLE ?
No, just the fbdev emulation but it can work perfectly fine without it.
> Or with other words should we re-enable CONFIG_FB like this [1] but for
> Raspberry Pi related configs?
>
> [1] -
> https://lore.kernel.org/linux-samsung-soc/20210611100204.6240-1-m.szyprow...@samsung.com/
It should work indeed
Maxime
signature.asc
Description: PGP signature
ere is better?
This doesn't have any relationship to the htotal and vtotal though? it's
something that is carried over by the MIPI-DSI functions and struct
mipi_dsi_device.
> >
> > > + }
> > > +
> > > + return MODE_OK;
> >
On Wed, Mar 31, 2021 at 09:49:14AM +0800, Kevin Tang wrote:
> Hi Maxime,
>
> Maxime Ripard 于2021年3月24日周三 下午7:13写道：
>
> > On Mon, Feb 22, 2021 at 09:28:21PM +0800, Kevin Tang wrote:
> > > From: Kevin Tang
> > >
> > > Adds MIPI DSI Controller
updated a lot
> on the basic ip version,
> the entire control register is different, i have cc to drm/bridge reviewers
> and maintainers.
You should make it more obvious then in a comment or in the name of the
driver. If it's fairly different from the original IP from Synops
On Tue, Apr 06, 2021 at 10:29:38AM +0200, Thomas Zimmermann wrote:
> The implementation of drm_driver.dumb_map_offset is the same for several
> TTM-based drivers. Provide a common function in GEM-TTM helpers.
For the series:
Acked-by: Maxime Ripard
Maxime
signature.asc
Descriptio
that both drivers will probe if
they are enabled (which is pretty likely), which is not great :)
I guess we should make them mutually exclusive through Kconfig
Maxime
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-deve
Hi Stephen,
On Tue, Mar 30, 2021 at 11:56:15AM -0700, Stephen Boyd wrote:
> Quoting Maxime Ripard (2021-03-30 08:35:27)
> > Hi Stephen,
> >
> > On Mon, Mar 29, 2021 at 06:52:01PM -0700, Stephen Boyd wrote:
> > > Trimming Cc list way down, sorry if that's to
Hi Dave, Daniel,
Like you asked, here's this week drm-misc-next PR
Maxime
drm-misc-next-2021-04-09:
drm-misc-next for 5.13:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- bridge: Fix Kconfig dependency
- cmdline: Refuse zero width/height mode
- ttm: Ignore signaled move f
Hi Dave,
On Thu, Apr 01, 2021 at 12:30:45PM +0100, Dave Stevenson wrote:
> > Signed-off-by: Maxime Ripard
> > ---
> > drivers/gpu/drm/vc4/vc4_hdmi.c | 56 +
> > drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 3 ++
> > 2 files changed, 59 in
The new clock request API allows us to increase the rate of the HSM
clock to match our pixel rate requirements while decreasing it when
we're done, resulting in a better power-efficiency.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 19 ---
drivers/gp
ll the requests are done.
* Similarly, clk_round_rate has been adjusted to take the requests
into account and return a rate that will be greater or equal to the
requested rates.
Signed-off-by: Maxime Ripard
---
drivers/clk/clk.c | 121
include/li
x27;t have an use-case for something else, this should
maybe be made more flexible?
Let me know what you think
Maxime
Maxime Ripard (2):
clk: Introduce a clock request API
drm/vc4: hdmi: Convert to the new clock request API
drivers/clk/clk.c
those drivers.
Reviewed-by: Harry Wentland
Reviewed-by: Jernej Skrabec
Signed-off-by: Maxime Ripard
---
Changes from v1:
- Rebased on latest drm-misc-next tag
- Added the tags
- Fix build breakage on amdgpu
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 23 ++-
drivers/gp
The intel driver uses the same logic to attach the Colorspace property
in multiple places and we'll need it in vc4 too. Let's move that common
code in a helper.
Signed-off-by: Maxime Ripard
---
Changes from v1:
- New patch
---
drivers/gpu/drm/drm_connector.c
-by: Jernej Skrabec
Signed-off-by: Maxime Ripard
---
Changes from v1:
- Rebased on latest drm-misc-next tag
- Added the tags
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 +---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 3 +--
drivers/gpu/drm/drm_connector.c
1 - 100 of 8823 matches
Mail list logo
