On Fri, Nov 24, 2023 at 03:51:00PM +0800, Sui Jingfeng wrote:
> Hi,
>
> On 2023/11/24 15:38, Maxime Ripard wrote:
> > On Fri, Nov 24, 2023 at 01:52:26AM +0800, Sui Jingfeng wrote:
> > > On 2023/11/23 16:08, Dmitry Baryshkov wrote:
> > > > > I'm agree
On Fri, Nov 24, 2023 at 01:52:26AM +0800, Sui Jingfeng wrote:
> On 2023/11/23 16:08, Dmitry Baryshkov wrote:
> > > I'm agree with the idea that drm bridges drivers involved toward to a
> > > direction
> > > that support more complex design, but I think we should also leave a way
> > > for the
>
Hi,
Here's this week drm-misc-next PR.
It's been fairly calm, but there's one big change: the IMG GPU driver is
now merged!
Maxime
drm-misc-next-2023-11-23:
drm-misc-next for 6.8:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- Drop deprecated drm_kms_helper.edid_firmware module
Hi,
On Wed, Nov 22, 2023 at 04:34:21PM +, Donald Robson wrote:
> This patch series adds the initial DRM driver for Imagination Technologies
> PowerVR
> GPUs, starting with those based on our Rogue architecture. It's worth pointing
> out that this is a new driver, written from the ground up,
Hi Luben,
On Thu, Nov 16, 2023 at 09:27:58AM +0100, Daniel Vetter wrote:
> On Thu, Nov 16, 2023 at 09:11:43AM +0100, Maxime Ripard wrote:
> > On Tue, Nov 14, 2023 at 06:46:21PM -0500, Luben Tuikov wrote:
> > > On 2023-11-13 22:08, Stephen Rothwell wrote:
> > > > BT
On Tue, Nov 21, 2023 at 04:56:44PM +0800, Liu Ying wrote:
> Fix a couple of building warnings on used uninitialized 'best_m' and
> 'best_n' local variables by initializing them to zero. This makes compiler
> happy only. No functional change.
>
> Fixes: ce62f8ea7e3f ("drm/bridge: imx: Add i.MX93
conversion rules.
> >
> > Ville Syrjälä (4):
> > drm: Fix color LUT rounding
> ^
> I'd like to merge this via drm-intel-next as needs to match
> the rounding done in the readout path in i915.
>
> Maarten,Maxime,Thomas can I get an ack for that?
Acked-by: Maxime Ripard
Maxime
signature.asc
Description: PGP signature
On Fri, Nov 17, 2023 at 12:24:22PM +0800, Sui Jingfeng wrote:
> Hi,
>
> On 2023/11/16 23:23, Dmitry Baryshkov wrote:
> > > > > Then you will need some way (fwnode?) to
> > > > > discover the bridge chain. And at the last point you will get into the
> > > > > device data and/or properties
On Fri, Nov 17, 2023 at 01:18:49AM +0800, Sui Jingfeng wrote:
>
> On 2023/11/16 23:23, Dmitry Baryshkov wrote:
> > On Thu, 16 Nov 2023 at 14:08, Sui Jingfeng wrote:
> > >
> > > On 2023/11/16 19:53, Sui Jingfeng wrote:
> > > > Hi,
> > > >
> > > >
> > > > On 2023/11/16 19:29, Dmitry Baryshkov
st (5):
drm/sched: Add drm_sched_wqueue_* helpers
drm/sched: Convert drm scheduler to use a work queue rather than kthread
drm/sched: Split free_job into own work item
drm/sched: Add drm_sched_start_timeout_unlocked helper
drm/sched: Add a helper to queue TDR immediately
M
On Mon, Oct 09, 2023 at 04:06:29PM +0200, Thomas Zimmermann wrote:
> DRM's format-conversion helpers require temporary memory. Pass the
> buffer from the caller to allow the caller to preallocate the buffer
> memory.
>
> The motivation for this patchset is the recent work on a DRM panic
>
nd the panel display_timing flags .
> > >
> > > Fixes: 1e29b840af9f ("drm/panel: simple: Add Innolux G101ICE-L01 panel")
> > > Signed-off-by: Marek Vasut
> > > ---
> > > Cc: Daniel Vetter
> > > Cc: David Airlie
> > > Cc: Jes
On Thu, Nov 16, 2023 at 07:07:39PM +0100, Javier Martinez Canillas wrote:
> This is used to specify the page start address offset of the display RAM.
>
> The value is used as offset when setting the page start address with the
> SSD130X_SET_PAGE_RANGE command, and the driver currently sets its
Hi,
On Thu, Nov 16, 2023 at 05:04:03PM +0100, Geert Uytterhoeven wrote:
> On Thu, Nov 16, 2023 at 4:58 PM Maxime Ripard wrote:
> > On Thu, Nov 16, 2023 at 02:16:08PM +, Biju Das wrote:
> > > Create entry for Renesas RZ DRM drivers and add my self as a maintainer.
>
Hi,
On Thu, Nov 16, 2023 at 02:16:08PM +, Biju Das wrote:
> Create entry for Renesas RZ DRM drivers and add my self as a maintainer.
>
> Signed-off-by: Biju Das
> Reviewed-by: Laurent Pinchart
> ---
> v13->v14:
> * Now SHMOBILE has maintainer entries. So dropped updating
>DRM DRIVERS
Hi,
On Mon, Nov 13, 2023 at 09:56:32PM -0500, Luben Tuikov wrote:
> On 2023-11-13 21:45, Stephen Rothwell wrote:
> > Hi Luben,
> >
> > On Mon, 13 Nov 2023 20:32:40 -0500 Luben Tuikov wrote:
> >>
> >> On 2023-11-13 20:08, Luben Tuikov wrote:
> >>> On 2023-11-13 15:55, Stephen Rothwell wrote:
>
On Tue, Nov 14, 2023 at 06:46:21PM -0500, Luben Tuikov wrote:
> On 2023-11-13 22:08, Stephen Rothwell wrote:
> > BTW, cherry picking commits does not avoid conflicts - in fact it can
> > cause conflicts if there are further changes to the files affected by
> > the cherry picked commit in either
of type void*. While this is probably dodgy enough to be on
> the wrong side of the C standard, it's been often used for similar
>
> [ ... ]
Reviewed-by: Maxime Ripard
Thanks!
Maxime
than hand-coding them.
>
> Let me know if you'd prefer to take these in separately via the drm
> trees, or if you're okay with having this whole series go via
> kselftest/kunit.
You can merge it through your tree with
Acked-by: Maxime Ripard
For the patches 2 and 3
Maxime
signature.asc
Description: PGP signature
Hi,
On Tue, Nov 14, 2023 at 05:18:08PM +0100, Marco Pagani wrote:
> On 2023-11-10 15:41, Maxime Ripard wrote:
> > On Wed, Nov 08, 2023 at 02:42:03PM +0100, Marco Pagani wrote:
> >> This patch introduces an initial KUnit test suite for GEM objects
> >> backed by shmem b
On Wed, 15 Nov 2023 11:35:36 +0100, Marco Pagani wrote:
> Rearrange entries in Kconfig and Makefile alphabetically to make room
> for additional KUnit test suites.
>
>
Applied to drm/drm-misc (drm-misc-next).
Thanks!
Maxime
On Fri, Nov 10, 2023 at 02:17:45PM +, Simon Ser wrote:
> On Friday, November 10th, 2023 at 15:13, Maxime Ripard
> wrote:
>
> > > > > We've talked with Sima at XDC about adding a symlink pointing to the
> > > > > DMA heap and ext
On Fri, Nov 10, 2023 at 02:23:16PM +, Simon Ser wrote:
> On Friday, November 10th, 2023 at 15:01, Maxime Ripard
> wrote:
>
> > On Fri, Nov 10, 2023 at 11:21:15AM +, Simon Ser wrote:
> >
> > > On Thursday, November 9th, 2023 at 20:17, Maxime Ripard
On Wed, Nov 08, 2023 at 02:42:03PM +0100, Marco Pagani wrote:
> This patch introduces an initial KUnit test suite for GEM objects
> backed by shmem buffers.
>
> Suggested-by: Javier Martinez Canillas
> Signed-off-by: Marco Pagani
>
> v2:
> - Improved description of test cases
> - Cleaner error
Hi,
On Fri, Nov 10, 2023 at 04:33:23PM +0530, Dipam Turkar wrote:
> Introduce unit tests for the drm_mode_create_dvi_i_properties() function to
> ensure
> the proper creation of DVI-I specific connector properties.
>
> Signed-off-by: Dipam Turkar
> ---
>
On Fri, Nov 10, 2023 at 11:08:06AM +, Simon Ser wrote:
> > On Thu, Nov 09, 2023 at 03:31:44PM +, Simon Ser wrote:
> > > > > - What would be a good name for the heap? "vc4" is maybe a bit naive
> > > > > and
> > > > > not precise enough. Something with "cma"? Do we need to plan a naming
>
On Fri, Nov 10, 2023 at 11:21:15AM +, Simon Ser wrote:
> On Thursday, November 9th, 2023 at 20:17, Maxime Ripard
> wrote:
>
> > > Can we add another function pointer to the struct drm_driver (or
> > > similar) to do the allocation, and move the actual
On Thu, Nov 09, 2023 at 03:42:38PM +, Dave Stevenson wrote:
> Hi Simon and Maxime
>
> On Thu, 9 Nov 2023 at 09:12, Maxime Ripard wrote:
> >
> > Hi Simon,
> >
> > On Thu, Nov 09, 2023 at 07:45:58AM +, Simon Ser wrote:
> > > User-space sometime
On Thu, Nov 09, 2023 at 03:31:44PM +, Simon Ser wrote:
> > > - What would be a good name for the heap? "vc4" is maybe a bit naive and
> > > not precise enough. Something with "cma"? Do we need to plan a naming
> > > scheme to accomodate for multiple vc4 devices?
> >
> > That's a general issue
On Wed, 25 Oct 2023 15:24:27 +0200, Maxime Ripard wrote:
> Both the drm_buddy and drm_mm tests have been converted from selftest to
> kunit recently.
>
> However, a significant portion of them are trying to exert some part of
> their API over a huge number of iterations and with ra
Hi Maira,
On Thu, Nov 09, 2023 at 09:14:29AM -0300, Maira Canal wrote:
> On 11/9/23 04:45, Simon Ser wrote:
> > User-space sometimes needs to allocate scanout-capable memory for
> > GPU rendering purposes. On a vc4/v3d split render/display SoC, this
> > is achieved via DRM dumb buffers: the v3d
Hi Simon,
On Thu, Nov 09, 2023 at 07:45:58AM +, Simon Ser wrote:
> User-space sometimes needs to allocate scanout-capable memory for
> GPU rendering purposes. On a vc4/v3d split render/display SoC, this
> is achieved via DRM dumb buffers: the v3d user-space driver opens
> the primary vc4
On Tue, Nov 07, 2023 at 12:41:54PM -0800, Hsin-Yi Wang wrote:
> Generic edp gets mode from edid. However, some panels report incorrect
> mode in this way, resulting in glitches on panel. Introduce a new quirk
> additional_mode to the generic edid to pick a correct hardcoded mode.
>
>
On Tue, 7 Nov 2023 12:41:53 -0800, Hsin-Yi Wang wrote:
> Add a few generic edp panels used by mt8186 chromebooks.
>
> Signed-off-by: Hsin-Yi Wang
> Reviewed-by: Douglas Anderson
Acked-by: Maxime Ripard
Thanks!
Maxime
Signed-off-by: Hsin-Yi Wang
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
AUO B116XAK01 panel")
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
Hi,
Thanks for your answer
On Tue, Nov 07, 2023 at 04:26:34PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Nov 07, 2023 at 01:18:14PM +0100, Maxime Ripard wrote:
> > On Tue, Nov 07, 2023 at 12:22:21PM +0100, Greg Kroah-Hartman wrote:
> > > On Tue, Nov 07, 2023 at 11:57:49AM +0
On Tue, Nov 07, 2023 at 12:22:21PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Nov 07, 2023 at 11:57:49AM +0100, Maxime Ripard wrote:
> > +GKH
>
> Why? I don't see a question for me here, sorry.
I guess the question is: we have a bus with various power states
(powered off, low po
+GKH
On Thu, Oct 26, 2023 at 11:41:34AM +0300, Dmitry Baryshkov wrote:
> > > > Also, we would still need to update every single panel driver, which is
> > > > going to create a lot of boilerplate that people might get wrong.
> > >
> > > Yes, quite unfortunately. Another approach that I have in
Hi,
On Sun, Oct 29, 2023 at 06:52:24PM +0200, Dmitry Baryshkov wrote:
> On Thu, 26 Oct 2023 at 14:53, Maxime Ripard wrote:
> >
> > On Thu, Oct 26, 2023 at 11:57:22AM +0300, Dmitry Baryshkov wrote:
> > > On Thu, 26 Oct 2023 at 11:07, Maxime Ripard wrote:
> > &g
Hi,
On Mon, Nov 06, 2023 at 09:26:15PM +0800, oushixi...@kylinos.cn wrote:
> I think it will cause memory leaks if too many nonblock commit works return
> -EBUSY.
Do you *think* or are you sure?
If you are sure, then please write down everything I mentioned earlier
in the commit log and resend
Hi Hans,
On Fri, Nov 03, 2023 at 10:05:18AM +0100, Hans Verkuil wrote:
> Hi Maxime,
>
> Thank you for posting v3, this time it runs fine on my RPi 4, thank you for
> fixing that.
>
> I'll start working on a conformity checker for this.
Awesome :)
> > +static int
On Mon, Oct 30, 2023 at 11:58:20AM +0100, Marco Pagani wrote:
> On 2023-10-25 10:43, Maxime Ripard wrote:
> > On Tue, Oct 24, 2023 at 07:14:25PM +0200, Marco Pagani wrote:
> >>>> +static void drm_gem_shmem_test_obj_create_private(struct kunit *test)
> >>>> +
On Mon, Nov 06, 2023 at 01:01:19PM +, Manna, Animesh wrote:
>
>
> > -Original Message-
> > From: Nikula, Jani
> > Sent: Friday, November 3, 2023 2:55 PM
> > To: Manna, Animesh ; intel-
> > g...@lists.freedesktop.org; Maxime Ripard ; Thoma
On Mon, 6 Nov 2023 12:48:27 +0100, Thomas Hellström wrote:
> "GPL-2.0-only" in the license header was incorrectly changed to the
> now deprecated "GPL-2.0". Fix.
>
> Cc: Maxime Ripard
> Cc: Danilo Krummrich
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
On Mon, Nov 06, 2023 at 11:37:34AM +0100, Thomas Hellström wrote:
> On 11/6/23 11:20, Maxime Ripard wrote:
> > On Mon, Nov 06, 2023 at 11:01:51AM +0100, Thomas Hellström wrote:
> > > Hi, David.
> > >
> > > On 11/3/23 17:37, David Edelsohn wrote:
> > &g
On Wed, 27 Sep 2023 14:38:37 +0100, Tvrtko Ursulin wrote:
> It is better not to lose precision and not revert to 1 MiB size
> granularity for every size greater than 1 MiB.
>
> Sizes in KiB should not be so troublesome to read (and in fact machine
> parsing is I expect the norm here), they align
Hi,
On Mon, Nov 06, 2023 at 03:37:42PM +0800, oushixiong wrote:
> From: Shixiong Ou
>
> Calling stall_checks() before allocating drm_crtc_commit not after that.
>
> Signed-off-by: Shixiong Ou
Generally speaking, we need much more context than that.
What bug did you encounter that makes you
On Mon, Nov 06, 2023 at 11:01:51AM +0100, Thomas Hellström wrote:
> Hi, David.
>
> On 11/3/23 17:37, David Edelsohn wrote:
> > Dual-license drm_gpuvm to GPL-2.0 OR MIT.
> > diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c
> > index 02ce6baacdad..08c088319652 100644 ---
> >
Hi,
On Wed, Nov 01, 2023 at 12:58:17PM +1000, Dave Airlie wrote:
> On Wed, 22 Mar 2023 at 19:04, Zongmin Zhou wrote:
> >
> > The allocated memory for qdev->dumb_heads should be released
> > in qxl_destroy_monitors_object before qxl suspend.
> > otherwise,qxl_create_monitors_object will be called
On Tue, 01 Aug 2023 10:53:09 +0800, Zongmin Zhou wrote:
> The allocated memory for qdev->dumb_heads should be released
> in qxl_destroy_monitors_object before qxl suspend.
> otherwise,qxl_create_monitors_object will be called to
> reallocate memory for qdev->dumb_heads after qxl resume,
> it will
On Fri, Nov 03, 2023 at 09:02:33AM -0700, Doug Anderson wrote:
> Hi,
>
> On Thu, Nov 2, 2023 at 3:13 PM Hsin-Yi Wang wrote:
> >
> > Add a function to clear the preferred bit of a connector's existing modes.
> > This is useful for edp panel to unset the preferred modes read from edid
> > if the
On Thu, Nov 02, 2023 at 07:33:48AM -0700, Doug Anderson wrote:
> Hi,
>
> On Wed, Nov 1, 2023 at 11:31 PM Dmitry Baryshkov
> wrote:
> >
> > On Wed, 1 Nov 2023 at 23:26, Hsin-Yi Wang wrote:
> > >
> > > If a non generic edp-panel is under aux-bus, the mode read from edid would
> > > still be
Hi,
On Wed, Nov 01, 2023 at 02:20:11PM -0700, Hsin-Yi Wang wrote:
> If a non generic edp-panel is under aux-bus, the mode read from edid would
> still be selected as preferred and results in multiple preferred modes,
> which is ambiguous.
>
> If a hard-coded mode is present, unset the preferred
We're not doing anything special in atomic_mode_set so we can simply
merge it into atomic_enable.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/rockchip
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 80 ++
1 file changed, 51 insertions(+), 29 deletions
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 101 ++-
1 file changed, 41 insertions(+), 60 deletions
container_of_const() allows to preserve the pointer constness and is
thus more flexible than inline functions.
Let's switch all our instances of container_of() to container_of_const().
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 16
1 file changed
The coeff_csc matrix isn't used anymore, let's remove it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 70
1 file changed, 70 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
The colorimetry field of hdmi_data_info is not used anywhere so we can
get rid of it. This was the last field left in that structure so we can
get rid of it too.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 15 ---
1 file changed, 15 deletions(-)
diff
The inno_hdmi mode_valid implementation always return MODE_OK which is
what the core assumes when we don't have an implementation.
Let's get rid of it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu
The sun4i_hdmi driver still uses the non-atomic variants of the encoder
hooks, so let's convert to their atomic equivalents.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu
The drm_dev field in the inno_hdmi struct stores a pointer to the DRM
device but is never used anywhere in the driver. Let's remove it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
atomic_check and mode_valid do not check for the same things which can
lead to surprising result if the userspace commits a mode that didn't go
through mode_valid. Let's merge the two implementations into a function
called by both.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i
The new HDMI connector infrastructure allows us to remove a lot of
boilerplate, so let's switch to it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 636 +
drivers/gpu/drm/vc4/vc4_hdmi.h | 44 +--
drivers/gpu/drm/vc4
We're not doing anything special in atomic_mode_set so we can simply
merge it into atomic_enable.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 38 +-
1 file changed, 14 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm
The CSC_* enum has no users left, so let's remove it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index c342bc8b3a23..f05417c6b637
it obvious what
we are doing in the error path.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 53 +++-
1 file changed, 34 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip
The inno_hdmi driver relies on its own internal infoframe type matching
the hardware.
This works fine, but in order to make further reworks easier, let's
switch to the HDMI spec definition of those types.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 71
The register mask and bits to enable or disable a given infoframe
depends on its type.
This is currently passed as an argument to the function that writes an
infoframe, but let's create a helper function to retrieve them based on
the type to make further reworks easier.
Signed-off-by: Maxime
when we
don't have a mode yet.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index f05417c6b637..35f44e556fcf
The inno_hdmi encoder still uses the !atomic variants of enable, disable
and modeset. Convert to their atomic equivalents.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu
The sink_has_audio flag is not used anywhere in the driver so let's get
rid of it. It's redundant with drm_display_info.has_audio anyway.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip
The driver maintains a copy of the adjusted mode but doesn't use it
anywhere. Remove it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
The driver has a lot of logic to deal with multiple input formats, but
hardcodes it to RGB. This means that most of that code has been dead
code, so let's get rid of it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 39 +---
1 file
The mode's VIC is only ever used in the inno_hdmi_setup() function so
there's no need to store it in the main structure.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm
Similarly to the input format, the driver has a lot of code to deal with
various output format, but the driver hardcodes it to RGB always.
Let's get rid of the dead code.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 57
1 file
The mode_fixup implementation doesn't do anything, so we can simply
remove it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index
generate them in our common logic so that
drivers can simply reuse what we precomputed.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/drm_atomic_state_helper.c | 327 ++
drivers/gpu/drm/drm_connector.c | 9
A lot of HDMI drivers have some variation of the formula to calculate
the TMDS character rate from a mode, but few of them actually take all
parameters into account.
Let's create a helper to provide that rate taking all parameters into
account.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm
it from the HDMI connector state that stores all those infos
and remove the duplication from drivers.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c | 1 +
drivers/gpu/drm/drm_atomic_state_helper.c | 44 +++
include/drm/drm_connector.h
Now that we have all the infrastructure needed, we can add some code
that will, for a given connector state and mode, compute the best output
format and bpc.
The algorithm is the same one than the one already found in i915 and
vc4.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm
still fragile so let's fix this properly.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 25c9c71256d3..f05e2c95a60d 100644
in the hardware. It won't be perfect since we have no guarantee that
it's actually what goes through the wire, but it's the best we can do.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_debugfs.c | 110 ++
1 file changed, 110 insertions(+)
diff --git
given mode.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic_state_helper.c | 9 +
drivers/gpu/drm/drm_connector.c | 4
include/drm/drm_connector.h | 30 ++
3 files changed, 43 insertions(+)
diff --git a/drive
Just like BPC, we'll add support for automatic selection of the output
format for HDMI connectors.
Let's add the needed defaults and fields for now.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c | 2 ++
drivers/gpu/drm/drm_atomic_state_helper.c | 4 +++-
drivers
HDMI controller drivers will need to figure out the RGB range they need
to configure based on a mode and property values. Let's expose that in
the HDMI connector state so drivers can just use that value.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c | 4
We'll add automatic selection of the output BPC in a following patch,
but let's add it to the HDMI connector state already.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c | 1 +
drivers/gpu/drm/drm_atomic_state_helper.c | 8 +++-
drivers/gpu/drm/drm_connector.c
the userspace having support for it, is proof enough that it's
pretty much a de-facto standard now and we can provide helpers for it.
Let's plumb it into the newly created HDMI connector.
Signed-off-by: Maxime Ripard
---
Documentation/gpu/kms-properties.csv | 1 -
drivers/gpu/drm
The next features we will need to share across drivers will need to
store some parameters for drivers to use, such as the selected output
format.
Let's create a new connector state dedicated to HDMI controllers, that
will eventually store everything we need.
Signed-off-by: Maxime Ripard
, and their behaviour
more consistent.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_connector.c | 39 +++
include/drm/drm_connector.h | 5 +
2 files changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index
it
through debugfs.
This entire series has been tested on a Pi4, and has only been
build-tested for sunxi and rockchip.
Let me know what you think,
Maxime
Signed-off-by: Maxime Ripard
---
Changes in v3:
- Made sure the series work on the RaspberryPi4
- Handle YUV420 in the char clock rate computa
On Tue, Oct 31, 2023 at 02:00:06PM +0100, Geert Uytterhoeven wrote:
> Hi Maxime,
>
> On Tue, Oct 31, 2023 at 12:53 PM Maxime Ripard wrote:
> > On Tue, Oct 31, 2023 at 12:27:05PM +0100, Javier Martinez Canillas wrote:
> > > Geert Uytterhoeven writes:
> > > >&g
On Tue, Oct 31, 2023 at 12:27:05PM +0100, Javier Martinez Canillas wrote:
> Geert Uytterhoeven writes:
>
> > Hi Javier,
>
> [...]
>
> >> >> Pushed to drm-misc (drm-misc-next). Thanks!
> >> >
> >> > Looks like you introduced an unintended
> >> >
> >> > (cherry picked from commit
On Mon, Oct 30, 2023 at 10:39:32PM +0800, Sui Jingfeng wrote:
> Hi,
>
>
> On 2023/10/30 21:39, Maxime Ripard wrote:
> > On Mon, Oct 30, 2023 at 09:25:50PM +0800, Sui Jingfeng wrote:
> > > I think my approach provide a solution, while still keep the bridges
>
On Mon, Oct 30, 2023 at 09:25:50PM +0800, Sui Jingfeng wrote:
> I think my approach provide a solution, while still keep the bridges drivers
> to a modular at the same time. Despite simple, it indeed solve the problem.
> It simple because of explicit control of the loading order by myself, not by
Hi,
On Mon, Oct 30, 2023 at 05:42:28PM +0800, Sui Jingfeng wrote:
> On 2023/10/30 06:53, Dmitry Baryshkov wrote:
> > On Sun, 29 Oct 2023 at 21:46, Sui Jingfeng wrote:
> > > The IT66121 is a DVO to HDMI converter, LS3A5000+LS7A1000 ML5A_MB use this
> > > chip to support HDMI output. Thus add a
eally not clear to me what these were
testing in the first place.
So the scope of the work would effectively be "increase our test
coverage" which I believe is already covered by the todo task just
above.
Maxime
> On 10/25/23 10:24, Maxime Ripard wrote:
> > Most of those suites
On Tue, 19 Sep 2023 15:22:49 -0300, Helen Koike wrote:
> DRM CI keeps track of which tests are failing, flaking or being skipped
> by the ci in the expectations files. Add entries for those files to the
> corresponding driver maintainer, so they can be notified when they
> change.
>
>
Applied
Hi,
On Thu, Oct 26, 2023 at 11:27:18AM -0300, Helen Koike wrote:
> On 26/10/2023 10:27, Maxime Ripard wrote:
> > On Thu, Oct 26, 2023 at 09:08:03AM -0300, Helen Koike wrote:
> > >
> > >
> > > On 26/10/2023 09:01, Helen Koike wrote:
> > > >
>
801 - 900 of 7441 matches
Mail list logo
