Re: [PATCH 2/3] drm/vc4: Drop legacy_cursor_update override

2020-10-23 Thread Maxime Ripard
On Wed, Oct 21, 2020 at 06:32:41PM +0200, Daniel Vetter wrote:
> With the removal of helper support it doesn't do anything anymore.
> Also, we already have async plane update code in vc4.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Eric Anholt 
> Cc: Maxime Ripard 

Acked-by: Maxime Ripard 

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PULL] drm-misc-next-fixes

2020-10-21 Thread Maxime Ripard
Hi!

Here's a couple of patches that should be merged in the current merge-window.

Thanks!
Maxime

drm-misc-next-fixes-2020-10-20:
Two patches to prevent out-of-bands accesses on fonts buffers
The following changes since commit d3c8f2784d3266d27956659c78835ee1d1925ad2:

  drm/ingenic: Fix bad revert (2020-10-12 20:26:14 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2020-10-20

for you to fetch changes up to 272d70895113ef00c03ab325787d159ee51718c8:

  Fonts: Support FONT_EXTRA_WORDS macros for font_6x8 (2020-10-19 17:55:10 
+0200)


Two patches to prevent out-of-bands accesses on fonts buffers


Peilin Ye (2):
  docs: fb: Add font_6x8 to available built-in fonts
  Fonts: Support FONT_EXTRA_WORDS macros for font_6x8

 Documentation/fb/fbcon.rst | 2 +-
 lib/fonts/font_6x8.c   | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/4] drm/vc4: kms: Split the HVS muxing check in a separate function

2020-10-19 Thread Maxime Ripard
Hi Hoegeun,

On Mon, Oct 12, 2020 at 09:25:05PM +0900, Hoegeun Kwon wrote:
> Hi Maxime,
> 
> On 10/8/20 8:25 PM, Maxime Ripard wrote:
> > The code that assigns HVS channels during atomic_check is starting to grow
> > a bit big, let's move it into a separate function.
> >
> > Signed-off-by: Maxime Ripard 
> 
> Thanks for this patch set, I checked all patches well works.
> 
> All patches:
> 
> Reviewed-by: Hoegeun Kwon 
> Tested-by: Hoegeun Kwon 

Following some discussion with Daniel last week, this is going to be
significantly reworked for the next iteration, so I won't take your tags
(but will Cc you for the next version).

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 3/3] drm/sun4i: frontend: Fix the scaler phase on A33

2020-10-17 Thread Maxime Ripard
The A33 has a different phase parameter in the Allwinner BSP on the
channel1 than the one currently applied. Fix this.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_frontend.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c 
b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index d32b12cbbb60..ff4187eab519 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -694,7 +694,7 @@ static const struct sun4i_frontend_data sun4i_a10_frontend 
= {
 };
 
 static const struct sun4i_frontend_data sun8i_a33_frontend = {
-   .ch_phase   = { 0x400, 0x400 },
+   .ch_phase   = { 0x400, 0xfc400 },
.has_coef_access_ctrl   = true,
 };
 
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 1/3] drm/sun4i: frontend: Rework a bit the phase data

2020-10-17 Thread Maxime Ripard
The scaler filter phase setup in the allwinner kernel has two different
cases for setting up the scaler filter, the first one using different phase
parameters for the two channels, and the second one reusing the first
channel parameters on the second channel.

The allwinner kernel has a third option where the horizontal phase of the
second channel will be set to a different value than the vertical one (and
seems like it's the same value than one used on the first channel).
However, that code path seems to never be taken, so we can ignore it for
now, and it's essentially what we're doing so far as well.

Since we will have always the same values across each components of the
filter setup for a given channel, we can simplify a bit our frontend
structure by only storing the phase value we want to apply to a given
channel.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_frontend.c | 34 ++
 drivers/gpu/drm/sun4i/sun4i_frontend.h |  6 +
 2 files changed, 9 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c 
b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index ec2a032e07b9..7462801b1fa8 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -443,17 +443,17 @@ int sun4i_frontend_update_formats(struct sun4i_frontend 
*frontend,
 * related to the scaler FIR filter phase parameters.
 */
regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_HORZPHASE_REG,
-frontend->data->ch_phase[0].horzphase);
+frontend->data->ch_phase[0]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_HORZPHASE_REG,
-frontend->data->ch_phase[1].horzphase);
+frontend->data->ch_phase[1]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE0_REG,
-frontend->data->ch_phase[0].vertphase[0]);
+frontend->data->ch_phase[0]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE0_REG,
-frontend->data->ch_phase[1].vertphase[0]);
+frontend->data->ch_phase[1]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE1_REG,
-frontend->data->ch_phase[0].vertphase[1]);
+frontend->data->ch_phase[0]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE1_REG,
-frontend->data->ch_phase[1].vertphase[1]);
+frontend->data->ch_phase[1]);
 
/*
 * Checking the input format is sufficient since we currently only
@@ -687,30 +687,12 @@ static const struct dev_pm_ops sun4i_frontend_pm_ops = {
 };
 
 static const struct sun4i_frontend_data sun4i_a10_frontend = {
-   .ch_phase   = {
-   {
-   .horzphase = 0,
-   .vertphase = { 0, 0 },
-   },
-   {
-   .horzphase = 0xfc000,
-   .vertphase = { 0xfc000, 0xfc000 },
-   },
-   },
+   .ch_phase   = { 0x000, 0xfc000 },
.has_coef_rdy   = true,
 };
 
 static const struct sun4i_frontend_data sun8i_a33_frontend = {
-   .ch_phase   = {
-   {
-   .horzphase = 0x400,
-   .vertphase = { 0x400, 0x400 },
-   },
-   {
-   .horzphase = 0x400,
-   .vertphase = { 0x400, 0x400 },
-   },
-   },
+   .ch_phase   = { 0x400, 0x400 },
.has_coef_access_ctrl   = true,
 };
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.h 
b/drivers/gpu/drm/sun4i/sun4i_frontend.h
index 0c382c1ddb0f..2e7b76e50c2b 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.h
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.h
@@ -115,11 +115,7 @@ struct reset_control;
 struct sun4i_frontend_data {
boolhas_coef_access_ctrl;
boolhas_coef_rdy;
-
-   struct {
-   u32 horzphase;
-   u32 vertphase[2];
-   } ch_phase[2];
+   u32 ch_phase[2];
 };
 
 struct sun4i_frontend {
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 2/3] drm/sun4i: frontend: Reuse the ch0 phase for RGB formats

2020-10-17 Thread Maxime Ripard
When using the scaler on the A10-like frontend with single-planar formats,
the current code will setup the channel 0 filter (used for the R or Y
component) with a different phase parameter than the channel 1 filter (used
for the G/B or U/V components).

This creates a bleed out that keeps repeating on of the last line of the
RGB plane across the rest of the display. The Allwinner BSP either applies
the same phase parameter over both channels or use a separate one, the
condition being whether the input format is YUV420 or not.

Since YUV420 is both subsampled and multi-planar, and since YUYV is
subsampled but single-planar, we can rule out the subsampling and assume
that the condition is actually whether the format is single or
multi-planar. And it looks like applying the same phase parameter over both
channels for single-planar formats fixes our issue, while we keep the
multi-planar formats working properly.

Reported-by: Taras Galchenko 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_frontend.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_frontend.c 
b/drivers/gpu/drm/sun4i/sun4i_frontend.c
index 7462801b1fa8..d32b12cbbb60 100644
--- a/drivers/gpu/drm/sun4i/sun4i_frontend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_frontend.c
@@ -407,6 +407,7 @@ int sun4i_frontend_update_formats(struct sun4i_frontend 
*frontend,
struct drm_framebuffer *fb = state->fb;
const struct drm_format_info *format = fb->format;
uint64_t modifier = fb->modifier;
+   unsigned ch1_phase_idx;
u32 out_fmt_val;
u32 in_fmt_val, in_mod_val, in_ps_val;
unsigned int i;
@@ -442,18 +443,19 @@ int sun4i_frontend_update_formats(struct sun4i_frontend 
*frontend,
 * I have no idea what this does exactly, but it seems to be
 * related to the scaler FIR filter phase parameters.
 */
+   ch1_phase_idx = (format->num_planes > 1) ? 1 : 0;
regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_HORZPHASE_REG,
 frontend->data->ch_phase[0]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_HORZPHASE_REG,
-frontend->data->ch_phase[1]);
+frontend->data->ch_phase[ch1_phase_idx]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE0_REG,
 frontend->data->ch_phase[0]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE0_REG,
-frontend->data->ch_phase[1]);
+frontend->data->ch_phase[ch1_phase_idx]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH0_VERTPHASE1_REG,
 frontend->data->ch_phase[0]);
regmap_write(frontend->regs, SUN4I_FRONTEND_CH1_VERTPHASE1_REG,
-frontend->data->ch_phase[1]);
+frontend->data->ch_phase[ch1_phase_idx]);
 
/*
 * Checking the input format is sufficient since we currently only
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] MAINTAINERS: Add myself as a maintainer for vc4

2020-10-14 Thread Maxime Ripard
On Fri, Oct 09, 2020 at 09:54:28AM -0700, Eric Anholt wrote:
> Reviewed-by: Eric Anholt 

Thanks! I applied it to drm-misc-next

> I'd be fine with retiring from being maintainer, too.  I'm definitely
> not active.

Ultimately that's up to you, but I guess it would be nice to still stick
around since you obviously have much more experience with the hardware
and the driver :)

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PULL] drm-misc-next-fixes

2020-10-13 Thread Maxime Ripard
Hi Dave,

Here's the remaining patches we have in drm-misc-next-fixes

Maxime

drm-misc-next-fixes-2020-10-13:
One fix for a bad revert in ingenic-drm, and one fix for panfrost to increase a 
timeout at power up.
The following changes since commit 8ba0b6d196315f68c271f549e8585129caefce97:

  drm/vc4: crtc: Keep the previously assigned HVS FIFO (2020-09-25 16:56:21 
+0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2020-10-13

for you to fetch changes up to d3c8f2784d3266d27956659c78835ee1d1925ad2:

  drm/ingenic: Fix bad revert (2020-10-12 20:26:14 +0200)


One fix for a bad revert in ingenic-drm, and one fix for panfrost to increase a 
timeout at power up.


Christian Hewitt (1):
  drm/panfrost: increase readl_relaxed_poll_timeout values

Ondrej Jirman (1):
  MAINTAINERS: Update entry for st7703 driver after the rename

Paul Cercueil (2):
  Revert "gpu/drm: ingenic: Add option to mmap GEM buffers cached"
  drm/ingenic: Fix bad revert

 MAINTAINERS   |   7 +-
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 114 +-
 drivers/gpu/drm/ingenic/ingenic-drm.h |   4 --
 drivers/gpu/drm/ingenic/ingenic-ipu.c |  12 +---
 drivers/gpu/drm/panfrost/panfrost_gpu.c   |   4 +-
 5 files changed, 10 insertions(+), 131 deletions(-)


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PULL] drm-misc-next-fixes

2020-10-10 Thread Maxime Ripard
Hi Dave, Daniel,

Here's this week PR for drm-misc-next-fixes

Maxime

drm-misc-next-fixes-2020-10-09:
One MAINTAINERS change and a revert for a compilation breakage in next for
ingenic
The following changes since commit 089d83418914abd4d908db117d9a3eca7f51a68c:

  drm/vc4: hvs: Pull the state of all the CRTCs prior to PV muxing (2020-09-21 
16:43:11 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2020-10-09

for you to fetch changes up to 6561e0aa4627da90f59076fec5e3a1b72a8aa63f:

  MAINTAINERS: Update entry for st7703 driver after the rename (2020-10-09 
08:55:00 +0200)


One MAINTAINERS change and a revert for a compilation breakage in next for
ingenic


Maxime Ripard (3):
  drm/vc4: kms: Assign a FIFO to enabled CRTCs instead of active
  drm/vc4: crtc: Rework a bit the CRTC state code
  drm/vc4: crtc: Keep the previously assigned HVS FIFO

Ondrej Jirman (1):
  MAINTAINERS: Update entry for st7703 driver after the rename

Paul Cercueil (1):
  Revert "gpu/drm: ingenic: Add option to mmap GEM buffers cached"

 MAINTAINERS   |   7 +-
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 116 +++---
 drivers/gpu/drm/ingenic/ingenic-drm.h |   4 --
 drivers/gpu/drm/ingenic/ingenic-ipu.c |  12 +---
 drivers/gpu/drm/vc4/vc4_crtc.c|  14 +++-
 drivers/gpu/drm/vc4/vc4_drv.h |   2 +
 drivers/gpu/drm/vc4/vc4_kms.c |  22 --
 7 files changed, 46 insertions(+), 131 deletions(-)


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] MAINTAINERS: Add myself as a maintainer for vc4

2020-10-10 Thread Maxime Ripard
Eric isn't working on vc4 anymore and I've been working on it, as well as
merging patches for it, recently so let's make it official so I don't miss
patches.

Signed-off-by: Maxime Ripard 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 91d46806e511..a248e3a2b537 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5957,6 +5957,7 @@ F:include/uapi/drm/v3d_drm.h
 
 DRM DRIVERS FOR VC4
 M: Eric Anholt 
+M: Maxime Ripard 
 S: Supported
 T: git git://github.com/anholt/linux
 T: git git://anongit.freedesktop.org/drm/drm-misc
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 3/6] drm/vc4: Pass the atomic state to encoder hooks

2020-10-09 Thread Maxime Ripard
We'll need to access the connector state in our encoder setup, so let's
just pass the whole DRM state to our private encoder hooks.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 18 ++
 drivers/gpu/drm/vc4/vc4_drv.h  | 10 +-
 drivers/gpu/drm/vc4/vc4_hdmi.c | 15 ++-
 3 files changed, 25 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index b5deacfe16cd..4204c5e37ffe 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -403,7 +403,9 @@ static void require_hvs_enabled(struct drm_device *dev)
 SCALER_DISPCTRL_ENABLE);
 }
 
-static int vc4_crtc_disable(struct drm_crtc *crtc, unsigned int channel)
+static int vc4_crtc_disable(struct drm_crtc *crtc,
+   struct drm_atomic_state *state,
+   unsigned int channel)
 {
struct drm_encoder *encoder = vc4_get_crtc_encoder(crtc);
struct vc4_encoder *vc4_encoder = to_vc4_encoder(encoder);
@@ -435,13 +437,13 @@ static int vc4_crtc_disable(struct drm_crtc *crtc, 
unsigned int channel)
mdelay(20);
 
if (vc4_encoder && vc4_encoder->post_crtc_disable)
-   vc4_encoder->post_crtc_disable(encoder);
+   vc4_encoder->post_crtc_disable(encoder, state);
 
vc4_crtc_pixelvalve_reset(crtc);
vc4_hvs_stop_channel(dev, channel);
 
if (vc4_encoder && vc4_encoder->post_crtc_powerdown)
-   vc4_encoder->post_crtc_powerdown(encoder);
+   vc4_encoder->post_crtc_powerdown(encoder, state);
 
return 0;
 }
@@ -468,7 +470,7 @@ int vc4_crtc_disable_at_boot(struct drm_crtc *crtc)
if (channel < 0)
return 0;
 
-   return vc4_crtc_disable(crtc, channel);
+   return vc4_crtc_disable(crtc, NULL, channel);
 }
 
 static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
@@ -484,7 +486,7 @@ static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
/* Disable vblank irq handling before crtc is disabled. */
drm_crtc_vblank_off(crtc);
 
-   vc4_crtc_disable(crtc, old_vc4_state->assigned_channel);
+   vc4_crtc_disable(crtc, state, old_vc4_state->assigned_channel);
 
/*
 * Make sure we issue a vblank event after disabling the CRTC if
@@ -518,14 +520,14 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
vc4_hvs_atomic_enable(crtc, state);
 
if (vc4_encoder->pre_crtc_configure)
-   vc4_encoder->pre_crtc_configure(encoder);
+   vc4_encoder->pre_crtc_configure(encoder, state);
 
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);
+   vc4_encoder->pre_crtc_enable(encoder, state);
 
/* When feeding the transposer block the pixelvalve is unneeded and
 * should not be enabled.
@@ -534,7 +536,7 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
   CRTC_READ(PV_V_CONTROL) | PV_VCONTROL_VIDEN);
 
if (vc4_encoder->post_crtc_enable)
-   vc4_encoder->post_crtc_enable(encoder);
+   vc4_encoder->post_crtc_enable(encoder, state);
 }
 
 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 92996c99600d..30dfe113dfd0 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -442,12 +442,12 @@ struct vc4_encoder {
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 (*pre_crtc_configure)(struct drm_encoder *encoder, struct 
drm_atomic_state *state);
+   void (*pre_crtc_enable)(struct drm_encoder *encoder, struct 
drm_atomic_state *state);
+   void (*post_crtc_enable)(struct drm_encoder *encoder, struct 
drm_atomic_state *state);
 
-   void (*post_crtc_disable)(struct drm_encoder *encoder);
-   void (*post_crtc_powerdown)(struct drm_encoder *encoder);
+   void (*post_crtc_disable)(struct drm_encoder *encoder, struct 
drm_atomic_state *state);
+   void (*post_crtc_powerdown)(struct drm_encoder *encoder, struct 
drm_atomic_state *state);
 };
 
 static inline struct vc4_encoder *
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 03825596a308..7d2593398094 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -357,7 +357,8 @@ static void vc4_hdmi_set_infoframes(struct drm_encoder 
*encoder)
vc4_hdmi_set_audio_infoframe(encoder);
 }
 
-static void vc4_hd

[PATCH 1/4] drm/vc4: kms: Split the HVS muxing check in a separate function

2020-10-09 Thread Maxime Ripard
The code that assigns HVS channels during atomic_check is starting to grow
a bit big, let's move it into a separate function.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_kms.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 149825ff5df8..846fe8b3cb7a 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -612,13 +612,13 @@ static const struct drm_private_state_funcs 
vc4_load_tracker_state_funcs = {
 #define NUM_OUTPUTS  6
 #define NUM_CHANNELS 3
 
-static int
-vc4_atomic_check(struct drm_device *dev, struct drm_atomic_state *state)
+static int vc4_pv_muxing_atomic_check(struct drm_device *dev,
+ struct drm_atomic_state *state)
 {
unsigned long unassigned_channels = GENMASK(NUM_CHANNELS - 1, 0);
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
struct drm_crtc *crtc;
-   int i, ret;
+   unsigned int i;
 
/*
 * Since the HVS FIFOs are shared across all the pixelvalves and
@@ -691,6 +691,18 @@ vc4_atomic_check(struct drm_device *dev, struct 
drm_atomic_state *state)
}
}
 
+   return 0;
+}
+
+static int
+vc4_atomic_check(struct drm_device *dev, struct drm_atomic_state *state)
+{
+   int ret;
+
+   ret = vc4_pv_muxing_atomic_check(dev, state);
+   if (ret)
+   return ret;
+
ret = vc4_ctm_atomic_check(dev, state);
if (ret < 0)
return ret;
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 6/6] drm/vc4: hdmi: Enable 10/12 bpc output

2020-10-09 Thread Maxime Ripard
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  | 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);
HDMI_WRITE(HDMI_HORZA,
@@ -583,6 +611,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, reg);
+
+   reg = HDMI_READ(HDMI_GCP_WORD_1);
+   reg &= ~VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_MASK;
+   reg |= VC4_SET_FIELD(gcp, VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1);
+   HDMI_WRITE(HDMI_GCP_WORD_1, reg);
+
+   reg = HDMI_READ(HDMI_GCP_CONFIG);
+   reg &= ~VC5_HDMI_GCP_CONFIG_GCP_ENAB

[PATCH 2/4] drm/vc4: kms: Document the muxing corner cases

2020-10-09 Thread Maxime Ripard
We've had a number of muxing corner-cases with specific ways to reproduce
them, so let's document them to make sure they aren't lost and introduce
regressions later on.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_kms.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 846fe8b3cb7a..3b5e62842901 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -612,6 +612,28 @@ static const struct drm_private_state_funcs 
vc4_load_tracker_state_funcs = {
 #define NUM_OUTPUTS  6
 #define NUM_CHANNELS 3
 
+/*
+ * The BCM2711 HVS has up to 7 output connected to the pixelvalves and
+ * the TXP (and therefore all the CRTCs found on that platform).
+ *
+ * The naive (and our initial) implementation would just iterate over
+ * all the active CRTCs, try to find a suitable FIFO, and then remove it
+ * from the available FIFOs pool. However, there's a few corner cases
+ * that need to be considered:
+ *
+ * - When running in a dual-display setup (so with two CRTCs involved),
+ *   we can update the state of a single CRTC (for example by changing
+ *   its mode using xrandr under X11) without affecting the other. In
+ *   this case, the other CRTC wouldn't be in the state at all, so we
+ *   need to consider all the running CRTCs in the DRM device to assign
+ *   a FIFO, not just the one in the state.
+ *
+ * - Since we need the pixelvalve to be disabled and enabled back when
+ *   the FIFO is changed, we should keep the FIFO assigned for as long
+ *   as the CRTC is enabled, only considering it free again once that
+ *   CRTC has been disabled. This can be tested by booting X11 on a
+ *   single display, and changing the resolution down and then back up.
+ */
 static int vc4_pv_muxing_atomic_check(struct drm_device *dev,
  struct drm_atomic_state *state)
 {
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 2/6] drm/vc4: hvs: Align the HVS atomic hooks to the new API

2020-10-09 Thread Maxime Ripard
Since the CRTC setup in vc4 is split between the PixelValves/TXP and the
HVS, only the PV/TXP atomic hooks were updated in the previous commits, but
it makes sense to update the HVS ones too.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 4 +---
 drivers/gpu/drm/vc4/vc4_drv.h  | 4 ++--
 drivers/gpu/drm/vc4/vc4_hvs.c  | 8 +---
 drivers/gpu/drm/vc4/vc4_txp.c  | 8 ++--
 4 files changed, 10 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 97b1f1f7aa18..b5deacfe16cd 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -503,8 +503,6 @@ static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
 static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
   struct drm_atomic_state *state)
 {
-   struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state,
-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);
@@ -517,7 +515,7 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
 */
drm_crtc_vblank_on(crtc);
 
-   vc4_hvs_atomic_enable(crtc, old_state);
+   vc4_hvs_atomic_enable(crtc, state);
 
if (vc4_encoder->pre_crtc_configure)
vc4_encoder->pre_crtc_configure(encoder);
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index a22478a35199..92996c99600d 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -912,8 +912,8 @@ extern struct platform_driver vc4_hvs_driver;
 void vc4_hvs_stop_channel(struct drm_device *dev, unsigned int output);
 int vc4_hvs_get_fifo_from_output(struct drm_device *dev, unsigned int output);
 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_enable(struct drm_crtc *crtc, struct drm_atomic_state 
*state);
+void vc4_hvs_atomic_disable(struct drm_crtc *crtc, struct drm_atomic_state 
*state);
 void vc4_hvs_atomic_flush(struct drm_crtc *crtc, struct drm_crtc_state *state);
 void vc4_hvs_dump_state(struct drm_device *dev);
 void vc4_hvs_unmask_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 4d0a833366ce..22403ab2a430 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -391,11 +391,12 @@ static void vc4_hvs_update_dlist(struct drm_crtc *crtc)
 }
 
 void vc4_hvs_atomic_enable(struct drm_crtc *crtc,
-  struct drm_crtc_state *old_state)
+  struct drm_atomic_state *state)
 {
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_crtc_state *new_crtc_state = 
drm_atomic_get_new_crtc_state(state, crtc);
+   struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(new_crtc_state);
struct drm_display_mode *mode = >state->adjusted_mode;
bool oneshot = vc4_state->feed_txp;
 
@@ -404,9 +405,10 @@ void vc4_hvs_atomic_enable(struct drm_crtc *crtc,
 }
 
 void vc4_hvs_atomic_disable(struct drm_crtc *crtc,
-   struct drm_crtc_state *old_state)
+   struct drm_atomic_state *state)
 {
struct drm_device *dev = crtc->dev;
+   struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state, 
crtc);
struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(old_state);
unsigned int chan = vc4_state->assigned_channel;
 
diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
index e0e0b72ea65c..9fc8328f505c 100644
--- a/drivers/gpu/drm/vc4/vc4_txp.c
+++ b/drivers/gpu/drm/vc4/vc4_txp.c
@@ -404,23 +404,19 @@ static int vc4_txp_atomic_check(struct drm_crtc *crtc,
 static void vc4_txp_atomic_enable(struct drm_crtc *crtc,
  struct drm_atomic_state *state)
 {
-   struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state,
-crtc);
drm_crtc_vblank_on(crtc);
-   vc4_hvs_atomic_enable(crtc, old_state);
+   vc4_hvs_atomic_enable(crtc, state);
 }
 
 static void vc4_txp_atomic_disable(struct drm_crtc *crtc,
   struct drm_atomic_state *state)
 {
-   struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state,
-crtc);
struct drm_device *dev = crtc->dev;
 
 

Re: [PATCH v5 00/80] drm/vc4: Support BCM2711 Display Pipeline

2020-10-09 Thread Maxime Ripard
On Wed, Sep 16, 2020 at 06:57:05PM +0200, Maxime Ripard wrote:
> On Mon, Sep 14, 2020 at 07:14:11PM +0900, Hoegeun Kwon wrote:
> > Hi Maxime,
> > 
> > On 9/8/20 9:00 PM, Maxime Ripard wrote:
> > > Hi Hoegeun,
> > >
> > > On Mon, Sep 07, 2020 at 08:49:12PM +0900, Hoegeun Kwon wrote:
> > >> On 9/3/20 5:00 PM, Maxime Ripard wrote:
> > >>> Hi everyone,
> > >>>
> > >>> Here's a (pretty long) series to introduce support in the VC4 DRM driver
> > >>> for the display pipeline found in the BCM2711 (and thus the RaspberryPi 
> > >>> 4).
> > >>>
> > >>> The main differences are that there's two HDMI controllers and that 
> > >>> there's
> > >>> more pixelvalve now. Those pixelvalve come with a mux in the HVS that 
> > >>> still
> > >>> have only 3 FIFOs. Both of those differences are breaking a bunch of
> > >>> expectations in the driver, so we first need a good bunch of cleanup and
> > >>> reworks to introduce support for the new controllers.
> > >>>
> > >>> Similarly, the HDMI controller has all its registers shuffled and split 
> > >>> in
> > >>> multiple controllers now, so we need a bunch of changes to support this 
> > >>> as
> > >>> well.
> > >>>
> > >>> Only the HDMI support is enabled for now (even though the DPI and DSI
> > >>> outputs have been tested too).
> > >>>
> > >>> Let me know if you have any comments
> > >>> Maxime
> > >>>
> > >>> Cc: bcm-kernel-feedback-l...@broadcom.com
> > >>> Cc: devicet...@vger.kernel.org
> > >>> Cc: Kamal Dasu 
> > >>> Cc: Philipp Zabel 
> > >>> Cc: Rob Herring 
> > >>> Cc: Stephen Boyd 
> > >>>
> > >>> Changes from v4:
> > >>> - Rebased on top of next-20200828
> > >>> - Collected the various tags
> > >>> - Fixed some issues with 4k support and dual output (thanks 
> > >>> Hoegeun!)
> > >> Thanks for your v5 patchset.
> > >>
> > >> I tested all patches based on the next-20200812.
> > > Thanks again for testing all the patches
> > >
> > >> Everything else is fine, but the dual hdmi modetest doesn't work well in 
> > >> my
> > >> environment...
> > >>
> > >> In my environment, dsi is not connected, I have seen your answer[1].
> > > Can you share a bit more your setup? What monitors are being connected
> > > to each HDMI port? Do you hotplug any?
> > Yes, Monitors are being connected to each HDMI ports. (did not use hotplug)
> > 
> > When booting, both HDMI-0 and 1 are recognized and the kernel log is output.
> > But after run modetest on HDMI-0(works) and modetest on HDMI-1(works),
> > crtc timed out occurs on HDMI-0 and does not work.
> > 
> > When HDMI-0 is not working we do a modetest on HDMI-0, it will work agin
> > after about 40 sec.
> > 
> > Below is the log for modetest.
> > 
> > 
> > root:~> modetest -Mvc4 -s 32:1280x720         - HDMI-0 works
> > setting mode 1280x720-60Hz@XR24 on connectors 32, crtc 64
> > failed to set gamma: Invalid argument
> > 
> > root:~> modetest -Mvc4 -s 32:1280x720         - HDMI-0 works
> > setting mode 1280x720-60Hz@XR24 on connectors 32, crtc 64
> > failed to set gamma: Invalid argument
> > 
> > root:~> modetest -Mvc4 -s 38:1280x720         - HDMI-1 works
> > setting mode 1280x720-60Hz@XR24 on connectors 38, crtc 69
> > failed to set gamma: Invalid argument
> > 
> >                                - Crtc timed out occurs on HDMI-0 and 
> > does not work.
> > 
> > [   71.134283] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* 
> > [CRTC:64:crtc-3] flip_done timed out
> > [   81.374296] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
> > [CRTC:64:crtc-3] flip_done timed out
> > [   91.618380] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
> > [CONNECTOR:32:HDMI-A-1] flip_done timed out
> > [  101.854274] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
> > [PLANE:60:plane-3] flip_done timed out
> > 
> > [  112.094271] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* 
> > [CRTC:64:crtc-3] flip_done timed out
> > [  122.590311] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
> > [CRTC:64:crtc-3] flip

[PATCH v2 4/6] drm/vc4: hdmi: Create a custom connector state

2020-10-09 Thread Maxime Ripard
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.

Signed-off-by: Maxime Ripard 
---
 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 7d2593398094..5e4ebb51a750 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -170,16 +170,39 @@ 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);
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 63c6f8bddf1d..d53d9fd88bfe 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -169,6 +169,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);
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 5/6] drm/vc4: hdmi: Store pixel frequency in the connector state

2020-10-09 Thread Maxime Ripard
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 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 44 ++-
 drivers/gpu/drm/vc4/vc4_hdmi.h |  1 +-
 2 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 5e4ebb51a750..21d20c8494e8 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -192,6 +192,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;
@@ -609,9 +610,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;
@@ -623,7 +644,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);
@@ -788,6 +809,26 @@ 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 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;
+
+   if (mode->flags & DRM_MODE_FLAG_DBLCLK)
+   pixel_rate *= 2;
+
+   if (pixel_rate > vc4_hdmi->variant->max_pixel_clock)
+   return -EINVAL;
+
+   vc4_state->pixel_rate = pixel_rate;
+
+   return 0;
+}
+
 static enum drm_mode_status
 vc4_hdmi_encoder_mode_valid(struct drm_encoder *encoder,
const struct drm_display_mode *mode)
@@ -801,6 +842,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,
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index d53d9fd88bfe..dbe2393ae043 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -171,6 +171,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 *
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 0/6] drm/vc4: hdmi: Support the 10/12 bit output

2020-10-09 Thread Maxime Ripard
Hi,

Here's some patches to enable the HDR output in the RPi4 HDMI controller.

This needed a quite intrusive rework in the first patch to allow a CRTC to
have access to the whole DRM state at atomic_enable / atomic_disable time.

Let me know what you think,
Maxime

Changes from v1:
  - Added the coccinelle script to the first patch
  - Fixed the pixel_rate ramp up

Maxime Ripard (6):
  drm/atomic: Pass the full state to CRTC atomic enable/disable
  drm/vc4: hvs: Align the HVS atomic hooks to the new API
  drm/vc4: Pass the atomic state to encoder hooks
  drm/vc4: hdmi: Create a custom connector state
  drm/vc4: hdmi: Store pixel frequency in the connector state
  drm/vc4: hdmi: Enable 10/12 bpc output

 drivers/gpu/drm/arc/arcpgu_crtc.c|   4 +-
 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c |   8 +-
 drivers/gpu/drm/arm/hdlcd_crtc.c |   4 +-
 drivers/gpu/drm/arm/malidp_crtc.c|   6 +-
 drivers/gpu/drm/armada/armada_crtc.c |   8 +-
 drivers/gpu/drm/ast/ast_mode.c   |   6 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c   |   4 +-
 drivers/gpu/drm/drm_atomic_helper.c  |   4 +-
 drivers/gpu/drm/drm_simple_kms_helper.c  |   4 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |   4 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c   |   6 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c   |   4 +-
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c  |   4 +-
 drivers/gpu/drm/imx/dcss/dcss-crtc.c |   9 +-
 drivers/gpu/drm/imx/ipuv3-crtc.c |   6 +-
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c|   4 +-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c  |   4 +-
 drivers/gpu/drm/meson/meson_crtc.c   |   8 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c |   7 +-
 drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c|   4 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c|   4 +-
 drivers/gpu/drm/mxsfb/mxsfb_kms.c|   4 +-
 drivers/gpu/drm/omapdrm/omap_crtc.c  |   4 +-
 drivers/gpu/drm/qxl/qxl_display.c|   4 +-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c   |   6 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c  |   6 +-
 drivers/gpu/drm/sti/sti_crtc.c   |   4 +-
 drivers/gpu/drm/stm/ltdc.c   |   4 +-
 drivers/gpu/drm/sun4i/sun4i_crtc.c   |   4 +-
 drivers/gpu/drm/tegra/dc.c   |   8 +-
 drivers/gpu/drm/tidss/tidss_crtc.c   |   6 +-
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c |   4 +-
 drivers/gpu/drm/vboxvideo/vbox_mode.c|   4 +-
 drivers/gpu/drm/vc4/vc4_crtc.c   |  26 +--
 drivers/gpu/drm/vc4/vc4_drv.h|  14 +-
 drivers/gpu/drm/vc4/vc4_hdmi.c   | 154 +++-
 drivers/gpu/drm/vc4/vc4_hdmi.h   |  12 +-
 drivers/gpu/drm/vc4/vc4_hdmi_regs.h  |   9 +-
 drivers/gpu/drm/vc4/vc4_hvs.c|   8 +-
 drivers/gpu/drm/vc4/vc4_txp.c|   9 +-
 drivers/gpu/drm/virtio/virtgpu_display.c |   4 +-
 drivers/gpu/drm/vkms/vkms_crtc.c |   4 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c  |   4 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |   4 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c |   4 +-
 drivers/gpu/drm/xlnx/zynqmp_disp.c   |   6 +-
 drivers/gpu/drm/zte/zx_vou.c |   4 +-
 include/drm/drm_modeset_helper_vtables.h |  13 +-
 48 files changed, 316 insertions(+), 129 deletions(-)

base-commit: 1a11a88cfd9a97e13be8bc880c4795f9844fbbec
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 3/4] drm/vc4: kms: Don't disable the muxing of an active CRTC

2020-10-09 Thread Maxime Ripard
The current HVS muxing code will consider the CRTCs in a given state to
setup their muxing in the HVS, and disable the other CRTCs muxes.

However, it's valid to only update a single CRTC with a state, and in this
situation we would mux out a CRTC that was enabled but left untouched by
the new state.

Fix this by considering all the CRTCs in the state and the ones with a
state and active.

Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically")
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_kms.c | 23 ---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 3b5e62842901..c9dfd5535a7e 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -185,6 +185,23 @@ static void vc4_hvs_pv_muxing_commit(struct vc4_dev *vc4,
}
 }
 
+static struct drm_crtc_state *
+drm_atomic_get_new_or_current_crtc_state(struct drm_atomic_state *state,
+struct drm_crtc *crtc)
+{
+   struct drm_crtc_state *crtc_state;
+
+   crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+   if (crtc_state)
+   return crtc_state;
+
+   return crtc->state;
+}
+
+#define for_each_new_or_current_crtc_state(__state, crtc, crtc_state)  \
+   list_for_each_entry(crtc, &__state->dev->mode_config.crtc_list, head) \
+   for_each_if(crtc_state = 
drm_atomic_get_new_or_current_crtc_state(__state, crtc))
+
 static void vc5_hvs_pv_muxing_commit(struct vc4_dev *vc4,
 struct drm_atomic_state *state)
 {
@@ -194,16 +211,16 @@ static void vc5_hvs_pv_muxing_commit(struct vc4_dev *vc4,
unsigned char dsp3_mux = 3;
unsigned char dsp4_mux = 3;
unsigned char dsp5_mux = 3;
-   unsigned int i;
u32 reg;
 
-   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
-   struct vc4_crtc_state *vc4_state = 
to_vc4_crtc_state(crtc_state);
+   for_each_new_or_current_crtc_state(state, crtc, crtc_state) {
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
+   struct vc4_crtc_state *vc4_state;
 
if (!crtc_state->active)
continue;
 
+   vc4_state = to_vc4_crtc_state(crtc_state);
switch (vc4_crtc->data->hvs_output) {
case 2:
dsp2_mux = (vc4_state->assigned_channel == 2) ? 0 : 1;
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 4/4] drm/vc4: kms: Fix VBLANK reporting on a disabled CRTC

2020-10-09 Thread Maxime Ripard
If a CRTC is enabled but not active, and that we're then doing a page flip
on another CRTC, drm_atomic_get_crtc_state will bring the first CRTC state
into the global state, and will make us wait for its vblank as well, even
though that might never occur.

Fix this by considering all the enabled CRTCs by either using their new
state in the global state, or using their current state if they aren't part
of the new state being checked, to remove their assigned channel from the
pool before started to assign channels to CRTCs enabled by the state.

Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically")
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_kms.c | 24 +++-
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index c9dfd5535a7e..0751ce5c6467 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -645,6 +645,14 @@ static const struct drm_private_state_funcs 
vc4_load_tracker_state_funcs = {
  *   need to consider all the running CRTCs in the DRM device to assign
  *   a FIFO, not just the one in the state.
  *
+ * - To fix the above, we can't use drm_atomic_get_crtc_state on all
+ *   enabled CRTCs to pull their CRTC state into the global state, since
+ *   a page flip would start considering their vblank to complete. Since
+ *   we don't have a guarantee that they are actually active, that
+ *   vblank might never happen, and shouldn't even be considered if we
+ *   want to do a page flip on a single CRTC. That can be tested by
+ *   doing a modetest -v first on HDMI1 and then on HDMI0.
+ *
  * - Since we need the pixelvalve to be disabled and enabled back when
  *   the FIFO is changed, we should keep the FIFO assigned for as long
  *   as the CRTC is enabled, only considering it free again once that
@@ -656,6 +664,7 @@ static int vc4_pv_muxing_atomic_check(struct drm_device 
*dev,
 {
unsigned long unassigned_channels = GENMASK(NUM_CHANNELS - 1, 0);
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
+   struct drm_crtc_state *crtc_state;
struct drm_crtc *crtc;
unsigned int i;
 
@@ -667,15 +676,14 @@ static int vc4_pv_muxing_atomic_check(struct drm_device 
*dev,
 * the same CRTCs, instead of evaluating only the CRTC being
 * modified.
 */
-   list_for_each_entry(crtc, >mode_config.crtc_list, head) {
-   struct drm_crtc_state *crtc_state;
+   for_each_new_or_current_crtc_state(state, crtc, crtc_state) {
+   struct vc4_crtc_state *vc4_crtc_state;
 
-   if (!crtc->state->enable)
+   if (!crtc_state->enable)
continue;
 
-   crtc_state = drm_atomic_get_crtc_state(state, crtc);
-   if (IS_ERR(crtc_state))
-   return PTR_ERR(crtc_state);
+   vc4_crtc_state = to_vc4_crtc_state(crtc_state);
+   unassigned_channels &= ~BIT(vc4_crtc_state->assigned_channel);
}
 
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
new_crtc_state, i) {
@@ -690,10 +698,8 @@ static int vc4_pv_muxing_atomic_check(struct drm_device 
*dev,
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);
+   if (new_vc4_crtc_state->assigned_channel != 
VC4_HVS_CHANNEL_DISABLED)
continue;
-   }
 
/*
 * The problem we have to solve here is that we have
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 1/6] drm/atomic: Pass the full state to CRTC atomic enable/disable

2020-10-09 Thread Maxime Ripard
If the CRTC driver ever needs to access the full DRM state, it can't do so
at atomic_enable / atomic_disable time since drm_atomic_helper_swap_state
will have cleared the pointer from the struct drm_crtc_state to the struct
drm_atomic_state before calling those hooks.

In order to allow that, let's pass the full DRM state to atomic_enable and
atomic_disable. The conversion was done using the coccinelle script below,
built tested on all the drivers and actually tested on vc4.

virtual report

@@
struct drm_crtc_helper_funcs *FUNCS;
identifier dev, state;
identifier crtc, crtc_state;
@@

 disable_outputs(struct drm_device *dev, struct drm_atomic_state *state)
 {
<...
-   FUNCS->atomic_disable(crtc, crtc_state);
+   FUNCS->atomic_disable(crtc, state);
...>
 }

@@
struct drm_crtc_helper_funcs *FUNCS;
identifier dev, state;
identifier crtc, crtc_state;
@@

 drm_atomic_helper_commit_modeset_enables(struct drm_device *dev, struct 
drm_atomic_state *state)
 {
<...
-   FUNCS->atomic_enable(crtc, crtc_state);
+   FUNCS->atomic_enable(crtc, state);
...>
 }

@@
identifier crtc, old_state;
@@

 struct drm_crtc_helper_funcs {
...
-   void (*atomic_enable)(struct drm_crtc *crtc, struct drm_crtc_state 
*old_state);
+   void (*atomic_enable)(struct drm_crtc *crtc, struct drm_atomic_state 
*state);
...
-   void (*atomic_disable)(struct drm_crtc *crtc, struct drm_crtc_state 
*old_state);
+   void (*atomic_disable)(struct drm_crtc *crtc, struct drm_atomic_state 
*state);
...
}

@ crtc_atomic_func @
identifier helpers;
identifier func;
@@

(
static struct drm_crtc_helper_funcs helpers = {
...,
.atomic_enable = func,
...,
};
|
static struct drm_crtc_helper_funcs helpers = {
...,
.atomic_disable = func,
...,
};
)

@ ignores_old_state @
identifier crtc_atomic_func.func;
identifier crtc, old_state;
@@

void func(struct drm_crtc *crtc,
struct drm_crtc_state *old_state)
{
... when != old_state
}

@ adds_old_state depends on crtc_atomic_func && !ignores_old_state @
identifier crtc_atomic_func.func;
identifier crtc, old_state;
@@

void func(struct drm_crtc *crtc, struct drm_crtc_state *old_state)
{
+   struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state, 
crtc);
...
}

@ depends on crtc_atomic_func @
identifier crtc_atomic_func.func;
expression E;
type T;
@@

void func(...)
{
...
-   T state = E;
+   T crtc_state = E;
<+...
-   state
+   crtc_state
...+>

}

@ depends on crtc_atomic_func @
identifier crtc_atomic_func.func;
type T;
@@

void func(...)
{
...
-   T state;
+   T crtc_state;
<+...
-   state
+   crtc_state
...+>

}

@ depends on crtc_atomic_func @
identifier crtc_atomic_func.func;
identifier old_state;
identifier crtc;
@@

void func(struct drm_crtc *crtc,
-  struct drm_crtc_state *old_state
+  struct drm_atomic_state *state
   )
{ ... }

@ include depends on adds_old_state @
@@

 #include 

@ no_include depends on !include && adds_old_state @
@@

+ #include 
  #include 

Acked-by: Daniel Vetter 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/arc/arcpgu_crtc.c|  4 ++--
 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c |  8 ++--
 drivers/gpu/drm/arm/hdlcd_crtc.c |  4 ++--
 drivers/gpu/drm/arm/malidp_crtc.c|  6 --
 drivers/gpu/drm/armada/armada_crtc.c |  8 ++--
 drivers/gpu/drm/ast/ast_mode.c   |  6 --
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c   |  4 ++--
 drivers/gpu/drm/drm_atomic_helper.c  |  4 ++--
 drivers/gpu/drm/drm_simple_kms_helper.c  |  4 ++--
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |  4 ++--
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c   |  6 --
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c   |  4 ++--
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c  |  4 ++--
 drivers/gpu/drm/imx/dcss/dcss-crtc.c |  9 +++--
 drivers/gpu/drm/imx/ipuv3-crtc.c |  6 --
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c|  4 ++--
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c  |  4 ++--
 drivers/gpu/drm/meson/meson_crtc.c   |  8 
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c |  7 +--
 drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c|  4 ++--
 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c|  4 ++--
 drivers/gpu/drm/mxsfb/mxsfb_kms.c|  4 ++--
 drivers/gpu/drm/omapdrm/omap_crtc.c  |  4 ++--
 drivers/gpu/drm/qxl/qxl_display.c|  4 ++--
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c   |  6 --
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c  |  6 --
 drivers/gpu/drm/sti/sti_crtc.c   |  4 ++--
 d

Re: [PATCH v5 80/80] ARM: dts: bcm2711: Enable the display pipeline

2020-10-07 Thread Maxime Ripard
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

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH RESEND v3 0/6] drm/sun4i: Add support for dual-link LVDS on the A20

2020-10-06 Thread Maxime Ripard
Hi,

This is a second attempt at supporting the LVDS dual-link output on the
Allwinner A20.

Let me know what you think,
Maxime

Changes from v2:
  - Added the DT binding description
  - Split the patch to enable the A20
  - Reworked a bit the error messages

Changes from v1:
  - Reworked the DT bindings
  - Refactored a bit the panel registration in the tcon code.

Maxime Ripard (6):
  drm/of: Change the prototype of drm_of_lvds_get_dual_link_pixel_order
  dt-bindings: display: sun4i: Add LVDS Dual-Link property
  drm/sun4i: tcon: Refactor the LVDS and panel probing
  drm/sun4i: tcon: Support the LVDS Dual-Link
  drm/sun4i: tcon: Enable the A20 dual-link output
  [DO NOT MERGE] ARM: dts: sun7i: Enable LVDS Dual-Link on the Cubieboard

 Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml |   6 
+++-
 arch/arm/boot/dts/sun7i-a20-cubieboard2.dts |  69 
++-
 drivers/gpu/drm/drm_of.c|  98 
+--
 drivers/gpu/drm/rcar-du/rcar_lvds.c |   8 
+---
 drivers/gpu/drm/sun4i/sun4i_tcon.c  | 163 
+---
 drivers/gpu/drm/sun4i/sun4i_tcon.h  |   4 
++-
 include/drm/drm_of.h|  16 
+--
 7 files changed, 236 insertions(+), 128 deletions(-)

base-commit: d113dbba9a18f9ac71edb1a66ae552c9407355f4
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH RESEND v3 6/6] [DO NOT MERGE] ARM: dts: sun7i: Enable LVDS Dual-Link on the Cubieboard

2020-10-06 Thread Maxime Ripard
For the sake of the example, let's enable an LVDS Dual-Link display on a
Cubieboard.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 69 ++-
 1 file changed, 69 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts 
b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
index b8203e4ef21c..20278a27ec16 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
@@ -85,6 +85,49 @@
gpios = < 7 20 GPIO_ACTIVE_HIGH>;
};
};
+
+   panel: panel {
+   compatible = "panel-lvds";
+   width-mm = <153>;
+   height-mm = <90>;
+   data-mapping = "vesa-24";
+
+   panel-timing {
+   clock-frequency = <14850>;
+   hfront-porch = <88>;
+   hactive = <1920>;
+   hback-porch = <148>;
+   hsync-len = <44>;
+
+   vfront-porch = <4>;
+   vactive = <1080>;
+   vback-porch = <36>;
+   vsync-len = <5>;
+   };
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   dual-lvds-even-pixels;
+
+   panel_input_0: endpoint {
+   remote-endpoint = <_out_panel>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   dual-lvds-odd-pixels;
+
+   panel_input_1: endpoint {
+   remote-endpoint = <_out_panel>;
+   };
+   };
+   };
+   };
 };
 
  {
@@ -218,6 +261,32 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_lvds0_pins>;
+   allwinner,lvds-companion = <>;
+   status = "okay";
+};
+
+_out {
+   tcon0_out_panel: endpoint@0 {
+   remote-endpoint = <_input_0>;
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_lvds1_pins>;
+   allwinner,lvds-companion = <>;
+   status = "okay";
+};
+
+_out {
+   tcon1_out_panel: endpoint@0 {
+   remote-endpoint = <_input_1>;
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pb_pins>;
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH RESEND v3 5/6] drm/sun4i: tcon: Enable the A20 dual-link output

2020-10-06 Thread Maxime Ripard
The A20 second TCON (TCON1) can be used as a secondary output to drive a
dual-link LVDS output. Let's add it to our capabilities.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index f497d866e835..de3d1b17a499 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1523,6 +1523,7 @@ static const struct sun4i_tcon_quirks 
sun7i_a20_tcon0_quirks = {
 };
 
 static const struct sun4i_tcon_quirks sun7i_a20_quirks = {
+   .supports_lvds  = true,
.has_channel_0  = true,
.has_channel_1  = true,
.dclk_min_div   = 4,
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH RESEND v3 2/6] dt-bindings: display: sun4i: Add LVDS Dual-Link property

2020-10-06 Thread Maxime Ripard
The Allwinner SoCs with two TCONs and LVDS output can use both to drive an
LVDS dual-link. Add a new property to express that link between these two
TCONs.

Signed-off-by: Maxime Ripard 
---
 Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml | 6 
++
 1 file changed, 6 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml 
b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
index e5344c4ae226..ce407f5466a5 100644
--- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
+++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml
@@ -115,6 +115,12 @@ properties:
 - const: edp
 - const: lvds
 
+  allwinner,lvds-companion:
+$ref: /schemas/types.yaml#/definitions/phandle
+description: >
+  Phandle to the other TCON in the system used to drive a dual-link LVDS
+  output.
+
   ports:
 type: object
 description: |
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH RESEND v3 3/6] drm/sun4i: tcon: Refactor the LVDS and panel probing

2020-10-06 Thread Maxime Ripard
The current code to parse the DT, deal with the older device trees, and
register either the RGB or LVDS output has so far grown organically into
the bind function and has become quite hard to extend properly.

Let's move it into a single function that grabs all the resources it needs
and registers the proper panel output.

Reviewed-by: Chen-Yu Tsai 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 127 +-
 1 file changed, 58 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 2a5a9903c4c6..8a21cf7a6bc1 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -875,6 +875,63 @@ static int sun4i_tcon_init_regmap(struct device *dev,
return 0;
 }
 
+static int sun4i_tcon_register_panel(struct drm_device *drm,
+struct sun4i_tcon *tcon)
+{
+   struct device_node *companion;
+   struct device_node *remote;
+   struct device *dev = tcon->dev;
+   int ret;
+
+   /*
+* If we have an LVDS panel connected to the TCON, we should
+* just probe the LVDS connector. Otherwise, let's just register
+* an RGB panel.
+*/
+   remote = of_graph_get_remote_node(dev->of_node, 1, 0);
+   if (!tcon->quirks->supports_lvds ||
+   !of_device_is_compatible(remote, "panel-lvds"))
+   return sun4i_rgb_init(drm, tcon);
+
+   /*
+* This can only be made optional since we've had DT
+* nodes without the LVDS reset properties.
+*
+* If the property is missing, just disable LVDS, and
+* print a warning.
+*/
+   tcon->lvds_rst = devm_reset_control_get_optional(dev, "lvds");
+   if (IS_ERR(tcon->lvds_rst)) {
+   dev_err(dev, "Couldn't get our reset line\n");
+   return PTR_ERR(tcon->lvds_rst);
+   } else if (!tcon->lvds_rst) {
+   dev_warn(dev, "Missing LVDS reset property, please upgrade your 
DT\n");
+   return -ENODEV;
+   }
+
+   reset_control_reset(tcon->lvds_rst);
+
+   /*
+* This can only be made optional since we've had DT
+* nodes without the LVDS clocks properties.
+*
+* If the property is missing, just disable LVDS, and
+* print a warning.
+*/
+   if (tcon->quirks->has_lvds_alt) {
+   tcon->lvds_pll = devm_clk_get_optional(dev, "lvds-alt");
+   if (IS_ERR(tcon->lvds_pll)) {
+   dev_err(dev, "Couldn't get the LVDS PLL\n");
+   return PTR_ERR(tcon->lvds_pll);
+   } else if (!tcon->lvds_pll) {
+   dev_warn(dev, "Missing LVDS PLL clock, please upgrade 
your DT\n");
+   return -ENODEV;
+   }
+   }
+
+   return sun4i_lvds_init(drm, tcon);
+}
+
 /*
  * On SoCs with the old display pipeline design (Display Engine 1.0),
  * the TCON is always tied to just one backend. Hence we can traverse
@@ -1122,10 +1179,8 @@ static int sun4i_tcon_bind(struct device *dev, struct 
device *master,
struct drm_device *drm = data;
struct sun4i_drv *drv = drm->dev_private;
struct sunxi_engine *engine;
-   struct device_node *remote;
struct sun4i_tcon *tcon;
struct reset_control *edp_rstc;
-   bool has_lvds_rst, has_lvds_alt, can_lvds;
int ret;
 
engine = sun4i_tcon_find_engine(drv, dev->of_node);
@@ -1170,58 +1225,6 @@ static int sun4i_tcon_bind(struct device *dev, struct 
device *master,
return ret;
}
 
-   if (tcon->quirks->supports_lvds) {
-   /*
-* This can only be made optional since we've had DT
-* nodes without the LVDS reset properties.
-*
-* If the property is missing, just disable LVDS, and
-* print a warning.
-*/
-   tcon->lvds_rst = devm_reset_control_get_optional(dev, "lvds");
-   if (IS_ERR(tcon->lvds_rst)) {
-   dev_err(dev, "Couldn't get our reset line\n");
-   return PTR_ERR(tcon->lvds_rst);
-   } else if (tcon->lvds_rst) {
-   has_lvds_rst = true;
-   reset_control_reset(tcon->lvds_rst);
-   } else {
-   has_lvds_rst = false;
-   }
-
-   /*
-* This can only be made optional since we've had DT
-* nodes without the LVDS reset properties.
-*
-* If the property is missing, just disable LVDS, and
-* print a warning.
-*/

Re: [PATCH 1/2] drm/vc4: hdmi: Disable Wifi Frequencies

2020-10-06 Thread Maxime Ripard
Hi Rob,

On Tue, Sep 29, 2020 at 02:00:55PM -0500, Rob Herring wrote:
> On Fri, Sep 25, 2020 at 03:07:43PM +0200, Maxime Ripard wrote:
> > There's cross-talk on the RPi4 between the 2.4GHz channels used by the WiFi
> > chip and some resolutions, most notably 1440p at 60Hz.
> > 
> > In such a case, we can either reject entirely the mode, or lower slightly
> > the pixel frequency to remove the overlap. Let's go for the latter.
> > 
> > Signed-off-by: Maxime Ripard 
> > ---
> >  .../bindings/display/brcm,bcm2711-hdmi.yaml|  6 ++
> >  drivers/gpu/drm/vc4/vc4_hdmi.c | 14 +-
> >  drivers/gpu/drm/vc4/vc4_hdmi.h |  8 
> >  3 files changed, 27 insertions(+), 1 deletion(-)
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml 
> > b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> > index 03a76729d26c..63e7fe999c0a 100644
> > --- a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> > +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> > @@ -76,6 +76,12 @@ properties:
> >resets:
> >  maxItems: 1
> >  
> > +  raspberrypi,disable-wifi-frequencies:
> > +type: boolean
> > +description: >
> > +  Should the pixel frequencies in the WiFi frequencies range be
> > +  avoided?
> 
> Based on googling the issue, perhaps should be a common property?

This is a fairly generic issue indeed, but went for the most
non-intrusive way. Do you have a better idea of a generic name, or do
you just want me to drop the vendor prefix?

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2 2/4] drm/sun4i: tcon: Refactor the LVDS and panel probing

2020-10-06 Thread Maxime Ripard
Hi Chen-Yu,

Sorry for the delay

On Sat, Aug 29, 2020 at 02:43:53PM +0800, Chen-Yu Tsai wrote:
> > +static int sun4i_tcon_register_panel(struct drm_device *drm,
> > +struct sun4i_tcon *tcon)
> > +{
> > +   struct device_node *companion;
> > +   struct device_node *remote;
> > +   struct device *dev = tcon->dev;
> > +   bool has_lvds_alt;
> > +   bool has_lvds_rst;
> > +   int ret;
> > +
> > +   /*
> > +* If we have an LVDS panel connected to the TCON, we should
> > +* just probe the LVDS connector. Otherwise, let's just register
> > +* an RGB panel.
> > +*/
> > +   remote = of_graph_get_remote_node(dev->of_node, 1, 0);
> > +   if (!tcon->quirks->supports_lvds ||
> > +   !of_device_is_compatible(remote, "panel-lvds"))
> > +   return sun4i_rgb_init(drm, tcon);
> 
> Slightly related: IIRC there are a few LVDS panels supported in panel-simple
> so they don't use the panel-lvds compatible. Any idea how to deal with those?

I agree that this is an issue, I'm not entirely sure how to fix it. The
proper fix would be to have multiple output ports, one for each output
type, but given how our current binding looks like I'm not sure how we
could retro-fit that without some horror-looking code.

Maybe we can add a property on the endpoint?

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] dt-bindings: display: Add dsi-controller.yaml in DSI controller schemas

2020-10-06 Thread Maxime Ripard
On Fri, Oct 02, 2020 at 05:59:24PM -0500, Rob Herring wrote:
> Some DSI controllers are missing a reference to the recently added
> dsi-controller.yaml schema. Add it and we can drop the duplicate parts.
> 
> Cc: Maxime Ripard 

Acked-by: Maxime Ripard 

Thanks!
Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH RESEND v3 1/6] drm/of: Change the prototype of drm_of_lvds_get_dual_link_pixel_order

2020-10-06 Thread Maxime Ripard
The drm_of_lvds_get_dual_link_pixel_order() function took so far the
device_node of the two ports used together to make up a dual-link LVDS
output.

This assumes that a binding would use an entire port for the LVDS output.
However, some bindings have used endpoints instead and thus we need to
operate at the endpoint level. Change slightly the arguments to allow that.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_of.c| 98 +++---
 drivers/gpu/drm/rcar-du/rcar_lvds.c |  8 +--
 include/drm/drm_of.h| 16 +++--
 3 files changed, 63 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index b50b44e76279..2dcb49b0401b 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -291,50 +291,34 @@ static int drm_of_lvds_get_port_pixels_type(struct 
device_node *port_node)
   (odd_pixels ? DRM_OF_LVDS_ODD : 0);
 }
 
-static int drm_of_lvds_get_remote_pixels_type(
-   const struct device_node *port_node)
+static int drm_of_lvds_get_remote_pixels_type(const struct device_node 
*endpoint)
 {
-   struct device_node *endpoint = NULL;
-   int pixels_type = -EPIPE;
+   struct device_node *remote_port;
+   int pixels_type;
 
-   for_each_child_of_node(port_node, endpoint) {
-   struct device_node *remote_port;
-   int current_pt;
-
-   if (!of_node_name_eq(endpoint, "endpoint"))
-   continue;
-
-   remote_port = of_graph_get_remote_port(endpoint);
-   if (!remote_port) {
-   of_node_put(remote_port);
-   return -EPIPE;
-   }
-
-   current_pt = drm_of_lvds_get_port_pixels_type(remote_port);
+   remote_port = of_graph_get_remote_port(endpoint);
+   if (!remote_port) {
of_node_put(remote_port);
-   if (pixels_type < 0)
-   pixels_type = current_pt;
-
-   /*
-* Sanity check, ensure that all remote endpoints have the same
-* pixel type. We may lift this restriction later if we need to
-* support multiple sinks with different dual-link
-* configurations by passing the endpoints explicitly to
-* drm_of_lvds_get_dual_link_pixel_order().
-*/
-   if (!current_pt || pixels_type != current_pt) {
-   of_node_put(remote_port);
-   return -EINVAL;
-   }
+   return -EPIPE;
}
 
+   pixels_type = drm_of_lvds_get_port_pixels_type(remote_port);
+   of_node_put(remote_port);
+
+   if (pixels_type < 0)
+   pixels_type = -EPIPE;
+
return pixels_type;
 }
 
 /**
  * drm_of_lvds_get_dual_link_pixel_order - Get LVDS dual-link pixel order
- * @port1: First DT port node of the Dual-link LVDS source
- * @port2: Second DT port node of the Dual-link LVDS source
+ * @dev1: First DT device node of the Dual-Link LVDS source
+ * @port1_id: ID of the first DT port node of the Dual-Link LVDS source
+ * @endpoint1_id: ID of the first DT port node of the Dual-Link LVDS source
+ * @dev2: First DT device node of the Dual-Link LVDS source
+ * @port2_id: ID of the first DT port node of the Dual-Link LVDS source
+ * @endpoint2_id: ID of the first DT port node of the Dual-Link LVDS source
  *
  * An LVDS dual-link connection is made of two links, with even pixels
  * transitting on one link, and odd pixels on the other link. This function
@@ -348,32 +332,48 @@ static int drm_of_lvds_get_remote_pixels_type(
  *
  * If either port is not connected, this function returns -EPIPE.
  *
- * @port1 and @port2 are typically DT sibling nodes, but may have different
- * parents when, for instance, two separate LVDS encoders carry the even and 
odd
- * pixels.
+ * @port1_id and @port2_id are typically DT sibling nodes, but may have
+ * different parents when, for instance, two separate LVDS encoders carry the
+ * even and odd pixels.
+ *
+ * If @port1_id, @port2_id, @endpoint1_id or @endpoint2_id are set to -1, their
+ * value is going to be ignored.
  *
  * Return:
- * * DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS - @port1 carries even pixels and @port2
- *   carries odd pixels
- * * DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS - @port1 carries odd pixels and @port2
- *   carries even pixels
- * * -EINVAL - @port1 and @port2 are not connected to a dual-link LVDS sink, or
- *   the sink configuration is invalid
- * * -EPIPE - when @port1 or @port2 are not connected
+ * * DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS - @endpoint1_id carries even pixels and
+ *   @endpoint2_id carries odd pixels
+ * * DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS - @endpoint1_id carries odd pixels and
+ *   @endpoint2_id carries even pixels
+ * * -EINVAL - @endpoint1_id and @endpoint2_id are not connected to a dual-link
+ *   LVDS s

[PATCH RESEND v3 4/6] drm/sun4i: tcon: Support the LVDS Dual-Link

2020-10-06 Thread Maxime Ripard
The A20 and other SoC with two TCONs (A31, R40, etc.) can use its second
TCON as the secondary LVDS link in a dual-link setup, with the TCON0 being
the main link. Extend a bit the parsing code to leverage the DRM dual-link
code, register only the LVDS output on the primary TCON, and add the needed
bits to setup the TCON properly.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 35 +++-
 drivers/gpu/drm/sun4i/sun4i_tcon.h |  4 -
 2 files changed, 39 insertions(+)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 8a21cf7a6bc1..f497d866e835 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -487,6 +487,9 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon 
*tcon,
else
reg |= SUN4I_TCON0_LVDS_IF_DATA_POL_NORMAL;
 
+   if (tcon->lvds_dual_link)
+   reg |= SUN4I_TCON0_LVDS_IF_DUAL_LINK;
+
if (sun4i_tcon_get_pixel_depth(encoder) == 24)
reg |= SUN4I_TCON0_LVDS_IF_BITWIDTH_24BITS;
else
@@ -894,6 +897,16 @@ static int sun4i_tcon_register_panel(struct drm_device 
*drm,
return sun4i_rgb_init(drm, tcon);
 
/*
+* Only the TCON0 will be relevant for the LVDS output, so if
+* our ID is something else, let's prevent our TCON from
+* registering its own LVDS output
+*/
+   if (tcon->id) {
+   dev_dbg(dev, "TCON used as an LVDS secondary link.");
+   return 0;
+   }
+
+   /*
 * This can only be made optional since we've had DT
 * nodes without the LVDS reset properties.
 *
@@ -929,6 +942,28 @@ static int sun4i_tcon_register_panel(struct drm_device 
*drm,
}
}
 
+   /*
+* If we don't have a second TCON, we will never be able to do
+* dual-link LVDS, so we don't have much more to do.
+*/
+   companion = of_parse_phandle(dev->of_node, "allwinner,lvds-companion", 
0);
+   if (!companion)
+   return sun4i_lvds_init(drm, tcon);
+
+   /*
+* Let's do a sanity check on the dual-link setup to make sure
+* everything is properly described.
+*/
+   ret = drm_of_lvds_get_dual_link_pixel_order(dev->of_node, 1, 0,
+   companion, 1, 0);
+   if (ret < 0) {
+   dev_err(dev, "Invalid Dual-Link Configuration.\n");
+   return ret;
+   }
+
+   dev_info(dev, "Primary TCON, enabling LVDS Dual-Link");
+   tcon->lvds_dual_link = true;
+
return sun4i_lvds_init(drm, tcon);
 }
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h 
b/drivers/gpu/drm/sun4i/sun4i_tcon.h
index cfbf4e6c1679..51c4e09cdd13 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
@@ -98,6 +98,7 @@
 
 #define SUN4I_TCON0_LVDS_IF_REG0x84
 #define SUN4I_TCON0_LVDS_IF_EN BIT(31)
+#define SUN4I_TCON0_LVDS_IF_DUAL_LINK  BIT(30)
 #define SUN4I_TCON0_LVDS_IF_BITWIDTH_MASK  BIT(26)
 #define SUN4I_TCON0_LVDS_IF_BITWIDTH_18BITS(1 << 26)
 #define SUN4I_TCON0_LVDS_IF_BITWIDTH_24BITS(0 << 26)
@@ -274,6 +275,9 @@ struct sun4i_tcon {
/* Associated crtc */
struct sun4i_crtc   *crtc;
 
+   /* Is the LVDS link a dual-channel link? */
+   boollvds_dual_link;
+
int id;
 
/* TCON list management */
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v3 0/6] drm/sun4i: Add support for dual-link LVDS on the A20

2020-10-06 Thread Maxime Ripard
Hi,

This is a second attempt at supporting the LVDS dual-link output on the
Allwinner A20.

Let me know what you think,
Maxime

Changes from v2:
  - Added the DT binding description
  - Split the patch to enable the A20
  - Reworked a bit the error messages

Changes from v1:
  - Reworked the DT bindings
  - Refactored a bit the panel registration in the tcon code.

Maxime Ripard (6):
  drm/of: Change the prototype of drm_of_lvds_get_dual_link_pixel_order
  dt-bindings: display: sun4i: Add LVDS Dual-Link property
  drm/sun4i: tcon: Refactor the LVDS and panel probing
  drm/sun4i: tcon: Support the LVDS Dual-Link
  drm/sun4i: tcon: Enable the A20 dual-link output
  [DO NOT MERGE] ARM: dts: sun7i: Enable LVDS Dual-Link on the Cubieboard

 Documentation/devicetree/bindings/display/allwinner,sun4i-a10-tcon.yaml |   6 
+++-
 arch/arm/boot/dts/sun7i-a20-cubieboard2.dts |  69 
++-
 drivers/gpu/drm/drm_of.c|  98 
+--
 drivers/gpu/drm/rcar-du/rcar_lvds.c |   8 
+---
 drivers/gpu/drm/sun4i/sun4i_tcon.c  | 163 
+---
 drivers/gpu/drm/sun4i/sun4i_tcon.h  |   4 
++-
 include/drm/drm_of.h|  16 
+--
 7 files changed, 236 insertions(+), 128 deletions(-)

base-commit: d113dbba9a18f9ac71edb1a66ae552c9407355f4
-- 
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 80/80] ARM: dts: bcm2711: Enable the display pipeline

2020-10-03 Thread Maxime Ripard
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)

Thanks!
Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/atomic: Make the kerneldoc a bit clearer

2020-10-03 Thread Maxime Ripard
Hi,

On Fri, Oct 02, 2020 at 09:56:20AM +0200, Daniel Vetter wrote:
> Crank up the warning a notch and point at the right set of locking
> functions for atomic drivers.
> 
> Signed-off-by: Daniel Vetter 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_atomic.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index aac9122f1da2..b2d20eb6c807 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1642,11 +1642,11 @@ static void __drm_state_dump(struct drm_device *dev, 
> struct drm_printer *p,
>   * to dmesg in case of error irq's.  (Hint, you probably want to
>   * ratelimit this!)
>   *
> - * The caller must drm_modeset_lock_all(), or if this is called
> - * from error irq handler, it should not be enabled by default.
> - * (Ie. if you are debugging errors you might not care that this
> - * is racey.  But calling this without all modeset locks held is
> - * not inherently safe.)
> + * The caller must wrap this drm_modeset_lock_all_ctx() and
> + * drm_modeset_drop_locks(). If this is called from error irq handler, it 
> should
> + * not be enabled by default - if you are debugging errors you might
> + * not care that this is racey, but calling this without all modeset locks 
> held
> + * is inherently unsafe.
>   */
>  void drm_state_dump(struct drm_device *dev, struct drm_printer *p)
>  {

For the comment itself:
Acked-by: Maxime Ripard 

But maybe we should add some lockdep assertion to make sure we can catch
someone actually doing this?


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/atomic: Make the kerneldoc a bit clearer

2020-10-03 Thread Maxime Ripard
On Fri, Oct 02, 2020 at 02:37:25PM +0200, Daniel Vetter wrote:
> On Fri, Oct 2, 2020 at 2:31 PM Maxime Ripard  wrote:
> > On Fri, Oct 02, 2020 at 09:56:20AM +0200, Daniel Vetter wrote:
> > > Crank up the warning a notch and point at the right set of locking
> > > functions for atomic drivers.
> > >
> > > Signed-off-by: Daniel Vetter 
> > > Cc: Maarten Lankhorst 
> > > Cc: Maxime Ripard 
> > > Cc: Thomas Zimmermann 
> > > Cc: David Airlie 
> > > Cc: Daniel Vetter 
> > > ---
> > >  drivers/gpu/drm/drm_atomic.c | 10 +-
> > >  1 file changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > index aac9122f1da2..b2d20eb6c807 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -1642,11 +1642,11 @@ static void __drm_state_dump(struct drm_device 
> > > *dev, struct drm_printer *p,
> > >   * to dmesg in case of error irq's.  (Hint, you probably want to
> > >   * ratelimit this!)
> > >   *
> > > - * The caller must drm_modeset_lock_all(), or if this is called
> > > - * from error irq handler, it should not be enabled by default.
> > > - * (Ie. if you are debugging errors you might not care that this
> > > - * is racey.  But calling this without all modeset locks held is
> > > - * not inherently safe.)
> > > + * The caller must wrap this drm_modeset_lock_all_ctx() and
> > > + * drm_modeset_drop_locks(). If this is called from error irq handler, 
> > > it should
> > > + * not be enabled by default - if you are debugging errors you might
> > > + * not care that this is racey, but calling this without all modeset 
> > > locks held
> > > + * is inherently unsafe.
> > >   */
> > >  void drm_state_dump(struct drm_device *dev, struct drm_printer *p)
> > >  {
> >
> > For the comment itself:
> > Acked-by: Maxime Ripard 
> 
> Thanks for taking a look, will merge.
> 
> > But maybe we should add some lockdep assertion to make sure we can catch
> > someone actually doing this?
> 
> I think it has some use for ad-hoc debugging in random places, or
> maybe as a an opt-in "tains your kernel" debug option. And then you
> really don't want your useful debug output burried in a few pages of
> lockdep splat first :-)

Yeah, but at the same time reducing the discoverability of this locking
expectation for the common case to favor some one-off debugging by
someone that has more chance to know better seems like not the best
trade-off.

Or maybe make the assertion conditional on drm.debug not being set or
something?

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PULL] drm-misc-next-fixes

2020-10-02 Thread Maxime Ripard
Hi Daniel, Dave,

Here's a few fixes for the next merge window

Thanks!
Maxime

drm-misc-next-fixes-2020-10-02:
Three fixes for vc4 that addresses dual-display breakages
The following changes since commit 089d83418914abd4d908db117d9a3eca7f51a68c:

  drm/vc4: hvs: Pull the state of all the CRTCs prior to PV muxing (2020-09-21 
16:43:11 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2020-10-02

for you to fetch changes up to 8ba0b6d196315f68c271f549e8585129caefce97:

  drm/vc4: crtc: Keep the previously assigned HVS FIFO (2020-09-25 16:56:21 
+0200)


Three fixes for vc4 that addresses dual-display breakages


Maxime Ripard (3):
  drm/vc4: kms: Assign a FIFO to enabled CRTCs instead of active
  drm/vc4: crtc: Rework a bit the CRTC state code
  drm/vc4: crtc: Keep the previously assigned HVS FIFO

 drivers/gpu/drm/vc4/vc4_crtc.c | 14 +++---
 drivers/gpu/drm/vc4/vc4_drv.h  |  2 ++
 drivers/gpu/drm/vc4/vc4_kms.c  | 22 --
 3 files changed, 29 insertions(+), 9 deletions(-)


signature.asc
Description: PGP signature
___
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

2020-10-02 Thread Maxime Ripard
On Thu, Oct 01, 2020 at 08:48:43AM +0200, Maxime Ripard wrote:
> Hi Stefan,
> 
> On Wed, Sep 30, 2020 at 06:52:13PM +0200, Stefan Wahren wrote:
> > Am 30.09.20 um 18:38 schrieb Nathan Chancellor:
> > > On Wed, Sep 30, 2020 at 04:07:58PM +0200, Maxime Ripard wrote:
> > >> Hi Nathan,
> > >>
> > >> On Tue, Sep 29, 2020 at 03:15:26PM -0700, Nathan Chancellor wrote:
> > >>> On Thu, Sep 03, 2020 at 10:01:52AM +0200, Maxime Ripard wrote:
> > >>>> Now that all the drivers have been adjusted for it, let's bring in the
> > >>>> necessary device tree changes.
> > >>>>
> > >>>> The VEC and PV3 are left out for now, since it will require a more 
> > >>>> specific
> > >>>> clock setup.
> > >>>>
> > >>>> Reviewed-by: Dave Stevenson 
> > >>>> Tested-by: Chanwoo Choi 
> > >>>> Tested-by: Hoegeun Kwon 
> > >>>> Tested-by: Stefan Wahren 
> > >>>> Signed-off-by: Maxime Ripard 
> > >>> Apologies if this has already been reported or have a solution but this
> > >>> patch (and presumably series) breaks output to the serial console after
> > >>> a certain point during init. On Raspbian, I see systemd startup messages
> > >>> then the output just turns into complete garbage. It looks like this
> > >>> patch is merged first in linux-next, which is why my bisect fell on the
> > >>> DRM merge. I am happy to provide whatever information could be helpful
> > >>> for debugging this. I am on the latest version of the firmware
> > >>> (currently 26620cc9a63c6cb9965374d509479b4ee2c30241).
> > >> Unfortunately, the miniUART is in the same clock tree than the core
> > >> clock and will thus have those kind of issues when the core clock is
> > >> changed (which is also something that one should expect when using the
> > >> DRM or other drivers).
> > >>
> > >> The only real workaround there would be to switch to one of the PL011
> > >> UARTs. I guess we can also somehow make the UART react to the core clock
> > >> frequency changes, but that's going to require some effort
> > >>
> > >> Maxime
> > > Ack, thank you for the reply! There does not really seem to be a whole
> > > ton of documentation around using one of the other PL011 UARTs so for
> > > now, I will just revert this commit locally.
> > 
> > there was a patch series & discussion about this topic, but we finally
> > didn't find a rock solid solution.
> > 
> > You can have a look at "[RFC 5/5] serial: 8250: bcm2835aux: add notifier
> > to follow clock changes" from 3.4.2019 on linux-rpi-kernel.
> 
> I couldn't find that discussion on the archive, but based on the title I
> guess there's some patches that have been merged this cycle for the 8250
> driver to do just that (868f3ee6e452 ("serial: 8250: Add 8250 port clock
> update method") and cc816969d7b5 ("serial: 8250_dw: Fix common clocks
> usage race condition")).
> 
> However, I'm not entirely sure the clock notifier works in our case with
> the firmware / MMIO clocks duality

I was a bit intrigued by this, so I looked into it, and it seems that
it's worth that it used to be. The core clock is supposed to be running
at 500 Mhz in most cases, and that's what we're setting so it shouldn't
cause any pratical issue.

However, it looks like on my board now the firmware reports that the
core clock is running at either 311MHz or 233MHz with hdmi_enable_4k60
(which seems odd?) and that contradicts the documentation here:
https://www.raspberrypi.org/documentation/configuration/config-txt/overclocking.md

Linux then comes in, changes the frequency to 500MHz and breaks the
UART. So either the doc is wrong, or the clock driver is.

vcgencmd measure_clock core reports that it's indeed 233Mhz and I'm
running a year-old firmware (built on the 2019-11-29), so I'd be
inclined to think that the doc is wrong here or we're misinterpreting
something.

Dave, Tim, any idea?

Thanks!
Maxime


signature.asc
Description: PGP signature
___
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

2020-10-02 Thread Maxime Ripard
On Thu, Sep 24, 2020 at 05:08:56PM +0900, Hoegeun Kwon wrote:
> Hi Maxime,
> 
> On 9/18/20 11:59 PM, 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.
> 
> Thanks for the patch.
> 
> There is a problem when doing page flip.
> After connecting 2 HDMIs without hotplug and booting.(Same thing when
> using hotplug.)
> 
> When executing page flip for each of HDMI 0 and 1 in modetest
> operation does not work normally. (crtc irq does not occur, so timeout 
> occurs.)
> Sometimes both hdmi 0 or 1 work or not.
> 
> LOGs:
> root:~> modetest -Mvc4 -s 32:1280x720 -v
> setting mode 1280x720-60Hz@XR24 on connectors 32, crtc 64
> failed to set gamma: Invalid argument
> freq: 60.24Hz
> freq: 60.00Hz
> 
> root:~> modetest -Mvc4 -s 38:1280x720 -v
> setting mode 1280x720-60Hz@XR24 on connectors 38, crtc 69
> failed to set gamma: Invalid argument
> select timed out or error (ret 0)
> select timed out or error (ret 0)
> 
> Could you please check it?

So I can reproduce that bug, but I've not been able to fix it yet.

The issue seems to happen 100% of the time when you start first with the
second connector, and then the first. It creates yet another muxing
corner case, which is that when the first modeset runs, there's only one
enabled CRTC (with the 69 here) that gets assigned the channel 0 (since
it's the only one and it can run from that channel). However, when
modeset exits, it doesn't disable that CRTC for some reason.

Then you enable a second CRTC (64) with the second modeset command, but
it has a lower index so it gets evaluated first and gets assigned the
channel 0 as well since we haven't removed the CRTC 69 from the pool
yet.

I've fixed that up by first removing the channels in current use, and
then allocating them in two separate passes, but it doesn't address the
problem entirely, so I'll keep looking.

Maxime


signature.asc
Description: PGP signature
___
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

2020-10-02 Thread Maxime Ripard
On Thu, Oct 01, 2020 at 11:22:03AM +0200, Nicolas Saenz Julienne wrote:
> On Wed, 2020-09-30 at 09:38 -0700, Nathan Chancellor wrote:
> > On Wed, Sep 30, 2020 at 04:07:58PM +0200, Maxime Ripard wrote:
> > > Hi Nathan,
> > > 
> > > On Tue, Sep 29, 2020 at 03:15:26PM -0700, Nathan Chancellor wrote:
> > > > On Thu, Sep 03, 2020 at 10:01:52AM +0200, Maxime Ripard wrote:
> > > > > Now that all the drivers have been adjusted for it, let's bring in the
> > > > > necessary device tree changes.
> > > > > 
> > > > > The VEC and PV3 are left out for now, since it will require a more 
> > > > > specific
> > > > > clock setup.
> > > > > 
> > > > > Reviewed-by: Dave Stevenson 
> > > > > Tested-by: Chanwoo Choi 
> > > > > Tested-by: Hoegeun Kwon 
> > > > > Tested-by: Stefan Wahren 
> > > > > Signed-off-by: Maxime Ripard 
> > > > 
> > > > Apologies if this has already been reported or have a solution but this
> > > > patch (and presumably series) breaks output to the serial console after
> > > > a certain point during init. On Raspbian, I see systemd startup messages
> > > > then the output just turns into complete garbage. It looks like this
> > > > patch is merged first in linux-next, which is why my bisect fell on the
> > > > DRM merge. I am happy to provide whatever information could be helpful
> > > > for debugging this. I am on the latest version of the firmware
> > > > (currently 26620cc9a63c6cb9965374d509479b4ee2c30241).
> > > 
> > > Unfortunately, the miniUART is in the same clock tree than the core
> > > clock and will thus have those kind of issues when the core clock is
> > > changed (which is also something that one should expect when using the
> > > DRM or other drivers).
> > > 
> > > The only real workaround there would be to switch to one of the PL011
> > > UARTs. I guess we can also somehow make the UART react to the core clock
> > > frequency changes, but that's going to require some effort
> > > 
> > > Maxime
> > 
> > Ack, thank you for the reply! There does not really seem to be a whole
> > ton of documentation around using one of the other PL011 UARTs so for
> > now, I will just revert this commit locally.
> 
> Nathan, a less intrusive solution would be to add 'core_freq_min=500' into 
> your
> config.txt.
> 
> Funnily enough core_freq=500 doesn't seem to work in that regard. It might be
> related with what Maxime is commenting.

Yeah, it fixes it here too

Maxime


signature.asc
Description: PGP signature
___
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

2020-10-01 Thread Maxime Ripard
On Thu, Sep 24, 2020 at 05:08:56PM +0900, Hoegeun Kwon wrote:
> Hi Maxime,
> 
> On 9/18/20 11:59 PM, 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.
> 
> Thanks for the patch.
> 
> There is a problem when doing page flip.
> After connecting 2 HDMIs without hotplug and booting.(Same thing when
> using hotplug.)
> 
> When executing page flip for each of HDMI 0 and 1 in modetest
> operation does not work normally. (crtc irq does not occur, so timeout 
> occurs.)
> Sometimes both hdmi 0 or 1 work or not.
> 
> LOGs:
> root:~> modetest -Mvc4 -s 32:1280x720 -v
> setting mode 1280x720-60Hz@XR24 on connectors 32, crtc 64
> failed to set gamma: Invalid argument
> freq: 60.24Hz
> freq: 60.00Hz
> 
> root:~> modetest -Mvc4 -s 38:1280x720 -v
> setting mode 1280x720-60Hz@XR24 on connectors 38, crtc 69
> failed to set gamma: Invalid argument
> select timed out or error (ret 0)
> select timed out or error (ret 0)
> 
> Could you please check it?

I'll look into it, thanks :)

Maxime


signature.asc
Description: PGP signature
___
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

2020-10-01 Thread Maxime Ripard
Hi Stefan,

On Wed, Sep 30, 2020 at 06:52:13PM +0200, Stefan Wahren wrote:
> Am 30.09.20 um 18:38 schrieb Nathan Chancellor:
> > On Wed, Sep 30, 2020 at 04:07:58PM +0200, Maxime Ripard wrote:
> >> Hi Nathan,
> >>
> >> On Tue, Sep 29, 2020 at 03:15:26PM -0700, Nathan Chancellor wrote:
> >>> On Thu, Sep 03, 2020 at 10:01:52AM +0200, Maxime Ripard wrote:
> >>>> Now that all the drivers have been adjusted for it, let's bring in the
> >>>> necessary device tree changes.
> >>>>
> >>>> The VEC and PV3 are left out for now, since it will require a more 
> >>>> specific
> >>>> clock setup.
> >>>>
> >>>> Reviewed-by: Dave Stevenson 
> >>>> Tested-by: Chanwoo Choi 
> >>>> Tested-by: Hoegeun Kwon 
> >>>> Tested-by: Stefan Wahren 
> >>>> Signed-off-by: Maxime Ripard 
> >>> Apologies if this has already been reported or have a solution but this
> >>> patch (and presumably series) breaks output to the serial console after
> >>> a certain point during init. On Raspbian, I see systemd startup messages
> >>> then the output just turns into complete garbage. It looks like this
> >>> patch is merged first in linux-next, which is why my bisect fell on the
> >>> DRM merge. I am happy to provide whatever information could be helpful
> >>> for debugging this. I am on the latest version of the firmware
> >>> (currently 26620cc9a63c6cb9965374d509479b4ee2c30241).
> >> Unfortunately, the miniUART is in the same clock tree than the core
> >> clock and will thus have those kind of issues when the core clock is
> >> changed (which is also something that one should expect when using the
> >> DRM or other drivers).
> >>
> >> The only real workaround there would be to switch to one of the PL011
> >> UARTs. I guess we can also somehow make the UART react to the core clock
> >> frequency changes, but that's going to require some effort
> >>
> >> Maxime
> > Ack, thank you for the reply! There does not really seem to be a whole
> > ton of documentation around using one of the other PL011 UARTs so for
> > now, I will just revert this commit locally.
> 
> there was a patch series & discussion about this topic, but we finally
> didn't find a rock solid solution.
> 
> You can have a look at "[RFC 5/5] serial: 8250: bcm2835aux: add notifier
> to follow clock changes" from 3.4.2019 on linux-rpi-kernel.

I couldn't find that discussion on the archive, but based on the title I
guess there's some patches that have been merged this cycle for the 8250
driver to do just that (868f3ee6e452 ("serial: 8250: Add 8250 port clock
update method") and cc816969d7b5 ("serial: 8250_dw: Fix common clocks
usage race condition")).

However, I'm not entirely sure the clock notifier works in our case with
the firmware / MMIO clocks duality

Maxime
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/2] drm/vc4: hdmi: Disable Wifi Frequencies

2020-10-01 Thread Maxime Ripard
Hi Daniel,

On Mon, Sep 28, 2020 at 11:02:11AM +0200, Daniel Vetter wrote:
> On Mon, Sep 28, 2020 at 9:06 AM Maxime Ripard  wrote:
> >
> > There's cross-talk on the RPi4 between the 2.4GHz channels used by the WiFi
> > chip and some resolutions, most notably 1440p at 60Hz.
> >
> > In such a case, we can either reject entirely the mode, or lower slightly
> > the pixel frequency to remove the overlap. Let's go for the latter.
> >
> > Signed-off-by: Maxime Ripard 
> > ---
> >  .../bindings/display/brcm,bcm2711-hdmi.yaml|  6 ++
> >  drivers/gpu/drm/vc4/vc4_hdmi.c | 14 +-
> >  drivers/gpu/drm/vc4/vc4_hdmi.h |  8 
> >  3 files changed, 27 insertions(+), 1 deletion(-)
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml 
> > b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> > index 03a76729d26c..63e7fe999c0a 100644
> > --- a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> > +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> > @@ -76,6 +76,12 @@ properties:
> >resets:
> >  maxItems: 1
> >
> > +  raspberrypi,disable-wifi-frequencies:
> > +type: boolean
> > +description: >
> > +  Should the pixel frequencies in the WiFi frequencies range be
> > +  avoided?
> > +
> >  required:
> >- compatible
> >- reg
> > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > index acfb4e235214..74da7c00ecd0 100644
> > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > @@ -877,13 +877,22 @@ static int vc4_hdmi_encoder_atomic_check(struct 
> > drm_encoder *encoder,
> > 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;
> > +   unsigned long long pixel_rate;
> >
> > if (vc4_hdmi->variant->broken_odd_h_timings &&
> > ((mode->hdisplay % 2) || (mode->hsync_start % 2) ||
> >  (mode->hsync_end % 2) || (mode->htotal % 2)))
> > return -EINVAL;
> >
> > +   /*
> > +* The 1440p@60 pixel rate is in the same range than the WiFi
> > +* channels. Slightly lower the frequency to bring it out of the
> > +* WiFi range.
> > +*/
> > +   if (vc4_hdmi->disable_wifi_frequencies && mode->clock == 241500)
> > +   mode->clock = 238560;
> 
> Don't you want to map for a (narrow) range of frequencies here? Just
> for that infamous 60p vs 59.99p thing and similar. And I think that
> would still be in that band you want to avoid.

Testing for a range seems better indeed, I'll send a new version

Thanks!
Maxime


signature.asc
Description: PGP signature
___
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

2020-10-01 Thread Maxime Ripard
Hi Nathan,

On Tue, Sep 29, 2020 at 03:15:26PM -0700, Nathan Chancellor wrote:
> On Thu, Sep 03, 2020 at 10:01:52AM +0200, Maxime Ripard wrote:
> > Now that all the drivers have been adjusted for it, let's bring in the
> > necessary device tree changes.
> > 
> > The VEC and PV3 are left out for now, since it will require a more specific
> > clock setup.
> > 
> > Reviewed-by: Dave Stevenson 
> > Tested-by: Chanwoo Choi 
> > Tested-by: Hoegeun Kwon 
> > Tested-by: Stefan Wahren 
> > Signed-off-by: Maxime Ripard 
> 
> Apologies if this has already been reported or have a solution but this
> patch (and presumably series) breaks output to the serial console after
> a certain point during init. On Raspbian, I see systemd startup messages
> then the output just turns into complete garbage. It looks like this
> patch is merged first in linux-next, which is why my bisect fell on the
> DRM merge. I am happy to provide whatever information could be helpful
> for debugging this. I am on the latest version of the firmware
> (currently 26620cc9a63c6cb9965374d509479b4ee2c30241).

Unfortunately, the miniUART is in the same clock tree than the core
clock and will thus have those kind of issues when the core clock is
changed (which is also something that one should expect when using the
DRM or other drivers).

The only real workaround there would be to switch to one of the PL011
UARTs. I guess we can also somehow make the UART react to the core clock
frequency changes, but that's going to require some effort

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH RFC v7 1/6] dt-bindings: display: add Unisoc's drm master bindings

2020-09-29 Thread Maxime Ripard
Hi!

On Mon, Sep 28, 2020 at 02:27:35PM +0800, Kevin Tang wrote:
> From: Kevin Tang 
> 
> The Unisoc DRM master device is a virtual device needed to list all
> DPU devices or other display interface nodes that comprise the
> graphics subsystem
> 
> RFC v7:
>   - Fix DTC unit name warnings
>   - Fix the problem of maintainers
> 
> Cc: Orson Zhai 
> Cc: Chunyan Zhang 
> Signed-off-by: Kevin Tang 
> ---
>  .../display/sprd/sprd,display-subsystem.yaml   | 39 
> ++
>  1 file changed, 39 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml 
> b/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml
> new file mode 100644
> index 000..9487a39
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml
> @@ -0,0 +1,39 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/sprd/sprd,display-subsystem.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Unisoc DRM master device
> +
> +maintainers:
> +  - Kevin Tang 
> +
> +description: |
> +  The Unisoc DRM master device is a virtual device needed to list all
> +  DPU devices or other display interface nodes that comprise the
> +  graphics subsystem.
> +
> +properties:
> +  compatible:
> +const: sprd,display-subsystem
> +
> +  ports:
> +$ref: /schemas/types.yaml#/definitions/phandle-array
> +description:
> +  Should contain a list of phandles pointing to display interface port
> +  of DPU devices.

Generally speaking, driver-specific properties should be prefixed by the
vendor name to avoid any conflict with generic properties (like the
OF-Graph ports subnode in this case)

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH RFC v7 5/6] dt-bindings: display: add Unisoc's mipi dsi bindings

2020-09-29 Thread Maxime Ripard
Hi!

On Mon, Sep 28, 2020 at 02:27:39PM +0800, Kevin Tang wrote:
> From: Kevin Tang 
> 
> Adds MIPI DSI Master and MIPI DSI-PHY (D-PHY)
> support for Unisoc's display subsystem.
> 
> RFC v7:
>   - Fix DTC unit name warnings
>   - Fix the problem of maintainers
> 
> Cc: Orson Zhai 
> Cc: Chunyan Zhang 
> Signed-off-by: Kevin Tang 
> ---
>  .../display/sprd/sprd,sharkl3-dsi-host.yaml| 98 
> ++
>  .../display/sprd/sprd,sharkl3-dsi-phy.yaml | 75 +
>  2 files changed, 173 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-phy.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml 
> b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
> new file mode 100644
> index 000..b6bbf67
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/display/sprd/sprd,sharkl3-dsi-host.yaml
> @@ -0,0 +1,98 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/sprd/sprd,sharkl3-dsi-host.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Unisoc MIPI DSI Controller
> +
> +maintainers:
> +  - Kevin Tang 
> +
> +properties:
> +  compatible:
> +const: sprd,sharkl3-dsi-host
> +
> +  reg:
> +maxItems: 1
> +description:
> +  Physical base address and length of the registers set for the device.
> +
> +  interrupts:
> +maxItems: 2
> +description:
> +  Should contain DSI interrupt.
> +
> +  clocks:
> +minItems: 1
> +
> +  clock-names:
> +items:
> +  - const: clk_src_96m
> +
> +  power-domains:
> +maxItems: 1
> +description: A phandle to DSIM power domain node
> +
> +  "#address-cells":
> +const: 1
> +
> +  "#size-cells":
> +const: 0
> +
> +  port@0:
> +type: object
> +description:
> +  A port node with endpoint definitions as defined in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt.
> +  That port should be the input endpoint, usually coming from
> +  the associated DPU.
> +  port@1:
> +type: object
> +description:
> +  A port node with endpoint definitions as defined in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt.
> +  That port should be the output endpoint, usually output to
> +  the associated DPHY.

Is there a specific reason you don't follow the OF-graph and have a
ports subnode with your two port@X in there?

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/vc4: hdmi: Block odd horizontal timings

2020-09-28 Thread Maxime Ripard
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 
---
 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 3/9] drm: Add simplekms driver

2020-09-28 Thread Maxime Ripard
Hi Thomas,

On Fri, Sep 25, 2020 at 05:01:23PM +0200, Thomas Zimmermann wrote:
> >> + ARRAY_SIZE(simplekms_formats),
> >> + simplekms_format_modifiers,
> >> + connector);
> >> +  if (ret)
> >> +  return ret;
> >> +
> >> +  drm_mode_config_reset(dev);
> > 
> > This breaks fastboot. I think ideally we'd have the state represent
> > everything is on, and allocate an fb + buffer with the current contents of
> > the framebuffer. Since we can allocate an fb that matches this shouldn't
> > be a problem, just a raw memcpy_fromio should do the job.
> 
> I'm trying to wrap my head around how the fastboot setup is implemented.
> 
> Apparently, i915's fbdev code goes through the existing pipeline state
> and fills the fb_info structure with compatible settings.
> 
> Where is the initial pipeline state created? If I write reset handlers
> that initialize the pipeline to the simple-framebuffer's fixed state,
> whould that be sufficient? A later stage could then do the equivalent of
> intel_fbdev_init_bios().
> 
> The simple-kms helpers don't seem to support custom reset handlers or
> atomic-state callbacks. I guess that would require and update as well?

You probably want to read the following :)

https://lore.kernel.org/dri-devel/CAKMK7uHtqHy_oz4W7F+hmp9iqp7W5Ra8CxPvJ=9bwmvfu-o...@mail.gmail.com/

It's been on my todo-list since, but I never got to work on it :/

Maxime


signature.asc
Description: PGP signature
___
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

2020-09-28 Thread Maxime Ripard
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?

Thanks!
Maxime
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 1/2] drm/vc4: hdmi: Disable Wifi Frequencies

2020-09-28 Thread Maxime Ripard
There's cross-talk on the RPi4 between the 2.4GHz channels used by the WiFi
chip and some resolutions, most notably 1440p at 60Hz.

In such a case, we can either reject entirely the mode, or lower slightly
the pixel frequency to remove the overlap. Let's go for the latter.

Signed-off-by: Maxime Ripard 
---
 .../bindings/display/brcm,bcm2711-hdmi.yaml|  6 ++
 drivers/gpu/drm/vc4/vc4_hdmi.c | 14 +-
 drivers/gpu/drm/vc4/vc4_hdmi.h |  8 
 3 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml 
b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
index 03a76729d26c..63e7fe999c0a 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
@@ -76,6 +76,12 @@ properties:
   resets:
 maxItems: 1
 
+  raspberrypi,disable-wifi-frequencies:
+type: boolean
+description: >
+  Should the pixel frequencies in the WiFi frequencies range be
+  avoided?
+
 required:
   - compatible
   - reg
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index acfb4e235214..74da7c00ecd0 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -877,13 +877,22 @@ static int vc4_hdmi_encoder_atomic_check(struct 
drm_encoder *encoder,
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;
+   unsigned long long pixel_rate;
 
if (vc4_hdmi->variant->broken_odd_h_timings &&
((mode->hdisplay % 2) || (mode->hsync_start % 2) ||
 (mode->hsync_end % 2) || (mode->htotal % 2)))
return -EINVAL;
 
+   /*
+* The 1440p@60 pixel rate is in the same range than the WiFi
+* channels. Slightly lower the frequency to bring it out of the
+* WiFi range.
+*/
+   if (vc4_hdmi->disable_wifi_frequencies && mode->clock == 241500)
+   mode->clock = 238560;
+
+   pixel_rate = mode->clock * 1000;
if (mode->flags & DRM_MODE_FLAG_DBLCLK)
pixel_rate *= 2;
 
@@ -1837,6 +1846,9 @@ 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;
}
 
+   vc4_hdmi->disable_wifi_frequencies =
+   of_property_read_bool(dev->of_node, 
"raspberrypi,disable-wifi-frequencies");
+
pm_runtime_enable(dev);
 
drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS);
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 40e51ece8efe..6618ee758890 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -143,6 +143,14 @@ struct vc4_hdmi {
int hpd_gpio;
bool hpd_active_low;
 
+   /*
+* On some systems (like the RPi4), some modes are in the same
+* frequency range than the WiFi channels (1440p@60Hz for
+* example). Should we take evasive actions because that system
+* has a wifi adapter.
+*/
+   bool disable_wifi_frequencies;
+
struct cec_adapter *cec_adap;
struct cec_msg cec_rx_msg;
bool cec_tx_ok;
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 2/2] ARM: dts: rpi-4: disable wifi frequencies

2020-09-28 Thread Maxime Ripard
The RPi4 WiFi chip and HDMI outputs have some frequency overlap with
crosstalk around 2.4GHz. Let's mark it as such so we can use some evasive
maneuvers.

Signed-off-by: Maxime Ripard 
---
 arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts 
b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
index ca24c2c737ab..1b739c3a9a12 100644
--- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
+++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
@@ -174,12 +174,14 @@  {
  {
clocks = <_clocks 13>, <_clocks 14>, < 0>, 
<_27MHz>;
clock-names = "hdmi", "bvb", "audio", "cec";
+   raspberrypi,disable-wifi-frequencies;
status = "okay";
 };
 
  {
clocks = <_clocks 13>, <_clocks 14>, < 1>, 
<_27MHz>;
clock-names = "hdmi", "bvb", "audio", "cec";
+   raspberrypi,disable-wifi-frequencies;
status = "okay";
 };
 
-- 
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

2020-09-28 Thread Maxime Ripard
Hi,

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.
> 
> Reviewed-by: Dave Stevenson 

Applied 1 and 2, with the typo fixed (and the fixes tag suggested by Daniel)

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 4/6] drm/vc4: hdmi: Create a custom connector state

2020-09-25 Thread Maxime Ripard
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.

Signed-off-by: Maxime Ripard 
---
 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 7d2593398094..5e4ebb51a750 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -170,16 +170,39 @@ 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);
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 63c6f8bddf1d..d53d9fd88bfe 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -169,6 +169,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);
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 1/6] drm/atomic: Pass the full state to CRTC atomic enable/disable

2020-09-25 Thread Maxime Ripard
If the CRTC driver ever needs to access the full DRM state, it can't do so
at atomic_enable / atomic_disable time since drm_atomic_helper_swap_state
will have cleared the pointer from the struct drm_crtc_state to the struct
drm_atomic_state before calling those hooks.

In order to allow that, let's pass the full DRM state to atomic_enable and
atomic_disable. The conversion was done using coccinelle, built tested on
all the drivers and actually tested on vc4.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/arc/arcpgu_crtc.c|  4 ++--
 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c |  8 ++--
 drivers/gpu/drm/arm/hdlcd_crtc.c |  4 ++--
 drivers/gpu/drm/arm/malidp_crtc.c|  6 --
 drivers/gpu/drm/armada/armada_crtc.c |  8 ++--
 drivers/gpu/drm/ast/ast_mode.c   |  6 --
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c   |  4 ++--
 drivers/gpu/drm/drm_atomic_helper.c  |  4 ++--
 drivers/gpu/drm/drm_simple_kms_helper.c  |  4 ++--
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |  4 ++--
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c   |  6 --
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c   |  4 ++--
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c  |  4 ++--
 drivers/gpu/drm/imx/dcss/dcss-crtc.c |  8 ++--
 drivers/gpu/drm/imx/ipuv3-crtc.c |  6 --
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c|  4 ++--
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c  |  4 ++--
 drivers/gpu/drm/meson/meson_crtc.c   |  8 
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c |  6 --
 drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c|  4 ++--
 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c|  4 ++--
 drivers/gpu/drm/mxsfb/mxsfb_kms.c|  4 ++--
 drivers/gpu/drm/omapdrm/omap_crtc.c  |  4 ++--
 drivers/gpu/drm/qxl/qxl_display.c|  4 ++--
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c   |  6 --
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c  |  6 --
 drivers/gpu/drm/sti/sti_crtc.c   |  4 ++--
 drivers/gpu/drm/stm/ltdc.c   |  4 ++--
 drivers/gpu/drm/sun4i/sun4i_crtc.c   |  4 ++--
 drivers/gpu/drm/tegra/dc.c   |  8 
 drivers/gpu/drm/tidss/tidss_crtc.c   |  6 --
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c |  4 ++--
 drivers/gpu/drm/vboxvideo/vbox_mode.c|  4 ++--
 drivers/gpu/drm/vc4/vc4_crtc.c   |  8 ++--
 drivers/gpu/drm/vc4/vc4_txp.c|  8 ++--
 drivers/gpu/drm/virtio/virtgpu_display.c |  4 ++--
 drivers/gpu/drm/vkms/vkms_crtc.c |  4 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c  |  4 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |  4 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c |  4 ++--
 drivers/gpu/drm/xlnx/zynqmp_disp.c   |  6 --
 drivers/gpu/drm/zte/zx_vou.c |  4 ++--
 include/drm/drm_modeset_helper_vtables.h | 13 ++---
 43 files changed, 128 insertions(+), 99 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index be7c29cec318..042d7b54a6de 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -116,7 +116,7 @@ static void arc_pgu_crtc_mode_set_nofb(struct drm_crtc 
*crtc)
 }
 
 static void arc_pgu_crtc_atomic_enable(struct drm_crtc *crtc,
-  struct drm_crtc_state *old_state)
+  struct drm_atomic_state *state)
 {
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
 
@@ -127,7 +127,7 @@ static void arc_pgu_crtc_atomic_enable(struct drm_crtc 
*crtc,
 }
 
 static void arc_pgu_crtc_atomic_disable(struct drm_crtc *crtc,
-   struct drm_crtc_state *old_state)
+   struct drm_atomic_state *state)
 {
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
 
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index f33418d6e1a0..a4bbf56a7fc1 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -273,8 +273,10 @@ komeda_crtc_do_flush(struct drm_crtc *crtc,
 
 static void
 komeda_crtc_atomic_enable(struct drm_crtc *crtc,
- struct drm_crtc_state *old)
+ struct drm_atomic_state *state)
 {
+   struct drm_crtc_state *old = drm_atomic_get_old_crtc_state(state,
+  crtc);
pm_runtime_get_sync(crtc->dev->dev);
komeda_crtc_prepare(to_kcrtc(crtc));
drm_crtc_vblank_on(crtc);
@@ -319,8 +321,10 @@ komeda_crtc_flush_and_wait_for_flip_done(

[PATCH 3/6] drm/vc4: Pass the atomic state to encoder hooks

2020-09-25 Thread Maxime Ripard
We'll need to access the connector state in our encoder setup, so let's
just pass the whole DRM state to our private encoder hooks.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 18 ++
 drivers/gpu/drm/vc4/vc4_drv.h  | 10 +-
 drivers/gpu/drm/vc4/vc4_hdmi.c | 15 ++-
 3 files changed, 25 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 878718b8836e..17a4427bd899 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -403,7 +403,9 @@ static void require_hvs_enabled(struct drm_device *dev)
 SCALER_DISPCTRL_ENABLE);
 }
 
-static int vc4_crtc_disable(struct drm_crtc *crtc, unsigned int channel)
+static int vc4_crtc_disable(struct drm_crtc *crtc,
+   struct drm_atomic_state *state,
+   unsigned int channel)
 {
struct drm_encoder *encoder = vc4_get_crtc_encoder(crtc);
struct vc4_encoder *vc4_encoder = to_vc4_encoder(encoder);
@@ -435,13 +437,13 @@ static int vc4_crtc_disable(struct drm_crtc *crtc, 
unsigned int channel)
mdelay(20);
 
if (vc4_encoder && vc4_encoder->post_crtc_disable)
-   vc4_encoder->post_crtc_disable(encoder);
+   vc4_encoder->post_crtc_disable(encoder, state);
 
vc4_crtc_pixelvalve_reset(crtc);
vc4_hvs_stop_channel(dev, channel);
 
if (vc4_encoder && vc4_encoder->post_crtc_powerdown)
-   vc4_encoder->post_crtc_powerdown(encoder);
+   vc4_encoder->post_crtc_powerdown(encoder, state);
 
return 0;
 }
@@ -468,7 +470,7 @@ int vc4_crtc_disable_at_boot(struct drm_crtc *crtc)
if (channel < 0)
return 0;
 
-   return vc4_crtc_disable(crtc, channel);
+   return vc4_crtc_disable(crtc, NULL, channel);
 }
 
 static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
@@ -484,7 +486,7 @@ static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
/* Disable vblank irq handling before crtc is disabled. */
drm_crtc_vblank_off(crtc);
 
-   vc4_crtc_disable(crtc, old_vc4_state->assigned_channel);
+   vc4_crtc_disable(crtc, state, old_vc4_state->assigned_channel);
 
/*
 * Make sure we issue a vblank event after disabling the CRTC if
@@ -518,14 +520,14 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
vc4_hvs_atomic_enable(crtc, state);
 
if (vc4_encoder->pre_crtc_configure)
-   vc4_encoder->pre_crtc_configure(encoder);
+   vc4_encoder->pre_crtc_configure(encoder, state);
 
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);
+   vc4_encoder->pre_crtc_enable(encoder, state);
 
/* When feeding the transposer block the pixelvalve is unneeded and
 * should not be enabled.
@@ -534,7 +536,7 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
   CRTC_READ(PV_V_CONTROL) | PV_VCONTROL_VIDEN);
 
if (vc4_encoder->post_crtc_enable)
-   vc4_encoder->post_crtc_enable(encoder);
+   vc4_encoder->post_crtc_enable(encoder, state);
 }
 
 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 232da0f50aa1..89e36da5043d 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -442,12 +442,12 @@ struct vc4_encoder {
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 (*pre_crtc_configure)(struct drm_encoder *encoder, struct 
drm_atomic_state *state);
+   void (*pre_crtc_enable)(struct drm_encoder *encoder, struct 
drm_atomic_state *state);
+   void (*post_crtc_enable)(struct drm_encoder *encoder, struct 
drm_atomic_state *state);
 
-   void (*post_crtc_disable)(struct drm_encoder *encoder);
-   void (*post_crtc_powerdown)(struct drm_encoder *encoder);
+   void (*post_crtc_disable)(struct drm_encoder *encoder, struct 
drm_atomic_state *state);
+   void (*post_crtc_powerdown)(struct drm_encoder *encoder, struct 
drm_atomic_state *state);
 };
 
 static inline struct vc4_encoder *
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 03825596a308..7d2593398094 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -357,7 +357,8 @@ static void vc4_hdmi_set_infoframes(struct drm_encoder 
*encoder)
vc4_hdmi_set_audio_infoframe(encoder);
 }
 
-static void vc4_hd

[PATCH 2/6] drm/vc4: hvs: Align the HVS atomic hooks to the new API

2020-09-25 Thread Maxime Ripard
Since the CRTC setup in vc4 is split between the PixelValves/TXP and the
HVS, only the PV/TXP atomic hooks were updated in the previous commits, but
it makes sense to update the HVS ones too.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 4 +---
 drivers/gpu/drm/vc4/vc4_drv.h  | 4 ++--
 drivers/gpu/drm/vc4/vc4_hvs.c  | 8 +---
 drivers/gpu/drm/vc4/vc4_txp.c  | 8 ++--
 4 files changed, 10 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 2e6fc2f28946..878718b8836e 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -503,8 +503,6 @@ static void vc4_crtc_atomic_disable(struct drm_crtc *crtc,
 static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
   struct drm_atomic_state *state)
 {
-   struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state,
-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);
@@ -517,7 +515,7 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
 */
drm_crtc_vblank_on(crtc);
 
-   vc4_hvs_atomic_enable(crtc, old_state);
+   vc4_hvs_atomic_enable(crtc, state);
 
if (vc4_encoder->pre_crtc_configure)
vc4_encoder->pre_crtc_configure(encoder);
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 90b911fd2a7f..232da0f50aa1 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -915,8 +915,8 @@ extern struct platform_driver vc4_hvs_driver;
 void vc4_hvs_stop_channel(struct drm_device *dev, unsigned int output);
 int vc4_hvs_get_fifo_from_output(struct drm_device *dev, unsigned int output);
 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_enable(struct drm_crtc *crtc, struct drm_atomic_state 
*state);
+void vc4_hvs_atomic_disable(struct drm_crtc *crtc, struct drm_atomic_state 
*state);
 void vc4_hvs_atomic_flush(struct drm_crtc *crtc, struct drm_crtc_state *state);
 void vc4_hvs_dump_state(struct drm_device *dev);
 void vc4_hvs_unmask_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 4d0a833366ce..22403ab2a430 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -391,11 +391,12 @@ static void vc4_hvs_update_dlist(struct drm_crtc *crtc)
 }
 
 void vc4_hvs_atomic_enable(struct drm_crtc *crtc,
-  struct drm_crtc_state *old_state)
+  struct drm_atomic_state *state)
 {
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_crtc_state *new_crtc_state = 
drm_atomic_get_new_crtc_state(state, crtc);
+   struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(new_crtc_state);
struct drm_display_mode *mode = >state->adjusted_mode;
bool oneshot = vc4_state->feed_txp;
 
@@ -404,9 +405,10 @@ void vc4_hvs_atomic_enable(struct drm_crtc *crtc,
 }
 
 void vc4_hvs_atomic_disable(struct drm_crtc *crtc,
-   struct drm_crtc_state *old_state)
+   struct drm_atomic_state *state)
 {
struct drm_device *dev = crtc->dev;
+   struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state, 
crtc);
struct vc4_crtc_state *vc4_state = to_vc4_crtc_state(old_state);
unsigned int chan = vc4_state->assigned_channel;
 
diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
index c127bca0f246..8692b101797e 100644
--- a/drivers/gpu/drm/vc4/vc4_txp.c
+++ b/drivers/gpu/drm/vc4/vc4_txp.c
@@ -403,23 +403,19 @@ static int vc4_txp_atomic_check(struct drm_crtc *crtc,
 static void vc4_txp_atomic_enable(struct drm_crtc *crtc,
  struct drm_atomic_state *state)
 {
-   struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state,
-crtc);
drm_crtc_vblank_on(crtc);
-   vc4_hvs_atomic_enable(crtc, old_state);
+   vc4_hvs_atomic_enable(crtc, state);
 }
 
 static void vc4_txp_atomic_disable(struct drm_crtc *crtc,
   struct drm_atomic_state *state)
 {
-   struct drm_crtc_state *old_state = drm_atomic_get_old_crtc_state(state,
-crtc);
struct drm_device *dev = crtc->dev;
 
 

[PATCH 0/6] drm/vc4: hdmi: Support the 10/12 bit output

2020-09-25 Thread Maxime Ripard
Hi,

Here's some patches to enable the HDR output in the RPi4 HDMI controller.

This needed a quite intrusive rework in the first patch to allow a CRTC to
have access to the whole DRM state at atomic_enable / atomic_disable time.

Let me know what you think,
Maxime

Maxime Ripard (6):
  drm/atomic: Pass the full state to CRTC atomic enable/disable
  drm/vc4: hvs: Align the HVS atomic hooks to the new API
  drm/vc4: Pass the atomic state to encoder hooks
  drm/vc4: hdmi: Create a custom connector state
  drm/vc4: hdmi: Store pixel frequency in the connector state
  drm/vc4: hdmi: Enable 10/12 bpc output

 drivers/gpu/drm/arc/arcpgu_crtc.c|   4 +-
 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c |   8 +-
 drivers/gpu/drm/arm/hdlcd_crtc.c |   4 +-
 drivers/gpu/drm/arm/malidp_crtc.c|   6 +-
 drivers/gpu/drm/armada/armada_crtc.c |   8 +-
 drivers/gpu/drm/ast/ast_mode.c   |   6 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c   |   4 +-
 drivers/gpu/drm/drm_atomic_helper.c  |   4 +-
 drivers/gpu/drm/drm_simple_kms_helper.c  |   4 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c |   4 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c   |   6 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c   |   4 +-
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c  |   4 +-
 drivers/gpu/drm/imx/dcss/dcss-crtc.c |   8 +-
 drivers/gpu/drm/imx/ipuv3-crtc.c |   6 +-
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c|   4 +-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c  |   4 +-
 drivers/gpu/drm/meson/meson_crtc.c   |   8 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c |   6 +-
 drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c|   4 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c|   4 +-
 drivers/gpu/drm/mxsfb/mxsfb_kms.c|   4 +-
 drivers/gpu/drm/omapdrm/omap_crtc.c  |   4 +-
 drivers/gpu/drm/qxl/qxl_display.c|   4 +-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c   |   6 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c  |   6 +-
 drivers/gpu/drm/sti/sti_crtc.c   |   4 +-
 drivers/gpu/drm/stm/ltdc.c   |   4 +-
 drivers/gpu/drm/sun4i/sun4i_crtc.c   |   4 +-
 drivers/gpu/drm/tegra/dc.c   |   8 +-
 drivers/gpu/drm/tidss/tidss_crtc.c   |   6 +-
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c |   4 +-
 drivers/gpu/drm/vboxvideo/vbox_mode.c|   4 +-
 drivers/gpu/drm/vc4/vc4_crtc.c   |  26 +--
 drivers/gpu/drm/vc4/vc4_drv.h|  14 +-
 drivers/gpu/drm/vc4/vc4_hdmi.c   | 154 +++-
 drivers/gpu/drm/vc4/vc4_hdmi.h   |  12 +-
 drivers/gpu/drm/vc4/vc4_hdmi_regs.h  |   9 +-
 drivers/gpu/drm/vc4/vc4_hvs.c|   8 +-
 drivers/gpu/drm/vc4/vc4_txp.c|   8 +-
 drivers/gpu/drm/virtio/virtgpu_display.c |   4 +-
 drivers/gpu/drm/vkms/vkms_crtc.c |   4 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c  |   4 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |   4 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c |   4 +-
 drivers/gpu/drm/xlnx/zynqmp_disp.c   |   6 +-
 drivers/gpu/drm/zte/zx_vou.c |   4 +-
 include/drm/drm_modeset_helper_vtables.h |  13 +-
 48 files changed, 313 insertions(+), 129 deletions(-)

base-commit: e742b35e5978d6a679adba2440eb91b0cba513f3
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 6/6] drm/vc4: hdmi: Enable 10/12 bpc output

2020-09-25 Thread Maxime Ripard
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  | 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..1c4dc774d56e 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);
HDMI_WRITE(HDMI_HORZA,
@@ -583,6 +611,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, reg);
+
+   reg = HDMI_READ(HDMI_GCP_WORD_1);
+   reg &= ~VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1_MASK;
+   reg |= VC4_SET_FIELD(gcp, VC5_HDMI_GCP_WORD_1_GCP_SUBPACKET_BYTE_1);
+   HDMI_WRITE(HDMI_GCP_WORD_1, reg);
+
+   reg = HDMI_READ(HDMI_GCP_CONFIG);
+   reg &= ~VC5_HDMI_GCP_CONFIG_GCP_ENAB

[PATCH 5/6] drm/vc4: hdmi: Store pixel frequency in the connector state

2020-09-25 Thread Maxime Ripard
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 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 44 ++-
 drivers/gpu/drm/vc4/vc4_hdmi.h |  1 +-
 2 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 5e4ebb51a750..21d20c8494e8 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -192,6 +192,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;
@@ -609,9 +610,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;
@@ -623,7 +644,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);
@@ -788,6 +809,26 @@ 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 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;
+
+   if (mode->flags & DRM_MODE_FLAG_DBLCLK)
+   pixel_rate *= 2;
+
+   if (pixel_rate > vc4_hdmi->variant->max_pixel_clock)
+   return -EINVAL;
+
+   vc4_state->pixel_rate = pixel_rate;
+
+   return 0;
+}
+
 static enum drm_mode_status
 vc4_hdmi_encoder_mode_valid(struct drm_encoder *encoder,
const struct drm_display_mode *mode)
@@ -801,6 +842,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,
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index d53d9fd88bfe..dbe2393ae043 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -171,6 +171,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 *
-- 
git-series 0.9.1
___
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

2020-09-24 Thread Maxime Ripard
On Fri, Sep 18, 2020 at 04:43:20PM +0100, Dave Stevenson wrote:
> 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 

Applied, thanks!
Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 2/2] drm/vc4: crtc: Keep the previously assigned HVS FIFO

2020-09-24 Thread Maxime Ripard
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 

---

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, connected to up to 6 CRTCs.
@@ -674,7 +684,7 @@ vc4_atomic_check(struct drm_device *dev, struct 
drm_atomic_state *state)
if (matching_channels) {
unsigned int channel = ffs(matching_channels) - 1;
 
-   vc4_crtc_state->assigned_channel = channel;
+   new_vc4_crtc_state->assigned_channel = channel;
unassigned_channels &= ~BIT(channel);
} else {
return -EINVAL;
-- 
2.26.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 1/2] drm/vc4: crtc: Rework a bit the CRTC state code

2020-09-24 Thread Maxime Ripard
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.

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 

---

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


[PULL] drm-misc-next

2020-09-22 Thread Maxime Ripard
ode path.
  drm/ttm: drop special pipeline accel cleanup function.
  drm/ttm: drop evicted from ttm_bo.

Dave Stevenson (7):
  drm/vc4: Add support for the BCM2711 HVS5
  drm/vc4: plane: Change LBM alignment constraint on LBM
  drm/vc4: plane: Optimize the LBM allocation size
  drm/vc4: hdmi: Use reg-names to retrieve the HDMI audio registers
  drm/vc4: hdmi: Reset audio infoframe on encoder_enable if previously 
streaming
  drm/vc4: hdmi: Set the b-frame marker to the match ALSA's default.
  drm/vc4: hdmi: Add audio-related callbacks

Dinghao Liu (2):
  drm/crc-debugfs: Fix memleak in crc_control_write
  video: fbdev: radeon: Fix memleak in radeonfb_pci_register

Doug Horn (1):
  Fix use after free in get_capset_info callback.

Enric Balletbo i Serra (1):
  drm/bridge: ps8640: Rework power state handling

Evgeny Novikov (1):
  fbdev: sm712fb: handle ioremap() errors in probe

George Kennedy (1):
  fbmem: add margin check to fb_check_caps()

Gerd Hoffmann (6):
  drm/virtio: fix unblank
  drm/virtio: drop virtio_gpu_output->enabled
  drm: allow limiting the scatter list size.
  drm/virtio: use drmm_mode_config_init
  drm/virtio: return virtio_gpu_queue errors
  drm/virtio: add virtio_gpu_cmd_unref_resource error handling

Gurchetan Singh (2):
  drm/virtio: fix uninitialized variable
  drm/virtio: report uuid in debugfs

Hoegeun Kwon (1):
  drm/vc4: hdmi: Add pixel BVB clock control

Jason Yan (4):
  video: fbdev: kyro: remove set but not used 'ulBestVCO'
  video: fbdev: kyro: remove set but not used 'ulCoreClock'
  drm/i810: make i810_flush_queue() return void
  drm: xlnx: remove defined but not used 'scaling_factors_666'

Jia Yang (1):
  drm: fix double free for gbo in drm_gem_vram_init and drm_gem_vram_create

Jing Xiangfeng (1):
  fbcon: Remove the superfluous break

Joe Perches (1):
  video: fbdev: tgafb: Avoid comma separated statements

Kristian H. Kristensen (1):
  udmabuf: Add missing compact_ioctl

Laurentiu Palcu (6):
  drm/imx: compile imx directory by default
  drm/imx: Add initial support for DCSS on iMX8MQ
  drm/imx/dcss: use drm_bridge_connector API
  MAINTAINERS: Add entry for i.MX 8MQ DCSS driver
  dt-bindings: display: imx: add bindings for DCSS
  drm/imx/dcss: fix compilation issue on 32bit

Linus Walleij (6):
  drm/panel: s6e63m0: Break out SPI transport
  drm/panel: s6e63m0: Add DSI transport
  drm/panel: s6e63m0: Add reading functionality
  drm/panel: s6e63m0: Add code to identify panel
  drm/panel: s6e63m0: Order enable/disable sequence
  drm/panel: s6e63m0: Fix up DRM_DEV* regression

Luben Tuikov (1):
  drm/amdgpu: Convert to using devm_drm_dev_alloc() (v2)

Lukas Bulwahn (1):
  MAINTAINERS: make linux-aspeed list remarks consistent

Maxime Ripard (74):
  dt-bindings: display: Add support for the BCM2711 HVS
  drm/vc4: hvs: Boost the core clock during modeset
  drm/vc4: plane: Create more planes
  drm/vc4: crtc: Deal with different number of pixel per clock
  drm/vc4: crtc: Use a shared interrupt
  drm/vc4: crtc: Move the cob allocation outside of bind
  drm/vc4: crtc: Rename HVS channel to output
  drm/vc4: crtc: Use local chan variable
  drm/vc4: crtc: Enable and disable the PV in atomic_enable / disable
  drm/vc4: kms: Convert to for_each_new_crtc_state
  drm/vc4: crtc: Assign output to channel automatically
  drm/vc4: crtc: Add FIFO depth to vc4_crtc_data
  drm/vc4: crtc: Add function to compute FIFO level bits
  drm/vc4: crtc: Rename HDMI encoder type to HDMI0
  drm/vc4: crtc: Add HDMI1 encoder type
  drm/vc4: crtc: Disable color management for HVS5
  drm/vc4: crtc: Turn pixelvalve reset into a function
  drm/vc4: crtc: Move PV dump to config_pv
  drm/vc4: crtc: Move HVS init and close to a function
  drm/vc4: crtc: Move the HVS gamma LUT setup to our init function
  drm/vc4: hvs: Make sure our channel is reset
  drm/vc4: crtc: Remove mode_set_nofb
  drm/vc4: crtc: Remove redundant pixelvalve reset
  drm/vc4: crtc: Move HVS channel init before the PV initialisation
  drm/vc4: encoder: Add finer-grained encoder callbacks
  drm/vc4: crtc: Add a delay after disabling the PixelValve output
  drm/vc4: crtc: Clear the PixelValve FIFO on disable
  drm/vc4: crtc: Clear the PixelValve FIFO during configuration
  drm/vc4: hvs: Make the stop_channel function public
  drm/vc4: hvs: Introduce a function to get the assigned FIFO
  drm/vc4: crtc: Move the CRTC disable out
  drm/vc4: drv: Disable the CRTC at boot time
  dt-bindings: display: vc4: pv: Add BCM2711 pixel valves
  drm/vc4: crtc: Add BCM2711 pixelvalves
  drm/vc4: hdmi: Use debugfs private field
  drm/vc4: hdmi: Move structure to header
  drm/vc4: hdmi: rework connectors and encoders
  dr

Re: [PATCH] drm/vc4: hvs: Pull the state of all the CRTCs prior to PV muxing

2020-09-22 Thread Maxime Ripard
On Fri, Sep 18, 2020 at 03:52:55PM +0100, Dave Stevenson wrote:
> 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

Oops, thanks

I've fixed it while applying it

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 2/2] drm/vc4: crtc: Keep the previously assigned HVS FIFO

2020-09-19 Thread Maxime Ripard
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 
---
 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;
+
+   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)
 
 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;
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);
+   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, connected to up to 6 CRTCs.
@@ -674,7 +683,7 @@ vc4_atomic_check(struct drm_device *dev, struct 
drm_atomic_state *state)
if (matching_channels) {
unsigned int channel = ffs(matching_channels) - 1;
 
-   vc4_crtc_state->assigned_channel = channel;
+   new_vc4_crtc_state->assigned_channel = channel;
unassigned_channels &= ~

[PATCH 1/2] drm/vc4: kms: Assign a FIFO to enabled CRTCs instead of active

2020-09-19 Thread Maxime Ripard
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 
---
 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


[PULL] drm-misc-next

2020-09-19 Thread Maxime Ripard
ction directly.
  drm/ttm: add a simple assign mem to bo wrapper
  drm/ttm: move ghost object creation to a common function
  drm/ttm: make common function for wait/free node path.
  drm/ttm: drop special pipeline accel cleanup function.
  drm/ttm: drop evicted from ttm_bo.

Dave Stevenson (7):
  drm/vc4: Add support for the BCM2711 HVS5
  drm/vc4: plane: Change LBM alignment constraint on LBM
  drm/vc4: plane: Optimize the LBM allocation size
  drm/vc4: hdmi: Use reg-names to retrieve the HDMI audio registers
  drm/vc4: hdmi: Reset audio infoframe on encoder_enable if previously 
streaming
  drm/vc4: hdmi: Set the b-frame marker to the match ALSA's default.
  drm/vc4: hdmi: Add audio-related callbacks

Dinghao Liu (2):
  drm/crc-debugfs: Fix memleak in crc_control_write
  video: fbdev: radeon: Fix memleak in radeonfb_pci_register

Doug Horn (1):
  Fix use after free in get_capset_info callback.

Enric Balletbo i Serra (1):
  drm/bridge: ps8640: Rework power state handling

Evgeny Novikov (1):
  fbdev: sm712fb: handle ioremap() errors in probe

George Kennedy (1):
  fbmem: add margin check to fb_check_caps()

Gerd Hoffmann (6):
  drm/virtio: fix unblank
  drm/virtio: drop virtio_gpu_output->enabled
  drm: allow limiting the scatter list size.
  drm/virtio: use drmm_mode_config_init
  drm/virtio: return virtio_gpu_queue errors
  drm/virtio: add virtio_gpu_cmd_unref_resource error handling

Gurchetan Singh (2):
  drm/virtio: fix uninitialized variable
  drm/virtio: report uuid in debugfs

Hoegeun Kwon (1):
  drm/vc4: hdmi: Add pixel BVB clock control

Jason Yan (4):
  video: fbdev: kyro: remove set but not used 'ulBestVCO'
  video: fbdev: kyro: remove set but not used 'ulCoreClock'
  drm/i810: make i810_flush_queue() return void
  drm: xlnx: remove defined but not used 'scaling_factors_666'

Jia Yang (1):
  drm: fix double free for gbo in drm_gem_vram_init and drm_gem_vram_create

Joe Perches (1):
  video: fbdev: tgafb: Avoid comma separated statements

Kristian H. Kristensen (1):
  udmabuf: Add missing compact_ioctl

Laurentiu Palcu (6):
  drm/imx: compile imx directory by default
  drm/imx: Add initial support for DCSS on iMX8MQ
  drm/imx/dcss: use drm_bridge_connector API
  MAINTAINERS: Add entry for i.MX 8MQ DCSS driver
  dt-bindings: display: imx: add bindings for DCSS
  drm/imx/dcss: fix compilation issue on 32bit

Linus Walleij (6):
  drm/panel: s6e63m0: Break out SPI transport
  drm/panel: s6e63m0: Add DSI transport
  drm/panel: s6e63m0: Add reading functionality
  drm/panel: s6e63m0: Add code to identify panel
  drm/panel: s6e63m0: Order enable/disable sequence
  drm/panel: s6e63m0: Fix up DRM_DEV* regression

Lukas Bulwahn (1):
  MAINTAINERS: make linux-aspeed list remarks consistent

Maxime Ripard (73):
  dt-bindings: display: Add support for the BCM2711 HVS
  drm/vc4: hvs: Boost the core clock during modeset
  drm/vc4: plane: Create more planes
  drm/vc4: crtc: Deal with different number of pixel per clock
  drm/vc4: crtc: Use a shared interrupt
  drm/vc4: crtc: Move the cob allocation outside of bind
  drm/vc4: crtc: Rename HVS channel to output
  drm/vc4: crtc: Use local chan variable
  drm/vc4: crtc: Enable and disable the PV in atomic_enable / disable
  drm/vc4: kms: Convert to for_each_new_crtc_state
  drm/vc4: crtc: Assign output to channel automatically
  drm/vc4: crtc: Add FIFO depth to vc4_crtc_data
  drm/vc4: crtc: Add function to compute FIFO level bits
  drm/vc4: crtc: Rename HDMI encoder type to HDMI0
  drm/vc4: crtc: Add HDMI1 encoder type
  drm/vc4: crtc: Disable color management for HVS5
  drm/vc4: crtc: Turn pixelvalve reset into a function
  drm/vc4: crtc: Move PV dump to config_pv
  drm/vc4: crtc: Move HVS init and close to a function
  drm/vc4: crtc: Move the HVS gamma LUT setup to our init function
  drm/vc4: hvs: Make sure our channel is reset
  drm/vc4: crtc: Remove mode_set_nofb
  drm/vc4: crtc: Remove redundant pixelvalve reset
  drm/vc4: crtc: Move HVS channel init before the PV initialisation
  drm/vc4: encoder: Add finer-grained encoder callbacks
  drm/vc4: crtc: Add a delay after disabling the PixelValve output
  drm/vc4: crtc: Clear the PixelValve FIFO on disable
  drm/vc4: crtc: Clear the PixelValve FIFO during configuration
  drm/vc4: hvs: Make the stop_channel function public
  drm/vc4: hvs: Introduce a function to get the assigned FIFO
  drm/vc4: crtc: Move the CRTC disable out
  drm/vc4: drv: Disable the CRTC at boot time
  dt-bindings: display: vc4: pv: Add BCM2711 pixel valves
  drm/vc4: crtc: Add BCM2711 pixelvalves
  drm/vc4: hdmi: Use debugfs private field
  drm/vc4: hdmi: Move structure to header
  drm/vc4: hdmi: rework conne

[PATCH] drm/vc4: hvs: Pull the state of all the CRTCs prior to PV muxing

2020-09-17 Thread Maxime Ripard
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
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.

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 
---
 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 v5 00/80] drm/vc4: Support BCM2711 Display Pipeline

2020-09-17 Thread Maxime Ripard
On Mon, Sep 14, 2020 at 07:14:11PM +0900, Hoegeun Kwon wrote:
> Hi Maxime,
> 
> On 9/8/20 9:00 PM, Maxime Ripard wrote:
> > Hi Hoegeun,
> >
> > On Mon, Sep 07, 2020 at 08:49:12PM +0900, Hoegeun Kwon wrote:
> >> On 9/3/20 5:00 PM, Maxime Ripard wrote:
> >>> Hi everyone,
> >>>
> >>> Here's a (pretty long) series to introduce support in the VC4 DRM driver
> >>> for the display pipeline found in the BCM2711 (and thus the RaspberryPi 
> >>> 4).
> >>>
> >>> The main differences are that there's two HDMI controllers and that 
> >>> there's
> >>> more pixelvalve now. Those pixelvalve come with a mux in the HVS that 
> >>> still
> >>> have only 3 FIFOs. Both of those differences are breaking a bunch of
> >>> expectations in the driver, so we first need a good bunch of cleanup and
> >>> reworks to introduce support for the new controllers.
> >>>
> >>> Similarly, the HDMI controller has all its registers shuffled and split in
> >>> multiple controllers now, so we need a bunch of changes to support this as
> >>> well.
> >>>
> >>> Only the HDMI support is enabled for now (even though the DPI and DSI
> >>> outputs have been tested too).
> >>>
> >>> Let me know if you have any comments
> >>> Maxime
> >>>
> >>> Cc: bcm-kernel-feedback-l...@broadcom.com
> >>> Cc: devicet...@vger.kernel.org
> >>> Cc: Kamal Dasu 
> >>> Cc: Philipp Zabel 
> >>> Cc: Rob Herring 
> >>> Cc: Stephen Boyd 
> >>>
> >>> Changes from v4:
> >>> - Rebased on top of next-20200828
> >>> - Collected the various tags
> >>> - Fixed some issues with 4k support and dual output (thanks Hoegeun!)
> >> Thanks for your v5 patchset.
> >>
> >> I tested all patches based on the next-20200812.
> > Thanks again for testing all the patches
> >
> >> Everything else is fine, but the dual hdmi modetest doesn't work well in my
> >> environment...
> >>
> >> In my environment, dsi is not connected, I have seen your answer[1].
> > Can you share a bit more your setup? What monitors are being connected
> > to each HDMI port? Do you hotplug any?
> Yes, Monitors are being connected to each HDMI ports. (did not use hotplug)
> 
> When booting, both HDMI-0 and 1 are recognized and the kernel log is output.
> But after run modetest on HDMI-0(works) and modetest on HDMI-1(works),
> crtc timed out occurs on HDMI-0 and does not work.
> 
> When HDMI-0 is not working we do a modetest on HDMI-0, it will work agin
> after about 40 sec.
> 
> Below is the log for modetest.
> 
> 
> root:~> modetest -Mvc4 -s 32:1280x720         - HDMI-0 works
> setting mode 1280x720-60Hz@XR24 on connectors 32, crtc 64
> failed to set gamma: Invalid argument
> 
> root:~> modetest -Mvc4 -s 32:1280x720         - HDMI-0 works
> setting mode 1280x720-60Hz@XR24 on connectors 32, crtc 64
> failed to set gamma: Invalid argument
> 
> root:~> modetest -Mvc4 -s 38:1280x720         - HDMI-1 works
> setting mode 1280x720-60Hz@XR24 on connectors 38, crtc 69
> failed to set gamma: Invalid argument
> 
>                                - Crtc timed out occurs on HDMI-0 and 
> does not work.
> 
> [   71.134283] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* 
> [CRTC:64:crtc-3] flip_done timed out
> [   81.374296] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
> [CRTC:64:crtc-3] flip_done timed out
> [   91.618380] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
> [CONNECTOR:32:HDMI-A-1] flip_done timed out
> [  101.854274] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
> [PLANE:60:plane-3] flip_done timed out
> 
> [  112.094271] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* 
> [CRTC:64:crtc-3] flip_done timed out
> [  122.590311] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
> [CRTC:64:crtc-3] flip_done timed out
> 
> root:~> modetest -Mvc4 -s 32:1280x720
> [  132.830309] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
> [CONNECTOR:32:HDMI-A-1] flip_done timed out
> [  143.070307] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
> [PLANE:60:plane-3] flip_done timed out
> [  153.310303] [drm:drm_atomic_helper_wait_for_flip_done] *ERROR* 
> [CRTC:64:crtc-3] flip_done timed out
> setting mode 1280x720-60Hz@XR24 on connectors 32, crtc 64
> [  163.550340] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
> [CRTC:64:crtc-3] flip_done timed out
> [  173.790277] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
> [CONNECTOR:32:HDMI-A-1] flip_done timed out
> [  184.030286] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* 
> [PLANE:60:plane-3] flip_done timed out
> failed to set gamma: Invalid argument         - HDMI-0 works

Thanks :)

I was able to reproduce it just by also letting X boot. I'm on a good
path to fix it and found a workaround. I'll send you the patch in the
upcoming days :)

Thanks again,
Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [git pull] virtio-shm region

2020-09-16 Thread Maxime Ripard
On Tue, Sep 15, 2020 at 04:38:04PM -0700, Gurchetan Singh wrote:
> On Tue, Sep 15, 2020 at 8:27 AM Maxime Ripard  wrote:
> 
> > Hi,
> >
> > On Mon, Sep 14, 2020 at 04:39:41PM -0700, Gurchetan Singh wrote:
> > > Hi,
> > >
> > > This set of changes are required for zero-copy virtio-gpu.
> > >
> > > The following changes since commit
> > 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5:
> > >
> > >   Linux 5.9-rc1 (2020-08-16 13:04:57 -0700)
> > >
> > > are available in the Git repository at:
> > >
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git
> > virtio-shm
> > >
> > > for you to fetch changes up to 38e895487afc2ed42c11045853cbb3fa20b52b6e:
> > >
> > >   virtio: Implement get_shm_region for MMIO transport (2020-09-10
> > 10:05:58
> > > +0200)
> > >
> > > 
> > > Sebastien Boeuf (3):
> > >   virtio: Add get_shm_region method
> > >   virtio: Implement get_shm_region for PCI transport
> > >   virtio: Implement get_shm_region for MMIO transport
> > >
> > >  drivers/virtio/virtio_mmio.c   | 31 +
> > >  drivers/virtio/virtio_pci_modern.c | 95
> > > ++
> > >  include/linux/virtio_config.h  | 17 +++
> > >  include/uapi/linux/virtio_mmio.h   | 11 +
> > >  include/uapi/linux/virtio_pci.h| 11 -
> > >  5 files changed, 164 insertions(+), 1 deletion(-)
> >
> > It's not really clear who you expect to pull that PR?
> >
> 
> Hmm, Daniel recommended "send[ing] the topic pull request to drm-misc
> maintainers (Maarten, Maxime, Thomas)" in the other thread, but I'm not
> really sure which one.  Maybe whomever is in charge of drm-misc-next pull
> requests?

That would be me then. I've applied it (but had to hack dim a bit, it
doesn't like !text email too much apparently) and pushed it to
drm-misc-next.

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [git pull] virtio-shm region

2020-09-15 Thread Maxime Ripard
Hi,

On Mon, Sep 14, 2020 at 04:39:41PM -0700, Gurchetan Singh wrote:
> Hi,
> 
> This set of changes are required for zero-copy virtio-gpu.
> 
> The following changes since commit 9123e3a74ec7b934a4a099e98af6a61c2f80bbf5:
> 
>   Linux 5.9-rc1 (2020-08-16 13:04:57 -0700)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git virtio-shm
> 
> for you to fetch changes up to 38e895487afc2ed42c11045853cbb3fa20b52b6e:
> 
>   virtio: Implement get_shm_region for MMIO transport (2020-09-10 10:05:58
> +0200)
> 
> 
> Sebastien Boeuf (3):
>   virtio: Add get_shm_region method
>   virtio: Implement get_shm_region for PCI transport
>   virtio: Implement get_shm_region for MMIO transport
> 
>  drivers/virtio/virtio_mmio.c   | 31 +
>  drivers/virtio/virtio_pci_modern.c | 95
> ++
>  include/linux/virtio_config.h  | 17 +++
>  include/uapi/linux/virtio_mmio.h   | 11 +
>  include/uapi/linux/virtio_pci.h| 11 -
>  5 files changed, 164 insertions(+), 1 deletion(-)

It's not really clear who you expect to pull that PR?

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/vc4: Fix bitwise OR versus ternary operator in vc4_plane_mode_set

2020-09-14 Thread Maxime Ripard
On Thu, Sep 10, 2020 at 10:18:32AM -0700, Nathan Chancellor wrote:
> Clang warns:
> 
> drivers/gpu/drm/vc4/vc4_plane.c:901:27: warning: operator '?:' has lower
> precedence than '|'; '|' will be evaluated first
> [-Wbitwise-conditional-parentheses]
> fb->format->has_alpha ?
> ~ ^
> drivers/gpu/drm/vc4/vc4_plane.c:901:27: note: place parentheses around
> the '|' expression to silence this warning
> fb->format->has_alpha ?
> ~ ^
> drivers/gpu/drm/vc4/vc4_plane.c:901:27: note: place parentheses around
> the '?:' expression to evaluate it first
> fb->format->has_alpha ?
> ~~^
> 1 warning generated.
> 
> Add the parentheses as that was clearly intended, otherwise
> SCALER5_CTL2_ALPHA_PREMULT won't be added to the list.
> 
> Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1150
> Signed-off-by: Nathan Chancellor 

Applied, thanks!
Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/vc4: Update type of reg parameter in vc4_hdmi_{read,write}

2020-09-14 Thread Maxime Ripard
On Thu, Sep 10, 2020 at 10:04:02AM -0700, Nathan Chancellor wrote:
> Clang warns 100+ times in the vc4 driver along the lines of:
> 
> drivers/gpu/drm/vc4/vc4_hdmi_phy.c:518:13: warning: implicit conversion
> from enumeration type 'enum vc4_hdmi_field' to different enumeration
> type 'enum vc4_hdmi_regs' [-Wenum-conversion]
> HDMI_WRITE(HDMI_TX_PHY_POWERDOWN_CTL,
> ~~~^~
> 
> The HDMI_READ and HDMI_WRITE macros pass in enumerators of type
> vc4_hdmi_field but vc4_hdmi_write and vc4_hdmi_read expect a enumerator
> of type vc4_hdmi_regs, causing a warning for every instance of this.
> Update the parameter type so there is no more mismatch.
> 
> Fixes: 311e305fdb4e ("drm/vc4: hdmi: Implement a register layout abstraction")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1149
> Signed-off-by: Nathan Chancellor 

Applied, thanks!
Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/vc4: hdmi: Fix NULL vs IS_ERR() checks in vc5_hdmi_init_resources()

2020-09-11 Thread Maxime Ripard
On Thu, Sep 10, 2020 at 01:08:25PM +0300, Dan Carpenter wrote:
> The devm_ioremap() function never returns error pointers, it returns
> NULL.
> 
> Fixes: 8323989140f3 ("drm/vc4: hdmi: Support the BCM2711 HDMI controllers")
> Signed-off-by: Dan Carpenter 

Applied, thanks!
Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PULL] drm-misc-next

2020-09-11 Thread Maxime Ripard
   drm/panel: s6e63m0: Add reading functionality
  drm/panel: s6e63m0: Add code to identify panel
  drm/panel: s6e63m0: Order enable/disable sequence
  drm/panel: s6e63m0: Fix up DRM_DEV* regression

Maxime Ripard (71):
  dt-bindings: display: Add support for the BCM2711 HVS
  drm/vc4: hvs: Boost the core clock during modeset
  drm/vc4: plane: Create more planes
  drm/vc4: crtc: Deal with different number of pixel per clock
  drm/vc4: crtc: Use a shared interrupt
  drm/vc4: crtc: Move the cob allocation outside of bind
  drm/vc4: crtc: Rename HVS channel to output
  drm/vc4: crtc: Use local chan variable
  drm/vc4: crtc: Enable and disable the PV in atomic_enable / disable
  drm/vc4: kms: Convert to for_each_new_crtc_state
  drm/vc4: crtc: Assign output to channel automatically
  drm/vc4: crtc: Add FIFO depth to vc4_crtc_data
  drm/vc4: crtc: Add function to compute FIFO level bits
  drm/vc4: crtc: Rename HDMI encoder type to HDMI0
  drm/vc4: crtc: Add HDMI1 encoder type
  drm/vc4: crtc: Disable color management for HVS5
  drm/vc4: crtc: Turn pixelvalve reset into a function
  drm/vc4: crtc: Move PV dump to config_pv
  drm/vc4: crtc: Move HVS init and close to a function
  drm/vc4: crtc: Move the HVS gamma LUT setup to our init function
  drm/vc4: hvs: Make sure our channel is reset
  drm/vc4: crtc: Remove mode_set_nofb
  drm/vc4: crtc: Remove redundant pixelvalve reset
  drm/vc4: crtc: Move HVS channel init before the PV initialisation
  drm/vc4: encoder: Add finer-grained encoder callbacks
  drm/vc4: crtc: Add a delay after disabling the PixelValve output
  drm/vc4: crtc: Clear the PixelValve FIFO on disable
  drm/vc4: crtc: Clear the PixelValve FIFO during configuration
  drm/vc4: hvs: Make the stop_channel function public
  drm/vc4: hvs: Introduce a function to get the assigned FIFO
  drm/vc4: crtc: Move the CRTC disable out
  drm/vc4: drv: Disable the CRTC at boot time
  dt-bindings: display: vc4: pv: Add BCM2711 pixel valves
  drm/vc4: crtc: Add BCM2711 pixelvalves
  drm/vc4: hdmi: Use debugfs private field
  drm/vc4: hdmi: Move structure to header
  drm/vc4: hdmi: rework connectors and encoders
  drm/vc4: hdmi: Remove DDC argument to connector_init
  drm/vc4: hdmi: Rename hdmi to vc4_hdmi
  drm/vc4: hdmi: Move accessors to vc4_hdmi
  drm/vc4: hdmi: Use local vc4_hdmi directly
  drm/vc4: hdmi: Add container_of macros for encoders and connectors
  drm/vc4: hdmi: Pass vc4_hdmi to CEC code
  drm/vc4: hdmi: Retrieve the vc4_hdmi at unbind using our device
  drm/vc4: hdmi: Remove vc4_dev hdmi pointer
  drm/vc4: hdmi: Remove vc4_hdmi_connector
  drm/vc4: hdmi: Introduce resource init and variant
  drm/vc4: hdmi: Implement a register layout abstraction
  drm/vc4: hdmi: Add reset callback
  drm/vc4: hdmi: Add PHY init and disable function
  drm/vc4: hdmi: Add PHY RNG enable / disable function
  drm/vc4: hdmi: Add a CSC setup callback
  drm/vc4: hdmi: Add a set_timings callback
  drm/vc4: hdmi: Store the encoder type in the variant structure
  drm/vc4: hdmi: Deal with multiple debugfs files
  drm/vc4: hdmi: Move CEC init to its own function
  drm/vc4: hdmi: Add CEC support flag
  drm/vc4: hdmi: Remove unused CEC_CLOCK_DIV define
  drm/vc4: hdmi: Rename drm_encoder pointer in mode_valid
  drm/vc4: hdmi: Adjust HSM clock rate depending on pixel rate
  drm/vc4: hdmi: Use clk_set_min_rate instead
  drm/vc4: hdmi: Deal with multiple ALSA cards
  drm/vc4: hdmi: Remove register dumps in enable
  drm/vc4: hdmi: Always recenter the HDMI FIFO
  drm/vc4: hdmi: Implement finer-grained hooks
  drm/vc4: hdmi: Do the VID_CTL configuration at once
  drm/vc4: hdmi: Switch to blank pixels when disabled
  drm/vc4: hdmi: Support the BCM2711 HDMI controllers
  dt-bindings: display: vc4: hdmi: Add BCM2711 HDMI controllers bindings
  dt-bindings: display: vc4: Document BCM2711 VC5
  drm/vc4: drv: Support BCM2711

Melissa Wen (1):
  MAINTAINERS: add entry for VKMS

Mike Rapoport (1):
  fbdev: remove mbx framebuffer driver

Neil Armstrong (1):
  drm/bridge: dw-mipi-dsi: fix dw_mipi_dsi_debugfs_show/write warnings

Randy Dunlap (2):
  dma-buf: fix kernel-doc warning in dma-fence.c
  dma-buf: fix kernel-doc warning in 

Rikard Falkeborn (1):
  drm/gma500: Constify static structs

Rodrigo Alencar (1):
  video: fbdev: ssd1307fb: Added support to Column offset

Rodrigo Siqueira (3):
  drm/vkms: Decouple crc operations from composer
  drm/vkms: Compute CRC without change input data
  drm/vkms: Add support for writeback

Sam McNally (1):
  drm/dp_mst: Support remote i2c writes

Sven Schneider (1):
  lib/fonts: add font 6x8 for OLED display

Tom Rix (1):
  video: fbdev: sis: fix null ptr dere

Re: [PATCH] drm/vc4: hdmi: Fix off by ones in vc4_hdmi_read/write()

2020-09-11 Thread Maxime Ripard
On Thu, Sep 10, 2020 at 01:07:48PM +0300, Dan Carpenter wrote:
> The variant->registers[] has ->num_registers elements so the >
> comparison needs to be changes to >= to prevent an out of bounds
> access.
> 
> Fixes: 311e305fdb4e ("drm/vc4: hdmi: Implement a register layout abstraction")
> Signed-off-by: Dan Carpenter 

Applied, thanks!
Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 0/2] drm/sun4i: sun8i-csc: Secondary CSC register correction

2020-09-11 Thread Maxime Ripard
On Sun, Sep 06, 2020 at 06:21:38PM +0200, Martin Cerveny wrote:
> The secondary video layer (VI) on "Allwinner V3s" displays
> decoded video (YUV) in wrong colors. The secondary
> CSC should be programmed. 
> Let's correct CSC register offset and extend regmap size.

Applied both, thanks

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/vc4/vc4_hdmi: fill ASoC card owner

2020-09-10 Thread Maxime Ripard
On Tue, Aug 25, 2020 at 02:38:19PM +0200, Stefan Wahren wrote:
> Am 10.07.20 um 11:47 schrieb Stefan Wahren:
> > Hi Marek,
> >
> > Am 02.07.20 um 08:58 schrieb Marek Szyprowski:
> >> On 01.07.2020 20:49, Stefan Wahren wrote:
> >>> Am 01.07.20 um 09:39 schrieb Marek Szyprowski:
>  card->owner is a required property and since commit 81033c6b584b ("ALSA:
>  core: Warn on empty module") a warning is issued if it is empty. Fix lack
>  of it. This fixes following warning observed on RaspberryPi 3B board
>  with ARM 32bit kernel and multi_v7_defconfig:
> 
>  [ cut here ]
>  WARNING: CPU: 1 PID: 210 at sound/core/init.c:207 
>  snd_card_new+0x378/0x398 [snd]
>  Modules linked in: vc4(+) snd_soc_core ac97_bus snd_pcm_dmaengine 
>  bluetooth snd_pcm snd_timer crc32_arm_ce raspberrypi_hwmon snd soundcore 
>  ecdh_generic ecc bcm2835_thermal phy_generic
>  CPU: 1 PID: 210 Comm: systemd-udevd Not tainted 
>  5.8.0-rc1-00027-g81033c6b584b #1087
>  Hardware name: BCM2835
>  [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
>  [] (show_stack) from [] (dump_stack+0xd4/0xe8)
>  [] (dump_stack) from [] (__warn+0xdc/0xf4)
>  [] (__warn) from [] (warn_slowpath_fmt+0xb0/0xb8)
>  [] (warn_slowpath_fmt) from [] 
>  (snd_card_new+0x378/0x398 [snd])
>  [] (snd_card_new [snd]) from [] 
>  (snd_soc_bind_card+0x280/0x99c [snd_soc_core])
>  [] (snd_soc_bind_card [snd_soc_core]) from [] 
>  (devm_snd_soc_register_card+0x34/0x6c [snd_soc_core])
>  [] (devm_snd_soc_register_card [snd_soc_core]) from 
>  [] (vc4_hdmi_bind+0x43c/0x5f4 [vc4])
>  [] (vc4_hdmi_bind [vc4]) from [] 
>  (component_bind_all+0xec/0x24c)
>  [] (component_bind_all) from [] 
>  (vc4_drm_bind+0xd4/0x174 [vc4])
>  [] (vc4_drm_bind [vc4]) from [] 
>  (try_to_bring_up_master+0x160/0x1b0)
>  [] (try_to_bring_up_master) from [] 
>  (component_master_add_with_match+0xd0/0x104)
>  [] (component_master_add_with_match) from [] 
>  (vc4_platform_drm_probe+0x9c/0xbc [vc4])
>  [] (vc4_platform_drm_probe [vc4]) from [] 
>  (platform_drv_probe+0x6c/0xa4)
>  [] (platform_drv_probe) from [] 
>  (really_probe+0x210/0x350)
>  [] (really_probe) from [] 
>  (driver_probe_device+0x5c/0xb4)
>  [] (driver_probe_device) from [] 
>  (device_driver_attach+0x58/0x60)
>  [] (device_driver_attach) from [] 
>  (__driver_attach+0x80/0xbc)
>  [] (__driver_attach) from [] 
>  (bus_for_each_dev+0x68/0xb4)
>  [] (bus_for_each_dev) from [] 
>  (bus_add_driver+0x130/0x1e8)
>  [] (bus_add_driver) from [] 
>  (driver_register+0x78/0x110)
>  [] (driver_register) from [] 
>  (do_one_initcall+0x50/0x220)
>  [] (do_one_initcall) from [] 
>  (do_init_module+0x60/0x210)
>  [] (do_init_module) from [] 
>  (load_module+0x1e34/0x2338)
>  [] (load_module) from [] (sys_finit_module+0xac/0xbc)
>  [] (sys_finit_module) from [] 
>  (ret_fast_syscall+0x0/0x54)
>  Exception stack(0xeded9fa8 to 0xeded9ff0)
>  ...
>  ---[ end trace 6414689569c2bc08 ]---
> 
>  Suggested-by: Takashi Iwai 
>  Signed-off-by: Marek Szyprowski 
> > Tested-by: Stefan Wahren 
> >>> thanks for this patch. Any chance for a fixes tag here?
> >> Fixes: bb7d78568814 ("drm/vc4: Add HDMI audio support")
> > Thanks
> 
> gentle ping ...

I just applied it, thanks!
Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v5 00/80] drm/vc4: Support BCM2711 Display Pipeline

2020-09-09 Thread Maxime Ripard
Hi Hoegeun,

On Mon, Sep 07, 2020 at 08:49:12PM +0900, Hoegeun Kwon wrote:
> On 9/3/20 5:00 PM, Maxime Ripard wrote:
> > Hi everyone,
> >
> > Here's a (pretty long) series to introduce support in the VC4 DRM driver
> > for the display pipeline found in the BCM2711 (and thus the RaspberryPi 4).
> >
> > The main differences are that there's two HDMI controllers and that there's
> > more pixelvalve now. Those pixelvalve come with a mux in the HVS that still
> > have only 3 FIFOs. Both of those differences are breaking a bunch of
> > expectations in the driver, so we first need a good bunch of cleanup and
> > reworks to introduce support for the new controllers.
> >
> > Similarly, the HDMI controller has all its registers shuffled and split in
> > multiple controllers now, so we need a bunch of changes to support this as
> > well.
> >
> > Only the HDMI support is enabled for now (even though the DPI and DSI
> > outputs have been tested too).
> >
> > Let me know if you have any comments
> > Maxime
> >
> > Cc: bcm-kernel-feedback-l...@broadcom.com
> > Cc: devicet...@vger.kernel.org
> > Cc: Kamal Dasu 
> > Cc: Philipp Zabel 
> > Cc: Rob Herring 
> > Cc: Stephen Boyd 
> >
> > Changes from v4:
> >- Rebased on top of next-20200828
> >- Collected the various tags
> >- Fixed some issues with 4k support and dual output (thanks Hoegeun!)
> 
> Thanks for your v5 patchset.
> 
> I tested all patches based on the next-20200812.

Thanks again for testing all the patches

> Everything else is fine, but the dual hdmi modetest doesn't work well in my
> environment...
> 
> In my environment, dsi is not connected, I have seen your answer[1].

Can you share a bit more your setup? What monitors are being connected
to each HDMI port? Do you hotplug any?

Maxime
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v5 00/80] drm/vc4: Support BCM2711 Display Pipeline

2020-09-08 Thread Maxime Ripard
Hi,

On Thu, Sep 03, 2020 at 10:00:32AM +0200, Maxime Ripard wrote:
> Hi everyone,
> 
> Here's a (pretty long) series to introduce support in the VC4 DRM driver
> for the display pipeline found in the BCM2711 (and thus the RaspberryPi 4).
> 
> The main differences are that there's two HDMI controllers and that there's
> more pixelvalve now. Those pixelvalve come with a mux in the HVS that still
> have only 3 FIFOs. Both of those differences are breaking a bunch of
> expectations in the driver, so we first need a good bunch of cleanup and
> reworks to introduce support for the new controllers.
> 
> Similarly, the HDMI controller has all its registers shuffled and split in
> multiple controllers now, so we need a bunch of changes to support this as
> well.
> 
> Only the HDMI support is enabled for now (even though the DPI and DSI
> outputs have been tested too).

I've applied the patches 1-79 to drm-misc. I guess the final DT patch
should go through the arm-soc tree?

Thanks to everyone involved in the reviews

Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v5 00/80] drm/vc4: Support BCM2711 Display Pipeline

2020-09-08 Thread Maxime Ripard
Hi!

On Fri, Sep 04, 2020 at 06:16:16PM +0800, Jian-Hong Pan wrote:
> Thanks for version 5 patch series!
> 
> I applied it based on linux-next tag next-20200828 and build it with
> the config [1] to test on RPi 4
> However, It fails to get HDMI state machine clock and pixel bcb clock.
> Then, vc4-drm probes failed. Full dmseg [2]:
> 
> [2.552675] [drm:vc5_hdmi_init_resources] *ERROR* Failed to get
> HDMI state machine clock
> [2.557974] raspberrypi-firmware soc:firmware: Attached to firmware
> from 2020-06-01T13:23:40
> [2.567612] of_clk_hw_onecell_get: invalid index 14
> [2.567636] [drm:vc5_hdmi_init_resources] *ERROR* Failed to get
> pixel bvb clock
> [2.567664] vc4-drm gpu: failed to bind fef00700.hdmi (ops vc4_hdmi_ops): 
> -2
> [2.567731] vc4-drm gpu: master bind failed: -2
> [2.567755] vc4-drm: probe of gpu failed with error -2

Sorry, I should have mentionned it in the cover letter. This series
depends on that patch from Hoegeun:
https://lore.kernel.org/dri-devel/20200901040759.29992-2-hoegeun.k...@samsung.com/

Maxime


signature.asc
Description: PGP signature
___
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

2020-09-08 Thread Maxime Ripard
Hi,

On Fri, Sep 04, 2020 at 10:46:26AM +0100, Dave Stevenson wrote:
> 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.

I'm currently working on the 4k60 support, so it will go away soon
(using your suggestion) so there's no need to overthink it :)

> >  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 

I've fixed it, thanks!
Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/sun4i: Fix DE2 YVU handling

2020-09-04 Thread Maxime Ripard
On Wed, Sep 02, 2020 at 12:03:05AM +0200, Jernej Skrabec wrote:
> Function sun8i_vi_layer_get_csc_mode() is supposed to return CSC mode
> but due to inproper return type (bool instead of u32) it returns just 0
> or 1. Colors are wrong for YVU formats because of that.
> 
> Fixes: daab3d0e8e2b ("drm/sun4i: de2: csc_mode in de2 format struct is mostly 
> redundant")
> Reported-by: Roman Stratiienko 
> Signed-off-by: Jernej Skrabec 

Applied, thanks!
Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/2] drm/sun4i: backend: Support alpha property on lowest plane

2020-09-04 Thread Maxime Ripard
On Sat, Aug 29, 2020 at 02:56:58PM +0800, Chen-Yu Tsai wrote:
> On Tue, Jul 28, 2020 at 9:48 PM Maxime Ripard  wrote:
> >
> > Unlike what we previously thought, only the per-pixel alpha is broken on
> > the lowest plane and the per-plane alpha isn't. Remove the check on the
> > alpha property being set on the lowest plane to reject a mode.
> >
> > Cc: Paul Kocialkowski 
> > Fixes: dcf496a6a608 ("drm/sun4i: sun4i: Introduce a quirk for lowest plane 
> > alpha support")
> > Signed-off-by: Maxime Ripard 
> 
> Reviewed-by: Chen-Yu Tsai 
> 
> once the build break is fixed.

Applied both patches (and fixed the breakage along the way)

Thanks!
Maxime


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v5 42/80] drm/vc4: hdmi: Rename hdmi to vc4_hdmi

2020-09-04 Thread Maxime Ripard
The driver isn't consistent with the name given to the vc4_hdmi
structure pointer in its functions. Make sure to use a consistent name.

Reviewed-by: Eric Anholt 
Tested-by: Chanwoo Choi 
Tested-by: Hoegeun Kwon 
Tested-by: Stefan Wahren 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 283 +-
 1 file changed, 142 insertions(+), 141 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 1f350b068fcd..6733e4bc235b 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -109,11 +109,11 @@ static const struct debugfs_reg32 hd_regs[] = {
 static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
 {
struct drm_info_node *node = (struct drm_info_node *)m->private;
-   struct vc4_hdmi *hdmi = node->info_ent->data;
+   struct vc4_hdmi *vc4_hdmi = node->info_ent->data;
struct drm_printer p = drm_seq_file_printer(m);
 
-   drm_print_regset32(, >hdmi_regset);
-   drm_print_regset32(, >hd_regset);
+   drm_print_regset32(, _hdmi->hdmi_regset);
+   drm_print_regset32(, _hdmi->hd_regset);
 
return 0;
 }
@@ -291,8 +291,8 @@ 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 *connector = >connector.base;
+   struct vc4_hdmi *vc4_hdmi = vc4->hdmi;
+   struct drm_connector *connector = _hdmi->connector.base;
struct drm_connector_state *cstate = connector->state;
struct drm_crtc *crtc = encoder->crtc;
const struct drm_display_mode *mode = >state->adjusted_mode;
@@ -337,7 +337,7 @@ static void vc4_hdmi_set_audio_infoframe(struct drm_encoder 
*encoder)
 {
struct drm_device *drm = encoder->dev;
struct vc4_dev *vc4 = drm->dev_private;
-   struct vc4_hdmi *hdmi = vc4->hdmi;
+   struct vc4_hdmi *vc4_hdmi = vc4->hdmi;
union hdmi_infoframe frame;
int ret;
 
@@ -346,7 +346,7 @@ static void vc4_hdmi_set_audio_infoframe(struct drm_encoder 
*encoder)
frame.audio.coding_type = HDMI_AUDIO_CODING_TYPE_STREAM;
frame.audio.sample_frequency = HDMI_AUDIO_SAMPLE_FREQUENCY_STREAM;
frame.audio.sample_size = HDMI_AUDIO_SAMPLE_SIZE_STREAM;
-   frame.audio.channels = hdmi->audio.channels;
+   frame.audio.channels = vc4_hdmi->audio.channels;
 
vc4_hdmi_write_infoframe(encoder, );
 }
@@ -361,7 +361,7 @@ static void vc4_hdmi_encoder_disable(struct drm_encoder 
*encoder)
 {
struct drm_device *dev = encoder->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
-   struct vc4_hdmi *hdmi = vc4->hdmi;
+   struct vc4_hdmi *vc4_hdmi = vc4->hdmi;
int ret;
 
HDMI_WRITE(VC4_HDMI_RAM_PACKET_CONFIG, 0);
@@ -370,9 +370,9 @@ static void vc4_hdmi_encoder_disable(struct drm_encoder 
*encoder)
HD_WRITE(VC4_HD_VID_CTL,
 HD_READ(VC4_HD_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
 
-   clk_disable_unprepare(hdmi->pixel_clock);
+   clk_disable_unprepare(vc4_hdmi->pixel_clock);
 
-   ret = pm_runtime_put(>pdev->dev);
+   ret = pm_runtime_put(_hdmi->pdev->dev);
if (ret < 0)
DRM_ERROR("Failed to release power domain: %d\n", ret);
 }
@@ -383,7 +383,7 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder 
*encoder)
struct vc4_hdmi_encoder *vc4_encoder = to_vc4_hdmi_encoder(encoder);
struct drm_device *dev = encoder->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
-   struct vc4_hdmi *hdmi = vc4->hdmi;
+   struct vc4_hdmi *vc4_hdmi = vc4->hdmi;
bool debug_dump_regs = false;
bool hsync_pos = mode->flags & DRM_MODE_FLAG_PHSYNC;
bool vsync_pos = mode->flags & DRM_MODE_FLAG_PVSYNC;
@@ -405,13 +405,13 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder 
*encoder)
u32 csc_ctl;
int ret;
 
-   ret = pm_runtime_get_sync(>pdev->dev);
+   ret = pm_runtime_get_sync(_hdmi->pdev->dev);
if (ret < 0) {
DRM_ERROR("Failed to retain power domain: %d\n", ret);
return;
}
 
-   ret = clk_set_rate(hdmi->pixel_clock,
+   ret = clk_set_rate(vc4_hdmi->pixel_clock,
   mode->clock * 1000 *
   ((mode->flags & DRM_MODE_FLAG_DBLCLK) ? 2 : 1));
if (ret) {
@@ -419,7 +419,7 @@ static void vc4_hdmi_encoder_enable(struct drm_encoder 
*encoder)
return;
}
 
-   ret = clk_prepare_enable(hdmi->pixel_clock);
+   ret = clk_prepare_enable(vc4_hdmi->pixel_clock);
if (ret) {

[PATCH v5 66/80] drm/vc4: hdmi: Reset audio infoframe on encoder_enable if previously streaming

2020-09-04 Thread Maxime Ripard
From: Dave Stevenson 

If the encoder is disabled and re-enabled (eg mode change) all infoframes
are reset, whilst the audio subsystem know nothing about this change.
The driver therefore needs to reinstate the audio infoframe for
itself.

Tested-by: Chanwoo Choi 
Tested-by: Hoegeun Kwon 
Tested-by: Stefan Wahren 
Signed-off-by: Dave Stevenson 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 12 
 drivers/gpu/drm/vc4/vc4_hdmi.h |  2 ++
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 53c3b5ae1179..43e59466b1d8 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -308,8 +308,16 @@ static void vc4_hdmi_set_audio_infoframe(struct 
drm_encoder *encoder)
 
 static void vc4_hdmi_set_infoframes(struct drm_encoder *encoder)
 {
+   struct vc4_hdmi *vc4_hdmi = encoder_to_vc4_hdmi(encoder);
+
vc4_hdmi_set_avi_infoframe(encoder);
vc4_hdmi_set_spd_infoframe(encoder);
+   /*
+* If audio was streaming, then we need to reenabled the audio
+* infoframe here during encoder_enable.
+*/
+   if (vc4_hdmi->audio.streaming)
+   vc4_hdmi_set_audio_infoframe(encoder);
 }
 
 static void vc4_hdmi_encoder_disable(struct drm_encoder *encoder)
@@ -694,6 +702,7 @@ static void vc4_hdmi_audio_reset(struct vc4_hdmi *vc4_hdmi)
struct device *dev = _hdmi->pdev->dev;
int ret;
 
+   vc4_hdmi->audio.streaming = false;
ret = vc4_hdmi_stop_packet(encoder, HDMI_INFOFRAME_TYPE_AUDIO);
if (ret)
dev_err(dev, "Failed to stop audio infoframe: %d\n", ret);
@@ -797,6 +806,7 @@ 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);
+   vc4_hdmi->audio.streaming = true;
 
if (vc4_hdmi->variant->phy_rng_enable)
vc4_hdmi->variant->phy_rng_enable(vc4_hdmi);
@@ -815,6 +825,8 @@ static int vc4_hdmi_audio_trigger(struct snd_pcm_substream 
*substream, int cmd,
if (vc4_hdmi->variant->phy_rng_disable)
vc4_hdmi->variant->phy_rng_disable(vc4_hdmi);
 
+   vc4_hdmi->audio.streaming = false;
+
break;
default:
break;
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
index 342f6e0227a2..77d47d1707ce 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.h
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
@@ -85,6 +85,8 @@ struct vc4_hdmi_audio {
int channels;
struct snd_dmaengine_dai_dma_data dma_data;
struct snd_pcm_substream *substream;
+
+   bool streaming;
 };
 
 /* General HDMI hardware state. */
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v5 67/80] drm/vc4: hdmi: Set the b-frame marker to the match ALSA's default.

2020-09-04 Thread Maxime Ripard
From: Dave Stevenson 

ALSA's iec958 plugin by default sets the block start preamble
to 8, whilst this driver was programming the hardware to expect
0xF.
Amend the hardware config to match ALSA.

Tested-by: Chanwoo Choi 
Tested-by: Hoegeun Kwon 
Tested-by: Stefan Wahren 
Signed-off-by: Dave Stevenson 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 43e59466b1d8..d8137b838326 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -754,10 +754,11 @@ static int vc4_hdmi_audio_hw_params(struct 
snd_pcm_substream *substream,
 
vc4_hdmi_audio_set_mai_clock(vc4_hdmi);
 
+   /* The B frame identifier should match the value used by alsa-lib (8) */
audio_packet_config =
VC4_HDMI_AUDIO_PACKET_ZERO_DATA_ON_SAMPLE_FLAT |
VC4_HDMI_AUDIO_PACKET_ZERO_DATA_ON_INACTIVE_CHANNELS |
-   VC4_SET_FIELD(0xf, VC4_HDMI_AUDIO_PACKET_B_FRAME_IDENTIFIER);
+   VC4_SET_FIELD(0x8, VC4_HDMI_AUDIO_PACKET_B_FRAME_IDENTIFIER);
 
channel_mask = GENMASK(vc4_hdmi->audio.channels - 1, 0);
audio_packet_config |= VC4_SET_FIELD(channel_mask,
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v5 64/80] drm/vc4: hdmi: Use clk_set_min_rate instead

2020-09-04 Thread Maxime Ripard
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.

Reviewed-by: Dave Stevenson 
Tested-by: Chanwoo Choi 
Tested-by: Hoegeun Kwon 
Tested-by: Stefan Wahren 
Signed-off-by: Maxime Ripard 
---
 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 84273fe650d6..487c04de6b85 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


[PATCH v5 79/80] drm/vc4: drv: Support BCM2711

2020-09-04 Thread Maxime Ripard
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 
---
 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_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 b/drivers/gpu/drm/vc4/vc4_plane.c
index 1e38e603f83b..24d7e6db6fdd 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -516,6 +516,11 @@ static void vc4_plane_calc_load(struct drm_plane_state 
*state)
struct vc4_plane_state *vc4_state;
struct drm_crt

[PATCH v5 69/80] drm/vc4: hdmi: Deal with multiple ALSA cards

2020-09-04 Thread Maxime Ripard
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 we 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.

Reviewed-by: Dave Stevenson 
Tested-by: Chanwoo Choi 
Tested-by: Hoegeun Kwon 
Tested-by: Stefan Wahren 
Signed-off-by: Maxime Ripard 
---
 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 20cfc85449ca..5e479647559f 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -1043,7 +1043,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;
 
/*
@@ -1502,6 +1502,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


[PATCH v5 57/80] drm/vc4: hdmi: Store the encoder type in the variant structure

2020-09-04 Thread Maxime Ripard
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.

Reviewed-by: Dave Stevenson 
Tested-by: Chanwoo Choi 
Tested-by: Hoegeun Kwon 
Tested-by: Stefan Wahren 
Signed-off-by: Maxime Ripard 
---
 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 9e2bc6cb690e..f6d18bdbd1bb 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -1267,7 +1267,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;
 
@@ -1446,6 +1446,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


[PATCH v5 58/80] drm/vc4: hdmi: Deal with multiple debugfs files

2020-09-04 Thread 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 variant to avoid that name conflict.

Reviewed-by: Dave Stevenson 
Tested-by: Chanwoo Choi 
Tested-by: Hoegeun Kwon 
Tested-by: Stefan Wahren 
Signed-off-by: Maxime Ripard 
---
 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 f6d18bdbd1bb..4d0b44a2ac61 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -1369,7 +1369,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;
 
@@ -1447,6 +1449,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


[PATCH v5 73/80] drm/vc4: hdmi: Do the VID_CTL configuration at once

2020-09-04 Thread Maxime Ripard
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.

Reviewed-by: Dave Stevenson 
Tested-by: Chanwoo Choi 
Tested-by: Hoegeun Kwon 
Tested-by: Stefan Wahren 
Signed-off-by: Maxime Ripard 
---
 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 128d33c8c2c3..8bf69cafdd7e 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


[PATCH v5 41/80] drm/vc4: hdmi: Remove DDC argument to connector_init

2020-09-04 Thread Maxime Ripard
Now that we are passing the vc4_hdmi structure to the connector init
function, we can simply use the pointer in that structure instead of
having the pointer as an argument.

Reviewed-by: Eric Anholt 
Tested-by: Chanwoo Choi 
Tested-by: Hoegeun Kwon 
Tested-by: Stefan Wahren 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_hdmi.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index 9a0612a87fb8..1f350b068fcd 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -192,8 +192,7 @@ static const struct drm_connector_helper_funcs 
vc4_hdmi_connector_helper_funcs =
 };
 
 static int vc4_hdmi_connector_init(struct drm_device *dev,
-  struct vc4_hdmi *vc4_hdmi,
-  struct i2c_adapter *ddc)
+  struct vc4_hdmi *vc4_hdmi)
 {
struct vc4_hdmi_connector *hdmi_connector = _hdmi->connector;
struct drm_connector *connector = _connector->base;
@@ -205,7 +204,7 @@ static int vc4_hdmi_connector_init(struct drm_device *dev,
drm_connector_init_with_ddc(dev, connector,
_hdmi_connector_funcs,
DRM_MODE_CONNECTOR_HDMIA,
-   ddc);
+   vc4_hdmi->ddc);
drm_connector_helper_add(connector, _hdmi_connector_helper_funcs);
 
/* Create and attach TV margin props to this connector. */
@@ -1322,7 +1321,7 @@ static int vc4_hdmi_bind(struct device *dev, struct 
device *master, void *data)
drm_simple_encoder_init(drm, encoder, DRM_MODE_ENCODER_TMDS);
drm_encoder_helper_add(encoder, _hdmi_encoder_helper_funcs);
 
-   ret = vc4_hdmi_connector_init(drm, hdmi, hdmi->ddc);
+   ret = vc4_hdmi_connector_init(drm, hdmi);
if (ret)
goto err_destroy_encoder;
 
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v5 16/80] drm/vc4: crtc: Add function to compute FIFO level bits

2020-09-04 Thread Maxime Ripard
The longer FIFOs in vc5 pixelvalves means that the FIFO full level
doesn't fit in the original register field and that we also have a
secondary field. In order to prepare for this, let's move the registers
fill part to a helper function.

Reviewed-by: Eric Anholt 
Tested-by: Chanwoo Choi 
Tested-by: Hoegeun Kwon 
Tested-by: Stefan Wahren 
Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/vc4/vc4_crtc.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 2c64efd2d3d9..1d9e3658ae59 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -234,6 +234,15 @@ static u32 vc4_get_fifo_full_level(struct vc4_crtc 
*vc4_crtc, u32 format)
}
 }
 
+static u32 vc4_crtc_get_fifo_full_level_bits(struct vc4_crtc *vc4_crtc,
+u32 format)
+{
+   u32 level = vc4_get_fifo_full_level(vc4_crtc, format);
+
+   return VC4_SET_FIELD(level & 0x3f,
+PV_CONTROL_FIFO_LEVEL);
+}
+
 /*
  * Returns the encoder attached to the CRTC.
  *
@@ -336,9 +345,8 @@ static void vc4_crtc_config_pv(struct drm_crtc *crtc)
CRTC_WRITE(PV_HACT_ACT, mode->hdisplay * pixel_rep);
 
CRTC_WRITE(PV_CONTROL,
+  vc4_crtc_get_fifo_full_level_bits(vc4_crtc, format) |
   VC4_SET_FIELD(format, PV_CONTROL_FORMAT) |
-  VC4_SET_FIELD(vc4_get_fifo_full_level(vc4_crtc, format),
-PV_CONTROL_FIFO_LEVEL) |
   VC4_SET_FIELD(pixel_rep - 1, PV_CONTROL_PIXEL_REP) |
   PV_CONTROL_CLR_AT_START |
   PV_CONTROL_TRIGGER_UNDERFLOW |
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v5 52/80] drm/vc4: hdmi: Add reset callback

2020-09-04 Thread Maxime Ripard
The BCM2711 and BCM283x HDMI controllers use a slightly different reset
sequence, so let's add a callback to reset the controller.

Reviewed-by: Dave Stevenson 
Tested-by: Chanwoo Choi 
Tested-by: Hoegeun Kwon 
Tested-by: Stefan Wahren 
Signed-off-by: Maxime Ripard 
---
 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 adc7c0693650..77971be075ec 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.
@@ -1291,14 +1303,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);
@@ -1427,6 +1431,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


[PATCH v5 56/80] drm/vc4: hdmi: Add a set_timings callback

2020-09-04 Thread Maxime Ripard
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 
---
 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,
-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));
-
+   if (vc4_hdmi->variant->set_timings)
+   vc4_hdmi->variant->set_timings(vc4_hdmi, mode);
 
if (vc4_encoder->hdmi_monitor &&
drm_default_rgb

[PATCH v5 70/80] drm/vc4: hdmi: Remove register dumps in enable

2020-09-04 Thread Maxime Ripard
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.

Reviewed-by: Dave Stevenson 
Tested-by: Chanwoo Choi 
Tested-by: Hoegeun Kwon 
Tested-by: Stefan Wahren 
Signed-off-by: Maxime Ripard 
---
 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 5e479647559f..3c7862a1dda8 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


[PATCH v5 27/80] drm/vc4: crtc: Move HVS channel init before the PV initialisation

2020-09-04 Thread Maxime Ripard
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.

Reviewed-by: Dave Stevenson 
Tested-by: Chanwoo Choi 
Tested-by: Hoegeun Kwon 
Tested-by: Stefan Wahren 
Signed-off-by: Maxime Ripard 
---
 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


  1   2   3   4   5   6   7   8   9   10   >