On Thu, May 16, 2024 at 12:56:27PM +0200, Daniel Vetter wrote:
> On Wed, May 15, 2024 at 11:42:58AM -0700, John Stultz wrote:
> > On Wed, May 15, 2024 at 6:57 AM Maxime Ripard wrote:
> > > This series is the follow-up of the discussion that John and I had a few
>
Hi John,
Thanks for your feedback
On Wed, May 15, 2024 at 11:42:58AM -0700, John Stultz wrote:
> On Wed, May 15, 2024 at 6:57 AM Maxime Ripard wrote:
> > This series is the follow-up of the discussion that John and I had a few
> > months ago here:
> >
> >
Hi again,
On Sun, May 12, 2024 at 04:18:38PM +0800, Andy Yan wrote:
> 在 2024-05-07 21:17:33，"Maxime Ripard" 写道：
> >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
Hi Andy,
On Sun, May 12, 2024 at 04:29:47PM +0800, Andy Yan wrote:
> At 2024-05-07 21:17:45, "Maxime Ripard" wrote:
> >The new HDMI connector infrastructure allows to remove some boilerplate,
> >especially to generate infoframes. Let's switch to it.
> >
> >
On Wed, May 15, 2024 at 11:19:58PM +0800, Sui Jingfeng wrote:
> Hi,
>
>
> On 5/15/24 22:58, Maxime Ripard wrote:
> > On Wed, May 15, 2024 at 10:53:00PM +0800, Sui Jingfeng wrote:
> > > On 5/15/24 22:30, Maxime Ripard wrote:
> > > > On Wed, May 15, 2024
On Sat, May 11, 2024 at 09:00:50PM +0530, Aradhya Bhatia wrote:
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index 4baca0d9107b..40f93230abb2 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -206,6 +206,20 @@ struct drm_bridge_funcs {
>
On Sat, May 11, 2024 at 09:00:46PM +0530, Aradhya Bhatia wrote:
> Update the Phy initialized state to "not initialized" when the driver
> (and the hardware by extension) gets suspended. This will allow the Phy
> to get initialized again after resume.
>
> Fix the OF node that gets passed to find
Hi,
On Sat, May 11, 2024 at 09:00:45PM +0530, Aradhya Bhatia wrote:
> Add support for mode_fixup for the tidss CRTC.
>
> Some bridges like the cdns-dsi consume the crtc_* timing parameters for
> programming the blanking values. Allow for the normal timing parameters
> to get copied to crtc_*
Hi,
On Wed, May 15, 2024 at 09:42:34AM +0200, Sean Nyekjaer wrote:
> On Wed, May 15, 2024 at 08:39:49AM UTC, Yannick FERTRE wrote:
> > Hi Sean,
> >
> > thanks for your patch.
> >
> > Tested-by: Yannick Fertre
> >
> > I think that a helper could be useful in simplifying this part.
> > This
On Wed, May 15, 2024 at 10:53:00PM +0800, Sui Jingfeng wrote:
> On 5/15/24 22:30, Maxime Ripard wrote:
> > On Wed, May 15, 2024 at 12:53:33AM +0800, Sui Jingfeng wrote:
> > > On 2024/5/15 00:22, Maxime Ripard wrote:
> > > > Hi,
> > > >
> > &
On Wed, May 15, 2024 at 12:53:33AM +0800, Sui Jingfeng wrote:
> Hi,
>
> On 2024/5/15 00:22, Maxime Ripard wrote:
> > Hi,
> >
> > On Tue, May 14, 2024 at 11:40:43PM +0800, Sui Jingfeng wrote:
> > > Because a lot of implementations has already added it in
Now that we have introduced ECC-related flags for the dma-heaps buffer
allocations, let's honour these flags depending on the memory setup.
Signed-off-by: Maxime Ripard
---
drivers/dma-buf/heaps/carveout_heap.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/dma
Now that we have introduced ECC-related flags for the dma-heaps buffer
allocations, let's honour these flags depending on the memory setup.
Signed-off-by: Maxime Ripard
---
drivers/dma-buf/heaps/cma_heap.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/dma-buf/heaps
setup
when allocate a dma-buf through a heap.
Signed-off-by: Maxime Ripard
---
drivers/dma-buf/dma-heap.c| 4
include/uapi/linux/dma-heap.h | 5 +++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index 84ae708fafe7
Now that we have introduced ECC-related flags for the dma-heaps buffer
allocations, let's honour these flags depending on the memory setup.
Signed-off-by: Maxime Ripard
---
drivers/dma-buf/heaps/system_heap.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/dma-buf
The system heap has been using its struct dma_heap pointer but wasn't
using it anywhere.
Since we'll need additional parameters to attach to that heap type,
let's create a private structure and set it as the dma_heap drvdata,
removing the global variable in the process.
Signed-off-by: Maxime
-by: Maxime Ripard
---
Maxime Ripard (8):
dma-buf: heaps: Introduce a new heap for reserved memory
of: Add helper to retrieve ECC memory bits
dma-buf: heaps: Import uAPI header
dma-buf: heaps: Add ECC protection flags
dma-buf: heaps: system: Remove global variable
dma-buf
-by: Maxime Ripard
---
include/linux/of.h | 25 +
1 file changed, 25 insertions(+)
diff --git a/include/linux/of.h b/include/linux/of.h
index a0bedd038a05..2fbee65a7aa9 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -1510,10 +1510,35 @@ static inline int
The uAPI header has a bunch of constants and structures that might be
handy in drivers.
Let's include the header in the driver-side dma-heap header.
Signed-off-by: Maxime Ripard
---
include/linux/dma-heap.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/dma-heap.h b
Some reserved memory regions might have particular memory setup or
attributes that make them good candidates for heaps.
Let's provide a heap type that will create a new heap for each reserved
memory region flagged as such.
Signed-off-by: Maxime Ripard
---
drivers/dma-buf/heaps/Kconfig
Hi,
On Tue, May 14, 2024 at 11:40:43PM +0800, Sui Jingfeng wrote:
> Because a lot of implementations has already added it into their drived
> class, promote it into drm_bridge core may benifits a lot. drm bridge is
> a driver, it should know the underlying hardware entity.
Is there some actual
On Mon, May 13, 2024 at 09:42:00AM -0400, Nicolas Dufresne wrote:
> Le lundi 13 mai 2024 à 10:29 +0200, Maxime Ripard a écrit :
> > On Wed, May 08, 2024 at 10:36:08AM +0200, Daniel Vetter wrote:
> > > On Tue, May 07, 2024 at 04:07:39PM -0400, Nicolas Dufresne wrote:
> > >
Hi,
On Wed, May 08, 2024 at 01:51:46PM -0700, Douglas Anderson wrote:
> Through a cooperative effort between Hsin-Yi Wang and Dmitry
> Baryshkov, we have realized the dev_err() in the
> mipi_dsi_*_write_seq() macros was causing quite a bit of bloat to the
> kernel. Let's hoist this call into
On Tue, May 07, 2024 at 10:59:42PM +0300, Dmitry Baryshkov wrote:
> On Tue, 7 May 2024 at 21:40, Laurent Pinchart
> wrote:
> >
> > On Tue, May 07, 2024 at 06:19:18PM +0300, Dmitry Baryshkov wrote:
> > > On Tue, 7 May 2024 at 18:15, Bryan O'Donoghue wrote:
> > > > On 07/05/2024 16:09, Dmitry
On Wed, May 08, 2024 at 10:36:08AM +0200, Daniel Vetter wrote:
> On Tue, May 07, 2024 at 04:07:39PM -0400, Nicolas Dufresne wrote:
> > Hi,
> >
> > Le mardi 07 mai 2024 à 21:36 +0300, Laurent Pinchart a écrit :
> > > Shorter term, we have a problem to solve, and the best option we have
> > > found
Now that we have a plane create helper for kunit mocked drivers, let's
convert to it in vc4.
Reviewed-by: Maíra Canal
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/tests/vc4_mock_plane.c | 34 +++---
1 file changed, 8 insertions(+), 26 deletions(-)
diff --git
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Reviewed-by: Jernej Skrabec
Acked-by: Sui Jingfeng
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/Kconfig | 3 ++
drivers/gpu/drm/sun4i
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Reviewed-by: Heiko Stuebner
Acked-by: Heiko Stuebner
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/Kconfig | 3 +
drivers/gpu/drm/rockchip
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 equivalent to the one already found in i915 and vc4.
Cc: Ville Syrjälä
Signed-off-by: Maxime Ripard
---
drivers/gpu
.
Reviewed-by: Maíra Canal
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/tests/vc4_mock.c | 6 ++
drivers/gpu/drm/vc4/tests/vc4_mock.h | 9 ++---
drivers/gpu/drm/vc4/tests/vc4_mock_plane.c | 14 +-
3 files changed, 9 insertions(+), 20 deletions(-)
diff
The new HDMI connector infrastructure allows us to remove a lot of
boilerplate, so let's switch to it.
Acked-by: Sui Jingfeng
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/Kconfig| 1 +
drivers/gpu/drm/vc4/vc4_hdmi.c | 644 +
drivers/gpu
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 | 152 ++
1 file changed, 152 insertions(+)
diff --git
The previous patch added the generation of the infoframes matching an
HDMI connector state. Let's add a few tests to make sure it works as
expected.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 219 +
1 file changed, 219 insertions
generate them in our common logic so that
drivers can simply reuse what we precomputed.
Cc: Ville Syrjälä
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c| 336 +
drivers/gpu/drm/drm_connector.c| 14 +
drivers/gpu/drm
The previous commit added the infrastructure to the connector state to
track what RGB Quantization should be used in a given state for an HDMI
connector.
Let's add some kunit tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm
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.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/display
This had a bunch of kunit tests to make sure our code to handle the
Broadcast RGB property behaves properly.
This requires bringing a bit of infrastructure to create mock HDMI
connectors, with custom EDIDs.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests
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.
Reviewed-by: Dave Stevenson
Acked-by: Pekka Paalanen
Reviewed-by: Sebastian Wick
Signed-off-by: Maxime
The previous patch added the bpc and format an HDMI connector needs to
be set up with for a given connector state.
Let's add a few tests to make sure it works as expected.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 509 +
drivers
The previous patch adds a new hook for HDMI connectors to filter out
configurations based on the TMDS character rate. Let's add some tests to
make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 65
given mode.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c| 9 +++
drivers/gpu/drm/drm_connector.c| 4 +++
drivers/gpu/drm/tests/drm_connector_test.c | 14 ++
drivers/gpu
The previous patch stores in the connector state the expected TMDS
character rate matching the configuration of the HDMI connector. Let's
add a few tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests
it from the HDMI connector state that stores all those infos
and remove the duplication from drivers.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c| 67 ++
drivers/gpu/drm/drm_atomic.c | 1
The previous patch added an helper to compute the TMDS character rate on
an HDMI connector. Let's add a few tests to make sure it works as
expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 296 +
1
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.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime
Now that we track the HDMI output format as part of the connector state,
let's add a few tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 99 +-
drivers/gpu/drm/tests
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.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c| 3 ++-
drivers/gpu/drm
Now that we're tracking the output bpc count in the connector state,
let's add a few tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/Kconfig| 1 +
drivers/gpu/drm/tests/Makefile
We'll add automatic selection of the output BPC in a following patch,
but let's add it to the HDMI connector state already.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 20
drivers/gpu/drm/drm_atomic.c
Reviewed-by: Sui Jingfeng
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/display/Kconfig | 7 +
drivers/gpu/drm/display/Makefile| 2 ++
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 41 +
include/drm/display/drm_hdmi_state_helper.h
We just introduced a new initialization function for our connectors, so
let's build a kunit test suite for it as well.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 123 +
1 file changed, 123 insertions
We'll need to use drm_mode_obj_find_prop_id() for kunit tests to make
sure a given property has been properly created. Let's export it for
tests only.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_mode_object.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm
with a few
requirements though, and thus we need a new initialization function.
Hopefully, this will make drivers simpler to handle, and their behaviour
more consistent.
Reviewed-by: Dave Stevenson
Reviewed-by: Sui Jingfeng
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_connector.c | 39
Cc: linux-ker...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: linux-rockc...@lists.infradead.org
Cc: linux-su...@lists.linux.dev
Signed-off-by: Maxime Ripard
Changes in v13:
- Adapt to latest Kconfig helper changes
- Fixes for sun4i and rockchip
- Rebase on current drm-misc-next
- Link to v
On Mon, May 06, 2024 at 07:50:57PM GMT, Laurent Pinchart wrote:
> On Mon, May 06, 2024 at 10:57:17AM -0400, Sean Anderson wrote:
> > On 5/6/24 03:35, Laurent Pinchart wrote:
> > > On Mon, May 06, 2024 at 09:29:36AM +0200, Maxime Ripard wrote:
> > >> Hi Laurent, Sean,
Hi,
On Mon, May 06, 2024 at 01:49:17PM GMT, Hans de Goede wrote:
> Hi dma-buf maintainers, et.al.,
>
> Various people have been working on making complex/MIPI cameras work OOTB
> with mainline Linux kernels and an opensource userspace stack.
>
> The generic solution adds a software ISP (for
Hi Andy,
Thanks a lot for giving it a try
All the issues you raised in your review are fixed.
On Sat, Apr 27, 2024 at 06:44:54PM GMT, Andy Yan wrote:
> And after this whole series applied on linux 6.9-rc4, the display on rk3036
> kylin is lost, I get
> the following error:
> [ 178.999421]
Hi,
On Sat, Apr 27, 2024 at 06:12:26PM GMT, Andy Yan wrote:
> On 4/23/24 18:45, Maxime Ripard wrote:
> > The new HDMI connector infrastructure allows to remove some boilerplate,
> > especially to generate infoframes. Let's switch to it.
> >
> > Reviewed-by: Heiko St
Hi Laurent, Sean,
On Sat, May 04, 2024 at 03:21:18PM GMT, Laurent Pinchart wrote:
> On Fri, May 03, 2024 at 05:54:32PM -0400, Sean Anderson wrote:
> > I have discovered a bug in the displayport driver on drm-misc-next. To
> > trigger it, run
> >
> > echo fd4a.display >
pared/enabled state. Even if someone was relying on the
>
> [ ... ]
Acked-by: Maxime Ripard
Thanks!
Maxime
On Fri, 26 Apr 2024 22:56:02 +0900, Masahiro Yamada wrote:
> When you create a submenu using the 'menu' syntax, there is no
> ambiguity about its end because the code between 'menu' and 'endmenu'
> becomes the submenu.
>
> In contrast, 'menuconfig' does not have the corresponding end marker.
>
On Wed, Apr 24, 2024 at 06:06:52PM +0530, Aravind Iddamsetty wrote:
>
> On 24/04/24 17:21, Maxime Ripard wrote:
> > On Mon, Apr 22, 2024 at 12:27:53PM +0530, Aravind Iddamsetty wrote:
> >> In scenarios where drm_dev_put is directly called by driver we
On Tue, Apr 30, 2024 at 12:54:39AM +0800, Sui Jingfeng wrote:
> On 2024/4/29 19:55, Maxime Ripard wrote:
> > On Sat, Apr 27, 2024 at 01:57:46PM +0800, Sui Jingfeng wrote:
> > > On 2024/4/26 14:23, Maxime Ripard wrote:
> > > > On Fri, Apr 26, 2024 at 04:43:
Hi,
On Tue, Apr 30, 2024 at 01:35:21AM +0800, Sui Jingfeng wrote:
> Linux kernel puts strict limits on which functions and data structures
> are available to loadable kernel modules; only those that have been
> explicitly exported with EXPORT_SYMBOL() or EXPORT_SYMBOL_GPL() are
> accessible. In
Hi,
On Mon, Apr 29, 2024 at 10:17:45AM +0200, Sean Nyekjaer wrote:
> On Wed, Apr 24, 2024 at 09:21:17AM UTC, Maxime Ripard wrote:
> > Hi,
> >
> > Sorry, my previous review didn't go through.
> >
> > On Fri, Mar 22, 2024 at 11:47:31AM +0100, Sean Nyekjae
On Sat, Apr 27, 2024 at 01:57:46PM +0800, Sui Jingfeng wrote:
> Hi,
>
>
> On 2024/4/26 14:23, Maxime Ripard wrote:
> > Hi,
> >
> > On Fri, Apr 26, 2024 at 04:43:18AM +0800, Sui Jingfeng wrote:
> > > On 2024/4/26 03:10, Andy Shevchenko wrote:
> > >
On Thu, Apr 25, 2024 at 06:04:50PM +0300, Andy Shevchenko wrote:
> On Thu, Apr 25, 2024 at 04:58:06PM +0200, Maxime Ripard wrote:
> > Hi,
> >
> > On Thu, Apr 25, 2024 at 03:42:07PM +0300, Andy Shevchenko wrote:
> > > First of all, the driver was introduced when it
On Sun, Apr 28, 2024 at 04:52:13PM +0800, Sui Jingfeng wrote:
> ping
>
> 在 2024/3/22 06:22, Sui Jingfeng 写道:
> > Having conditional around the of_node pointer of the drm_bridge structure
> > turns out to make driver code use ugly #ifdef blocks.
The code being ugly is an opinion, what problem is
Hi,
On Fri, Apr 26, 2024 at 04:43:18AM +0800, Sui Jingfeng wrote:
> On 2024/4/26 03:10, Andy Shevchenko wrote:
> > On Fri, Apr 26, 2024 at 02:08:16AM +0800, Sui Jingfeng wrote:
> > > On 2024/4/25 22:26, Andy Shevchenko wrote:
> > > > It seems driver missed the point of proper use of device
Hi,
On Thu, Apr 25, 2024 at 03:42:07PM +0300, Andy Shevchenko wrote:
> First of all, the driver was introduced when it was already
> two drivers available for Ilitek 9341 panels.
>
> Second, the most recent (fourth!) driver has incorporated this one
> and hence, when enabled, it covers the
On Wed, Apr 24, 2024 at 08:20:32AM -0400, Rodrigo Vivi wrote:
> On Wed, Apr 24, 2024 at 01:49:16PM +0200, Maxime Ripard wrote:
> > On Tue, Apr 23, 2024 at 01:42:22PM -0400, Rodrigo Vivi wrote:
> > > On Tue, Apr 23, 2024 at 02:25:06PM +0530, Aravind Iddamsetty wrote:
> > >
of introducing a
> helper (Rodrigo)
>
> v3: add kernel-doc (Maxime Ripard)
>
> Cc: Maxime Ripard
> Cc: Thomas Hellstr_m
> Cc: Rodrigo Vivi
>
> Reviewed-by: Rodrigo Vivi
> Signed-off-by: Aravind Iddamsetty
> ---
> drivers/gpu/drm/drm_drv.c | 13 ++
;> In scenarios where drm_dev_put is directly called by driver we want to
> > >> release devm_drm_dev_init_release action associated with struct
> > >> drm_device.
> > >>
> > >> v2: Directly expose the original function, instead of introducing a
>
Hi,
On Wed, Apr 24, 2024 at 10:43:32AM +0300, Dmitry Baryshkov wrote:
> On Wed, 24 Apr 2024 at 09:54, Neil Armstrong
> wrote:
> >
> > On 20/04/2024 04:41, Dmitry Baryshkov wrote:
> > > This panel driver uses DSC PPS functions and as such depends on the
> > > DRM_DISPLAY_DP_HELPER. Add missing
Hi,
Sorry, my previous review didn't go through.
On Fri, Mar 22, 2024 at 11:47:31AM +0100, Sean Nyekjaer wrote:
> When using the DSI interface via DSI2LVDS bridge, it seems a bit harsh
> to reguire the requested and the actual px clock to be within
> 50Hz. A typical LVDS display requires the px
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 | 152 ++
1 file changed, 152 insertions(+)
diff --git
The previous patch added the generation of the infoframes matching an
HDMI connector state. Let's add a few tests to make sure it works as
expected.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 219 +
1 file changed, 219 insertions
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Reviewed-by: Jernej Skrabec
Acked-by: Sui Jingfeng
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/Kconfig | 1 +
drivers/gpu/drm/sun4i
.
Reviewed-by: Maíra Canal
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/tests/vc4_mock.c | 6 ++
drivers/gpu/drm/vc4/tests/vc4_mock.h | 9 ++---
drivers/gpu/drm/vc4/tests/vc4_mock_plane.c | 14 +-
3 files changed, 9 insertions(+), 20 deletions(-)
diff
The new HDMI connector infrastructure allows us to remove a lot of
boilerplate, so let's switch to it.
Acked-by: Sui Jingfeng
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/Kconfig| 1 +
drivers/gpu/drm/vc4/vc4_hdmi.c | 644 +
drivers/gpu
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.
Reviewed-by: Dave Stevenson
Acked-by: Pekka Paalanen
Reviewed-by: Sebastian Wick
Signed-off-by: Maxime
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Reviewed-by: Heiko Stuebner
Acked-by: Heiko Stuebner
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/Kconfig | 1 +
drivers/gpu/drm/rockchip
generate them in our common logic so that
drivers can simply reuse what we precomputed.
Cc: Ville Syrjälä
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c| 336 +
drivers/gpu/drm/drm_connector.c| 14 +
drivers/gpu/drm
Now that we have a plane create helper for kunit mocked drivers, let's
convert to it in vc4.
Reviewed-by: Maíra Canal
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/tests/vc4_mock_plane.c | 34 +++---
1 file changed, 8 insertions(+), 26 deletions(-)
diff --git
The previous patch added the bpc and format an HDMI connector needs to
be set up with for a given connector state.
Let's add a few tests to make sure it works as expected.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 509 +
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.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/display
The previous patch adds a new hook for HDMI connectors to filter out
configurations based on the TMDS character rate. Let's add some tests to
make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 65
This had a bunch of kunit tests to make sure our code to handle the
Broadcast RGB property behaves properly.
This requires bringing a bit of infrastructure to create mock HDMI
connectors, with custom EDIDs.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests
The previous commit added the infrastructure to the connector state to
track what RGB Quantization should be used in a given state for an HDMI
connector.
Let's add some kunit tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm
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 equivalent to the one already found in i915 and vc4.
Cc: Ville Syrjälä
Signed-off-by: Maxime Ripard
---
drivers/gpu
The previous patch stores in the connector state the expected TMDS
character rate matching the configuration of the HDMI connector. Let's
add a few tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests
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.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime
Now that we track the HDMI output format as part of the connector state,
let's add a few tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 99 +-
drivers/gpu/drm/tests
given mode.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c| 9 +++
drivers/gpu/drm/drm_connector.c| 4 +++
drivers/gpu/drm/tests/drm_connector_test.c | 14 ++
drivers/gpu
The previous patch added an helper to compute the TMDS character rate on
an HDMI connector. Let's add a few tests to make sure it works as
expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 296 +
1
it from the HDMI connector state that stores all those infos
and remove the duplication from drivers.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c| 67 ++
drivers/gpu/drm/drm_atomic.c | 1
Reviewed-by: Sui Jingfeng
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/display/Kconfig | 8 +
drivers/gpu/drm/display/Makefile| 2 ++
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 41 +
include/drm/display/drm_hdmi_state_helper.h
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.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c| 3 ++-
drivers/gpu/drm
Now that we're tracking the output bpc count in the connector state,
let's add a few tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/Kconfig| 1 +
drivers/gpu/drm/tests/Makefile
We just introduced a new initialization function for our connectors, so
let's build a kunit test suite for it as well.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 123 +
1 file changed, 123 insertions
1 - 100 of 7509 matches
Mail list logo
