- Linux-kselftest-mirror - lists.linaro.org

Re: [PATCH 19/24] drm/vc4: crtc: Make encoder lookup helper public

by Javier Martinez Canillas

On 11/23/22 16:26, Maxime Ripard wrote: > We'll need a function that looks up an encoder by its vc4_encoder_type. > Such a function is already present in the CRTC code, so let's make it > public so that we can reuse it in the unit tests. > > Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> > --- Reviewed-by: Javier Martinez Canillas <javierm(a)redhat.com> -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

3 years

1
0
0 0

Re: [PATCH 18/24] drm/vc4: crtc: Introduce a lower-level crtc init helper

by Javier Martinez Canillas

On 11/23/22 16:26, Maxime Ripard wrote: > The current vc4_crtc_init() helper assumes that we will be using > hardware planes and calls vc4_plane_init(). > > While it's a reasonable assumption, we'll want to mock the plane and > thus provide our own. Let's create a helper that will take the plane as > an argument. > > Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> > --- Reviewed-by: Javier Martinez Canillas <javierm(a)redhat.com> -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

3 years

1
0
0 0

Re: [PATCH 17/24] drm/vc4: crtc: Pass the device and data in vc4_crtc_init

by Javier Martinez Canillas

On 11/23/22 16:25, Maxime Ripard wrote: > Both users of vc4_crtc_init need the same extra initialization to set > the pointer to the platform_device and the CRTC data. Since it's > mandatory, let's make them both arguments of vc4_crtc_init(). > > Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> > --- Reviewed-by: Javier Martinez Canillas <javierm(a)redhat.com> -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

3 years

1
0
0 0

Re: [PATCH 16/24] drm/vc4: txp: Initialise the CRTC before the encoder and connector

by Javier Martinez Canillas

On 11/23/22 16:25, Maxime Ripard wrote: > It makes more sense to register the CRTC before the encoder and > connectors, so let's move our call around. > > Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> > --- Reviewed-by: Javier Martinez Canillas <javierm(a)redhat.com> -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

3 years

1
0
0 0

Re: [PATCH 15/24] drm/vc4: Add TXP encoder type

by Javier Martinez Canillas

On 11/23/22 16:25, Maxime Ripard wrote: > The TXP is integrated as a separate CRTC/Encoder/Connector combo, but > for some reason doesn't rely on the vc4_encoder type and it's associated > type. > > Let's create a type to make it consistent with the other encoders. > > Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> > --- Reviewed-by: Javier Martinez Canillas <javierm(a)redhat.com> -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

3 years

1
0
0 0

Re: [PATCH 14/24] drm/vc4: txp: Reorder the variable assignments

by Javier Martinez Canillas

On 11/23/22 16:25, Maxime Ripard wrote: > The current order of variable assignments is unneccessarily complex, > let's make it simpler. > > Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> > --- Much easier to follow indeed. Reviewed-by: Javier Martinez Canillas <javierm(a)redhat.com> -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

3 years

1
0
0 0

Re: [PATCH 13/24] drm/vc4: kms: Constify the HVS old/new state helpers

by Javier Martinez Canillas

On 11/23/22 16:25, Maxime Ripard wrote: > The vc4_hvs_get_(old|new)_global_state functions don't modify the > drm_atomic_state passed as an argument, so let's make it const. > > Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> > --- Reviewed-by: Javier Martinez Canillas <javierm(a)redhat.com> -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

3 years

1
0
0 0

Re: [PATCH 12/24] drm/vc4: Move HVS state to main header

by Javier Martinez Canillas

On 11/23/22 16:25, Maxime Ripard wrote: > In order to introduce unit tests for the HVS state computation, we'll > need access to the vc4_hvs_state struct definition and its associated > helpers. > > Let's move them in our driver header. > > Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> > --- Reviewed-by: Javier Martinez Canillas <javierm(a)redhat.com> -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

3 years

1
0
0 0

Re: [PATCH 11/24] drm/vc4: Constify container_of wrappers

by Javier Martinez Canillas

On 11/23/22 16:25, Maxime Ripard wrote: > None of our wrappers around container_of to access our objects from the > DRM object pointer actually modify the latter. > > Let's make them const. > > Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> > --- Reviewed-by: Javier Martinez Canillas <javierm(a)redhat.com> -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

3 years

1
0
0 0

Re: [PATCH 10/24] drm/vc4: kms: Sort the CRTCs by output before assigning them

by Javier Martinez Canillas

On 11/23/22 16:25, Maxime Ripard wrote: > On the vc4 devices (and later), the blending is done by a single device > called the HVS. The HVS has three FIFO that can operate in parallel, and > route their output to 6 CRTCs and 7 encoders on the BCM2711. > > Each of these CRTCs and encoders have some contraints on which FIFO they constraints. > can feed from, so we need some code to take all those constraints into > account and assign FIFOs to CRTCs. > > The problem can be simplified by assigning those FIFOs to CRTCs by > ascending output index number. We had a comment mentioning it already, > but we were never actually enforcing it. > > It was working still in most situations because the probe order is > roughly equivalent, except for the (optional, and fairly rarely used on > the Pi4) VEC which was last in the probe order sequence, but one of the > earliest device to assign. > > This resulted in configurations that were rejected by our code but were > still valid with a different assignment. > > We can fix this by making sure we assign CRTCs to FIFOs by ordering > them by ascending HVS output index. > > Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically") > Signed-off-by: Maxime Ripard <maxime(a)cerno.tech> > --- [...] > > - for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, new_crtc_state, i) { > - struct vc4_crtc_state *old_vc4_crtc_state = > - to_vc4_crtc_state(old_crtc_state); > - struct vc4_crtc_state *new_vc4_crtc_state = > - to_vc4_crtc_state(new_crtc_state); > - struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc); > + /* > + * The problem we have to solve here is that we have up to 7 > + * encoders, connected to up to 6 CRTCs. > + * > + * Those CRTCs, depending on the instance, can be routed to 1, 2 > + * or 3 HVS FIFOs, and we need to set the change the muxing This sentence sounds a little bit off to me. Did you mean: "we need to set the muxing between" or "we need to change the muxing" ? I'm not familiar with VC4 but the patch seems to do what the commit message says, so the changes look good to me. Reviewed-by: Javier Martinez Canillas <javierm(a)redhat.com> -- Best regards, Javier Martinez Canillas Core Platforms Red Hat

3 years

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror