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: [email protected]
Cc: [email protected]
Cc: Kamal Dasu <[email protected]>
Cc: Philipp Zabel <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: Stephen Boyd <[email protected]>
Changes from v4:
- Rebased on top of next-20200828
- Collected the various tags
- Fixed some issues with 4k support and dual output (thanks Hoegeun!)
- Fixed typos in commit logs (thanks Dave!)
- Split the csc setup hook into its own patch again
- Added the CEC clock to the DT binding
- Fixed the DT binding example
- Reduced the number of calls to of_device_is_compatible in vc4_kms_load
- Added back the check for the state commit in our commit hook
Changes from v3:
- Rebased on top of next-20200708
- Added a name to the HDMI audio codec component
- Only disable the BCM2711 HDMI pixelvalves at boot
- Fixed an error in the HVS binding
- Fix a framebuffer size condition that was inverted
- Changed the channel allocation algorithm using Eric's suggestion
- Always write the muxing values instead of updating if needed
- Improved a bit the hvs_available_channels comment in the structure
- Change atomic_complete_commit code to use for_each_new_crtc_in_state
- Change the muxing code to take into account disparities between the
BCM2711 and previous SoCs.
- Only change the clock rate on BCM2711 during a modeset
- Fix a crash at atomic_disable
- Use clk_set_min_rate for the core clock too
- Add a few defines, and simplify the FIFO level stuff
- Reordered the patches according to Eric's reviews
- Fixed a regression with VID_CTL setting on RPI3
Changes from v2:
- Rebased on top of next-20200526
- Split the firmware clock series away
- Removed the stuck pixel (with all the subsequent pixels being shifted
by one
- Fixed the writeback issue too.
- Fix the dual output
- Fixed the return value of phy_get_cp_current
- Enhanced the comment on the reset delay
- Increase the max width and height
- Made a proper Kconfig option for the DVP clock driver
- Fixed the alsa card name collision
Changes from v1:
- Rebased on top of 5.7-rc1
- Run checkpatch
- Added audio support
- Fixed some HDMI timeouts
- Swiched to clk_hw_register_gate_parent_data
- Reorder Kconfig symbols in drivers/i2c/busses
- Make the firmware clocks a child of the firmware node
- Switch DVP clock driver to clk_hw interface
- constify raspberrypi_clk_data in raspberrypi_clock_property
- Don't mark firmware clocks as IGNORE_UNUSED
- Change from reset_ms to reset_us in reset-simple, and add a bit more
comments
- Remove generic clk patch to test if a NULL pointer is returned
- Removed misleading message in the is_prepared renaming patch commit
message
- Constify HDMI controller variants
- Fix a bug in the allocation size of the clk data array
- Added a mention in the DT binding conversion patches about the breakage
- Merged a few fixes from kbuild
- Fixed a few bisection and CEC build issues
- Collected Acked-by and Reviewed-by
- Change Dave email address to raspberrypi.com
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
Hoegeun Kwon (1):
drm/vc4: hdmi: Add pixel BVB clock control
Maxime Ripard (72):
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
ARM: dts: bcm2711: Enable the display pipeline
Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml | 117 +++++-
Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml | 18 +-
Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml | 5 +-
Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml | 1 +-
arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 48 ++-
arch/arm/boot/dts/bcm2711.dtsi | 122 ++++-
drivers/gpu/drm/vc4/Makefile | 1 +-
drivers/gpu/drm/vc4/vc4_crtc.c | 354 +++++++++++----
drivers/gpu/drm/vc4/vc4_drv.c | 5 +-
drivers/gpu/drm/vc4/vc4_drv.h | 43 +-
drivers/gpu/drm/vc4/vc4_hdmi.c | 1650 +++++++++++++++++++++++++++++++++++++++++++-----------------------------
drivers/gpu/drm/vc4/vc4_hdmi.h | 184 ++++++++-
drivers/gpu/drm/vc4/vc4_hdmi_phy.c | 520 +++++++++++++++++++++++-
drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 442 +++++++++++++++++++-
drivers/gpu/drm/vc4/vc4_hvs.c | 269 +++++++-----
drivers/gpu/drm/vc4/vc4_kms.c | 229 +++++++++-
drivers/gpu/drm/vc4/vc4_plane.c | 222 +++++++---
drivers/gpu/drm/vc4/vc4_regs.h | 177 +++-----
drivers/gpu/drm/vc4/vc4_txp.c | 4 +-
19 files changed, 3406 insertions(+), 1005 deletions(-)
create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi.h
create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi_phy.c
create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi_regs.h
base-commit: 20c0f70ad7bf5aaf2e22ef974867d0708373fe93
--
git-series 0.9.1
Some of the HDMI pixelvalves in vc5 output two pixels per clock cycle.
Let's put the number of pixel output per clock cycle in the CRTC data and
update the various calculations to reflect that.
Reviewed-by: Eric Anholt <[email protected]>
Tested-by: Chanwoo Choi <[email protected]>
Tested-by: Hoegeun Kwon <[email protected]>
Tested-by: Stefan Wahren <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
---
drivers/gpu/drm/vc4/vc4_crtc.c | 18 +++++++++++-------
drivers/gpu/drm/vc4/vc4_drv.h | 3 +++
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 6d8fa6118fc1..e55b2208b4b7 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -235,6 +235,7 @@ static void vc4_crtc_config_pv(struct drm_crtc *crtc)
struct drm_encoder *encoder = vc4_get_crtc_encoder(crtc);
struct vc4_encoder *vc4_encoder = to_vc4_encoder(encoder);
struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
+ const struct vc4_pv_data *pv_data = vc4_crtc_to_vc4_pv_data(vc4_crtc);
struct drm_crtc_state *state = crtc->state;
struct drm_display_mode *mode = &state->adjusted_mode;
bool interlace = mode->flags & DRM_MODE_FLAG_INTERLACE;
@@ -242,6 +243,7 @@ static void vc4_crtc_config_pv(struct drm_crtc *crtc)
bool is_dsi = (vc4_encoder->type == VC4_ENCODER_TYPE_DSI0 ||
vc4_encoder->type == VC4_ENCODER_TYPE_DSI1);
u32 format = is_dsi ? PV_CONTROL_FORMAT_DSIV_24 : PV_CONTROL_FORMAT_24;
+ u8 ppc = pv_data->pixels_per_clock;
/* Reset the PV fifo. */
CRTC_WRITE(PV_CONTROL, 0);
@@ -249,17 +251,16 @@ static void vc4_crtc_config_pv(struct drm_crtc *crtc)
CRTC_WRITE(PV_CONTROL, 0);
CRTC_WRITE(PV_HORZA,
- VC4_SET_FIELD((mode->htotal -
- mode->hsync_end) * pixel_rep,
+ VC4_SET_FIELD((mode->htotal - mode->hsync_end) * pixel_rep / ppc,
PV_HORZA_HBP) |
- VC4_SET_FIELD((mode->hsync_end -
- mode->hsync_start) * pixel_rep,
+ VC4_SET_FIELD((mode->hsync_end - mode->hsync_start) * pixel_rep / ppc,
PV_HORZA_HSYNC));
+
CRTC_WRITE(PV_HORZB,
- VC4_SET_FIELD((mode->hsync_start -
- mode->hdisplay) * pixel_rep,
+ VC4_SET_FIELD((mode->hsync_start - mode->hdisplay) * pixel_rep / ppc,
PV_HORZB_HFP) |
- VC4_SET_FIELD(mode->hdisplay * pixel_rep, PV_HORZB_HACTIVE));
+ VC4_SET_FIELD(mode->hdisplay * pixel_rep / ppc,
+ PV_HORZB_HACTIVE));
CRTC_WRITE(PV_VERTA,
VC4_SET_FIELD(mode->crtc_vtotal - mode->crtc_vsync_end,
@@ -761,6 +762,7 @@ static const struct vc4_pv_data bcm2835_pv0_data = {
.hvs_channel = 0,
},
.debugfs_name = "crtc0_regs",
+ .pixels_per_clock = 1,
.encoder_types = {
[PV_CONTROL_CLK_SELECT_DSI] = VC4_ENCODER_TYPE_DSI0,
[PV_CONTROL_CLK_SELECT_DPI_SMI_HDMI] = VC4_ENCODER_TYPE_DPI,
@@ -772,6 +774,7 @@ static const struct vc4_pv_data bcm2835_pv1_data = {
.hvs_channel = 2,
},
.debugfs_name = "crtc1_regs",
+ .pixels_per_clock = 1,
.encoder_types = {
[PV_CONTROL_CLK_SELECT_DSI] = VC4_ENCODER_TYPE_DSI1,
[PV_CONTROL_CLK_SELECT_DPI_SMI_HDMI] = VC4_ENCODER_TYPE_SMI,
@@ -783,6 +786,7 @@ static const struct vc4_pv_data bcm2835_pv2_data = {
.hvs_channel = 1,
},
.debugfs_name = "crtc2_regs",
+ .pixels_per_clock = 1,
.encoder_types = {
[PV_CONTROL_CLK_SELECT_DPI_SMI_HDMI] = VC4_ENCODER_TYPE_HDMI,
[PV_CONTROL_CLK_SELECT_VEC] = VC4_ENCODER_TYPE_VEC,
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 6358f6ca8d56..0bc150daafb2 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -454,6 +454,9 @@ struct vc4_crtc_data {
struct vc4_pv_data {
struct vc4_crtc_data base;
+ /* Number of pixels output per clock period */
+ u8 pixels_per_clock;
+
enum vc4_encoder_type encoder_types[4];
const char *debugfs_name;
--
git-series 0.9.1
The driver resets the pixelvalve FIFO in a number of occurences without
always using the same sequence.
Since this will be critical for BCM2711, let's move that sequence to a
function so that we are consistent.
Reviewed-by: Eric Anholt <[email protected]>
Tested-by: Chanwoo Choi <[email protected]>
Tested-by: Hoegeun Kwon <[email protected]>
Tested-by: Stefan Wahren <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
---
drivers/gpu/drm/vc4/vc4_crtc.c | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 41bc61d5a61f..c2ab907611e3 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -267,6 +267,15 @@ static struct drm_encoder *vc4_get_crtc_encoder(struct drm_crtc *crtc)
return NULL;
}
+static void vc4_crtc_pixelvalve_reset(struct drm_crtc *crtc)
+{
+ struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
+
+ /* The PV needs to be disabled before it can be flushed */
+ CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) & ~PV_CONTROL_EN);
+ CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) | PV_CONTROL_FIFO_CLR);
+}
+
static void vc4_crtc_config_pv(struct drm_crtc *crtc)
{
struct drm_encoder *encoder = vc4_get_crtc_encoder(crtc);
@@ -282,10 +291,7 @@ static void vc4_crtc_config_pv(struct drm_crtc *crtc)
u32 format = is_dsi ? PV_CONTROL_FORMAT_DSIV_24 : PV_CONTROL_FORMAT_24;
u8 ppc = pv_data->pixels_per_clock;
- /* Reset the PV fifo. */
- CRTC_WRITE(PV_CONTROL, 0);
- CRTC_WRITE(PV_CONTROL, PV_CONTROL_FIFO_CLR | PV_CONTROL_EN);
- CRTC_WRITE(PV_CONTROL, 0);
+ vc4_crtc_pixelvalve_reset(crtc);
CRTC_WRITE(PV_HORZA,
VC4_SET_FIELD((mode->htotal - mode->hsync_end) * pixel_rep / ppc,
@@ -430,9 +436,9 @@ static void vc4_crtc_atomic_enable(struct drm_crtc *crtc,
require_hvs_enabled(dev);
- /* Reset the PV fifo. */
- CRTC_WRITE(PV_CONTROL, CRTC_READ(PV_CONTROL) |
- PV_CONTROL_FIFO_CLR | PV_CONTROL_EN);
+ vc4_crtc_pixelvalve_reset(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().
--
git-series 0.9.1
In vc5, the HVS has 6 outputs and 3 FIFOs (or channels), with
pixelvalves each being assigned to a given output, but each output can
then be muxed to feed from multiple FIFOs.
Since vc4 had that entirely static, both were probably equivalent, but
since that changes, let's rename hvs_channel to hvs_output in the
vc4_crtc_data, since a pixelvalve is really connected to an output, and
not to a FIFO.
Reviewed-by: Dave Stevenson <[email protected]>
Tested-by: Chanwoo Choi <[email protected]>
Tested-by: Hoegeun Kwon <[email protected]>
Tested-by: Stefan Wahren <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
---
drivers/gpu/drm/vc4/vc4_crtc.c | 8 ++++----
drivers/gpu/drm/vc4/vc4_drv.h | 4 ++--
drivers/gpu/drm/vc4/vc4_hvs.c | 2 +-
drivers/gpu/drm/vc4/vc4_txp.c | 2 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index fdecaba77836..d3126fe04d9a 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -775,7 +775,7 @@ static const struct drm_crtc_helper_funcs vc4_crtc_helper_funcs = {
static const struct vc4_pv_data bcm2835_pv0_data = {
.base = {
- .hvs_channel = 0,
+ .hvs_output = 0,
},
.debugfs_name = "crtc0_regs",
.pixels_per_clock = 1,
@@ -787,7 +787,7 @@ static const struct vc4_pv_data bcm2835_pv0_data = {
static const struct vc4_pv_data bcm2835_pv1_data = {
.base = {
- .hvs_channel = 2,
+ .hvs_output = 2,
},
.debugfs_name = "crtc1_regs",
.pixels_per_clock = 1,
@@ -799,7 +799,7 @@ static const struct vc4_pv_data bcm2835_pv1_data = {
static const struct vc4_pv_data bcm2835_pv2_data = {
.base = {
- .hvs_channel = 1,
+ .hvs_output = 1,
},
.debugfs_name = "crtc2_regs",
.pixels_per_clock = 1,
@@ -862,7 +862,7 @@ int vc4_crtc_init(struct drm_device *drm, struct vc4_crtc *vc4_crtc,
drm_crtc_init_with_planes(drm, crtc, primary_plane, NULL,
crtc_funcs, NULL);
drm_crtc_helper_add(crtc, crtc_helper_funcs);
- vc4_crtc->channel = vc4_crtc->data->hvs_channel;
+ vc4_crtc->channel = vc4_crtc->data->hvs_output;
drm_mode_crtc_set_gamma_size(crtc, ARRAY_SIZE(vc4_crtc->lut_r));
drm_crtc_enable_color_mgmt(crtc, 0, false, crtc->gamma_size);
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index d80fc3bbb450..d1cf4c038180 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -447,8 +447,8 @@ to_vc4_encoder(struct drm_encoder *encoder)
}
struct vc4_crtc_data {
- /* Which channel of the HVS this pixelvalve sources from. */
- int hvs_channel;
+ /* Which output of the HVS this pixelvalve sources from. */
+ int hvs_output;
};
struct vc4_pv_data {
diff --git a/drivers/gpu/drm/vc4/vc4_hvs.c b/drivers/gpu/drm/vc4/vc4_hvs.c
index abdb43c4cc10..365425d67f3f 100644
--- a/drivers/gpu/drm/vc4/vc4_hvs.c
+++ b/drivers/gpu/drm/vc4/vc4_hvs.c
@@ -419,7 +419,7 @@ void vc4_hvs_mode_set_nofb(struct drm_crtc *crtc)
struct drm_display_mode *mode = &crtc->state->adjusted_mode;
bool interlace = mode->flags & DRM_MODE_FLAG_INTERLACE;
- if (vc4_crtc->data->hvs_channel == 2) {
+ if (vc4_crtc->data->hvs_output == 2) {
u32 dispctrl;
u32 dsp3_mux;
diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
index a7c3af0005a0..f39d9900d027 100644
--- a/drivers/gpu/drm/vc4/vc4_txp.c
+++ b/drivers/gpu/drm/vc4/vc4_txp.c
@@ -452,7 +452,7 @@ static irqreturn_t vc4_txp_interrupt(int irq, void *data)
}
static const struct vc4_crtc_data vc4_txp_crtc_data = {
- .hvs_channel = 2,
+ .hvs_output = 2,
};
static int vc4_txp_bind(struct device *dev, struct device *master, void *data)
--
git-series 0.9.1
From: Dave Stevenson <[email protected]>
The current code is using the maximum of the source line size and the
destination line size to compute the size of the LBM to allocate.
While this is simpler, it starts to be an issue with modes such as 4k with
a quite long that will consume all the available memory, so we no longer
have that luxury.
Tested-by: Chanwoo Choi <[email protected]>
Tested-by: Hoegeun Kwon <[email protected]>
Tested-by: Stefan Wahren <[email protected]>
Signed-off-by: Dave Stevenson <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
---
drivers/gpu/drm/vc4/vc4_plane.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index d0771ebd5f75..23916814b4e3 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -437,10 +437,7 @@ static void vc4_write_ppf(struct vc4_plane_state *vc4_state, u32 src, u32 dst)
static u32 vc4_lbm_size(struct drm_plane_state *state)
{
struct vc4_plane_state *vc4_state = to_vc4_plane_state(state);
- /* This is the worst case number. One of the two sizes will
- * be used depending on the scaling configuration.
- */
- u32 pix_per_line = max(vc4_state->src_w[0], (u32)vc4_state->crtc_w);
+ u32 pix_per_line;
u32 lbm;
/* LBM is not needed when there's no vertical scaling. */
@@ -448,6 +445,18 @@ static u32 vc4_lbm_size(struct drm_plane_state *state)
vc4_state->y_scaling[1] == VC4_SCALING_NONE)
return 0;
+ /*
+ * This can be further optimized in the RGB/YUV444 case if the PPF
+ * decimation factor is between 0.5 and 1.0 by using crtc_w.
+ *
+ * It's not an issue though, since in that case since src_w[0] is going
+ * to be greater than or equal to crtc_w.
+ */
+ if (vc4_state->x_scaling[0] == VC4_SCALING_TPZ)
+ pix_per_line = vc4_state->crtc_w;
+ else
+ pix_per_line = vc4_state->src_w[0];
+
if (!vc4_state->is_yuv) {
if (vc4_state->y_scaling[0] == VC4_SCALING_TPZ)
lbm = pix_per_line * 8;
--
git-series 0.9.1
The vc4 atomic commit loop has an handrolled loop that is basically
identical to for_each_new_crtc_state, let's convert it to that helper.
Tested-by: Chanwoo Choi <[email protected]>
Tested-by: Hoegeun Kwon <[email protected]>
Tested-by: Stefan Wahren <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
---
drivers/gpu/drm/vc4/vc4_kms.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 210cc2408087..a41d105d4e3c 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -152,14 +152,16 @@ vc4_atomic_complete_commit(struct drm_atomic_state *state)
struct drm_device *dev = state->dev;
struct vc4_dev *vc4 = to_vc4_dev(dev);
struct vc4_hvs *hvs = vc4->hvs;
- struct vc4_crtc *vc4_crtc;
+ struct drm_crtc_state *new_crtc_state;
+ struct drm_crtc *crtc;
int i;
- for (i = 0; i < dev->mode_config.num_crtc; i++) {
- if (!state->crtcs[i].ptr || !state->crtcs[i].commit)
+ for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
+ struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
+
+ if (!new_crtc_state->commit)
continue;
- vc4_crtc = to_vc4_crtc(state->crtcs[i].ptr);
vc4_hvs_mask_underrun(dev, vc4_crtc->channel);
}
--
git-series 0.9.1
The HVS found in the BCM2711 is slightly different from the previous
generations, let's add a compatible for it.
Reviewed-by: Eric Anholt <[email protected]>
Tested-by: Chanwoo Choi <[email protected]>
Tested-by: Hoegeun Kwon <[email protected]>
Tested-by: Stefan Wahren <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>
---
Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml | 18 ++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml
index 02410f8d6d49..e826ab0adb75 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml
@@ -11,7 +11,9 @@ maintainers:
properties:
compatible:
- const: brcm,bcm2835-hvs
+ enum:
+ - brcm,bcm2711-hvs
+ - brcm,bcm2835-hvs
reg:
maxItems: 1
@@ -19,6 +21,10 @@ properties:
interrupts:
maxItems: 1
+ clocks:
+ maxItems: 1
+ description: Core Clock
+
required:
- compatible
- reg
@@ -26,6 +32,16 @@ required:
additionalProperties: false
+if:
+ properties:
+ compatible:
+ contains:
+ const: brcm,bcm2711-hvs"
+
+then:
+ required:
+ - clocks
+
examples:
- |
hvs@7e400000 {
--
git-series 0.9.1
Hi Maxime,
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
I decompile bcm2711-rpi-4-b.dtb. Both hdmi@7ef00700 and hdmi@7ef05700
show the clocks member.
hdmi@7ef00700 {
compatible = "brcm,bcm2711-hdmi0";
reg = <0x7ef00700 0x300 0x7ef00300 0x200 0x7ef00f00 0x80
0x7ef00f80 0x80 0x7ef01b00 0x200 0x7ef01f00 0x400 0x7ef00200 0x80
0x7ef04300 0x100 0x7ef20000 0x100>;
reg-names = "hdmi\0dvp\0phy\0rm\0packet\0metadata\0csc\0cec\0hd";
clock-names = "hdmi\0bvb\0audio\0cec";
resets = <0x17 0x00>;
ddc = <0x18>;
dmas = <0x19 0x0a>;
dma-names = "audio-rx";
status = "okay";
clocks = <0x10 0x0d 0x10 0x0e 0x17 0x00 0x1a>;
};
hdmi@7ef05700 {
compatible = "brcm,bcm2711-hdmi1";
reg = <0x7ef05700 0x300 0x7ef05300 0x200 0x7ef05f00 0x80
0x7ef05f80 0x80 0x7ef06b00 0x200 0x7ef06f00 0x400 0x7ef00280 0x80
0x7ef09300 0x100 0x7ef20000 0x100>;
reg-names = "hdmi\0dvp\0phy\0rm\0packet\0metadata\0csc\0cec\0hd";
ddc = <0x1b>;
clock-names = "hdmi\0bvb\0audio\0cec";
resets = <0x17 0x01>;
dmas = <0x19 0x11>;
dma-names = "audio-rx";
status = "okay";
clocks = <0x10 0x0d 0x10 0x0e 0x17 0x01 0x1a>;
};
Also re-check runtime device tree, they are the same values as mentioned above:
$ xxd /proc/device-tree/soc/hdmi@7ef00700/clocks
00000000: 0000 0010 0000 000d 0000 0010 0000 000e ................
00000010: 0000 0017 0000 0000 0000 001a ............
$ xxd /proc/device-tree/soc/hdmi@7ef05700/clocks
00000000: 0000 0010 0000 000d 0000 0010 0000 000e ................
00000010: 0000 0017 0000 0001 0000 001a ............
Do I miss something?
[1]: https://gist.github.com/starnight/649ea5a8384313f0354aca504f78ad70#file-config
[2]: https://gist.github.com/starnight/649ea5a8384313f0354aca504f78ad70#file-dmesg-log
Jian-Hong Pan
Hi Maxime
On Thu, 3 Sep 2020 at 09:02, Maxime Ripard <[email protected]> wrote:
>
> The vc4 atomic commit loop has an handrolled loop that is basically
> identical to for_each_new_crtc_state, let's convert it to that helper.
>
> Tested-by: Chanwoo Choi <[email protected]>
> Tested-by: Hoegeun Kwon <[email protected]>
> Tested-by: Stefan Wahren <[email protected]>
> Signed-off-by: Maxime Ripard <[email protected]>
Based on your comment to the previous revision, I'm happy.
Reviewed-by: Dave Stevenson <[email protected]>
> ---
> drivers/gpu/drm/vc4/vc4_kms.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
> index 210cc2408087..a41d105d4e3c 100644
> --- a/drivers/gpu/drm/vc4/vc4_kms.c
> +++ b/drivers/gpu/drm/vc4/vc4_kms.c
> @@ -152,14 +152,16 @@ vc4_atomic_complete_commit(struct drm_atomic_state *state)
> struct drm_device *dev = state->dev;
> struct vc4_dev *vc4 = to_vc4_dev(dev);
> struct vc4_hvs *hvs = vc4->hvs;
> - struct vc4_crtc *vc4_crtc;
> + struct drm_crtc_state *new_crtc_state;
> + struct drm_crtc *crtc;
> int i;
>
> - for (i = 0; i < dev->mode_config.num_crtc; i++) {
> - if (!state->crtcs[i].ptr || !state->crtcs[i].commit)
> + for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
> + struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
> +
> + if (!new_crtc_state->commit)
> continue;
>
> - vc4_crtc = to_vc4_crtc(state->crtcs[i].ptr);
> vc4_hvs_mask_underrun(dev, vc4_crtc->channel);
> }
>
> --
> git-series 0.9.1
Hi Maxime,
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: [email protected]
> Cc: [email protected]
> Cc: Kamal Dasu <[email protected]>
> Cc: Philipp Zabel <[email protected]>
> Cc: Rob Herring <[email protected]>
> Cc: Stephen Boyd <[email protected]>
>
> 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.
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].
Do you have any other settings? For example in config.txt.
[1] https://lkml.org/lkml/2020/9/2/566
> - Fixed typos in commit logs (thanks Dave!)
> - Split the csc setup hook into its own patch again
> - Added the CEC clock to the DT binding
> - Fixed the DT binding example
> - Reduced the number of calls to of_device_is_compatible in vc4_kms_load
> - Added back the check for the state commit in our commit hook
Best regards,
Hoegeun
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/[email protected]/
Maxime
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
Hi Maxime,
On Mon, 2020-09-07 at 18:22 +0200, Maxime Ripard wrote:
> 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?
I'll take care of it tomorrow.
Regards,
Nicolas
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: [email protected]
> > Cc: [email protected]
> > Cc: Kamal Dasu <[email protected]>
> > Cc: Philipp Zabel <[email protected]>
> > Cc: Rob Herring <[email protected]>
> > Cc: Stephen Boyd <[email protected]>
> >
> > 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
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: [email protected]
>>> Cc: [email protected]
>>> Cc: Kamal Dasu <[email protected]>
>>> Cc: Philipp Zabel <[email protected]>
>>> Cc: Rob Herring <[email protected]>
>>> Cc: Stephen Boyd <[email protected]>
>>>
>>> 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
Best regards,
Hoegeun
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: [email protected]
> >>> Cc: [email protected]
> >>> Cc: Kamal Dasu <[email protected]>
> >>> Cc: Philipp Zabel <[email protected]>
> >>> Cc: Rob Herring <[email protected]>
> >>> Cc: Stephen Boyd <[email protected]>
> >>>
> >>> 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
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: [email protected]
> > >>> Cc: [email protected]
> > >>> Cc: Kamal Dasu <[email protected]>
> > >>> Cc: Philipp Zabel <[email protected]>
> > >>> Cc: Rob Herring <[email protected]>
> > >>> Cc: Stephen Boyd <[email protected]>
> > >>>
> > >>> 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 :)
It took a bit longer than expected but the last 4 patches I just sent
should fix that issue
Thanks for reporting it!
Maxime