[PATCH 2/3] drm/vc4: Use .pixel_order instead of custom .flip_cbcr
The hardware has enums for altering the Cr and Cb order,
so use this instead of having a flag which swaps the
order the pointers are presented to the hardware
(that only worked for 3 plane formats anyway).
Explicitly sets .pixel_order in each case, rather than
relying on then default XYCBCR order being a value 0.
Signed-off-by: Dave Stevenson <dave.steven...@raspberrypi.org>
---
drivers/gpu/drm/vc4/vc4_plane.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 513b4b1..6373fd5 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -86,7 +86,6 @@ static const struct hvs_format {
u32 hvs; /* HVS_FORMAT_* */
u32 pixel_order;
bool has_alpha;
- bool flip_cbcr;
} hvs_formats[] = {
{
.drm = DRM_FORMAT_XRGB, .hvs = HVS_PIXEL_FORMAT_RGBA,
@@ -131,28 +130,32 @@ static const struct hvs_format {
{
.drm = DRM_FORMAT_YUV422,
.hvs = HVS_PIXEL_FORMAT_YCBCR_YUV422_3PLANE,
+ .pixel_order = HVS_PIXEL_ORDER_XYCBCR,
},
{
.drm = DRM_FORMAT_YVU422,
.hvs = HVS_PIXEL_FORMAT_YCBCR_YUV422_3PLANE,
- .flip_cbcr = true,
+ .pixel_order = HVS_PIXEL_ORDER_XYCRCB,
},
{
.drm = DRM_FORMAT_YUV420,
.hvs = HVS_PIXEL_FORMAT_YCBCR_YUV420_3PLANE,
+ .pixel_order = HVS_PIXEL_ORDER_XYCBCR,
},
{
.drm = DRM_FORMAT_YVU420,
.hvs = HVS_PIXEL_FORMAT_YCBCR_YUV420_3PLANE,
- .flip_cbcr = true,
+ .pixel_order = HVS_PIXEL_ORDER_XYCRCB,
},
{
.drm = DRM_FORMAT_NV12,
.hvs = HVS_PIXEL_FORMAT_YCBCR_YUV420_2PLANE,
+ .pixel_order = HVS_PIXEL_ORDER_XYCBCR,
},
{
.drm = DRM_FORMAT_NV16,
.hvs = HVS_PIXEL_FORMAT_YCBCR_YUV422_2PLANE,
+ .pixel_order = HVS_PIXEL_ORDER_XYCBCR,
},
};
@@ -625,15 +628,8 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
* The pointers may be any byte address.
*/
vc4_state->ptr0_offset = vc4_state->dlist_count;
- if (!format->flip_cbcr) {
- for (i = 0; i < num_planes; i++)
- vc4_dlist_write(vc4_state, vc4_state->offsets[i]);
- } else {
- WARN_ON_ONCE(num_planes != 3);
- vc4_dlist_write(vc4_state, vc4_state->offsets[0]);
- vc4_dlist_write(vc4_state, vc4_state->offsets[2]);
- vc4_dlist_write(vc4_state, vc4_state->offsets[1]);
- }
+ for (i = 0; i < num_planes; i++)
+ vc4_dlist_write(vc4_state, vc4_state->offsets[i]);
/* Pointer Context Word 0/1/2: Written by the HVS */
for (i = 0; i < num_planes; i++)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] drm/vc4 support for extra formats
These are relatively trivial patches that just expand the list of formats that the vc4 DRM driver will accept. RGB888, BGR888, NV21, and NV61 tested with the modetest app from the libdrm repo. YUV422 and YVU422 can't be as they aren't supported. Dave Stevenson (3): drm/vc4: Add support for DRM_FORMAT_RGB888 and DRM_FORMAT_BGR888 drm/vc4: Use .pixel_order instead of custom .flip_cbcr drm/vc4: Add support for NV21 and NV61. drivers/gpu/drm/vc4/vc4_plane.c | 38 ++ 1 file changed, 26 insertions(+), 12 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/vc4: Add support for NV21 and NV61.
NV12 (YUV420 2 plane) and NV16 (YUV422 2 plane) were
supported, but NV21 and NV61 (same but with Cb and Cr
swapped) weren't. Add them.
Signed-off-by: Dave Stevenson <dave.steven...@raspberrypi.org>
---
drivers/gpu/drm/vc4/vc4_plane.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 6373fd5..515f979 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -153,10 +153,20 @@ static const struct hvs_format {
.pixel_order = HVS_PIXEL_ORDER_XYCBCR,
},
{
+ .drm = DRM_FORMAT_NV21,
+ .hvs = HVS_PIXEL_FORMAT_YCBCR_YUV420_2PLANE,
+ .pixel_order = HVS_PIXEL_ORDER_XYCRCB,
+ },
+ {
.drm = DRM_FORMAT_NV16,
.hvs = HVS_PIXEL_FORMAT_YCBCR_YUV422_2PLANE,
.pixel_order = HVS_PIXEL_ORDER_XYCBCR,
},
+ {
+ .drm = DRM_FORMAT_NV61,
+ .hvs = HVS_PIXEL_FORMAT_YCBCR_YUV422_2PLANE,
+ .pixel_order = HVS_PIXEL_ORDER_XYCRCB,
+ },
};
static const struct hvs_format *vc4_get_hvs_format(u32 drm_format)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/vc4: Add support for DRM_FORMAT_RGB888 and DRM_FORMAT_BGR888
Filling out the list of supported formats based on those the
hardware can support.
Signed-off-by: Dave Stevenson <dave.steven...@raspberrypi.org>
---
drivers/gpu/drm/vc4/vc4_plane.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 423a23e..513b4b1 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -121,6 +121,14 @@ static const struct hvs_format {
.pixel_order = HVS_PIXEL_ORDER_ABGR, .has_alpha = false,
},
{
+ .drm = DRM_FORMAT_RGB888, .hvs = HVS_PIXEL_FORMAT_RGB888,
+ .pixel_order = HVS_PIXEL_ORDER_XRGB, .has_alpha = false,
+ },
+ {
+ .drm = DRM_FORMAT_BGR888, .hvs = HVS_PIXEL_FORMAT_RGB888,
+ .pixel_order = HVS_PIXEL_ORDER_XBGR, .has_alpha = false,
+ },
+ {
.drm = DRM_FORMAT_YUV422,
.hvs = HVS_PIXEL_FORMAT_YCBCR_YUV422_3PLANE,
},
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/vc4: Force ->x_scaling[1] should never be set to VC4_SCALING_NONE
Hi Boris & Eric.
On Thu, 8 Nov 2018 at 15:12, Eric Anholt wrote:
>
> Boris Brezillon writes:
>
> > On Thu, 08 Nov 2018 06:52:44 -0800
> > Eric Anholt wrote:
> >
> >> Boris Brezillon writes:
> >>
> >> > For the YUV conversion to work properly, ->x_scaling[0,1] should never
> >> > be set to VC4_SCALING_NONE, but vc4_get_scaling_mode() might return
> >> > VC4_SCALING_NONE if the horizontal scaling ratio exactly matches the
> >> > horizontal subsampling factor. Add a test to turn VC4_SCALING_NONE
> >> > into VC4_SCALING_PPF when that happens.
> >> >
> >> > Fixes: fc04023fafec ("drm/vc4: Add support for YUV planes.")
> >> > Signed-off-by: Boris Brezillon
> >>
> >> I couldn't find a spec justification for this -- did you have a testcase
> >> that fails?
> >
> > Yep. Just set the downscaling ratio to 0.5 with an NV12 format and
> > you'll hit the issue (I used modetest to do that):
> >
> > # modetest -M vc4 -s 29:1920x1080-60 -P 96@95:1920x1080*0.5@NV12
>
> I found that the firmware has a similar behavior to your patch ("if Y is
> !unity (x or scaling) and UV is unity, set UV to HPPF/VPPF scaling").
> They also select the unity flag after the YUV scaling fixup.
>
> Regardless, if this works, it's got my reviewed-by.
>
> Hopefully we can do some IGT with writeback or chamelium testing all of
> the X/Y scaling options with a focus on hitting these 1:1 ratios. The
> state space is big and the docs are just ambiguous enough.
Great timing as I've hit exactly this when playing back a 1080P video
on a 1080P screen. The colours were very muted in this situation,
whilst playing any other resolution or any RGB format was fine. Took
me a while to realise it wasn't the conversion matrices being set
incorrectly :-/ Applying this patch sorts the problem.
This was on the downstream 4.19 kernel, and the v2 of this set
backported fairly easily. Can I request that for stable? Otherwise we
can cherry-pick it for downstream.
Thanks
Dave
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 79/91] drm/vc4: hdmi: Deal with multiple debugfs files
Hi Stefan and Maxime
On Tue, 28 Apr 2020 at 16:57, Maxime Ripard wrote:
>
> Hi Stefan,
>
> On Sat, Apr 25, 2020 at 11:26:31PM +0200, Stefan Wahren wrote:
> > Am 24.04.20 um 17:35 schrieb Maxime Ripard:
> > > The HDMI driver was registering a single debugfs file so far with the name
> > > hdmi_regs.
> > >
> > > Obviously, this is not going to work anymore when will have multiple HDMI
> > > controllers since we will end up trying to register two files with the
> > > same
> > > name.
> > >
> > > Let's use the ID to avoid that name conflict.
> >
> > even with this patch there is a name conflict in debugfs using Linux
> > 5.7-rc1. Dave Stevenson addressed this by using different card names
> > [1]. Since this patch won't apply anymore here is my suggestion:
> >
> > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > index 29287ab..7209397 100644
> > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > @@ -1181,9 +1181,14 @@ static int vc4_hdmi_audio_init(struct vc4_hdmi
> > *vc4_hdmi)
> >
> > card->dai_link = dai_link;
> > card->num_links = 1;
> > -card->name = "vc4-hdmi";
> > card->dev = dev;
> >
> > +if (vc4_hdmi->variant->encoder_type == VC4_ENCODER_TYPE_HDMI1) {
> > +card->name = "vc4-hdmi1";
> > +} else {
> > +card->name = "vc4-hdmi";
> > +}
> > +
>
> Thinking about this some more, we don't really need VC4_ENCODER_TYPE_HDMI0 and
> HDMI1, and it can all work with the same encoder type for both, so I'll drop
> them.
>
> To address this issue though, we can add a card name string to the variant,
> like
> I did for debugfs. Is that alright for you?
My patch doesn't fix everything with the audio debugfs entries anyway.
I'm working against 5.4 on our downstream tree, and even with my patch
I get
[7.459508] debugfs: Directory 'fef00700.hdmi' with parent
'vc4-hdmi' already present!
[7.511017] debugfs: Directory 'fef05700.hdmi' with parent
'vc4-hdmi1' already present!
I seem to recall I reduced the number of complaints over 'vc4-hdmi',
but internal to sound/soc-core the node is still registered twice.
There was discussion about this a few months back.
https://lore.kernel.org/lkml/1jblpvraho@starbuckisacylon.baylibre.com/
seemed to conclude that it wasn't totally trivial to solve.
Regards,
Dave
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 75/80] drm/vc4: hdmi: Add pixel BVB clock control
Hi Maxime
On Thu, 3 Sep 2020 at 09:03, Maxime Ripard wrote:
>
> From: Hoegeun Kwon
>
> The BCM2711 has another clock that needs to be ramped up depending on the
> pixel rate: the pixel BVB clock. Add the code to adjust that clock when
> changing the mode.
>
> Signed-off-by: Hoegeun Kwon
> [Maxime: Changed the commit log, used clk_set_min_rate]
> Signed-off-by: Maxime Ripard
> Link:
> https://lore.kernel.org/r/20200901040759.29992-3-hoegeun.k...@samsung.com
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 23 +++
> drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
> 2 files changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index ab7abb409de2..39508107dafd 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -54,6 +54,7 @@
> #include "vc4_regs.h"
>
> #define CEC_CLOCK_FREQ 4
> +#define VC4_HSM_MID_CLOCK 149985000
I didn't flag it earlier, but this is a bit of a weird name for the
define. I know it wants to be concise, but it made me do a double take
as to what it is for.
I'm currently applying all these patches to our Raspberry Pi tree and
actually CEC needs a fixed HSM on Pi0-3 to avoid recomputing all the
timings. So I have a VC4_HSM_CLOCK define which is the fixed clock
rate for Pi 0-3.
This one is more a threshold for HSM to control BVB, and my brain
starts to hurt over what it should be called.
Unless there are other comments around this patchset (and I hope to
read through the remaining ones today), then I don't consider it a
blocker, but we can probably do better as and when we add the next
threshold for 4k60.
My current understanding is that the clock has to be an integer divide
of 600MHz, and at least the pixel rate / 2, so the only link to HSM is
due to HSM being 101% of pixel rate, but I will try to find
confirmation of that.
>
> static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
> {
> @@ -344,6 +345,7 @@ static void vc4_hdmi_encoder_post_crtc_powerdown(struct
> drm_encoder *encoder)
> HDMI_WRITE(HDMI_VID_CTL,
>HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
>
> + clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock);
> clk_disable_unprepare(vc4_hdmi->hsm_clock);
> clk_disable_unprepare(vc4_hdmi->pixel_clock);
>
> @@ -516,6 +518,27 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
> drm_encoder *encoder)
> return;
> }
>
> + /*
> +* FIXME: When the pixel freq is 594MHz (4k60), this needs to be setup
> +* at 150MHz.
> +*/
Typo here. For 4k60 we need 300MHz (pixel clock / 2)
Otherwise
Reviewed-by: Dave Stevenson
> + ret = clk_set_min_rate(vc4_hdmi->pixel_bvb_clock,
> + (hsm_rate > VC4_HSM_MID_CLOCK ? 15000 :
> 7500));
> + if (ret) {
> + DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
> + clk_disable_unprepare(vc4_hdmi->hsm_clock);
> + clk_disable_unprepare(vc4_hdmi->pixel_clock);
> + return;
> + }
> +
> + ret = clk_prepare_enable(vc4_hdmi->pixel_bvb_clock);
> + if (ret) {
> + DRM_ERROR("Failed to turn on pixel bvb clock: %d\n", ret);
> + clk_disable_unprepare(vc4_hdmi->hsm_clock);
> + clk_disable_unprepare(vc4_hdmi->pixel_clock);
> + return;
> + }
> +
> if (vc4_hdmi->variant->reset)
> vc4_hdmi->variant->reset(vc4_hdmi);
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index 34138e0dd4a6..59639b405b7f 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -119,6 +119,7 @@ struct vc4_hdmi {
> struct clk *pixel_clock;
> struct clk *hsm_clock;
> struct clk *audio_clock;
> + struct clk *pixel_bvb_clock;
>
> struct debugfs_regset32 hdmi_regset;
> struct debugfs_regset32 hd_regset;
> --
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 55/80] drm/vc4: hdmi: Add a CSC setup callback
Hi Maxime
On Thu, 3 Sep 2020 at 09:03, Maxime Ripard wrote:
>
> Similarly to the previous patches, the CSC setup is slightly different in
> the BCM2711 than in the previous generations. Let's add a callback for it.
>
> Tested-by: Chanwoo Choi
> Tested-by: Hoegeun Kwon
> Tested-by: Stefan Wahren
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 70 +--
> drivers/gpu/drm/vc4/vc4_hdmi.h | 3 ++-
> 2 files changed, 45 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index c29376c3fd8a..532618e02399 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -334,6 +334,41 @@ static void vc4_hdmi_encoder_disable(struct drm_encoder
> *encoder)
> DRM_ERROR("Failed to release power domain: %d\n", ret);
> }
>
> +static void vc4_hdmi_csc_setup(struct vc4_hdmi *vc4_hdmi, bool enable)
> +{
> + u32 csc_ctl;
> +
> + csc_ctl = VC4_SET_FIELD(VC4_HD_CSC_CTL_ORDER_BGR,
> + VC4_HD_CSC_CTL_ORDER);
> +
> + if (enable) {
> + /* CEA VICs other than #1 requre limited range RGB
> +* output unless overridden by an AVI infoframe.
> +* Apply a colorspace conversion to squash 0-255 down
> +* to 16-235. The matrix here is:
> +*
> +* [ 0 0 0.8594 16]
> +* [ 0 0.8594 0 16]
> +* [ 0.8594 0 0 16]
> +* [ 0 0 0 1]
> +*/
> + csc_ctl |= VC4_HD_CSC_CTL_ENABLE;
> + csc_ctl |= VC4_HD_CSC_CTL_RGB2YCC;
> + csc_ctl |= VC4_SET_FIELD(VC4_HD_CSC_CTL_MODE_CUSTOM,
> +VC4_HD_CSC_CTL_MODE);
> +
> + HDMI_WRITE(HDMI_CSC_12_11, (0x000 << 16) | 0x000);
> + HDMI_WRITE(HDMI_CSC_14_13, (0x100 << 16) | 0x6e0);
> + HDMI_WRITE(HDMI_CSC_22_21, (0x6e0 << 16) | 0x000);
> + HDMI_WRITE(HDMI_CSC_24_23, (0x100 << 16) | 0x000);
> + HDMI_WRITE(HDMI_CSC_32_31, (0x000 << 16) | 0x6e0);
> + HDMI_WRITE(HDMI_CSC_34_33, (0x100 << 16) | 0x000);
> + }
> +
> + /* The RGB order applies even when CSC is disabled. */
> + HDMI_WRITE(HDMI_CSC_CTL, csc_ctl);
> +}
> +
> static void vc4_hdmi_encoder_enable(struct drm_encoder *encoder)
> {
> struct drm_display_mode *mode = >crtc->state->adjusted_mode;
> @@ -357,7 +392,6 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
> *encoder)
> mode->crtc_vsync_end -
> interlaced,
> VC4_HDMI_VERTB_VBP));
> - u32 csc_ctl;
> int ret;
>
> ret = pm_runtime_get_sync(_hdmi->pdev->dev);
> @@ -428,41 +462,20 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
> *encoder)
>(vsync_pos ? 0 : VC4_HD_VID_CTL_VSYNC_LOW) |
>(hsync_pos ? 0 : VC4_HD_VID_CTL_HSYNC_LOW));
>
> - csc_ctl = VC4_SET_FIELD(VC4_HD_CSC_CTL_ORDER_BGR,
> - VC4_HD_CSC_CTL_ORDER);
>
> if (vc4_encoder->hdmi_monitor &&
> - drm_default_rgb_quant_range(mode) ==
> - HDMI_QUANTIZATION_RANGE_LIMITED) {
> - /* CEA VICs other than #1 requre limited range RGB
> -* output unless overridden by an AVI infoframe.
> -* Apply a colorspace conversion to squash 0-255 down
> -* to 16-235. The matrix here is:
> -*
> -* [ 0 0 0.8594 16]
> -* [ 0 0.8594 0 16]
> -* [ 0.8594 0 0 16]
> -* [ 0 0 0 1]
> -*/
> - csc_ctl |= VC4_HD_CSC_CTL_ENABLE;
> - csc_ctl |= VC4_HD_CSC_CTL_RGB2YCC;
> - csc_ctl |= VC4_SET_FIELD(VC4_HD_CSC_CTL_MODE_CUSTOM,
> -VC4_HD_CSC_CTL_MODE);
> + drm_default_rgb_quant_range(mode) ==
> HDMI_QUANTIZATION_RANGE_LIMITED) {
> + if (vc4_hdmi->variant->csc_setup)
> + vc4_hdmi->variant->csc_setup(vc4_hdmi, true);
>
> - HDMI_WRITE(HDMI_CSC_12_11, (0x000 << 16) | 0x000);
> - HDMI_WRITE(HDMI_CSC_14_13, (0x100 << 16) | 0x6e0);
> - HDMI_WRITE(HDMI_CSC_22_2
Re: [PATCH v5 13/80] drm/vc4: kms: Convert to for_each_new_crtc_state
Hi Maxime
On Thu, 3 Sep 2020 at 09:02, Maxime Ripard wrote:
>
> The vc4 atomic commit loop has an handrolled loop that is basically
> identical to for_each_new_crtc_state, let's convert it to that helper.
>
> Tested-by: Chanwoo Choi
> Tested-by: Hoegeun Kwon
> Tested-by: Stefan Wahren
> Signed-off-by: Maxime Ripard
Based on your comment to the previous revision, I'm happy.
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_kms.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> index 210cc2408087..a41d105d4e3c 100644
> --- a/drivers/gpu/drm/vc4/vc4_kms.c
> +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> @@ -152,14 +152,16 @@ vc4_atomic_complete_commit(struct drm_atomic_state
> *state)
> struct drm_device *dev = state->dev;
> struct vc4_dev *vc4 = to_vc4_dev(dev);
> struct vc4_hvs *hvs = vc4->hvs;
> - struct vc4_crtc *vc4_crtc;
> + struct drm_crtc_state *new_crtc_state;
> + struct drm_crtc *crtc;
> int i;
>
> - for (i = 0; i < dev->mode_config.num_crtc; i++) {
> - if (!state->crtcs[i].ptr || !state->crtcs[i].commit)
> + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
> + struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
> +
> + if (!new_crtc_state->commit)
> continue;
>
> - vc4_crtc = to_vc4_crtc(state->crtcs[i].ptr);
> vc4_hvs_mask_underrun(dev, vc4_crtc->channel);
> }
>
> --
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 56/80] drm/vc4: hdmi: Add a set_timings callback
Hi Maxime
On Thu, 3 Sep 2020 at 09:03, Maxime Ripard wrote:
>
> Similarly to the previous patches, the timings setup in the HDMI controller
> of the BCM2711 is slightly different, mostly because it supports higher
> resolutions and thus needed more spaces for the various timings, resulting
> in the register layout changing.
>
> Let's add a callback for that as well.
>
> Tested-by: Chanwoo Choi
> Tested-by: Hoegeun Kwon
> Tested-by: Stefan Wahren
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 72 +++
> drivers/gpu/drm/vc4/vc4_hdmi.h | 4 ++-
> 2 files changed, 44 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 532618e02399..9e2bc6cb690e 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -369,12 +369,9 @@ static void vc4_hdmi_csc_setup(struct vc4_hdmi
> *vc4_hdmi, bool enable)
> HDMI_WRITE(HDMI_CSC_CTL, csc_ctl);
> }
>
> -static void vc4_hdmi_encoder_enable(struct drm_encoder *encoder)
> +static void vc4_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
> +struct drm_display_mode *mode)
> {
> - struct drm_display_mode *mode = >crtc->state->adjusted_mode;
> - struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> - struct vc4_hdmi_encoder *vc4_encoder = _hdmi->encoder;
> - bool debug_dump_regs = false;
> bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
> bool vsync_pos = mode->flags & DRM_MODE_FLAG_PVSYNC;
> bool interlaced = mode->flags & DRM_MODE_FLAG_INTERLACE;
> @@ -392,6 +389,41 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
> *encoder)
> mode->crtc_vsync_end -
> interlaced,
> VC4_HDMI_VERTB_VBP));
> +
> + HDMI_WRITE(HDMI_HORZA,
> + (vsync_pos ? VC4_HDMI_HORZA_VPOS : 0) |
> + (hsync_pos ? VC4_HDMI_HORZA_HPOS : 0) |
> + VC4_SET_FIELD(mode->hdisplay * pixel_rep,
> +VC4_HDMI_HORZA_HAP));
> +
> + HDMI_WRITE(HDMI_HORZB,
> + VC4_SET_FIELD((mode->htotal -
> + mode->hsync_end) * pixel_rep,
> +VC4_HDMI_HORZB_HBP) |
> + VC4_SET_FIELD((mode->hsync_end -
> + mode->hsync_start) * pixel_rep,
> +VC4_HDMI_HORZB_HSP) |
> + VC4_SET_FIELD((mode->hsync_start -
> + mode->hdisplay) * pixel_rep,
> +VC4_HDMI_HORZB_HFP));
> +
> + HDMI_WRITE(HDMI_VERTA0, verta);
> + HDMI_WRITE(HDMI_VERTA1, verta);
> +
> + HDMI_WRITE(HDMI_VERTB0, vertb_even);
> + HDMI_WRITE(HDMI_VERTB1, vertb);
> +
> + HDMI_WRITE(HDMI_VID_CTL,
> + (vsync_pos ? 0 : VC4_HD_VID_CTL_VSYNC_LOW) |
> + (hsync_pos ? 0 : VC4_HD_VID_CTL_HSYNC_LOW));
> +}
> +
> +static void vc4_hdmi_encoder_enable(struct drm_encoder *encoder)
> +{
> + struct drm_display_mode *mode = >crtc->state->adjusted_mode;
> + struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> + struct vc4_hdmi_encoder *vc4_encoder = to_vc4_hdmi_encoder(encoder);
> + bool debug_dump_regs = false;
> int ret;
>
> ret = pm_runtime_get_sync(_hdmi->pdev->dev);
> @@ -435,33 +467,8 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
> *encoder)
>VC4_HDMI_SCHEDULER_CONTROL_MANUAL_FORMAT |
>VC4_HDMI_SCHEDULER_CONTROL_IGNORE_VSYNC_PREDICTS);
>
> - HDMI_WRITE(HDMI_HORZA,
> - (vsync_pos ? VC4_HDMI_HORZA_VPOS : 0) |
> - (hsync_pos ? VC4_HDMI_HORZA_HPOS : 0) |
> - VC4_SET_FIELD(mode->hdisplay * pixel_rep,
> -VC4_HDMI_HORZA_HAP));
> -
> - HDMI_WRITE(HDMI_HORZB,
> - VC4_SET_FIELD((mode->htotal -
> - mode->hsync_end) * pixel_rep,
> -VC4_HDMI_HORZB_HBP) |
> - VC4_SET_FIELD((mode->hsync_end -
> - mode->hsync_start) * pixel_rep,
> -VC4_HDMI_HORZB_HSP) |
> - VC4_SET_FIELD((mode->hsync_start -
> - mode->hdisplay) * pixel_rep,
> -
Re: [PATCH v5 79/80] drm/vc4: drv: Support BCM2711
Hi Maxime
On Thu, 3 Sep 2020 at 09:03, Maxime Ripard wrote:
>
> The BCM2711 has a reworked display pipeline, and the load tracker needs
> some adjustment to operate properly. Let's add a compatible for BCM2711
> and disable the load tracker until properly supported.
>
> Tested-by: Chanwoo Choi
> Tested-by: Hoegeun Kwon
> Tested-by: Stefan Wahren
> Signed-off-by: Maxime Ripard
I'm happy with this.
Potentially a case for having split it into two patches (make the load
tracker optional, and then use that option for the new compatible),
but I'm not convinced, so:
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_drv.c | 1 +-
> drivers/gpu/drm/vc4/vc4_drv.h | 3 ++-
> drivers/gpu/drm/vc4/vc4_kms.c | 44 +++---
> drivers/gpu/drm/vc4/vc4_plane.c | 5 -
> 4 files changed, 40 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
> index 9567d1019212..f1a5fd5dab6f 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.c
> +++ b/drivers/gpu/drm/vc4/vc4_drv.c
> @@ -372,6 +372,7 @@ static int vc4_platform_drm_remove(struct platform_device
> *pdev)
> }
>
> static const struct of_device_id vc4_of_match[] = {
> + { .compatible = "brcm,bcm2711-vc5", },
> { .compatible = "brcm,bcm2835-vc4", },
> { .compatible = "brcm,cygnus-vc4", },
> {},
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index 501a48a714d3..8c8d96b6289f 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -200,6 +200,9 @@ struct vc4_dev {
>
> int power_refcount;
>
> + /* Set to true when the load tracker is supported. */
> + bool load_tracker_available;
> +
> /* Set to true when the load tracker is active. */
> bool load_tracker_enabled;
>
> diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> index bfc7ddd49ac5..16e233e1406e 100644
> --- a/drivers/gpu/drm/vc4/vc4_kms.c
> +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> @@ -536,6 +536,9 @@ static int vc4_load_tracker_atomic_check(struct
> drm_atomic_state *state)
> struct drm_plane *plane;
> int i;
>
> + if (!vc4->load_tracker_available)
> + return 0;
> +
> priv_state = drm_atomic_get_private_obj_state(state,
> >load_tracker);
> if (IS_ERR(priv_state))
> @@ -683,12 +686,18 @@ int vc4_kms_load(struct drm_device *dev)
> struct vc4_dev *vc4 = to_vc4_dev(dev);
> struct vc4_ctm_state *ctm_state;
> struct vc4_load_tracker_state *load_state;
> + bool is_vc5 = of_device_is_compatible(dev->dev->of_node,
> + "brcm,bcm2711-vc5");
> int ret;
>
> - /* Start with the load tracker enabled. Can be disabled through the
> -* debugfs load_tracker file.
> -*/
> - vc4->load_tracker_enabled = true;
> + if (!is_vc5) {
> + vc4->load_tracker_available = true;
> +
> + /* Start with the load tracker enabled. Can be
> +* disabled through the debugfs load_tracker file.
> +*/
> + vc4->load_tracker_enabled = true;
> + }
>
> sema_init(>async_modeset, 1);
>
> @@ -702,8 +711,14 @@ int vc4_kms_load(struct drm_device *dev)
> return ret;
> }
>
> - dev->mode_config.max_width = 2048;
> - dev->mode_config.max_height = 2048;
> + if (is_vc5) {
> + dev->mode_config.max_width = 7680;
> + dev->mode_config.max_height = 7680;
> + } else {
> + dev->mode_config.max_width = 2048;
> + dev->mode_config.max_height = 2048;
> + }
> +
> dev->mode_config.funcs = _mode_funcs;
> dev->mode_config.preferred_depth = 24;
> dev->mode_config.async_page_flip = true;
> @@ -718,14 +733,17 @@ int vc4_kms_load(struct drm_device *dev)
> drm_atomic_private_obj_init(dev, >ctm_manager, _state->base,
> _ctm_state_funcs);
>
> - load_state = kzalloc(sizeof(*load_state), GFP_KERNEL);
> - if (!load_state) {
> - drm_atomic_private_obj_fini(>ctm_manager);
> - return -ENOMEM;
> - }
> + if (vc4->load_tracker_available) {
> + load_state = kzalloc(sizeof(*load_state), GFP_KERNEL);
> + if (!load_state) {
> + drm_atomi
Re: [PATCH v2 6/6] drm/vc4: hdmi: Enable 10/12 bpc output
Hi Maxime
On Thu, 8 Oct 2020 at 13:44, Maxime Ripard wrote:
>
> The BCM2711 supports higher bpc count than just 8, so let's support it in
> our driver.
Something appears to be slightly off with this one. Running the
monitor (Dell U2718Q 4k monitor) at 1080p60.
Use modetest to switch "max bpc" to 10bpc, and the monitor reports 1080p48.
Use modetest to switch "max bpc" to 12bpc, and the monitor reports 1080p40.
I haven't got an HDMI analyser to hand to confirm whether we're
actually putting out 10 or 12bpc.
So at a guess a clock is unaltered, but the number of bits being sent
over the link is increased, thereby dropping the overall frame rate.
Having tested with the firmware it only points to my monitor not
supporting alternate bpc values - not so helpful.
I'm not sure the handling of the GCP is correct either. It is
enabled/disabled via bit 0 of HDMI_RAM_PACKET_CONFIG in the same way
all the infoframes are.
The firmware enables/disables sending the GCP when handling avmute,
but this driver isn't handling avmute so it never gets enabled
I'll have a further experiment to see if I can make things play ball.
I'll need to collect the analyser and deep colour display to really
try it out.
Dave
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 68 +-
> drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +-
> drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 9 -
> 3 files changed, 77 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 21d20c8494e8..3ff72fab4c40 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -76,6 +76,17 @@
> #define VC5_HDMI_VERTB_VSPO_SHIFT 16
> #define VC5_HDMI_VERTB_VSPO_MASK VC4_MASK(29, 16)
>
> +#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_SHIFT 8
> +#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_MASK VC4_MASK(10,
> 8)
> +
> +#define VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_SHIFT 0
> +#define VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_MASK VC4_MASK(3, 0)
> +
> +#define VC5_HDMI_GCP_CONFIG_GCP_ENABLE BIT(31)
> +
> +#define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_SHIFT 8
> +#define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_MASK VC4_MASK(15, 8)
> +
> # define VC4_HD_M_SW_RST BIT(2)
> # define VC4_HD_M_ENABLE BIT(0)
>
> @@ -177,6 +188,9 @@ static void vc4_hdmi_connector_reset(struct drm_connector
> *connector)
>
> kfree(connector->state);
>
> + conn_state->base.max_bpc = 8;
> + conn_state->base.max_requested_bpc = 8;
> +
> __drm_atomic_helper_connector_reset(connector, _state->base);
> drm_atomic_helper_connector_tv_reset(connector);
> }
> @@ -224,12 +238,20 @@ static int vc4_hdmi_connector_init(struct drm_device
> *dev,
> vc4_hdmi->ddc);
> drm_connector_helper_add(connector, _hdmi_connector_helper_funcs);
>
> + /*
> +* Some of the properties below require access to state, like bpc.
> +* Allocate some default initial connector state with our reset
> helper.
> +*/
> + if (connector->funcs->reset)
> + connector->funcs->reset(connector);
> +
> /* Create and attach TV margin props to this connector. */
> ret = drm_mode_create_tv_margin_properties(dev);
> if (ret)
> return ret;
>
> drm_connector_attach_tv_margin_properties(connector);
> + drm_connector_attach_max_bpc_property(connector, 8, 16);
>
> connector->polled = (DRM_CONNECTOR_POLL_CONNECT |
> DRM_CONNECTOR_POLL_DISCONNECT);
> @@ -495,6 +517,7 @@ static void vc5_hdmi_csc_setup(struct vc4_hdmi *vc4_hdmi,
> bool enable)
> }
>
> static void vc4_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
> +struct drm_connector_state *state,
> struct drm_display_mode *mode)
> {
> bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
> @@ -538,7 +561,9 @@ static void vc4_hdmi_set_timings(struct vc4_hdmi
> *vc4_hdmi,
> HDMI_WRITE(HDMI_VERTB0, vertb_even);
> HDMI_WRITE(HDMI_VERTB1, vertb);
> }
> +
> static void vc5_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
> +struct drm_connector_state *state,
> struct drm_display_mode *mode)
> {
> bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
> @@ -558,6 +583,9 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi
> *vc4_hdmi,
> mode->crtc_vsync_end -
> interlaced,
> VC4_HDMI_VERTB_VBP));
> + unsigned char gcp;
> + bool gcp_en;
> + u32 reg;
>
> HDMI_WRITE(HDMI_VEC_INTERFACE_XBAR, 0x354021);
>
Re: [PATCH v5 80/80] ARM: dts: bcm2711: Enable the display pipeline
Hi Maxime On Fri, 2 Oct 2020 at 16:19, Maxime Ripard wrote: > > Hi Tim, > > On Thu, Oct 01, 2020 at 11:15:46AM +0100, Tim Gover wrote: > > hdmi_enable_4k60=1 causes the firmware to select 3.3 GHz for the PLLC > > VCO to support a core-frequency of 550 MHz which is the minimum > > frequency required by the HVS at 4Kp60. The side effect is that if the > > display clock requirements are lower than 4Kp60 then you will see > > different core frequencies selected by DVFS. > > > > If enable_uart=1 and the mini-uart is selected (default unless > > bluetooth is disabled) then the firmware will pin the core-frequency > > to either core_freq max (500 or 550). Although, I think there is a way > > of pinning it to a lower fixed frequency. > > > > The table in overclocking.md defines options for setting the maximum > > core frequency but unless core_freq_min is specified DVFS will > > automatically pick the lowest idle frequency required by the display > > resolution. > > I'm wondering if there's some way to detect this from Linux? I guess it > would be nice to be able to at least detect a broken config to warn / > prevent an user that their situation is not going to be reliable / work > really well (like if they have a 4k display without hdmi_enable_4kp60 > set, or the issue we're discussing here) The main filter in the firmware is the parameter hdmi_pixel_freq_limit. That can either be set manually from config.txt, or defaults appropriately based on hdmi_enable_4kp60. Under firmware_kms [1] I read back those values to use as a filter within crtc_mode_valid[2]. I can't think of a nice way of exposing that without the vc4 driver gaining a DT link to the firmware, and that starts to get ugly. Dave [1] https://github.com/raspberrypi/linux/blob/rpi-5.9.y/drivers/gpu/drm/vc4/vc4_firmware_kms.c#L1859 [2] https://github.com/raspberrypi/linux/blob/rpi-5.9.y/drivers/gpu/drm/vc4/vc4_firmware_kms.c#L1077 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 80/80] ARM: dts: bcm2711: Enable the display pipeline
Hi Maxime On Tue, 6 Oct 2020 at 16:26, Maxime Ripard wrote: > > Hi Dave, > > On Fri, Oct 02, 2020 at 04:57:05PM +0100, Dave Stevenson wrote: > > Hi Maxime > > > > On Fri, 2 Oct 2020 at 16:19, Maxime Ripard wrote: > > > > > > Hi Tim, > > > > > > On Thu, Oct 01, 2020 at 11:15:46AM +0100, Tim Gover wrote: > > > > hdmi_enable_4k60=1 causes the firmware to select 3.3 GHz for the PLLC > > > > VCO to support a core-frequency of 550 MHz which is the minimum > > > > frequency required by the HVS at 4Kp60. The side effect is that if the > > > > display clock requirements are lower than 4Kp60 then you will see > > > > different core frequencies selected by DVFS. > > > > > > > > If enable_uart=1 and the mini-uart is selected (default unless > > > > bluetooth is disabled) then the firmware will pin the core-frequency > > > > to either core_freq max (500 or 550). Although, I think there is a way > > > > of pinning it to a lower fixed frequency. > > > > > > > > The table in overclocking.md defines options for setting the maximum > > > > core frequency but unless core_freq_min is specified DVFS will > > > > automatically pick the lowest idle frequency required by the display > > > > resolution. > > > > > > I'm wondering if there's some way to detect this from Linux? I guess it > > > would be nice to be able to at least detect a broken config to warn / > > > prevent an user that their situation is not going to be reliable / work > > > really well (like if they have a 4k display without hdmi_enable_4kp60 > > > set, or the issue we're discussing here) > > > > The main filter in the firmware is the parameter > > hdmi_pixel_freq_limit. That can either be set manually from > > config.txt, or defaults appropriately based on hdmi_enable_4kp60. > > Under firmware_kms [1] I read back those values to use as a filter > > within crtc_mode_valid[2]. > > I can't think of a nice way of exposing that without the vc4 driver > > gaining a DT link to the firmware, and that starts to get ugly. > > I had in mind something like if the clock driver can infer that somehow > through some the boundaries reported by the firmware maybe? IIRC, > hdmi_enable_4kp60 will already change the max frequency reported to > 550MHz instead of 500MHz Yes, that's plausible, but I don't know enough about the clock infrastructure for advertising limits to know what works there. Tell me what you need from the mailbox service and I'll see what I can do. We do already have RPI_FIRMWARE_GET_MAX_CLOCK_RATE and RPI_FIRMWARE_GET_MIN_CLOCK_RATE. It'd take a few minutes of staring at the code (or a quick test) to confirm if they definitely are changed for CORE clock by hdmi_enable_4kp60 - I think it does. Dave ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/vc4: hdmi: Add pixel bvb clock control
Hi Stefan & Hoegeun
On Wed, 26 Aug 2020 at 11:04, Stefan Wahren wrote:
>
> Hi Hoeguen,
>
> Am 21.08.20 um 09:10 schrieb Hoegeun Kwon:
> > There is a problem that the output does not work at a resolution
> > exceeding FHD. To solve this, we need to adjust the bvb clock at a
> > resolution exceeding FHD.
>
> this patch introduces a mandatory clock, please update
> brcm,bcm2835-hdmi.yaml first.
>
> Is this clock physically available on BCM283x or only on BCM2711?
>
> I'm a little bit afraid, this change could break with older firmware
> versions on BCM283x.
Thanks for your keen eye on these things.
BVB only exists on 2711, not 283x.
It runs at 2 pixels/clock, must be an integer divider of I believe
600MHz, and between 75 and 300MHz.
This aim of this patch is fine as we currently only go up to 4k30, but
for 4k60 the BVB will need to be set to 300MHz.
Thanks
Dave
> Best regards
> Stefan
>
> >
> > Signed-off-by: Hoegeun Kwon
> > ---
> > drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
> > drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
> > 2 files changed, 26 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > index 95ec5eedea39..eb3192d1fd86 100644
> > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > @@ -80,6 +80,7 @@
> > # define VC4_HD_M_ENABLE BIT(0)
> >
> > #define CEC_CLOCK_FREQ 4
> > +#define VC4_HSM_MID_CLOCK 149985000
> >
> > static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
> > {
> > @@ -380,6 +381,7 @@ static void vc4_hdmi_encoder_post_crtc_powerdown(struct
> > drm_encoder *encoder)
> > HDMI_WRITE(HDMI_VID_CTL,
> > HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
> >
> > + clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock);
> > clk_disable_unprepare(vc4_hdmi->hsm_clock);
> > clk_disable_unprepare(vc4_hdmi->pixel_clock);
> >
> > @@ -638,6 +640,23 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
> > drm_encoder *encoder)
> > return;
> > }
> >
> > + ret = clk_set_rate(vc4_hdmi->pixel_bvb_clock,
> > + (hsm_rate > VC4_HSM_MID_CLOCK ? 15000 :
> > 7500));
> > + if (ret) {
> > + DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
> > + clk_disable_unprepare(vc4_hdmi->hsm_clock);
> > + clk_disable_unprepare(vc4_hdmi->pixel_clock);
> > + return;
> > + }
> > +
> > + ret = clk_prepare_enable(vc4_hdmi->pixel_bvb_clock);
> > + if (ret) {
> > + DRM_ERROR("Failed to turn on pixel bvb clock: %d\n", ret);
> > + clk_disable_unprepare(vc4_hdmi->hsm_clock);
> > + clk_disable_unprepare(vc4_hdmi->pixel_clock);
> > + return;
> > + }
> > +
> > if (vc4_hdmi->variant->reset)
> > vc4_hdmi->variant->reset(vc4_hdmi);
> >
> > @@ -1593,6 +1612,12 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
> > *vc4_hdmi)
> > return PTR_ERR(vc4_hdmi->audio_clock);
> > }
> >
> > + vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
> > + if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
> > + DRM_ERROR("Failed to get pixel bvb clock\n");
> > + return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
> > + }
> > +
> > vc4_hdmi->reset = devm_reset_control_get(dev, NULL);
> > if (IS_ERR(vc4_hdmi->reset)) {
> > DRM_ERROR("Failed to get HDMI reset line\n");
> > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> > index 0806c6d9f24e..63c6f8bddf1d 100644
> > --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> > @@ -147,6 +147,7 @@ struct vc4_hdmi {
> > struct clk *pixel_clock;
> > struct clk *hsm_clock;
> > struct clk *audio_clock;
> > + struct clk *pixel_bvb_clock;
> >
> > struct reset_control *reset;
> >
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/vc4: hdmi: Add pixel bvb clock control
Hi Maxime, Stefan, and Hoegeun
On Fri, 28 Aug 2020 at 16:25, Maxime Ripard wrote:
>
> Hi,
>
> On Fri, Aug 28, 2020 at 02:45:49PM +0200, Stefan Wahren wrote:
> > Am 28.08.20 um 08:30 schrieb Hoegeun Kwon:
> > > On 8/27/20 6:49 PM, Stefan Wahren wrote:
> > >> Am 27.08.20 um 06:35 schrieb Hoegeun Kwon:
> > >>> Hi Stefan,
> > >>>
> > >>> Thank you for your review.
> > >>>
> > >>>
> > >>> On 8/26/20 7:04 PM, Stefan Wahren wrote:
> > Hi Hoeguen,
> >
> > Am 21.08.20 um 09:10 schrieb Hoegeun Kwon:
> > > There is a problem that the output does not work at a resolution
> > > exceeding FHD. To solve this, we need to adjust the bvb clock at a
> > > resolution exceeding FHD.
> > this patch introduces a mandatory clock, please update
> > brcm,bcm2835-hdmi.yaml first.
> >
> > Is this clock physically available on BCM283x or only on BCM2711?
> > >>> As far as I know, BCM2711 raspberry pi 4 supports 4k,
> > >>>
> > >>> don't supported on pi 3 and pi 3+.
> > >>>
> > >>> Since 4k is not supported in versions prior to Raspberry Pi 4,
> > >>>
> > >>> I don't think we need to modify the bvb clock.
> > >>>
> > >>>
> > >>> So I think it is better to update 'brcm,bcm2711-hdmi.yaml'
> > >>>
> > >>> instead of 'brcm,bcm2835-hdmi.yaml'.
> > >> You are correct please update only brcm,bcm2711-hdmi.yaml.
> > >>
> > >> My concern was that the function vc4_hdmi_encoder_pre_crtc_configure()
> > >> is called on a non-bcm2711 platform or on a Raspberry Pi 4 with an older
> > >> DTB. So making the BVB clock optional might be better?
> > > You are right, if use old dtb, we have a problem with the hdmi driver.
> > >
> > > So how about modifying it like this?
> > >
> > > @@ -1614,8 +1614,8 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
> > > *vc4_hdmi)
> > >
> > > vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
> > > if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
> > > - DRM_ERROR("Failed to get pixel bvb clock\n");
> > > - return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
> > > + DRM_WARN("Failed to get pixel bvb clock\n");
> > > + vc4_hdmi->pixel_bvb_clock = NULL;
> > > }
> >
> > i think the better solution would be devm_clk_get_optional(), which
> > return NULL in case the clock doesn't exist.
>
> It's not really optional though. BCM2711 will require it in order to run
> properly (as Hoegeun experienced), and the previous SoCs won't.
>
> If we use clk_get_optional and that the DT is missing the clock on the
> BCM2711, we will silently ignore it which doesn't sound great.
Am I missing something here? (I know I missed this earlier)
We're in vc5_hdmi_init_resources, which is inherently bcm2711 only.
bcm283x will go through vc4_hdmi_init_resources.
As long as vc4_hdmi_init_resources has left vc4_hdmi->pixel_bvb_clock
at NULL, then the clock framework will be happy to do a nop.
For BCM2711 an old DT would have issues, but, as Maxime has stated, no
binding or upstream DTB has been merged yet, so it can be made
mandatory.
Making it optional drops you back on whatever the firmware might have
set it to, which may be sufficient for some resolutions but not
others.
Dave
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/v3d: Remove set but not used variable
Hi
On Wed, 23 Sep 2020 at 08:53, Li Heng wrote:
>
> This addresses the following gcc warning with "make W=1":
>
> drivers/gpu/drm/v3d/v3d_drv.c:73:32: warning:
> ‘v3d_v3d_pm_ops’ defined but not used [-Wunused-const-variable=]
>
> Reported-by: Hulk Robot
> Signed-off-by: Li Heng
> ---
> drivers/gpu/drm/v3d/v3d_drv.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
> index 9f7c261..05140db 100644
> --- a/drivers/gpu/drm/v3d/v3d_drv.c
> +++ b/drivers/gpu/drm/v3d/v3d_drv.c
> @@ -70,10 +70,6 @@ static int v3d_runtime_resume(struct device *dev)
> }
> #endif
>
> -static const struct dev_pm_ops v3d_v3d_pm_ops = {
> - SET_RUNTIME_PM_OPS(v3d_runtime_suspend, v3d_runtime_resume, NULL)
> -};
> -
This looks to be the wrong approach, and I think a patch has got
dropped somewhere.
On our Raspberry Pi downstream vendor tree we have a patch [1] from
Eric that renames v3d_v3d_pm_ops to v3d_pm_ops (don't need the
duplicated suffix), and adds it to v3d_platform_driver. Why that never
made it through the mainline trees I don't know.
Eric: How good's your memory on this one?
Thanks
Dave
[1]
https://github.com/raspberrypi/linux/commit/fddfb26f6503835a3c6f7ca0175ce2260f60f67c
> static int v3d_get_param_ioctl(struct drm_device *dev, void *data,
>struct drm_file *file_priv)
> {
> --
> 2.7.4
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/vc4: crtc: Rework a bit the CRTC state code
Hi Maxime
On Wed, 23 Sep 2020 at 09:40, Maxime Ripard wrote:
>
> The current CRTC state reset hook in vc4 allocates a vc4_crtc_state
> structure as a drm_crtc_state, and relies on the fact that vc4_crtc_state
> embeds drm_crtc_state as its first member, and therefore can be safely
> casted.
s/casted/cast
> However, this is pretty fragile especially since there's no check for this
> in place, and we're going to need to access vc4_crtc_state member at reset
> so this looks like a good occasion to make it more robust.
>
> Signed-off-by: Maxime Ripard
> Tested-by: Dave Stevenson
Based on the issue I perceived with the previous patch, I'm happy. I
haven't thought about how the framework handles losing the state, but
that's not the driver's problem.
There is still an implicit assumption that drm_crtc_state is the first
member from the implementation of to_vc4_crtc_state in vc4_drv.h. To
make it even more robust that could be a container_of instead. I
haven't checked for any other places that make the assumption though.
Reviewed-by: Dave Stevenson
> ---
>
> Changes from v1:
> - new patch
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index a393f93390a2..7ef20adedee5 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -852,11 +852,18 @@ void vc4_crtc_destroy_state(struct drm_crtc *crtc,
>
> void vc4_crtc_reset(struct drm_crtc *crtc)
> {
> + struct vc4_crtc_state *vc4_crtc_state;
> +
> if (crtc->state)
> vc4_crtc_destroy_state(crtc, crtc->state);
> - crtc->state = kzalloc(sizeof(struct vc4_crtc_state), GFP_KERNEL);
> - if (crtc->state)
> - __drm_atomic_helper_crtc_reset(crtc, crtc->state);
> +
> + vc4_crtc_state = kzalloc(sizeof(*vc4_crtc_state), GFP_KERNEL);
> + if (!vc4_crtc_state) {
> + crtc->state = NULL;
> + return;
> + }
> +
> + __drm_atomic_helper_crtc_reset(crtc, _crtc_state->base);
> }
>
> static const struct drm_crtc_funcs vc4_crtc_funcs = {
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/vc4: crtc: Rework a bit the CRTC state code
On Fri, 25 Sep 2020 at 12:38, Maxime Ripard wrote: > > Hi Dave, > > On Wed, Sep 23, 2020 at 03:59:04PM +0100, Dave Stevenson wrote: > > Hi Maxime > > > > On Wed, 23 Sep 2020 at 09:40, Maxime Ripard wrote: > > > > > > The current CRTC state reset hook in vc4 allocates a vc4_crtc_state > > > structure as a drm_crtc_state, and relies on the fact that vc4_crtc_state > > > embeds drm_crtc_state as its first member, and therefore can be safely > > > casted. > > > > s/casted/cast > > > > > However, this is pretty fragile especially since there's no check for this > > > in place, and we're going to need to access vc4_crtc_state member at reset > > > so this looks like a good occasion to make it more robust. > > > > > > Signed-off-by: Maxime Ripard > > > Tested-by: Dave Stevenson > > > > Based on the issue I perceived with the previous patch, I'm happy. I > > haven't thought about how the framework handles losing the state, but > > that's not the driver's problem. > > > > There is still an implicit assumption that drm_crtc_state is the first > > member from the implementation of to_vc4_crtc_state in vc4_drv.h. To > > make it even more robust that could be a container_of instead. I > > haven't checked for any other places that make the assumption though. > > Good catch, I'll send another patch to fix it > > > Reviewed-by: Dave Stevenson > > Does it apply to the second patch as well? No. I got another interrupt before I'd refreshed my memory over what the second patch was doing and responding to it. I'll do that now (I don't think it changed much from v1) Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/vc4: crtc: Keep the previously assigned HVS FIFO
Hi Maxime
Sorry for the delay.
On Wed, 23 Sep 2020 at 09:40, Maxime Ripard wrote:
>
> The HVS FIFOs are currently assigned each time we have an atomic_check
> for all the enabled CRTCs.
>
> However, if we are running multiple outputs in parallel and we happen to
> disable the first (by index) CRTC, we end up changing the assigned FIFO
> of the second CRTC without disabling and reenabling the pixelvalve which
> ends up in a stall and eventually a VBLANK timeout.
>
> In order to fix this, we can create a special value for our assigned
> channel to mark it as disabled, and if our CRTC already had an assigned
> channel in its previous state, we keep on using it.
>
> Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically")
> Signed-off-by: Maxime Ripard
> Tested-by: Dave Stevenson
Reviewed-by: Dave Stevenson
I retested too and had triple output (HDMI-0, HDMI-1, and DPI) working
happily! Switching around resolutions on the HDMI outputs was working
fine. DPI was an Adafruit Kippah and 800x480 LCD, so no options on
resolution.
We may finally have this muxing nailed.
Dave
> ---
>
> Changes from v1:
> - Split away the crtc state reset refactoring
> - Fixed the checkpatch warnings
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 1 +
> drivers/gpu/drm/vc4/vc4_drv.h | 2 ++
> drivers/gpu/drm/vc4/vc4_kms.c | 22 --
> 3 files changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index 7ef20adedee5..482219fb4db2 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -863,6 +863,7 @@ void vc4_crtc_reset(struct drm_crtc *crtc)
> return;
> }
>
> + vc4_crtc_state->assigned_channel = VC4_HVS_CHANNEL_DISABLED;
> __drm_atomic_helper_crtc_reset(crtc, _crtc_state->base);
> }
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index 8c8d96b6289f..90b911fd2a7f 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -532,6 +532,8 @@ struct vc4_crtc_state {
> } margins;
> };
>
> +#define VC4_HVS_CHANNEL_DISABLED ((unsigned int)-1)
> +
> static inline struct vc4_crtc_state *
> to_vc4_crtc_state(struct drm_crtc_state *crtc_state)
> {
> diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> index 01fa60844695..149825ff5df8 100644
> --- a/drivers/gpu/drm/vc4/vc4_kms.c
> +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> @@ -616,7 +616,7 @@ static int
> vc4_atomic_check(struct drm_device *dev, struct drm_atomic_state *state)
> {
> unsigned long unassigned_channels = GENMASK(NUM_CHANNELS - 1, 0);
> - struct drm_crtc_state *crtc_state;
> + struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> struct drm_crtc *crtc;
> int i, ret;
>
> @@ -629,6 +629,8 @@ vc4_atomic_check(struct drm_device *dev, struct
> drm_atomic_state *state)
> * modified.
> */
> list_for_each_entry(crtc, >mode_config.crtc_list, head) {
> + struct drm_crtc_state *crtc_state;
> +
> if (!crtc->state->enable)
> continue;
>
> @@ -637,15 +639,23 @@ vc4_atomic_check(struct drm_device *dev, struct
> drm_atomic_state *state)
> return PTR_ERR(crtc_state);
> }
>
> - for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> - struct vc4_crtc_state *vc4_crtc_state =
> - to_vc4_crtc_state(crtc_state);
> + for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
> new_crtc_state, i) {
> + struct vc4_crtc_state *new_vc4_crtc_state =
> + to_vc4_crtc_state(new_crtc_state);
> struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
> unsigned int matching_channels;
>
> - if (!crtc_state->enable)
> + if (old_crtc_state->enable && !new_crtc_state->enable)
> + new_vc4_crtc_state->assigned_channel =
> VC4_HVS_CHANNEL_DISABLED;
> +
> + if (!new_crtc_state->enable)
> continue;
>
> + if (new_vc4_crtc_state->assigned_channel !=
> VC4_HVS_CHANNEL_DISABLED) {
> + unassigned_channels &=
> ~BIT(new_vc4_crtc_state->assigned_channel);
> + continue;
> + }
> +
> /*
> * The problem we have to solve here is that we have
> * up to 7 encoders, connecte
Re: [PATCH v3 032/105] drm/vc4: crtc: Enable and disable the PV in atomic_enable / disable
Hi Maxime and Eric On Tue, 2 Jun 2020 at 15:12, Maxime Ripard wrote: > > Hi Eric > > On Wed, May 27, 2020 at 09:54:44AM -0700, Eric Anholt wrote: > > On Wed, May 27, 2020 at 8:50 AM Maxime Ripard wrote: > > > > > > The VIDEN bit in the pixelvalve currently being used to enable or disable > > > the pixelvalve seems to not be enough in some situations, which whill end > > > up with the pixelvalve stalling. > > > > > > In such a case, even re-enabling VIDEN doesn't bring it back and we need > > > to > > > clear the FIFO. This can only be done if the pixelvalve is disabled > > > though. > > > > > > In order to overcome this, we can configure the pixelvalve during > > > mode_set_no_fb, but only enable it in atomic_enable and flush the FIFO > > > there, and in atomic_disable disable the pixelvalve again. > > > > What displays has this been tested with? Getting this sequencing > > right is so painful, and things like DSI are tricky to get to light > > up. > > That FIFO is between the HVS and the HDMI PVs, so this was obviously > tested against that. Dave also tested the DSI output IIRC, so we should > be covered here. DSI wasn't working on the first patch set that Maxime sent - I haven't tested this one as yet but will do so. DPI was working early on to both an Adafruit 800x480 DPI panel, and via a VGA666 as VGA. HDMI is obviously working. VEC is being ignored now. The clock structure is more restricted than earlier chips, so to get the required clocks for the VEC without using fractional divides it compromises the clock that other parts of the system can run at (IIRC including the ARM). That's why the VEC has to be explicitly enabled for the firmware to enable it as the only output. It's annoying, but that's just a restriction of the chip. Dave ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/vc4: kms: Assign a FIFO to enabled CRTCs instead of active
Hi Maxime
Thanks for the patch.
On Fri, 18 Sep 2020 at 15:59, Maxime Ripard wrote:
>
> The HVS has three FIFOs that can be assigned to a number of PixelValves
> through a mux.
>
> However, changing that FIFO requires that we disable and then enable the
> pixelvalve, so we want to assign FIFOs to all the enabled CRTCs, and not
> just the active ones.
>
> Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically")
> Signed-off-by: Maxime Ripard
Tested-by: Dave Stevenson
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_kms.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> index af3ee3dcdab6..01fa60844695 100644
> --- a/drivers/gpu/drm/vc4/vc4_kms.c
> +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> @@ -643,7 +643,7 @@ vc4_atomic_check(struct drm_device *dev, struct
> drm_atomic_state *state)
> struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
> unsigned int matching_channels;
>
> - if (!crtc_state->active)
> + if (!crtc_state->enable)
> continue;
>
> /*
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/vc4: crtc: Keep the previously assigned HVS FIFO
Hi Maxime
Thanks for the patch - it makes mode switching reliable for me! :-)
On Fri, 18 Sep 2020 at 15:59, Maxime Ripard wrote:
>
> The HVS FIFOs are currently assigned each time we have an atomic_check
> for all the enabled CRTCs.
>
> However, if we are running multiple outputs in parallel and we happen to
> disable the first (by index) CRTC, we end up changing the assigned FIFO
> of the second CRTC without disabling and reenabling the pixelvalve which
> ends up in a stall and eventually a VBLANK timeout.
>
> In order to fix this, we can create a special value for our assigned
> channel to mark it as disabled, and if our CRTC already had an assigned
> channel in its previous state, we keep on using it.
>
> Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically")
> Signed-off-by: Maxime Ripard
Tested-by: Dave Stevenson
Review comments below though.
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 13 ++---
> drivers/gpu/drm/vc4/vc4_drv.h | 1 +
> drivers/gpu/drm/vc4/vc4_kms.c | 21 +++--
> 3 files changed, 26 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index a393f93390a2..be754120faa8 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -852,11 +852,18 @@ void vc4_crtc_destroy_state(struct drm_crtc *crtc,
>
> void vc4_crtc_reset(struct drm_crtc *crtc)
> {
> + struct vc4_crtc_state *vc4_crtc_state;
> +
> if (crtc->state)
> vc4_crtc_destroy_state(crtc, crtc->state);
> - crtc->state = kzalloc(sizeof(struct vc4_crtc_state), GFP_KERNEL);
> - if (crtc->state)
> - __drm_atomic_helper_crtc_reset(crtc, crtc->state);
> +
> + vc4_crtc_state = kzalloc(sizeof(*vc4_crtc_state), GFP_KERNEL);
> + if (!vc4_crtc_state)
> + return;
This error path has me worried, but I may have missed it.
If crtc->state was set then it's been freed via
vc4_crtc_destroy_state. However I don't see anything that has reset
crtc->state to NULL.
If the new alloc fails then I believe we exit with crtc->state still
set to the old freed pointer.
The old code directly set crtc->state, so it got reset to NULL by the failure.
> +
> + vc4_crtc_state->assigned_channel = VC4_HVS_CHANNEL_DISABLED;
> + crtc->state = _crtc_state->base;
> + __drm_atomic_helper_crtc_reset(crtc, crtc->state);
> }
>
> static const struct drm_crtc_funcs vc4_crtc_funcs = {
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index 8c8d96b6289f..2b13f2126f13 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -531,6 +531,7 @@ struct vc4_crtc_state {
> unsigned int bottom;
> } margins;
> };
> +#define VC4_HVS_CHANNEL_DISABLED ((unsigned int) -1)
Checkpatch whinge on that
CHECK: No space is necessary after a cast
#55: FILE: drivers/gpu/drm/vc4/vc4_drv.h:539:
+#define VC4_HVS_CHANNEL_DISABLED ((unsigned int) -1)
CHECK: Please use a blank line after function/struct/union/enum declarations
#55: FILE: drivers/gpu/drm/vc4/vc4_drv.h:539:
};
+#define VC4_HVS_CHANNEL_DISABLED ((unsigned int) -1)
> static inline struct vc4_crtc_state *
> to_vc4_crtc_state(struct drm_crtc_state *crtc_state)
> diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> index 01fa60844695..f452dad50c22 100644
> --- a/drivers/gpu/drm/vc4/vc4_kms.c
> +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> @@ -616,7 +616,7 @@ static int
> vc4_atomic_check(struct drm_device *dev, struct drm_atomic_state *state)
> {
> unsigned long unassigned_channels = GENMASK(NUM_CHANNELS - 1, 0);
> - struct drm_crtc_state *crtc_state;
> + struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> struct drm_crtc *crtc;
> int i, ret;
>
> @@ -629,6 +629,7 @@ vc4_atomic_check(struct drm_device *dev, struct
> drm_atomic_state *state)
> * modified.
> */
> list_for_each_entry(crtc, >mode_config.crtc_list, head) {
> + struct drm_crtc_state *crtc_state;
Blank line between variables and code, or not in this subsystem?
Checkpatch hasn't complained to me here.
> if (!crtc->state->enable)
> continue;
>
> @@ -637,15 +638,23 @@ vc4_atomic_check(struct drm_device *dev, struct
> drm_atomic_state *state)
> return PTR_ERR(crtc_state);
> }
>
> - for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> - struct vc4_crtc_state *vc4_crtc_state =
> - to_vc4_crtc_state(crtc_state);
> +
Re: [PATCH] drm/vc4: hvs: Pull the state of all the CRTCs prior to PV muxing
Hi Maxime
On Thu, 17 Sep 2020 at 13:16, Maxime Ripard wrote:
>
> The vc4 display engine has a first controller called the HVS that will
> perform the composition of the planes. That HVS has 3 FIFOs and can
> therefore compose planes for up to three outputs. The timings part is
> generated through a component called the Pixel Valve, and the BCM2711 has 6
> of them.
>
> Thus, the HVS has some bits to control which FIFO gets output to which
> Pixel Valve. The current code supports that muxing by looking at all the
> CRTCs in a new DRM atomic state in atomic_check, and given the set of
> contraints that we have, assigns FIFOs to CRTCs or reject the mode
s/contraints/constraints
> entirely. The actual muxing will occur during atomic_commit.
>
> However, that doesn't work if only a fraction of the CRTCs' state is
> updated in that state, since it will ignore the CRTCs that are kept running
> unmodified, and will thus unassign its associated FIFO, and later disable
> it.
Yup, that would surely mess things up :)
> In order to make the code work as expected, let's pull the CRTC state of
> all the enabled CRTC in our atomic_check so that we can operate on all the
> running CRTCs, no matter whether they are affected by the new state or not.
>
> Cc: Hoegeun Kwon
> Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically")
> Signed-off-by: Maxime Ripard
Tested-by: Dave Stevenson
Reviewed-by: Dave Stevenson
Thanks
Dave
> ---
> drivers/gpu/drm/vc4/vc4_kms.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> index 16e233e1406e..af3ee3dcdab6 100644
> --- a/drivers/gpu/drm/vc4/vc4_kms.c
> +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> @@ -620,6 +620,23 @@ vc4_atomic_check(struct drm_device *dev, struct
> drm_atomic_state *state)
> struct drm_crtc *crtc;
> int i, ret;
>
> + /*
> +* Since the HVS FIFOs are shared across all the pixelvalves and
> +* the TXP (and thus all the CRTCs), we need to pull the current
> +* state of all the enabled CRTCs so that an update to a single
> +* CRTC still keeps the previous FIFOs enabled and assigned to
> +* the same CRTCs, instead of evaluating only the CRTC being
> +* modified.
> +*/
> + list_for_each_entry(crtc, >mode_config.crtc_list, head) {
> + if (!crtc->state->enable)
> + continue;
> +
> + crtc_state = drm_atomic_get_crtc_state(state, crtc);
> + if (IS_ERR(crtc_state))
> + return PTR_ERR(crtc_state);
> + }
> +
> for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> struct vc4_crtc_state *vc4_crtc_state =
> to_vc4_crtc_state(crtc_state);
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: hdmi: Add a name to the codec DAI component
Hi Maxime
On Wed, 8 Jul 2020 at 15:46, Maxime Ripard wrote:
>
> Since the components for a given device in ASoC are identified by their
> name, it makes sense to add one even though it's not strictly necessary.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 15a11cd4de25..a057db0d9baa 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -983,6 +983,7 @@ static const struct snd_soc_dapm_route
> vc4_hdmi_audio_routes[] = {
> };
>
> static const struct snd_soc_component_driver vc4_hdmi_audio_component_drv = {
> + .name = "vc4-hdmi-codec-dai-component",
> .controls = vc4_hdmi_audio_controls,
> .num_controls = ARRAY_SIZE(vc4_hdmi_audio_controls),
> .dapm_widgets = vc4_hdmi_audio_widgets,
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: Rework the structure convertion functions
s/convertion/conversion in subject line
On Wed, 28 Oct 2020 at 12:37, Maxime Ripard wrote:
>
> Most of the helpers to retrieve vc4 structures from the DRM base structures
> rely on the fact that the first member of the vc4 structure is the DRM one
> and just cast the pointers between them.
>
> However, this is pretty fragile especially since there's no check to make
> sure that the DRM structure is indeed at the offset 0 in the structure, so
> let's use container_of to make it more robust.
>
> Signed-off-by: Maxime Ripard
Otherwise
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_drv.h | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index 236dde0bb9a1..836fdca5e643 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -287,7 +287,7 @@ struct vc4_bo {
> static inline struct vc4_bo *
> to_vc4_bo(struct drm_gem_object *bo)
> {
> - return (struct vc4_bo *)bo;
> + return container_of(to_drm_gem_cma_obj(bo), struct vc4_bo, base);
> }
>
> struct vc4_fence {
> @@ -300,7 +300,7 @@ struct vc4_fence {
> static inline struct vc4_fence *
> to_vc4_fence(struct dma_fence *fence)
> {
> - return (struct vc4_fence *)fence;
> + return container_of(fence, struct vc4_fence, base);
> }
>
> struct vc4_seqno_cb {
> @@ -347,7 +347,7 @@ struct vc4_plane {
> static inline struct vc4_plane *
> to_vc4_plane(struct drm_plane *plane)
> {
> - return (struct vc4_plane *)plane;
> + return container_of(plane, struct vc4_plane, base);
> }
>
> enum vc4_scaling_mode {
> @@ -423,7 +423,7 @@ struct vc4_plane_state {
> static inline struct vc4_plane_state *
> to_vc4_plane_state(struct drm_plane_state *state)
> {
> - return (struct vc4_plane_state *)state;
> + return container_of(state, struct vc4_plane_state, base);
> }
>
> enum vc4_encoder_type {
> @@ -499,7 +499,7 @@ struct vc4_crtc {
> static inline struct vc4_crtc *
> to_vc4_crtc(struct drm_crtc *crtc)
> {
> - return (struct vc4_crtc *)crtc;
> + return container_of(crtc, struct vc4_crtc, base);
> }
>
> static inline const struct vc4_crtc_data *
> @@ -537,7 +537,7 @@ struct vc4_crtc_state {
> static inline struct vc4_crtc_state *
> to_vc4_crtc_state(struct drm_crtc_state *crtc_state)
> {
> - return (struct vc4_crtc_state *)crtc_state;
> + return container_of(crtc_state, struct vc4_crtc_state, base);
> }
>
> #define V3D_READ(offset) readl(vc4->v3d->regs + offset)
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: hdmi: Block odd horizontal timings
Hi Maxime
On Fri, 25 Sep 2020 at 14:00, Maxime Ripard wrote:
>
> The FIFO between the pixelvalve and the HDMI controller runs at 2 pixels
> per clock cycle, and cannot deal with odd timings.
>
> Let's reject any mode with such timings.
>
> Signed-off-by: Maxime Ripard
It's unsupported due to the architecture rather than broken.
I'd hope the compiler would convert "% 2" to "& 1" in these cases, but
it's not a critical performance path anyway.
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 12
> drivers/gpu/drm/vc4/vc4_hdmi.h | 3 +++
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 1c4dc774d56e..acfb4e235214 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -879,6 +879,11 @@ static int vc4_hdmi_encoder_atomic_check(struct
> drm_encoder *encoder,
> struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> unsigned long long pixel_rate = mode->clock * 1000;
>
> + if (vc4_hdmi->variant->broken_odd_h_timings &&
> + ((mode->hdisplay % 2) || (mode->hsync_start % 2) ||
> +(mode->hsync_end % 2) || (mode->htotal % 2)))
> + return -EINVAL;
> +
> if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> pixel_rate *= 2;
>
> @@ -901,6 +906,11 @@ vc4_hdmi_encoder_mode_valid(struct drm_encoder *encoder,
> {
> struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
>
> + if (vc4_hdmi->variant->broken_odd_h_timings &&
> + ((mode->hdisplay % 2) || (mode->hsync_start % 2) ||
> +(mode->hsync_end % 2) || (mode->htotal % 2)))
> + return MODE_H_ILLEGAL;
> +
> if ((mode->clock * 1000) > vc4_hdmi->variant->max_pixel_clock)
> return MODE_CLOCK_HIGH;
>
> @@ -1950,6 +1960,7 @@ static const struct vc4_hdmi_variant
> bcm2711_hdmi0_variant = {
> PHY_LANE_2,
> PHY_LANE_CK,
> },
> + .broken_odd_h_timings = true,
>
> .init_resources = vc5_hdmi_init_resources,
> .csc_setup = vc5_hdmi_csc_setup,
> @@ -1975,6 +1986,7 @@ static const struct vc4_hdmi_variant
> bcm2711_hdmi1_variant = {
> PHY_LANE_CK,
> PHY_LANE_2,
> },
> + .broken_odd_h_timings = true,
>
> .init_resources = vc5_hdmi_init_resources,
> .csc_setup = vc5_hdmi_csc_setup,
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index af45b0d81dec..40e51ece8efe 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -62,6 +62,9 @@ struct vc4_hdmi_variant {
> */
> enum vc4_hdmi_phy_channel phy_lane_mapping[4];
>
> + /* The BCM2711 cannot deal with odd horizontal pixel timings */
> + bool broken_odd_h_timings;
> +
> /* Callback to get the resources (memory region, interrupts,
> * clocks, etc) for that variant.
> */
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 60/78] drm/vc4: hdmi: Remove unused CEC_CLOCK_DIV define
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> The CEC_CLOCK_DIV define is not used anywhere in the driver, let's remove
> it.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 86e21de6c578..a01562a49bf0 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -55,7 +55,6 @@
>
> #define HSM_CLOCK_FREQ 163682864
> #define CEC_CLOCK_FREQ 4
> -#define CEC_CLOCK_DIV (HSM_CLOCK_FREQ / CEC_CLOCK_FREQ)
>
> static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
> {
> --
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 69/78] drm/vc4: hdmi: Remove register dumps in enable
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> The current code has some logic, disabled by default, to dump the register
> setup in the HDMI controller.
>
> However, since we're going to split those functions in multiple, shorter,
> functions that only make sense where they are called in sequence, keeping
> the register dump makes little sense.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 17 -
> 1 file changed, 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 0a9a323e03d8..4058985940e6 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -430,7 +430,6 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
> *encoder)
> struct drm_display_mode *mode = >crtc->state->adjusted_mode;
> struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> struct vc4_hdmi_encoder *vc4_encoder = to_vc4_hdmi_encoder(encoder);
> - bool debug_dump_regs = false;
> unsigned long pixel_rate, hsm_rate;
> int ret;
>
> @@ -489,14 +488,6 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
> *encoder)
> if (vc4_hdmi->variant->phy_init)
> vc4_hdmi->variant->phy_init(vc4_hdmi, mode);
>
> - if (debug_dump_regs) {
> - struct drm_printer p = drm_info_printer(_hdmi->pdev->dev);
> -
> - dev_info(_hdmi->pdev->dev, "HDMI regs before:\n");
> - drm_print_regset32(, _hdmi->hdmi_regset);
> - drm_print_regset32(, _hdmi->hd_regset);
> - }
> -
> HDMI_WRITE(HDMI_VID_CTL, 0);
>
> HDMI_WRITE(HDMI_SCHEDULER_CONTROL,
> @@ -522,14 +513,6 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
> *encoder)
>
> HDMI_WRITE(HDMI_FIFO_CTL, VC4_HDMI_FIFO_CTL_MASTER_SLAVE_N);
>
> - if (debug_dump_regs) {
> - struct drm_printer p = drm_info_printer(_hdmi->pdev->dev);
> -
> - dev_info(_hdmi->pdev->dev, "HDMI regs after:\n");
> - drm_print_regset32(, _hdmi->hdmi_regset);
> - drm_print_regset32(, _hdmi->hd_regset);
> - }
> -
> HDMI_WRITE(HDMI_VID_CTL,
>HDMI_READ(HDMI_VID_CTL) |
>VC4_HD_VID_CTL_ENABLE |
> --
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 68/78] drm/vc4: hdmi: Deal with multiple ALSA cards
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> The HDMI driver was registering a single ALSA card so far with the name
> vc4-hdmi.
>
> Obviously, this is not going to work anymore when will have multiple HDMI
s/will/we
> controllers since we will end up trying to register two files with the same
> name.
>
> Let's use the variant to avoid that name conflict.
>
> Signed-off-by: Maxime Ripard
With that change
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 3 ++-
> drivers/gpu/drm/vc4/vc4_hdmi.h | 3 +++
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 1b6f51849d6c..0a9a323e03d8 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -1044,7 +1044,7 @@ static int vc4_hdmi_audio_init(struct vc4_hdmi
> *vc4_hdmi)
>
> card->dai_link = dai_link;
> card->num_links = 1;
> - card->name = "vc4-hdmi";
> + card->name = vc4_hdmi->variant->card_name;
> card->dev = dev;
>
> /*
> @@ -1503,6 +1503,7 @@ static int vc4_hdmi_dev_remove(struct platform_device
> *pdev)
> static const struct vc4_hdmi_variant bcm2835_variant = {
> .encoder_type = VC4_ENCODER_TYPE_HDMI0,
> .debugfs_name = "hdmi_regs",
> + .card_name = "vc4-hdmi",
> .max_pixel_clock= 16200,
> .cec_available = true,
> .registers = vc4_hdmi_fields,
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index 4aea5ee8a91d..34138e0dd4a6 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -30,6 +30,9 @@ struct vc4_hdmi_variant {
> /* Encoder Type for that controller */
> enum vc4_encoder_type encoder_type;
>
> + /* ALSA card name */
> + const char *card_name;
> +
> /* Filename to expose the registers in debugfs */
> const char *debugfs_name;
>
> --
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 21/78] drm/vc4: crtc: Move PV dump to config_pv
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> Now that we only configure the PixelValve in vc4_crtc_config_pv, it doesn't
> really make much sense to dump its register content in its caller.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 26 --
> 1 file changed, 12 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index c2ab907611e3..181d3fd57bc7 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -290,6 +290,14 @@ static void vc4_crtc_config_pv(struct drm_crtc *crtc)
>vc4_encoder->type == VC4_ENCODER_TYPE_DSI1);
> u32 format = is_dsi ? PV_CONTROL_FORMAT_DSIV_24 :
> PV_CONTROL_FORMAT_24;
> u8 ppc = pv_data->pixels_per_clock;
> + bool debug_dump_regs = false;
> +
> + if (debug_dump_regs) {
> + struct drm_printer p = drm_info_printer(_crtc->pdev->dev);
> + dev_info(_crtc->pdev->dev, "CRTC %d regs before:\n",
> +drm_crtc_index(crtc));
> + drm_print_regset32(, _crtc->regset);
> + }
>
> vc4_crtc_pixelvalve_reset(crtc);
>
> @@ -359,30 +367,20 @@ static void vc4_crtc_config_pv(struct drm_crtc *crtc)
>PV_CONTROL_WAIT_HSTART |
>VC4_SET_FIELD(vc4_encoder->clock_select,
> PV_CONTROL_CLK_SELECT));
> -}
> -
> -static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)
> -{
> - struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
> - bool debug_dump_regs = false;
>
> if (debug_dump_regs) {
> struct drm_printer p = drm_info_printer(_crtc->pdev->dev);
> - dev_info(_crtc->pdev->dev, "CRTC %d regs before:\n",
> + dev_info(_crtc->pdev->dev, "CRTC %d regs after:\n",
> drm_crtc_index(crtc));
> drm_print_regset32(, _crtc->regset);
> }
> +}
>
> +static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)
> +{
> vc4_crtc_config_pv(crtc);
>
> vc4_hvs_mode_set_nofb(crtc);
> -
> - if (debug_dump_regs) {
> - struct drm_printer p = drm_info_printer(_crtc->pdev->dev);
> - dev_info(_crtc->pdev->dev, "CRTC %d regs after:\n",
> -drm_crtc_index(crtc));
> - drm_print_regset32(, _crtc->regset);
> - }
> }
>
> static void require_hvs_enabled(struct drm_device *dev)
> --
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 40/78] drm/vc4: hdmi: rework connectors and encoders
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> the vc4_hdmi driver has some custom structures to hold the data it needs to
> associate with the drm_encoder and drm_connector structures.
>
> However, it allocates them separately from the vc4_hdmi structure which
> makes it more complicated than it needs to be.
>
> Move those structures to be contained by vc4_hdmi and update the code
> accordingly.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 87 ---
> drivers/gpu/drm/vc4/vc4_hdmi.h | 64 +-
> 2 files changed, 72 insertions(+), 79 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index db79e0d88625..1e2214f24ed7 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -191,20 +191,15 @@ static const struct drm_connector_helper_funcs
> vc4_hdmi_connector_helper_funcs =
> .get_modes = vc4_hdmi_connector_get_modes,
> };
>
> -static struct drm_connector *vc4_hdmi_connector_init(struct drm_device *dev,
> -struct drm_encoder
> *encoder,
> -struct i2c_adapter *ddc)
> +static int vc4_hdmi_connector_init(struct drm_device *dev,
> + struct vc4_hdmi *vc4_hdmi,
> + struct i2c_adapter *ddc)
> {
> - struct drm_connector *connector;
> - struct vc4_hdmi_connector *hdmi_connector;
> + struct vc4_hdmi_connector *hdmi_connector = _hdmi->connector;
> + struct drm_connector *connector = _connector->base;
> + struct drm_encoder *encoder = _hdmi->encoder.base.base;
> int ret;
>
> - hdmi_connector = devm_kzalloc(dev->dev, sizeof(*hdmi_connector),
> - GFP_KERNEL);
> - if (!hdmi_connector)
> - return ERR_PTR(-ENOMEM);
> - connector = _connector->base;
> -
> hdmi_connector->encoder = encoder;
>
> drm_connector_init_with_ddc(dev, connector,
> @@ -216,7 +211,7 @@ static struct drm_connector
> *vc4_hdmi_connector_init(struct drm_device *dev,
> /* Create and attach TV margin props to this connector. */
> ret = drm_mode_create_tv_margin_properties(dev);
> if (ret)
> - return ERR_PTR(ret);
> + return ret;
>
> drm_connector_attach_tv_margin_properties(connector);
>
> @@ -228,7 +223,7 @@ static struct drm_connector
> *vc4_hdmi_connector_init(struct drm_device *dev,
>
> drm_connector_attach_encoder(connector, encoder);
>
> - return connector;
> + return 0;
> }
>
> static int vc4_hdmi_stop_packet(struct drm_encoder *encoder,
> @@ -298,21 +293,22 @@ static void vc4_hdmi_set_avi_infoframe(struct
> drm_encoder *encoder)
> struct vc4_hdmi_encoder *vc4_encoder = to_vc4_hdmi_encoder(encoder);
> struct vc4_dev *vc4 = encoder->dev->dev_private;
> struct vc4_hdmi *hdmi = vc4->hdmi;
> - struct drm_connector_state *cstate = hdmi->connector->state;
> + struct drm_connector *connector = >connector.base;
> + struct drm_connector_state *cstate = connector->state;
> struct drm_crtc *crtc = encoder->crtc;
> const struct drm_display_mode *mode = >state->adjusted_mode;
> union hdmi_infoframe frame;
> int ret;
>
> ret = drm_hdmi_avi_infoframe_from_display_mode(,
> - hdmi->connector, mode);
> + connector, mode);
> if (ret < 0) {
> DRM_ERROR("couldn't fill AVI infoframe\n");
> return;
> }
>
> drm_hdmi_avi_infoframe_quant_range(,
> - hdmi->connector, mode,
> + connector, mode,
>vc4_encoder->limited_rgb_range ?
>HDMI_QUANTIZATION_RANGE_LIMITED :
>HDMI_QUANTIZATION_RANGE_FULL);
> @@ -628,7 +624,8 @@ static const struct drm_encoder_helper_funcs
> vc4_hdmi_encoder_helper_funcs = {
> /* HDMI audio codec callbacks */
> static void vc4_hdmi_audio_set_mai_clock(struct vc4_hdmi *hdmi)
> {
> - struct drm_device *drm = hdmi->encoder->dev;
> + struct drm_encoder *encoder = >encoder.base.base;
> + struct drm_device *drm = enco
Re: [PATCH v4 57/78] drm/vc4: hdmi: Deal with multiple debugfs files
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> The HDMI driver was registering a single debugfs file so far with the name
> hdmi_regs.
>
> Obviously, this is not going to work anymore when will have multiple HDMI
> controllers since we will end up trying to register two files with the same
> name.
>
> Let's use the variant to avoid that name conflict.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 5 -
> drivers/gpu/drm/vc4/vc4_hdmi.h | 3 +++
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index c50241170d7e..ef51eedaf75a 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -1370,7 +1370,9 @@ static int vc4_hdmi_bind(struct device *dev, struct
> device *master, void *data)
> if (ret)
> goto err_destroy_encoder;
>
> - vc4_debugfs_add_file(drm, "hdmi_regs", vc4_hdmi_debugfs_regs,
> vc4_hdmi);
> + vc4_debugfs_add_file(drm, variant->debugfs_name,
> +vc4_hdmi_debugfs_regs,
> +vc4_hdmi);
>
> return 0;
>
> @@ -1448,6 +1450,7 @@ static int vc4_hdmi_dev_remove(struct platform_device
> *pdev)
>
> static const struct vc4_hdmi_variant bcm2835_variant = {
> .encoder_type = VC4_ENCODER_TYPE_HDMI0,
> + .debugfs_name = "hdmi_regs",
> .registers = vc4_hdmi_fields,
> .num_registers = ARRAY_SIZE(vc4_hdmi_fields),
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index 0d529db4b3ab..794216f3228d 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -30,6 +30,9 @@ struct vc4_hdmi_variant {
> /* Encoder Type for that controller */
> enum vc4_encoder_type encoder_type;
>
> + /* Filename to expose the registers in debugfs */
> + const char *debugfs_name;
> +
> /* List of the registers available on that variant */
> const struct vc4_hdmi_register *registers;
>
> --
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 11/78] drm/vc4: crtc: Use local chan variable
Hi Maxime On Wed, 8 Jul 2020 at 18:42, Maxime Ripard wrote: > > The vc4_crtc_handle_page_flip already has a local variable holding the > value of vc4_crtc->channel, so let's use it instead. > > Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson > --- > drivers/gpu/drm/vc4/vc4_crtc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c > index d3126fe04d9a..cdeaa0cd981f 100644 > --- a/drivers/gpu/drm/vc4/vc4_crtc.c > +++ b/drivers/gpu/drm/vc4/vc4_crtc.c > @@ -533,7 +533,7 @@ static void vc4_crtc_handle_page_flip(struct vc4_crtc > *vc4_crtc) > * the CRTC and encoder already reconfigured, leading to > * underruns. This can be seen when reconfiguring the CRTC. > */ > - vc4_hvs_unmask_underrun(dev, vc4_crtc->channel); > + vc4_hvs_unmask_underrun(dev, chan); > } > spin_unlock_irqrestore(>event_lock, flags); > } > -- > git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 12/78] drm/vc4: crtc: Enable and disable the PV in atomic_enable / disable
Hi Maxime On Wed, 8 Jul 2020 at 18:42, Maxime Ripard wrote: > > The VIDEN bit in the pixelvalve currently being used to enable or disable > the pixelvalve seems to not be enough in some situations, which whill end > up with the pixelvalve stalling. > > In such a case, even re-enabling VIDEN doesn't bring it back and we need to > clear the FIFO. This can only be done if the pixelvalve is disabled though. > > In order to overcome this, we can configure the pixelvalve during > mode_set_no_fb, but only enable it in atomic_enable and flush the FIFO > there, and in atomic_disable disable the pixelvalve again. Very minor nitpick: the configure is in vc4_crtc_config_pv, but that is called from mode_set_no_fb. The comment is correct from a DRM overview perspective, but not from the actual code. Describing the DRM call is probably the better approach, but it looks odd when compared to the code. > Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson > --- > drivers/gpu/drm/vc4/vc4_crtc.c | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c > index cdeaa0cd981f..fe2e5675aed4 100644 > --- a/drivers/gpu/drm/vc4/vc4_crtc.c > +++ b/drivers/gpu/drm/vc4/vc4_crtc.c > @@ -332,9 +332,7 @@ static void vc4_crtc_config_pv(struct drm_crtc *crtc) >PV_CONTROL_TRIGGER_UNDERFLOW | >PV_CONTROL_WAIT_HSTART | >VC4_SET_FIELD(vc4_encoder->clock_select, > -PV_CONTROL_CLK_SELECT) | > - PV_CONTROL_FIFO_CLR | > - PV_CONTROL_EN); > +PV_CONTROL_CLK_SELECT)); > } > > static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc) > @@ -386,6 +384,8 @@ static void vc4_crtc_atomic_disable(struct drm_crtc *crtc, > ret = wait_for(!(CRTC_READ(PV_V_CONTROL) & PV_VCONTROL_VIDEN), 1); > WARN_ONCE(ret, "Timeout waiting for !PV_VCONTROL_VIDEN\n"); > > + CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) & ~PV_CONTROL_EN); > + > vc4_hvs_atomic_disable(crtc, old_state); > > /* > @@ -410,6 +410,10 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc, > > require_hvs_enabled(dev); > > + /* Reset the PV fifo. */ > + CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) | > + PV_CONTROL_FIFO_CLR | PV_CONTROL_EN); > + > /* Enable vblank irq handling before crtc is started otherwise > * drm_crtc_get_vblank() fails in vc4_crtc_update_dlist(). > */ > -- > git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 24/78] drm/vc4: hvs: Make sure our channel is reset
Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > In order to clear our intermediate FIFOs that might end up with a stale > pixel, let's make sure our FIFO channel is reset everytime our channel is > setup. Minor nit pick: s/everytime/every time > Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson > --- > drivers/gpu/drm/vc4/vc4_hvs.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c > index c7de77afbf0a..64b9d72471ef 100644 > --- a/drivers/gpu/drm/vc4/vc4_hvs.c > +++ b/drivers/gpu/drm/vc4/vc4_hvs.c > @@ -205,6 +205,10 @@ static int vc4_hvs_init_channel(struct vc4_dev *vc4, > struct drm_crtc *crtc, > u32 dispbkgndx; > u32 dispctrl; > > + HVS_WRITE(SCALER_DISPCTRLX(chan), 0); > + HVS_WRITE(SCALER_DISPCTRLX(chan), SCALER_DISPCTRLX_RESET); > + HVS_WRITE(SCALER_DISPCTRLX(chan), 0); > + > /* Turn on the scaler, which will wait for vstart to start > * compositing. > * When feeding the transposer, we should operate in oneshot > -- > git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 47/78] drm/vc4: hdmi: Retrieve the vc4_hdmi at unbind using our device
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> The unbind function needs to retrieve a vc4_hdmi structure pointer through
> the struct device that we're given since we want to support multiple HDMI
> controllers.
>
> However, our optional ASoC support doesn't make that trivial since it will
> overwrite the device drvdata if we use it, but obviously won't if we don't
> use it.
>
> Let's make sure the fields are at the proper offset to be able to cast
> between the snd_soc_card structure and the vc4_hdmi structure
> transparently so we can support both cases.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 24 +++-
> drivers/gpu/drm/vc4/vc4_hdmi.h | 4 ++--
> 2 files changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 09b297a1b39d..7cd1394c10fa 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -1200,6 +1200,7 @@ static int vc4_hdmi_bind(struct device *dev, struct
> device *master, void *data)
> if (!vc4_hdmi)
> return -ENOMEM;
>
> + dev_set_drvdata(dev, vc4_hdmi);
> encoder = _hdmi->encoder.base.base;
> vc4_hdmi->encoder.base.type = VC4_ENCODER_TYPE_HDMI0;
> vc4_hdmi->pdev = pdev;
> @@ -1362,7 +1363,28 @@ static void vc4_hdmi_unbind(struct device *dev, struct
> device *master,
> {
> struct drm_device *drm = dev_get_drvdata(master);
> struct vc4_dev *vc4 = drm->dev_private;
> - struct vc4_hdmi *vc4_hdmi = vc4->hdmi;
> + struct vc4_hdmi *vc4_hdmi;
> +
> + /*
> +* ASoC makes it a bit hard to retrieve a pointer to the
> +* vc4_hdmi structure. Registering the card will overwrite our
> +* device drvdata with a pointer to the snd_soc_card structure,
> +* which can then be used to retrieve whatever drvdata we want
> +* to associate.
> +*
> +* However, that doesn't fly in the case where we wouldn't
> +* register an ASoC card (because of an old DT that is missing
> +* the dmas properties for example), then the card isn't
> +* registered and the device drvdata wouldn't be set.
> +*
> +* We can deal with both cases by making sure a snd_soc_card
> +* pointer and a vc4_hdmi structure are pointing to the same
> +* memory address, so we can treat them indistinctly without any
> +* issue.
> +*/
> + BUILD_BUG_ON(offsetof(struct vc4_hdmi_audio, card) != 0);
> + BUILD_BUG_ON(offsetof(struct vc4_hdmi, audio) != 0);
> + vc4_hdmi = dev_get_drvdata(dev);
>
> cec_unregister_adapter(vc4_hdmi->cec_adap);
> vc4_hdmi_connector_destroy(_hdmi->connector.base);
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index 749a807cd1f3..d43462789450 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -53,13 +53,13 @@ struct vc4_hdmi_audio {
>
> /* General HDMI hardware state. */
> struct vc4_hdmi {
> + struct vc4_hdmi_audio audio;
> +
> struct platform_device *pdev;
>
> struct vc4_hdmi_encoder encoder;
> struct vc4_hdmi_connector connector;
>
> - struct vc4_hdmi_audio audio;
> -
> struct i2c_adapter *ddc;
> void __iomem *hdmicore_regs;
> void __iomem *hd_regs;
> --
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 53/78] drm/vc4: hdmi: Add PHY init and disable function
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> The HDMI PHY in the BCM2711 HDMI controller is significantly more
> complicated to setup than in the older BCM283x SoCs.
>
> Let's add hooks to enable and disable the PHY.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/Makefile | 1 +
> drivers/gpu/drm/vc4/vc4_hdmi.c | 14 +++---
> drivers/gpu/drm/vc4/vc4_hdmi.h | 13 +
> drivers/gpu/drm/vc4/vc4_hdmi_phy.c | 25 +
> 4 files changed, 46 insertions(+), 7 deletions(-)
> create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi_phy.c
>
> diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
> index b303703bc7f3..d0163e18e9ca 100644
> --- a/drivers/gpu/drm/vc4/Makefile
> +++ b/drivers/gpu/drm/vc4/Makefile
> @@ -12,6 +12,7 @@ vc4-y := \
> vc4_kms.o \
> vc4_gem.o \
> vc4_hdmi.o \
> + vc4_hdmi_phy.o \
> vc4_vec.o \
> vc4_hvs.o \
> vc4_irq.o \
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 80bc3dd9d4a8..068041145d1c 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -321,7 +321,9 @@ static void vc4_hdmi_encoder_disable(struct drm_encoder
> *encoder)
>
> HDMI_WRITE(HDMI_RAM_PACKET_CONFIG, 0);
>
> - HDMI_WRITE(HDMI_TX_PHY_RESET_CTL, 0xf << 16);
> + if (vc4_hdmi->variant->phy_disable)
> + vc4_hdmi->variant->phy_disable(vc4_hdmi);
> +
> HDMI_WRITE(HDMI_VID_CTL,
>HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
>
> @@ -381,12 +383,8 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
> *encoder)
> if (vc4_hdmi->variant->reset)
> vc4_hdmi->variant->reset(vc4_hdmi);
>
> - /* PHY should be in reset, like
> -* vc4_hdmi_encoder_disable() does.
> -*/
> - HDMI_WRITE(HDMI_TX_PHY_RESET_CTL, 0xf << 16);
> -
> - HDMI_WRITE(HDMI_TX_PHY_RESET_CTL, 0);
> + if (vc4_hdmi->variant->phy_init)
> + vc4_hdmi->variant->phy_init(vc4_hdmi, mode);
>
> if (debug_dump_regs) {
> struct drm_printer p = drm_info_printer(_hdmi->pdev->dev);
> @@ -1433,6 +1431,8 @@ static const struct vc4_hdmi_variant bcm2835_variant = {
>
> .init_resources = vc4_hdmi_init_resources,
> .reset = vc4_hdmi_reset,
> + .phy_init = vc4_hdmi_phy_init,
> + .phy_disable= vc4_hdmi_phy_disable,
> };
>
> static const struct of_device_id vc4_hdmi_dt_match[] = {
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index 17a30589f39c..32c80161c786 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -21,6 +21,8 @@ to_vc4_hdmi_encoder(struct drm_encoder *encoder)
> return container_of(encoder, struct vc4_hdmi_encoder, base.base);
> }
>
> +struct drm_display_mode;
> +
> struct vc4_hdmi;
> struct vc4_hdmi_register;
>
> @@ -38,6 +40,13 @@ struct vc4_hdmi_variant {
>
> /* Callback to reset the HDMI block */
> void (*reset)(struct vc4_hdmi *vc4_hdmi);
> +
> + /* Callback to initialize the PHY according to the mode */
> + void (*phy_init)(struct vc4_hdmi *vc4_hdmi,
> +struct drm_display_mode *mode);
> +
> + /* Callback to disable the PHY */
> + void (*phy_disable)(struct vc4_hdmi *vc4_hdmi);
> };
>
> /* HDMI audio information */
> @@ -95,4 +104,8 @@ encoder_to_vc4_hdmi(struct drm_encoder *encoder)
> return container_of(_encoder, struct vc4_hdmi, encoder);
> }
>
> +void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
> + struct drm_display_mode *mode);
> +void vc4_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
> +
> #endif /* _VC4_HDMI_H_ */
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
> b/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
> new file mode 100644
> index ..5a1746877bb5
> --- /dev/null
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
> @@ -0,0 +1,25 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2015 Broadcom
> + * Copyright (c) 2014 The Linux Foundation. All rights reserved.
> + * Copyright (C) 2013 Red Hat
> + * Author: Rob Clark
> + */
> +
> +#include "vc4_hdmi.h"
> +#include "vc4_hdmi_regs.h"
> +
> +void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi, struct drm_display_mode
> *mode)
> +{
> + /* PHY should be in reset, like
Re: [PATCH v4 55/78] drm/vc4: hdmi: Add a CSC setup callback
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> Similarly to the previous patches, the CSC setup is slightly different in
> the BCM2711 than in the previous generations. Let's add a callback for it.
We've gained the set_timings callback in this patch as well as
csc_setup. Was that an accidental squash as we had them as independent
commits in v1.
Dave
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 142 +++---
> drivers/gpu/drm/vc4/vc4_hdmi.h | 7 ++-
> 2 files changed, 89 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 19897d6525ac..a50220bfd5dd 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -334,12 +334,44 @@ static void vc4_hdmi_encoder_disable(struct drm_encoder
> *encoder)
> DRM_ERROR("Failed to release power domain: %d\n", ret);
> }
>
> -static void vc4_hdmi_encoder_enable(struct drm_encoder *encoder)
> +static void vc4_hdmi_csc_setup(struct vc4_hdmi *vc4_hdmi, bool enable)
> +{
> + u32 csc_ctl;
> +
> + csc_ctl = VC4_SET_FIELD(VC4_HD_CSC_CTL_ORDER_BGR,
> + VC4_HD_CSC_CTL_ORDER);
> +
> + if (enable) {
> + /* CEA VICs other than #1 requre limited range RGB
> +* output unless overridden by an AVI infoframe.
> +* Apply a colorspace conversion to squash 0-255 down
> +* to 16-235. The matrix here is:
> +*
> +* [ 0 0 0.8594 16]
> +* [ 0 0.8594 0 16]
> +* [ 0.8594 0 0 16]
> +* [ 0 0 0 1]
> +*/
> + csc_ctl |= VC4_HD_CSC_CTL_ENABLE;
> + csc_ctl |= VC4_HD_CSC_CTL_RGB2YCC;
> + csc_ctl |= VC4_SET_FIELD(VC4_HD_CSC_CTL_MODE_CUSTOM,
> +VC4_HD_CSC_CTL_MODE);
> +
> + HDMI_WRITE(HDMI_CSC_12_11, (0x000 << 16) | 0x000);
> + HDMI_WRITE(HDMI_CSC_14_13, (0x100 << 16) | 0x6e0);
> + HDMI_WRITE(HDMI_CSC_22_21, (0x6e0 << 16) | 0x000);
> + HDMI_WRITE(HDMI_CSC_24_23, (0x100 << 16) | 0x000);
> + HDMI_WRITE(HDMI_CSC_32_31, (0x000 << 16) | 0x6e0);
> + HDMI_WRITE(HDMI_CSC_34_33, (0x100 << 16) | 0x000);
> + }
> +
> + /* The RGB order applies even when CSC is disabled. */
> + HDMI_WRITE(HDMI_CSC_CTL, csc_ctl);
> +}
> +
> +static void vc4_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
> +struct drm_display_mode *mode)
> {
> - struct drm_display_mode *mode = >crtc->state->adjusted_mode;
> - struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> - struct vc4_hdmi_encoder *vc4_encoder = _hdmi->encoder;
> - bool debug_dump_regs = false;
> bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
> bool vsync_pos = mode->flags & DRM_MODE_FLAG_PVSYNC;
> bool interlaced = mode->flags & DRM_MODE_FLAG_INTERLACE;
> @@ -357,7 +389,41 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
> *encoder)
> mode->crtc_vsync_end -
> interlaced,
> VC4_HDMI_VERTB_VBP));
> - u32 csc_ctl;
> +
> + HDMI_WRITE(HDMI_HORZA,
> + (vsync_pos ? VC4_HDMI_HORZA_VPOS : 0) |
> + (hsync_pos ? VC4_HDMI_HORZA_HPOS : 0) |
> + VC4_SET_FIELD(mode->hdisplay * pixel_rep,
> +VC4_HDMI_HORZA_HAP));
> +
> + HDMI_WRITE(HDMI_HORZB,
> + VC4_SET_FIELD((mode->htotal -
> + mode->hsync_end) * pixel_rep,
> +VC4_HDMI_HORZB_HBP) |
> + VC4_SET_FIELD((mode->hsync_end -
> + mode->hsync_start) * pixel_rep,
> +VC4_HDMI_HORZB_HSP) |
> + VC4_SET_FIELD((mode->hsync_start -
> + mode->hdisplay) * pixel_rep,
> +VC4_HDMI_HORZB_HFP));
> +
> + HDMI_WRITE(HDMI_VERTA0, verta);
> + HDMI_WRITE(HDMI_VERTA1, verta);
> +
> + HDMI_WRITE(HDMI_VERTB0, vertb_even);
> + HDMI_WRITE(HDMI_VERTB1, vertb);
> +
> + HDMI_WRITE(HDMI_VID_CTL,
> + (vsync_pos ? 0 : VC4_HD_VID_CTL_VSYNC_LOW) |
> + (hsync_pos ? 0 : VC4_HD_VID_CTL_HSYNC_LOW));
> +}
> +
> +static void vc4_hdmi_encoder_enable(struct drm_encoder *encoder)
> +{
> + struct drm_display_mode *mode = >crtc->state->adjusted_mode;
> + struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> + struct vc4_hdmi_encoder *vc4_encoder = to_vc4_hdmi_encoder(encoder);
> + bool debug_dump_regs = false;
> int ret;
>
Re: [PATCH v4 56/78] drm/vc4: hdmi: Store the encoder type in the variant structure
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> The vc4 CRTC will use the encoder type to control its output clock
> muxing. However, this will be different from HDMI0 to HDMI1, so let's
> store our type in the variant structure so that we can support multiple
> controllers later on.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 3 ++-
> drivers/gpu/drm/vc4/vc4_hdmi.h | 3 +++
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index a50220bfd5dd..c50241170d7e 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -1268,7 +1268,7 @@ static int vc4_hdmi_bind(struct device *dev, struct
> device *master, void *data)
>
> dev_set_drvdata(dev, vc4_hdmi);
> encoder = _hdmi->encoder.base.base;
> - vc4_hdmi->encoder.base.type = VC4_ENCODER_TYPE_HDMI0;
> + vc4_hdmi->encoder.base.type = variant->encoder_type;
> vc4_hdmi->pdev = pdev;
> vc4_hdmi->variant = variant;
>
> @@ -1447,6 +1447,7 @@ static int vc4_hdmi_dev_remove(struct platform_device
> *pdev)
> }
>
> static const struct vc4_hdmi_variant bcm2835_variant = {
> + .encoder_type = VC4_ENCODER_TYPE_HDMI0,
> .registers = vc4_hdmi_fields,
> .num_registers = ARRAY_SIZE(vc4_hdmi_fields),
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index 0c32dc46d289..0d529db4b3ab 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -27,6 +27,9 @@ struct vc4_hdmi;
> struct vc4_hdmi_register;
>
> struct vc4_hdmi_variant {
> + /* Encoder Type for that controller */
> + enum vc4_encoder_type encoder_type;
> +
> /* List of the registers available on that variant */
> const struct vc4_hdmi_register *registers;
>
> --
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 61/78] drm/vc4: hdmi: Rename drm_encoder pointer in mode_valid
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> The mode_valid hook on the encoder uses a pointer to a drm_encoder called
> crtc, which is pretty confusing. Let's rename it to encoder to make it
> clear what it is.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index a01562a49bf0..17797b14cde4 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -556,7 +556,7 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
> *encoder)
> }
>
> static enum drm_mode_status
> -vc4_hdmi_encoder_mode_valid(struct drm_encoder *crtc,
> +vc4_hdmi_encoder_mode_valid(struct drm_encoder *encoder,
> const struct drm_display_mode *mode)
> {
> /*
> --
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 62/78] drm/vc4: hdmi: Adjust HSM clock rate depending on pixel rate
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> The HSM clock needs to be setup at around 101% of the pixel rate. This
> was done previously by setting the clock rate to 163.7MHz at probe time and
> only check in mode_valid whether the mode pixel clock was under the pixel
> clock +1% or not.
>
> However, with 4k we need to change that frequency to a higher frequency
> than 163.7MHz, and yet want to have the lowest clock as possible to have a
> decent power saving.
>
> Let's change that logic a bit by setting the clock rate of the HSM clock
> to the pixel rate at encoder_enable time. This would work for the
> BCM2711 that support 4k resolutions and has a clock that can provide it,
> but we still have to take care of a 4k panel plugged on a BCM283x SoCs
> that wouldn't be able to use those modes, so let's define the limit in
> the variant.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 79 ---
> drivers/gpu/drm/vc4/vc4_hdmi.h | 3 +-
> 2 files changed, 41 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 17797b14cde4..9f30fab744f2 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -53,7 +53,6 @@
> #include "vc4_hdmi_regs.h"
> #include "vc4_regs.h"
>
> -#define HSM_CLOCK_FREQ 163682864
> #define CEC_CLOCK_FREQ 4
>
> static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
> @@ -326,6 +325,7 @@ static void vc4_hdmi_encoder_disable(struct drm_encoder
> *encoder)
> HDMI_WRITE(HDMI_VID_CTL,
>HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
>
> + clk_disable_unprepare(vc4_hdmi->hsm_clock);
> clk_disable_unprepare(vc4_hdmi->pixel_clock);
>
> ret = pm_runtime_put(_hdmi->pdev->dev);
> @@ -423,6 +423,7 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
> *encoder)
> struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> struct vc4_hdmi_encoder *vc4_encoder = to_vc4_hdmi_encoder(encoder);
> bool debug_dump_regs = false;
> + unsigned long pixel_rate, hsm_rate;
> int ret;
>
> ret = pm_runtime_get_sync(_hdmi->pdev->dev);
> @@ -431,9 +432,8 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
> *encoder)
> return;
> }
>
> - ret = clk_set_rate(vc4_hdmi->pixel_clock,
> - mode->clock * 1000 *
> - ((mode->flags & DRM_MODE_FLAG_DBLCLK) ? 2 : 1));
> + pixel_rate = mode->clock * 1000 * ((mode->flags &
> DRM_MODE_FLAG_DBLCLK) ? 2 : 1);
> + ret = clk_set_rate(vc4_hdmi->pixel_clock, pixel_rate);
> if (ret) {
> DRM_ERROR("Failed to set pixel clock rate: %d\n", ret);
> return;
> @@ -445,6 +445,36 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
> *encoder)
> return;
> }
>
> + /*
> +* As stated in RPi's vc4 firmware "HDMI state machine (HSM) clock
> must
> +* be faster than pixel clock, infinitesimally faster, tested in
> +* simulation. Otherwise, exact value is unimportant for HDMI
> +* operation." This conflicts with bcm2835's vc4 documentation, which
> +* states HSM's clock has to be at least 108% of the pixel clock.
> +*
> +* Real life tests reveal that vc4's firmware statement holds up, and
> +* users are able to use pixel clocks closer to HSM's, namely for
> +* 1920x1200@60Hz. So it was decided to have leave a 1% margin between
> +* both clocks. Which, for RPi0-3 implies a maximum pixel clock of
> +* 162MHz.
> +*
> +* Additionally, the AXI clock needs to be at least 25% of
> +* pixel clock, but HSM ends up being the limiting factor.
> +*/
> + hsm_rate = max_t(unsigned long, 12000, (pixel_rate / 100) * 101);
> + ret = clk_set_rate(vc4_hdmi->hsm_clock, hsm_rate);
> + if (ret) {
> + DRM_ERROR("Failed to set HSM clock rate: %d\n", ret);
> + return;
> + }
> +
> + ret = clk_prepare_enable(vc4_hdmi->hsm_clock);
> + if (ret) {
> + DRM_ERROR("Failed to turn on HSM clock: %d\n", ret);
> + clk_disable_unprepare(vc4_hdmi->pixel_clock);
> + return;
> + }
> +
> if (vc4_hdmi->variant->reset)
> vc4_hdmi->variant->re
Re: [PATCH v4 63/78] drm/vc4: hdmi: Use clk_set_min_rate instead
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> The HSM clock needs to be running at 101% the pixel clock of the HDMI
> controller, however it's shared between the two HDMI controllers, which
> means that if the resolutions are different between the two HDMI
> controllers, and the lowest resolution is on the second (in enable order)
> controller, the first HDMI controller will end up with a smaller than
> expected clock rate.
>
> Since we don't really need an exact frequency there, we can simply change
> the minimum rate we expect instead.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 9f30fab744f2..d99188c90ff9 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -462,7 +462,7 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
> *encoder)
> * pixel clock, but HSM ends up being the limiting factor.
> */
> hsm_rate = max_t(unsigned long, 12000, (pixel_rate / 100) * 101);
> - ret = clk_set_rate(vc4_hdmi->hsm_clock, hsm_rate);
> + ret = clk_set_min_rate(vc4_hdmi->hsm_clock, hsm_rate);
> if (ret) {
> DRM_ERROR("Failed to set HSM clock rate: %d\n", ret);
> return;
> --
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 73/78] drm/vc4: hdmi: Switch to blank pixels when disabled
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> In order to avoid pixels getting stuck in an unflushable FIFO, we need when
> we disable the HDMI controller to switch away from getting our pixels from
> the pixelvalve and instead use blank pixels, and switch back to the
> pixelvalve when we enable the HDMI controller.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 9 +
> drivers/gpu/drm/vc4/vc4_regs.h | 3 +++
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index f56a718a3643..37463b016b47 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -325,6 +325,12 @@ static void vc4_hdmi_encoder_post_crtc_disable(struct
> drm_encoder *encoder)
> struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
>
> HDMI_WRITE(HDMI_RAM_PACKET_CONFIG, 0);
> +
> + HDMI_WRITE(HDMI_VID_CTL, HDMI_READ(HDMI_VID_CTL) |
> + VC4_HD_VID_CTL_CLRRGB | VC4_HD_VID_CTL_CLRSYNC);
> +
> + HDMI_WRITE(HDMI_VID_CTL,
> + HDMI_READ(HDMI_VID_CTL) | VC4_HD_VID_CTL_BLANKPIX);
> }
>
> static void vc4_hdmi_encoder_post_crtc_powerdown(struct drm_encoder *encoder)
> @@ -563,6 +569,9 @@ static void vc4_hdmi_encoder_post_crtc_enable(struct
> drm_encoder *encoder)
>(vsync_pos ? 0 : VC4_HD_VID_CTL_VSYNC_LOW) |
>(hsync_pos ? 0 : VC4_HD_VID_CTL_HSYNC_LOW));
>
> + HDMI_WRITE(HDMI_VID_CTL,
> + HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_BLANKPIX);
> +
> if (vc4_encoder->hdmi_monitor) {
> HDMI_WRITE(HDMI_SCHEDULER_CONTROL,
>HDMI_READ(HDMI_SCHEDULER_CONTROL) |
> diff --git a/drivers/gpu/drm/vc4/vc4_regs.h b/drivers/gpu/drm/vc4/vc4_regs.h
> index d1e8961edaa0..30af52b406f1 100644
> --- a/drivers/gpu/drm/vc4/vc4_regs.h
> +++ b/drivers/gpu/drm/vc4/vc4_regs.h
> @@ -723,6 +723,9 @@
> # define VC4_HD_VID_CTL_FRAME_COUNTER_RESETBIT(29)
> # define VC4_HD_VID_CTL_VSYNC_LOW BIT(28)
> # define VC4_HD_VID_CTL_HSYNC_LOW BIT(27)
> +# define VC4_HD_VID_CTL_CLRSYNCBIT(24)
> +# define VC4_HD_VID_CTL_CLRRGB BIT(23)
> +# define VC4_HD_VID_CTL_BLANKPIX BIT(18)
>
> # define VC4_HD_CSC_CTL_ORDER_MASK VC4_MASK(7, 5)
> # define VC4_HD_CSC_CTL_ORDER_SHIFT5
> --
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 71/78] drm/vc4: hdmi: Implement finer-grained hooks
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> In order to prevent some pixels getting stuck in an unflushable FIFO on
> bcm2711, we need to enable the HVS, the pixelvalve (the CRTC) and the HDMI
> controller (the encoder) in an intertwined way, and with tight delays.
>
> However, the atomic callbacks don't really provide a way to work with
> either constraints, so we need to roll our own callbacks so that we can
> provide those guarantees.
>
> Since those callbacks have been implemented and called in the CRTC code, we
> can just implement them in the HDMI driver now.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 39 +++
> 1 file changed, 35 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 00592c1ada73..bbe521ab000b 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -320,12 +320,17 @@ static void vc4_hdmi_set_infoframes(struct drm_encoder
> *encoder)
> vc4_hdmi_set_audio_infoframe(encoder);
> }
>
> -static void vc4_hdmi_encoder_disable(struct drm_encoder *encoder)
> +static void vc4_hdmi_encoder_post_crtc_disable(struct drm_encoder *encoder)
> {
> struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> - int ret;
>
> HDMI_WRITE(HDMI_RAM_PACKET_CONFIG, 0);
> +}
> +
> +static void vc4_hdmi_encoder_post_crtc_powerdown(struct drm_encoder *encoder)
> +{
> + struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> + int ret;
>
> if (vc4_hdmi->variant->phy_disable)
> vc4_hdmi->variant->phy_disable(vc4_hdmi);
> @@ -341,6 +346,10 @@ static void vc4_hdmi_encoder_disable(struct drm_encoder
> *encoder)
> DRM_ERROR("Failed to release power domain: %d\n", ret);
> }
>
> +static void vc4_hdmi_encoder_disable(struct drm_encoder *encoder)
> +{
> +}
> +
> static void vc4_hdmi_csc_setup(struct vc4_hdmi *vc4_hdmi, bool enable)
> {
> u32 csc_ctl;
> @@ -449,11 +458,10 @@ static void vc4_hdmi_recenter_fifo(struct vc4_hdmi
> *vc4_hdmi)
> "VC4_HDMI_FIFO_CTL_RECENTER_DONE");
> }
>
> -static void vc4_hdmi_encoder_enable(struct drm_encoder *encoder)
> +static void vc4_hdmi_encoder_pre_crtc_configure(struct drm_encoder *encoder)
> {
> struct drm_display_mode *mode = >crtc->state->adjusted_mode;
> struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> - struct vc4_hdmi_encoder *vc4_encoder = to_vc4_hdmi_encoder(encoder);
> unsigned long pixel_rate, hsm_rate;
> int ret;
>
> @@ -521,6 +529,13 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
> *encoder)
>
> if (vc4_hdmi->variant->set_timings)
> vc4_hdmi->variant->set_timings(vc4_hdmi, mode);
> +}
> +
> +static void vc4_hdmi_encoder_pre_crtc_enable(struct drm_encoder *encoder)
> +{
> + struct drm_display_mode *mode = >crtc->state->adjusted_mode;
> + struct vc4_hdmi_encoder *vc4_encoder = to_vc4_hdmi_encoder(encoder);
> + struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
>
> if (vc4_encoder->hdmi_monitor &&
> drm_default_rgb_quant_range(mode) ==
> HDMI_QUANTIZATION_RANGE_LIMITED) {
> @@ -536,6 +551,13 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
> *encoder)
> }
>
> HDMI_WRITE(HDMI_FIFO_CTL, VC4_HDMI_FIFO_CTL_MASTER_SLAVE_N);
> +}
> +
> +static void vc4_hdmi_encoder_post_crtc_enable(struct drm_encoder *encoder)
> +{
> + struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> + struct vc4_hdmi_encoder *vc4_encoder = to_vc4_hdmi_encoder(encoder);
> + int ret;
>
> HDMI_WRITE(HDMI_VID_CTL,
>HDMI_READ(HDMI_VID_CTL) |
> @@ -582,6 +604,10 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
> *encoder)
> vc4_hdmi_recenter_fifo(vc4_hdmi);
> }
>
> +static void vc4_hdmi_encoder_enable(struct drm_encoder *encoder)
> +{
> +}
> +
> static enum drm_mode_status
> vc4_hdmi_encoder_mode_valid(struct drm_encoder *encoder,
> const struct drm_display_mode *mode)
> @@ -1362,6 +1388,11 @@ static int vc4_hdmi_bind(struct device *dev, struct
> device *master, void *data)
> dev_set_drvdata(dev, vc4_hdmi);
> encoder = _hdmi->encoder.base.base;
> vc4_hdmi->encoder.base.type = variant->encoder_type;
> + vc4_hdmi->encoder.base.pre_crtc_configure =
> vc4_hdmi_encode
Re: [PATCH v4 27/78] drm/vc4: crtc: Move HVS channel init before the PV initialisation
Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > In order to avoid stale pixels getting stuck in an intermediate FIFO > between the HVS and the pixelvalve on BCM2711, we need to configure the HVS > channel before the pixelvalve is reset and configured. > > Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson > --- > drivers/gpu/drm/vc4/vc4_crtc.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c > index 2c5ff45dc315..b7b0e19e2fe1 100644 > --- a/drivers/gpu/drm/vc4/vc4_crtc.c > +++ b/drivers/gpu/drm/vc4/vc4_crtc.c > @@ -427,10 +427,6 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc, > > require_hvs_enabled(dev); > > - vc4_crtc_config_pv(crtc); > - > - CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) | PV_CONTROL_EN); > - > /* Enable vblank irq handling before crtc is started otherwise > * drm_crtc_get_vblank() fails in vc4_crtc_update_dlist(). > */ > @@ -438,6 +434,10 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc, > > vc4_hvs_atomic_enable(crtc, old_state); > > + vc4_crtc_config_pv(crtc); > + > + CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) | PV_CONTROL_EN); > + > /* When feeding the transposer block the pixelvalve is unneeded and > * should not be enabled. > */ > -- > git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 51/78] drm/vc4: hdmi: Implement a register layout abstraction
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> The HDMI controllers found in the BCM2711 have most of the registers
> reorganized in multiple registers areas and at different offsets than
> previously found.
>
> The logic however remains pretty much the same, so it doesn't really make
> sense to create a whole new driver and we should share the code as much as
> possible.
>
> Let's implement some indirection to wrap around a register and depending on
> the variant will lookup the associated register on that particular variant.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 427 ++---
> drivers/gpu/drm/vc4/vc4_hdmi.h | 12 +-
> drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 241 -
> drivers/gpu/drm/vc4/vc4_regs.h | 92 +--
> 4 files changed, 464 insertions(+), 308 deletions(-)
> create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi_regs.h
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index ac021e07a8cb..a4fed1439bf3 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -50,62 +50,13 @@
> #include "media/cec.h"
> #include "vc4_drv.h"
> #include "vc4_hdmi.h"
> +#include "vc4_hdmi_regs.h"
> #include "vc4_regs.h"
>
> #define HSM_CLOCK_FREQ 163682864
> #define CEC_CLOCK_FREQ 4
> #define CEC_CLOCK_DIV (HSM_CLOCK_FREQ / CEC_CLOCK_FREQ)
>
> -static const struct debugfs_reg32 hdmi_regs[] = {
> - VC4_REG32(VC4_HDMI_CORE_REV),
> - VC4_REG32(VC4_HDMI_SW_RESET_CONTROL),
> - VC4_REG32(VC4_HDMI_HOTPLUG_INT),
> - VC4_REG32(VC4_HDMI_HOTPLUG),
> - VC4_REG32(VC4_HDMI_MAI_CHANNEL_MAP),
> - VC4_REG32(VC4_HDMI_MAI_CONFIG),
> - VC4_REG32(VC4_HDMI_MAI_FORMAT),
> - VC4_REG32(VC4_HDMI_AUDIO_PACKET_CONFIG),
> - VC4_REG32(VC4_HDMI_RAM_PACKET_CONFIG),
> - VC4_REG32(VC4_HDMI_HORZA),
> - VC4_REG32(VC4_HDMI_HORZB),
> - VC4_REG32(VC4_HDMI_FIFO_CTL),
> - VC4_REG32(VC4_HDMI_SCHEDULER_CONTROL),
> - VC4_REG32(VC4_HDMI_VERTA0),
> - VC4_REG32(VC4_HDMI_VERTA1),
> - VC4_REG32(VC4_HDMI_VERTB0),
> - VC4_REG32(VC4_HDMI_VERTB1),
> - VC4_REG32(VC4_HDMI_TX_PHY_RESET_CTL),
> - VC4_REG32(VC4_HDMI_TX_PHY_CTL0),
> -
> - VC4_REG32(VC4_HDMI_CEC_CNTRL_1),
> - VC4_REG32(VC4_HDMI_CEC_CNTRL_2),
> - VC4_REG32(VC4_HDMI_CEC_CNTRL_3),
> - VC4_REG32(VC4_HDMI_CEC_CNTRL_4),
> - VC4_REG32(VC4_HDMI_CEC_CNTRL_5),
> - VC4_REG32(VC4_HDMI_CPU_STATUS),
> - VC4_REG32(VC4_HDMI_CPU_MASK_STATUS),
> -
> - VC4_REG32(VC4_HDMI_CEC_RX_DATA_1),
> - VC4_REG32(VC4_HDMI_CEC_RX_DATA_2),
> - VC4_REG32(VC4_HDMI_CEC_RX_DATA_3),
> - VC4_REG32(VC4_HDMI_CEC_RX_DATA_4),
> - VC4_REG32(VC4_HDMI_CEC_TX_DATA_1),
> - VC4_REG32(VC4_HDMI_CEC_TX_DATA_2),
> - VC4_REG32(VC4_HDMI_CEC_TX_DATA_3),
> - VC4_REG32(VC4_HDMI_CEC_TX_DATA_4),
> -};
> -
> -static const struct debugfs_reg32 hd_regs[] = {
> - VC4_REG32(VC4_HD_M_CTL),
> - VC4_REG32(VC4_HD_MAI_CTL),
> - VC4_REG32(VC4_HD_MAI_THR),
> - VC4_REG32(VC4_HD_MAI_FMT),
> - VC4_REG32(VC4_HD_MAI_SMP),
> - VC4_REG32(VC4_HD_VID_CTL),
> - VC4_REG32(VC4_HD_CSC_CTL),
> - VC4_REG32(VC4_HD_FRAME_COUNT),
> -};
> -
> static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
> {
> struct drm_info_node *node = (struct drm_info_node *)m->private;
> @@ -134,7 +85,7 @@ vc4_hdmi_connector_detect(struct drm_connector *connector,
> bool force)
> if (drm_probe_ddc(vc4_hdmi->ddc))
> return connector_status_connected;
>
> - if (HDMI_READ(VC4_HDMI_HOTPLUG) & VC4_HDMI_HOTPLUG_CONNECTED)
> + if (HDMI_READ(HDMI_HOTPLUG) & VC4_HDMI_HOTPLUG_CONNECTED)
> return connector_status_connected;
> cec_phys_addr_invalidate(vc4_hdmi->cec_adap);
> return connector_status_disconnected;
> @@ -223,10 +174,10 @@ static int vc4_hdmi_stop_packet(struct drm_encoder
> *encoder,
> struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> u32 packet_id = type - 0x80;
>
> - HDMI_WRITE(VC4_HDMI_RAM_PACKET_CONFIG,
> - HDMI_READ(VC4_HDMI_RAM_PACKET_CONFIG) & ~BIT(packet_id));
> + HDMI_WRITE(HDMI_RAM_PACKET_CONFIG,
> + HDMI_READ(HDMI_RAM_PACKET_CONFIG) & ~BIT(packet_id));
>
> - return wait_for(!(HDMI_READ(VC4_HDMI_RAM_PACKET_STATUS) &
> + return wait_for(!(HDMI_READ(HDMI_
Re: [PATCH v4 52/78] drm/vc4: hdmi: Add reset callback
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> The BCM2711 and BCM283x HDMI controllers use a slightly different reset
> sequence, so let's add a callback to reset the controller.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 31 ++-
> drivers/gpu/drm/vc4/vc4_hdmi.h | 3 +++
> 2 files changed, 21 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index a4fed1439bf3..80bc3dd9d4a8 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -69,6 +69,21 @@ static int vc4_hdmi_debugfs_regs(struct seq_file *m, void
> *unused)
> return 0;
> }
>
> +static void vc4_hdmi_reset(struct vc4_hdmi *vc4_hdmi)
> +{
> + HDMI_WRITE(HDMI_M_CTL, VC4_HD_M_SW_RST);
> + udelay(1);
> + HDMI_WRITE(HDMI_M_CTL, 0);
> +
> + HDMI_WRITE(HDMI_M_CTL, VC4_HD_M_ENABLE);
> +
> + HDMI_WRITE(HDMI_SW_RESET_CONTROL,
> + VC4_HDMI_SW_RESET_HDMI |
> + VC4_HDMI_SW_RESET_FORMAT_DETECT);
> +
> + HDMI_WRITE(HDMI_SW_RESET_CONTROL, 0);
> +}
> +
> static enum drm_connector_status
> vc4_hdmi_connector_detect(struct drm_connector *connector, bool force)
> {
> @@ -363,11 +378,8 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
> *encoder)
> return;
> }
>
> - HDMI_WRITE(HDMI_SW_RESET_CONTROL,
> - VC4_HDMI_SW_RESET_HDMI |
> - VC4_HDMI_SW_RESET_FORMAT_DETECT);
> -
> - HDMI_WRITE(HDMI_SW_RESET_CONTROL, 0);
> + if (vc4_hdmi->variant->reset)
> + vc4_hdmi->variant->reset(vc4_hdmi);
>
> /* PHY should be in reset, like
> * vc4_hdmi_encoder_disable() does.
> @@ -1292,14 +1304,6 @@ static int vc4_hdmi_bind(struct device *dev, struct
> device *master, void *data)
> vc4_hdmi->hpd_active_low = hpd_gpio_flags &
> OF_GPIO_ACTIVE_LOW;
> }
>
> - /* HDMI core must be enabled. */
> - if (!(HDMI_READ(HDMI_M_CTL) & VC4_HD_M_ENABLE)) {
> - HDMI_WRITE(HDMI_M_CTL, VC4_HD_M_SW_RST);
> - udelay(1);
> - HDMI_WRITE(HDMI_M_CTL, 0);
> -
> - HDMI_WRITE(HDMI_M_CTL, VC4_HD_M_ENABLE);
> - }
> pm_runtime_enable(dev);
>
> drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS);
> @@ -1428,6 +1432,7 @@ static const struct vc4_hdmi_variant bcm2835_variant = {
> .num_registers = ARRAY_SIZE(vc4_hdmi_fields),
>
> .init_resources = vc4_hdmi_init_resources,
> + .reset = vc4_hdmi_reset,
> };
>
> static const struct of_device_id vc4_hdmi_dt_match[] = {
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index b36e0210671f..17a30589f39c 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -35,6 +35,9 @@ struct vc4_hdmi_variant {
> * clocks, etc) for that variant.
> */
> int (*init_resources)(struct vc4_hdmi *vc4_hdmi);
> +
> + /* Callback to reset the HDMI block */
> + void (*reset)(struct vc4_hdmi *vc4_hdmi);
> };
>
> /* HDMI audio information */
> --
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 70/78] drm/vc4: hdmi: Always recenter the HDMI FIFO
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> In order to avoid a pixel getting stuck in an unflushable FIFO, we need to
> recenter the FIFO every time we're doing a modeset and not only if we're
> connected to an HDMI monitor.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 46 +++
> 1 file changed, 26 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 4058985940e6..00592c1ada73 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -425,6 +425,30 @@ static void vc4_hdmi_set_timings(struct vc4_hdmi
> *vc4_hdmi,
>(hsync_pos ? 0 : VC4_HD_VID_CTL_HSYNC_LOW));
> }
>
> +static void vc4_hdmi_recenter_fifo(struct vc4_hdmi *vc4_hdmi)
> +{
> + u32 drift;
> + int ret;
> +
> + drift = HDMI_READ(HDMI_FIFO_CTL);
> + drift &= VC4_HDMI_FIFO_VALID_WRITE_MASK;
> +
> + HDMI_WRITE(HDMI_FIFO_CTL,
> + drift & ~VC4_HDMI_FIFO_CTL_RECENTER);
> + HDMI_WRITE(HDMI_FIFO_CTL,
> + drift | VC4_HDMI_FIFO_CTL_RECENTER);
> + usleep_range(1000, 1100);
> + HDMI_WRITE(HDMI_FIFO_CTL,
> + drift & ~VC4_HDMI_FIFO_CTL_RECENTER);
> + HDMI_WRITE(HDMI_FIFO_CTL,
> + drift | VC4_HDMI_FIFO_CTL_RECENTER);
> +
> + ret = wait_for(HDMI_READ(HDMI_FIFO_CTL) &
> + VC4_HDMI_FIFO_CTL_RECENTER_DONE, 1);
> + WARN_ONCE(ret, "Timeout waiting for "
> + "VC4_HDMI_FIFO_CTL_RECENTER_DONE");
> +}
> +
> static void vc4_hdmi_encoder_enable(struct drm_encoder *encoder)
> {
> struct drm_display_mode *mode = >crtc->state->adjusted_mode;
> @@ -543,8 +567,6 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
> *encoder)
> }
>
> if (vc4_encoder->hdmi_monitor) {
> - u32 drift;
> -
> WARN_ON(!(HDMI_READ(HDMI_SCHEDULER_CONTROL) &
> VC4_HDMI_SCHEDULER_CONTROL_HDMI_ACTIVE));
> HDMI_WRITE(HDMI_SCHEDULER_CONTROL,
> @@ -555,25 +577,9 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
> *encoder)
>VC4_HDMI_RAM_PACKET_ENABLE);
>
> vc4_hdmi_set_infoframes(encoder);
> -
> - drift = HDMI_READ(HDMI_FIFO_CTL);
> - drift &= VC4_HDMI_FIFO_VALID_WRITE_MASK;
> -
> - HDMI_WRITE(HDMI_FIFO_CTL,
> - drift & ~VC4_HDMI_FIFO_CTL_RECENTER);
> - HDMI_WRITE(HDMI_FIFO_CTL,
> - drift | VC4_HDMI_FIFO_CTL_RECENTER);
> - usleep_range(1000, 1100);
> - HDMI_WRITE(HDMI_FIFO_CTL,
> - drift & ~VC4_HDMI_FIFO_CTL_RECENTER);
> - HDMI_WRITE(HDMI_FIFO_CTL,
> - drift | VC4_HDMI_FIFO_CTL_RECENTER);
> -
> - ret = wait_for(HDMI_READ(HDMI_FIFO_CTL) &
> - VC4_HDMI_FIFO_CTL_RECENTER_DONE, 1);
> - WARN_ONCE(ret, "Timeout waiting for "
> - "VC4_HDMI_FIFO_CTL_RECENTER_DONE");
> }
> +
> + vc4_hdmi_recenter_fifo(vc4_hdmi);
> }
>
> static enum drm_mode_status
> --
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 26/78] drm/vc4: crtc: Remove redundant pixelvalve reset
Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > Since we moved the pixelvalve configuration to atomic_enable, we're now > first calling the function that resets the pixelvalve and then the one that > configures it. > > However, the first thing the latter is doing is calling the reset function, > meaning that we reset twice our pixelvalve. Let's remove the first call. > > Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson > --- > drivers/gpu/drm/vc4/vc4_crtc.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c > index 2eda2e6429ec..2c5ff45dc315 100644 > --- a/drivers/gpu/drm/vc4/vc4_crtc.c > +++ b/drivers/gpu/drm/vc4/vc4_crtc.c > @@ -427,7 +427,6 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc, > > require_hvs_enabled(dev); > > - vc4_crtc_pixelvalve_reset(crtc); > vc4_crtc_config_pv(crtc); > > CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) | PV_CONTROL_EN); > -- > git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 25/78] drm/vc4: crtc: Remove mode_set_nofb
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> On BCM2711 to avoid stale pixels getting stuck in intermediate FIFOs, the
> pixelvalve needs to be setup each time there's a mode change or enable /
> disable sequence.
>
> Therefore, we can't really use mode_set_nofb anymore to configure it, but
> we need to move it to atomic_enable.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index 284a85b9d7d4..2eda2e6429ec 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -376,11 +376,6 @@ static void vc4_crtc_config_pv(struct drm_crtc *crtc)
> }
> }
>
> -static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)
> -{
> - vc4_crtc_config_pv(crtc);
> -}
> -
> static void require_hvs_enabled(struct drm_device *dev)
> {
> struct vc4_dev *vc4 = to_vc4_dev(dev);
> @@ -433,6 +428,7 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
> require_hvs_enabled(dev);
>
> vc4_crtc_pixelvalve_reset(crtc);
> + vc4_crtc_config_pv(crtc);
>
> CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) | PV_CONTROL_EN);
>
> @@ -791,7 +787,6 @@ static const struct drm_crtc_funcs vc4_crtc_funcs = {
> };
>
> static const struct drm_crtc_helper_funcs vc4_crtc_helper_funcs = {
> - .mode_set_nofb = vc4_crtc_mode_set_nofb,
> .mode_valid = vc4_crtc_mode_valid,
> .atomic_check = vc4_crtc_atomic_check,
> .atomic_flush = vc4_hvs_atomic_flush,
> --
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 28/78] drm/vc4: encoder: Add finer-grained encoder callbacks
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> In the BCM2711, the setup of the HVS, pixelvalve and HDMI controller
> requires very precise ordering and timing that the regular atomic callbacks
> don't provide. Let's add new callbacks on top of the regular ones to be
> able to split the configuration as needed.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 19 +++
> drivers/gpu/drm/vc4/vc4_drv.h | 7 +++
> 2 files changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index b7b0e19e2fe1..d0b326e1df0a 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -389,6 +389,8 @@ static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
> {
> struct drm_device *dev = crtc->dev;
> struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
> + struct drm_encoder *encoder = vc4_get_crtc_encoder(crtc);
> + struct vc4_encoder *vc4_encoder = to_vc4_encoder(encoder);
> int ret;
>
> require_hvs_enabled(dev);
> @@ -401,10 +403,16 @@ static void vc4_crtc_atomic_disable(struct drm_crtc
> *crtc,
> ret = wait_for(!(CRTC_READ(PV_V_CONTROL) & PV_VCONTROL_VIDEN), 1);
> WARN_ONCE(ret, "Timeout waiting for !PV_VCONTROL_VIDEN\n");
>
> + if (vc4_encoder->post_crtc_disable)
> + vc4_encoder->post_crtc_disable(encoder);
> +
> CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) & ~PV_CONTROL_EN);
>
> vc4_hvs_atomic_disable(crtc, old_state);
>
> + if (vc4_encoder->post_crtc_powerdown)
> + vc4_encoder->post_crtc_powerdown(encoder);
> +
> /*
> * Make sure we issue a vblank event after disabling the CRTC if
> * someone was waiting it.
> @@ -424,6 +432,8 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
> {
> struct drm_device *dev = crtc->dev;
> struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
> + struct drm_encoder *encoder = vc4_get_crtc_encoder(crtc);
> + struct vc4_encoder *vc4_encoder = to_vc4_encoder(encoder);
>
> require_hvs_enabled(dev);
>
> @@ -434,15 +444,24 @@ static void vc4_crtc_atomic_enable(struct drm_crtc
> *crtc,
>
> vc4_hvs_atomic_enable(crtc, old_state);
>
> + if (vc4_encoder->pre_crtc_configure)
> + vc4_encoder->pre_crtc_configure(encoder);
> +
> vc4_crtc_config_pv(crtc);
>
> CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) | PV_CONTROL_EN);
>
> + if (vc4_encoder->pre_crtc_enable)
> + vc4_encoder->pre_crtc_enable(encoder);
> +
> /* When feeding the transposer block the pixelvalve is unneeded and
> * should not be enabled.
> */
> CRTC_WRITE(PV_V_CONTROL,
>CRTC_READ(PV_V_CONTROL) | PV_VCONTROL_VIDEN);
> +
> + if (vc4_encoder->post_crtc_enable)
> + vc4_encoder->post_crtc_enable(encoder);
> }
>
> static enum drm_mode_status vc4_crtc_mode_valid(struct drm_crtc *crtc,
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index dfcc684f5d28..251fcc35530c 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -439,6 +439,13 @@ struct vc4_encoder {
> struct drm_encoder base;
> enum vc4_encoder_type type;
> u32 clock_select;
> +
> + void (*pre_crtc_configure)(struct drm_encoder *encoder);
> + void (*pre_crtc_enable)(struct drm_encoder *encoder);
> + void (*post_crtc_enable)(struct drm_encoder *encoder);
> +
> + void (*post_crtc_disable)(struct drm_encoder *encoder);
> + void (*post_crtc_powerdown)(struct drm_encoder *encoder);
> };
>
> static inline struct vc4_encoder *
> --
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 30/78] drm/vc4: crtc: Clear the PixelValve FIFO on disable
Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > In order to avoid a stale pixel getting stuck on mode change or a disable > / enable cycle, we need to make sure to flush the PV FIFO on disable. > > Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson > --- > drivers/gpu/drm/vc4/vc4_crtc.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c > index 7b178d67187f..13fe0e370fb3 100644 > --- a/drivers/gpu/drm/vc4/vc4_crtc.c > +++ b/drivers/gpu/drm/vc4/vc4_crtc.c > @@ -408,8 +408,7 @@ static void vc4_crtc_atomic_disable(struct drm_crtc *crtc, > if (vc4_encoder->post_crtc_disable) > vc4_encoder->post_crtc_disable(encoder); > > - CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) & ~PV_CONTROL_EN); > - > + vc4_crtc_pixelvalve_reset(crtc); > vc4_hvs_atomic_disable(crtc, old_state); > > if (vc4_encoder->post_crtc_powerdown) > -- > git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 59/78] drm/vc4: hdmi: Add CEC support flag
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> Similarly to the audio support, CEC support is not there yet for the
> BCM2711, so let's skip entirely the CEC initialization through a variant
> flag.
CEC is sorted now, but it's easier & cleaner to keep this patch and
add a new patchset that enables CEC at a later date.
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 4
> drivers/gpu/drm/vc4/vc4_hdmi.h | 3 +++
> 2 files changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 8cd08b541c14..86e21de6c578 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -1179,6 +1179,9 @@ static int vc4_hdmi_cec_init(struct vc4_hdmi *vc4_hdmi)
> u32 value;
> int ret;
>
> + if (!vc4_hdmi->variant->cec_available)
> + return 0;
> +
> vc4_hdmi->cec_adap = cec_allocate_adapter(_hdmi_cec_adap_ops,
> vc4_hdmi, "vc4",
> CEC_CAP_DEFAULTS |
> @@ -1477,6 +1480,7 @@ static int vc4_hdmi_dev_remove(struct platform_device
> *pdev)
> static const struct vc4_hdmi_variant bcm2835_variant = {
> .encoder_type = VC4_ENCODER_TYPE_HDMI0,
> .debugfs_name = "hdmi_regs",
> + .cec_available = true,
> .registers = vc4_hdmi_fields,
> .num_registers = ARRAY_SIZE(vc4_hdmi_fields),
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index 794216f3228d..3f07aebe89f1 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -33,6 +33,9 @@ struct vc4_hdmi_variant {
> /* Filename to expose the registers in debugfs */
> const char *debugfs_name;
>
> + /* Set to true when the CEC support is available */
> + bool cec_available;
> +
> /* List of the registers available on that variant */
> const struct vc4_hdmi_register *registers;
>
> --
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 31/78] drm/vc4: crtc: Clear the PixelValve FIFO during configuration
Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > Even though it's not really clear why we need to flush the PV FIFO during > the configuration even though we started by flushing it, experience shows > that without it we get a stale pixel stuck in the FIFO between the HVS and > the PV. > > Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson > --- > drivers/gpu/drm/vc4/vc4_crtc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c > index 13fe0e370fb3..25a77cd46b28 100644 > --- a/drivers/gpu/drm/vc4/vc4_crtc.c > +++ b/drivers/gpu/drm/vc4/vc4_crtc.c > @@ -358,7 +358,7 @@ static void vc4_crtc_config_pv(struct drm_crtc *crtc) > if (is_dsi) > CRTC_WRITE(PV_HACT_ACT, mode->hdisplay * pixel_rep); > > - CRTC_WRITE(PV_CONTROL, > + CRTC_WRITE(PV_CONTROL, PV_CONTROL_FIFO_CLR | >vc4_crtc_get_fifo_full_level_bits(vc4_crtc, format) | >VC4_SET_FIELD(format, PV_CONTROL_FORMAT) | >VC4_SET_FIELD(pixel_rep - 1, PV_CONTROL_PIXEL_REP) | > -- > git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 10/78] drm/vc4: crtc: Rename HVS channel to output
Hi Maxime
On Wed, 8 Jul 2020 at 18:42, Maxime Ripard wrote:
>
> In vc5, the HVS has 6 outputs and 3 FIFOs (or channels), with
> pixelvalves each being assigned to a given output, but each output can
> then be muxed to feed from multiple FIFOs.
>
> Since vc4 had that entirely static, both were probably equivalent, but
> since that changes, let's rename hvs_channel to hvs_output in the
> vc4_crtc_data, since a pixelvalve is really connected to an output, and
> not to a FIFO.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 8
> drivers/gpu/drm/vc4/vc4_drv.h | 4 ++--
> drivers/gpu/drm/vc4/vc4_hvs.c | 2 +-
> drivers/gpu/drm/vc4/vc4_txp.c | 2 +-
> 4 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index fdecaba77836..d3126fe04d9a 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -775,7 +775,7 @@ static const struct drm_crtc_helper_funcs
> vc4_crtc_helper_funcs = {
>
> static const struct vc4_pv_data bcm2835_pv0_data = {
> .base = {
> - .hvs_channel = 0,
> + .hvs_output = 0,
> },
> .debugfs_name = "crtc0_regs",
> .pixels_per_clock = 1,
> @@ -787,7 +787,7 @@ static const struct vc4_pv_data bcm2835_pv0_data = {
>
> static const struct vc4_pv_data bcm2835_pv1_data = {
> .base = {
> - .hvs_channel = 2,
> + .hvs_output = 2,
> },
> .debugfs_name = "crtc1_regs",
> .pixels_per_clock = 1,
> @@ -799,7 +799,7 @@ static const struct vc4_pv_data bcm2835_pv1_data = {
>
> static const struct vc4_pv_data bcm2835_pv2_data = {
> .base = {
> - .hvs_channel = 1,
> + .hvs_output = 1,
> },
> .debugfs_name = "crtc2_regs",
> .pixels_per_clock = 1,
> @@ -862,7 +862,7 @@ int vc4_crtc_init(struct drm_device *drm, struct vc4_crtc
> *vc4_crtc,
> drm_crtc_init_with_planes(drm, crtc, primary_plane, NULL,
> crtc_funcs, NULL);
> drm_crtc_helper_add(crtc, crtc_helper_funcs);
> - vc4_crtc->channel = vc4_crtc->data->hvs_channel;
> + vc4_crtc->channel = vc4_crtc->data->hvs_output;
> drm_mode_crtc_set_gamma_size(crtc, ARRAY_SIZE(vc4_crtc->lut_r));
> drm_crtc_enable_color_mgmt(crtc, 0, false, crtc->gamma_size);
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index d80fc3bbb450..d1cf4c038180 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -447,8 +447,8 @@ to_vc4_encoder(struct drm_encoder *encoder)
> }
>
> struct vc4_crtc_data {
> - /* Which channel of the HVS this pixelvalve sources from. */
> - int hvs_channel;
> + /* Which output of the HVS this pixelvalve sources from. */
> + int hvs_output;
> };
>
> struct vc4_pv_data {
> diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
> index 091fdf4908aa..6fd9de1dc65a 100644
> --- a/drivers/gpu/drm/vc4/vc4_hvs.c
> +++ b/drivers/gpu/drm/vc4/vc4_hvs.c
> @@ -419,7 +419,7 @@ void vc4_hvs_mode_set_nofb(struct drm_crtc *crtc)
> struct drm_display_mode *mode = >state->adjusted_mode;
> bool interlace = mode->flags & DRM_MODE_FLAG_INTERLACE;
>
> - if (vc4_crtc->data->hvs_channel == 2) {
> + if (vc4_crtc->data->hvs_output == 2) {
> u32 dispctrl;
> u32 dsp3_mux;
>
> diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
> index a7c3af0005a0..f39d9900d027 100644
> --- a/drivers/gpu/drm/vc4/vc4_txp.c
> +++ b/drivers/gpu/drm/vc4/vc4_txp.c
> @@ -452,7 +452,7 @@ static irqreturn_t vc4_txp_interrupt(int irq, void *data)
> }
>
> static const struct vc4_crtc_data vc4_txp_crtc_data = {
> - .hvs_channel = 2,
> + .hvs_output = 2,
> };
>
> static int vc4_txp_bind(struct device *dev, struct device *master, void
> *data)
> --
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 22/78] drm/vc4: crtc: Move HVS init and close to a function
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> In order to make further refactoring easier, let's move the HVS channel
> setup / teardown to their own function.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hvs.c | 104 +++
> 1 file changed, 58 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
> index 50f9a9674a7e..78bb1c0b0b76 100644
> --- a/drivers/gpu/drm/vc4/vc4_hvs.c
> +++ b/drivers/gpu/drm/vc4/vc4_hvs.c
> @@ -196,6 +196,62 @@ static void vc4_hvs_update_gamma_lut(struct drm_crtc
> *crtc)
> vc4_hvs_lut_load(crtc);
> }
>
> +static int vc4_hvs_init_channel(struct vc4_dev *vc4, struct drm_crtc *crtc,
> + struct drm_display_mode *mode, bool oneshot)
> +{
> + struct vc4_crtc_state *vc4_crtc_state =
> to_vc4_crtc_state(crtc->state);
> + unsigned int chan = vc4_crtc_state->assigned_channel;
> + u32 dispctrl;
> +
> + /* Turn on the scaler, which will wait for vstart to start
> +* compositing.
> +* When feeding the transposer, we should operate in oneshot
> +* mode.
> +*/
> + dispctrl = SCALER_DISPCTRLX_ENABLE;
> +
> + if (!vc4->hvs->hvs5)
> + dispctrl |= VC4_SET_FIELD(mode->hdisplay,
> + SCALER_DISPCTRLX_WIDTH) |
> + VC4_SET_FIELD(mode->vdisplay,
> + SCALER_DISPCTRLX_HEIGHT) |
> + (oneshot ? SCALER_DISPCTRLX_ONESHOT : 0);
> + else
> + dispctrl |= VC4_SET_FIELD(mode->hdisplay,
> + SCALER5_DISPCTRLX_WIDTH) |
> + VC4_SET_FIELD(mode->vdisplay,
> + SCALER5_DISPCTRLX_HEIGHT) |
> + (oneshot ? SCALER5_DISPCTRLX_ONESHOT : 0);
> +
> + HVS_WRITE(SCALER_DISPCTRLX(chan), dispctrl);
> +
> + return 0;
> +}
> +
> +static void vc4_hvs_stop_channel(struct drm_device *dev, unsigned int chan)
> +{
> + struct vc4_dev *vc4 = to_vc4_dev(dev);
> +
> + if (HVS_READ(SCALER_DISPCTRLX(chan)) & SCALER_DISPCTRLX_ENABLE)
> + return;
> +
> + HVS_WRITE(SCALER_DISPCTRLX(chan),
> + HVS_READ(SCALER_DISPCTRLX(chan)) | SCALER_DISPCTRLX_RESET);
> + HVS_WRITE(SCALER_DISPCTRLX(chan),
> + HVS_READ(SCALER_DISPCTRLX(chan)) &
> ~SCALER_DISPCTRLX_ENABLE);
> +
> + /* Once we leave, the scaler should be disabled and its fifo empty. */
> + WARN_ON_ONCE(HVS_READ(SCALER_DISPCTRLX(chan)) &
> SCALER_DISPCTRLX_RESET);
> +
> + WARN_ON_ONCE(VC4_GET_FIELD(HVS_READ(SCALER_DISPSTATX(chan)),
> + SCALER_DISPSTATX_MODE) !=
> +SCALER_DISPSTATX_MODE_DISABLED);
> +
> + WARN_ON_ONCE((HVS_READ(SCALER_DISPSTATX(chan)) &
> + (SCALER_DISPSTATX_FULL | SCALER_DISPSTATX_EMPTY)) !=
> +SCALER_DISPSTATX_EMPTY);
> +}
> +
> int vc4_hvs_atomic_check(struct drm_crtc *crtc,
> struct drm_crtc_state *state)
> {
> @@ -268,63 +324,19 @@ void vc4_hvs_atomic_enable(struct drm_crtc *crtc,
> struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
> struct drm_display_mode *mode = >state->adjusted_mode;
> bool oneshot = vc4_state->feed_txp;
> - u32 dispctrl;
>
> vc4_hvs_update_dlist(crtc);
> -
> - /* Turn on the scaler, which will wait for vstart to start
> -* compositing.
> -* When feeding the transposer, we should operate in oneshot
> -* mode.
> -*/
> - dispctrl = SCALER_DISPCTRLX_ENABLE;
> -
> - if (!vc4->hvs->hvs5)
> - dispctrl |= VC4_SET_FIELD(mode->hdisplay,
> - SCALER_DISPCTRLX_WIDTH) |
> - VC4_SET_FIELD(mode->vdisplay,
> - SCALER_DISPCTRLX_HEIGHT) |
> - (oneshot ? SCALER_DISPCTRLX_ONESHOT : 0);
> - else
> - dispctrl |= VC4_SET_FIELD(mode->hdisplay,
> - SCALER5_DISPCTRLX_WIDTH) |
> - VC4_SET_FIELD(mode->vdisplay,
> - SCALER5_DISPCTRLX_HEIGHT) |
> - (oneshot ? SCALER5_DISPCTRLX_ONESHOT : 0);
> -
> - HVS_WRITE(SCALER
Re: [PATCH v4 50/78] drm/vc4: hdmi: Introduce resource init and variant
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> The HDMI controllers found in the BCM2711 has a pretty different clock and
> registers areas than found in the older BCM283x SoCs.
>
> Let's create a variant structure to store the various adjustments we'll
> need later on, and a function to get the resources needed for one
> particular version.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 61 +++
> drivers/gpu/drm/vc4/vc4_hdmi.h | 10 ++-
> 2 files changed, 51 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index ec7710dfd04e..ac021e07a8cb 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -1179,28 +1179,12 @@ static const struct cec_adap_ops
> vc4_hdmi_cec_adap_ops = {
> };
> #endif
>
> -static int vc4_hdmi_bind(struct device *dev, struct device *master, void
> *data)
> +static int vc4_hdmi_init_resources(struct vc4_hdmi *vc4_hdmi)
> {
> -#ifdef CONFIG_DRM_VC4_HDMI_CEC
> - struct cec_connector_info conn_info;
> -#endif
> - struct platform_device *pdev = to_platform_device(dev);
> - struct drm_device *drm = dev_get_drvdata(master);
> - struct vc4_hdmi *vc4_hdmi;
> - struct drm_encoder *encoder;
> - struct device_node *ddc_node;
> - u32 value;
> + struct platform_device *pdev = vc4_hdmi->pdev;
> + struct device *dev = >dev;
> int ret;
>
> - vc4_hdmi = devm_kzalloc(dev, sizeof(*vc4_hdmi), GFP_KERNEL);
> - if (!vc4_hdmi)
> - return -ENOMEM;
> -
> - dev_set_drvdata(dev, vc4_hdmi);
> - encoder = _hdmi->encoder.base.base;
> - vc4_hdmi->encoder.base.type = VC4_ENCODER_TYPE_HDMI0;
> - vc4_hdmi->pdev = pdev;
> -
> vc4_hdmi->hdmicore_regs = vc4_ioremap_regs(pdev, 0);
> if (IS_ERR(vc4_hdmi->hdmicore_regs))
> return PTR_ERR(vc4_hdmi->hdmicore_regs);
> @@ -1212,6 +1196,7 @@ static int vc4_hdmi_bind(struct device *dev, struct
> device *master, void *data)
> vc4_hdmi->hdmi_regset.base = vc4_hdmi->hdmicore_regs;
> vc4_hdmi->hdmi_regset.regs = hdmi_regs;
> vc4_hdmi->hdmi_regset.nregs = ARRAY_SIZE(hdmi_regs);
> +
> vc4_hdmi->hd_regset.base = vc4_hdmi->hd_regs;
> vc4_hdmi->hd_regset.regs = hd_regs;
> vc4_hdmi->hd_regset.nregs = ARRAY_SIZE(hd_regs);
> @@ -1223,12 +1208,44 @@ static int vc4_hdmi_bind(struct device *dev, struct
> device *master, void *data)
> DRM_ERROR("Failed to get pixel clock\n");
> return ret;
> }
> +
> vc4_hdmi->hsm_clock = devm_clk_get(dev, "hdmi");
> if (IS_ERR(vc4_hdmi->hsm_clock)) {
> DRM_ERROR("Failed to get HDMI state machine clock\n");
> return PTR_ERR(vc4_hdmi->hsm_clock);
> }
>
> + return 0;
> +}
> +
> +static int vc4_hdmi_bind(struct device *dev, struct device *master, void
> *data)
> +{
> +#ifdef CONFIG_DRM_VC4_HDMI_CEC
> + struct cec_connector_info conn_info;
> +#endif
> + const struct vc4_hdmi_variant *variant =
> of_device_get_match_data(dev);
> + struct platform_device *pdev = to_platform_device(dev);
> + struct drm_device *drm = dev_get_drvdata(master);
> + struct vc4_hdmi *vc4_hdmi;
> + struct drm_encoder *encoder;
> + struct device_node *ddc_node;
> + u32 value;
> + int ret;
> +
> + vc4_hdmi = devm_kzalloc(dev, sizeof(*vc4_hdmi), GFP_KERNEL);
> + if (!vc4_hdmi)
> + return -ENOMEM;
> +
> + dev_set_drvdata(dev, vc4_hdmi);
> + encoder = _hdmi->encoder.base.base;
> + vc4_hdmi->encoder.base.type = VC4_ENCODER_TYPE_HDMI0;
> + vc4_hdmi->pdev = pdev;
> + vc4_hdmi->variant = variant;
> +
> + ret = variant->init_resources(vc4_hdmi);
> + if (ret)
> + return ret;
> +
> ddc_node = of_parse_phandle(dev->of_node, "ddc", 0);
> if (!ddc_node) {
> DRM_ERROR("Failed to find ddc node in device tree\n");
> @@ -1404,8 +1421,12 @@ static int vc4_hdmi_dev_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +static const struct vc4_hdmi_variant bcm2835_variant = {
> + .init_resources = vc4_hdmi_init_resources,
> +};
> +
> static const struct of_device_id vc4_hdmi_dt_match[] = {
> - { .compatible = "brcm,
Re: [PATCH v4 54/78] drm/vc4: hdmi: Add PHY RNG enable / disable function
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> Let's continue the implementation of hooks for the parts that change in the
> BCM2711 SoC with the PHY RNG setup.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 15 +--
> drivers/gpu/drm/vc4/vc4_hdmi.h | 8
> drivers/gpu/drm/vc4/vc4_hdmi_phy.c | 15 +++
> 3 files changed, 32 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 068041145d1c..19897d6525ac 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -762,9 +762,9 @@ static int vc4_hdmi_audio_trigger(struct
> snd_pcm_substream *substream, int cmd,
> switch (cmd) {
> case SNDRV_PCM_TRIGGER_START:
> vc4_hdmi_set_audio_infoframe(encoder);
> - HDMI_WRITE(HDMI_TX_PHY_CTL_0,
> - HDMI_READ(HDMI_TX_PHY_CTL_0) &
> - ~VC4_HDMI_TX_PHY_RNG_PWRDN);
> +
> + if (vc4_hdmi->variant->phy_rng_enable)
> + vc4_hdmi->variant->phy_rng_enable(vc4_hdmi);
>
> HDMI_WRITE(HDMI_MAI_CTL,
>VC4_SET_FIELD(vc4_hdmi->audio.channels,
> @@ -776,9 +776,10 @@ static int vc4_hdmi_audio_trigger(struct
> snd_pcm_substream *substream, int cmd,
>VC4_HD_MAI_CTL_DLATE |
>VC4_HD_MAI_CTL_ERRORE |
>VC4_HD_MAI_CTL_ERRORF);
> - HDMI_WRITE(HDMI_TX_PHY_CTL_0,
> - HDMI_READ(HDMI_TX_PHY_CTL_0) |
> - VC4_HDMI_TX_PHY_RNG_PWRDN);
> +
> + if (vc4_hdmi->variant->phy_rng_disable)
> + vc4_hdmi->variant->phy_rng_disable(vc4_hdmi);
> +
> break;
> default:
> break;
> @@ -1433,6 +1434,8 @@ static const struct vc4_hdmi_variant bcm2835_variant = {
> .reset = vc4_hdmi_reset,
> .phy_init = vc4_hdmi_phy_init,
> .phy_disable= vc4_hdmi_phy_disable,
> + .phy_rng_enable = vc4_hdmi_phy_rng_enable,
> + .phy_rng_disable= vc4_hdmi_phy_rng_disable,
> };
>
> static const struct of_device_id vc4_hdmi_dt_match[] = {
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index 32c80161c786..950accbc44e4 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -47,6 +47,12 @@ struct vc4_hdmi_variant {
>
> /* Callback to disable the PHY */
> void (*phy_disable)(struct vc4_hdmi *vc4_hdmi);
> +
> + /* Callback to enable the RNG in the PHY */
> + void (*phy_rng_enable)(struct vc4_hdmi *vc4_hdmi);
> +
> + /* Callback to disable the RNG in the PHY */
> + void (*phy_rng_disable)(struct vc4_hdmi *vc4_hdmi);
> };
>
> /* HDMI audio information */
> @@ -107,5 +113,7 @@ encoder_to_vc4_hdmi(struct drm_encoder *encoder)
> void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
>struct drm_display_mode *mode);
> void vc4_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
> +void vc4_hdmi_phy_rng_enable(struct vc4_hdmi *vc4_hdmi);
> +void vc4_hdmi_phy_rng_disable(struct vc4_hdmi *vc4_hdmi);
>
> #endif /* _VC4_HDMI_H_ */
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
> b/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
> index 5a1746877bb5..93287e24d7d1 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
> @@ -7,6 +7,7 @@
> */
>
> #include "vc4_hdmi.h"
> +#include "vc4_regs.h"
> #include "vc4_hdmi_regs.h"
>
> void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi, struct drm_display_mode
> *mode)
> @@ -23,3 +24,17 @@ void vc4_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi)
> {
> HDMI_WRITE(HDMI_TX_PHY_RESET_CTL, 0xf << 16);
> }
> +
> +void vc4_hdmi_phy_rng_enable(struct vc4_hdmi *vc4_hdmi)
> +{
> + HDMI_WRITE(HDMI_TX_PHY_CTL_0,
> + HDMI_READ(HDMI_TX_PHY_CTL_0) &
> + ~VC4_HDMI_TX_PHY_RNG_PWRDN);
> +}
> +
> +void vc4_hdmi_phy_rng_disable(struct vc4_hdmi *vc4_hdmi)
> +{
> + HDMI_WRITE(HDMI_TX_PHY_CTL_0,
> + HDMI_READ(HDMI_TX_PHY_CTL_0) |
> + VC4_HDMI_TX_PHY_RNG_PWRDN);
> +}
> --
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 58/78] drm/vc4: hdmi: Move CEC init to its own function
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> The CEC init code was put directly into the bind function, which was quite
> inconsistent with how the audio support was done, and would prevent us from
> further changes to skip that initialisation entirely.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 108 +-
> 1 file changed, 67 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index ef51eedaf75a..8cd08b541c14 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -1171,6 +1171,67 @@ static const struct cec_adap_ops vc4_hdmi_cec_adap_ops
> = {
> .adap_log_addr = vc4_hdmi_cec_adap_log_addr,
> .adap_transmit = vc4_hdmi_cec_adap_transmit,
> };
> +
> +static int vc4_hdmi_cec_init(struct vc4_hdmi *vc4_hdmi)
> +{
> + struct cec_connector_info conn_info;
> + struct platform_device *pdev = vc4_hdmi->pdev;
> + u32 value;
> + int ret;
> +
> + vc4_hdmi->cec_adap = cec_allocate_adapter(_hdmi_cec_adap_ops,
> + vc4_hdmi, "vc4",
> + CEC_CAP_DEFAULTS |
> + CEC_CAP_CONNECTOR_INFO, 1);
> + ret = PTR_ERR_OR_ZERO(vc4_hdmi->cec_adap);
> + if (ret < 0)
> + return ret;
> +
> + cec_fill_conn_info_from_drm(_info, _hdmi->connector);
> + cec_s_conn_info(vc4_hdmi->cec_adap, _info);
> +
> + HDMI_WRITE(HDMI_CEC_CPU_MASK_SET, 0x);
> + value = HDMI_READ(HDMI_CEC_CNTRL_1);
> + value &= ~VC4_HDMI_CEC_DIV_CLK_CNT_MASK;
> + /*
> +* Set the logical address to Unregistered and set the clock
> +* divider: the hsm_clock rate and this divider setting will
> +* give a 40 kHz CEC clock.
> +*/
> + value |= VC4_HDMI_CEC_ADDR_MASK |
> +(4091 << VC4_HDMI_CEC_DIV_CLK_CNT_SHIFT);
> + HDMI_WRITE(HDMI_CEC_CNTRL_1, value);
> + ret = devm_request_threaded_irq(>dev, platform_get_irq(pdev, 0),
> + vc4_cec_irq_handler,
> + vc4_cec_irq_handler_thread, 0,
> + "vc4 hdmi cec", vc4_hdmi);
> + if (ret)
> + goto err_delete_cec_adap;
> +
> + ret = cec_register_adapter(vc4_hdmi->cec_adap, >dev);
> + if (ret < 0)
> + goto err_delete_cec_adap;
> +
> + return 0;
> +
> +err_delete_cec_adap:
> + cec_delete_adapter(vc4_hdmi->cec_adap);
> +
> + return ret;
> +}
> +
> +static void vc4_hdmi_cec_exit(struct vc4_hdmi *vc4_hdmi)
> +{
> + cec_unregister_adapter(vc4_hdmi->cec_adap);
> +}
> +#else
> +static int vc4_hdmi_cec_init(struct vc4_hdmi *vc4_hdmi)
> +{
> + return 0;
> +}
> +
> +static void vc4_hdmi_cec_exit(struct vc4_hdmi *vc4_hdmi) {};
> +
> #endif
>
> static int vc4_hdmi_build_regset(struct vc4_hdmi *vc4_hdmi,
> @@ -1250,9 +1311,6 @@ static int vc4_hdmi_init_resources(struct vc4_hdmi
> *vc4_hdmi)
>
> static int vc4_hdmi_bind(struct device *dev, struct device *master, void
> *data)
> {
> -#ifdef CONFIG_DRM_VC4_HDMI_CEC
> - struct cec_connector_info conn_info;
> -#endif
> const struct vc4_hdmi_variant *variant =
> of_device_get_match_data(dev);
> struct platform_device *pdev = to_platform_device(dev);
> struct drm_device *drm = dev_get_drvdata(master);
> @@ -1332,43 +1390,13 @@ static int vc4_hdmi_bind(struct device *dev, struct
> device *master, void *data)
> if (ret)
> goto err_destroy_encoder;
>
> -#ifdef CONFIG_DRM_VC4_HDMI_CEC
> - vc4_hdmi->cec_adap = cec_allocate_adapter(_hdmi_cec_adap_ops,
> - vc4_hdmi, "vc4",
> - CEC_CAP_DEFAULTS |
> - CEC_CAP_CONNECTOR_INFO, 1);
> - ret = PTR_ERR_OR_ZERO(vc4_hdmi->cec_adap);
> - if (ret < 0)
> - goto err_destroy_conn;
> -
> - cec_fill_conn_info_from_drm(_info, _hdmi->connector);
> - cec_s_conn_info(vc4_hdmi->cec_adap, _info);
> -
> - HDMI_WRITE(HDMI_CEC_CPU_MASK_SET, 0x);
> - value = HDMI_READ(HDMI_CEC_CNTRL_1);
> - value &= ~VC4_HDMI_CEC_DIV_CLK_CNT_MASK;
> - /*
> -* Set the logical add
Re: [PATCH v4 72/78] drm/vc4: hdmi: Do the VID_CTL configuration at once
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> The VID_CTL setup is done in several places in the driver even though it's
> not really required. Let's simplify it a bit to do the configuration in one
> go.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index bbe521ab000b..f56a718a3643 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -428,10 +428,6 @@ static void vc4_hdmi_set_timings(struct vc4_hdmi
> *vc4_hdmi,
>
> HDMI_WRITE(HDMI_VERTB0, vertb_even);
> HDMI_WRITE(HDMI_VERTB1, vertb);
> -
> - HDMI_WRITE(HDMI_VID_CTL,
> - (vsync_pos ? 0 : VC4_HD_VID_CTL_VSYNC_LOW) |
> - (hsync_pos ? 0 : VC4_HD_VID_CTL_HSYNC_LOW));
> }
>
> static void vc4_hdmi_recenter_fifo(struct vc4_hdmi *vc4_hdmi)
> @@ -520,8 +516,6 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
> drm_encoder *encoder)
> if (vc4_hdmi->variant->phy_init)
> vc4_hdmi->variant->phy_init(vc4_hdmi, mode);
>
> - HDMI_WRITE(HDMI_VID_CTL, 0);
> -
> HDMI_WRITE(HDMI_SCHEDULER_CONTROL,
>HDMI_READ(HDMI_SCHEDULER_CONTROL) |
>VC4_HDMI_SCHEDULER_CONTROL_MANUAL_FORMAT |
> @@ -555,15 +549,19 @@ static void vc4_hdmi_encoder_pre_crtc_enable(struct
> drm_encoder *encoder)
>
> static void vc4_hdmi_encoder_post_crtc_enable(struct drm_encoder *encoder)
> {
> + struct drm_display_mode *mode = >crtc->state->adjusted_mode;
> struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> struct vc4_hdmi_encoder *vc4_encoder = to_vc4_hdmi_encoder(encoder);
> + bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
> + bool vsync_pos = mode->flags & DRM_MODE_FLAG_PVSYNC;
> int ret;
>
> HDMI_WRITE(HDMI_VID_CTL,
> - HDMI_READ(HDMI_VID_CTL) |
>VC4_HD_VID_CTL_ENABLE |
>VC4_HD_VID_CTL_UNDERFLOW_ENABLE |
> - VC4_HD_VID_CTL_FRAME_COUNTER_RESET);
> + VC4_HD_VID_CTL_FRAME_COUNTER_RESET |
> + (vsync_pos ? 0 : VC4_HD_VID_CTL_VSYNC_LOW) |
> + (hsync_pos ? 0 : VC4_HD_VID_CTL_HSYNC_LOW));
>
> if (vc4_encoder->hdmi_monitor) {
> HDMI_WRITE(HDMI_SCHEDULER_CONTROL,
> --
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 74/78] drm/vc4: hdmi: Support the BCM2711 HDMI controllers
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> Now that the driver is ready for it, let's bring in the HDMI controllers
> variants for the BCM2711.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 278 +-
> drivers/gpu/drm/vc4/vc4_hdmi.h | 36 ++-
> drivers/gpu/drm/vc4/vc4_hdmi_phy.c | 480 +-
> drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 201 -
> drivers/gpu/drm/vc4/vc4_regs.h | 2 +-
> 5 files changed, 997 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 37463b016b47..d5ba0b1b73a9 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -43,6 +43,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -53,6 +54,31 @@
> #include "vc4_hdmi_regs.h"
> #include "vc4_regs.h"
>
> +#define VC5_HDMI_HORZA_HFP_SHIFT 16
> +#define VC5_HDMI_HORZA_HFP_MASKVC4_MASK(28, 16)
> +#define VC5_HDMI_HORZA_VPOSBIT(15)
> +#define VC5_HDMI_HORZA_HPOSBIT(14)
> +#define VC5_HDMI_HORZA_HAP_SHIFT 0
> +#define VC5_HDMI_HORZA_HAP_MASKVC4_MASK(13, 0)
> +
> +#define VC5_HDMI_HORZB_HBP_SHIFT 16
> +#define VC5_HDMI_HORZB_HBP_MASKVC4_MASK(26, 16)
> +#define VC5_HDMI_HORZB_HSP_SHIFT 0
> +#define VC5_HDMI_HORZB_HSP_MASKVC4_MASK(10, 0)
> +
> +#define VC5_HDMI_VERTA_VSP_SHIFT 24
> +#define VC5_HDMI_VERTA_VSP_MASKVC4_MASK(28, 24)
> +#define VC5_HDMI_VERTA_VFP_SHIFT 16
> +#define VC5_HDMI_VERTA_VFP_MASKVC4_MASK(22, 16)
> +#define VC5_HDMI_VERTA_VAL_SHIFT 0
> +#define VC5_HDMI_VERTA_VAL_MASKVC4_MASK(12, 0)
> +
> +#define VC5_HDMI_VERTB_VSPO_SHIFT 16
> +#define VC5_HDMI_VERTB_VSPO_MASK VC4_MASK(29, 16)
> +
> +# define VC4_HD_M_SW_RST BIT(2)
> +# define VC4_HD_M_ENABLE BIT(0)
> +
> #define CEC_CLOCK_FREQ 4
>
> static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
> @@ -82,6 +108,16 @@ static void vc4_hdmi_reset(struct vc4_hdmi *vc4_hdmi)
> HDMI_WRITE(HDMI_SW_RESET_CONTROL, 0);
> }
>
> +static void vc5_hdmi_reset(struct vc4_hdmi *vc4_hdmi)
> +{
> + reset_control_reset(vc4_hdmi->reset);
> +
> + HDMI_WRITE(HDMI_DVP_CTL, 0);
> +
> + HDMI_WRITE(HDMI_CLOCK_STOP,
> + HDMI_READ(HDMI_CLOCK_STOP) | VC4_DVP_HT_CLOCK_STOP_PIXEL);
> +}
> +
> static enum drm_connector_status
> vc4_hdmi_connector_detect(struct drm_connector *connector, bool force)
> {
> @@ -391,6 +427,45 @@ static void vc4_hdmi_csc_setup(struct vc4_hdmi
> *vc4_hdmi, bool enable)
> HDMI_WRITE(HDMI_CSC_CTL, csc_ctl);
> }
>
> +static void vc5_hdmi_csc_setup(struct vc4_hdmi *vc4_hdmi, bool enable)
> +{
> + u32 csc_ctl;
> +
> + csc_ctl = 0x07; /* RGB_CONVERT_MODE = custom matrix, ||
> USE_RGB_TO_YCBCR */
> +
> + if (enable) {
> + /* CEA VICs other than #1 requre limited range RGB
> +* output unless overridden by an AVI infoframe.
> +* Apply a colorspace conversion to squash 0-255 down
> +* to 16-235. The matrix here is:
> +*
> +* [ 0.8594 0 0 16]
> +* [ 0 0.8594 0 16]
> +* [ 0 0 0.8594 16]
> +* [ 0 0 0 1]
> +* Matrix is signed 2p13 fixed point, with signed 9p6 offsets
> +*/
> + HDMI_WRITE(HDMI_CSC_12_11, (0x << 16) | 0x1b80);
> + HDMI_WRITE(HDMI_CSC_14_13, (0x0400 << 16) | 0x);
> + HDMI_WRITE(HDMI_CSC_22_21, (0x1b80 << 16) | 0x);
> + HDMI_WRITE(HDMI_CSC_24_23, (0x0400 << 16) | 0x);
> + HDMI_WRITE(HDMI_CSC_32_31, (0x << 16) | 0x);
> + HDMI_WRITE(HDMI_CSC_34_33, (0x0400 << 16) | 0x1b80);
> + } else {
> + /* Still use the matrix for full range, but make it unity.
> +* Matrix is signed 2p13 fixed point, with signed 9p6 offsets
> +*/
> + HDMI_WRITE(HDMI_CSC_12_11, (0x << 16) | 0x2000);
> + HDMI_WRITE(HDMI_CSC_14_13, (0x << 16) | 0x);
> +
Re: [PATCH v4 78/78] ARM: dts: bcm2711: Enable the display pipeline
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> Now that all the drivers have been adjusted for it, let's bring in the
> necessary device tree changes.
Possibly a comment to say that the VEC and PV3 are deliberately NOT
enabled as the VEC requires further very specific clock setup changes?
> Signed-off-by: Maxime Ripard
Otherwise
Reviewed-by: Dave Stevenson
> ---
> arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 46 +++-
> arch/arm/boot/dts/bcm2711.dtsi| 115 ++-
> 2 files changed, 160 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> index 222d7825e1ab..b93eb30e1ddb 100644
> --- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> +++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> @@ -68,6 +68,14 @@
> };
> };
>
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> {
> firmware_clocks: clocks {
> compatible = "raspberrypi,firmware-clocks";
> @@ -163,6 +171,36 @@
> "RGMII_TXD3";
> };
>
> + {
> + clocks = <_clocks 13>, < 0>;
> + status = "okay";
> +};
> +
> + {
> + clocks = <_clocks 13>, < 1>;
> + status = "okay";
> +};
> +
> + {
> + clocks = <_clocks 4>;
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> {
> pinctrl-names = "default";
> pinctrl-0 = <_0_gpio40 _1_gpio41>;
> @@ -231,3 +269,11 @@
> {
> interrupts = ;
> };
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "disabled";
> +};
> diff --git a/arch/arm/boot/dts/bcm2711.dtsi b/arch/arm/boot/dts/bcm2711.dtsi
> index 00bcaed1be32..e637378650f6 100644
> --- a/arch/arm/boot/dts/bcm2711.dtsi
> +++ b/arch/arm/boot/dts/bcm2711.dtsi
> @@ -12,6 +12,11 @@
>
> interrupt-parent = <>;
>
> + vc4: gpu {
> + compatible = "brcm,bcm2711-vc5";
> + status = "disabled";
> + };
> +
> clk_108MHz: clk-108M {
> #clock-cells = <0>;
> compatible = "fixed-clock";
> @@ -238,6 +243,27 @@
> status = "disabled";
> };
>
> + pixelvalve0: pixelvalve@7e206000 {
> + compatible = "brcm,bcm2711-pixelvalve0";
> + reg = <0x7e206000 0x100>;
> + interrupts = ;
> + status = "disabled";
> + };
> +
> + pixelvalve1: pixelvalve@7e207000 {
> + compatible = "brcm,bcm2711-pixelvalve1";
> + reg = <0x7e207000 0x100>;
> + interrupts = ;
> + status = "disabled";
> + };
> +
> + pixelvalve2: pixelvalve@7e20a000 {
> + compatible = "brcm,bcm2711-pixelvalve2";
> + reg = <0x7e20a000 0x100>;
> + interrupts = ;
> + status = "disabled";
> + };
> +
> pwm1: pwm@7e20c800 {
> compatible = "brcm,bcm2835-pwm";
> reg = <0x7e20c800 0x28>;
> @@ -248,10 +274,25 @@
> status = "disabled";
> };
>
> - hvs@7e40 {
> + pixelvalve4: pixelvalve@7e216000 {
> + compatible = "brcm,bcm2711-pixelvalve4";
> + reg = <0x7e216000 0x100>;
> + interrupts = ;
> + status = "disabled";
> + };
> +
> + hvs: hvs@7e40 {
> + compatible = "brcm,bcm2711-hvs";
> interrupts = ;
> };
>
> + pixelvalve3: pixelvalve@7ec12000 {
> + compatible = "brcm,bcm2711-pixelvalve3";
> + reg = <0x7ec12000 0x100>;
> + interrupts = ;
> + status = "disabled";
> +
Re: [PATCH v4 77/78] drm/vc4: drv: Support BCM2711
Hi Maxime
On Wed, 8 Jul 2020 at 18:44, Maxime Ripard wrote:
>
> The BCM2711 has a reworked display pipeline, and the load tracker needs
> some adjustement to operate properly. Let's add a compatible for BCM2711
s/adjustement/adjustment
> and disable the load tracker until properly supported.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/vc4/vc4_drv.c | 1 +-
> drivers/gpu/drm/vc4/vc4_drv.h | 3 ++-
> drivers/gpu/drm/vc4/vc4_kms.c | 42 +++---
> drivers/gpu/drm/vc4/vc4_plane.c | 5 -
> 4 files changed, 38 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
> index 9567d1019212..f1a5fd5dab6f 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.c
> +++ b/drivers/gpu/drm/vc4/vc4_drv.c
> @@ -372,6 +372,7 @@ static int vc4_platform_drm_remove(struct platform_device
> *pdev)
> }
>
> static const struct of_device_id vc4_of_match[] = {
> + { .compatible = "brcm,bcm2711-vc5", },
> { .compatible = "brcm,bcm2835-vc4", },
> { .compatible = "brcm,cygnus-vc4", },
> {},
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index 501a48a714d3..8c8d96b6289f 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -200,6 +200,9 @@ struct vc4_dev {
>
> int power_refcount;
>
> + /* Set to true when the load tracker is supported. */
> + bool load_tracker_available;
> +
> /* Set to true when the load tracker is active. */
> bool load_tracker_enabled;
>
> diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> index 7c8a87339959..ae479f988666 100644
> --- a/drivers/gpu/drm/vc4/vc4_kms.c
> +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> @@ -532,6 +532,9 @@ static int vc4_load_tracker_atomic_check(struct
> drm_atomic_state *state)
> struct drm_plane *plane;
> int i;
>
> + if (!vc4->load_tracker_available)
> + return 0;
> +
> priv_state = drm_atomic_get_private_obj_state(state,
> >load_tracker);
> if (IS_ERR(priv_state))
> @@ -681,10 +684,14 @@ int vc4_kms_load(struct drm_device *dev)
> struct vc4_load_tracker_state *load_state;
> int ret;
>
> - /* Start with the load tracker enabled. Can be disabled through the
> -* debugfs load_tracker file.
> -*/
> - vc4->load_tracker_enabled = true;
> + if (!of_device_is_compatible(dev->dev->of_node, "brcm,bcm2711-vc5")) {
Is it better to look up the compatible string, or pass something via
the .data element of the of_device_id table? Probably down to personal
preference?
> + vc4->load_tracker_available = true;
> +
> + /* Start with the load tracker enabled. Can be
> +* disabled through the debugfs load_tracker file.
> +*/
> + vc4->load_tracker_enabled = true;
> + }
>
> sema_init(>async_modeset, 1);
>
> @@ -698,8 +705,14 @@ int vc4_kms_load(struct drm_device *dev)
> return ret;
> }
>
> - dev->mode_config.max_width = 2048;
> - dev->mode_config.max_height = 2048;
> + if (of_device_is_compatible(dev->dev->of_node, "brcm,bcm2711-vc5")) {
We're making the same of_device_is_compatible call twice within
vc4_kms_load. Set a flag based on it and check that instead?
Dave
> + dev->mode_config.max_width = 7680;
> + dev->mode_config.max_height = 7680;
> + } else {
> + dev->mode_config.max_width = 2048;
> + dev->mode_config.max_height = 2048;
> + }
> +
> dev->mode_config.funcs = _mode_funcs;
> dev->mode_config.preferred_depth = 24;
> dev->mode_config.async_page_flip = true;
> @@ -714,14 +727,17 @@ int vc4_kms_load(struct drm_device *dev)
> drm_atomic_private_obj_init(dev, >ctm_manager, _state->base,
> _ctm_state_funcs);
>
> - load_state = kzalloc(sizeof(*load_state), GFP_KERNEL);
> - if (!load_state) {
> - drm_atomic_private_obj_fini(>ctm_manager);
> - return -ENOMEM;
> - }
> + if (vc4->load_tracker_available) {
> + load_state = kzalloc(sizeof(*load_state), GFP_KERNEL);
> + if (!load_state) {
> + drm_atomic_private_obj_fini(>ctm_manager);
> + return -ENOMEM;
> + }
>
> - drm_atomic_private_obj_init(dev, >load_tracker,
> _state->base,
> - _load_tracker_state_funcs);
> + drm_atomic_private_obj_init(dev, >load_tracker,
> + _state->base,
> + _load_tracker_state_funcs);
> + }
>
> drm_mode_config_reset(dev);
>
> diff --git a/drivers/gpu/drm/vc4/vc4_plane.c
Re: [PATCH v4 29/78] drm/vc4: crtc: Add a delay after disabling the PixelValve output
Hi Maxime On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > In order to avoid pixels getting stuck in the (unflushable) FIFO between > the HVS and the PV, we need to add some delay after disabling the PV output > and before disabling the HDMI controller. 20ms seems to be good enough so > let's use that. > > Signed-off-by: Maxime Ripard > --- > drivers/gpu/drm/vc4/vc4_crtc.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c > index d0b326e1df0a..7b178d67187f 100644 > --- a/drivers/gpu/drm/vc4/vc4_crtc.c > +++ b/drivers/gpu/drm/vc4/vc4_crtc.c > @@ -403,6 +403,8 @@ static void vc4_crtc_atomic_disable(struct drm_crtc *crtc, > ret = wait_for(!(CRTC_READ(PV_V_CONTROL) & PV_VCONTROL_VIDEN), 1); > WARN_ONCE(ret, "Timeout waiting for !PV_VCONTROL_VIDEN\n"); > > + mdelay(20); mdelay for 20ms seems a touch unfriendly as it's a busy wait. Can we not msleep instead? Dave > + > if (vc4_encoder->post_crtc_disable) > vc4_encoder->post_crtc_disable(encoder); > > -- > git-series 0.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 14/78] drm/vc4: crtc: Assign output to channel automatically
Hi Maxime
On Wed, 8 Jul 2020 at 18:42, Maxime Ripard wrote:
>
> The HVS found in the BCM2711 has 6 outputs and 3 FIFOs, with each output
> being connected to a pixelvalve, and some muxing between the FIFOs and
> outputs.
>
> Any output cannot feed from any FIFO though, and they all have a bunch of
> constraints.
>
> In order to support this, let's store the possible FIFOs each output can be
> assigned to in the vc4_crtc_data, and use that information at atomic_check
> time to iterate over all the CRTCs enabled and assign them FIFOs.
>
> The channel assigned is then set in the vc4_crtc_state so that the rest of
> the driver can use it.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 12 +-
> drivers/gpu/drm/vc4/vc4_drv.h | 7 +-
> drivers/gpu/drm/vc4/vc4_hvs.c | 28 ++
> drivers/gpu/drm/vc4/vc4_kms.c | 167 +-
> drivers/gpu/drm/vc4/vc4_regs.h | 10 ++-
> drivers/gpu/drm/vc4/vc4_txp.c | 1 +-
> 6 files changed, 199 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index fe2e5675aed4..b7e47ce1476c 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -88,6 +88,7 @@ static bool vc4_crtc_get_scanout_position(struct drm_crtc
> *crtc,
> struct drm_device *dev = crtc->dev;
> struct vc4_dev *vc4 = to_vc4_dev(dev);
> struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
> + struct vc4_crtc_state *vc4_crtc_state =
> to_vc4_crtc_state(crtc->state);
> unsigned int cob_size;
> u32 val;
> int fifo_lines;
> @@ -104,7 +105,7 @@ static bool vc4_crtc_get_scanout_position(struct drm_crtc
> *crtc,
> * Read vertical scanline which is currently composed for our
> * pixelvalve by the HVS, and also the scaler status.
> */
> - val = HVS_READ(SCALER_DISPSTATX(vc4_crtc->channel));
> + val = HVS_READ(SCALER_DISPSTATX(vc4_crtc_state->assigned_channel));
>
> /* Get optional system timestamp after query. */
> if (etime)
> @@ -124,7 +125,7 @@ static bool vc4_crtc_get_scanout_position(struct drm_crtc
> *crtc,
> *hpos += mode->crtc_htotal / 2;
> }
>
> - cob_size = vc4_crtc_get_cob_allocation(vc4, vc4_crtc->channel);
> + cob_size = vc4_crtc_get_cob_allocation(vc4,
> vc4_crtc_state->assigned_channel);
> /* This is the offset we need for translating hvs -> pv scanout pos.
> */
> fifo_lines = cob_size / mode->crtc_hdisplay;
>
> @@ -520,7 +521,7 @@ static void vc4_crtc_handle_page_flip(struct vc4_crtc
> *vc4_crtc)
> struct drm_device *dev = crtc->dev;
> struct vc4_dev *vc4 = to_vc4_dev(dev);
> struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
> - u32 chan = vc4_crtc->channel;
> + u32 chan = vc4_state->assigned_channel;
> unsigned long flags;
>
> spin_lock_irqsave(>event_lock, flags);
> @@ -719,6 +720,7 @@ struct drm_crtc_state *vc4_crtc_duplicate_state(struct
> drm_crtc *crtc)
> old_vc4_state = to_vc4_crtc_state(crtc->state);
> vc4_state->feed_txp = old_vc4_state->feed_txp;
> vc4_state->margins = old_vc4_state->margins;
> + vc4_state->assigned_channel = old_vc4_state->assigned_channel;
>
> __drm_atomic_helper_crtc_duplicate_state(crtc, _state->base);
> return _state->base;
> @@ -779,6 +781,7 @@ static const struct drm_crtc_helper_funcs
> vc4_crtc_helper_funcs = {
>
> static const struct vc4_pv_data bcm2835_pv0_data = {
> .base = {
> + .hvs_available_channels = BIT(0),
> .hvs_output = 0,
> },
> .debugfs_name = "crtc0_regs",
> @@ -791,6 +794,7 @@ static const struct vc4_pv_data bcm2835_pv0_data = {
>
> static const struct vc4_pv_data bcm2835_pv1_data = {
> .base = {
> + .hvs_available_channels = BIT(2),
> .hvs_output = 2,
> },
> .debugfs_name = "crtc1_regs",
> @@ -803,6 +807,7 @@ static const struct vc4_pv_data bcm2835_pv1_data = {
>
> static const struct vc4_pv_data bcm2835_pv2_data = {
> .base = {
> + .hvs_available_channels = BIT(1),
> .hvs_output = 1,
> },
> .debugfs_name = "crtc2_regs",
> @@ -866,7 +871,6 @@ int vc4_crtc_init(struct drm_device *drm, struct vc4_crtc
> *vc4_crtc,
> drm_crtc_init_with_planes(drm, crtc, primary_plane, NULL,
>
Re: [PATCH v4 23/78] drm/vc4: crtc: Move the HVS gamma LUT setup to our init function
Hi Maxime
On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote:
>
> Since most of the HVS channel is setup in the init function, let's move the
> gamma setup there too. As this makes the HVS mode_set function empty, let's
> remove it in the process.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 2 +-
> drivers/gpu/drm/vc4/vc4_drv.h | 1 +-
> drivers/gpu/drm/vc4/vc4_hvs.c | 59 +--
> drivers/gpu/drm/vc4/vc4_txp.c | 1 +-
> 4 files changed, 16 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index 181d3fd57bc7..284a85b9d7d4 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -379,8 +379,6 @@ static void vc4_crtc_config_pv(struct drm_crtc *crtc)
> static void vc4_crtc_mode_set_nofb(struct drm_crtc *crtc)
> {
> vc4_crtc_config_pv(crtc);
> -
> - vc4_hvs_mode_set_nofb(crtc);
> }
>
> static void require_hvs_enabled(struct drm_device *dev)
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index 4126506b3a69..dfcc684f5d28 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -904,7 +904,6 @@ int vc4_hvs_atomic_check(struct drm_crtc *crtc, struct
> drm_crtc_state *state);
> void vc4_hvs_atomic_enable(struct drm_crtc *crtc, struct drm_crtc_state
> *old_state);
> void vc4_hvs_atomic_disable(struct drm_crtc *crtc, struct drm_crtc_state
> *old_state);
> void vc4_hvs_atomic_flush(struct drm_crtc *crtc, struct drm_crtc_state
> *state);
> -void vc4_hvs_mode_set_nofb(struct drm_crtc *crtc);
> void vc4_hvs_dump_state(struct drm_device *dev);
> void vc4_hvs_unmask_underrun(struct drm_device *dev, int channel);
> void vc4_hvs_mask_underrun(struct drm_device *dev, int channel);
> diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
> index 78bb1c0b0b76..c7de77afbf0a 100644
> --- a/drivers/gpu/drm/vc4/vc4_hvs.c
> +++ b/drivers/gpu/drm/vc4/vc4_hvs.c
> @@ -201,6 +201,8 @@ static int vc4_hvs_init_channel(struct vc4_dev *vc4,
> struct drm_crtc *crtc,
> {
> struct vc4_crtc_state *vc4_crtc_state =
> to_vc4_crtc_state(crtc->state);
> unsigned int chan = vc4_crtc_state->assigned_channel;
> + bool interlace = mode->flags & DRM_MODE_FLAG_INTERLACE;
> + u32 dispbkgndx;
> u32 dispctrl;
>
> /* Turn on the scaler, which will wait for vstart to start
> @@ -225,6 +227,20 @@ static int vc4_hvs_init_channel(struct vc4_dev *vc4,
> struct drm_crtc *crtc,
>
> HVS_WRITE(SCALER_DISPCTRLX(chan), dispctrl);
>
> + dispbkgndx = HVS_READ(SCALER_DISPBKGNDX(chan));
> + dispbkgndx &= ~SCALER_DISPBKGND_GAMMA;
> + dispbkgndx &= ~SCALER_DISPBKGND_INTERLACE;
> +
> + HVS_WRITE(SCALER_DISPBKGNDX(chan), dispbkgndx |
> + SCALER_DISPBKGND_AUTOHS |
> + ((!vc4->hvs->hvs5) ? SCALER_DISPBKGND_GAMMA : 0) |
> + (interlace ? SCALER_DISPBKGND_INTERLACE : 0));
> +
> + /* Reload the LUT, since the SRAMs would have been disabled if
> +* all CRTCs had SCALER_DISPBKGND_GAMMA unset at once.
> +*/
> + vc4_hvs_lut_load(crtc);
> +
> return 0;
> }
>
> @@ -421,49 +437,6 @@ void vc4_hvs_atomic_flush(struct drm_crtc *crtc,
> }
> }
>
> -void vc4_hvs_mode_set_nofb(struct drm_crtc *crtc)
> -{
> - struct drm_device *dev = crtc->dev;
> - struct vc4_dev *vc4 = to_vc4_dev(dev);
> - struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(crtc->state);
> - struct drm_display_mode *mode = >state->adjusted_mode;
> - bool interlace = mode->flags & DRM_MODE_FLAG_INTERLACE;
> -
> - if (vc4_state->assigned_channel == 2) {
> - u32 dispctrl;
> - u32 dsp3_mux;
> -
> - /*
> -* SCALER_DISPCTRL_DSP3 = X, where X < 2 means 'connect DSP3
> to
> -* FIFO X'.
> -* SCALER_DISPCTRL_DSP3 = 3 means 'disable DSP 3'.
> -*
> -* DSP3 is connected to FIFO2 unless the transposer is
> -* enabled. In this case, FIFO 2 is directly accessed by the
> -* TXP IP, and we need to disable the FIFO2 -> pixelvalve1
> -* route.
> -*/
> - if (vc4_state->feed_txp)
> - dsp3_mux = VC4_SET_FIELD(3, SCALER_DISPCTRL_DSP3_MUX);
> - else
> - dsp3_mux = VC4_SET_FIELD(2, SCALER_DISPCTRL_DSP3_MUX)
Re: [PATCH v4 29/78] drm/vc4: crtc: Add a delay after disabling the PixelValve output
On Wed, 29 Jul 2020 at 15:42, Maxime Ripard wrote: > > Hi, > > On Wed, Jul 29, 2020 at 03:09:21PM +0100, Dave Stevenson wrote: > > On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: > > > > > > In order to avoid pixels getting stuck in the (unflushable) FIFO between > > > the HVS and the PV, we need to add some delay after disabling the PV > > > output > > > and before disabling the HDMI controller. 20ms seems to be good enough so > > > let's use that. > > > > > > Signed-off-by: Maxime Ripard > > > --- > > > drivers/gpu/drm/vc4/vc4_crtc.c | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c > > > b/drivers/gpu/drm/vc4/vc4_crtc.c > > > index d0b326e1df0a..7b178d67187f 100644 > > > --- a/drivers/gpu/drm/vc4/vc4_crtc.c > > > +++ b/drivers/gpu/drm/vc4/vc4_crtc.c > > > @@ -403,6 +403,8 @@ static void vc4_crtc_atomic_disable(struct drm_crtc > > > *crtc, > > > ret = wait_for(!(CRTC_READ(PV_V_CONTROL) & PV_VCONTROL_VIDEN), 1); > > > WARN_ONCE(ret, "Timeout waiting for !PV_VCONTROL_VIDEN\n"); > > > > > > + mdelay(20); > > > > mdelay for 20ms seems a touch unfriendly as it's a busy wait. Can we > > not msleep instead? > > Since the timing was fairly critical, sleeping didn't seem like a good > solution since there's definitely some chance you overshoot and end up > with a higher time than the one you targeted. Fair enough. I know timing is "entertaining" around some of the 2711 pipeline setup. Reviewed-by: Dave Stevenson ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 13/78] drm/vc4: kms: Convert to for_each_new_crtc_state
Hi Maxime
On Wed, 8 Jul 2020 at 18:42, Maxime Ripard wrote:
>
> The vc4 atomic commit loop has an handrolled loop that is basically
> identical to for_each_new_crtc_state, let's convert it to that helper.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/vc4/vc4_kms.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> index 210cc2408087..717673b18132 100644
> --- a/drivers/gpu/drm/vc4/vc4_kms.c
> +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> @@ -152,14 +152,13 @@ vc4_atomic_complete_commit(struct drm_atomic_state
> *state)
> struct drm_device *dev = state->dev;
> struct vc4_dev *vc4 = to_vc4_dev(dev);
> struct vc4_hvs *hvs = vc4->hvs;
> - struct vc4_crtc *vc4_crtc;
> + struct drm_crtc_state *new_crtc_state;
> + struct drm_crtc *crtc;
> int i;
>
> - for (i = 0; i < dev->mode_config.num_crtc; i++) {
> - if (!state->crtcs[i].ptr || !state->crtcs[i].commit)
> - continue;
> + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
> + struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
for_each_new_crtc_in_state doesn't check !state->crtcs[i].commit as
the hand rolled loop did. Sorry, this is my lack of knowledge, but
does that actually make any real difference?
I see nothing wrong in calling vc4_hvs_mask_underrun multiple times
anyway, so it's most likely going to be harmless anyway, but wanted to
query it.
Dave
>
> - vc4_crtc = to_vc4_crtc(state->crtcs[i].ptr);
> vc4_hvs_mask_underrun(dev, vc4_crtc->channel);
> }
>
> --
> git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] drm/vc4: DSI improvements and BCM2711 support
Hi Maxime On Thu, 3 Dec 2020 at 13:25, Maxime Ripard wrote: > > Hi, > > Here's a series adding support for the DSI0 controller in the BCM2835 and the > DSI1 controller found in the BCM2711. > > Let me know what you think, > Maxime Thanks for that series - your using a variant structure is much cleaner than the hack I had. For those that I didn't author (ie 1, 3, and 4) Reviewed-by: Dave Stevenson > Dave Stevenson (5): > drm/vc4: dsi: Correct DSI register definition > drm/vc4: dsi: Add support for DSI0 > dt-bindings: Add compatible for BCM2711 DSI1 > drm/vc4: dsi: Add configuration for BCM2711 DSI1 > ARM: dts: bcm2711: Use compatible string for BCM2711 DSI1 > > Maxime Ripard (3): > drm/vc4: drv: Remove the DSI pointer in vc4_drv > drm/vc4: dsi: Use snprintf for the PHY clocks instead of an array > drm/vc4: dsi: Introduce a variant structure > > .../bindings/display/brcm,bcm2835-dsi0.yaml | 1 + > arch/arm/boot/dts/bcm2711.dtsi| 1 + > drivers/gpu/drm/vc4/vc4_drv.h | 1 - > drivers/gpu/drm/vc4/vc4_dsi.c | 111 ++ > 4 files changed, 67 insertions(+), 47 deletions(-) > > -- > 2.28.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V3 1/2] dt-bindings: Add DT bindings for Toshiba TC358762 DSI-to-DPI bridge
Hi Marek
On Wed, 12 Aug 2020 at 21:07, Sam Ravnborg wrote:
>
> Hi Marek.
>
> On Sun, Aug 09, 2020 at 12:57:04PM +0200, Marek Vasut wrote:
> > Add DT bindings for Toshiba TC358762 DSI-to-DPI bridge, this
> > one is used in the Raspberry Pi 7" touchscreen display unit.
> >
> > Signed-off-by: Marek Vasut
> > To: dri-devel@lists.freedesktop.org
> > Cc: Eric Anholt
> > Cc: Rob Herring
> > Cc: Sam Ravnborg
> > Cc: devicet...@vger.kernel.org
> > ---
> > V2: Fix dt_binding_check errors
> > V3: Add ... at the end of example
>
> With Rob's r-b it is now applied to drm-misc-next.
>
> Sam
>
> > ---
> > .../display/bridge/toshiba,tc358762.yaml | 127 ++
> > 1 file changed, 127 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
> > b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
> > new file mode 100644
> > index ..195025e6803c
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358762.yaml
> > @@ -0,0 +1,127 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/bridge/toshiba,tc358762.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Toshiba TC358762 MIPI DSI to MIPI DPI bridge
> > +
> > +maintainers:
> > + - Marek Vasut
> > +
> > +description: |
> > + The TC358762 is bridge device which converts MIPI DSI to MIPI DPI.
> > +
> > +properties:
> > + compatible:
> > +enum:
> > + - toshiba,tc358762
> > +
> > + reg:
> > +maxItems: 1
> > +description: virtual channel number of a DSI peripheral
> > +
> > + vddc-supply:
> > +description: Regulator for 1.2V internal core power.
> > +
> > + ports:
> > +type: object
> > +
> > +properties:
> > + "#address-cells":
> > +const: 1
> > +
> > + "#size-cells":
> > +const: 0
> > +
> > + port@0:
> > +type: object
> > +additionalProperties: false
> > +
> > +description: |
> > + Video port for MIPI DSI input
> > +
> > +properties:
> > + reg:
> > +const: 0
> > +
> > +patternProperties:
> > + endpoint:
> > +type: object
> > +additionalProperties: false
> > +
> > +properties:
> > + remote-endpoint: true
> > +
> > +required:
> > + - reg
> > +
> > + port@1:
> > +type: object
> > +additionalProperties: false
> > +
> > +description: |
> > + Video port for MIPI DPI output (panel or connector).
> > +
> > +properties:
> > + reg:
> > +const: 1
> > +
> > +patternProperties:
> > + endpoint:
> > +type: object
> > +additionalProperties: false
> > +
> > +properties:
> > + remote-endpoint: true
> > +
> > +required:
> > + - reg
> > +
> > +required:
> > + - "#address-cells"
> > + - "#size-cells"
> > + - port@0
> > + - port@1
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - vddc-supply
> > + - ports
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +i2c1 {
Minor point.
I've just come to use this and noticed that this example puts the
device under i2c1. Seeing as it's a DSI driver with no I2C
interaction, shouldn't it be under a dsi node?
Thanks
Dave
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + bridge@0 {
> > +reg = <0>;
> > +compatible = "toshiba,tc358762";
> > +vddc-supply = <_1v2_reg>;
> > +
> > +ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > +reg = <0>;
> > +bridge_in: endpoint {
> > + remote-endpoint = <_out>;
> > +};
> > + };
> > +
> > + port@1 {
> > +reg = <1>;
> > +bridge_out: endpoint {
> > + remote-endpoint = <_in>;
> > +};
> > + };
> > +};
> > + };
> > +};
> > +
> > +...
> > --
> > 2.28.0
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 3/9] drm/vc4: hdmi: Take into account the clock doubling flag in atomic_check
Hi Maxime
On Mon, 7 Dec 2020 at 15:57, Maxime Ripard wrote:
>
> Reported-by: Thomas Zimmermann
> Fixes: 63495f6b4aed ("drm/vc4: hdmi: Make sure our clock rate is within
> limits")
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 5a608ed1d75e..a88aa20beeb6 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -796,6 +796,9 @@ static int vc4_hdmi_encoder_atomic_check(struct
> drm_encoder *encoder,
> pixel_rate = mode->clock * 1000;
> }
>
> + if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> + pixel_rate = pixel_rate * 2;
> +
> if (pixel_rate > vc4_hdmi->variant->max_pixel_clock)
> return -EINVAL;
>
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 6/9] drm/vc4: hdmi: Store pixel frequency in the connector state
Hi Maxime
On Mon, 7 Dec 2020 at 15:57, Maxime Ripard wrote:
>
> The pixel rate is for now quite simple to compute, but with more features
> (30 and 36 bits output, YUV output, etc.) will depend on a bunch of
> connectors properties.
>
> Let's store the rate we have to run the pixel clock at in our custom
> connector state, and compute it in atomic_check.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 26 +-
> drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
> 2 files changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 744396c8dcb9..83699105c7a5 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -194,6 +194,7 @@ vc4_hdmi_connector_duplicate_state(struct drm_connector
> *connector)
> if (!new_state)
> return NULL;
>
> + new_state->pixel_rate = vc4_state->pixel_rate;
> __drm_atomic_helper_connector_duplicate_state(connector,
> _state->base);
>
> return _state->base;
> @@ -611,9 +612,29 @@ static void vc4_hdmi_recenter_fifo(struct vc4_hdmi
> *vc4_hdmi)
> "VC4_HDMI_FIFO_CTL_RECENTER_DONE");
> }
>
> +static struct drm_connector_state *
> +vc4_hdmi_encoder_get_connector_state(struct drm_encoder *encoder,
> +struct drm_atomic_state *state)
> +{
> + struct drm_connector_state *conn_state;
> + struct drm_connector *connector;
> + unsigned int i;
> +
> + for_each_new_connector_in_state(state, connector, conn_state, i) {
> + if (conn_state->best_encoder == encoder)
> + return conn_state;
> + }
> +
> + return NULL;
> +}
> +
> static void vc4_hdmi_encoder_pre_crtc_configure(struct drm_encoder *encoder,
> struct drm_atomic_state
> *state)
> {
> + struct drm_connector_state *conn_state =
> + vc4_hdmi_encoder_get_connector_state(encoder, state);
> + struct vc4_hdmi_connector_state *vc4_conn_state =
> + conn_state_to_vc4_hdmi_conn_state(conn_state);
> struct drm_display_mode *mode = >crtc->state->adjusted_mode;
> struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> unsigned long pixel_rate, hsm_rate;
> @@ -625,7 +646,7 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
> drm_encoder *encoder,
> return;
> }
>
> - pixel_rate = mode->clock * 1000 * ((mode->flags &
> DRM_MODE_FLAG_DBLCLK) ? 2 : 1);
> + pixel_rate = vc4_conn_state->pixel_rate;
> ret = clk_set_rate(vc4_hdmi->pixel_clock, pixel_rate);
> if (ret) {
> DRM_ERROR("Failed to set pixel clock rate: %d\n", ret);
> @@ -797,6 +818,7 @@ static int vc4_hdmi_encoder_atomic_check(struct
> drm_encoder *encoder,
> struct drm_crtc_state *crtc_state,
> struct drm_connector_state
> *conn_state)
> {
> + struct vc4_hdmi_connector_state *vc4_state =
> conn_state_to_vc4_hdmi_conn_state(conn_state);
> struct drm_display_mode *mode = _state->adjusted_mode;
> struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> unsigned long long pixel_rate = mode->clock * 1000;
> @@ -827,6 +849,8 @@ static int vc4_hdmi_encoder_atomic_check(struct
> drm_encoder *encoder,
> if (pixel_rate > vc4_hdmi->variant->max_pixel_clock)
> return -EINVAL;
>
> + vc4_state->pixel_rate = pixel_rate;
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index 2cf5362052e2..bca6943de884 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -182,6 +182,7 @@ encoder_to_vc4_hdmi(struct drm_encoder *encoder)
>
> struct vc4_hdmi_connector_state {
> struct drm_connector_state base;
> + unsigned long long pixel_rate;
> };
>
> static inline struct vc4_hdmi_connector_state *
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 7/9] drm/vc4: hdmi: Use the connector state pixel rate for the PHY
Hi Maxime
On Mon, 7 Dec 2020 at 15:57, Maxime Ripard wrote:
>
> The PHY initialisation parameters are not based on the pixel clock but
> the TMDS clock rate which can be the pixel clock in the standard case,
> but could be adjusted based on some parameters like the bits per color.
>
> Since the TMDS clock rate is stored in our custom connector state
> already, let's reuse it from there instead of computing it again.
>
> Acked-by: Thomas Zimmermann
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
> drivers/gpu/drm/vc4/vc4_hdmi.h | 11 +--
> drivers/gpu/drm/vc4/vc4_hdmi_phy.c | 8 +---
> 3 files changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 83699105c7a5..5310e06efc82 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -714,7 +714,7 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
> drm_encoder *encoder,
> vc4_hdmi->variant->reset(vc4_hdmi);
>
> if (vc4_hdmi->variant->phy_init)
> - vc4_hdmi->variant->phy_init(vc4_hdmi, mode);
> + vc4_hdmi->variant->phy_init(vc4_hdmi, vc4_conn_state);
>
> HDMI_WRITE(HDMI_SCHEDULER_CONTROL,
>HDMI_READ(HDMI_SCHEDULER_CONTROL) |
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index bca6943de884..60c53d7c9bad 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -21,10 +21,9 @@ to_vc4_hdmi_encoder(struct drm_encoder *encoder)
> return container_of(encoder, struct vc4_hdmi_encoder, base.base);
> }
>
> -struct drm_display_mode;
> -
> struct vc4_hdmi;
> struct vc4_hdmi_register;
> +struct vc4_hdmi_connector_state;
>
> enum vc4_hdmi_phy_channel {
> PHY_LANE_0 = 0,
> @@ -80,9 +79,9 @@ struct vc4_hdmi_variant {
> void (*set_timings)(struct vc4_hdmi *vc4_hdmi,
> struct drm_display_mode *mode);
>
> - /* Callback to initialize the PHY according to the mode */
> + /* Callback to initialize the PHY according to the connector state */
> void (*phy_init)(struct vc4_hdmi *vc4_hdmi,
> -struct drm_display_mode *mode);
> +struct vc4_hdmi_connector_state *vc4_conn_state);
>
> /* Callback to disable the PHY */
> void (*phy_disable)(struct vc4_hdmi *vc4_hdmi);
> @@ -192,13 +191,13 @@ conn_state_to_vc4_hdmi_conn_state(struct
> drm_connector_state *conn_state)
> }
>
> void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
> - struct drm_display_mode *mode);
> + struct vc4_hdmi_connector_state *vc4_conn_state);
> void vc4_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
> void vc4_hdmi_phy_rng_enable(struct vc4_hdmi *vc4_hdmi);
> void vc4_hdmi_phy_rng_disable(struct vc4_hdmi *vc4_hdmi);
>
> void vc5_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
> - struct drm_display_mode *mode);
> + struct vc4_hdmi_connector_state *vc4_conn_state);
> void vc5_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
> void vc5_hdmi_phy_rng_enable(struct vc4_hdmi *vc4_hdmi);
> void vc5_hdmi_phy_rng_disable(struct vc4_hdmi *vc4_hdmi);
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
> b/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
> index 057796b54c51..36535480f8e2 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi_phy.c
> @@ -127,7 +127,8 @@
>
> #define OSCILLATOR_FREQUENCY 5400
>
> -void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi, struct drm_display_mode
> *mode)
> +void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
> + struct vc4_hdmi_connector_state *conn_state)
> {
> /* PHY should be in reset, like
> * vc4_hdmi_encoder_disable() does.
> @@ -339,11 +340,12 @@ static void vc5_hdmi_reset_phy(struct vc4_hdmi
> *vc4_hdmi)
> HDMI_WRITE(HDMI_TX_PHY_POWERDOWN_CTL, BIT(10));
> }
>
> -void vc5_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi, struct drm_display_mode
> *mode)
> +void vc5_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
> + struct vc4_hdmi_connector_state *conn_state)
> {
> const struct phy_lane_settings *chan0_settings, *chan1_settings,
> *chan2_settings, *clock_settings;
> const struct vc4_hdmi_variant *variant = vc4_hdmi->variant;
> - unsigned long long pixel_freq = mode->clock * 1000;
> + unsigned long long pixel_freq = conn_state->pixel_rate;
> unsigned long long vco_freq;
> unsigned char word_sel;
> u8 vco_sel, vco_div;
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 8/9] drm/vc4: hdmi: Limit the BCM2711 to the max without scrambling
Hi Maxime
On Mon, 7 Dec 2020 at 15:57, Maxime Ripard wrote:
>
> Unlike the previous generations, the HSM clock limitation is way above
> what we can reach without scrambling, so let's move the maximum
> frequency we support to the maximum clock frequency without scrambling.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 5310e06efc82..f4ff6b5db484 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -82,6 +82,8 @@
> #define CEC_CLOCK_FREQ 4
> #define VC4_HSM_MID_CLOCK 149985000
>
> +#define HDMI_14_MAX_TMDS_CLK (340 * 1000 * 1000)
> +
> static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
> {
> struct drm_info_node *node = (struct drm_info_node *)m->private;
> @@ -1911,7 +1913,7 @@ static const struct vc4_hdmi_variant
> bcm2711_hdmi0_variant = {
> .encoder_type = VC4_ENCODER_TYPE_HDMI0,
> .debugfs_name = "hdmi0_regs",
> .card_name = "vc4-hdmi-0",
> - .max_pixel_clock= 29700,
> + .max_pixel_clock= HDMI_14_MAX_TMDS_CLK,
> .registers = vc5_hdmi_hdmi0_fields,
> .num_registers = ARRAY_SIZE(vc5_hdmi_hdmi0_fields),
> .phy_lane_mapping = {
> @@ -1937,7 +1939,7 @@ static const struct vc4_hdmi_variant
> bcm2711_hdmi1_variant = {
> .encoder_type = VC4_ENCODER_TYPE_HDMI1,
> .debugfs_name = "hdmi1_regs",
> .card_name = "vc4-hdmi-1",
> - .max_pixel_clock= 29700,
> + .max_pixel_clock= HDMI_14_MAX_TMDS_CLK,
> .registers = vc5_hdmi_hdmi1_fields,
> .num_registers = ARRAY_SIZE(vc5_hdmi_hdmi1_fields),
> .phy_lane_mapping = {
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 5/9] drm/vc4: hdmi: Create a custom connector state
Hi Maxime
On Mon, 7 Dec 2020 at 15:57, Maxime Ripard wrote:
>
> When run with a higher bpc than 8, the clock of the HDMI controller needs
> to be adjusted. Let's create a connector state that will be used at
> atomic_check and atomic_enable to compute and store the clock rate
> associated to the state.
>
> Acked-by: Thomas Zimmermann
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 27 +--
> drivers/gpu/drm/vc4/vc4_hdmi.h | 10 ++
> 2 files changed, 35 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 61039cc89d9d..744396c8dcb9 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -170,18 +170,41 @@ static int vc4_hdmi_connector_get_modes(struct
> drm_connector *connector)
>
> static void vc4_hdmi_connector_reset(struct drm_connector *connector)
> {
> - drm_atomic_helper_connector_reset(connector);
> + struct vc4_hdmi_connector_state *conn_state =
> kzalloc(sizeof(*conn_state), GFP_KERNEL);
> +
> + if (connector->state)
> + __drm_atomic_helper_connector_destroy_state(connector->state);
> +
> + kfree(connector->state);
> +
> + __drm_atomic_helper_connector_reset(connector, _state->base);
>
> if (connector->state)
> drm_atomic_helper_connector_tv_reset(connector);
> }
>
> +static struct drm_connector_state *
> +vc4_hdmi_connector_duplicate_state(struct drm_connector *connector)
> +{
> + struct drm_connector_state *conn_state = connector->state;
> + struct vc4_hdmi_connector_state *vc4_state =
> conn_state_to_vc4_hdmi_conn_state(conn_state);
> + struct vc4_hdmi_connector_state *new_state;
> +
> + new_state = kzalloc(sizeof(*new_state), GFP_KERNEL);
> + if (!new_state)
> + return NULL;
> +
> + __drm_atomic_helper_connector_duplicate_state(connector,
> _state->base);
> +
> + return _state->base;
> +}
> +
> static const struct drm_connector_funcs vc4_hdmi_connector_funcs = {
> .detect = vc4_hdmi_connector_detect,
> .fill_modes = drm_helper_probe_single_connector_modes,
> .destroy = vc4_hdmi_connector_destroy,
> .reset = vc4_hdmi_connector_reset,
> - .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> + .atomic_duplicate_state = vc4_hdmi_connector_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> };
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index 0526a9cf608a..2cf5362052e2 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -180,6 +180,16 @@ encoder_to_vc4_hdmi(struct drm_encoder *encoder)
> return container_of(_encoder, struct vc4_hdmi, encoder);
> }
>
> +struct vc4_hdmi_connector_state {
> + struct drm_connector_state base;
> +};
> +
> +static inline struct vc4_hdmi_connector_state *
> +conn_state_to_vc4_hdmi_conn_state(struct drm_connector_state *conn_state)
> +{
> + return container_of(conn_state, struct vc4_hdmi_connector_state,
> base);
> +}
> +
> void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
>struct drm_display_mode *mode);
> void vc4_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 9/9] drm/vc4: hdmi: Enable 10/12 bpc output
Hi Maxime
On Mon, 7 Dec 2020 at 15:57, Maxime Ripard wrote:
>
> The BCM2711 supports higher bpc count than just 8, so let's support it in
> our driver.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 71 -
> drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
> drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 9
> 3 files changed, 80 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index f4ff6b5db484..fb30ddd842b1 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -76,6 +76,17 @@
> #define VC5_HDMI_VERTB_VSPO_SHIFT 16
> #define VC5_HDMI_VERTB_VSPO_MASK VC4_MASK(29, 16)
>
> +#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_SHIFT 8
> +#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_MASK VC4_MASK(10,
> 8)
> +
> +#define VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_SHIFT 0
> +#define VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_MASK VC4_MASK(3, 0)
> +
> +#define VC5_HDMI_GCP_CONFIG_GCP_ENABLE BIT(31)
> +
> +#define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_SHIFT 8
> +#define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_MASK VC4_MASK(15, 8)
> +
> # define VC4_HD_M_SW_RST BIT(2)
> # define VC4_HD_M_ENABLE BIT(0)
>
> @@ -179,6 +190,9 @@ static void vc4_hdmi_connector_reset(struct drm_connector
> *connector)
>
> kfree(connector->state);
>
> + conn_state->base.max_bpc = 8;
> + conn_state->base.max_requested_bpc = 8;
> +
Having added protection from the kzalloc failing in 4/9, this adds
back in dereferencing conn_state without having checked it succeeded
first :(
Otherwise this looks fine.
Dave
> __drm_atomic_helper_connector_reset(connector, _state->base);
>
> if (connector->state)
> @@ -228,12 +242,20 @@ static int vc4_hdmi_connector_init(struct drm_device
> *dev,
> vc4_hdmi->ddc);
> drm_connector_helper_add(connector, _hdmi_connector_helper_funcs);
>
> + /*
> +* Some of the properties below require access to state, like bpc.
> +* Allocate some default initial connector state with our reset
> helper.
> +*/
> + if (connector->funcs->reset)
> + connector->funcs->reset(connector);
> +
> /* Create and attach TV margin props to this connector. */
> ret = drm_mode_create_tv_margin_properties(dev);
> if (ret)
> return ret;
>
> drm_connector_attach_tv_margin_properties(connector);
> + drm_connector_attach_max_bpc_property(connector, 8, 12);
>
> connector->polled = (DRM_CONNECTOR_POLL_CONNECT |
> DRM_CONNECTOR_POLL_DISCONNECT);
> @@ -499,6 +521,7 @@ static void vc5_hdmi_csc_setup(struct vc4_hdmi *vc4_hdmi,
> bool enable)
> }
>
> static void vc4_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
> +struct drm_connector_state *state,
> struct drm_display_mode *mode)
> {
> bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
> @@ -542,7 +565,9 @@ static void vc4_hdmi_set_timings(struct vc4_hdmi
> *vc4_hdmi,
> HDMI_WRITE(HDMI_VERTB0, vertb_even);
> HDMI_WRITE(HDMI_VERTB1, vertb);
> }
> +
> static void vc5_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
> +struct drm_connector_state *state,
> struct drm_display_mode *mode)
> {
> bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
> @@ -562,6 +587,9 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi
> *vc4_hdmi,
> mode->crtc_vsync_end -
> interlaced,
> VC4_HDMI_VERTB_VBP));
> + unsigned char gcp;
> + bool gcp_en;
> + u32 reg;
>
> HDMI_WRITE(HDMI_VEC_INTERFACE_XBAR, 0x354021);
> HDMI_WRITE(HDMI_HORZA,
> @@ -587,6 +615,39 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi
> *vc4_hdmi,
> HDMI_WRITE(HDMI_VERTB0, vertb_even);
> HDMI_WRITE(HDMI_VERTB1, vertb);
>
> + switch (state->max_bpc) {
> + case 12:
> + gcp = 6;
> + gcp_en = true;
> + break;
> + case 10:
> + gcp = 5;
> + gcp_en = true;
> + break;
> + case 8:
> + default:
> + gcp = 4;
> + gcp_en = false;
> + break;
> + }
> +
> + reg = HDMI_READ(HDMI_DEEP_COLOR_CONFIG_1);
> + reg &= ~(VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_MASK |
> +VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_MASK);
> + reg |= VC4_SET_FIELD(2, VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE)
> |
> + VC4_SET_FIELD(gcp,
Re: [PATCH v5 4/9] drm/vc4: hdmi: Don't access the connector state in reset if kmalloc fails
Hi Maxime
On Mon, 7 Dec 2020 at 15:57, Maxime Ripard wrote:
>
> drm_atomic_helper_connector_reset uses kmalloc which, from an API
> standpoint, can fail, and thus setting connector->state to NULL.
> However, our reset hook then calls drm_atomic_helper_connector_tv_reset
> that will access connector->state without checking if it's a valid
> pointer or not.
>
> Make sure we don't end up accessing a NULL pointer.
>
> Acked-by: Thomas Zimmermann
> Suggested-by: Dave Stevenson
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index a88aa20beeb6..61039cc89d9d 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -171,7 +171,9 @@ static int vc4_hdmi_connector_get_modes(struct
> drm_connector *connector)
> static void vc4_hdmi_connector_reset(struct drm_connector *connector)
> {
> drm_atomic_helper_connector_reset(connector);
> - drm_atomic_helper_connector_tv_reset(connector);
> +
> + if (connector->state)
> + drm_atomic_helper_connector_tv_reset(connector);
> }
>
> static const struct drm_connector_funcs vc4_hdmi_connector_funcs = {
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/vc4: hdmi: Don't poll for the infoframes status on setup
Hi Maxime
On Thu, 3 Dec 2020 at 07:46, Maxime Ripard wrote:
>
> The infoframes are sent at a regular interval as a data island packet,
> so we don't need to wait for them to be sent when we're setting them up.
>
> However, we do need to poll when we're enabling since the we can't
> update the packet RAM until it has been sent.
>
> Let's add a boolean flag to tell whether we want to poll or not to
> support both cases.
>
> Suggested-by: Dave Stevenson
> Signed-off-by: Maxime Ripard
That looks like it should do what was intended - thanks.
Reviewed-by: Dave Stevenson
> ---
>
> Changes from v1:
> - Inverted when to poll
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index a2c5b5e9786a..d3c4a9b5bb6d 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -265,7 +265,8 @@ static int vc4_hdmi_connector_init(struct drm_device *dev,
> }
>
> static int vc4_hdmi_stop_packet(struct drm_encoder *encoder,
> - enum hdmi_infoframe_type type)
> + enum hdmi_infoframe_type type,
> + bool poll)
> {
> struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> u32 packet_id = type - 0x80;
> @@ -273,6 +274,9 @@ static int vc4_hdmi_stop_packet(struct drm_encoder
> *encoder,
> HDMI_WRITE(HDMI_RAM_PACKET_CONFIG,
>HDMI_READ(HDMI_RAM_PACKET_CONFIG) & ~BIT(packet_id));
>
> + if (!poll)
> + return 0;
> +
> return wait_for(!(HDMI_READ(HDMI_RAM_PACKET_STATUS) &
> BIT(packet_id)), 100);
> }
> @@ -299,7 +303,7 @@ static void vc4_hdmi_write_infoframe(struct drm_encoder
> *encoder,
> if (len < 0)
> return;
>
> - ret = vc4_hdmi_stop_packet(encoder, frame->any.type);
> + ret = vc4_hdmi_stop_packet(encoder, frame->any.type, true);
> if (ret) {
> DRM_ERROR("Failed to wait for infoframe to go idle: %d\n",
> ret);
> return;
> @@ -1056,7 +1060,7 @@ static void vc4_hdmi_audio_reset(struct vc4_hdmi
> *vc4_hdmi)
> int ret;
>
> vc4_hdmi->audio.streaming = false;
> - ret = vc4_hdmi_stop_packet(encoder, HDMI_INFOFRAME_TYPE_AUDIO);
> + ret = vc4_hdmi_stop_packet(encoder, HDMI_INFOFRAME_TYPE_AUDIO, false);
> if (ret)
> dev_err(dev, "Failed to stop audio infoframe: %d\n", ret);
>
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 5/9] drm/vc4: hdmi: Create a custom connector state
Hi Maxime
On Tue, 15 Dec 2020 at 15:42, Maxime Ripard wrote:
>
> When run with a higher bpc than 8, the clock of the HDMI controller needs
> to be adjusted. Let's create a connector state that will be used at
> atomic_check and atomic_enable to compute and store the clock rate
> associated to the state.
>
> Acked-by: Thomas Zimmermann
> Signed-off-by: Maxime Ripard
I'm happy again
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 33 ++---
> drivers/gpu/drm/vc4/vc4_hdmi.h | 10 ++
> 2 files changed, 40 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 920895deb2e7..d22a0dbd0ce2 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -170,10 +170,37 @@ static int vc4_hdmi_connector_get_modes(struct
> drm_connector *connector)
>
> static void vc4_hdmi_connector_reset(struct drm_connector *connector)
> {
> - drm_atomic_helper_connector_reset(connector);
> + struct vc4_hdmi_connector_state *old_state =
> + conn_state_to_vc4_hdmi_conn_state(connector->state);
> + struct vc4_hdmi_connector_state *new_state =
> + kzalloc(sizeof(*new_state), GFP_KERNEL);
>
> if (connector->state)
> - drm_atomic_helper_connector_tv_reset(connector);
> + __drm_atomic_helper_connector_destroy_state(connector->state);
> +
> + kfree(old_state);
> + __drm_atomic_helper_connector_reset(connector, _state->base);
> +
> + if (!new_state)
> + return;
> +
> + drm_atomic_helper_connector_tv_reset(connector);
> +}
> +
> +static struct drm_connector_state *
> +vc4_hdmi_connector_duplicate_state(struct drm_connector *connector)
> +{
> + struct drm_connector_state *conn_state = connector->state;
> + struct vc4_hdmi_connector_state *vc4_state =
> conn_state_to_vc4_hdmi_conn_state(conn_state);
> + struct vc4_hdmi_connector_state *new_state;
> +
> + new_state = kzalloc(sizeof(*new_state), GFP_KERNEL);
> + if (!new_state)
> + return NULL;
> +
> + __drm_atomic_helper_connector_duplicate_state(connector,
> _state->base);
> +
> + return _state->base;
> }
>
> static const struct drm_connector_funcs vc4_hdmi_connector_funcs = {
> @@ -181,7 +208,7 @@ static const struct drm_connector_funcs
> vc4_hdmi_connector_funcs = {
> .fill_modes = drm_helper_probe_single_connector_modes,
> .destroy = vc4_hdmi_connector_destroy,
> .reset = vc4_hdmi_connector_reset,
> - .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> + .atomic_duplicate_state = vc4_hdmi_connector_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> };
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index 0526a9cf608a..2cf5362052e2 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -180,6 +180,16 @@ encoder_to_vc4_hdmi(struct drm_encoder *encoder)
> return container_of(_encoder, struct vc4_hdmi, encoder);
> }
>
> +struct vc4_hdmi_connector_state {
> + struct drm_connector_state base;
> +};
> +
> +static inline struct vc4_hdmi_connector_state *
> +conn_state_to_vc4_hdmi_conn_state(struct drm_connector_state *conn_state)
> +{
> + return container_of(conn_state, struct vc4_hdmi_connector_state,
> base);
> +}
> +
> void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
>struct drm_display_mode *mode);
> void vc4_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
> --
> 2.29.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 02/15] drm/vc4: hdmi: Move hdmi reset to bind
Hi Maxime & Dom
On Thu, 10 Dec 2020 at 13:46, Maxime Ripard wrote:
>
> From: Dom Cobley
>
> The hdmi reset got moved to a later point in the commit 9045e91a476b
> ("drm/vc4: hdmi: Add reset callback").
>
> However, the reset now occurs after vc4_hdmi_cec_init and so tramples
> the setup of registers like HDMI_CEC_CNTRL_1
>
> This only affects pi0-3 as on pi4 the cec registers are in a separate
> block
It does mean that this reset only happens once on bind rather than on
every pre_crtc_configure, but as this really is the big reset the
entire block I don't see it needing to be triggered on every
configure.
> Fixes: 9045e91a476b ("drm/vc4: hdmi: Add reset callback")
> Signed-off-by: Dom Cobley
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 8006bddc8fbb..3df1747dd917 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -773,9 +773,6 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
> drm_encoder *encoder,
> return;
> }
>
> - if (vc4_hdmi->variant->reset)
> - vc4_hdmi->variant->reset(vc4_hdmi);
> -
> if (vc4_hdmi->variant->phy_init)
> vc4_hdmi->variant->phy_init(vc4_hdmi, vc4_conn_state);
>
> @@ -1865,6 +1862,9 @@ static int vc4_hdmi_bind(struct device *dev, struct
> device *master, void *data)
> vc4_hdmi->disable_wifi_frequencies =
> of_property_read_bool(dev->of_node,
> "wifi-2.4ghz-coexistence");
>
> + if (vc4_hdmi->variant->reset)
> + vc4_hdmi->variant->reset(vc4_hdmi);
> +
> pm_runtime_enable(dev);
>
> drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS);
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/15] drm/vc4: hdmi: Compute the CEC clock divider from the clock rate
Hi Maxime
On Thu, 10 Dec 2020 at 13:47, Maxime Ripard wrote:
>
> The CEC clock divider needs to output a frequency of 40kHz from the HSM
> rate on the BCM2835. The driver used to have a fixed frequency for it,
> but that changed and we now need to compute it dynamically to maintain
> the proper rate.
>
> Fixes: cd4cb49dc5bb ("drm/vc4: hdmi: Adjust HSM clock rate depending on pixel
> rate")
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
(To be a total pedant it's still a fixed frequency on vc4, but it's
configurable via the variant entry).
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index eff3bac562c6..0c53d7427d15 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -1586,6 +1586,7 @@ static int vc4_hdmi_cec_init(struct vc4_hdmi *vc4_hdmi)
> {
> struct cec_connector_info conn_info;
> struct platform_device *pdev = vc4_hdmi->pdev;
> + u16 clk_cnt;
> u32 value;
> int ret;
>
> @@ -1611,8 +1612,9 @@ static int vc4_hdmi_cec_init(struct vc4_hdmi *vc4_hdmi)
> * divider: the hsm_clock rate and this divider setting will
> * give a 40 kHz CEC clock.
> */
> + clk_cnt = clk_get_rate(vc4_hdmi->hsm_clock) / CEC_CLOCK_FREQ;
> value |= VC4_HDMI_CEC_ADDR_MASK |
> -(4091 << VC4_HDMI_CEC_DIV_CLK_CNT_SHIFT);
> +(clk_cnt << VC4_HDMI_CEC_DIV_CLK_CNT_SHIFT);
> HDMI_WRITE(HDMI_CEC_CNTRL_1, value);
> ret = devm_request_threaded_irq(>dev, platform_get_irq(pdev, 0),
> vc4_cec_irq_handler,
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/15] drm/vc4: hdmi: Fix up CEC registers
Hi Maxime & Dom
On Thu, 10 Dec 2020 at 13:46, Maxime Ripard wrote:
>
> From: Dom Cobley
>
> The commit 311e305fdb4e ("drm/vc4: hdmi: Implement a register layout
> abstraction") forgot one CEC register, and made a copy and paste mistake
> for another one. Fix those mistakes.
>
> Fixes: 311e305fdb4e ("drm/vc4: hdmi: Implement a register layout abstraction")
> Signed-off-by: Dom Cobley
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi_regs.h
> b/drivers/gpu/drm/vc4/vc4_hdmi_regs.h
> index 013fd57febd8..20a1438a72cb 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi_regs.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi_regs.h
> @@ -29,6 +29,7 @@ enum vc4_hdmi_field {
> HDMI_CEC_CPU_MASK_SET,
> HDMI_CEC_CPU_MASK_STATUS,
> HDMI_CEC_CPU_STATUS,
> + HDMI_CEC_CPU_SET,
>
> /*
> * Transmit data, first byte is low byte of the 32-bit reg.
> @@ -199,9 +200,10 @@ static const struct vc4_hdmi_register vc4_hdmi_fields[]
> = {
> VC4_HDMI_REG(HDMI_TX_PHY_RESET_CTL, 0x02c0),
> VC4_HDMI_REG(HDMI_TX_PHY_CTL_0, 0x02c4),
> VC4_HDMI_REG(HDMI_CEC_CPU_STATUS, 0x0340),
> + VC4_HDMI_REG(HDMI_CEC_CPU_SET, 0x0344),
> VC4_HDMI_REG(HDMI_CEC_CPU_CLEAR, 0x0348),
> VC4_HDMI_REG(HDMI_CEC_CPU_MASK_STATUS, 0x034c),
> - VC4_HDMI_REG(HDMI_CEC_CPU_MASK_SET, 0x034c),
> + VC4_HDMI_REG(HDMI_CEC_CPU_MASK_SET, 0x0350),
> VC4_HDMI_REG(HDMI_CEC_CPU_MASK_CLEAR, 0x0354),
> VC4_HDMI_REG(HDMI_RAM_PACKET_START, 0x0400),
> };
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/15] drm/vc4: hdmi: Introduce a CEC clock
Hi Maxime
On Thu, 10 Dec 2020 at 13:47, Maxime Ripard wrote:
>
> While the BCM2835 had the CEC clock derived from the HSM clock, the
> BCM2711 has a dedicated parent clock for it.
>
> Let's introduce a separate clock for it so that we can handle both
> cases.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 9 -
> drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index b93ee3e26e2b..0debd22bc992 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -145,7 +145,7 @@ static void vc4_hdmi_cec_update_clk_div(struct vc4_hdmi
> *vc4_hdmi)
> * Set the clock divider: the hsm_clock rate and this divider
> * setting will give a 40 kHz CEC clock.
> */
> - clk_cnt = clk_get_rate(vc4_hdmi->hsm_clock) / CEC_CLOCK_FREQ;
> + clk_cnt = clk_get_rate(vc4_hdmi->cec_clock) / CEC_CLOCK_FREQ;
> value |= clk_cnt << VC4_HDMI_CEC_DIV_CLK_CNT_SHIFT;
> HDMI_WRITE(HDMI_CEC_CNTRL_1, value);
> }
> @@ -1740,6 +1740,7 @@ static int vc4_hdmi_init_resources(struct vc4_hdmi
> *vc4_hdmi)
> return PTR_ERR(vc4_hdmi->hsm_clock);
> }
> vc4_hdmi->audio_clock = vc4_hdmi->hsm_clock;
> + vc4_hdmi->cec_clock = vc4_hdmi->hsm_clock;
>
> return 0;
> }
> @@ -1833,6 +1834,12 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
> *vc4_hdmi)
> return PTR_ERR(vc4_hdmi->audio_clock);
> }
>
> + vc4_hdmi->cec_clock = devm_clk_get(dev, "cec");
> + if (IS_ERR(vc4_hdmi->cec_clock)) {
> + DRM_ERROR("Failed to get CEC clock\n");
> + return PTR_ERR(vc4_hdmi->cec_clock);
> + }
Aren't we adding to the DT binding here and breaking backwards compatibility?
Admittedly CEC didn't work before (and was masked out) for vc5, but do
we need to worry about those with existing DT files that currently
work happily?
Otherwise I'm happy with the patch.
Dave
> +
> vc4_hdmi->reset = devm_reset_control_get(dev, NULL);
> if (IS_ERR(vc4_hdmi->reset)) {
> DRM_ERROR("Failed to get HDMI reset line\n");
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index 720914761261..adc4bf33ff15 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -155,6 +155,7 @@ struct vc4_hdmi {
> bool cec_tx_ok;
> bool cec_irq_was_rx;
>
> + struct clk *cec_clock;
> struct clk *pixel_clock;
> struct clk *hsm_clock;
> struct clk *audio_clock;
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/15] drm/vc4: hdmi: Introduce a CEC clock
On Fri, 18 Dec 2020 at 12:23, Maxime Ripard wrote:
>
> Hi Dave,
>
> On Fri, Dec 18, 2020 at 11:37:50AM +, Dave Stevenson wrote:
> > Hi Maxime
> >
> > On Thu, 10 Dec 2020 at 13:47, Maxime Ripard wrote:
> > >
> > > While the BCM2835 had the CEC clock derived from the HSM clock, the
> > > BCM2711 has a dedicated parent clock for it.
> > >
> > > Let's introduce a separate clock for it so that we can handle both
> > > cases.
> > >
> > > Signed-off-by: Maxime Ripard
> > > ---
> > > drivers/gpu/drm/vc4/vc4_hdmi.c | 9 -
> > > drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
> > > 2 files changed, 9 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > index b93ee3e26e2b..0debd22bc992 100644
> > > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > > @@ -145,7 +145,7 @@ static void vc4_hdmi_cec_update_clk_div(struct
> > > vc4_hdmi *vc4_hdmi)
> > > * Set the clock divider: the hsm_clock rate and this divider
> > > * setting will give a 40 kHz CEC clock.
> > > */
> > > - clk_cnt = clk_get_rate(vc4_hdmi->hsm_clock) / CEC_CLOCK_FREQ;
> > > + clk_cnt = clk_get_rate(vc4_hdmi->cec_clock) / CEC_CLOCK_FREQ;
> > > value |= clk_cnt << VC4_HDMI_CEC_DIV_CLK_CNT_SHIFT;
> > > HDMI_WRITE(HDMI_CEC_CNTRL_1, value);
> > > }
> > > @@ -1740,6 +1740,7 @@ static int vc4_hdmi_init_resources(struct vc4_hdmi
> > > *vc4_hdmi)
> > > return PTR_ERR(vc4_hdmi->hsm_clock);
> > > }
> > > vc4_hdmi->audio_clock = vc4_hdmi->hsm_clock;
> > > + vc4_hdmi->cec_clock = vc4_hdmi->hsm_clock;
> > >
> > > return 0;
> > > }
> > > @@ -1833,6 +1834,12 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
> > > *vc4_hdmi)
> > > return PTR_ERR(vc4_hdmi->audio_clock);
> > > }
> > >
> > > + vc4_hdmi->cec_clock = devm_clk_get(dev, "cec");
> > > + if (IS_ERR(vc4_hdmi->cec_clock)) {
> > > + DRM_ERROR("Failed to get CEC clock\n");
> > > + return PTR_ERR(vc4_hdmi->cec_clock);
> > > + }
> >
> > Aren't we adding to the DT binding here and breaking backwards
> > compatibility?
> > Admittedly CEC didn't work before (and was masked out) for vc5, but do
> > we need to worry about those with existing DT files that currently
> > work happily?
>
> The DT compatibility is not a worry here: I made sure the CEC clock and
> range were part of the binding since it's been introduced:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2e3725b05b785e73482a194b99bff3d5a1c85140
>
> So we were not using it so far, but it was in the DT all along
I guess I should have read it then :-)
In which case
Reviewed-by: Dave Stevenson
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 9/9] drm/vc4: hdmi: Enable 10/12 bpc output
Hi Maxime
On Tue, 15 Dec 2020 at 15:43, Maxime Ripard wrote:
>
> The BCM2711 supports higher bpc count than just 8, so let's support it in
> our driver.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 70 -
> drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
> drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 9
> 3 files changed, 79 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 41897b8e9d51..2e5449b25ce4 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -76,6 +76,17 @@
> #define VC5_HDMI_VERTB_VSPO_SHIFT 16
> #define VC5_HDMI_VERTB_VSPO_MASK VC4_MASK(29, 16)
>
> +#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_SHIFT 8
> +#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_MASK VC4_MASK(10,
> 8)
> +
> +#define VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_SHIFT 0
> +#define VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_MASK VC4_MASK(3, 0)
> +
> +#define VC5_HDMI_GCP_CONFIG_GCP_ENABLE BIT(31)
> +
> +#define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_SHIFT 8
> +#define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_MASK VC4_MASK(15, 8)
> +
> # define VC4_HD_M_SW_RST BIT(2)
> # define VC4_HD_M_ENABLE BIT(0)
>
> @@ -186,6 +197,8 @@ static void vc4_hdmi_connector_reset(struct drm_connector
> *connector)
> if (!new_state)
> return;
>
> + new_state->base.max_bpc = 8;
> + new_state->base.max_requested_bpc = 8;
> drm_atomic_helper_connector_tv_reset(connector);
> }
>
> @@ -232,12 +245,20 @@ static int vc4_hdmi_connector_init(struct drm_device
> *dev,
> vc4_hdmi->ddc);
> drm_connector_helper_add(connector, _hdmi_connector_helper_funcs);
>
> + /*
> +* Some of the properties below require access to state, like bpc.
> +* Allocate some default initial connector state with our reset
> helper.
> +*/
> + if (connector->funcs->reset)
> + connector->funcs->reset(connector);
> +
> /* Create and attach TV margin props to this connector. */
> ret = drm_mode_create_tv_margin_properties(dev);
> if (ret)
> return ret;
>
> drm_connector_attach_tv_margin_properties(connector);
> + drm_connector_attach_max_bpc_property(connector, 8, 12);
>
> connector->polled = (DRM_CONNECTOR_POLL_CONNECT |
> DRM_CONNECTOR_POLL_DISCONNECT);
> @@ -506,6 +527,7 @@ static void vc5_hdmi_csc_setup(struct vc4_hdmi *vc4_hdmi,
> bool enable)
> }
>
> static void vc4_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
> +struct drm_connector_state *state,
> struct drm_display_mode *mode)
> {
> bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
> @@ -549,7 +571,9 @@ static void vc4_hdmi_set_timings(struct vc4_hdmi
> *vc4_hdmi,
> HDMI_WRITE(HDMI_VERTB0, vertb_even);
> HDMI_WRITE(HDMI_VERTB1, vertb);
> }
> +
> static void vc5_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
> +struct drm_connector_state *state,
> struct drm_display_mode *mode)
> {
> bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
> @@ -569,6 +593,9 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi
> *vc4_hdmi,
> mode->crtc_vsync_end -
> interlaced,
> VC4_HDMI_VERTB_VBP));
> + unsigned char gcp;
> + bool gcp_en;
> + u32 reg;
>
> HDMI_WRITE(HDMI_VEC_INTERFACE_XBAR, 0x354021);
> HDMI_WRITE(HDMI_HORZA,
> @@ -594,6 +621,39 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi
> *vc4_hdmi,
> HDMI_WRITE(HDMI_VERTB0, vertb_even);
> HDMI_WRITE(HDMI_VERTB1, vertb);
>
> + switch (state->max_bpc) {
> + case 12:
> + gcp = 6;
> + gcp_en = true;
> + break;
> + case 10:
> + gcp = 5;
> + gcp_en = true;
> + break;
> + case 8:
> + default:
> + gcp = 4;
> + gcp_en = false;
> + break;
> + }
> +
> + reg = HDMI_READ(HDMI_DEEP_COLOR_CONFIG_1);
> + reg &= ~(VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PA
Re: [PATCH v6 5/9] drm/vc4: hdmi: Create a custom connector state
Hi Maxime
On Thu, 10 Dec 2020 at 14:23, Maxime Ripard wrote:
>
> When run with a higher bpc than 8, the clock of the HDMI controller needs
> to be adjusted. Let's create a connector state that will be used at
> atomic_check and atomic_enable to compute and store the clock rate
> associated to the state.
>
> Acked-by: Thomas Zimmermann
> Reviewed-by: Dave Stevenson
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 33 ++---
> drivers/gpu/drm/vc4/vc4_hdmi.h | 10 ++
> 2 files changed, 40 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 61039cc89d9d..8978df3f0ca4 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -170,10 +170,37 @@ static int vc4_hdmi_connector_get_modes(struct
> drm_connector *connector)
>
> static void vc4_hdmi_connector_reset(struct drm_connector *connector)
> {
> - drm_atomic_helper_connector_reset(connector);
> + struct vc4_hdmi_connector_state *old_state =
> + conn_state_to_vc4_hdmi_conn_state(connector->state);
> + struct vc4_hdmi_connector_state *new_state =
> + kzalloc(sizeof(*conn_state), GFP_KERNEL);
>
> if (connector->state)
> - drm_atomic_helper_connector_tv_reset(connector);
> + __drm_atomic_helper_connector_destroy_state(connector->state);
> +
> + kfree(old_state);
> +
> + if (!new_state)
> + return;
This has changed since v5 that I added my R-B to.
So we no longer call __drm_atomic_helper_connector_reset should the
kzalloc fail. Doesn't that mean connector->state is still set to
old_state? Except we've called kfree on that and it's therefore
invalid.
Calling __drm_atomic_helper_connector_reset unconditionally is fine as
it checks for the new pointer being NULL before dereferencing, but
always assigns it to connector->state.
Calling drm_atomic_helper_connector_tv_reset when connector->state =
NULL isn't safe.
> + __drm_atomic_helper_connector_reset(connector, _state->base);
Put the if (!new_state) return; here?
Patch 9/9 can set the max_bpc and max_bpc_requested field here too.
Dave
> + drm_atomic_helper_connector_tv_reset(connector);
> +}
> +
> +static struct drm_connector_state *
> +vc4_hdmi_connector_duplicate_state(struct drm_connector *connector)
> +{
> + struct drm_connector_state *conn_state = connector->state;
> + struct vc4_hdmi_connector_state *vc4_state =
> conn_state_to_vc4_hdmi_conn_state(conn_state);
> + struct vc4_hdmi_connector_state *new_state;
> +
> + new_state = kzalloc(sizeof(*new_state), GFP_KERNEL);
> + if (!new_state)
> + return NULL;
> +
> + __drm_atomic_helper_connector_duplicate_state(connector,
> _state->base);
> +
> + return _state->base;
> }
>
> static const struct drm_connector_funcs vc4_hdmi_connector_funcs = {
> @@ -181,7 +208,7 @@ static const struct drm_connector_funcs
> vc4_hdmi_connector_funcs = {
> .fill_modes = drm_helper_probe_single_connector_modes,
> .destroy = vc4_hdmi_connector_destroy,
> .reset = vc4_hdmi_connector_reset,
> - .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> + .atomic_duplicate_state = vc4_hdmi_connector_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> };
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index 0526a9cf608a..2cf5362052e2 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -180,6 +180,16 @@ encoder_to_vc4_hdmi(struct drm_encoder *encoder)
> return container_of(_encoder, struct vc4_hdmi, encoder);
> }
>
> +struct vc4_hdmi_connector_state {
> + struct drm_connector_state base;
> +};
> +
> +static inline struct vc4_hdmi_connector_state *
> +conn_state_to_vc4_hdmi_conn_state(struct drm_connector_state *conn_state)
> +{
> + return container_of(conn_state, struct vc4_hdmi_connector_state,
> base);
> +}
> +
> void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi,
>struct drm_display_mode *mode);
> void vc4_hdmi_phy_disable(struct vc4_hdmi *vc4_hdmi);
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 9/9] drm/vc4: hdmi: Enable 10/12 bpc output
Hi Maxime
On Thu, 10 Dec 2020 at 14:23, Maxime Ripard wrote:
>
> The BCM2711 supports higher bpc count than just 8, so let's support it in
> our driver.
>
> Signed-off-by: Maxime Ripard
Looks good to me, but is impacted by the comment I've just made on 5/9.
Dave
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 71 -
> drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
> drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 9
> 3 files changed, 80 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 996c727278fb..e9796120e991 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -76,6 +76,17 @@
> #define VC5_HDMI_VERTB_VSPO_SHIFT 16
> #define VC5_HDMI_VERTB_VSPO_MASK VC4_MASK(29, 16)
>
> +#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_SHIFT 8
> +#define VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_MASK VC4_MASK(10,
> 8)
> +
> +#define VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_SHIFT 0
> +#define VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_MASK VC4_MASK(3, 0)
> +
> +#define VC5_HDMI_GCP_CONFIG_GCP_ENABLE BIT(31)
> +
> +#define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_SHIFT 8
> +#define VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_MASK VC4_MASK(15, 8)
> +
> # define VC4_HD_M_SW_RST BIT(2)
> # define VC4_HD_M_ENABLE BIT(0)
>
> @@ -185,6 +196,9 @@ static void vc4_hdmi_connector_reset(struct drm_connector
> *connector)
> if (!new_state)
> return;
>
> + new_state->base.max_bpc = 8;
> + new_state->base.max_requested_bpc = 8;
> +
> __drm_atomic_helper_connector_reset(connector, _state->base);
> drm_atomic_helper_connector_tv_reset(connector);
> }
> @@ -232,12 +246,20 @@ static int vc4_hdmi_connector_init(struct drm_device
> *dev,
> vc4_hdmi->ddc);
> drm_connector_helper_add(connector, _hdmi_connector_helper_funcs);
>
> + /*
> +* Some of the properties below require access to state, like bpc.
> +* Allocate some default initial connector state with our reset
> helper.
> +*/
> + if (connector->funcs->reset)
> + connector->funcs->reset(connector);
> +
> /* Create and attach TV margin props to this connector. */
> ret = drm_mode_create_tv_margin_properties(dev);
> if (ret)
> return ret;
>
> drm_connector_attach_tv_margin_properties(connector);
> + drm_connector_attach_max_bpc_property(connector, 8, 12);
>
> connector->polled = (DRM_CONNECTOR_POLL_CONNECT |
> DRM_CONNECTOR_POLL_DISCONNECT);
> @@ -503,6 +525,7 @@ static void vc5_hdmi_csc_setup(struct vc4_hdmi *vc4_hdmi,
> bool enable)
> }
>
> static void vc4_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
> +struct drm_connector_state *state,
> struct drm_display_mode *mode)
> {
> bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
> @@ -546,7 +569,9 @@ static void vc4_hdmi_set_timings(struct vc4_hdmi
> *vc4_hdmi,
> HDMI_WRITE(HDMI_VERTB0, vertb_even);
> HDMI_WRITE(HDMI_VERTB1, vertb);
> }
> +
> static void vc5_hdmi_set_timings(struct vc4_hdmi *vc4_hdmi,
> +struct drm_connector_state *state,
> struct drm_display_mode *mode)
> {
> bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
> @@ -566,6 +591,9 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi
> *vc4_hdmi,
> mode->crtc_vsync_end -
> interlaced,
> VC4_HDMI_VERTB_VBP));
> + unsigned char gcp;
> + bool gcp_en;
> + u32 reg;
>
> HDMI_WRITE(HDMI_VEC_INTERFACE_XBAR, 0x354021);
> HDMI_WRITE(HDMI_HORZA,
> @@ -591,6 +619,39 @@ static void vc5_hdmi_set_timings(struct vc4_hdmi
> *vc4_hdmi,
> HDMI_WRITE(HDMI_VERTB0, vertb_even);
> HDMI_WRITE(HDMI_VERTB1, vertb);
>
> + switch (state->max_bpc) {
> + case 12:
> + gcp = 6;
> + gcp_en = true;
> + break;
> + case 10:
> + gcp = 5;
> + gcp_en = true;
> + break;
> + case 8:
> + default:
> + gcp = 4;
> + gcp_en = false;
> + break;
> + }
> +
> + reg = HDMI_READ(HDMI_DEEP_COLOR_CONFIG_1);
> + reg &= ~(VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE_MASK |
> +VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH_MASK);
> + reg |= VC4_SET_FIELD(2, VC5_HDMI_DEEP_COLOR_CONFIG_1_INIT_PACK_PHASE)
> |
> + VC4_SET_FIELD(gcp, VC5_HDMI_DEEP_COLOR_CONFIG_1_COLOR_DEPTH);
> + HDMI_WRITE(HDMI_DEEP_COLOR_CONFIG_1,
Re: [PATCH 03/15] drm/vc4: hdmi: Fix register offset with longer CEC messages
Hi Dom & Maxime
On Thu, 10 Dec 2020 at 13:46, Maxime Ripard wrote:
>
> From: Dom Cobley
>
> The code prior to 311e305fdb4e ("drm/vc4: hdmi: Implement a register
> layout abstraction") was relying on the fact that the register offset
> was incremented by 4 for each readl call. That worked since the register
> width is 4 bytes.
>
> However, since that commit the HDMI_READ macro is now taking an enum,
> and the offset doesn't increment by 4 but 1 now. Divide the index by 4
> to fix this.
>
> Fixes: 311e305fdb4e ("drm/vc4: hdmi: Implement a register layout abstraction")
> Signed-off-by: Dom Cobley
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 17 +++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 3df1747dd917..28b78ea885ea 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -1434,13 +1434,20 @@ static irqreturn_t vc4_cec_irq_handler_thread(int
> irq, void *priv)
>
> static void vc4_cec_read_msg(struct vc4_hdmi *vc4_hdmi, u32 cntrl1)
> {
> + struct drm_device *dev = vc4_hdmi->connector.dev;
> struct cec_msg *msg = _hdmi->cec_rx_msg;
> unsigned int i;
>
> msg->len = 1 + ((cntrl1 & VC4_HDMI_CEC_REC_WRD_CNT_MASK) >>
> VC4_HDMI_CEC_REC_WRD_CNT_SHIFT);
> +
> + if (msg->len > 16) {
> + drm_err(dev, "Attempting to read too much data (%d)\n",
> msg->len);
> + return;
> + }
> +
> for (i = 0; i < msg->len; i += 4) {
> - u32 val = HDMI_READ(HDMI_CEC_RX_DATA_1 + i);
> + u32 val = HDMI_READ(HDMI_CEC_RX_DATA_1 + (i >> 2));
>
> msg->msg[i] = val & 0xff;
> msg->msg[i + 1] = (val >> 8) & 0xff;
> @@ -1533,11 +1540,17 @@ static int vc4_hdmi_cec_adap_transmit(struct
> cec_adapter *adap, u8 attempts,
> u32 signal_free_time, struct cec_msg
> *msg)
> {
> struct vc4_hdmi *vc4_hdmi = cec_get_drvdata(adap);
> + struct drm_device *dev = vc4_hdmi->connector.dev;
> u32 val;
> unsigned int i;
>
> + if (msg->len > 16) {
> + drm_err(dev, "Attempting to transmit too much data (%d)\n",
> msg->len);
> + return -ENOMEM;
> + }
> +
> for (i = 0; i < msg->len; i += 4)
> - HDMI_WRITE(HDMI_CEC_TX_DATA_1 + i,
> + HDMI_WRITE(HDMI_CEC_TX_DATA_1 + (i >> 2),
>(msg->msg[i]) |
>(msg->msg[i + 1] << 8) |
>(msg->msg[i + 2] << 16) |
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/15] drm/vc4: hdmi: Restore cec physical address on reconnect
On Fri, 18 Dec 2020 at 14:21, Dave Stevenson
wrote:
>
> Hi Maxime & Dom
>
> On Thu, 10 Dec 2020 at 13:47, Maxime Ripard wrote:
> >
> > From: Dom Cobley
> >
> > Currently we call cec_phys_addr_invalidate on a hotplug deassert.
> > That may be due to a TV power cycling, or an AVR being switched
> > on (and switching edid).
> >
> > This makes CEC unusable since our controller wouldn't have a physical
> > address anymore.
> >
> > Set it back up again on the hotplug assert.
> >
> > Fixes: 15b4511a4af6 ("drm/vc4: add HDMI CEC support")
> > Signed-off-by: Dom Cobley
> > Signed-off-by: Maxime Ripard
> > ---
> > drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
> > 1 file changed, 17 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > index 28b78ea885ea..eff3bac562c6 100644
> > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > @@ -136,20 +136,29 @@ static enum drm_connector_status
> > vc4_hdmi_connector_detect(struct drm_connector *connector, bool force)
> > {
> > struct vc4_hdmi *vc4_hdmi = connector_to_vc4_hdmi(connector);
> > + bool connected = false;
> >
> > if (vc4_hdmi->hpd_gpio) {
> > if (gpio_get_value_cansleep(vc4_hdmi->hpd_gpio) ^
> > vc4_hdmi->hpd_active_low)
> > - return connector_status_connected;
> > - cec_phys_addr_invalidate(vc4_hdmi->cec_adap);
> > - return connector_status_disconnected;
> > - }
> > -
> > - if (drm_probe_ddc(vc4_hdmi->ddc))
> > - return connector_status_connected;
> > -
> > + connected = true;
> > + } else if (drm_probe_ddc(vc4_hdmi->ddc))
> > + connected = true;
> > if (HDMI_READ(HDMI_HOTPLUG) & VC4_HDMI_HOTPLUG_CONNECTED)
>
> This needs to become an "else if(...".
> It used to be that all the other paths would return, so were mutually
> exclusive to this. Now they set a thing and keep going we need to
> avoid reading the register should there be a HPD gpio or the ddc probe
> succeeds.
> Memory says that otherwise Pi3 always reports connected.
>
> I fixed this in a downstream patch already -
> https://github.com/raspberrypi/linux/commit/d345caec1e9b2317b9cd7eb5b92ae453a0d3e98c
>
> Otherwise fine.
>
> Dave
>
> > + connected = true;
> > + if (connected) {
> > + if (connector->status != connector_status_connected) {
> > + struct edid *edid = drm_get_edid(connector,
> > vc4_hdmi->ddc);
> > +
> > + if (edid) {
> > +
> > cec_s_phys_addr_from_edid(vc4_hdmi->cec_adap, edid);
> > + vc4_hdmi->encoder.hdmi_monitor =
> > drm_detect_hdmi_monitor(edid);
> > +
> > drm_connector_update_edid_property(connector, edid);
Actually looking at this again in the context of the other changes, do
we need to call drm_connector_update_edid_property() here?
We've just called drm_get_edid() to get the edid, and that calls
drm_connector_update_edid_property() as well [1]
Updating vc4_hdmi->encoder.hdmi_monitor may be necessary. It's
otherwise done in vc4_hdmi_connector_get_modes, which I sort of expect
to be called almost immediately by the framework when connector_detect
returns "connected". I haven't checked if that is guaranteed though.
vc4_hdmi_connector_get_modes also includes a manual call to
drm_connector_update_edid_property after having just called
drm_get_edid, so that one feels redundant too.
Dave
[1]
https://elixir.bootlin.com/linux/v5.10/source/drivers/gpu/drm/drm_edid.c#L2059
> > + kfree(edid);
> > + }
> > + }
> > return connector_status_connected;
> > + }
> > cec_phys_addr_invalidate(vc4_hdmi->cec_adap);
> > return connector_status_disconnected;
> > }
> > --
> > 2.28.0
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/15] drm/vc4: hdmi: Restore cec physical address on reconnect
Hi Maxime & Dom
On Thu, 10 Dec 2020 at 13:47, Maxime Ripard wrote:
>
> From: Dom Cobley
>
> Currently we call cec_phys_addr_invalidate on a hotplug deassert.
> That may be due to a TV power cycling, or an AVR being switched
> on (and switching edid).
>
> This makes CEC unusable since our controller wouldn't have a physical
> address anymore.
>
> Set it back up again on the hotplug assert.
>
> Fixes: 15b4511a4af6 ("drm/vc4: add HDMI CEC support")
> Signed-off-by: Dom Cobley
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
> 1 file changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 28b78ea885ea..eff3bac562c6 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -136,20 +136,29 @@ static enum drm_connector_status
> vc4_hdmi_connector_detect(struct drm_connector *connector, bool force)
> {
> struct vc4_hdmi *vc4_hdmi = connector_to_vc4_hdmi(connector);
> + bool connected = false;
>
> if (vc4_hdmi->hpd_gpio) {
> if (gpio_get_value_cansleep(vc4_hdmi->hpd_gpio) ^
> vc4_hdmi->hpd_active_low)
> - return connector_status_connected;
> - cec_phys_addr_invalidate(vc4_hdmi->cec_adap);
> - return connector_status_disconnected;
> - }
> -
> - if (drm_probe_ddc(vc4_hdmi->ddc))
> - return connector_status_connected;
> -
> + connected = true;
> + } else if (drm_probe_ddc(vc4_hdmi->ddc))
> + connected = true;
> if (HDMI_READ(HDMI_HOTPLUG) & VC4_HDMI_HOTPLUG_CONNECTED)
This needs to become an "else if(...".
It used to be that all the other paths would return, so were mutually
exclusive to this. Now they set a thing and keep going we need to
avoid reading the register should there be a HPD gpio or the ddc probe
succeeds.
Memory says that otherwise Pi3 always reports connected.
I fixed this in a downstream patch already -
https://github.com/raspberrypi/linux/commit/d345caec1e9b2317b9cd7eb5b92ae453a0d3e98c
Otherwise fine.
Dave
> + connected = true;
> + if (connected) {
> + if (connector->status != connector_status_connected) {
> + struct edid *edid = drm_get_edid(connector,
> vc4_hdmi->ddc);
> +
> + if (edid) {
> + cec_s_phys_addr_from_edid(vc4_hdmi->cec_adap,
> edid);
> + vc4_hdmi->encoder.hdmi_monitor =
> drm_detect_hdmi_monitor(edid);
> + drm_connector_update_edid_property(connector,
> edid);
> + kfree(edid);
> + }
> + }
> return connector_status_connected;
> + }
> cec_phys_addr_invalidate(vc4_hdmi->cec_adap);
> return connector_status_disconnected;
> }
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/15] drm/vc4: hdmi: Update the CEC clock divider on HSM rate change
Hi Maxime
On Thu, 10 Dec 2020 at 13:47, Maxime Ripard wrote:
>
> As part of the enable sequence we might change the HSM clock rate if the
> pixel rate is different than the one we were already dealing with.
>
> On the BCM2835 however, the CEC clock derives from the HSM clock so any
> rate change will need to be reflected in the CEC clock divider to output
> 40kHz.
>
> Fixes: cd4cb49dc5bb ("drm/vc4: hdmi: Adjust HSM clock rate depending on pixel
> rate")
> Signed-off-by: Maxime Ripard
I thought we'd got a duplicate patch here, but it's moving code that
was changed in patch 6/15 so it can be called from
vc4_hdmi_encoder_pre_crtc_configure too. Good for confusing me!
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 39 +-
> 1 file changed, 29 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 0c53d7427d15..b93ee3e26e2b 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -132,6 +132,27 @@ static void vc5_hdmi_reset(struct vc4_hdmi *vc4_hdmi)
>HDMI_READ(HDMI_CLOCK_STOP) | VC4_DVP_HT_CLOCK_STOP_PIXEL);
> }
>
> +#ifdef CONFIG_DRM_VC4_HDMI_CEC
> +static void vc4_hdmi_cec_update_clk_div(struct vc4_hdmi *vc4_hdmi)
> +{
> + u16 clk_cnt;
> + u32 value;
> +
> + value = HDMI_READ(HDMI_CEC_CNTRL_1);
> + value &= ~VC4_HDMI_CEC_DIV_CLK_CNT_MASK;
> +
> + /*
> +* Set the clock divider: the hsm_clock rate and this divider
> +* setting will give a 40 kHz CEC clock.
> +*/
> + clk_cnt = clk_get_rate(vc4_hdmi->hsm_clock) / CEC_CLOCK_FREQ;
> + value |= clk_cnt << VC4_HDMI_CEC_DIV_CLK_CNT_SHIFT;
> + HDMI_WRITE(HDMI_CEC_CNTRL_1, value);
> +}
> +#else
> +static void vc4_hdmi_cec_update_clk_div(struct vc4_hdmi *vc4_hdmi) {}
> +#endif
> +
> static enum drm_connector_status
> vc4_hdmi_connector_detect(struct drm_connector *connector, bool force)
> {
> @@ -761,6 +782,8 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
> drm_encoder *encoder,
> return;
> }
>
> + vc4_hdmi_cec_update_clk_div(vc4_hdmi);
> +
> /*
> * FIXME: When the pixel freq is 594MHz (4k60), this needs to be setup
> * at 300MHz.
> @@ -1586,7 +1609,6 @@ static int vc4_hdmi_cec_init(struct vc4_hdmi *vc4_hdmi)
> {
> struct cec_connector_info conn_info;
> struct platform_device *pdev = vc4_hdmi->pdev;
> - u16 clk_cnt;
> u32 value;
> int ret;
>
> @@ -1605,17 +1627,14 @@ static int vc4_hdmi_cec_init(struct vc4_hdmi
> *vc4_hdmi)
> cec_s_conn_info(vc4_hdmi->cec_adap, _info);
>
> HDMI_WRITE(HDMI_CEC_CPU_MASK_SET, 0x);
> +
> value = HDMI_READ(HDMI_CEC_CNTRL_1);
> - value &= ~VC4_HDMI_CEC_DIV_CLK_CNT_MASK;
> - /*
> -* Set the logical address to Unregistered and set the clock
> -* divider: the hsm_clock rate and this divider setting will
> -* give a 40 kHz CEC clock.
> -*/
> - clk_cnt = clk_get_rate(vc4_hdmi->hsm_clock) / CEC_CLOCK_FREQ;
> - value |= VC4_HDMI_CEC_ADDR_MASK |
> -(clk_cnt << VC4_HDMI_CEC_DIV_CLK_CNT_SHIFT);
> + /* Set the logical address to Unregistered */
> + value |= VC4_HDMI_CEC_ADDR_MASK;
> HDMI_WRITE(HDMI_CEC_CNTRL_1, value);
> +
> + vc4_hdmi_cec_update_clk_div(vc4_hdmi);
> +
> ret = devm_request_threaded_irq(>dev, platform_get_irq(pdev, 0),
> vc4_cec_irq_handler,
> vc4_cec_irq_handler_thread, 0,
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 11/15] drm/vc4: hdmi: Remove cec_available flag
Hi Dom & Maxime
On Thu, 10 Dec 2020 at 13:47, Maxime Ripard wrote:
>
> From: Dom Cobley
>
> Now that our HDMI controller supports CEC for the BCM2711, let's remove
> that flag.
>
> Signed-off-by: Dom Cobley
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 4
> drivers/gpu/drm/vc4/vc4_hdmi.h | 3 ---
> 2 files changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index d208b7d1d937..327638d93032 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -1658,9 +1658,6 @@ static int vc4_hdmi_cec_init(struct vc4_hdmi *vc4_hdmi)
> u32 value;
> int ret;
>
> - if (!vc4_hdmi->variant->cec_available)
> - return 0;
> -
> vc4_hdmi->cec_adap = cec_allocate_adapter(_hdmi_cec_adap_ops,
> vc4_hdmi, "vc4",
> CEC_CAP_DEFAULTS |
> @@ -2074,7 +2071,6 @@ static const struct vc4_hdmi_variant bcm2835_variant = {
> .debugfs_name = "hdmi_regs",
> .card_name = "vc4-hdmi",
> .max_pixel_clock= 16200,
> - .cec_available = true,
> .registers = vc4_hdmi_fields,
> .num_registers = ARRAY_SIZE(vc4_hdmi_fields),
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index 27352827f70c..c93ada62f429 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -42,9 +42,6 @@ struct vc4_hdmi_variant {
> /* Filename to expose the registers in debugfs */
> const char *debugfs_name;
>
> - /* Set to true when the CEC support is available */
> - bool cec_available;
> -
> /* Maximum pixel clock supported by the controller (in Hz) */
> unsigned long long max_pixel_clock;
>
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/15] drm/vc4: hdmi: Don't register the CEC adapter if there's no interrupts
On Thu, 10 Dec 2020 at 13:47, Maxime Ripard wrote:
>
> We introduced the BCM2711 support to the vc4 HDMI controller with 5.10,
> but this was lacking any of the interrupts of the CEC controller so we
> have to deal with the backward compatibility.
>
> Do so by simply ignoring the CEC setup if the DT doesn't have the
> interrupts property.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 327638d93032..69217c68d3a4 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -1655,9 +1655,15 @@ static int vc4_hdmi_cec_init(struct vc4_hdmi *vc4_hdmi)
> {
> struct cec_connector_info conn_info;
> struct platform_device *pdev = vc4_hdmi->pdev;
> + struct device *dev = >dev;
> u32 value;
> int ret;
>
> + if (!of_find_property(dev->of_node, "interrupts", NULL)) {
> + dev_warn(dev, "'interrupts' DT property is missing, no
> CEC\n");
> + return 0;
> + }
> +
> vc4_hdmi->cec_adap = cec_allocate_adapter(_hdmi_cec_adap_ops,
> vc4_hdmi, "vc4",
> CEC_CAP_DEFAULTS |
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drm/vc4: hdmi: Block odd horizontal timings
Hi Maxime
Thanks for the rewording :-)
On Thu, 29 Oct 2020 at 12:25, Maxime Ripard wrote:
>
> The FIFO between the pixelvalve and the HDMI controller runs at 2 pixels
> per clock cycle, and cannot deal with odd timings.
>
> Let's reject any mode with such timings.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
>
> Changes from v1:
> - s/broken/unsupported/
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 12
> drivers/gpu/drm/vc4/vc4_hdmi.h | 3 +++
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 3d0338822cd2..506c12454086 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -768,6 +768,11 @@ static int vc4_hdmi_encoder_atomic_check(struct
> drm_encoder *encoder,
> struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> unsigned long long pixel_rate = mode->clock * 1000;
>
> + if (vc4_hdmi->variant->unsupported_odd_h_timings &&
> + ((mode->hdisplay % 2) || (mode->hsync_start % 2) ||
> +(mode->hsync_end % 2) || (mode->htotal % 2)))
> + return -EINVAL;
> +
> if (pixel_rate > vc4_hdmi->variant->max_pixel_clock)
> return -EINVAL;
>
> @@ -780,6 +785,11 @@ vc4_hdmi_encoder_mode_valid(struct drm_encoder *encoder,
> {
> struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
>
> + if (vc4_hdmi->variant->unsupported_odd_h_timings &&
> + ((mode->hdisplay % 2) || (mode->hsync_start % 2) ||
> +(mode->hsync_end % 2) || (mode->htotal % 2)))
> + return MODE_H_ILLEGAL;
> +
> if ((mode->clock * 1000) > vc4_hdmi->variant->max_pixel_clock)
> return MODE_CLOCK_HIGH;
>
> @@ -1830,6 +1840,7 @@ static const struct vc4_hdmi_variant
> bcm2711_hdmi0_variant = {
> PHY_LANE_2,
> PHY_LANE_CK,
> },
> + .unsupported_odd_h_timings = true,
>
> .init_resources = vc5_hdmi_init_resources,
> .csc_setup = vc5_hdmi_csc_setup,
> @@ -1855,6 +1866,7 @@ static const struct vc4_hdmi_variant
> bcm2711_hdmi1_variant = {
> PHY_LANE_CK,
> PHY_LANE_2,
> },
> + .unsupported_odd_h_timings = true,
>
> .init_resources = vc5_hdmi_init_resources,
> .csc_setup = vc5_hdmi_csc_setup,
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index 63c6f8bddf1d..6815e93b1a48 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -62,6 +62,9 @@ struct vc4_hdmi_variant {
> */
> enum vc4_hdmi_phy_channel phy_lane_mapping[4];
>
> + /* The BCM2711 cannot deal with odd horizontal pixel timings */
> + bool unsupported_odd_h_timings;
> +
> /* Callback to get the resources (memory region, interrupts,
> * clocks, etc) for that variant.
> */
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] drm/vc4: hdmi: Make sure our clock rate is within limits
Hi Maxime
On Thu, 29 Oct 2020 at 12:25, Maxime Ripard wrote:
>
> The HDMI controller cannot go above a certain pixel rate limit depending on
> the generations, but that limit is only enforced in mode_valid at the
> moment, which means that we won't advertise modes that exceed that limit,
> but the userspace is still free to try to setup a mode that would.
>
> Implement atomic_check to make sure we check it in that scenario too.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
>
> Changes from v1:
> - Added that patch to resolve a conflict
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index e8f99e290655..3d0338822cd2 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -760,6 +760,20 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder
> *encoder)
> {
> }
>
> +static int vc4_hdmi_encoder_atomic_check(struct drm_encoder *encoder,
> +struct drm_crtc_state *crtc_state,
> +struct drm_connector_state
> *conn_state)
> +{
> + struct drm_display_mode *mode = _state->adjusted_mode;
> + struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> + unsigned long long pixel_rate = mode->clock * 1000;
> +
> + if (pixel_rate > vc4_hdmi->variant->max_pixel_clock)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> static enum drm_mode_status
> vc4_hdmi_encoder_mode_valid(struct drm_encoder *encoder,
> const struct drm_display_mode *mode)
> @@ -773,6 +787,7 @@ vc4_hdmi_encoder_mode_valid(struct drm_encoder *encoder,
> }
>
> static const struct drm_encoder_helper_funcs vc4_hdmi_encoder_helper_funcs =
> {
> + .atomic_check = vc4_hdmi_encoder_atomic_check,
> .mode_valid = vc4_hdmi_encoder_mode_valid,
> .disable = vc4_hdmi_encoder_disable,
> .enable = vc4_hdmi_encoder_enable,
> --
> 2.26.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: hdmi: Don't poll for the infoframes status on setup
Hi Maxime
On Thu, 19 Nov 2020 at 09:20, Maxime Ripard wrote:
>
> The infoframes are sent at a regular interval as a data island packet,
> so we don't need to wait for them to be sent when we're setting them up.
>
> However, we do need to poll when we're disabling since the we can't
> update the packet RAM until it has been sent.
>
> Let's add a boolean flag to tell whether we want to poll or not to
> support both cases.
>
> Suggested-by: Dave Stevenson
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 285c871b02fb..e1bbdba646db 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -265,7 +265,8 @@ static int vc4_hdmi_connector_init(struct drm_device *dev,
> }
>
> static int vc4_hdmi_stop_packet(struct drm_encoder *encoder,
> - enum hdmi_infoframe_type type)
> + enum hdmi_infoframe_type type,
> + bool poll)
> {
> struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
> u32 packet_id = type - 0x80;
> @@ -273,6 +274,9 @@ static int vc4_hdmi_stop_packet(struct drm_encoder
> *encoder,
> HDMI_WRITE(HDMI_RAM_PACKET_CONFIG,
>HDMI_READ(HDMI_RAM_PACKET_CONFIG) & ~BIT(packet_id));
>
> + if (!poll)
> + return 0;
> +
> return wait_for(!(HDMI_READ(HDMI_RAM_PACKET_STATUS) &
> BIT(packet_id)), 100);
> }
> @@ -299,7 +303,7 @@ static void vc4_hdmi_write_infoframe(struct drm_encoder
> *encoder,
> if (len < 0)
> return;
>
> - ret = vc4_hdmi_stop_packet(encoder, frame->any.type);
> + ret = vc4_hdmi_stop_packet(encoder, frame->any.type, false);
Have we got the poll flags the right way up here?
When updating we must wait before updating the ram packet registers,
which means we want to wait, so doesn't poll want to be true here?
In vc4_hdmi_audio_reset where we're just stopping the audio we don't
care about waiting, so poll can be false.
Dave
> if (ret) {
> DRM_ERROR("Failed to wait for infoframe to go idle: %d\n",
> ret);
> return;
> @@ -1055,7 +1059,7 @@ static void vc4_hdmi_audio_reset(struct vc4_hdmi
> *vc4_hdmi)
> int ret;
>
> vc4_hdmi->audio.streaming = false;
> - ret = vc4_hdmi_stop_packet(encoder, HDMI_INFOFRAME_TYPE_AUDIO);
> + ret = vc4_hdmi_stop_packet(encoder, HDMI_INFOFRAME_TYPE_AUDIO, true);
> if (ret)
> dev_err(dev, "Failed to stop audio infoframe: %d\n", ret);
>
> --
> 2.28.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/vc4: hdmi: Block odd horizontal timings
On Thu, 29 Oct 2020 at 09:17, Maxime Ripard wrote: > > Hi! > > On Wed, Oct 28, 2020 at 01:42:20PM +, Dave Stevenson wrote: > > Hi Maxime > > > > On Fri, 25 Sep 2020 at 14:00, Maxime Ripard wrote: > > > > > > The FIFO between the pixelvalve and the HDMI controller runs at 2 pixels > > > per clock cycle, and cannot deal with odd timings. > > > > > > Let's reject any mode with such timings. > > > > > > Signed-off-by: Maxime Ripard > > Thanks for your review > > > It's unsupported due to the architecture rather than broken. > > Would you prefer s/broken/unsupported/ then? If you needed to respin then yes, but it's not that big a deal. Dave ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/vc4: Correct POS1_SCL for hvs5
Hi Maxime.
On Thu, 21 Jan 2021 at 10:58, Maxime Ripard wrote:
>
> From: Dom Cobley
>
> Fixes failure with 4096x1080 resolutions
>
> [ 284.315379] WARNING: CPU: 1 PID: 901 at
> drivers/gpu/drm/vc4/vc4_plane.c:981 vc4_plane_mode_set+0x1374/0x13c4
> [ 284.315385] Modules linked in: ir_rc5_decoder rpivid_hevc(C)
> bcm2835_codec(C) bcm2835_isp(C) bcm2835_mmal_vchiq(C) bcm2835_gpiomem
> v4l2_mem2mem videobuf2_dma_contig videobuf2_memops videobuf2_v4l2
> videobuf2_common videodev mc cdc_acm xpad ir_rc6_decoder rc_rc6_mce
> gpio_ir_recv fuse
> [ 284.315509] CPU: 1 PID: 901 Comm: kodi.bin Tainted: G C
> 5.10.7 #1
> [ 284.315514] Hardware name: BCM2711
> [ 284.315518] Backtrace:
> [ 284.315533] [] (dump_backtrace) from []
> (show_stack+0x20/0x24)
> [ 284.315540] r7: r6: r5:6813 r4:c18ecf1c
> [ 284.315549] [] (show_stack) from []
> (dump_stack+0xc4/0xf0)
> [ 284.315558] [] (dump_stack) from [] (__warn+0xfc/0x158)
> [ 284.315564] r9: r8:0009 r7:03d5 r6:0009 r5:c08cc7dc
> r4:c0fd09b8
> [ 284.315572] [] (__warn) from []
> (warn_slowpath_fmt+0x74/0xe4)
> [ 284.315577] r7:c08cc7dc r6:03d5 r5:c0fd09b8 r4:
> [ 284.315584] [] (warn_slowpath_fmt) from []
> (vc4_plane_mode_set+0x1374/0x13c4)
> [ 284.315589] r8: r7: r6:1000 r5:c404c600 r4:c2e34600
> [ 284.315596] [] (vc4_plane_mode_set) from []
> (vc4_plane_atomic_check+0x40/0x1c0)
> [ 284.315601] r10:0001 r9:c2e34600 r8:c0e67068 r7:c0fc44e0 r6:c2ce3640
> r5:c3d636c0
> [ 284.315605] r4:c2e34600
> [ 284.315614] [] (vc4_plane_atomic_check) from []
> (drm_atomic_helper_check_planes+0xec/0x1ec)
> [ 284.315620] r9:c2e34600 r8:c0e67068 r7:c0fc44e0 r6:c2ce3640 r5:c3d636c0
> r4:0006
> [ 284.315627] [] (drm_atomic_helper_check_planes) from
> [] (drm_atomic_helper_check+0x54/0x9c)
> [ 284.315633] r9:c2e35400 r8:0006 r7: r6:c2ba7800 r5:c3d636c0
> r4:
> [ 284.315641] [] (drm_atomic_helper_check) from []
> (vc4_atomic_check+0x25c/0x454)
> [ 284.315645] r7: r6:c2ba7800 r5:0001 r4:c3d636c0
> [ 284.315652] [] (vc4_atomic_check) from []
> (drm_atomic_check_only+0x5cc/0x7e0)
> [ 284.315658] r10:c404c6c8 r9: r8:c472c480 r7:0003 r6:c3d636c0
> r5:
> [ 284.315662] r4:003c r3:c08b7a4c
> [ 284.315670] [] (drm_atomic_check_only) from []
> (drm_mode_atomic_ioctl+0x758/0xa7c)
> [ 284.315675] r10:c3d46000 r9:c3d636c0 r8:c2ce8a70 r7:027e3a54 r6:0043
> r5:c1fbb800
> [ 284.315679] r4:0281a858
> [ 284.315688] [] (drm_mode_atomic_ioctl) from []
> (drm_ioctl_kernel+0xc4/0x108)
> [ 284.315693] r10:c03864bc r9:c1fbb800 r8:c3d47e64 r7:c089b308 r6:0002
> r5:c2ba7800
> [ 284.315697] r4:
> [ 284.315705] [] (drm_ioctl_kernel) from []
> (drm_ioctl+0x1e8/0x3a0)
> [ 284.315711] r9:c1fbb800 r8:00bc r7:c3d47e64 r6:0038 r5:c0e59570
> r4:0038
> [ 284.315719] [] (drm_ioctl) from []
> (sys_ioctl+0x35c/0x914)
> [ 284.315724] r10:c2d08200 r9: r8:c36fa300 r7:befdd870 r6:c03864bc
> r5:c36fa301
> [ 284.315728] r4:c03864bc
> [ 284.315735] [] (sys_ioctl) from []
> (ret_fast_syscall+0x0/0x28)
> [ 284.315739] Exception stack(0xc3d47fa8 to 0xc3d47ff0)
> [ 284.315745] 7fa0: 027eb750 befdd870 c03864bc
> befdd870
> [ 284.315750] 7fc0: 027eb750 befdd870 c03864bc 0036 027e3948 0281a640
> 0281a850 027e3a50
> [ 284.315756] 7fe0: b4b64100 befdd844 b4b5ba2c b49c994c
> [ 284.315762] r10:0036 r9:c3d46000 r8:c0200204 r7:0036 r6:c03864bc
> r5:befdd870
> [ 284.315765] r4:027eb750
>
> Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5")
> Signed-off-by: Dom Cobley
> Signed-off-by: Maxime Ripard
Reviewed-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_plane.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
> index b98eabb52920..8c55679cbaef 100644
> --- a/drivers/gpu/drm/vc4/vc4_plane.c
> +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> @@ -917,9 +917,9 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
> if (!vc4_state->is_unity) {
> vc4_dlist_write(vc4_state,
> VC4_SET_FIELD(vc4_state->crtc_w,
> - SCALER_POS1_SCL_WIDTH) |
> + SCALER5_POS1_SCL_WIDTH)
> |
> VC4_SET_FIELD(vc4_state->crtc_h,
> -
> SCALER_POS1_SCL_HEIGH
Re: [PATCH v2 05/15] drm/vc4: hdmi: Restore cec physical address on reconnect
Hi Maxime
Sorry for the slow reply on these patches.
On Mon, 11 Jan 2021 at 14:23, Maxime Ripard wrote:
>
> From: Dom Cobley
>
> Currently we call cec_phys_addr_invalidate on a hotplug deassert.
> That may be due to a TV power cycling, or an AVR being switched
> on (and switching edid).
>
> This makes CEC unusable since our controller wouldn't have a physical
> address anymore.
>
> Set it back up again on the hotplug assert.
>
> Fixes: 15b4511a4af6 ("drm/vc4: add HDMI CEC support")
> Signed-off-by: Dom Cobley
> Signed-off-by: Maxime Ripard
I follow the logic, and trust Dom that it works, but I don't know if
that is the correct thing within CEC.
Ideally Hans will comment as the original author of the CEC code - I
believe he's testing the series anyway.
Acked-by: Dave Stevenson
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 24 ++--
> 1 file changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 7945dbcee78c..c3a301396aad 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -136,20 +136,32 @@ static enum drm_connector_status
> vc4_hdmi_connector_detect(struct drm_connector *connector, bool force)
> {
> struct vc4_hdmi *vc4_hdmi = connector_to_vc4_hdmi(connector);
> + bool connected = false;
>
> if (vc4_hdmi->hpd_gpio) {
> if (gpio_get_value_cansleep(vc4_hdmi->hpd_gpio) ^
> vc4_hdmi->hpd_active_low)
> - return connector_status_connected;
> - cec_phys_addr_invalidate(vc4_hdmi->cec_adap);
> - return connector_status_disconnected;
> + connected = true;
> + } else if (drm_probe_ddc(vc4_hdmi->ddc)) {
> + connected = true;
> + } else if (HDMI_READ(HDMI_HOTPLUG) & VC4_HDMI_HOTPLUG_CONNECTED) {
> + connected = true;
> }
>
> - if (drm_probe_ddc(vc4_hdmi->ddc))
> - return connector_status_connected;
> + if (connected) {
> + if (connector->status != connector_status_connected) {
> + struct edid *edid = drm_get_edid(connector,
> vc4_hdmi->ddc);
> +
> + if (edid) {
> + cec_s_phys_addr_from_edid(vc4_hdmi->cec_adap,
> edid);
> + vc4_hdmi->encoder.hdmi_monitor =
> drm_detect_hdmi_monitor(edid);
> + kfree(edid);
> + }
> + }
>
> - if (HDMI_READ(HDMI_HOTPLUG) & VC4_HDMI_HOTPLUG_CONNECTED)
> return connector_status_connected;
> + }
> +
> cec_phys_addr_invalidate(vc4_hdmi->cec_adap);
> return connector_status_disconnected;
> }
> --
> 2.29.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
