linux-clk.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipeline
@ 2020-04-24 15:33 Maxime Ripard
  2020-04-24 15:33 ` [PATCH v2 03/91] dt-bindings: clock: Add a binding for the RPi Firmware clocks Maxime Ripard
                   ` (18 more replies)
  0 siblings, 19 replies; 49+ messages in thread
From: Maxime Ripard @ 2020-04-24 15:33 UTC (permalink / raw)
  To: Nicolas Saenz Julienne, Eric Anholt
  Cc: dri-devel, linux-rpi-kernel, bcm-kernel-feedback-list,
	linux-arm-kernel, linux-kernel, Dave Stevenson, Tim Gover,
	Phil Elwell, Maxime Ripard, devicetree, Kamal Dasu, linux-clk,
	linux-i2c, Michael Turquette, Philipp Zabel, Rob Herring,
	Stephen Boyd, Wolfram Sang

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 output has
been tested too). There's a couple of rough edges still that should be
addressed in the next versions:
  - After a modeset, it's likely that the pixels will be shifted by one.
  - Dual output doesn't work
  - The transposer (and thus writeback) doesn't work either and conflicts
    with the output mux too.

Let me know if you have any comments
Maxime

Cc: bcm-kernel-feedback-list@broadcom.com
Cc: devicetree@vger.kernel.org
Cc: Kamal Dasu <kdasu.kdev@gmail.com>
Cc: linux-clk@vger.kernel.org
Cc: linux-i2c@vger.kernel.org
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Wolfram Sang <wsa@the-dreams.de>

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 (6):
  drm/vc4: Add support for the BCM2711 HVS5
  drm/vc4: plane: Improve LBM usage
  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

Florian Fainelli (1):
  dt-bindings: arm: bcm: Convert BCM2835 firmware binding to YAML

Maxime Ripard (84):
  i2c: brcmstb: Allow to compile it on BCM2835
  dt-bindings: clock: Add a binding for the RPi Firmware clocks
  firmware: rpi: Only create clocks device if we don't have a node for it
  clk: bcm: rpi: Allow the driver to be probed by DT
  clk: bcm: rpi: Statically init clk_init_data
  clk: bcm: rpi: Use clk_hw_register for pllb_arm
  clk: bcm: rpi: Remove global pllb_arm clock pointer
  clk: bcm: rpi: Make sure pllb_arm is removed
  clk: bcm: rpi: Remove pllb_arm_lookup global pointer
  clk: bcm: rpi: Switch to clk_hw_register_clkdev
  clk: bcm: rpi: Make sure the clkdev lookup is removed
  clk: bcm: rpi: Create a data structure for the clocks
  clk: bcm: rpi: Add clock id to data
  clk: bcm: rpi: Pass the clocks data to the firmware function
  clk: bcm: rpi: Rename is_prepared function
  clk: bcm: rpi: Split pllb clock hooks
  clk: bcm: rpi: Make the PLLB registration function return a clk_hw
  clk: bcm: rpi: Add DT provider for the clocks
  clk: bcm: rpi: Discover the firmware clocks
  ARM: dts: bcm2711: Add firmware clocks node
  reset: Move reset-simple header out of drivers/reset
  reset: simple: Add reset callback
  dt-bindings: clock: Add BCM2711 DVP binding
  clk: bcm: Add BCM2711 DVP driver
  ARM: dts: bcm2711: Add HDMI DVP
  dt-bindings: display: Convert VC4 bindings to schemas
  dt-bindings: display: vc4: dpi: Add missing clock-names property
  dt-bindings: display: vc4: dsi: Add missing clock properties
  dt-bindings: display: vc4: hdmi: Add missing clock-names property
  dt-bindings: display: vc4: Document BCM2711 VC5
  drm/vc4: drv: Add include guards
  drm/vc4: drv: Support BCM2711
  dt-bindings: display: Add support for the BCM2711 HVS
  drm/vc4: hvs: Boost the core clock during modeset
  drm/vc4: plane: Move planes creation to its own function
  drm/vc4: plane: Move additional planes creation to driver
  drm/vc4: plane: Register all the planes at once
  drm/vc4: plane: Create overlays for any CRTC
  drm/vc4: plane: Create more planes
  drm/vc4: crtc: Rename SoC data structures
  drm/vc4: crtc: Move crtc state to common header
  drm/vc4: crtc: Deal with different number of pixel per clock
  drm/vc4: crtc: Use a shared interrupt
  drm/vc4: crtc: Turn static const variable into a define
  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: 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: Remove redundant call to drm_crtc_enable_color_mgmt
  drm/vc4: crtc: Disable color management for HVS5
  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: 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: 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: Support the BCM2711 HDMI controllers
  dt-bindings: display: vc4: hdmi: Add BCM2711 HDMI controllers bindings
  ARM: dts: bcm2711: Enable the display pipeline

 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt  |   14 +-
 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml |   59 +++-
 Documentation/devicetree/bindings/clock/brcm,bcm2711-dvp.yaml               |   47 ++-
 Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt                  |  174 +--------
 Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml            |  109 +++++-
 Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml             |   72 +++-
 Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml            |   84 ++++-
 Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml            |   80 ++++-
 Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml             |   53 ++-
 Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml     |   45 ++-
 Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml             |   37 ++-
 Documentation/devicetree/bindings/display/brcm,bcm2835-v3d.yaml             |   42 ++-
 Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml             |   35 ++-
 Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml             |   44 ++-
 MAINTAINERS                                                                 |    2 +-
 arch/arm/boot/dts/bcm2711-rpi-4-b.dts                                       |   51 ++-
 arch/arm/boot/dts/bcm2711.dtsi                                              |  130 +++++-
 drivers/clk/bcm/Kconfig                                                     |    1 +-
 drivers/clk/bcm/Makefile                                                    |    1 +-
 drivers/clk/bcm/clk-bcm2711-dvp.c                                           |  127 ++++++-
 drivers/clk/bcm/clk-raspberrypi.c                                           |  280 +++++++++----
 drivers/firmware/raspberrypi.c                                              |   17 +-
 drivers/gpu/drm/vc4/Makefile                                                |    1 +-
 drivers/gpu/drm/vc4/vc4_crtc.c                                              |  328 +++++++++------
 drivers/gpu/drm/vc4/vc4_drv.c                                               |    5 +-
 drivers/gpu/drm/vc4/vc4_drv.h                                               |   58 ++-
 drivers/gpu/drm/vc4/vc4_hdmi.c                                              | 1536 ++++++++++++++++++++++++++++++++++++++++++------------------------------
 drivers/gpu/drm/vc4/vc4_hdmi.h                                              |  179 ++++++++-
 drivers/gpu/drm/vc4/vc4_hdmi_phy.c                                          |  508 ++++++++++++++++++++++++-
 drivers/gpu/drm/vc4/vc4_hdmi_regs.h                                         |  451 +++++++++++++++++++++-
 drivers/gpu/drm/vc4/vc4_hvs.c                                               |   25 +-
 drivers/gpu/drm/vc4/vc4_kms.c                                               |  181 +++++++-
 drivers/gpu/drm/vc4/vc4_plane.c                                             |  271 +++++++++----
 drivers/gpu/drm/vc4/vc4_regs.h                                              |  173 +++-----
 drivers/i2c/busses/Kconfig                                                  |    4 +-
 drivers/reset/reset-simple.c                                                |   27 +-
 drivers/reset/reset-simple.h                                                |   41 +--
 drivers/reset/reset-socfpga.c                                               |    3 +-
 drivers/reset/reset-sunxi.c                                                 |    3 +-
 drivers/reset/reset-uniphier-glue.c                                         |    3 +-
 include/linux/reset/reset-simple.h                                          |   47 ++-
 include/soc/bcm2835/raspberrypi-firmware.h                                  |    5 +-
 42 files changed, 4109 insertions(+), 1244 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt
 create mode 100644 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
 create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm2711-dvp.yaml
 delete mode 100644 Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
 create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
 create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml
 create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml
 create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml
 create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml
 create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml
 create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml
 create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-v3d.yaml
 create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml
 create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml
 create mode 100644 drivers/clk/bcm/clk-bcm2711-dvp.c
 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
 delete mode 100644 drivers/reset/reset-simple.h
 create mode 100644 include/linux/reset/reset-simple.h

base-commit: cb3692197b5da2fb898335eec1640db14d92e52e
-- 
git-series 0.9.1

^ permalink raw reply	[flat|nested] 49+ messages in thread

* [PATCH v2 03/91] dt-bindings: clock: Add a binding for the RPi Firmware clocks
  2020-04-24 15:33 [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipeline Maxime Ripard
@ 2020-04-24 15:33 ` Maxime Ripard
  2020-05-11 21:47   ` Rob Herring
  2020-04-24 15:33 ` [PATCH v2 05/91] clk: bcm: rpi: Allow the driver to be probed by DT Maxime Ripard
                   ` (17 subsequent siblings)
  18 siblings, 1 reply; 49+ messages in thread
From: Maxime Ripard @ 2020-04-24 15:33 UTC (permalink / raw)
  To: Nicolas Saenz Julienne, Eric Anholt
  Cc: dri-devel, linux-rpi-kernel, bcm-kernel-feedback-list,
	linux-arm-kernel, linux-kernel, Dave Stevenson, Tim Gover,
	Phil Elwell, Maxime Ripard, Michael Turquette, Stephen Boyd,
	Rob Herring, linux-clk, devicetree

The firmware running on the RPi VideoCore can be used to discover and
change the various clocks running in the BCM2711. Since devices will
need to use them through the DT, let's add a pretty simple binding.

Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-clk@vger.kernel.org
Cc: devicetree@vger.kernel.org
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
 Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
index cec540c052b6..b48ed875eb8e 100644
--- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
@@ -22,6 +22,25 @@ properties:
       Phandle to the firmware device's Mailbox.
       (See: ../mailbox/mailbox.txt for more information)
 
+  clocks:
+    type: object
+
+    properties:
+      compatible:
+        const: raspberrypi,firmware-clocks
+
+      "#clock-cells":
+        const: 1
+        description: >
+          The argument is the ID of the clocks contained by the
+          firmware messages.
+
+    required:
+      - compatible
+      - "#clock-cells"
+
+    additionalProperties: false
+
 required:
   - compatible
   - mboxes
@@ -31,5 +50,10 @@ examples:
     firmware {
         compatible = "raspberrypi,bcm2835-firmware", "simple-bus";
         mboxes = <&mailbox>;
+
+        firmware_clocks: clocks {
+            compatible = "raspberrypi,firmware-clocks";
+            #clock-cells = <1>;
+        };
     };
 ...
-- 
git-series 0.9.1

^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH v2 05/91] clk: bcm: rpi: Allow the driver to be probed by DT
  2020-04-24 15:33 [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipeline Maxime Ripard
  2020-04-24 15:33 ` [PATCH v2 03/91] dt-bindings: clock: Add a binding for the RPi Firmware clocks Maxime Ripard
@ 2020-04-24 15:33 ` Maxime Ripard
  2020-04-30 16:19   ` Nicolas Saenz Julienne
  2020-04-24 15:33 ` [PATCH v2 06/91] clk: bcm: rpi: Statically init clk_init_data Maxime Ripard
                   ` (16 subsequent siblings)
  18 siblings, 1 reply; 49+ messages in thread
From: Maxime Ripard @ 2020-04-24 15:33 UTC (permalink / raw)
  To: Nicolas Saenz Julienne, Eric Anholt
  Cc: dri-devel, linux-rpi-kernel, bcm-kernel-feedback-list,
	linux-arm-kernel, linux-kernel, Dave Stevenson, Tim Gover,
	Phil Elwell, Maxime Ripard, Michael Turquette, Stephen Boyd,
	linux-clk

The current firmware clock driver for the RaspberryPi can only be probed by
manually registering an associated platform_device.

While this works fine for cpufreq where the device gets attached a clkdev
lookup, it would be tedious to maintain a table of all the devices using
one of the clocks exposed by the firmware.

Since the DT on the other hand is the perfect place to store those
associations, make the firmware clocks driver probe-able through the device
tree so that we can represent it as a node.

Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: linux-clk@vger.kernel.org
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
 drivers/clk/bcm/clk-raspberrypi.c | 20 +++++++++++++++++---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c
index 1654fd0eedc9..aedeaaf2f66b 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -255,15 +255,22 @@ static int raspberrypi_clk_probe(struct platform_device *pdev)
 	struct raspberrypi_clk *rpi;
 	int ret;
 
-	firmware_node = of_find_compatible_node(NULL, NULL,
-					"raspberrypi,bcm2835-firmware");
+	/*
+	 * We can be probed either through the an old-fashioned
+	 * platform device registration or through a DT node that is a
+	 * child of the firmware node. Handle both cases.
+	 */
+	if (dev->of_node)
+		firmware_node = of_get_parent(dev->of_node);
+	else
+		firmware_node = of_find_compatible_node(NULL, NULL,
+							"raspberrypi,bcm2835-firmware");
 	if (!firmware_node) {
 		dev_err(dev, "Missing firmware node\n");
 		return -ENOENT;
 	}
 
 	firmware = rpi_firmware_get(firmware_node);
-	of_node_put(firmware_node);
 	if (!firmware)
 		return -EPROBE_DEFER;
 
@@ -300,9 +307,16 @@ static int raspberrypi_clk_remove(struct platform_device *pdev)
 	return 0;
 }
 
+static const struct of_device_id raspberrypi_clk_match[] = {
+	{ .compatible = "raspberrypi,firmware-clocks" },
+	{ },
+};
+MODULE_DEVICE_TABLE(of, raspberrypi_clk_match);
+
 static struct platform_driver raspberrypi_clk_driver = {
 	.driver = {
 		.name = "raspberrypi-clk",
+		.of_match_table = raspberrypi_clk_match,
 	},
 	.probe          = raspberrypi_clk_probe,
 	.remove		= raspberrypi_clk_remove,
-- 
git-series 0.9.1

^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH v2 06/91] clk: bcm: rpi: Statically init clk_init_data
  2020-04-24 15:33 [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipeline Maxime Ripard
  2020-04-24 15:33 ` [PATCH v2 03/91] dt-bindings: clock: Add a binding for the RPi Firmware clocks Maxime Ripard
  2020-04-24 15:33 ` [PATCH v2 05/91] clk: bcm: rpi: Allow the driver to be probed by DT Maxime Ripard
@ 2020-04-24 15:33 ` Maxime Ripard
  2020-05-27  6:47   ` Stephen Boyd
  2020-04-24 15:33 ` [PATCH v2 07/91] clk: bcm: rpi: Use clk_hw_register for pllb_arm Maxime Ripard
                   ` (15 subsequent siblings)
  18 siblings, 1 reply; 49+ messages in thread
From: Maxime Ripard @ 2020-04-24 15:33 UTC (permalink / raw)
  To: Nicolas Saenz Julienne, Eric Anholt
  Cc: dri-devel, linux-rpi-kernel, bcm-kernel-feedback-list,
	linux-arm-kernel, linux-kernel, Dave Stevenson, Tim Gover,
	Phil Elwell, Maxime Ripard, Michael Turquette, Stephen Boyd,
	linux-clk

Instead of declaring the clk_init_data and then calling memset on it, just
initialise properly.

Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: linux-clk@vger.kernel.org
Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
 drivers/clk/bcm/clk-raspberrypi.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c
index aedeaaf2f66b..b6d2823c2882 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -175,11 +175,10 @@ static const struct clk_ops raspberrypi_firmware_pll_clk_ops = {
 
 static int raspberrypi_register_pllb(struct raspberrypi_clk *rpi)
 {
+	struct clk_init_data init = {};
 	u32 min_rate = 0, max_rate = 0;
-	struct clk_init_data init;
 	int ret;
 
-	memset(&init, 0, sizeof(init));
 
 	/* All of the PLLs derive from the external oscillator. */
 	init.parent_names = (const char *[]){ "osc" };
-- 
git-series 0.9.1

^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH v2 07/91] clk: bcm: rpi: Use clk_hw_register for pllb_arm
  2020-04-24 15:33 [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipeline Maxime Ripard
                   ` (2 preceding siblings ...)
  2020-04-24 15:33 ` [PATCH v2 06/91] clk: bcm: rpi: Statically init clk_init_data Maxime Ripard
@ 2020-04-24 15:33 ` Maxime Ripard
  2020-04-24 15:33 ` [PATCH v2 08/91] clk: bcm: rpi: Remove global pllb_arm clock pointer Maxime Ripard
                   ` (14 subsequent siblings)
  18 siblings, 0 replies; 49+ messages in thread
From: Maxime Ripard @ 2020-04-24 15:33 UTC (permalink / raw)
  To: Nicolas Saenz Julienne, Eric Anholt
  Cc: dri-devel, linux-rpi-kernel, bcm-kernel-feedback-list,
	linux-arm-kernel, linux-kernel, Dave Stevenson, Tim Gover,
	Phil Elwell, Maxime Ripard, Michael Turquette, linux-clk,
	Stephen Boyd

The pllb_arm clock is defined as a fixed factor clock with the pllb
clock as a parent. However, all its configuration is entirely static,
and thus we don't really need to call clk_hw_register_fixed_factor() but
can simply call clk_hw_register() with a static clk_fixed_factor
structure.

Cc: Michael Turquette <mturquette@baylibre.com>
Cc: linux-clk@vger.kernel.org
Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
 drivers/clk/bcm/clk-raspberrypi.c | 24 ++++++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c
index b6d2823c2882..3e9032b9a0a6 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -225,16 +225,28 @@ static int raspberrypi_register_pllb(struct raspberrypi_clk *rpi)
 	return devm_clk_hw_register(rpi->dev, &rpi->pllb);
 }
 
+static struct clk_fixed_factor raspberrypi_clk_pllb_arm = {
+	.mult = 1,
+	.div = 2,
+	.hw.init = &(struct clk_init_data) {
+		.name		= "pllb_arm",
+		.parent_names	= (const char *[]){ "pllb" },
+		.num_parents	= 1,
+		.ops		= &clk_fixed_factor_ops,
+		.flags		= CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE,
+	},
+};
+
 static int raspberrypi_register_pllb_arm(struct raspberrypi_clk *rpi)
 {
-	rpi->pllb_arm = clk_hw_register_fixed_factor(rpi->dev,
-				"pllb_arm", "pllb",
-				CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE,
-				1, 2);
-	if (IS_ERR(rpi->pllb_arm)) {
+	int ret;
+
+	ret = clk_hw_register(rpi->dev, &raspberrypi_clk_pllb_arm.hw);
+	if (ret) {
 		dev_err(rpi->dev, "Failed to initialize pllb_arm\n");
-		return PTR_ERR(rpi->pllb_arm);
+		return ret;
 	}
+	rpi->pllb_arm = &raspberrypi_clk_pllb_arm.hw;
 
 	rpi->pllb_arm_lookup = clkdev_hw_create(rpi->pllb_arm, NULL, "cpu0");
 	if (!rpi->pllb_arm_lookup) {
-- 
git-series 0.9.1

^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH v2 08/91] clk: bcm: rpi: Remove global pllb_arm clock pointer
  2020-04-24 15:33 [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipeline Maxime Ripard
                   ` (3 preceding siblings ...)
  2020-04-24 15:33 ` [PATCH v2 07/91] clk: bcm: rpi: Use clk_hw_register for pllb_arm Maxime Ripard
@ 2020-04-24 15:33 ` Maxime Ripard
  2020-05-27  6:48   ` Stephen Boyd
  2020-04-24 15:33 ` [PATCH v2 09/91] clk: bcm: rpi: Make sure pllb_arm is removed Maxime Ripard
                   ` (13 subsequent siblings)
  18 siblings, 1 reply; 49+ messages in thread
From: Maxime Ripard @ 2020-04-24 15:33 UTC (permalink / raw)
  To: Nicolas Saenz Julienne, Eric Anholt
  Cc: dri-devel, linux-rpi-kernel, bcm-kernel-feedback-list,
	linux-arm-kernel, linux-kernel, Dave Stevenson, Tim Gover,
	Phil Elwell, Maxime Ripard, Michael Turquette, Stephen Boyd,
	linux-clk

The pllb_arm clk_hw pointer in the raspberry_clk structure isn't used
anywhere but in the raspberrypi_register_pllb_arm.

Let's remove it, this will make our lives easier in future patches.

Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: linux-clk@vger.kernel.org
Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
 drivers/clk/bcm/clk-raspberrypi.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c
index 3e9032b9a0a6..a99e8189311f 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -40,7 +40,6 @@ struct raspberrypi_clk {
 	unsigned long max_rate;
 
 	struct clk_hw pllb;
-	struct clk_hw *pllb_arm;
 	struct clk_lookup *pllb_arm_lookup;
 };
 
@@ -246,12 +245,12 @@ static int raspberrypi_register_pllb_arm(struct raspberrypi_clk *rpi)
 		dev_err(rpi->dev, "Failed to initialize pllb_arm\n");
 		return ret;
 	}
-	rpi->pllb_arm = &raspberrypi_clk_pllb_arm.hw;
 
-	rpi->pllb_arm_lookup = clkdev_hw_create(rpi->pllb_arm, NULL, "cpu0");
+	rpi->pllb_arm_lookup = clkdev_hw_create(&raspberrypi_clk_pllb_arm.hw,
+						NULL, "cpu0");
 	if (!rpi->pllb_arm_lookup) {
 		dev_err(rpi->dev, "Failed to initialize pllb_arm_lookup\n");
-		clk_hw_unregister_fixed_factor(rpi->pllb_arm);
+		clk_hw_unregister_fixed_factor(&raspberrypi_clk_pllb_arm.hw);
 		return -ENOMEM;
 	}
 
-- 
git-series 0.9.1

^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH v2 09/91] clk: bcm: rpi: Make sure pllb_arm is removed
  2020-04-24 15:33 [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipeline Maxime Ripard
                   ` (4 preceding siblings ...)
  2020-04-24 15:33 ` [PATCH v2 08/91] clk: bcm: rpi: Remove global pllb_arm clock pointer Maxime Ripard
@ 2020-04-24 15:33 ` Maxime Ripard
  2020-05-27  6:48   ` Stephen Boyd
  2020-04-24 15:33 ` [PATCH v2 10/91] clk: bcm: rpi: Remove pllb_arm_lookup global pointer Maxime Ripard
                   ` (12 subsequent siblings)
  18 siblings, 1 reply; 49+ messages in thread
From: Maxime Ripard @ 2020-04-24 15:33 UTC (permalink / raw)
  To: Nicolas Saenz Julienne, Eric Anholt
  Cc: dri-devel, linux-rpi-kernel, bcm-kernel-feedback-list,
	linux-arm-kernel, linux-kernel, Dave Stevenson, Tim Gover,
	Phil Elwell, Maxime Ripard, Michael Turquette, linux-clk,
	Stephen Boyd

The pllb_arm clock was created at probe time, but was never removed if
something went wrong later in probe, or if the driver was ever removed from
the system.

Now that we are using clk_hw_register, we can just use its managed variant
to take care of that for us.

Cc: Michael Turquette <mturquette@baylibre.com>
Cc: linux-clk@vger.kernel.org
Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
 drivers/clk/bcm/clk-raspberrypi.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c
index a99e8189311f..859eac020122 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -240,7 +240,7 @@ static int raspberrypi_register_pllb_arm(struct raspberrypi_clk *rpi)
 {
 	int ret;
 
-	ret = clk_hw_register(rpi->dev, &raspberrypi_clk_pllb_arm.hw);
+	ret = devm_clk_hw_register(rpi->dev, &raspberrypi_clk_pllb_arm.hw);
 	if (ret) {
 		dev_err(rpi->dev, "Failed to initialize pllb_arm\n");
 		return ret;
@@ -250,7 +250,6 @@ static int raspberrypi_register_pllb_arm(struct raspberrypi_clk *rpi)
 						NULL, "cpu0");
 	if (!rpi->pllb_arm_lookup) {
 		dev_err(rpi->dev, "Failed to initialize pllb_arm_lookup\n");
-		clk_hw_unregister_fixed_factor(&raspberrypi_clk_pllb_arm.hw);
 		return -ENOMEM;
 	}
 
-- 
git-series 0.9.1

^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH v2 10/91] clk: bcm: rpi: Remove pllb_arm_lookup global pointer
  2020-04-24 15:33 [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipeline Maxime Ripard
                   ` (5 preceding siblings ...)
  2020-04-24 15:33 ` [PATCH v2 09/91] clk: bcm: rpi: Make sure pllb_arm is removed Maxime Ripard
@ 2020-04-24 15:33 ` Maxime Ripard
  2020-04-24 15:33 ` [PATCH v2 11/91] clk: bcm: rpi: Switch to clk_hw_register_clkdev Maxime Ripard
                   ` (11 subsequent siblings)
  18 siblings, 0 replies; 49+ messages in thread
From: Maxime Ripard @ 2020-04-24 15:33 UTC (permalink / raw)
  To: Nicolas Saenz Julienne, Eric Anholt
  Cc: dri-devel, linux-rpi-kernel, bcm-kernel-feedback-list,
	linux-arm-kernel, linux-kernel, Dave Stevenson, Tim Gover,
	Phil Elwell, Maxime Ripard, Michael Turquette, linux-clk,
	Stephen Boyd

The pllb_arm_lookup pointer in the struct raspberrypi_clk is not used for
anything but to store the returned pointer to clkdev_hw_create, and is not
used anywhere else in the driver.

Let's remove that global pointer from the structure.

Cc: Michael Turquette <mturquette@baylibre.com>
Cc: linux-clk@vger.kernel.org
Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
 drivers/clk/bcm/clk-raspberrypi.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c
index 859eac020122..5bed35483e71 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -40,7 +40,6 @@ struct raspberrypi_clk {
 	unsigned long max_rate;
 
 	struct clk_hw pllb;
-	struct clk_lookup *pllb_arm_lookup;
 };
 
 /*
@@ -238,6 +237,7 @@ static struct clk_fixed_factor raspberrypi_clk_pllb_arm = {
 
 static int raspberrypi_register_pllb_arm(struct raspberrypi_clk *rpi)
 {
+	struct clk_lookup *pllb_arm_lookup;
 	int ret;
 
 	ret = devm_clk_hw_register(rpi->dev, &raspberrypi_clk_pllb_arm.hw);
@@ -246,9 +246,9 @@ static int raspberrypi_register_pllb_arm(struct raspberrypi_clk *rpi)
 		return ret;
 	}
 
-	rpi->pllb_arm_lookup = clkdev_hw_create(&raspberrypi_clk_pllb_arm.hw,
-						NULL, "cpu0");
-	if (!rpi->pllb_arm_lookup) {
+	pllb_arm_lookup = clkdev_hw_create(&raspberrypi_clk_pllb_arm.hw,
+					   NULL, "cpu0");
+	if (!pllb_arm_lookup) {
 		dev_err(rpi->dev, "Failed to initialize pllb_arm_lookup\n");
 		return -ENOMEM;
 	}
-- 
git-series 0.9.1

^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH v2 11/91] clk: bcm: rpi: Switch to clk_hw_register_clkdev
  2020-04-24 15:33 [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipeline Maxime Ripard
                   ` (6 preceding siblings ...)
  2020-04-24 15:33 ` [PATCH v2 10/91] clk: bcm: rpi: Remove pllb_arm_lookup global pointer Maxime Ripard
@ 2020-04-24 15:33 ` Maxime Ripard
  2020-04-24 15:33 ` [PATCH v2 12/91] clk: bcm: rpi: Make sure the clkdev lookup is removed Maxime Ripard
                   ` (10 subsequent siblings)
  18 siblings, 0 replies; 49+ messages in thread
From: Maxime Ripard @ 2020-04-24 15:33 UTC (permalink / raw)
  To: Nicolas Saenz Julienne, Eric Anholt
  Cc: dri-devel, linux-rpi-kernel, bcm-kernel-feedback-list,
	linux-arm-kernel, linux-kernel, Dave Stevenson, Tim Gover,
	Phil Elwell, Maxime Ripard, Michael Turquette, linux-clk,
	Stephen Boyd

Since we don't care about retrieving the clk_lookup structure pointer
returned by clkdev_hw_create, we can just use the clk_hw_register_clkdev
function.

Cc: Michael Turquette <mturquette@baylibre.com>
Cc: linux-clk@vger.kernel.org
Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
 drivers/clk/bcm/clk-raspberrypi.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c
index 5bed35483e71..013706816895 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -237,7 +237,6 @@ static struct clk_fixed_factor raspberrypi_clk_pllb_arm = {
 
 static int raspberrypi_register_pllb_arm(struct raspberrypi_clk *rpi)
 {
-	struct clk_lookup *pllb_arm_lookup;
 	int ret;
 
 	ret = devm_clk_hw_register(rpi->dev, &raspberrypi_clk_pllb_arm.hw);
@@ -246,11 +245,11 @@ static int raspberrypi_register_pllb_arm(struct raspberrypi_clk *rpi)
 		return ret;
 	}
 
-	pllb_arm_lookup = clkdev_hw_create(&raspberrypi_clk_pllb_arm.hw,
-					   NULL, "cpu0");
-	if (!pllb_arm_lookup) {
-		dev_err(rpi->dev, "Failed to initialize pllb_arm_lookup\n");
-		return -ENOMEM;
+	ret = clk_hw_register_clkdev(&raspberrypi_clk_pllb_arm.hw,
+				     NULL, "cpu0");
+	if (ret) {
+		dev_err(rpi->dev, "Failed to initialize clkdev\n");
+		return ret;
 	}
 
 	return 0;
-- 
git-series 0.9.1

^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH v2 12/91] clk: bcm: rpi: Make sure the clkdev lookup is removed
  2020-04-24 15:33 [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipeline Maxime Ripard
                   ` (7 preceding siblings ...)
  2020-04-24 15:33 ` [PATCH v2 11/91] clk: bcm: rpi: Switch to clk_hw_register_clkdev Maxime Ripard
@ 2020-04-24 15:33 ` Maxime Ripard
  2020-04-24 15:33 ` [PATCH v2 13/91] clk: bcm: rpi: Create a data structure for the clocks Maxime Ripard
                   ` (9 subsequent siblings)
  18 siblings, 0 replies; 49+ messages in thread
From: Maxime Ripard @ 2020-04-24 15:33 UTC (permalink / raw)
  To: Nicolas Saenz Julienne, Eric Anholt
  Cc: dri-devel, linux-rpi-kernel, bcm-kernel-feedback-list,
	linux-arm-kernel, linux-kernel, Dave Stevenson, Tim Gover,
	Phil Elwell, Maxime Ripard, Michael Turquette, linux-clk,
	Stephen Boyd

The clkdev lookup created for the cpufreq device is never removed if
there's an issue later in probe or at module removal time.

Let's convert to the managed variant of the clk_hw_register_clkdev function
to make sure it happens.

Cc: Michael Turquette <mturquette@baylibre.com>
Cc: linux-clk@vger.kernel.org
Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
 drivers/clk/bcm/clk-raspberrypi.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c
index 013706816895..eb5c4f5720e8 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -245,8 +245,9 @@ static int raspberrypi_register_pllb_arm(struct raspberrypi_clk *rpi)
 		return ret;
 	}
 
-	ret = clk_hw_register_clkdev(&raspberrypi_clk_pllb_arm.hw,
-				     NULL, "cpu0");
+	ret = devm_clk_hw_register_clkdev(rpi->dev,
+					  &raspberrypi_clk_pllb_arm.hw,
+					  NULL, "cpu0");
 	if (ret) {
 		dev_err(rpi->dev, "Failed to initialize clkdev\n");
 		return ret;
-- 
git-series 0.9.1

^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH v2 13/91] clk: bcm: rpi: Create a data structure for the clocks
  2020-04-24 15:33 [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipeline Maxime Ripard
                   ` (8 preceding siblings ...)
  2020-04-24 15:33 ` [PATCH v2 12/91] clk: bcm: rpi: Make sure the clkdev lookup is removed Maxime Ripard
@ 2020-04-24 15:33 ` Maxime Ripard
  2020-04-24 15:33 ` [PATCH v2 14/91] clk: bcm: rpi: Add clock id to data Maxime Ripard
                   ` (8 subsequent siblings)
  18 siblings, 0 replies; 49+ messages in thread
From: Maxime Ripard @ 2020-04-24 15:33 UTC (permalink / raw)
  To: Nicolas Saenz Julienne, Eric Anholt
  Cc: dri-devel, linux-rpi-kernel, bcm-kernel-feedback-list,
	linux-arm-kernel, linux-kernel, Dave Stevenson, Tim Gover,
	Phil Elwell, Maxime Ripard, Michael Turquette, linux-clk,
	Stephen Boyd

So far the driver has really only been providing a single clock, and stored
both the data associated to that clock in particular with the data
associated to the "controller".

Since we will change that in the future, let's decouple the clock data from
the provider data.

Cc: Michael Turquette <mturquette@baylibre.com>
Cc: linux-clk@vger.kernel.org
Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
 drivers/clk/bcm/clk-raspberrypi.c | 40 ++++++++++++++++++++------------
 1 file changed, 26 insertions(+), 14 deletions(-)

diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c
index eb5c4f5720e8..75197d8574cf 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -35,11 +35,15 @@ struct raspberrypi_clk {
 	struct device *dev;
 	struct rpi_firmware *firmware;
 	struct platform_device *cpufreq;
+};
+
+struct raspberrypi_clk_data {
+	struct clk_hw hw;
 
 	unsigned long min_rate;
 	unsigned long max_rate;
 
-	struct clk_hw pllb;
+	struct raspberrypi_clk *rpi;
 };
 
 /*
@@ -83,8 +87,9 @@ static int raspberrypi_clock_property(struct rpi_firmware *firmware, u32 tag,
 
 static int raspberrypi_fw_pll_is_on(struct clk_hw *hw)
 {
-	struct raspberrypi_clk *rpi = container_of(hw, struct raspberrypi_clk,
-						   pllb);
+	struct raspberrypi_clk_data *data =
+		container_of(hw, struct raspberrypi_clk_data, hw);
+	struct raspberrypi_clk *rpi = data->rpi;
 	u32 val = 0;
 	int ret;
 
@@ -101,8 +106,9 @@ static int raspberrypi_fw_pll_is_on(struct clk_hw *hw)
 static unsigned long raspberrypi_fw_pll_get_rate(struct clk_hw *hw,
 						 unsigned long parent_rate)
 {
-	struct raspberrypi_clk *rpi = container_of(hw, struct raspberrypi_clk,
-						   pllb);
+	struct raspberrypi_clk_data *data =
+		container_of(hw, struct raspberrypi_clk_data, hw);
+	struct raspberrypi_clk *rpi = data->rpi;
 	u32 val = 0;
 	int ret;
 
@@ -119,8 +125,9 @@ static unsigned long raspberrypi_fw_pll_get_rate(struct clk_hw *hw,
 static int raspberrypi_fw_pll_set_rate(struct clk_hw *hw, unsigned long rate,
 				       unsigned long parent_rate)
 {
-	struct raspberrypi_clk *rpi = container_of(hw, struct raspberrypi_clk,
-						   pllb);
+	struct raspberrypi_clk_data *data =
+		container_of(hw, struct raspberrypi_clk_data, hw);
+	struct raspberrypi_clk *rpi = data->rpi;
 	u32 new_rate = rate / RPI_FIRMWARE_PLLB_ARM_DIV_RATE;
 	int ret;
 
@@ -142,13 +149,13 @@ static int raspberrypi_fw_pll_set_rate(struct clk_hw *hw, unsigned long rate,
 static int raspberrypi_pll_determine_rate(struct clk_hw *hw,
 					  struct clk_rate_request *req)
 {
-	struct raspberrypi_clk *rpi = container_of(hw, struct raspberrypi_clk,
-						   pllb);
+	struct raspberrypi_clk_data *data =
+		container_of(hw, struct raspberrypi_clk_data, hw);
 	u64 div, final_rate;
 	u32 ndiv, fdiv;
 
 	/* We can't use req->rate directly as it would overflow */
-	final_rate = clamp(req->rate, rpi->min_rate, rpi->max_rate);
+	final_rate = clamp(req->rate, data->min_rate, data->max_rate);
 
 	div = (u64)final_rate << A2W_PLL_FRAC_BITS;
 	do_div(div, req->best_parent_rate);
@@ -173,10 +180,15 @@ static const struct clk_ops raspberrypi_firmware_pll_clk_ops = {
 
 static int raspberrypi_register_pllb(struct raspberrypi_clk *rpi)
 {
+	struct raspberrypi_clk_data *data;
 	struct clk_init_data init = {};
 	u32 min_rate = 0, max_rate = 0;
 	int ret;
 
+	data = devm_kzalloc(rpi->dev, sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+	data->rpi = rpi;
 
 	/* All of the PLLs derive from the external oscillator. */
 	init.parent_names = (const char *[]){ "osc" };
@@ -215,12 +227,12 @@ static int raspberrypi_register_pllb(struct raspberrypi_clk *rpi)
 	dev_info(rpi->dev, "CPU frequency range: min %u, max %u\n",
 		 min_rate, max_rate);
 
-	rpi->min_rate = min_rate * RPI_FIRMWARE_PLLB_ARM_DIV_RATE;
-	rpi->max_rate = max_rate * RPI_FIRMWARE_PLLB_ARM_DIV_RATE;
+	data->min_rate = min_rate * RPI_FIRMWARE_PLLB_ARM_DIV_RATE;
+	data->max_rate = max_rate * RPI_FIRMWARE_PLLB_ARM_DIV_RATE;
 
-	rpi->pllb.init = &init;
+	data->hw.init = &init;
 
-	return devm_clk_hw_register(rpi->dev, &rpi->pllb);
+	return devm_clk_hw_register(rpi->dev, &data->hw);
 }
 
 static struct clk_fixed_factor raspberrypi_clk_pllb_arm = {
-- 
git-series 0.9.1

^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH v2 14/91] clk: bcm: rpi: Add clock id to data
  2020-04-24 15:33 [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipeline Maxime Ripard
                   ` (9 preceding siblings ...)
  2020-04-24 15:33 ` [PATCH v2 13/91] clk: bcm: rpi: Create a data structure for the clocks Maxime Ripard
@ 2020-04-24 15:33 ` Maxime Ripard
  2020-04-24 15:33 ` [PATCH v2 15/91] clk: bcm: rpi: Pass the clocks data to the firmware function Maxime Ripard
                   ` (7 subsequent siblings)
  18 siblings, 0 replies; 49+ messages in thread
From: Maxime Ripard @ 2020-04-24 15:33 UTC (permalink / raw)
  To: Nicolas Saenz Julienne, Eric Anholt
  Cc: dri-devel, linux-rpi-kernel, bcm-kernel-feedback-list,
	linux-arm-kernel, linux-kernel, Dave Stevenson, Tim Gover,
	Phil Elwell, Maxime Ripard, Michael Turquette, linux-clk,
	Stephen Boyd

The driver has really only supported one clock so far and has hardcoded the
ID used in communications with the firmware in all the functions
implementing the clock framework hooks. Let's store that in the clock data
structure so that we can support more clocks later on.

Cc: Michael Turquette <mturquette@baylibre.com>
Cc: linux-clk@vger.kernel.org
Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
 drivers/clk/bcm/clk-raspberrypi.c | 16 +++++++---------
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c
index 75197d8574cf..6aee81f494bb 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -39,6 +39,7 @@ struct raspberrypi_clk {
 
 struct raspberrypi_clk_data {
 	struct clk_hw hw;
+	unsigned int id;
 
 	unsigned long min_rate;
 	unsigned long max_rate;
@@ -95,7 +96,7 @@ static int raspberrypi_fw_pll_is_on(struct clk_hw *hw)
 
 	ret = raspberrypi_clock_property(rpi->firmware,
 					 RPI_FIRMWARE_GET_CLOCK_STATE,
-					 RPI_FIRMWARE_ARM_CLK_ID, &val);
+					 data->id, &val);
 	if (ret)
 		return 0;
 
@@ -114,8 +115,7 @@ static unsigned long raspberrypi_fw_pll_get_rate(struct clk_hw *hw,
 
 	ret = raspberrypi_clock_property(rpi->firmware,
 					 RPI_FIRMWARE_GET_CLOCK_RATE,
-					 RPI_FIRMWARE_ARM_CLK_ID,
-					 &val);
+					 data->id, &val);
 	if (ret)
 		return ret;
 
@@ -133,8 +133,7 @@ static int raspberrypi_fw_pll_set_rate(struct clk_hw *hw, unsigned long rate,
 
 	ret = raspberrypi_clock_property(rpi->firmware,
 					 RPI_FIRMWARE_SET_CLOCK_RATE,
-					 RPI_FIRMWARE_ARM_CLK_ID,
-					 &new_rate);
+					 data->id, &new_rate);
 	if (ret)
 		dev_err_ratelimited(rpi->dev, "Failed to change %s frequency: %d",
 				    clk_hw_get_name(hw), ret);
@@ -189,6 +188,7 @@ static int raspberrypi_register_pllb(struct raspberrypi_clk *rpi)
 	if (!data)
 		return -ENOMEM;
 	data->rpi = rpi;
+	data->id = RPI_FIRMWARE_ARM_CLK_ID;
 
 	/* All of the PLLs derive from the external oscillator. */
 	init.parent_names = (const char *[]){ "osc" };
@@ -200,8 +200,7 @@ static int raspberrypi_register_pllb(struct raspberrypi_clk *rpi)
 	/* Get min & max rates set by the firmware */
 	ret = raspberrypi_clock_property(rpi->firmware,
 					 RPI_FIRMWARE_GET_MIN_CLOCK_RATE,
-					 RPI_FIRMWARE_ARM_CLK_ID,
-					 &min_rate);
+					 data->id, &min_rate);
 	if (ret) {
 		dev_err(rpi->dev, "Failed to get %s min freq: %d\n",
 			init.name, ret);
@@ -210,8 +209,7 @@ static int raspberrypi_register_pllb(struct raspberrypi_clk *rpi)
 
 	ret = raspberrypi_clock_property(rpi->firmware,
 					 RPI_FIRMWARE_GET_MAX_CLOCK_RATE,
-					 RPI_FIRMWARE_ARM_CLK_ID,
-					 &max_rate);
+					 data->id, &max_rate);
 	if (ret) {
 		dev_err(rpi->dev, "Failed to get %s max freq: %d\n",
 			init.name, ret);
-- 
git-series 0.9.1

^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH v2 15/91] clk: bcm: rpi: Pass the clocks data to the firmware function
  2020-04-24 15:33 [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipeline Maxime Ripard
                   ` (10 preceding siblings ...)
  2020-04-24 15:33 ` [PATCH v2 14/91] clk: bcm: rpi: Add clock id to data Maxime Ripard
@ 2020-04-24 15:33 ` Maxime Ripard
  2020-05-27  6:49   ` Stephen Boyd
  2020-04-24 15:33 ` [PATCH v2 16/91] clk: bcm: rpi: Rename is_prepared function Maxime Ripard
                   ` (6 subsequent siblings)
  18 siblings, 1 reply; 49+ messages in thread
From: Maxime Ripard @ 2020-04-24 15:33 UTC (permalink / raw)
  To: Nicolas Saenz Julienne, Eric Anholt
  Cc: dri-devel, linux-rpi-kernel, bcm-kernel-feedback-list,
	linux-arm-kernel, linux-kernel, Dave Stevenson, Tim Gover,
	Phil Elwell, Maxime Ripard, Michael Turquette, Stephen Boyd,
	linux-clk

The raspberry_clock_property only takes the clock ID as an argument, but
now that we have a clock data structure it makes more sense to just pass
that structure instead.

Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: linux-clk@vger.kernel.org
Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
 drivers/clk/bcm/clk-raspberrypi.c | 29 ++++++++++++++---------------
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c
index 6aee81f494bb..6e8977b70e38 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -67,11 +67,12 @@ struct raspberrypi_firmware_prop {
 	__le32 disable_turbo;
 } __packed;
 
-static int raspberrypi_clock_property(struct rpi_firmware *firmware, u32 tag,
-				      u32 clk, u32 *val)
+static int raspberrypi_clock_property(struct rpi_firmware *firmware,
+				      const struct raspberrypi_clk_data *data,
+				      u32 tag, u32 *val)
 {
 	struct raspberrypi_firmware_prop msg = {
-		.id = cpu_to_le32(clk),
+		.id = cpu_to_le32(data->id),
 		.val = cpu_to_le32(*val),
 		.disable_turbo = cpu_to_le32(1),
 	};
@@ -94,9 +95,8 @@ static int raspberrypi_fw_pll_is_on(struct clk_hw *hw)
 	u32 val = 0;
 	int ret;
 
-	ret = raspberrypi_clock_property(rpi->firmware,
-					 RPI_FIRMWARE_GET_CLOCK_STATE,
-					 data->id, &val);
+	ret = raspberrypi_clock_property(rpi->firmware, data,
+					 RPI_FIRMWARE_GET_CLOCK_STATE, &val);
 	if (ret)
 		return 0;
 
@@ -113,9 +113,8 @@ static unsigned long raspberrypi_fw_pll_get_rate(struct clk_hw *hw,
 	u32 val = 0;
 	int ret;
 
-	ret = raspberrypi_clock_property(rpi->firmware,
-					 RPI_FIRMWARE_GET_CLOCK_RATE,
-					 data->id, &val);
+	ret = raspberrypi_clock_property(rpi->firmware, data,
+					 RPI_FIRMWARE_GET_CLOCK_RATE, &val);
 	if (ret)
 		return ret;
 
@@ -131,9 +130,9 @@ static int raspberrypi_fw_pll_set_rate(struct clk_hw *hw, unsigned long rate,
 	u32 new_rate = rate / RPI_FIRMWARE_PLLB_ARM_DIV_RATE;
 	int ret;
 
-	ret = raspberrypi_clock_property(rpi->firmware,
+	ret = raspberrypi_clock_property(rpi->firmware, data,
 					 RPI_FIRMWARE_SET_CLOCK_RATE,
-					 data->id, &new_rate);
+					 &new_rate);
 	if (ret)
 		dev_err_ratelimited(rpi->dev, "Failed to change %s frequency: %d",
 				    clk_hw_get_name(hw), ret);
@@ -198,18 +197,18 @@ static int raspberrypi_register_pllb(struct raspberrypi_clk *rpi)
 	init.flags = CLK_GET_RATE_NOCACHE | CLK_IGNORE_UNUSED;
 
 	/* Get min & max rates set by the firmware */
-	ret = raspberrypi_clock_property(rpi->firmware,
+	ret = raspberrypi_clock_property(rpi->firmware, data,
 					 RPI_FIRMWARE_GET_MIN_CLOCK_RATE,
-					 data->id, &min_rate);
+					 &min_rate);
 	if (ret) {
 		dev_err(rpi->dev, "Failed to get %s min freq: %d\n",
 			init.name, ret);
 		return ret;
 	}
 
-	ret = raspberrypi_clock_property(rpi->firmware,
+	ret = raspberrypi_clock_property(rpi->firmware, data,
 					 RPI_FIRMWARE_GET_MAX_CLOCK_RATE,
-					 data->id, &max_rate);
+					 &max_rate);
 	if (ret) {
 		dev_err(rpi->dev, "Failed to get %s max freq: %d\n",
 			init.name, ret);
-- 
git-series 0.9.1

^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH v2 16/91] clk: bcm: rpi: Rename is_prepared function
  2020-04-24 15:33 [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipeline Maxime Ripard
                   ` (11 preceding siblings ...)
  2020-04-24 15:33 ` [PATCH v2 15/91] clk: bcm: rpi: Pass the clocks data to the firmware function Maxime Ripard
@ 2020-04-24 15:33 ` Maxime Ripard
  2020-04-24 15:33 ` [PATCH v2 17/91] clk: bcm: rpi: Split pllb clock hooks Maxime Ripard
                   ` (5 subsequent siblings)
  18 siblings, 0 replies; 49+ messages in thread
From: Maxime Ripard @ 2020-04-24 15:33 UTC (permalink / raw)
  To: Nicolas Saenz Julienne, Eric Anholt
  Cc: dri-devel, linux-rpi-kernel, bcm-kernel-feedback-list,
	linux-arm-kernel, linux-kernel, Dave Stevenson, Tim Gover,
	Phil Elwell, Maxime Ripard, Michael Turquette, linux-clk,
	Stephen Boyd

The raspberrypi_fw_pll_is_on function doesn't only apply to PLL
registered in the driver, but any clock exposed by the firmware.

Since we also implement the is_prepared hook, make the function
consistent with the other function names.

Cc: Michael Turquette <mturquette@baylibre.com>
Cc: linux-clk@vger.kernel.org
Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
 drivers/clk/bcm/clk-raspberrypi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c
index 6e8977b70e38..99201f58a609 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -87,7 +87,7 @@ static int raspberrypi_clock_property(struct rpi_firmware *firmware,
 	return 0;
 }
 
-static int raspberrypi_fw_pll_is_on(struct clk_hw *hw)
+static int raspberrypi_fw_is_prepared(struct clk_hw *hw)
 {
 	struct raspberrypi_clk_data *data =
 		container_of(hw, struct raspberrypi_clk_data, hw);
@@ -170,7 +170,7 @@ static int raspberrypi_pll_determine_rate(struct clk_hw *hw,
 }
 
 static const struct clk_ops raspberrypi_firmware_pll_clk_ops = {
-	.is_prepared = raspberrypi_fw_pll_is_on,
+	.is_prepared = raspberrypi_fw_is_prepared,
 	.recalc_rate = raspberrypi_fw_pll_get_rate,
 	.set_rate = raspberrypi_fw_pll_set_rate,
 	.determine_rate = raspberrypi_pll_determine_rate,
-- 
git-series 0.9.1

^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH v2 17/91] clk: bcm: rpi: Split pllb clock hooks
  2020-04-24 15:33 [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipeline Maxime Ripard
                   ` (12 preceding siblings ...)
  2020-04-24 15:33 ` [PATCH v2 16/91] clk: bcm: rpi: Rename is_prepared function Maxime Ripard
@ 2020-04-24 15:33 ` Maxime Ripard
  2020-04-24 15:33 ` [PATCH v2 18/91] clk: bcm: rpi: Make the PLLB registration function return a clk_hw Maxime Ripard
                   ` (4 subsequent siblings)
  18 siblings, 0 replies; 49+ messages in thread
From: Maxime Ripard @ 2020-04-24 15:33 UTC (permalink / raw)
  To: Nicolas Saenz Julienne, Eric Anholt
  Cc: dri-devel, linux-rpi-kernel, bcm-kernel-feedback-list,
	linux-arm-kernel, linux-kernel, Dave Stevenson, Tim Gover,
	Phil Elwell, Maxime Ripard, Michael Turquette, linux-clk,
	Stephen Boyd

The driver only supports the pllb for now and all the clock framework hooks
are a mix of the generic firmware interface and the specifics of the pllb.
Since we will support more clocks in the future let's split the generic and
specific hooks

Cc: Michael Turquette <mturquette@baylibre.com>
Cc: linux-clk@vger.kernel.org
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
 drivers/clk/bcm/clk-raspberrypi.c | 30 ++++++++++++++++++++++--------
 1 file changed, 22 insertions(+), 8 deletions(-)

diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c
index 99201f58a609..8c88d2ea1d67 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -104,8 +104,8 @@ static int raspberrypi_fw_is_prepared(struct clk_hw *hw)
 }
 
 
-static unsigned long raspberrypi_fw_pll_get_rate(struct clk_hw *hw,
-						 unsigned long parent_rate)
+static unsigned long raspberrypi_fw_get_rate(struct clk_hw *hw,
+					     unsigned long parent_rate)
 {
 	struct raspberrypi_clk_data *data =
 		container_of(hw, struct raspberrypi_clk_data, hw);
@@ -118,21 +118,27 @@ static unsigned long raspberrypi_fw_pll_get_rate(struct clk_hw *hw,
 	if (ret)
 		return ret;
 
-	return val * RPI_FIRMWARE_PLLB_ARM_DIV_RATE;
+	return val;
 }
 
-static int raspberrypi_fw_pll_set_rate(struct clk_hw *hw, unsigned long rate,
-				       unsigned long parent_rate)
+static unsigned long raspberrypi_fw_pll_get_rate(struct clk_hw *hw,
+						 unsigned long parent_rate)
+{
+	return raspberrypi_fw_get_rate(hw, parent_rate) *
+		RPI_FIRMWARE_PLLB_ARM_DIV_RATE;
+}
+
+static int raspberrypi_fw_set_rate(struct clk_hw *hw, unsigned long rate,
+				   unsigned long parent_rate)
 {
 	struct raspberrypi_clk_data *data =
 		container_of(hw, struct raspberrypi_clk_data, hw);
 	struct raspberrypi_clk *rpi = data->rpi;
-	u32 new_rate = rate / RPI_FIRMWARE_PLLB_ARM_DIV_RATE;
+	u32 _rate = rate;
 	int ret;
 
 	ret = raspberrypi_clock_property(rpi->firmware, data,
-					 RPI_FIRMWARE_SET_CLOCK_RATE,
-					 &new_rate);
+					 RPI_FIRMWARE_SET_CLOCK_RATE, &_rate);
 	if (ret)
 		dev_err_ratelimited(rpi->dev, "Failed to change %s frequency: %d",
 				    clk_hw_get_name(hw), ret);
@@ -140,6 +146,14 @@ static int raspberrypi_fw_pll_set_rate(struct clk_hw *hw, unsigned long rate,
 	return ret;
 }
 
+static int raspberrypi_fw_pll_set_rate(struct clk_hw *hw, unsigned long rate,
+				       unsigned long parent_rate)
+{
+	u32 new_rate = rate / RPI_FIRMWARE_PLLB_ARM_DIV_RATE;
+
+	return raspberrypi_fw_set_rate(hw, new_rate, parent_rate);
+}
+
 /*
  * Sadly there is no firmware rate rounding interface. We borrowed it from
  * clk-bcm2835.
-- 
git-series 0.9.1

^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH v2 18/91] clk: bcm: rpi: Make the PLLB registration function return a clk_hw
  2020-04-24 15:33 [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipeline Maxime Ripard
                   ` (13 preceding siblings ...)
  2020-04-24 15:33 ` [PATCH v2 17/91] clk: bcm: rpi: Split pllb clock hooks Maxime Ripard
@ 2020-04-24 15:33 ` Maxime Ripard
  2020-04-24 15:34 ` [PATCH v2 19/91] clk: bcm: rpi: Add DT provider for the clocks Maxime Ripard
                   ` (3 subsequent siblings)
  18 siblings, 0 replies; 49+ messages in thread
From: Maxime Ripard @ 2020-04-24 15:33 UTC (permalink / raw)
  To: Nicolas Saenz Julienne, Eric Anholt
  Cc: dri-devel, linux-rpi-kernel, bcm-kernel-feedback-list,
	linux-arm-kernel, linux-kernel, Dave Stevenson, Tim Gover,
	Phil Elwell, Maxime Ripard, Michael Turquette, linux-clk,
	Stephen Boyd

The raspberrypi_register_pllb has been returning an integer so far to
notify whether the functions has exited successfully or not.

However, the OF provider functions in the clock framework require access to
the clk_hw structure so that we can expose those clocks to device tree
consumers.

Since we'll want that for the future clocks, let's return a clk_hw pointer
instead of the return code.

Cc: Michael Turquette <mturquette@baylibre.com>
Cc: linux-clk@vger.kernel.org
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
 drivers/clk/bcm/clk-raspberrypi.c | 40 +++++++++++++++++---------------
 1 file changed, 22 insertions(+), 18 deletions(-)

diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c
index 8c88d2ea1d67..677d7f3e8d2e 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -190,7 +190,7 @@ static const struct clk_ops raspberrypi_firmware_pll_clk_ops = {
 	.determine_rate = raspberrypi_pll_determine_rate,
 };
 
-static int raspberrypi_register_pllb(struct raspberrypi_clk *rpi)
+static struct clk_hw *raspberrypi_register_pllb(struct raspberrypi_clk *rpi)
 {
 	struct raspberrypi_clk_data *data;
 	struct clk_init_data init = {};
@@ -199,7 +199,7 @@ static int raspberrypi_register_pllb(struct raspberrypi_clk *rpi)
 
 	data = devm_kzalloc(rpi->dev, sizeof(*data), GFP_KERNEL);
 	if (!data)
-		return -ENOMEM;
+		return ERR_PTR(-ENOMEM);
 	data->rpi = rpi;
 	data->id = RPI_FIRMWARE_ARM_CLK_ID;
 
@@ -217,7 +217,7 @@ static int raspberrypi_register_pllb(struct raspberrypi_clk *rpi)
 	if (ret) {
 		dev_err(rpi->dev, "Failed to get %s min freq: %d\n",
 			init.name, ret);
-		return ret;
+		return ERR_PTR(ret);
 	}
 
 	ret = raspberrypi_clock_property(rpi->firmware, data,
@@ -226,13 +226,13 @@ static int raspberrypi_register_pllb(struct raspberrypi_clk *rpi)
 	if (ret) {
 		dev_err(rpi->dev, "Failed to get %s max freq: %d\n",
 			init.name, ret);
-		return ret;
+		return ERR_PTR(ret);
 	}
 
 	if (!min_rate || !max_rate) {
 		dev_err(rpi->dev, "Unexpected frequency range: min %u, max %u\n",
 			min_rate, max_rate);
-		return -EINVAL;
+		return ERR_PTR(-EINVAL);
 	}
 
 	dev_info(rpi->dev, "CPU frequency range: min %u, max %u\n",
@@ -243,7 +243,11 @@ static int raspberrypi_register_pllb(struct raspberrypi_clk *rpi)
 
 	data->hw.init = &init;
 
-	return devm_clk_hw_register(rpi->dev, &data->hw);
+	ret = devm_clk_hw_register(rpi->dev, &data->hw);
+	if (ret)
+		return ERR_PTR(ret);
+
+	return &data->hw;
 }
 
 static struct clk_fixed_factor raspberrypi_clk_pllb_arm = {
@@ -258,14 +262,14 @@ static struct clk_fixed_factor raspberrypi_clk_pllb_arm = {
 	},
 };
 
-static int raspberrypi_register_pllb_arm(struct raspberrypi_clk *rpi)
+static struct clk_hw *raspberrypi_register_pllb_arm(struct raspberrypi_clk *rpi)
 {
 	int ret;
 
 	ret = devm_clk_hw_register(rpi->dev, &raspberrypi_clk_pllb_arm.hw);
 	if (ret) {
 		dev_err(rpi->dev, "Failed to initialize pllb_arm\n");
-		return ret;
+		return ERR_PTR(ret);
 	}
 
 	ret = devm_clk_hw_register_clkdev(rpi->dev,
@@ -273,10 +277,10 @@ static int raspberrypi_register_pllb_arm(struct raspberrypi_clk *rpi)
 					  NULL, "cpu0");
 	if (ret) {
 		dev_err(rpi->dev, "Failed to initialize clkdev\n");
-		return ret;
+		return ERR_PTR(ret);
 	}
 
-	return 0;
+	return &raspberrypi_clk_pllb_arm.hw;
 }
 
 static int raspberrypi_clk_probe(struct platform_device *pdev)
@@ -285,7 +289,7 @@ static int raspberrypi_clk_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct rpi_firmware *firmware;
 	struct raspberrypi_clk *rpi;
-	int ret;
+	struct clk_hw *hw;
 
 	/*
 	 * We can be probed either through the an old-fashioned
@@ -314,15 +318,15 @@ static int raspberrypi_clk_probe(struct platform_device *pdev)
 	rpi->firmware = firmware;
 	platform_set_drvdata(pdev, rpi);
 
-	ret = raspberrypi_register_pllb(rpi);
-	if (ret) {
-		dev_err(dev, "Failed to initialize pllb, %d\n", ret);
-		return ret;
+	hw = raspberrypi_register_pllb(rpi);
+	if (IS_ERR(hw)) {
+		dev_err(dev, "Failed to initialize pllb, %ld\n", PTR_ERR(hw));
+		return PTR_ERR(hw);
 	}
 
-	ret = raspberrypi_register_pllb_arm(rpi);
-	if (ret)
-		return ret;
+	hw = raspberrypi_register_pllb_arm(rpi);
+	if (IS_ERR(hw))
+		return PTR_ERR(hw);
 
 	rpi->cpufreq = platform_device_register_data(dev, "raspberrypi-cpufreq",
 						     -1, NULL, 0);
-- 
git-series 0.9.1

^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH v2 19/91] clk: bcm: rpi: Add DT provider for the clocks
  2020-04-24 15:33 [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipeline Maxime Ripard
                   ` (14 preceding siblings ...)
  2020-04-24 15:33 ` [PATCH v2 18/91] clk: bcm: rpi: Make the PLLB registration function return a clk_hw Maxime Ripard
@ 2020-04-24 15:34 ` Maxime Ripard
  2020-04-24 15:34 ` [PATCH v2 20/91] clk: bcm: rpi: Discover the firmware clocks Maxime Ripard
                   ` (2 subsequent siblings)
  18 siblings, 0 replies; 49+ messages in thread
From: Maxime Ripard @ 2020-04-24 15:34 UTC (permalink / raw)
  To: Nicolas Saenz Julienne, Eric Anholt
  Cc: dri-devel, linux-rpi-kernel, bcm-kernel-feedback-list,
	linux-arm-kernel, linux-kernel, Dave Stevenson, Tim Gover,
	Phil Elwell, Maxime Ripard, Michael Turquette, linux-clk,
	Stephen Boyd

For the upcoming registration of the clocks provided by the firmware, make
sure it's exposed to the device tree providers.

Cc: Michael Turquette <mturquette@baylibre.com>
Cc: linux-clk@vger.kernel.org
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
 drivers/clk/bcm/clk-raspberrypi.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c
index 677d7f3e8d2e..1a9027169a2a 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -31,6 +31,8 @@
 
 #define A2W_PLL_FRAC_BITS		20
 
+#define NUM_FW_CLKS			16
+
 struct raspberrypi_clk {
 	struct device *dev;
 	struct rpi_firmware *firmware;
@@ -285,11 +287,13 @@ static struct clk_hw *raspberrypi_register_pllb_arm(struct raspberrypi_clk *rpi)
 
 static int raspberrypi_clk_probe(struct platform_device *pdev)
 {
+	struct clk_hw_onecell_data *clk_data;
 	struct device_node *firmware_node;
 	struct device *dev = &pdev->dev;
 	struct rpi_firmware *firmware;
 	struct raspberrypi_clk *rpi;
 	struct clk_hw *hw;
+	int ret;
 
 	/*
 	 * We can be probed either through the an old-fashioned
@@ -318,6 +322,11 @@ static int raspberrypi_clk_probe(struct platform_device *pdev)
 	rpi->firmware = firmware;
 	platform_set_drvdata(pdev, rpi);
 
+	clk_data = devm_kzalloc(dev, struct_size(clk_data, hws, NUM_FW_CLKS),
+				GFP_KERNEL);
+	if (!clk_data)
+		return -ENOMEM;
+
 	hw = raspberrypi_register_pllb(rpi);
 	if (IS_ERR(hw)) {
 		dev_err(dev, "Failed to initialize pllb, %ld\n", PTR_ERR(hw));
@@ -327,6 +336,13 @@ static int raspberrypi_clk_probe(struct platform_device *pdev)
 	hw = raspberrypi_register_pllb_arm(rpi);
 	if (IS_ERR(hw))
 		return PTR_ERR(hw);
+	clk_data->hws[RPI_FIRMWARE_ARM_CLK_ID] = hw;
+	clk_data->num = RPI_FIRMWARE_ARM_CLK_ID + 1;
+
+	ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get,
+					  clk_data);
+	if (ret)
+		return ret;
 
 	rpi->cpufreq = platform_device_register_data(dev, "raspberrypi-cpufreq",
 						     -1, NULL, 0);
-- 
git-series 0.9.1

^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH v2 20/91] clk: bcm: rpi: Discover the firmware clocks
  2020-04-24 15:33 [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipeline Maxime Ripard
                   ` (15 preceding siblings ...)
  2020-04-24 15:34 ` [PATCH v2 19/91] clk: bcm: rpi: Add DT provider for the clocks Maxime Ripard
@ 2020-04-24 15:34 ` Maxime Ripard
  2020-05-04 12:05   ` Nicolas Saenz Julienne
  2020-05-27  7:03   ` Stephen Boyd
  2020-04-24 15:34 ` [PATCH v2 25/91] clk: bcm: Add BCM2711 DVP driver Maxime Ripard
  2020-04-27  7:23 ` [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin Jian-Hong Pan
  18 siblings, 2 replies; 49+ messages in thread
From: Maxime Ripard @ 2020-04-24 15:34 UTC (permalink / raw)
  To: Nicolas Saenz Julienne, Eric Anholt
  Cc: dri-devel, linux-rpi-kernel, bcm-kernel-feedback-list,
	linux-arm-kernel, linux-kernel, Dave Stevenson, Tim Gover,
	Phil Elwell, Maxime Ripard, Michael Turquette, Stephen Boyd,
	linux-clk

The RaspberryPi4 firmware actually exposes more clocks than are currently
handled by the driver and we will need to change some of them directly
based on the pixel rate for the display related clocks, or the load for the
GPU.

This rate change can have a number of side-effects, including adjusting the
various PLL voltages or the PLL parents. The firmware will also update
those clocks by itself for example if the SoC runs too hot.

In order to make Linux play as nice as possible with those constraints, it
makes sense to rely on the firmware clocks as much as possible.

Fortunately,t he firmware has an interface to discover the clocks it
exposes.

Let's use it to discover, register the clocks in the clocks framework and
then expose them through the device tree for consumers to use them.

Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: linux-clk@vger.kernel.org
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
 drivers/clk/bcm/clk-raspberrypi.c          | 104 +++++++++++++++++++---
 include/soc/bcm2835/raspberrypi-firmware.h |   5 +-
 2 files changed, 97 insertions(+), 12 deletions(-)

diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-raspberrypi.c
index 1a9027169a2a..6a789749aea6 100644
--- a/drivers/clk/bcm/clk-raspberrypi.c
+++ b/drivers/clk/bcm/clk-raspberrypi.c
@@ -285,6 +285,95 @@ static struct clk_hw *raspberrypi_register_pllb_arm(struct raspberrypi_clk *rpi)
 	return &raspberrypi_clk_pllb_arm.hw;
 }
 
+static long raspberrypi_fw_dumb_round_rate(struct clk_hw *hw,
+					   unsigned long rate,
+					   unsigned long *parent_rate)
+{
+	/*
+	 * The firmware will do the rounding but that isn't part of
+	 * the interface with the firmware, so we just do our best
+	 * here.
+	 */
+	return rate;
+}
+
+static const struct clk_ops raspberrypi_firmware_clk_ops = {
+	.is_prepared	= raspberrypi_fw_is_prepared,
+	.recalc_rate	= raspberrypi_fw_get_rate,
+	.round_rate	= raspberrypi_fw_dumb_round_rate,
+	.set_rate	= raspberrypi_fw_set_rate,
+};
+
+static struct clk_hw *raspberrypi_clk_register(struct raspberrypi_clk *rpi,
+					       unsigned int parent,
+					       unsigned int id)
+{
+	struct raspberrypi_clk_data *data;
+	struct clk_init_data init = {};
+	int ret;
+
+	if (id == RPI_FIRMWARE_ARM_CLK_ID) {
+		struct clk_hw *hw;
+
+		hw = raspberrypi_register_pllb(rpi);
+		if (IS_ERR(hw)) {
+			dev_err(rpi->dev, "Failed to initialize pllb, %ld\n",
+				PTR_ERR(hw));
+			return hw;
+		}
+
+		return raspberrypi_register_pllb_arm(rpi);
+	}
+
+	data = devm_kzalloc(rpi->dev, sizeof(*data), GFP_KERNEL);
+	if (!data)
+		return ERR_PTR(-ENOMEM);
+	data->rpi = rpi;
+	data->id = id;
+
+	init.name = devm_kasprintf(rpi->dev, GFP_KERNEL, "fw-clk-%u", id);
+	init.ops = &raspberrypi_firmware_clk_ops;
+	init.flags = CLK_GET_RATE_NOCACHE;
+
+	data->hw.init = &init;
+
+	ret = devm_clk_hw_register(rpi->dev, &data->hw);
+	if (ret)
+		return ERR_PTR(ret);
+
+	return &data->hw;
+}
+
+static int raspberrypi_discover_clocks(struct raspberrypi_clk *rpi,
+				       struct clk_hw_onecell_data *data)
+{
+	struct rpi_firmware_get_clocks_response *clks;
+	int ret;
+
+	clks = devm_kcalloc(rpi->dev, sizeof(*clks), NUM_FW_CLKS, GFP_KERNEL);
+	if (!clks)
+		return -ENOMEM;
+
+	ret = rpi_firmware_property(rpi->firmware, RPI_FIRMWARE_GET_CLOCKS,
+				    clks, sizeof(*clks) * NUM_FW_CLKS);
+	if (ret)
+		return ret;
+
+	while (clks->id) {
+		struct clk_hw *hw;
+
+		hw = raspberrypi_clk_register(rpi, clks->parent, clks->id);
+		if (IS_ERR(hw))
+			return PTR_ERR(hw);
+
+		data->hws[clks->id] = hw;
+		data->num = clks->id + 1;
+		clks++;
+	}
+
+	return 0;
+}
+
 static int raspberrypi_clk_probe(struct platform_device *pdev)
 {
 	struct clk_hw_onecell_data *clk_data;
@@ -292,7 +381,6 @@ static int raspberrypi_clk_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct rpi_firmware *firmware;
 	struct raspberrypi_clk *rpi;
-	struct clk_hw *hw;
 	int ret;
 
 	/*
@@ -327,17 +415,9 @@ static int raspberrypi_clk_probe(struct platform_device *pdev)
 	if (!clk_data)
 		return -ENOMEM;
 
-	hw = raspberrypi_register_pllb(rpi);
-	if (IS_ERR(hw)) {
-		dev_err(dev, "Failed to initialize pllb, %ld\n", PTR_ERR(hw));
-		return PTR_ERR(hw);
-	}
-
-	hw = raspberrypi_register_pllb_arm(rpi);
-	if (IS_ERR(hw))
-		return PTR_ERR(hw);
-	clk_data->hws[RPI_FIRMWARE_ARM_CLK_ID] = hw;
-	clk_data->num = RPI_FIRMWARE_ARM_CLK_ID + 1;
+	ret = raspberrypi_discover_clocks(rpi, clk_data);
+	if (ret)
+		return ret;
 
 	ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get,
 					  clk_data);
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
index 7800e12ee042..27bfc0dcfa9b 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -135,6 +135,11 @@ enum rpi_firmware_property_tag {
 	RPI_FIRMWARE_GET_DMA_CHANNELS =                       0x00060001,
 };
 
+struct rpi_firmware_get_clocks_response {
+	__le32 parent;
+	__le32 id;
+};
+
 #if IS_ENABLED(CONFIG_RASPBERRYPI_FIRMWARE)
 int rpi_firmware_property(struct rpi_firmware *fw,
 			  u32 tag, void *data, size_t len);
-- 
git-series 0.9.1

^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH v2 25/91] clk: bcm: Add BCM2711 DVP driver
  2020-04-24 15:33 [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipeline Maxime Ripard
                   ` (16 preceding siblings ...)
  2020-04-24 15:34 ` [PATCH v2 20/91] clk: bcm: rpi: Discover the firmware clocks Maxime Ripard
@ 2020-04-24 15:34 ` Maxime Ripard
  2020-05-27  7:06   ` Stephen Boyd
  2020-04-27  7:23 ` [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin Jian-Hong Pan
  18 siblings, 1 reply; 49+ messages in thread
From: Maxime Ripard @ 2020-04-24 15:34 UTC (permalink / raw)
  To: Nicolas Saenz Julienne, Eric Anholt
  Cc: dri-devel, linux-rpi-kernel, bcm-kernel-feedback-list,
	linux-arm-kernel, linux-kernel, Dave Stevenson, Tim Gover,
	Phil Elwell, Maxime Ripard, Michael Turquette, Stephen Boyd,
	Rob Herring, linux-clk, devicetree

The HDMI block has a block that controls clocks and reset signals to the
HDMI0 and HDMI1 controllers.

Let's expose that through a clock driver implementing a clock and reset
provider.

Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-clk@vger.kernel.org
Cc: devicetree@vger.kernel.org
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
 drivers/clk/bcm/Kconfig           |   1 +-
 drivers/clk/bcm/Makefile          |   1 +-
 drivers/clk/bcm/clk-bcm2711-dvp.c | 127 +++++++++++++++++++++++++++++++-
 3 files changed, 129 insertions(+)
 create mode 100644 drivers/clk/bcm/clk-bcm2711-dvp.c

diff --git a/drivers/clk/bcm/Kconfig b/drivers/clk/bcm/Kconfig
index 8c83977a7dc4..03bbd8040451 100644
--- a/drivers/clk/bcm/Kconfig
+++ b/drivers/clk/bcm/Kconfig
@@ -4,6 +4,7 @@ config CLK_BCM2835
 	depends on ARCH_BCM2835 || ARCH_BRCMSTB || COMPILE_TEST
 	depends on COMMON_CLK
 	default ARCH_BCM2835 || ARCH_BRCMSTB
+	select RESET_SIMPLE
 	help
 	  Enable common clock framework support for Broadcom BCM2835
 	  SoCs.
diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
index 0070ddf6cdd2..2c1349062147 100644
--- a/drivers/clk/bcm/Makefile
+++ b/drivers/clk/bcm/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_CLK_BCM_KONA)	+= clk-kona-setup.o
 obj-$(CONFIG_CLK_BCM_KONA)	+= clk-bcm281xx.o
 obj-$(CONFIG_CLK_BCM_KONA)	+= clk-bcm21664.o
 obj-$(CONFIG_COMMON_CLK_IPROC)	+= clk-iproc-armpll.o clk-iproc-pll.o clk-iproc-asiu.o
+obj-$(CONFIG_CLK_BCM2835)	+= clk-bcm2711-dvp.o
 obj-$(CONFIG_CLK_BCM2835)	+= clk-bcm2835.o
 obj-$(CONFIG_CLK_BCM2835)	+= clk-bcm2835-aux.o
 obj-$(CONFIG_CLK_RASPBERRYPI)	+= clk-raspberrypi.o
diff --git a/drivers/clk/bcm/clk-bcm2711-dvp.c b/drivers/clk/bcm/clk-bcm2711-dvp.c
new file mode 100644
index 000000000000..c1c4b5857d32
--- /dev/null
+++ b/drivers/clk/bcm/clk-bcm2711-dvp.c
@@ -0,0 +1,127 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+// Copyright 2020 Cerno
+
+#include <linux/clk-provider.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/reset-controller.h>
+#include <linux/reset/reset-simple.h>
+
+#define DVP_HT_RPI_SW_INIT	0x04
+#define DVP_HT_RPI_MISC_CONFIG	0x08
+
+#define NR_CLOCKS	2
+#define NR_RESETS	6
+
+struct clk_dvp {
+	struct clk_hw_onecell_data	*data;
+	struct reset_simple_data	reset;
+};
+
+static const struct clk_parent_data clk_dvp_parent = {
+	.index	= 0,
+};
+
+static int clk_dvp_probe(struct platform_device *pdev)
+{
+	struct clk_hw_onecell_data *data;
+	struct resource *res;
+	struct clk_dvp *dvp;
+	void __iomem *base;
+	int ret;
+
+	dvp = devm_kzalloc(&pdev->dev, sizeof(*dvp), GFP_KERNEL);
+	if (!dvp)
+		return -ENOMEM;
+	platform_set_drvdata(pdev, dvp);
+
+	dvp->data = devm_kzalloc(&pdev->dev,
+				 struct_size(dvp->data, hws, NR_CLOCKS),
+				 GFP_KERNEL);
+	if (!dvp->data)
+		return -ENOMEM;
+	data = dvp->data;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(base))
+		return PTR_ERR(base);
+
+	dvp->reset.rcdev.owner = THIS_MODULE;
+	dvp->reset.rcdev.nr_resets = NR_RESETS;
+	dvp->reset.rcdev.ops = &reset_simple_ops;
+	dvp->reset.rcdev.of_node = pdev->dev.of_node;
+	dvp->reset.membase = base + DVP_HT_RPI_SW_INIT;
+	spin_lock_init(&dvp->reset.lock);
+
+	ret = reset_controller_register(&dvp->reset.rcdev);
+	if (ret)
+		return ret;
+
+	data->hws[0] = clk_hw_register_gate_parent_data(&pdev->dev,
+							"hdmi0-108MHz",
+							&clk_dvp_parent, 0,
+							base + DVP_HT_RPI_MISC_CONFIG, 3,
+							CLK_GATE_SET_TO_DISABLE,
+							&dvp->reset.lock);
+	if (IS_ERR(data->hws[0])) {
+		ret = PTR_ERR(data->hws[0]);
+		goto unregister_reset;
+	}
+
+	data->hws[1] = clk_hw_register_gate_parent_data(&pdev->dev,
+							"hdmi1-108MHz",
+							&clk_dvp_parent, 0,
+							base + DVP_HT_RPI_MISC_CONFIG, 4,
+							CLK_GATE_SET_TO_DISABLE,
+							&dvp->reset.lock);
+	if (IS_ERR(data->hws[1])) {
+		ret = PTR_ERR(data->hws[1]);
+		goto unregister_clk0;
+	}
+
+	data->num = NR_CLOCKS;
+	ret = of_clk_add_hw_provider(pdev->dev.of_node, of_clk_hw_onecell_get,
+				     data);
+	if (ret)
+		goto unregister_clk1;
+
+	return 0;
+
+unregister_clk1:
+	clk_hw_unregister_gate(data->hws[1]);
+
+unregister_clk0:
+	clk_hw_unregister_gate(data->hws[0]);
+
+unregister_reset:
+	reset_controller_unregister(&dvp->reset.rcdev);
+	return ret;
+};
+
+static int clk_dvp_remove(struct platform_device *pdev)
+{
+	struct clk_dvp *dvp = platform_get_drvdata(pdev);
+	struct clk_hw_onecell_data *data = dvp->data;
+
+	clk_hw_unregister_gate(data->hws[1]);
+	clk_hw_unregister_gate(data->hws[0]);
+	reset_controller_unregister(&dvp->reset.rcdev);
+
+	return 0;
+}
+
+static const struct of_device_id clk_dvp_dt_ids[] = {
+	{ .compatible = "brcm,brcm2711-dvp", },
+	{ /* sentinel */ }
+};
+
+static struct platform_driver clk_dvp_driver = {
+	.probe	= clk_dvp_probe,
+	.remove	= clk_dvp_remove,
+	.driver	= {
+		.name		= "brcm2711-dvp",
+		.of_match_table	= clk_dvp_dt_ids,
+	},
+};
+module_platform_driver(clk_dvp_driver);
-- 
git-series 0.9.1

^ permalink raw reply related	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
  2020-04-24 15:33 [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipeline Maxime Ripard
                   ` (17 preceding siblings ...)
  2020-04-24 15:34 ` [PATCH v2 25/91] clk: bcm: Add BCM2711 DVP driver Maxime Ripard
@ 2020-04-27  7:23 ` Jian-Hong Pan
  2020-04-28 16:21   ` Maxime Ripard
  18 siblings, 1 reply; 49+ messages in thread
From: Jian-Hong Pan @ 2020-04-27  7:23 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Jian-Hong Pan, Nicolas Saenz Julienne, Eric Anholt, dri-devel,
	linux-rpi-kernel, bcm-kernel-feedback-list, linux-arm-kernel,
	linux-kernel, devicetree, linux-clk, linux-i2c, linux

Hi Maxime,

Thanks for your V2 patch series!  I'm testing it.

This patch series is applied upon mainline kernel 5.7-rc2 cleanly and built.
System can boot into console text mode, but no graphic UI.

Get the error in vc5_hdmi_phy_init(), and full dmesg is at [1]:

[    5.587543] vc4_hdmi fef00700.hdmi: Unknown register ID 46
[    5.587700] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi' already present!
[    5.588070] vc4_hdmi fef00700.hdmi: vc4-hdmi-hifi <-> fef00700.hdmi mapping ok
[    5.588076] vc4_hdmi fef00700.hdmi: ASoC: no DMI vendor name!
[    5.588263] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops)
[    5.588299] vc4_hdmi fef05700.hdmi: Unknown register ID 46
[    5.588373] debugfs: Directory 'vc4-hdmi' with parent 'asoc' already present!
[    5.588673] vc4_hdmi fef05700.hdmi: vc4-hdmi-hifi <-> fef05700.hdmi mapping ok
[    5.588677] vc4_hdmi fef05700.hdmi: ASoC: no DMI vendor name!
[    5.588809] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops)
[    5.588854] vc4-drm gpu: bound fe806000.vec (ops vc4_vec_ops)
[    5.588897] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops)
[    5.588934] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops)
[    5.588990] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops)
[    5.589030] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops)
[    5.589074] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops)
[    5.589106] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops)
[    5.589145] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops)
[    5.589294] checking generic (3e513000 6d8c00) vs hw (0 ffffffffffffffff)
[    5.589297] fb0: switching to vc4drmfb from simple
[    5.589433] Console: switching to colour dummy device 80x25
[    5.589481] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    5.589816] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
[    5.601079] ------------[ cut here ]------------
[    5.601095] WARNING: CPU: 2 PID: 127 at drivers/gpu/drm/vc4/vc4_hdmi_phy.c:413 vc5_hdmi_phy_init+0x7ac/0x2078
[    5.601097] Modules linked in:
[    5.601103] CPU: 2 PID: 127 Comm: kworker/2:1 Not tainted 5.7.0-rc2-00091-ga181df59a930 #7
[    5.601105] Hardware name: Raspberry Pi 4 Model B (DT)
[    5.601112] Workqueue: events deferred_probe_work_func
[    5.601116] pstate: 20000005 (nzCv daif -PAN -UAO)
[    5.601119] pc : vc5_hdmi_phy_init+0x7ac/0x2078
[    5.601123] lr : vc4_hdmi_encoder_enable+0x1b8/0x1ac0
[    5.601124] sp : ffff80001217b410
[    5.601126] x29: ffff80001217b410 x28: ffff0000ec6370f0 
[    5.601129] x27: ffff0000f650d400 x26: 000000008a500000 
[    5.601132] x25: ffff8000113b4ac0 x24: 0000000000002060 
[    5.601135] x23: 000000000a500000 x22: 0000000000000300 
[    5.601137] x21: 0000000008d9ee20 x20: ffff0000ec535080 
[    5.601140] x19: 000000010989e7c0 x18: 0000000000000000 
[    5.601142] x17: 0000000000000001 x16: 0000000000005207 
[    5.601145] x15: 00004932ad293c92 x14: 0000000000000137 
[    5.601147] x13: ffff800010015000 x12: 0000000000000001 
[    5.601150] x11: 0000000000000001 x10: 0000000000000000 
[    5.601152] x9 : 0000000000000000 x8 : ffff800010015038 
[    5.601154] x7 : 0000000000000001 x6 : ffff80001217b368 
[    5.601157] x5 : 0000000000000000 x4 : 000000000000004c 
[    5.601159] x3 : 0000000000000000 x2 : ffff8000113b4ac0 
[    5.601162] x1 : ffff8000120c5f44 x0 : 00000000dc8984ff 
[    5.601164] Call trace:
[    5.601169]  vc5_hdmi_phy_init+0x7ac/0x2078
[    5.601172]  vc4_hdmi_encoder_enable+0x1b8/0x1ac0
[    5.601176]  drm_atomic_helper_commit_modeset_enables+0x224/0x248
[    5.601179]  vc4_atomic_complete_commit+0x400/0x558
[    5.601182]  vc4_atomic_commit+0x1e0/0x200
[    5.601185]  drm_atomic_commit+0x4c/0x60
[    5.601190]  drm_client_modeset_commit_atomic.isra.0+0x17c/0x238
[    5.601192]  drm_client_modeset_commit_locked+0x5c/0x198
[    5.601195]  drm_client_modeset_commit+0x30/0x58
[    5.601201]  drm_fb_helper_restore_fbdev_mode_unlocked+0x78/0xe0
[    5.601204]  drm_fb_helper_set_par+0x30/0x68
[    5.601208]  fbcon_init+0x3d4/0x598
[    5.601212]  visual_init+0xb0/0x108
[    5.601214]  do_bind_con_driver+0x1d0/0x3a8
[    5.601217]  do_take_over_console+0x144/0x208
[    5.601219]  do_fbcon_takeover+0x68/0xd8
[    5.601222]  fbcon_fb_registered+0x100/0x118
[    5.601226]  register_framebuffer+0x1f4/0x338
[    5.601229]  __drm_fb_helper_initial_config_and_unlock+0x2f8/0x4a0
[    5.601232]  drm_fbdev_client_hotplug+0xd4/0x1b0
[    5.601235]  drm_fbdev_generic_setup+0xb0/0x130
[    5.601238]  vc4_drm_bind+0x184/0x1a0
[    5.601241]  try_to_bring_up_master+0x168/0x1c8
[    5.601244]  __component_add+0xa4/0x170
[    5.601246]  component_add+0x14/0x20
[    5.601248]  vc4_vec_dev_probe+0x20/0x30
[    5.601252]  platform_drv_probe+0x54/0xa8
[    5.601254]  really_probe+0xd8/0x320
[    5.601256]  driver_probe_device+0x58/0xf0
[    5.601258]  __device_attach_driver+0x84/0xc8
[    5.601263]  bus_for_each_drv+0x78/0xc8
[    5.601265]  __device_attach+0xe4/0x140
[    5.601267]  device_initial_probe+0x14/0x20
[    5.601269]  bus_probe_device+0x9c/0xa8
[    5.601271]  deferred_probe_work_func+0x74/0xb0
[    5.601276]  process_one_work+0x1bc/0x338
[    5.601279]  worker_thread+0x1f8/0x428
[    5.601282]  kthread+0x138/0x158
[    5.601286]  ret_from_fork+0x10/0x1c
[    5.601288] ---[ end trace cfba0996218c3f3d ]---

[1]: https://gist.github.com/starnight/2236cf350737e3b0e9f05135fc7c910e

Jian-Hong Pan

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
  2020-04-27  7:23 ` [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin Jian-Hong Pan
@ 2020-04-28 16:21   ` Maxime Ripard
  2020-05-04  6:35     ` Jian-Hong Pan
  0 siblings, 1 reply; 49+ messages in thread
From: Maxime Ripard @ 2020-04-28 16:21 UTC (permalink / raw)
  To: Jian-Hong Pan
  Cc: Nicolas Saenz Julienne, Eric Anholt, dri-devel, linux-rpi-kernel,
	bcm-kernel-feedback-list, linux-arm-kernel, linux-kernel,
	devicetree, linux-clk, linux-i2c, linux

[-- Attachment #1: Type: text/plain, Size: 5925 bytes --]

Hi,

On Mon, Apr 27, 2020 at 03:23:42PM +0800, Jian-Hong Pan wrote:
> Hi Maxime,
> 
> Thanks for your V2 patch series!  I'm testing it.
> 
> This patch series is applied upon mainline kernel 5.7-rc2 cleanly and built.
> System can boot into console text mode, but no graphic UI.
> 
> Get the error in vc5_hdmi_phy_init(), and full dmesg is at [1]:
> 
> [    5.587543] vc4_hdmi fef00700.hdmi: Unknown register ID 46
> [    5.587700] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi' already present!
> [    5.588070] vc4_hdmi fef00700.hdmi: vc4-hdmi-hifi <-> fef00700.hdmi mapping ok
> [    5.588076] vc4_hdmi fef00700.hdmi: ASoC: no DMI vendor name!
> [    5.588263] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops)
> [    5.588299] vc4_hdmi fef05700.hdmi: Unknown register ID 46
> [    5.588373] debugfs: Directory 'vc4-hdmi' with parent 'asoc' already present!
> [    5.588673] vc4_hdmi fef05700.hdmi: vc4-hdmi-hifi <-> fef05700.hdmi mapping ok
> [    5.588677] vc4_hdmi fef05700.hdmi: ASoC: no DMI vendor name!
> [    5.588809] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops)
> [    5.588854] vc4-drm gpu: bound fe806000.vec (ops vc4_vec_ops)
> [    5.588897] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops)
> [    5.588934] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops)
> [    5.588990] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops)
> [    5.589030] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops)
> [    5.589074] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops)
> [    5.589106] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops)
> [    5.589145] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops)
> [    5.589294] checking generic (3e513000 6d8c00) vs hw (0 ffffffffffffffff)
> [    5.589297] fb0: switching to vc4drmfb from simple
> [    5.589433] Console: switching to colour dummy device 80x25
> [    5.589481] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [    5.589816] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
> [    5.601079] ------------[ cut here ]------------
> [    5.601095] WARNING: CPU: 2 PID: 127 at drivers/gpu/drm/vc4/vc4_hdmi_phy.c:413 vc5_hdmi_phy_init+0x7ac/0x2078
> [    5.601097] Modules linked in:
> [    5.601103] CPU: 2 PID: 127 Comm: kworker/2:1 Not tainted 5.7.0-rc2-00091-ga181df59a930 #7
> [    5.601105] Hardware name: Raspberry Pi 4 Model B (DT)
> [    5.601112] Workqueue: events deferred_probe_work_func
> [    5.601116] pstate: 20000005 (nzCv daif -PAN -UAO)
> [    5.601119] pc : vc5_hdmi_phy_init+0x7ac/0x2078
> [    5.601123] lr : vc4_hdmi_encoder_enable+0x1b8/0x1ac0
> [    5.601124] sp : ffff80001217b410
> [    5.601126] x29: ffff80001217b410 x28: ffff0000ec6370f0 
> [    5.601129] x27: ffff0000f650d400 x26: 000000008a500000 
> [    5.601132] x25: ffff8000113b4ac0 x24: 0000000000002060 
> [    5.601135] x23: 000000000a500000 x22: 0000000000000300 
> [    5.601137] x21: 0000000008d9ee20 x20: ffff0000ec535080 
> [    5.601140] x19: 000000010989e7c0 x18: 0000000000000000 
> [    5.601142] x17: 0000000000000001 x16: 0000000000005207 
> [    5.601145] x15: 00004932ad293c92 x14: 0000000000000137 
> [    5.601147] x13: ffff800010015000 x12: 0000000000000001 
> [    5.601150] x11: 0000000000000001 x10: 0000000000000000 
> [    5.601152] x9 : 0000000000000000 x8 : ffff800010015038 
> [    5.601154] x7 : 0000000000000001 x6 : ffff80001217b368 
> [    5.601157] x5 : 0000000000000000 x4 : 000000000000004c 
> [    5.601159] x3 : 0000000000000000 x2 : ffff8000113b4ac0 
> [    5.601162] x1 : ffff8000120c5f44 x0 : 00000000dc8984ff 
> [    5.601164] Call trace:
> [    5.601169]  vc5_hdmi_phy_init+0x7ac/0x2078
> [    5.601172]  vc4_hdmi_encoder_enable+0x1b8/0x1ac0
> [    5.601176]  drm_atomic_helper_commit_modeset_enables+0x224/0x248
> [    5.601179]  vc4_atomic_complete_commit+0x400/0x558
> [    5.601182]  vc4_atomic_commit+0x1e0/0x200
> [    5.601185]  drm_atomic_commit+0x4c/0x60
> [    5.601190]  drm_client_modeset_commit_atomic.isra.0+0x17c/0x238
> [    5.601192]  drm_client_modeset_commit_locked+0x5c/0x198
> [    5.601195]  drm_client_modeset_commit+0x30/0x58
> [    5.601201]  drm_fb_helper_restore_fbdev_mode_unlocked+0x78/0xe0
> [    5.601204]  drm_fb_helper_set_par+0x30/0x68
> [    5.601208]  fbcon_init+0x3d4/0x598
> [    5.601212]  visual_init+0xb0/0x108
> [    5.601214]  do_bind_con_driver+0x1d0/0x3a8
> [    5.601217]  do_take_over_console+0x144/0x208
> [    5.601219]  do_fbcon_takeover+0x68/0xd8
> [    5.601222]  fbcon_fb_registered+0x100/0x118
> [    5.601226]  register_framebuffer+0x1f4/0x338
> [    5.601229]  __drm_fb_helper_initial_config_and_unlock+0x2f8/0x4a0
> [    5.601232]  drm_fbdev_client_hotplug+0xd4/0x1b0
> [    5.601235]  drm_fbdev_generic_setup+0xb0/0x130
> [    5.601238]  vc4_drm_bind+0x184/0x1a0
> [    5.601241]  try_to_bring_up_master+0x168/0x1c8
> [    5.601244]  __component_add+0xa4/0x170
> [    5.601246]  component_add+0x14/0x20
> [    5.601248]  vc4_vec_dev_probe+0x20/0x30
> [    5.601252]  platform_drv_probe+0x54/0xa8
> [    5.601254]  really_probe+0xd8/0x320
> [    5.601256]  driver_probe_device+0x58/0xf0
> [    5.601258]  __device_attach_driver+0x84/0xc8
> [    5.601263]  bus_for_each_drv+0x78/0xc8
> [    5.601265]  __device_attach+0xe4/0x140
> [    5.601267]  device_initial_probe+0x14/0x20
> [    5.601269]  bus_probe_device+0x9c/0xa8
> [    5.601271]  deferred_probe_work_func+0x74/0xb0
> [    5.601276]  process_one_work+0x1bc/0x338
> [    5.601279]  worker_thread+0x1f8/0x428
> [    5.601282]  kthread+0x138/0x158
> [    5.601286]  ret_from_fork+0x10/0x1c
> [    5.601288] ---[ end trace cfba0996218c3f3d ]---

Thanks for testing!

Do you have a bit more details regarding your setup? Was it connected to an
external display? If so, do you know the resolution it was trying to setup?

Thanks!
Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 05/91] clk: bcm: rpi: Allow the driver to be probed by DT
  2020-04-24 15:33 ` [PATCH v2 05/91] clk: bcm: rpi: Allow the driver to be probed by DT Maxime Ripard
@ 2020-04-30 16:19   ` Nicolas Saenz Julienne
  0 siblings, 0 replies; 49+ messages in thread
From: Nicolas Saenz Julienne @ 2020-04-30 16:19 UTC (permalink / raw)
  To: Maxime Ripard, Eric Anholt
  Cc: dri-devel, linux-rpi-kernel, bcm-kernel-feedback-list,
	linux-arm-kernel, linux-kernel, Dave Stevenson, Tim Gover,
	Phil Elwell, Michael Turquette, Stephen Boyd, linux-clk

[-- Attachment #1: Type: text/plain, Size: 2033 bytes --]

On Fri, 2020-04-24 at 17:33 +0200, Maxime Ripard wrote:
> The current firmware clock driver for the RaspberryPi can only be probed by
> manually registering an associated platform_device.
> 
> While this works fine for cpufreq where the device gets attached a clkdev
> lookup, it would be tedious to maintain a table of all the devices using
> one of the clocks exposed by the firmware.
> 
> Since the DT on the other hand is the perfect place to store those
> associations, make the firmware clocks driver probe-able through the device
> tree so that we can represent it as a node.
> 
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: linux-clk@vger.kernel.org
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---
>  drivers/clk/bcm/clk-raspberrypi.c | 20 +++++++++++++++++---
>  1 file changed, 17 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-
> raspberrypi.c
> index 1654fd0eedc9..aedeaaf2f66b 100644
> --- a/drivers/clk/bcm/clk-raspberrypi.c
> +++ b/drivers/clk/bcm/clk-raspberrypi.c
> @@ -255,15 +255,22 @@ static int raspberrypi_clk_probe(struct platform_device
> *pdev)
>  	struct raspberrypi_clk *rpi;
>  	int ret;
>  
> -	firmware_node = of_find_compatible_node(NULL, NULL,
> -					"raspberrypi,bcm2835-firmware");
> +	/*
> +	 * We can be probed either through the an old-fashioned
> +	 * platform device registration or through a DT node that is a
> +	 * child of the firmware node. Handle both cases.
> +	 */
> +	if (dev->of_node)
> +		firmware_node = of_get_parent(dev->of_node);
> +	else
> +		firmware_node = of_find_compatible_node(NULL, NULL,
> +							"raspberrypi,bcm2835-
> firmware");
>  	if (!firmware_node) {
>  		dev_err(dev, "Missing firmware node\n");
>  		return -ENOENT;
>  	}
>  
>  	firmware = rpi_firmware_get(firmware_node);
> -	of_node_put(firmware_node);

Why remove this? I think it's still needed after your changes.

Regards,
Nicolas


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
  2020-04-28 16:21   ` Maxime Ripard
@ 2020-05-04  6:35     ` Jian-Hong Pan
  2020-05-07 17:21       ` Maxime Ripard
  0 siblings, 1 reply; 49+ messages in thread
From: Jian-Hong Pan @ 2020-05-04  6:35 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Nicolas Saenz Julienne, Eric Anholt, dri-devel, linux-rpi-kernel,
	bcm-kernel-feedback-list, linux-arm-kernel, Linux Kernel,
	devicetree, linux-clk, linux-i2c, Linux Upstreaming Team

Maxime Ripard <maxime@cerno.tech> 於 2020年4月29日 週三 上午12:21寫道:
>
> Hi,
>
> On Mon, Apr 27, 2020 at 03:23:42PM +0800, Jian-Hong Pan wrote:
> > Hi Maxime,
> >
> > Thanks for your V2 patch series!  I'm testing it.
> >
> > This patch series is applied upon mainline kernel 5.7-rc2 cleanly and built.
> > System can boot into console text mode, but no graphic UI.
> >
> > Get the error in vc5_hdmi_phy_init(), and full dmesg is at [1]:
> >
> > [    5.587543] vc4_hdmi fef00700.hdmi: Unknown register ID 46
> > [    5.587700] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi' already present!
> > [    5.588070] vc4_hdmi fef00700.hdmi: vc4-hdmi-hifi <-> fef00700.hdmi mapping ok
> > [    5.588076] vc4_hdmi fef00700.hdmi: ASoC: no DMI vendor name!
> > [    5.588263] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops)
> > [    5.588299] vc4_hdmi fef05700.hdmi: Unknown register ID 46
> > [    5.588373] debugfs: Directory 'vc4-hdmi' with parent 'asoc' already present!
> > [    5.588673] vc4_hdmi fef05700.hdmi: vc4-hdmi-hifi <-> fef05700.hdmi mapping ok
> > [    5.588677] vc4_hdmi fef05700.hdmi: ASoC: no DMI vendor name!
> > [    5.588809] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops)
> > [    5.588854] vc4-drm gpu: bound fe806000.vec (ops vc4_vec_ops)
> > [    5.588897] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops)
> > [    5.588934] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops)
> > [    5.588990] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops)
> > [    5.589030] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops)
> > [    5.589074] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops)
> > [    5.589106] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops)
> > [    5.589145] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops)
> > [    5.589294] checking generic (3e513000 6d8c00) vs hw (0 ffffffffffffffff)
> > [    5.589297] fb0: switching to vc4drmfb from simple
> > [    5.589433] Console: switching to colour dummy device 80x25
> > [    5.589481] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> > [    5.589816] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
> > [    5.601079] ------------[ cut here ]------------
> > [    5.601095] WARNING: CPU: 2 PID: 127 at drivers/gpu/drm/vc4/vc4_hdmi_phy.c:413 vc5_hdmi_phy_init+0x7ac/0x2078
> > [    5.601097] Modules linked in:
> > [    5.601103] CPU: 2 PID: 127 Comm: kworker/2:1 Not tainted 5.7.0-rc2-00091-ga181df59a930 #7
> > [    5.601105] Hardware name: Raspberry Pi 4 Model B (DT)
> > [    5.601112] Workqueue: events deferred_probe_work_func
> > [    5.601116] pstate: 20000005 (nzCv daif -PAN -UAO)
> > [    5.601119] pc : vc5_hdmi_phy_init+0x7ac/0x2078
> > [    5.601123] lr : vc4_hdmi_encoder_enable+0x1b8/0x1ac0
> > [    5.601124] sp : ffff80001217b410
> > [    5.601126] x29: ffff80001217b410 x28: ffff0000ec6370f0
> > [    5.601129] x27: ffff0000f650d400 x26: 000000008a500000
> > [    5.601132] x25: ffff8000113b4ac0 x24: 0000000000002060
> > [    5.601135] x23: 000000000a500000 x22: 0000000000000300
> > [    5.601137] x21: 0000000008d9ee20 x20: ffff0000ec535080
> > [    5.601140] x19: 000000010989e7c0 x18: 0000000000000000
> > [    5.601142] x17: 0000000000000001 x16: 0000000000005207
> > [    5.601145] x15: 00004932ad293c92 x14: 0000000000000137
> > [    5.601147] x13: ffff800010015000 x12: 0000000000000001
> > [    5.601150] x11: 0000000000000001 x10: 0000000000000000
> > [    5.601152] x9 : 0000000000000000 x8 : ffff800010015038
> > [    5.601154] x7 : 0000000000000001 x6 : ffff80001217b368
> > [    5.601157] x5 : 0000000000000000 x4 : 000000000000004c
> > [    5.601159] x3 : 0000000000000000 x2 : ffff8000113b4ac0
> > [    5.601162] x1 : ffff8000120c5f44 x0 : 00000000dc8984ff
> > [    5.601164] Call trace:
> > [    5.601169]  vc5_hdmi_phy_init+0x7ac/0x2078
> > [    5.601172]  vc4_hdmi_encoder_enable+0x1b8/0x1ac0
> > [    5.601176]  drm_atomic_helper_commit_modeset_enables+0x224/0x248
> > [    5.601179]  vc4_atomic_complete_commit+0x400/0x558
> > [    5.601182]  vc4_atomic_commit+0x1e0/0x200
> > [    5.601185]  drm_atomic_commit+0x4c/0x60
> > [    5.601190]  drm_client_modeset_commit_atomic.isra.0+0x17c/0x238
> > [    5.601192]  drm_client_modeset_commit_locked+0x5c/0x198
> > [    5.601195]  drm_client_modeset_commit+0x30/0x58
> > [    5.601201]  drm_fb_helper_restore_fbdev_mode_unlocked+0x78/0xe0
> > [    5.601204]  drm_fb_helper_set_par+0x30/0x68
> > [    5.601208]  fbcon_init+0x3d4/0x598
> > [    5.601212]  visual_init+0xb0/0x108
> > [    5.601214]  do_bind_con_driver+0x1d0/0x3a8
> > [    5.601217]  do_take_over_console+0x144/0x208
> > [    5.601219]  do_fbcon_takeover+0x68/0xd8
> > [    5.601222]  fbcon_fb_registered+0x100/0x118
> > [    5.601226]  register_framebuffer+0x1f4/0x338
> > [    5.601229]  __drm_fb_helper_initial_config_and_unlock+0x2f8/0x4a0
> > [    5.601232]  drm_fbdev_client_hotplug+0xd4/0x1b0
> > [    5.601235]  drm_fbdev_generic_setup+0xb0/0x130
> > [    5.601238]  vc4_drm_bind+0x184/0x1a0
> > [    5.601241]  try_to_bring_up_master+0x168/0x1c8
> > [    5.601244]  __component_add+0xa4/0x170
> > [    5.601246]  component_add+0x14/0x20
> > [    5.601248]  vc4_vec_dev_probe+0x20/0x30
> > [    5.601252]  platform_drv_probe+0x54/0xa8
> > [    5.601254]  really_probe+0xd8/0x320
> > [    5.601256]  driver_probe_device+0x58/0xf0
> > [    5.601258]  __device_attach_driver+0x84/0xc8
> > [    5.601263]  bus_for_each_drv+0x78/0xc8
> > [    5.601265]  __device_attach+0xe4/0x140
> > [    5.601267]  device_initial_probe+0x14/0x20
> > [    5.601269]  bus_probe_device+0x9c/0xa8
> > [    5.601271]  deferred_probe_work_func+0x74/0xb0
> > [    5.601276]  process_one_work+0x1bc/0x338
> > [    5.601279]  worker_thread+0x1f8/0x428
> > [    5.601282]  kthread+0x138/0x158
> > [    5.601286]  ret_from_fork+0x10/0x1c
> > [    5.601288] ---[ end trace cfba0996218c3f3d ]---
>
> Thanks for testing!
>
> Do you have a bit more details regarding your setup? Was it connected to an
> external display?

Yes, the HDMI cable is connected to HDMI0 port on RPi 4.

> If so, do you know the resolution it was trying to setup?

According to the log, I think it is 1920x1080:
Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
HDMI-1 connected
Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
HDMI-2 disconnected
Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
Composite-1 disconnected
Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Using
exact sizes for initial modes
Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
HDMI-1 using initial mode 1920x1080 +0+0

https://gist.github.com/starnight/45e1468bfa0426a54d2fb4a9269cfb94

Regards,
Jian-Hong Pan

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 20/91] clk: bcm: rpi: Discover the firmware clocks
  2020-04-24 15:34 ` [PATCH v2 20/91] clk: bcm: rpi: Discover the firmware clocks Maxime Ripard
@ 2020-05-04 12:05   ` Nicolas Saenz Julienne
  2020-05-15  8:19     ` Maxime Ripard
  2020-05-27  7:03   ` Stephen Boyd
  1 sibling, 1 reply; 49+ messages in thread
From: Nicolas Saenz Julienne @ 2020-05-04 12:05 UTC (permalink / raw)
  To: Maxime Ripard, Eric Anholt
  Cc: Tim Gover, Dave Stevenson, Stephen Boyd, Michael Turquette,
	linux-kernel, dri-devel, linux-clk, bcm-kernel-feedback-list,
	linux-rpi-kernel, Phil Elwell, linux-arm-kernel

[-- Attachment #1: Type: text/plain, Size: 5482 bytes --]

Hi Maxime, as always, thanks for the series!
Some extra context, and comments below.

On Fri, 2020-04-24 at 17:34 +0200, Maxime Ripard wrote:
> The RaspberryPi4 firmware actually exposes more clocks than are currently
> handled by the driver and we will need to change some of them directly
> based on the pixel rate for the display related clocks, or the load for the
> GPU.
> 
> This rate change can have a number of side-effects, including adjusting the
> various PLL voltages or the PLL parents. The firmware will also update
> those clocks by itself for example if the SoC runs too hot.

To complete this:

RPi4's firmware implements DVFS. Clock frequency and SoC voltage are
correlated, if you can determine all clocks are running below a maximum then it
should be safe to lower the voltage. Currently, firmware actively monitors arm,
core, h264, v3d, isp and hevc to determine what voltage can be reduced to, and
if arm increases any of those clocks behind the firmware's back, when it has a
lowered voltage, a crash is highly likely.

As pointed out to me by RPi foundation engineers hsm/pixel aren't currently
being monitored, as driving a high resolution display also requires a high core
clock, which already sets an acceptable min voltage threshold. But that might
change if needed.

Ultimately, from the DVFS, the safe way to change clocks from arm would be to
always use the firmware interface, which we're far from doing right now. On the
other hand, AFAIK not all clocks have a firmware counterpart.

Note that we could also have a word with the RPi foundation and see if
disabling DVFS is possible (AFAIK it's not an option right now). Although I
personally prefer to support this upstream, aside from the obvious benefits to
battery powered use cases, not consuming power unnecessarily is always big
plus.

> In order to make Linux play as nice as possible with those constraints, it
> makes sense to rely on the firmware clocks as much as possible.

As I comment above, not as simple as it seems. I suggest, for now, we only
register the clocks we're going to use and that are likely to be affected by
DVFS. hsm being a contender here.

As we'd be settling on a hybrid solution here, which isn't ideal to say the
least, I'd like to gather some opinions on whether pushing towards a fully
firmware based solution is something you'd like to see.

> Fortunately,t he firmware has an interface to discover the clocks it
> exposes.

nit: wrongly placed space

> Let's use it to discover, register the clocks in the clocks framework and
> then expose them through the device tree for consumers to use them.
>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: linux-clk@vger.kernel.org
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---
>  drivers/clk/bcm/clk-raspberrypi.c          | 104 +++++++++++++++++++---

[...]

> +static struct clk_hw *raspberrypi_clk_register(struct raspberrypi_clk *rpi,
> +					       unsigned int parent,
> +					       unsigned int id)
> +{
> +	struct raspberrypi_clk_data *data;
> +	struct clk_init_data init = {};
> +	int ret;
> +
> +	if (id == RPI_FIRMWARE_ARM_CLK_ID) {
> +		struct clk_hw *hw;
> +
> +		hw = raspberrypi_register_pllb(rpi);
> +		if (IS_ERR(hw)) {
> +			dev_err(rpi->dev, "Failed to initialize pllb, %ld\n",
> +				PTR_ERR(hw));
> +			return hw;
> +		}
> +
> +		return raspberrypi_register_pllb_arm(rpi);
> +	}

We shouldn't create a special case for pllb. My suggestion here is that we
revert the commit that removed pllb from the mmio driver, in order to maintain a
nice view of the clock tree, and register this as a regular fw-clk.

The only user to this is RPi's the cpufreq driver, which shouldn't mind the
change as long as you maintain the clk lookup creation.

On that topic, now that the clocks are available in DT we could even move
raspberrypi-cpufreq's registration there. But that's out of the scope of this
series.

> +
> +	data = devm_kzalloc(rpi->dev, sizeof(*data), GFP_KERNEL);
> +	if (!data)
> +		return ERR_PTR(-ENOMEM);
> +	data->rpi = rpi;
> +	data->id = id;
> +
> +	init.name = devm_kasprintf(rpi->dev, GFP_KERNEL, "fw-clk-%u", id);

I'd really like more descriptive names here, sadly the firmware interface
doesn't provide them, but they are set in stone nonetheless. Something like
'fw-clk-arm' and 'fw-clk-hsm' comes to mind (SCMI does provide naming BTW).

See here for a list of all clocks:
https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface#clocks

> +	init.ops = &raspberrypi_firmware_clk_ops;
> +	init.flags = CLK_GET_RATE_NOCACHE;
> +
> +	data->hw.init = &init;
> +
> +	ret = devm_clk_hw_register(rpi->dev, &data->hw);
> +	if (ret)
> +		return ERR_PTR(ret);
> +
> +	return &data->hw;
> +}
> +
> +static int raspberrypi_discover_clocks(struct raspberrypi_clk *rpi,
> +				       struct clk_hw_onecell_data *data)
> +{
> +	struct rpi_firmware_get_clocks_response *clks;
> +	int ret;
> +
> +	clks = devm_kcalloc(rpi->dev, sizeof(*clks), NUM_FW_CLKS, GFP_KERNEL);
> +	if (!clks)
> +		return -ENOMEM;
> +
> +	ret = rpi_firmware_property(rpi->firmware, RPI_FIRMWARE_GET_CLOCKS,
> +				    clks, sizeof(*clks) * NUM_FW_CLKS);
> +	if (ret)
> +		return ret;
> +
> +	while (clks->id) {
> +		struct clk_hw *hw;

Se my comment above WRT registering all clocks.

Regards,
Nicolas


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
  2020-05-04  6:35     ` Jian-Hong Pan
@ 2020-05-07 17:21       ` Maxime Ripard
  2020-05-08  6:20         ` Jian-Hong Pan
  0 siblings, 1 reply; 49+ messages in thread
From: Maxime Ripard @ 2020-05-07 17:21 UTC (permalink / raw)
  To: Jian-Hong Pan
  Cc: Nicolas Saenz Julienne, Eric Anholt, dri-devel, linux-rpi-kernel,
	bcm-kernel-feedback-list, linux-arm-kernel, Linux Kernel,
	devicetree, linux-clk, linux-i2c, Linux Upstreaming Team

[-- Attachment #1: Type: text/plain, Size: 7500 bytes --]

On Mon, May 04, 2020 at 02:35:08PM +0800, Jian-Hong Pan wrote:
> Maxime Ripard <maxime@cerno.tech> 於 2020年4月29日 週三 上午12:21寫道:
> >
> > Hi,
> >
> > On Mon, Apr 27, 2020 at 03:23:42PM +0800, Jian-Hong Pan wrote:
> > > Hi Maxime,
> > >
> > > Thanks for your V2 patch series!  I'm testing it.
> > >
> > > This patch series is applied upon mainline kernel 5.7-rc2 cleanly and built.
> > > System can boot into console text mode, but no graphic UI.
> > >
> > > Get the error in vc5_hdmi_phy_init(), and full dmesg is at [1]:
> > >
> > > [    5.587543] vc4_hdmi fef00700.hdmi: Unknown register ID 46
> > > [    5.587700] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi' already present!
> > > [    5.588070] vc4_hdmi fef00700.hdmi: vc4-hdmi-hifi <-> fef00700.hdmi mapping ok
> > > [    5.588076] vc4_hdmi fef00700.hdmi: ASoC: no DMI vendor name!
> > > [    5.588263] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops)
> > > [    5.588299] vc4_hdmi fef05700.hdmi: Unknown register ID 46
> > > [    5.588373] debugfs: Directory 'vc4-hdmi' with parent 'asoc' already present!
> > > [    5.588673] vc4_hdmi fef05700.hdmi: vc4-hdmi-hifi <-> fef05700.hdmi mapping ok
> > > [    5.588677] vc4_hdmi fef05700.hdmi: ASoC: no DMI vendor name!
> > > [    5.588809] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops)
> > > [    5.588854] vc4-drm gpu: bound fe806000.vec (ops vc4_vec_ops)
> > > [    5.588897] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops)
> > > [    5.588934] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops)
> > > [    5.588990] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops)
> > > [    5.589030] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops)
> > > [    5.589074] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops)
> > > [    5.589106] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops)
> > > [    5.589145] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops)
> > > [    5.589294] checking generic (3e513000 6d8c00) vs hw (0 ffffffffffffffff)
> > > [    5.589297] fb0: switching to vc4drmfb from simple
> > > [    5.589433] Console: switching to colour dummy device 80x25
> > > [    5.589481] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> > > [    5.589816] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
> > > [    5.601079] ------------[ cut here ]------------
> > > [    5.601095] WARNING: CPU: 2 PID: 127 at drivers/gpu/drm/vc4/vc4_hdmi_phy.c:413 vc5_hdmi_phy_init+0x7ac/0x2078
> > > [    5.601097] Modules linked in:
> > > [    5.601103] CPU: 2 PID: 127 Comm: kworker/2:1 Not tainted 5.7.0-rc2-00091-ga181df59a930 #7
> > > [    5.601105] Hardware name: Raspberry Pi 4 Model B (DT)
> > > [    5.601112] Workqueue: events deferred_probe_work_func
> > > [    5.601116] pstate: 20000005 (nzCv daif -PAN -UAO)
> > > [    5.601119] pc : vc5_hdmi_phy_init+0x7ac/0x2078
> > > [    5.601123] lr : vc4_hdmi_encoder_enable+0x1b8/0x1ac0
> > > [    5.601124] sp : ffff80001217b410
> > > [    5.601126] x29: ffff80001217b410 x28: ffff0000ec6370f0
> > > [    5.601129] x27: ffff0000f650d400 x26: 000000008a500000
> > > [    5.601132] x25: ffff8000113b4ac0 x24: 0000000000002060
> > > [    5.601135] x23: 000000000a500000 x22: 0000000000000300
> > > [    5.601137] x21: 0000000008d9ee20 x20: ffff0000ec535080
> > > [    5.601140] x19: 000000010989e7c0 x18: 0000000000000000
> > > [    5.601142] x17: 0000000000000001 x16: 0000000000005207
> > > [    5.601145] x15: 00004932ad293c92 x14: 0000000000000137
> > > [    5.601147] x13: ffff800010015000 x12: 0000000000000001
> > > [    5.601150] x11: 0000000000000001 x10: 0000000000000000
> > > [    5.601152] x9 : 0000000000000000 x8 : ffff800010015038
> > > [    5.601154] x7 : 0000000000000001 x6 : ffff80001217b368
> > > [    5.601157] x5 : 0000000000000000 x4 : 000000000000004c
> > > [    5.601159] x3 : 0000000000000000 x2 : ffff8000113b4ac0
> > > [    5.601162] x1 : ffff8000120c5f44 x0 : 00000000dc8984ff
> > > [    5.601164] Call trace:
> > > [    5.601169]  vc5_hdmi_phy_init+0x7ac/0x2078
> > > [    5.601172]  vc4_hdmi_encoder_enable+0x1b8/0x1ac0
> > > [    5.601176]  drm_atomic_helper_commit_modeset_enables+0x224/0x248
> > > [    5.601179]  vc4_atomic_complete_commit+0x400/0x558
> > > [    5.601182]  vc4_atomic_commit+0x1e0/0x200
> > > [    5.601185]  drm_atomic_commit+0x4c/0x60
> > > [    5.601190]  drm_client_modeset_commit_atomic.isra.0+0x17c/0x238
> > > [    5.601192]  drm_client_modeset_commit_locked+0x5c/0x198
> > > [    5.601195]  drm_client_modeset_commit+0x30/0x58
> > > [    5.601201]  drm_fb_helper_restore_fbdev_mode_unlocked+0x78/0xe0
> > > [    5.601204]  drm_fb_helper_set_par+0x30/0x68
> > > [    5.601208]  fbcon_init+0x3d4/0x598
> > > [    5.601212]  visual_init+0xb0/0x108
> > > [    5.601214]  do_bind_con_driver+0x1d0/0x3a8
> > > [    5.601217]  do_take_over_console+0x144/0x208
> > > [    5.601219]  do_fbcon_takeover+0x68/0xd8
> > > [    5.601222]  fbcon_fb_registered+0x100/0x118
> > > [    5.601226]  register_framebuffer+0x1f4/0x338
> > > [    5.601229]  __drm_fb_helper_initial_config_and_unlock+0x2f8/0x4a0
> > > [    5.601232]  drm_fbdev_client_hotplug+0xd4/0x1b0
> > > [    5.601235]  drm_fbdev_generic_setup+0xb0/0x130
> > > [    5.601238]  vc4_drm_bind+0x184/0x1a0
> > > [    5.601241]  try_to_bring_up_master+0x168/0x1c8
> > > [    5.601244]  __component_add+0xa4/0x170
> > > [    5.601246]  component_add+0x14/0x20
> > > [    5.601248]  vc4_vec_dev_probe+0x20/0x30
> > > [    5.601252]  platform_drv_probe+0x54/0xa8
> > > [    5.601254]  really_probe+0xd8/0x320
> > > [    5.601256]  driver_probe_device+0x58/0xf0
> > > [    5.601258]  __device_attach_driver+0x84/0xc8
> > > [    5.601263]  bus_for_each_drv+0x78/0xc8
> > > [    5.601265]  __device_attach+0xe4/0x140
> > > [    5.601267]  device_initial_probe+0x14/0x20
> > > [    5.601269]  bus_probe_device+0x9c/0xa8
> > > [    5.601271]  deferred_probe_work_func+0x74/0xb0
> > > [    5.601276]  process_one_work+0x1bc/0x338
> > > [    5.601279]  worker_thread+0x1f8/0x428
> > > [    5.601282]  kthread+0x138/0x158
> > > [    5.601286]  ret_from_fork+0x10/0x1c
> > > [    5.601288] ---[ end trace cfba0996218c3f3d ]---
> >
> > Thanks for testing!
> >
> > Do you have a bit more details regarding your setup? Was it connected to an
> > external display?
> 
> Yes, the HDMI cable is connected to HDMI0 port on RPi 4.
> 
> > If so, do you know the resolution it was trying to setup?
> 
> According to the log, I think it is 1920x1080:
> Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> HDMI-1 connected
> Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> HDMI-2 disconnected
> Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> Composite-1 disconnected
> Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Using
> exact sizes for initial modes
> Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> HDMI-1 using initial mode 1920x1080 +0+0
> 
> https://gist.github.com/starnight/45e1468bfa0426a54d2fb4a9269cfb94

It looks to be fairly standard then, and I'm testing on the same resolution so
it should be alright.

Given from your log, it looks like you're running as arm64 though, while I stuck
with arm32, so it could be the explanation.

Can you share your config.txt and .config so that I can try to reproduce it
here?

Thanks!
Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
  2020-05-07 17:21       ` Maxime Ripard
@ 2020-05-08  6:20         ` Jian-Hong Pan
  2020-05-11  3:12           ` Jian-Hong Pan
  0 siblings, 1 reply; 49+ messages in thread
From: Jian-Hong Pan @ 2020-05-08  6:20 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Nicolas Saenz Julienne, Eric Anholt, dri-devel, linux-rpi-kernel,
	bcm-kernel-feedback-list, linux-arm-kernel, Linux Kernel,
	devicetree, linux-clk, linux-i2c, Linux Upstreaming Team

Maxime Ripard <maxime@cerno.tech> 於 2020年5月8日 週五 上午1:22寫道:
>
> On Mon, May 04, 2020 at 02:35:08PM +0800, Jian-Hong Pan wrote:
> > Maxime Ripard <maxime@cerno.tech> 於 2020年4月29日 週三 上午12:21寫道:
> > >
> > > Hi,
> > >
> > > On Mon, Apr 27, 2020 at 03:23:42PM +0800, Jian-Hong Pan wrote:
> > > > Hi Maxime,
> > > >
> > > > Thanks for your V2 patch series!  I'm testing it.
> > > >
> > > > This patch series is applied upon mainline kernel 5.7-rc2 cleanly and built.
> > > > System can boot into console text mode, but no graphic UI.
> > > >
> > > > Get the error in vc5_hdmi_phy_init(), and full dmesg is at [1]:
> > > >
> > > > [    5.587543] vc4_hdmi fef00700.hdmi: Unknown register ID 46
> > > > [    5.587700] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi' already present!
> > > > [    5.588070] vc4_hdmi fef00700.hdmi: vc4-hdmi-hifi <-> fef00700.hdmi mapping ok
> > > > [    5.588076] vc4_hdmi fef00700.hdmi: ASoC: no DMI vendor name!
> > > > [    5.588263] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops)
> > > > [    5.588299] vc4_hdmi fef05700.hdmi: Unknown register ID 46
> > > > [    5.588373] debugfs: Directory 'vc4-hdmi' with parent 'asoc' already present!
> > > > [    5.588673] vc4_hdmi fef05700.hdmi: vc4-hdmi-hifi <-> fef05700.hdmi mapping ok
> > > > [    5.588677] vc4_hdmi fef05700.hdmi: ASoC: no DMI vendor name!
> > > > [    5.588809] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops)
> > > > [    5.588854] vc4-drm gpu: bound fe806000.vec (ops vc4_vec_ops)
> > > > [    5.588897] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops)
> > > > [    5.588934] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops)
> > > > [    5.588990] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops)
> > > > [    5.589030] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops)
> > > > [    5.589074] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops)
> > > > [    5.589106] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops)
> > > > [    5.589145] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops)
> > > > [    5.589294] checking generic (3e513000 6d8c00) vs hw (0 ffffffffffffffff)
> > > > [    5.589297] fb0: switching to vc4drmfb from simple
> > > > [    5.589433] Console: switching to colour dummy device 80x25
> > > > [    5.589481] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> > > > [    5.589816] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
> > > > [    5.601079] ------------[ cut here ]------------
> > > > [    5.601095] WARNING: CPU: 2 PID: 127 at drivers/gpu/drm/vc4/vc4_hdmi_phy.c:413 vc5_hdmi_phy_init+0x7ac/0x2078
> > > > [    5.601097] Modules linked in:
> > > > [    5.601103] CPU: 2 PID: 127 Comm: kworker/2:1 Not tainted 5.7.0-rc2-00091-ga181df59a930 #7
> > > > [    5.601105] Hardware name: Raspberry Pi 4 Model B (DT)
> > > > [    5.601112] Workqueue: events deferred_probe_work_func
> > > > [    5.601116] pstate: 20000005 (nzCv daif -PAN -UAO)
> > > > [    5.601119] pc : vc5_hdmi_phy_init+0x7ac/0x2078
> > > > [    5.601123] lr : vc4_hdmi_encoder_enable+0x1b8/0x1ac0
> > > > [    5.601124] sp : ffff80001217b410
> > > > [    5.601126] x29: ffff80001217b410 x28: ffff0000ec6370f0
> > > > [    5.601129] x27: ffff0000f650d400 x26: 000000008a500000
> > > > [    5.601132] x25: ffff8000113b4ac0 x24: 0000000000002060
> > > > [    5.601135] x23: 000000000a500000 x22: 0000000000000300
> > > > [    5.601137] x21: 0000000008d9ee20 x20: ffff0000ec535080
> > > > [    5.601140] x19: 000000010989e7c0 x18: 0000000000000000
> > > > [    5.601142] x17: 0000000000000001 x16: 0000000000005207
> > > > [    5.601145] x15: 00004932ad293c92 x14: 0000000000000137
> > > > [    5.601147] x13: ffff800010015000 x12: 0000000000000001
> > > > [    5.601150] x11: 0000000000000001 x10: 0000000000000000
> > > > [    5.601152] x9 : 0000000000000000 x8 : ffff800010015038
> > > > [    5.601154] x7 : 0000000000000001 x6 : ffff80001217b368
> > > > [    5.601157] x5 : 0000000000000000 x4 : 000000000000004c
> > > > [    5.601159] x3 : 0000000000000000 x2 : ffff8000113b4ac0
> > > > [    5.601162] x1 : ffff8000120c5f44 x0 : 00000000dc8984ff
> > > > [    5.601164] Call trace:
> > > > [    5.601169]  vc5_hdmi_phy_init+0x7ac/0x2078
> > > > [    5.601172]  vc4_hdmi_encoder_enable+0x1b8/0x1ac0
> > > > [    5.601176]  drm_atomic_helper_commit_modeset_enables+0x224/0x248
> > > > [    5.601179]  vc4_atomic_complete_commit+0x400/0x558
> > > > [    5.601182]  vc4_atomic_commit+0x1e0/0x200
> > > > [    5.601185]  drm_atomic_commit+0x4c/0x60
> > > > [    5.601190]  drm_client_modeset_commit_atomic.isra.0+0x17c/0x238
> > > > [    5.601192]  drm_client_modeset_commit_locked+0x5c/0x198
> > > > [    5.601195]  drm_client_modeset_commit+0x30/0x58
> > > > [    5.601201]  drm_fb_helper_restore_fbdev_mode_unlocked+0x78/0xe0
> > > > [    5.601204]  drm_fb_helper_set_par+0x30/0x68
> > > > [    5.601208]  fbcon_init+0x3d4/0x598
> > > > [    5.601212]  visual_init+0xb0/0x108
> > > > [    5.601214]  do_bind_con_driver+0x1d0/0x3a8
> > > > [    5.601217]  do_take_over_console+0x144/0x208
> > > > [    5.601219]  do_fbcon_takeover+0x68/0xd8
> > > > [    5.601222]  fbcon_fb_registered+0x100/0x118
> > > > [    5.601226]  register_framebuffer+0x1f4/0x338
> > > > [    5.601229]  __drm_fb_helper_initial_config_and_unlock+0x2f8/0x4a0
> > > > [    5.601232]  drm_fbdev_client_hotplug+0xd4/0x1b0
> > > > [    5.601235]  drm_fbdev_generic_setup+0xb0/0x130
> > > > [    5.601238]  vc4_drm_bind+0x184/0x1a0
> > > > [    5.601241]  try_to_bring_up_master+0x168/0x1c8
> > > > [    5.601244]  __component_add+0xa4/0x170
> > > > [    5.601246]  component_add+0x14/0x20
> > > > [    5.601248]  vc4_vec_dev_probe+0x20/0x30
> > > > [    5.601252]  platform_drv_probe+0x54/0xa8
> > > > [    5.601254]  really_probe+0xd8/0x320
> > > > [    5.601256]  driver_probe_device+0x58/0xf0
> > > > [    5.601258]  __device_attach_driver+0x84/0xc8
> > > > [    5.601263]  bus_for_each_drv+0x78/0xc8
> > > > [    5.601265]  __device_attach+0xe4/0x140
> > > > [    5.601267]  device_initial_probe+0x14/0x20
> > > > [    5.601269]  bus_probe_device+0x9c/0xa8
> > > > [    5.601271]  deferred_probe_work_func+0x74/0xb0
> > > > [    5.601276]  process_one_work+0x1bc/0x338
> > > > [    5.601279]  worker_thread+0x1f8/0x428
> > > > [    5.601282]  kthread+0x138/0x158
> > > > [    5.601286]  ret_from_fork+0x10/0x1c
> > > > [    5.601288] ---[ end trace cfba0996218c3f3d ]---
> > >
> > > Thanks for testing!
> > >
> > > Do you have a bit more details regarding your setup? Was it connected to an
> > > external display?
> >
> > Yes, the HDMI cable is connected to HDMI0 port on RPi 4.
> >
> > > If so, do you know the resolution it was trying to setup?
> >
> > According to the log, I think it is 1920x1080:
> > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > HDMI-1 connected
> > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > HDMI-2 disconnected
> > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > Composite-1 disconnected
> > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Using
> > exact sizes for initial modes
> > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > HDMI-1 using initial mode 1920x1080 +0+0
> >
> > https://gist.github.com/starnight/45e1468bfa0426a54d2fb4a9269cfb94
>
> It looks to be fairly standard then, and I'm testing on the same resolution so
> it should be alright.
>
> Given from your log, it looks like you're running as arm64 though, while I stuck
> with arm32, so it could be the explanation.

Yes, I build it as arm64.

> Can you share your config.txt and .config so that I can try to reproduce it
> here?

Here is the config
https://gist.github.com/starnight/320b757441b6769c36160704b401c98b

Thanks,
Jian-Hong Pan

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
  2020-05-08  6:20         ` Jian-Hong Pan
@ 2020-05-11  3:12           ` Jian-Hong Pan
  2020-05-25 11:11             ` Maxime Ripard
  2020-05-26 10:20             ` Maxime Ripard
  0 siblings, 2 replies; 49+ messages in thread
From: Jian-Hong Pan @ 2020-05-11  3:12 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Nicolas Saenz Julienne, Eric Anholt, dri-devel, linux-rpi-kernel,
	bcm-kernel-feedback-list, linux-arm-kernel, Linux Kernel,
	devicetree, linux-clk, linux-i2c, Linux Upstreaming Team

Jian-Hong Pan <jian-hong@endlessm.com> 於 2020年5月8日 週五 下午2:20寫道:
>
> Maxime Ripard <maxime@cerno.tech> 於 2020年5月8日 週五 上午1:22寫道:
> >
> > On Mon, May 04, 2020 at 02:35:08PM +0800, Jian-Hong Pan wrote:
> > > Maxime Ripard <maxime@cerno.tech> 於 2020年4月29日 週三 上午12:21寫道:
> > > >
> > > > Hi,
> > > >
> > > > On Mon, Apr 27, 2020 at 03:23:42PM +0800, Jian-Hong Pan wrote:
> > > > > Hi Maxime,
> > > > >
> > > > > Thanks for your V2 patch series!  I'm testing it.
> > > > >
> > > > > This patch series is applied upon mainline kernel 5.7-rc2 cleanly and built.
> > > > > System can boot into console text mode, but no graphic UI.
> > > > >
> > > > > Get the error in vc5_hdmi_phy_init(), and full dmesg is at [1]:
> > > > >
> > > > > [    5.587543] vc4_hdmi fef00700.hdmi: Unknown register ID 46
> > > > > [    5.587700] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi' already present!
> > > > > [    5.588070] vc4_hdmi fef00700.hdmi: vc4-hdmi-hifi <-> fef00700.hdmi mapping ok
> > > > > [    5.588076] vc4_hdmi fef00700.hdmi: ASoC: no DMI vendor name!
> > > > > [    5.588263] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops)
> > > > > [    5.588299] vc4_hdmi fef05700.hdmi: Unknown register ID 46
> > > > > [    5.588373] debugfs: Directory 'vc4-hdmi' with parent 'asoc' already present!
> > > > > [    5.588673] vc4_hdmi fef05700.hdmi: vc4-hdmi-hifi <-> fef05700.hdmi mapping ok
> > > > > [    5.588677] vc4_hdmi fef05700.hdmi: ASoC: no DMI vendor name!
> > > > > [    5.588809] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops)
> > > > > [    5.588854] vc4-drm gpu: bound fe806000.vec (ops vc4_vec_ops)
> > > > > [    5.588897] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops)
> > > > > [    5.588934] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops)
> > > > > [    5.588990] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops)
> > > > > [    5.589030] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops)
> > > > > [    5.589074] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops)
> > > > > [    5.589106] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops)
> > > > > [    5.589145] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops)
> > > > > [    5.589294] checking generic (3e513000 6d8c00) vs hw (0 ffffffffffffffff)
> > > > > [    5.589297] fb0: switching to vc4drmfb from simple
> > > > > [    5.589433] Console: switching to colour dummy device 80x25
> > > > > [    5.589481] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> > > > > [    5.589816] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
> > > > > [    5.601079] ------------[ cut here ]------------
> > > > > [    5.601095] WARNING: CPU: 2 PID: 127 at drivers/gpu/drm/vc4/vc4_hdmi_phy.c:413 vc5_hdmi_phy_init+0x7ac/0x2078
> > > > > [    5.601097] Modules linked in:
> > > > > [    5.601103] CPU: 2 PID: 127 Comm: kworker/2:1 Not tainted 5.7.0-rc2-00091-ga181df59a930 #7
> > > > > [    5.601105] Hardware name: Raspberry Pi 4 Model B (DT)
> > > > > [    5.601112] Workqueue: events deferred_probe_work_func
> > > > > [    5.601116] pstate: 20000005 (nzCv daif -PAN -UAO)
> > > > > [    5.601119] pc : vc5_hdmi_phy_init+0x7ac/0x2078
> > > > > [    5.601123] lr : vc4_hdmi_encoder_enable+0x1b8/0x1ac0
> > > > > [    5.601124] sp : ffff80001217b410
> > > > > [    5.601126] x29: ffff80001217b410 x28: ffff0000ec6370f0
> > > > > [    5.601129] x27: ffff0000f650d400 x26: 000000008a500000
> > > > > [    5.601132] x25: ffff8000113b4ac0 x24: 0000000000002060
> > > > > [    5.601135] x23: 000000000a500000 x22: 0000000000000300
> > > > > [    5.601137] x21: 0000000008d9ee20 x20: ffff0000ec535080
> > > > > [    5.601140] x19: 000000010989e7c0 x18: 0000000000000000
> > > > > [    5.601142] x17: 0000000000000001 x16: 0000000000005207
> > > > > [    5.601145] x15: 00004932ad293c92 x14: 0000000000000137
> > > > > [    5.601147] x13: ffff800010015000 x12: 0000000000000001
> > > > > [    5.601150] x11: 0000000000000001 x10: 0000000000000000
> > > > > [    5.601152] x9 : 0000000000000000 x8 : ffff800010015038
> > > > > [    5.601154] x7 : 0000000000000001 x6 : ffff80001217b368
> > > > > [    5.601157] x5 : 0000000000000000 x4 : 000000000000004c
> > > > > [    5.601159] x3 : 0000000000000000 x2 : ffff8000113b4ac0
> > > > > [    5.601162] x1 : ffff8000120c5f44 x0 : 00000000dc8984ff
> > > > > [    5.601164] Call trace:
> > > > > [    5.601169]  vc5_hdmi_phy_init+0x7ac/0x2078
> > > > > [    5.601172]  vc4_hdmi_encoder_enable+0x1b8/0x1ac0
> > > > > [    5.601176]  drm_atomic_helper_commit_modeset_enables+0x224/0x248
> > > > > [    5.601179]  vc4_atomic_complete_commit+0x400/0x558
> > > > > [    5.601182]  vc4_atomic_commit+0x1e0/0x200
> > > > > [    5.601185]  drm_atomic_commit+0x4c/0x60
> > > > > [    5.601190]  drm_client_modeset_commit_atomic.isra.0+0x17c/0x238
> > > > > [    5.601192]  drm_client_modeset_commit_locked+0x5c/0x198
> > > > > [    5.601195]  drm_client_modeset_commit+0x30/0x58
> > > > > [    5.601201]  drm_fb_helper_restore_fbdev_mode_unlocked+0x78/0xe0
> > > > > [    5.601204]  drm_fb_helper_set_par+0x30/0x68
> > > > > [    5.601208]  fbcon_init+0x3d4/0x598
> > > > > [    5.601212]  visual_init+0xb0/0x108
> > > > > [    5.601214]  do_bind_con_driver+0x1d0/0x3a8
> > > > > [    5.601217]  do_take_over_console+0x144/0x208
> > > > > [    5.601219]  do_fbcon_takeover+0x68/0xd8
> > > > > [    5.601222]  fbcon_fb_registered+0x100/0x118
> > > > > [    5.601226]  register_framebuffer+0x1f4/0x338
> > > > > [    5.601229]  __drm_fb_helper_initial_config_and_unlock+0x2f8/0x4a0
> > > > > [    5.601232]  drm_fbdev_client_hotplug+0xd4/0x1b0
> > > > > [    5.601235]  drm_fbdev_generic_setup+0xb0/0x130
> > > > > [    5.601238]  vc4_drm_bind+0x184/0x1a0
> > > > > [    5.601241]  try_to_bring_up_master+0x168/0x1c8
> > > > > [    5.601244]  __component_add+0xa4/0x170
> > > > > [    5.601246]  component_add+0x14/0x20
> > > > > [    5.601248]  vc4_vec_dev_probe+0x20/0x30
> > > > > [    5.601252]  platform_drv_probe+0x54/0xa8
> > > > > [    5.601254]  really_probe+0xd8/0x320
> > > > > [    5.601256]  driver_probe_device+0x58/0xf0
> > > > > [    5.601258]  __device_attach_driver+0x84/0xc8
> > > > > [    5.601263]  bus_for_each_drv+0x78/0xc8
> > > > > [    5.601265]  __device_attach+0xe4/0x140
> > > > > [    5.601267]  device_initial_probe+0x14/0x20
> > > > > [    5.601269]  bus_probe_device+0x9c/0xa8
> > > > > [    5.601271]  deferred_probe_work_func+0x74/0xb0
> > > > > [    5.601276]  process_one_work+0x1bc/0x338
> > > > > [    5.601279]  worker_thread+0x1f8/0x428
> > > > > [    5.601282]  kthread+0x138/0x158
> > > > > [    5.601286]  ret_from_fork+0x10/0x1c
> > > > > [    5.601288] ---[ end trace cfba0996218c3f3d ]---
> > > >
> > > > Thanks for testing!
> > > >
> > > > Do you have a bit more details regarding your setup? Was it connected to an
> > > > external display?
> > >
> > > Yes, the HDMI cable is connected to HDMI0 port on RPi 4.
> > >
> > > > If so, do you know the resolution it was trying to setup?
> > >
> > > According to the log, I think it is 1920x1080:
> > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > > HDMI-1 connected
> > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > > HDMI-2 disconnected
> > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > > Composite-1 disconnected
> > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Using
> > > exact sizes for initial modes
> > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > > HDMI-1 using initial mode 1920x1080 +0+0
> > >
> > > https://gist.github.com/starnight/45e1468bfa0426a54d2fb4a9269cfb94
> >
> > It looks to be fairly standard then, and I'm testing on the same resolution so
> > it should be alright.
> >
> > Given from your log, it looks like you're running as arm64 though, while I stuck
> > with arm32, so it could be the explanation.
>
> Yes, I build it as arm64.
>
> > Can you share your config.txt and .config so that I can try to reproduce it
> > here?
>
> Here is the config
> https://gist.github.com/starnight/320b757441b6769c36160704b401c98b

Here is the only one line in config.txt:
enable_uart=1

Actually, we make the Raspberry Pi's firmware bring up U-Boot, then
U-Boot boots kernel.

Jian-Hong Pan

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 03/91] dt-bindings: clock: Add a binding for the RPi Firmware clocks
  2020-04-24 15:33 ` [PATCH v2 03/91] dt-bindings: clock: Add a binding for the RPi Firmware clocks Maxime Ripard
@ 2020-05-11 21:47   ` Rob Herring
  2020-05-13  8:13     ` Maxime Ripard
  0 siblings, 1 reply; 49+ messages in thread
From: Rob Herring @ 2020-05-11 21:47 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Nicolas Saenz Julienne, Eric Anholt, dri-devel, linux-rpi-kernel,
	bcm-kernel-feedback-list, linux-arm-kernel, linux-kernel,
	Dave Stevenson, Tim Gover, Phil Elwell, Michael Turquette,
	Stephen Boyd, linux-clk, devicetree

On Fri, Apr 24, 2020 at 05:33:44PM +0200, Maxime Ripard wrote:
> The firmware running on the RPi VideoCore can be used to discover and
> change the various clocks running in the BCM2711. Since devices will
> need to use them through the DT, let's add a pretty simple binding.
> 
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: linux-clk@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---
>  Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> index cec540c052b6..b48ed875eb8e 100644
> --- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> +++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> @@ -22,6 +22,25 @@ properties:
>        Phandle to the firmware device's Mailbox.
>        (See: ../mailbox/mailbox.txt for more information)
>  
> +  clocks:
> +    type: object
> +
> +    properties:
> +      compatible:
> +        const: raspberrypi,firmware-clocks
> +
> +      "#clock-cells":
> +        const: 1
> +        description: >
> +          The argument is the ID of the clocks contained by the
> +          firmware messages.

Not really any reason to make this a child node. The parent can be a 
clock provider.

> +
> +    required:
> +      - compatible
> +      - "#clock-cells"
> +
> +    additionalProperties: false
> +
>  required:
>    - compatible
>    - mboxes
> @@ -31,5 +50,10 @@ examples:
>      firmware {
>          compatible = "raspberrypi,bcm2835-firmware", "simple-bus";
>          mboxes = <&mailbox>;
> +
> +        firmware_clocks: clocks {
> +            compatible = "raspberrypi,firmware-clocks";
> +            #clock-cells = <1>;
> +        };
>      };
>  ...
> -- 
> git-series 0.9.1

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 03/91] dt-bindings: clock: Add a binding for the RPi Firmware clocks
  2020-05-11 21:47   ` Rob Herring
@ 2020-05-13  8:13     ` Maxime Ripard
  0 siblings, 0 replies; 49+ messages in thread
From: Maxime Ripard @ 2020-05-13  8:13 UTC (permalink / raw)
  To: Rob Herring
  Cc: Nicolas Saenz Julienne, Eric Anholt, dri-devel, linux-rpi-kernel,
	bcm-kernel-feedback-list, linux-arm-kernel, linux-kernel,
	Dave Stevenson, Tim Gover, Phil Elwell, Michael Turquette,
	Stephen Boyd, linux-clk, devicetree

[-- Attachment #1: Type: text/plain, Size: 2140 bytes --]

Hi Rob,

On Mon, May 11, 2020 at 04:47:27PM -0500, Rob Herring wrote:
> On Fri, Apr 24, 2020 at 05:33:44PM +0200, Maxime Ripard wrote:
> > The firmware running on the RPi VideoCore can be used to discover and
> > change the various clocks running in the BCM2711. Since devices will
> > need to use them through the DT, let's add a pretty simple binding.
> > 
> > Cc: Michael Turquette <mturquette@baylibre.com>
> > Cc: Stephen Boyd <sboyd@kernel.org>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > Cc: linux-clk@vger.kernel.org
> > Cc: devicetree@vger.kernel.org
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > ---
> >  Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 24 ++++++++++++++++++++++++
> >  1 file changed, 24 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> > index cec540c052b6..b48ed875eb8e 100644
> > --- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> > +++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> > @@ -22,6 +22,25 @@ properties:
> >        Phandle to the firmware device's Mailbox.
> >        (See: ../mailbox/mailbox.txt for more information)
> >  
> > +  clocks:
> > +    type: object
> > +
> > +    properties:
> > +      compatible:
> > +        const: raspberrypi,firmware-clocks
> > +
> > +      "#clock-cells":
> > +        const: 1
> > +        description: >
> > +          The argument is the ID of the clocks contained by the
> > +          firmware messages.
> 
> Not really any reason to make this a child node. The parent can be a 
> clock provider.

This was meant to provide some consistency for that driver. It already has a nod
for the GPIOs exposed through the firmware in the RPi where you could make the
exact same argument, so I guess that, while we shouldn't make the same choices
if we had to design it from scratch, it's more important to keep the same design
choices for a given binding?

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 20/91] clk: bcm: rpi: Discover the firmware clocks
  2020-05-04 12:05   ` Nicolas Saenz Julienne
@ 2020-05-15  8:19     ` Maxime Ripard
  2020-05-21  9:13       ` Nicolas Saenz Julienne
  0 siblings, 1 reply; 49+ messages in thread
From: Maxime Ripard @ 2020-05-15  8:19 UTC (permalink / raw)
  To: Nicolas Saenz Julienne
  Cc: Eric Anholt, Tim Gover, Dave Stevenson, Stephen Boyd,
	Michael Turquette, linux-kernel, dri-devel, linux-clk,
	bcm-kernel-feedback-list, linux-rpi-kernel, Phil Elwell,
	linux-arm-kernel

[-- Attachment #1: Type: text/plain, Size: 5543 bytes --]

Hi Nicolas,

On Mon, May 04, 2020 at 02:05:47PM +0200, Nicolas Saenz Julienne wrote:
> Hi Maxime, as always, thanks for the series!
> Some extra context, and comments below.
> 
> On Fri, 2020-04-24 at 17:34 +0200, Maxime Ripard wrote:
> > The RaspberryPi4 firmware actually exposes more clocks than are currently
> > handled by the driver and we will need to change some of them directly
> > based on the pixel rate for the display related clocks, or the load for the
> > GPU.
> > 
> > This rate change can have a number of side-effects, including adjusting the
> > various PLL voltages or the PLL parents. The firmware will also update
> > those clocks by itself for example if the SoC runs too hot.
> 
> To complete this:
> 
> RPi4's firmware implements DVFS. Clock frequency and SoC voltage are
> correlated, if you can determine all clocks are running below a maximum then it
> should be safe to lower the voltage. Currently, firmware actively monitors arm,
> core, h264, v3d, isp and hevc to determine what voltage can be reduced to, and
> if arm increases any of those clocks behind the firmware's back, when it has a
> lowered voltage, a crash is highly likely.
> 
> As pointed out to me by RPi foundation engineers hsm/pixel aren't currently
> being monitored, as driving a high resolution display also requires a high core
> clock, which already sets an acceptable min voltage threshold. But that might
> change if needed.
> 
> Ultimately, from the DVFS, the safe way to change clocks from arm would be to
> always use the firmware interface, which we're far from doing right now. On the
> other hand, AFAIK not all clocks have a firmware counterpart.
> 
> Note that we could also have a word with the RPi foundation and see if
> disabling DVFS is possible (AFAIK it's not an option right now). Although I
> personally prefer to support this upstream, aside from the obvious benefits to
> battery powered use cases, not consuming power unnecessarily is always big
> plus.
> 
> > In order to make Linux play as nice as possible with those constraints, it
> > makes sense to rely on the firmware clocks as much as possible.
> 
> As I comment above, not as simple as it seems. I suggest, for now, we only
> register the clocks we're going to use and that are likely to be affected by
> DVFS. hsm being a contender here.
> 
> As we'd be settling on a hybrid solution here, which isn't ideal to say the
> least, I'd like to gather some opinions on whether pushing towards a fully
> firmware based solution is something you'd like to see.

Thanks for the summary above, I'll try to adjust that commit log to reflect
this. As for my opinion, I don't really think that an hybrid approach is
practical, since that would leave us with weird interactions between the
firmware (and possibly multiple versinos of it) and the linux driver, and this
would be pretty hard to maintain in the long run.

That leaves us either the MMIO-based driver or the firmware-based one, and here
with what you said above, at the moment, the firmware based one is a clear
winner.

> > Fortunately,t he firmware has an interface to discover the clocks it
> > exposes.
> 
> nit: wrongly placed space
> 
> > Let's use it to discover, register the clocks in the clocks framework and
> > then expose them through the device tree for consumers to use them.
> >
> > Cc: Michael Turquette <mturquette@baylibre.com>
> > Cc: Stephen Boyd <sboyd@kernel.org>
> > Cc: linux-clk@vger.kernel.org
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > ---
> >  drivers/clk/bcm/clk-raspberrypi.c          | 104 +++++++++++++++++++---
> 
> [...]
> 
> > +static struct clk_hw *raspberrypi_clk_register(struct raspberrypi_clk *rpi,
> > +					       unsigned int parent,
> > +					       unsigned int id)
> > +{
> > +	struct raspberrypi_clk_data *data;
> > +	struct clk_init_data init = {};
> > +	int ret;
> > +
> > +	if (id == RPI_FIRMWARE_ARM_CLK_ID) {
> > +		struct clk_hw *hw;
> > +
> > +		hw = raspberrypi_register_pllb(rpi);
> > +		if (IS_ERR(hw)) {
> > +			dev_err(rpi->dev, "Failed to initialize pllb, %ld\n",
> > +				PTR_ERR(hw));
> > +			return hw;
> > +		}
> > +
> > +		return raspberrypi_register_pllb_arm(rpi);
> > +	}
> 
> We shouldn't create a special case for pllb. My suggestion here is that we
> revert the commit that removed pllb from the mmio driver, in order to maintain
> a nice view of the clock tree, and register this as a regular fw-clk.
> 
> The only user to this is RPi's the cpufreq driver, which shouldn't mind the
> change as long as you maintain the clk lookup creation.

Ok, I'll change that.

> On that topic, now that the clocks are available in DT we could even move
> raspberrypi-cpufreq's registration there. But that's out of the scope of this
> series.
> 
> > +
> > +	data = devm_kzalloc(rpi->dev, sizeof(*data), GFP_KERNEL);
> > +	if (!data)
> > +		return ERR_PTR(-ENOMEM);
> > +	data->rpi = rpi;
> > +	data->id = id;
> > +
> > +	init.name = devm_kasprintf(rpi->dev, GFP_KERNEL, "fw-clk-%u", id);
> 
> I'd really like more descriptive names here, sadly the firmware interface
> doesn't provide them, but they are set in stone nonetheless. Something like
> 'fw-clk-arm' and 'fw-clk-hsm' comes to mind (SCMI does provide naming BTW).
> 
> See here for a list of all clocks:
> https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface#clocks

That's a good idea, I'll add that too.

Thanks!
Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 20/91] clk: bcm: rpi: Discover the firmware clocks
  2020-05-15  8:19     ` Maxime Ripard
@ 2020-05-21  9:13       ` Nicolas Saenz Julienne
  0 siblings, 0 replies; 49+ messages in thread
From: Nicolas Saenz Julienne @ 2020-05-21  9:13 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Eric Anholt, Tim Gover, Dave Stevenson, Stephen Boyd,
	Michael Turquette, linux-kernel, dri-devel, linux-clk,
	bcm-kernel-feedback-list, linux-rpi-kernel, Phil Elwell,
	linux-arm-kernel

[-- Attachment #1: Type: text/plain, Size: 3581 bytes --]

Hi Maxime,

On Fri, 2020-05-15 at 10:19 +0200, Maxime Ripard wrote:
> Hi Nicolas,
> 
> On Mon, May 04, 2020 at 02:05:47PM +0200, Nicolas Saenz Julienne wrote:
> > Hi Maxime, as always, thanks for the series!
> > Some extra context, and comments below.
> > 
> > On Fri, 2020-04-24 at 17:34 +0200, Maxime Ripard wrote:
> > > The RaspberryPi4 firmware actually exposes more clocks than are currently
> > > handled by the driver and we will need to change some of them directly
> > > based on the pixel rate for the display related clocks, or the load for
> > > the
> > > GPU.
> > > 
> > > This rate change can have a number of side-effects, including adjusting
> > > the
> > > various PLL voltages or the PLL parents. The firmware will also update
> > > those clocks by itself for example if the SoC runs too hot.
> > 
> > To complete this:
> > 
> > RPi4's firmware implements DVFS. Clock frequency and SoC voltage are
> > correlated, if you can determine all clocks are running below a maximum then
> > it
> > should be safe to lower the voltage. Currently, firmware actively monitors
> > arm,
> > core, h264, v3d, isp and hevc to determine what voltage can be reduced to,
> > and
> > if arm increases any of those clocks behind the firmware's back, when it has
> > a
> > lowered voltage, a crash is highly likely.
> > 
> > As pointed out to me by RPi foundation engineers hsm/pixel aren't currently
> > being monitored, as driving a high resolution display also requires a high
> > core
> > clock, which already sets an acceptable min voltage threshold. But that
> > might
> > change if needed.
> > 
> > Ultimately, from the DVFS, the safe way to change clocks from arm would be
> > to
> > always use the firmware interface, which we're far from doing right now. On
> > the
> > other hand, AFAIK not all clocks have a firmware counterpart.
> > 
> > Note that we could also have a word with the RPi foundation and see if
> > disabling DVFS is possible (AFAIK it's not an option right now). Although I
> > personally prefer to support this upstream, aside from the obvious benefits
> > to
> > battery powered use cases, not consuming power unnecessarily is always big
> > plus.
> > 
> > > In order to make Linux play as nice as possible with those constraints, it
> > > makes sense to rely on the firmware clocks as much as possible.
> > 
> > As I comment above, not as simple as it seems. I suggest, for now, we only
> > register the clocks we're going to use and that are likely to be affected by
> > DVFS. hsm being a contender here.
> > 
> > As we'd be settling on a hybrid solution here, which isn't ideal to say the
> > least, I'd like to gather some opinions on whether pushing towards a fully
> > firmware based solution is something you'd like to see.
> 
> Thanks for the summary above, I'll try to adjust that commit log to reflect
> this. As for my opinion, I don't really think that an hybrid approach is
> practical, since that would leave us with weird interactions between the
> firmware (and possibly multiple versinos of it) and the linux driver, and this
> would be pretty hard to maintain in the long run.
> 
> That leaves us either the MMIO-based driver or the firmware-based one, and
> here
> with what you said above, at the moment, the firmware based one is a clear
> winner.

We're on the same page here :)

My remaining concern is the fact there isn't a firmware counterpart to every
clock used right now. But it's something we can work out in the future.

Regards,
Nicolas


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
  2020-05-11  3:12           ` Jian-Hong Pan
@ 2020-05-25 11:11             ` Maxime Ripard
  2020-05-26 10:20             ` Maxime Ripard
  1 sibling, 0 replies; 49+ messages in thread
From: Maxime Ripard @ 2020-05-25 11:11 UTC (permalink / raw)
  To: Jian-Hong Pan
  Cc: Nicolas Saenz Julienne, Eric Anholt, dri-devel, linux-rpi-kernel,
	bcm-kernel-feedback-list, linux-arm-kernel, Linux Kernel,
	devicetree, linux-clk, linux-i2c, Linux Upstreaming Team

[-- Attachment #1: Type: text/plain, Size: 9081 bytes --]

Hi,

On Mon, May 11, 2020 at 11:12:05AM +0800, Jian-Hong Pan wrote:
> Jian-Hong Pan <jian-hong@endlessm.com> 於 2020年5月8日 週五 下午2:20寫道:
> >
> > Maxime Ripard <maxime@cerno.tech> 於 2020年5月8日 週五 上午1:22寫道:
> > >
> > > On Mon, May 04, 2020 at 02:35:08PM +0800, Jian-Hong Pan wrote:
> > > > Maxime Ripard <maxime@cerno.tech> 於 2020年4月29日 週三 上午12:21寫道:
> > > > >
> > > > > Hi,
> > > > >
> > > > > On Mon, Apr 27, 2020 at 03:23:42PM +0800, Jian-Hong Pan wrote:
> > > > > > Hi Maxime,
> > > > > >
> > > > > > Thanks for your V2 patch series!  I'm testing it.
> > > > > >
> > > > > > This patch series is applied upon mainline kernel 5.7-rc2 cleanly and built.
> > > > > > System can boot into console text mode, but no graphic UI.
> > > > > >
> > > > > > Get the error in vc5_hdmi_phy_init(), and full dmesg is at [1]:
> > > > > >
> > > > > > [    5.587543] vc4_hdmi fef00700.hdmi: Unknown register ID 46
> > > > > > [    5.587700] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi' already present!
> > > > > > [    5.588070] vc4_hdmi fef00700.hdmi: vc4-hdmi-hifi <-> fef00700.hdmi mapping ok
> > > > > > [    5.588076] vc4_hdmi fef00700.hdmi: ASoC: no DMI vendor name!
> > > > > > [    5.588263] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops)
> > > > > > [    5.588299] vc4_hdmi fef05700.hdmi: Unknown register ID 46
> > > > > > [    5.588373] debugfs: Directory 'vc4-hdmi' with parent 'asoc' already present!
> > > > > > [    5.588673] vc4_hdmi fef05700.hdmi: vc4-hdmi-hifi <-> fef05700.hdmi mapping ok
> > > > > > [    5.588677] vc4_hdmi fef05700.hdmi: ASoC: no DMI vendor name!
> > > > > > [    5.588809] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops)
> > > > > > [    5.588854] vc4-drm gpu: bound fe806000.vec (ops vc4_vec_ops)
> > > > > > [    5.588897] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops)
> > > > > > [    5.588934] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops)
> > > > > > [    5.588990] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops)
> > > > > > [    5.589030] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops)
> > > > > > [    5.589074] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops)
> > > > > > [    5.589106] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops)
> > > > > > [    5.589145] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops)
> > > > > > [    5.589294] checking generic (3e513000 6d8c00) vs hw (0 ffffffffffffffff)
> > > > > > [    5.589297] fb0: switching to vc4drmfb from simple
> > > > > > [    5.589433] Console: switching to colour dummy device 80x25
> > > > > > [    5.589481] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> > > > > > [    5.589816] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
> > > > > > [    5.601079] ------------[ cut here ]------------
> > > > > > [    5.601095] WARNING: CPU: 2 PID: 127 at drivers/gpu/drm/vc4/vc4_hdmi_phy.c:413 vc5_hdmi_phy_init+0x7ac/0x2078
> > > > > > [    5.601097] Modules linked in:
> > > > > > [    5.601103] CPU: 2 PID: 127 Comm: kworker/2:1 Not tainted 5.7.0-rc2-00091-ga181df59a930 #7
> > > > > > [    5.601105] Hardware name: Raspberry Pi 4 Model B (DT)
> > > > > > [    5.601112] Workqueue: events deferred_probe_work_func
> > > > > > [    5.601116] pstate: 20000005 (nzCv daif -PAN -UAO)
> > > > > > [    5.601119] pc : vc5_hdmi_phy_init+0x7ac/0x2078
> > > > > > [    5.601123] lr : vc4_hdmi_encoder_enable+0x1b8/0x1ac0
> > > > > > [    5.601124] sp : ffff80001217b410
> > > > > > [    5.601126] x29: ffff80001217b410 x28: ffff0000ec6370f0
> > > > > > [    5.601129] x27: ffff0000f650d400 x26: 000000008a500000
> > > > > > [    5.601132] x25: ffff8000113b4ac0 x24: 0000000000002060
> > > > > > [    5.601135] x23: 000000000a500000 x22: 0000000000000300
> > > > > > [    5.601137] x21: 0000000008d9ee20 x20: ffff0000ec535080
> > > > > > [    5.601140] x19: 000000010989e7c0 x18: 0000000000000000
> > > > > > [    5.601142] x17: 0000000000000001 x16: 0000000000005207
> > > > > > [    5.601145] x15: 00004932ad293c92 x14: 0000000000000137
> > > > > > [    5.601147] x13: ffff800010015000 x12: 0000000000000001
> > > > > > [    5.601150] x11: 0000000000000001 x10: 0000000000000000
> > > > > > [    5.601152] x9 : 0000000000000000 x8 : ffff800010015038
> > > > > > [    5.601154] x7 : 0000000000000001 x6 : ffff80001217b368
> > > > > > [    5.601157] x5 : 0000000000000000 x4 : 000000000000004c
> > > > > > [    5.601159] x3 : 0000000000000000 x2 : ffff8000113b4ac0
> > > > > > [    5.601162] x1 : ffff8000120c5f44 x0 : 00000000dc8984ff
> > > > > > [    5.601164] Call trace:
> > > > > > [    5.601169]  vc5_hdmi_phy_init+0x7ac/0x2078
> > > > > > [    5.601172]  vc4_hdmi_encoder_enable+0x1b8/0x1ac0
> > > > > > [    5.601176]  drm_atomic_helper_commit_modeset_enables+0x224/0x248
> > > > > > [    5.601179]  vc4_atomic_complete_commit+0x400/0x558
> > > > > > [    5.601182]  vc4_atomic_commit+0x1e0/0x200
> > > > > > [    5.601185]  drm_atomic_commit+0x4c/0x60
> > > > > > [    5.601190]  drm_client_modeset_commit_atomic.isra.0+0x17c/0x238
> > > > > > [    5.601192]  drm_client_modeset_commit_locked+0x5c/0x198
> > > > > > [    5.601195]  drm_client_modeset_commit+0x30/0x58
> > > > > > [    5.601201]  drm_fb_helper_restore_fbdev_mode_unlocked+0x78/0xe0
> > > > > > [    5.601204]  drm_fb_helper_set_par+0x30/0x68
> > > > > > [    5.601208]  fbcon_init+0x3d4/0x598
> > > > > > [    5.601212]  visual_init+0xb0/0x108
> > > > > > [    5.601214]  do_bind_con_driver+0x1d0/0x3a8
> > > > > > [    5.601217]  do_take_over_console+0x144/0x208
> > > > > > [    5.601219]  do_fbcon_takeover+0x68/0xd8
> > > > > > [    5.601222]  fbcon_fb_registered+0x100/0x118
> > > > > > [    5.601226]  register_framebuffer+0x1f4/0x338
> > > > > > [    5.601229]  __drm_fb_helper_initial_config_and_unlock+0x2f8/0x4a0
> > > > > > [    5.601232]  drm_fbdev_client_hotplug+0xd4/0x1b0
> > > > > > [    5.601235]  drm_fbdev_generic_setup+0xb0/0x130
> > > > > > [    5.601238]  vc4_drm_bind+0x184/0x1a0
> > > > > > [    5.601241]  try_to_bring_up_master+0x168/0x1c8
> > > > > > [    5.601244]  __component_add+0xa4/0x170
> > > > > > [    5.601246]  component_add+0x14/0x20
> > > > > > [    5.601248]  vc4_vec_dev_probe+0x20/0x30
> > > > > > [    5.601252]  platform_drv_probe+0x54/0xa8
> > > > > > [    5.601254]  really_probe+0xd8/0x320
> > > > > > [    5.601256]  driver_probe_device+0x58/0xf0
> > > > > > [    5.601258]  __device_attach_driver+0x84/0xc8
> > > > > > [    5.601263]  bus_for_each_drv+0x78/0xc8
> > > > > > [    5.601265]  __device_attach+0xe4/0x140
> > > > > > [    5.601267]  device_initial_probe+0x14/0x20
> > > > > > [    5.601269]  bus_probe_device+0x9c/0xa8
> > > > > > [    5.601271]  deferred_probe_work_func+0x74/0xb0
> > > > > > [    5.601276]  process_one_work+0x1bc/0x338
> > > > > > [    5.601279]  worker_thread+0x1f8/0x428
> > > > > > [    5.601282]  kthread+0x138/0x158
> > > > > > [    5.601286]  ret_from_fork+0x10/0x1c
> > > > > > [    5.601288] ---[ end trace cfba0996218c3f3d ]---
> > > > >
> > > > > Thanks for testing!
> > > > >
> > > > > Do you have a bit more details regarding your setup? Was it connected to an
> > > > > external display?
> > > >
> > > > Yes, the HDMI cable is connected to HDMI0 port on RPi 4.
> > > >
> > > > > If so, do you know the resolution it was trying to setup?
> > > >
> > > > According to the log, I think it is 1920x1080:
> > > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > > > HDMI-1 connected
> > > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > > > HDMI-2 disconnected
> > > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > > > Composite-1 disconnected
> > > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Using
> > > > exact sizes for initial modes
> > > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > > > HDMI-1 using initial mode 1920x1080 +0+0
> > > >
> > > > https://gist.github.com/starnight/45e1468bfa0426a54d2fb4a9269cfb94
> > >
> > > It looks to be fairly standard then, and I'm testing on the same resolution so
> > > it should be alright.
> > >
> > > Given from your log, it looks like you're running as arm64 though, while I stuck
> > > with arm32, so it could be the explanation.
> >
> > Yes, I build it as arm64.
> >
> > > Can you share your config.txt and .config so that I can try to reproduce it
> > > here?
> >
> > Here is the config
> > https://gist.github.com/starnight/320b757441b6769c36160704b401c98b
> 
> Here is the only one line in config.txt:
> enable_uart=1
> 
> Actually, we make the Raspberry Pi's firmware bring up U-Boot, then
> U-Boot boots kernel.

I gave it a try today, and it seems that you also need arm_64bit=1 in the
config.txt, but then the communication with the firmware doesn't work anymore
and the kernel just falls apart.

I'll give it a try with U-boot

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
  2020-05-11  3:12           ` Jian-Hong Pan
  2020-05-25 11:11             ` Maxime Ripard
@ 2020-05-26 10:20             ` Maxime Ripard
  2020-05-27  3:49               ` Daniel Drake
  1 sibling, 1 reply; 49+ messages in thread
From: Maxime Ripard @ 2020-05-26 10:20 UTC (permalink / raw)
  To: Jian-Hong Pan
  Cc: Nicolas Saenz Julienne, Eric Anholt, dri-devel, linux-rpi-kernel,
	bcm-kernel-feedback-list, linux-arm-kernel, Linux Kernel,
	devicetree, linux-clk, linux-i2c, Linux Upstreaming Team

Hi,

On Mon, May 11, 2020 at 11:12:05AM +0800, Jian-Hong Pan wrote:
> Jian-Hong Pan <jian-hong@endlessm.com> 於 2020年5月8日 週五 下午2:20寫道:
> >
> > Maxime Ripard <maxime@cerno.tech> 於 2020年5月8日 週五 上午1:22寫道:
> > >
> > > On Mon, May 04, 2020 at 02:35:08PM +0800, Jian-Hong Pan wrote:
> > > > Maxime Ripard <maxime@cerno.tech> 於 2020年4月29日 週三 上午12:21寫道:
> > > > >
> > > > > Hi,
> > > > >
> > > > > On Mon, Apr 27, 2020 at 03:23:42PM +0800, Jian-Hong Pan wrote:
> > > > > > Hi Maxime,
> > > > > >
> > > > > > Thanks for your V2 patch series!  I'm testing it.
> > > > > >
> > > > > > This patch series is applied upon mainline kernel 5.7-rc2 cleanly and built.
> > > > > > System can boot into console text mode, but no graphic UI.
> > > > > >
> > > > > > Get the error in vc5_hdmi_phy_init(), and full dmesg is at [1]:
> > > > > >
> > > > > > [    5.587543] vc4_hdmi fef00700.hdmi: Unknown register ID 46
> > > > > > [    5.587700] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi' already present!
> > > > > > [    5.588070] vc4_hdmi fef00700.hdmi: vc4-hdmi-hifi <-> fef00700.hdmi mapping ok
> > > > > > [    5.588076] vc4_hdmi fef00700.hdmi: ASoC: no DMI vendor name!
> > > > > > [    5.588263] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops)
> > > > > > [    5.588299] vc4_hdmi fef05700.hdmi: Unknown register ID 46
> > > > > > [    5.588373] debugfs: Directory 'vc4-hdmi' with parent 'asoc' already present!
> > > > > > [    5.588673] vc4_hdmi fef05700.hdmi: vc4-hdmi-hifi <-> fef05700.hdmi mapping ok
> > > > > > [    5.588677] vc4_hdmi fef05700.hdmi: ASoC: no DMI vendor name!
> > > > > > [    5.588809] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops)
> > > > > > [    5.588854] vc4-drm gpu: bound fe806000.vec (ops vc4_vec_ops)
> > > > > > [    5.588897] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops)
> > > > > > [    5.588934] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops)
> > > > > > [    5.588990] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops)
> > > > > > [    5.589030] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops)
> > > > > > [    5.589074] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops)
> > > > > > [    5.589106] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops)
> > > > > > [    5.589145] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops)
> > > > > > [    5.589294] checking generic (3e513000 6d8c00) vs hw (0 ffffffffffffffff)
> > > > > > [    5.589297] fb0: switching to vc4drmfb from simple
> > > > > > [    5.589433] Console: switching to colour dummy device 80x25
> > > > > > [    5.589481] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> > > > > > [    5.589816] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
> > > > > > [    5.601079] ------------[ cut here ]------------
> > > > > > [    5.601095] WARNING: CPU: 2 PID: 127 at drivers/gpu/drm/vc4/vc4_hdmi_phy.c:413 vc5_hdmi_phy_init+0x7ac/0x2078
> > > > > > [    5.601097] Modules linked in:
> > > > > > [    5.601103] CPU: 2 PID: 127 Comm: kworker/2:1 Not tainted 5.7.0-rc2-00091-ga181df59a930 #7
> > > > > > [    5.601105] Hardware name: Raspberry Pi 4 Model B (DT)
> > > > > > [    5.601112] Workqueue: events deferred_probe_work_func
> > > > > > [    5.601116] pstate: 20000005 (nzCv daif -PAN -UAO)
> > > > > > [    5.601119] pc : vc5_hdmi_phy_init+0x7ac/0x2078
> > > > > > [    5.601123] lr : vc4_hdmi_encoder_enable+0x1b8/0x1ac0
> > > > > > [    5.601124] sp : ffff80001217b410
> > > > > > [    5.601126] x29: ffff80001217b410 x28: ffff0000ec6370f0
> > > > > > [    5.601129] x27: ffff0000f650d400 x26: 000000008a500000
> > > > > > [    5.601132] x25: ffff8000113b4ac0 x24: 0000000000002060
> > > > > > [    5.601135] x23: 000000000a500000 x22: 0000000000000300
> > > > > > [    5.601137] x21: 0000000008d9ee20 x20: ffff0000ec535080
> > > > > > [    5.601140] x19: 000000010989e7c0 x18: 0000000000000000
> > > > > > [    5.601142] x17: 0000000000000001 x16: 0000000000005207
> > > > > > [    5.601145] x15: 00004932ad293c92 x14: 0000000000000137
> > > > > > [    5.601147] x13: ffff800010015000 x12: 0000000000000001
> > > > > > [    5.601150] x11: 0000000000000001 x10: 0000000000000000
> > > > > > [    5.601152] x9 : 0000000000000000 x8 : ffff800010015038
> > > > > > [    5.601154] x7 : 0000000000000001 x6 : ffff80001217b368
> > > > > > [    5.601157] x5 : 0000000000000000 x4 : 000000000000004c
> > > > > > [    5.601159] x3 : 0000000000000000 x2 : ffff8000113b4ac0
> > > > > > [    5.601162] x1 : ffff8000120c5f44 x0 : 00000000dc8984ff
> > > > > > [    5.601164] Call trace:
> > > > > > [    5.601169]  vc5_hdmi_phy_init+0x7ac/0x2078
> > > > > > [    5.601172]  vc4_hdmi_encoder_enable+0x1b8/0x1ac0
> > > > > > [    5.601176]  drm_atomic_helper_commit_modeset_enables+0x224/0x248
> > > > > > [    5.601179]  vc4_atomic_complete_commit+0x400/0x558
> > > > > > [    5.601182]  vc4_atomic_commit+0x1e0/0x200
> > > > > > [    5.601185]  drm_atomic_commit+0x4c/0x60
> > > > > > [    5.601190]  drm_client_modeset_commit_atomic.isra.0+0x17c/0x238
> > > > > > [    5.601192]  drm_client_modeset_commit_locked+0x5c/0x198
> > > > > > [    5.601195]  drm_client_modeset_commit+0x30/0x58
> > > > > > [    5.601201]  drm_fb_helper_restore_fbdev_mode_unlocked+0x78/0xe0
> > > > > > [    5.601204]  drm_fb_helper_set_par+0x30/0x68
> > > > > > [    5.601208]  fbcon_init+0x3d4/0x598
> > > > > > [    5.601212]  visual_init+0xb0/0x108
> > > > > > [    5.601214]  do_bind_con_driver+0x1d0/0x3a8
> > > > > > [    5.601217]  do_take_over_console+0x144/0x208
> > > > > > [    5.601219]  do_fbcon_takeover+0x68/0xd8
> > > > > > [    5.601222]  fbcon_fb_registered+0x100/0x118
> > > > > > [    5.601226]  register_framebuffer+0x1f4/0x338
> > > > > > [    5.601229]  __drm_fb_helper_initial_config_and_unlock+0x2f8/0x4a0
> > > > > > [    5.601232]  drm_fbdev_client_hotplug+0xd4/0x1b0
> > > > > > [    5.601235]  drm_fbdev_generic_setup+0xb0/0x130
> > > > > > [    5.601238]  vc4_drm_bind+0x184/0x1a0
> > > > > > [    5.601241]  try_to_bring_up_master+0x168/0x1c8
> > > > > > [    5.601244]  __component_add+0xa4/0x170
> > > > > > [    5.601246]  component_add+0x14/0x20
> > > > > > [    5.601248]  vc4_vec_dev_probe+0x20/0x30
> > > > > > [    5.601252]  platform_drv_probe+0x54/0xa8
> > > > > > [    5.601254]  really_probe+0xd8/0x320
> > > > > > [    5.601256]  driver_probe_device+0x58/0xf0
> > > > > > [    5.601258]  __device_attach_driver+0x84/0xc8
> > > > > > [    5.601263]  bus_for_each_drv+0x78/0xc8
> > > > > > [    5.601265]  __device_attach+0xe4/0x140
> > > > > > [    5.601267]  device_initial_probe+0x14/0x20
> > > > > > [    5.601269]  bus_probe_device+0x9c/0xa8
> > > > > > [    5.601271]  deferred_probe_work_func+0x74/0xb0
> > > > > > [    5.601276]  process_one_work+0x1bc/0x338
> > > > > > [    5.601279]  worker_thread+0x1f8/0x428
> > > > > > [    5.601282]  kthread+0x138/0x158
> > > > > > [    5.601286]  ret_from_fork+0x10/0x1c
> > > > > > [    5.601288] ---[ end trace cfba0996218c3f3d ]---
> > > > >
> > > > > Thanks for testing!
> > > > >
> > > > > Do you have a bit more details regarding your setup? Was it connected to an
> > > > > external display?
> > > >
> > > > Yes, the HDMI cable is connected to HDMI0 port on RPi 4.
> > > >
> > > > > If so, do you know the resolution it was trying to setup?
> > > >
> > > > According to the log, I think it is 1920x1080:
> > > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > > > HDMI-1 connected
> > > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > > > HDMI-2 disconnected
> > > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > > > Composite-1 disconnected
> > > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Using
> > > > exact sizes for initial modes
> > > > Apr 27 15:37:25 endless gdm-Xorg-:0[1960]: (II) modeset(0): Output
> > > > HDMI-1 using initial mode 1920x1080 +0+0
> > > >
> > > > https://gist.github.com/starnight/45e1468bfa0426a54d2fb4a9269cfb94
> > >
> > > It looks to be fairly standard then, and I'm testing on the same resolution so
> > > it should be alright.
> > >
> > > Given from your log, it looks like you're running as arm64 though, while I stuck
> > > with arm32, so it could be the explanation.
> >
> > Yes, I build it as arm64.
> >
> > > Can you share your config.txt and .config so that I can try to reproduce it
> > > here?
> >
> > Here is the config
> > https://gist.github.com/starnight/320b757441b6769c36160704b401c98b
> 
> Here is the only one line in config.txt:
> enable_uart=1
> 
> Actually, we make the Raspberry Pi's firmware bring up U-Boot, then
> U-Boot boots kernel.

I gave it a try with U-Boot with my latest work and couldn't reproduce it, so it
seems that I fixed it along the way

Maxime

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
  2020-05-26 10:20             ` Maxime Ripard
@ 2020-05-27  3:49               ` Daniel Drake
  2020-05-27  9:13                 ` Maxime Ripard
  0 siblings, 1 reply; 49+ messages in thread
From: Daniel Drake @ 2020-05-27  3:49 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Jian-Hong Pan, Nicolas Saenz Julienne, Eric Anholt, dri-devel,
	linux-rpi-kernel, bcm-kernel-feedback-list, linux-arm-kernel,
	Linux Kernel, devicetree, linux-clk, linux-i2c,
	Linux Upstreaming Team

Hi Maxime,

On Tue, May 26, 2020 at 6:20 PM Maxime Ripard <maxime@cerno.tech> wrote:
> I gave it a try with U-Boot with my latest work and couldn't reproduce it, so it
> seems that I fixed it along the way

Is your latest work available in a git branch anywhere that we could
test directly?

Thanks
Daniel

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 06/91] clk: bcm: rpi: Statically init clk_init_data
  2020-04-24 15:33 ` [PATCH v2 06/91] clk: bcm: rpi: Statically init clk_init_data Maxime Ripard
@ 2020-05-27  6:47   ` Stephen Boyd
  0 siblings, 0 replies; 49+ messages in thread
From: Stephen Boyd @ 2020-05-27  6:47 UTC (permalink / raw)
  To: Eric Anholt, Maxime Ripard, Nicolas Saenz Julienne
  Cc: dri-devel, linux-rpi-kernel, bcm-kernel-feedback-list,
	linux-arm-kernel, linux-kernel, Dave Stevenson, Tim Gover,
	Phil Elwell, Maxime Ripard, Michael Turquette, linux-clk

Quoting Maxime Ripard (2020-04-24 08:33:47)
> Instead of declaring the clk_init_data and then calling memset on it, just
> initialise properly.
> 
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: linux-clk@vger.kernel.org
> Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---

Reviewed-by: Stephen Boyd <sboyd@kernel.org>

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 08/91] clk: bcm: rpi: Remove global pllb_arm clock pointer
  2020-04-24 15:33 ` [PATCH v2 08/91] clk: bcm: rpi: Remove global pllb_arm clock pointer Maxime Ripard
@ 2020-05-27  6:48   ` Stephen Boyd
  0 siblings, 0 replies; 49+ messages in thread
From: Stephen Boyd @ 2020-05-27  6:48 UTC (permalink / raw)
  To: Eric Anholt, Maxime Ripard, Nicolas Saenz Julienne
  Cc: dri-devel, linux-rpi-kernel, bcm-kernel-feedback-list,
	linux-arm-kernel, linux-kernel, Dave Stevenson, Tim Gover,
	Phil Elwell, Maxime Ripard, Michael Turquette, linux-clk

Quoting Maxime Ripard (2020-04-24 08:33:49)
> The pllb_arm clk_hw pointer in the raspberry_clk structure isn't used
> anywhere but in the raspberrypi_register_pllb_arm.
> 
> Let's remove it, this will make our lives easier in future patches.
> 
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: linux-clk@vger.kernel.org
> Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---

Reviewed-by: Stephen Boyd <sboyd@kernel.org>

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 09/91] clk: bcm: rpi: Make sure pllb_arm is removed
  2020-04-24 15:33 ` [PATCH v2 09/91] clk: bcm: rpi: Make sure pllb_arm is removed Maxime Ripard
@ 2020-05-27  6:48   ` Stephen Boyd
  0 siblings, 0 replies; 49+ messages in thread
From: Stephen Boyd @ 2020-05-27  6:48 UTC (permalink / raw)
  To: Eric Anholt, Maxime Ripard, Nicolas Saenz Julienne
  Cc: dri-devel, linux-rpi-kernel, bcm-kernel-feedback-list,
	linux-arm-kernel, linux-kernel, Dave Stevenson, Tim Gover,
	Phil Elwell, Maxime Ripard, Michael Turquette, linux-clk

Quoting Maxime Ripard (2020-04-24 08:33:50)
> The pllb_arm clock was created at probe time, but was never removed if
> something went wrong later in probe, or if the driver was ever removed from
> the system.
> 
> Now that we are using clk_hw_register, we can just use its managed variant

clk_hw_register()

> to take care of that for us.
> 
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: linux-clk@vger.kernel.org
> Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> Reviewed-by: Stephen Boyd <sboyd@kernel.org>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---

Reviewed-by: Stephen Boyd <sboyd@kernel.org>

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 15/91] clk: bcm: rpi: Pass the clocks data to the firmware function
  2020-04-24 15:33 ` [PATCH v2 15/91] clk: bcm: rpi: Pass the clocks data to the firmware function Maxime Ripard
@ 2020-05-27  6:49   ` Stephen Boyd
  0 siblings, 0 replies; 49+ messages in thread
From: Stephen Boyd @ 2020-05-27  6:49 UTC (permalink / raw)
  To: Eric Anholt, Maxime Ripard, Nicolas Saenz Julienne
  Cc: dri-devel, linux-rpi-kernel, bcm-kernel-feedback-list,
	linux-arm-kernel, linux-kernel, Dave Stevenson, Tim Gover,
	Phil Elwell, Maxime Ripard, Michael Turquette, linux-clk

Quoting Maxime Ripard (2020-04-24 08:33:56)
> The raspberry_clock_property only takes the clock ID as an argument, but
> now that we have a clock data structure it makes more sense to just pass
> that structure instead.
> 
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: linux-clk@vger.kernel.org
> Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---

Reviewed-by: Stephen Boyd <sboyd@kernel.org>

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 20/91] clk: bcm: rpi: Discover the firmware clocks
  2020-04-24 15:34 ` [PATCH v2 20/91] clk: bcm: rpi: Discover the firmware clocks Maxime Ripard
  2020-05-04 12:05   ` Nicolas Saenz Julienne
@ 2020-05-27  7:03   ` Stephen Boyd
  1 sibling, 0 replies; 49+ messages in thread
From: Stephen Boyd @ 2020-05-27  7:03 UTC (permalink / raw)
  To: Eric Anholt, Maxime Ripard, Nicolas Saenz Julienne
  Cc: dri-devel, linux-rpi-kernel, bcm-kernel-feedback-list,
	linux-arm-kernel, linux-kernel, Dave Stevenson, Tim Gover,
	Phil Elwell, Maxime Ripard, Michael Turquette, linux-clk

Quoting Maxime Ripard (2020-04-24 08:34:01)
> The RaspberryPi4 firmware actually exposes more clocks than are currently
> handled by the driver and we will need to change some of them directly
> based on the pixel rate for the display related clocks, or the load for the
> GPU.
> 
> This rate change can have a number of side-effects, including adjusting the
> various PLL voltages or the PLL parents. The firmware will also update
> those clocks by itself for example if the SoC runs too hot.
> 
> In order to make Linux play as nice as possible with those constraints, it
> makes sense to rely on the firmware clocks as much as possible.
> 
> Fortunately,t he firmware has an interface to discover the clocks it

Fortunately, the

> exposes.
> 
> Let's use it to discover, register the clocks in the clocks framework and
> then expose them through the device tree for consumers to use them.
> 
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: linux-clk@vger.kernel.org
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---

Reviewed-by: Stephen Boyd <sboyd@kernel.org>

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 25/91] clk: bcm: Add BCM2711 DVP driver
  2020-04-24 15:34 ` [PATCH v2 25/91] clk: bcm: Add BCM2711 DVP driver Maxime Ripard
@ 2020-05-27  7:06   ` Stephen Boyd
  0 siblings, 0 replies; 49+ messages in thread
From: Stephen Boyd @ 2020-05-27  7:06 UTC (permalink / raw)
  To: Eric Anholt, Maxime Ripard, Nicolas Saenz Julienne
  Cc: dri-devel, linux-rpi-kernel, bcm-kernel-feedback-list,
	linux-arm-kernel, linux-kernel, Dave Stevenson, Tim Gover,
	Phil Elwell, Maxime Ripard, Michael Turquette, Rob Herring,
	linux-clk, devicetree

Quoting Maxime Ripard (2020-04-24 08:34:06)
> The HDMI block has a block that controls clocks and reset signals to the
> HDMI0 and HDMI1 controllers.
> 
> Let's expose that through a clock driver implementing a clock and reset
> provider.
> 
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: linux-clk@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---

Reviewed-by: Stephen Boyd <sboyd@kernel.org>

> diff --git a/drivers/clk/bcm/clk-bcm2711-dvp.c b/drivers/clk/bcm/clk-bcm2711-dvp.c
> new file mode 100644
> index 000000000000..c1c4b5857d32
> --- /dev/null
> +++ b/drivers/clk/bcm/clk-bcm2711-dvp.c
> @@ -0,0 +1,127 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +// Copyright 2020 Cerno
> +
> +#include <linux/clk-provider.h>
> +#include <linux/module.h>
[...]
> +
> +static int clk_dvp_probe(struct platform_device *pdev)
> +{
> +       struct clk_hw_onecell_data *data;
> +       struct resource *res;
> +       struct clk_dvp *dvp;
> +       void __iomem *base;
> +       int ret;
> +
> +       dvp = devm_kzalloc(&pdev->dev, sizeof(*dvp), GFP_KERNEL);
> +       if (!dvp)
> +               return -ENOMEM;
> +       platform_set_drvdata(pdev, dvp);
> +
> +       dvp->data = devm_kzalloc(&pdev->dev,
> +                                struct_size(dvp->data, hws, NR_CLOCKS),
> +                                GFP_KERNEL);
> +       if (!dvp->data)
> +               return -ENOMEM;
> +       data = dvp->data;
> +
> +       res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +       base = devm_ioremap_resource(&pdev->dev, res);

devm_platform_ioremap_resource()?

> +       if (IS_ERR(base))
> +               return PTR_ERR(base);
> +

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
  2020-05-27  3:49               ` Daniel Drake
@ 2020-05-27  9:13                 ` Maxime Ripard
  2020-05-27  9:15                   ` Daniel Drake
  0 siblings, 1 reply; 49+ messages in thread
From: Maxime Ripard @ 2020-05-27  9:13 UTC (permalink / raw)
  To: Daniel Drake
  Cc: Jian-Hong Pan, Nicolas Saenz Julienne, Eric Anholt, dri-devel,
	linux-rpi-kernel, bcm-kernel-feedback-list, linux-arm-kernel,
	Linux Kernel, devicetree, linux-clk, linux-i2c,
	Linux Upstreaming Team

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

Hi Daniel,

On Wed, May 27, 2020 at 11:49:36AM +0800, Daniel Drake wrote:
> Hi Maxime,
> 
> On Tue, May 26, 2020 at 6:20 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > I gave it a try with U-Boot with my latest work and couldn't reproduce it, so it
> > seems that I fixed it along the way
> 
> Is your latest work available in a git branch anywhere that we could
> test directly?

I'm about to send a v3 today or tomorrow, I can Cc you (and Jian-Hong) if you
want.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
  2020-05-27  9:13                 ` Maxime Ripard
@ 2020-05-27  9:15                   ` Daniel Drake
  2020-05-28  7:30                     ` Maxime Ripard
  0 siblings, 1 reply; 49+ messages in thread
From: Daniel Drake @ 2020-05-27  9:15 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Jian-Hong Pan, Nicolas Saenz Julienne, Eric Anholt, dri-devel,
	linux-rpi-kernel, bcm-kernel-feedback-list, linux-arm-kernel,
	Linux Kernel, devicetree, linux-clk, linux-i2c,
	Linux Upstreaming Team

On Wed, May 27, 2020 at 5:13 PM Maxime Ripard <maxime@cerno.tech> wrote:
> I'm about to send a v3 today or tomorrow, I can Cc you (and Jian-Hong) if you
> want.

That would be great, although given the potentially inconsistent
results we've been seeing so far it would be great if you could
additionally push a git branch somewhere.
That way we can have higher confidence that we are applying exactly
the same patches to the same base etc.

Thanks
Daniel

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
  2020-05-27  9:15                   ` Daniel Drake
@ 2020-05-28  7:30                     ` Maxime Ripard
  2020-06-01  7:58                       ` Jian-Hong Pan
  0 siblings, 1 reply; 49+ messages in thread
From: Maxime Ripard @ 2020-05-28  7:30 UTC (permalink / raw)
  To: Daniel Drake
  Cc: Jian-Hong Pan, Nicolas Saenz Julienne, Eric Anholt, dri-devel,
	linux-rpi-kernel, bcm-kernel-feedback-list, linux-arm-kernel,
	Linux Kernel, devicetree, linux-clk, linux-i2c,
	Linux Upstreaming Team

[-- Attachment #1: Type: text/plain, Size: 767 bytes --]

Hi Daniel,

On Wed, May 27, 2020 at 05:15:12PM +0800, Daniel Drake wrote:
> On Wed, May 27, 2020 at 5:13 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > I'm about to send a v3 today or tomorrow, I can Cc you (and Jian-Hong) if you
> > want.
> 
> That would be great, although given the potentially inconsistent
> results we've been seeing so far it would be great if you could
> additionally push a git branch somewhere.
> That way we can have higher confidence that we are applying exactly
> the same patches to the same base etc.

So I sent a new iteration yesterday, and of course forgot to cc you... Sorry for
that.

I've pushed my current branch here:
https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/log/?h=rpi4-kms

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
  2020-05-28  7:30                     ` Maxime Ripard
@ 2020-06-01  7:58                       ` Jian-Hong Pan
  2020-06-02 11:04                         ` Maxime Ripard
  0 siblings, 1 reply; 49+ messages in thread
From: Jian-Hong Pan @ 2020-06-01  7:58 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Daniel Drake, Nicolas Saenz Julienne, Eric Anholt, dri-devel,
	linux-rpi-kernel, bcm-kernel-feedback-list, linux-arm-kernel,
	Linux Kernel, devicetree, linux-clk, linux-i2c,
	Linux Upstreaming Team

Maxime Ripard <maxime@cerno.tech> 於 2020年5月28日 週四 下午3:30寫道:
>
> Hi Daniel,
>
> On Wed, May 27, 2020 at 05:15:12PM +0800, Daniel Drake wrote:
> > On Wed, May 27, 2020 at 5:13 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > I'm about to send a v3 today or tomorrow, I can Cc you (and Jian-Hong) if you
> > > want.
> >
> > That would be great, although given the potentially inconsistent
> > results we've been seeing so far it would be great if you could
> > additionally push a git branch somewhere.
> > That way we can have higher confidence that we are applying exactly
> > the same patches to the same base etc.
>
> So I sent a new iteration yesterday, and of course forgot to cc you... Sorry for
> that.
>
> I've pushed my current branch here:
> https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/log/?h=rpi4-kms

Thanks to Maxime!

I have tried your repository on branch rpi4-kms.  The DRM VC4 is used!
But got some issues:
1. Some weird error message in dmesg.  Not sure it is related, or not
[    5.219321] [drm:vc5_hdmi_init_resources] *ERROR* Failed to get
HDMI state machine clock
https://gist.github.com/starnight/3f317dca121065a361cf08e91225e389

2. The screen flashes suddenly sometimes.

3. The higher resolutions, like 1920x1080 ... are lost after hot
re-plug HDMI cable (HDMI0)

Jian-Hong Pan

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
  2020-06-01  7:58                       ` Jian-Hong Pan
@ 2020-06-02 11:04                         ` Maxime Ripard
  2020-06-05  8:44                           ` Jian-Hong Pan
  0 siblings, 1 reply; 49+ messages in thread
From: Maxime Ripard @ 2020-06-02 11:04 UTC (permalink / raw)
  To: Jian-Hong Pan
  Cc: Daniel Drake, Nicolas Saenz Julienne, Eric Anholt, dri-devel,
	linux-rpi-kernel, bcm-kernel-feedback-list, linux-arm-kernel,
	Linux Kernel, devicetree, linux-clk, linux-i2c,
	Linux Upstreaming Team

[-- Attachment #1: Type: text/plain, Size: 1807 bytes --]

Hi,

On Mon, Jun 01, 2020 at 03:58:26PM +0800, Jian-Hong Pan wrote:
> Maxime Ripard <maxime@cerno.tech> 於 2020年5月28日 週四 下午3:30寫道:
> >
> > Hi Daniel,
> >
> > On Wed, May 27, 2020 at 05:15:12PM +0800, Daniel Drake wrote:
> > > On Wed, May 27, 2020 at 5:13 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > I'm about to send a v3 today or tomorrow, I can Cc you (and Jian-Hong) if you
> > > > want.
> > >
> > > That would be great, although given the potentially inconsistent
> > > results we've been seeing so far it would be great if you could
> > > additionally push a git branch somewhere.
> > > That way we can have higher confidence that we are applying exactly
> > > the same patches to the same base etc.
> >
> > So I sent a new iteration yesterday, and of course forgot to cc you... Sorry for
> > that.
> >
> > I've pushed my current branch here:
> > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/log/?h=rpi4-kms
> 
> Thanks to Maxime!
> 
> I have tried your repository on branch rpi4-kms.  The DRM VC4 is used!
> But got some issues:
> 1. Some weird error message in dmesg.  Not sure it is related, or not
> [    5.219321] [drm:vc5_hdmi_init_resources] *ERROR* Failed to get
> HDMI state machine clock
> https://gist.github.com/starnight/3f317dca121065a361cf08e91225e389

That's a deferred probing. The first time the HDMI driver is being
probed, the firmware clock driver has not been probed yet. It's making
another attempt later on, which succeeds.

> 2. The screen flashes suddenly sometimes.
> 
> 3. The higher resolutions, like 1920x1080 ... are lost after hot
> re-plug HDMI cable (HDMI0)

I'm not sure on how to exactly reproduce those issues (or what they are)
though, can you expand on this?

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
  2020-06-02 11:04                         ` Maxime Ripard
@ 2020-06-05  8:44                           ` Jian-Hong Pan
  2020-06-29 14:21                             ` Maxime Ripard
  0 siblings, 1 reply; 49+ messages in thread
From: Jian-Hong Pan @ 2020-06-05  8:44 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Daniel Drake, Nicolas Saenz Julienne, Eric Anholt, dri-devel,
	linux-rpi-kernel, bcm-kernel-feedback-list, linux-arm-kernel,
	Linux Kernel, devicetree, linux-clk, linux-i2c,
	Linux Upstreaming Team

Maxime Ripard <maxime@cerno.tech> 於 2020年6月2日 週二 下午7:04寫道:
>
> Hi,
>
> On Mon, Jun 01, 2020 at 03:58:26PM +0800, Jian-Hong Pan wrote:
> > Maxime Ripard <maxime@cerno.tech> 於 2020年5月28日 週四 下午3:30寫道:
> > >
> > > Hi Daniel,
> > >
> > > On Wed, May 27, 2020 at 05:15:12PM +0800, Daniel Drake wrote:
> > > > On Wed, May 27, 2020 at 5:13 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > I'm about to send a v3 today or tomorrow, I can Cc you (and Jian-Hong) if you
> > > > > want.
> > > >
> > > > That would be great, although given the potentially inconsistent
> > > > results we've been seeing so far it would be great if you could
> > > > additionally push a git branch somewhere.
> > > > That way we can have higher confidence that we are applying exactly
> > > > the same patches to the same base etc.
> > >
> > > So I sent a new iteration yesterday, and of course forgot to cc you... Sorry for
> > > that.
> > >
> > > I've pushed my current branch here:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/log/?h=rpi4-kms
> >
> > Thanks to Maxime!
> >
> > I have tried your repository on branch rpi4-kms.  The DRM VC4 is used!
> > But got some issues:
> > 1. Some weird error message in dmesg.  Not sure it is related, or not
> > [    5.219321] [drm:vc5_hdmi_init_resources] *ERROR* Failed to get
> > HDMI state machine clock
> > https://gist.github.com/starnight/3f317dca121065a361cf08e91225e389
>
> That's a deferred probing. The first time the HDMI driver is being
> probed, the firmware clock driver has not been probed yet. It's making
> another attempt later on, which succeeds.
>
> > 2. The screen flashes suddenly sometimes.

I append drm.debug=0x3 to boot command.  Whenever, the screen flashes,
I notice the logs like this:

Jun 01 15:22:40 endless kernel: [drm:drm_calc_timestamping_constants]
crtc 64: hwmode: htotal 2200, vtotal 1125, vdisplay 1080
Jun 01 15:22:40 endless kernel: [drm:drm_calc_timestamping_constants]
crtc 64: clock 148500 kHz framedur 16666666 linedur 14814
Jun 01 15:22:40 endless kernel: [drm:drm_vblank_enable] enabling
vblank on crtc 3, ret: 0
Jun 01 15:22:40 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 159 (2)
Jun 01 15:22:40 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 154 (1)
Jun 01 15:22:40 endless kernel: [drm:vblank_disable_fn] disabling
vblank on crtc 3
Jun 01 15:22:42 endless kernel: [drm:drm_ioctl] pid=584, dev=0xe200,
auth=1, DRM_IOCTL_MODE_CURSOR
Jun 01 15:22:42 endless kernel: [drm:drm_ioctl] pid=584, dev=0xe200,
auth=1, DRM_IOCTL_MODE_CURSOR2
Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_get] OBJ ID: 159 (1)
Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_get] OBJ ID: 154 (1)
Jun 01 15:22:42 endless kernel: [drm:drm_calc_timestamping_constants]
crtc 64: hwmode: htotal 2200, vtotal 1125, vdisplay 1080
Jun 01 15:22:42 endless kernel: [drm:drm_calc_timestamping_constants]
crtc 64: clock 148500 kHz framedur 16666666 linedur 14814
Jun 01 15:22:42 endless kernel: [drm:drm_vblank_enable] enabling
vblank on crtc 3, ret: 0
Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 159 (2)
Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 154 (2)

Here is the full log
https://gist.github.com/starnight/85d641819839eddc7a55ca7173990a56

> > 3. The higher resolutions, like 1920x1080 ... are lost after hot
> > re-plug HDMI cable (HDMI0)

I should explain this in more detail.  Here are the steps to reproduce
this issue:
1. Before unplug the HDMI cable from HDMI0 port.
$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 2048 x 2048
HDMI-1 connected primary 1920x1080+0+0 (normal left inverted right x
axis y axis) 521mm x 293mm
   1920x1080     60.00*+  50.00    59.94
   1920x1080i    60.00    50.00    59.94
   1680x1050     59.88
   1280x1024     75.02    60.02
   1440x900      59.90
   1280x960      60.00
   1152x864      75.00
   1280x720      60.00    50.00    59.94
   1440x576      50.00
   1024x768      75.03    70.07    60.00
   1440x480      60.00    59.94
   832x624       74.55
   800x600       72.19    75.00    60.32    56.25
   720x576       50.00
   720x480       60.00    59.94
   640x480       75.00    72.81    66.67    60.00    59.94
   720x400       70.08
HDMI-2 disconnected (normal left inverted right x axis y axis)

2. Unplug the HDMI cable from HDMI0 port.
3. Plug the HDMI cable to **HDMI1** port.
$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 2048 x 2048
HDMI-1 disconnected (normal left inverted right x axis y axis)
HDMI-2 connected primary 1920x1080+0+0 (normal left inverted right x
axis y axis) 521mm x 293mm
   1920x1080     60.00*+  50.00    59.94
   1920x1080i    60.00    50.00    59.94
   1680x1050     59.88
   1280x1024     75.02    60.02
   1440x900      59.90
   1280x960      60.00
   1152x864      75.00
   1280x720      60.00    50.00    59.94
   1440x576      50.00
   1024x768      75.03    70.07    60.00
   1440x480      60.00    59.94
   832x624       74.55
   800x600       72.19    75.00    60.32    56.25
   720x576       50.00
   720x480       60.00    59.94
   640x480       75.00    72.81    66.67    60.00    59.94
   720x400       70.08

4. Unplug the HDMI cable from **HDMI1** port.
5. Plug the HDMI cable back to HDMI0 port.
$ xrandr
Screen 0: minimum 320 x 200, current 1368 x 768, maximum 2048 x 2048
HDMI-1 connected primary 1368x768+0+0 (normal left inverted right x
axis y axis) 0mm x 0mm
   1368x768      59.88*
   1360x768      59.80
   1280x800      59.81
   1152x864      60.00
   1280x720      59.86
   1024x768      60.00
   1024x576      59.90
   960x540       59.63
   800x600       60.32
   800x450       59.82
   700x450       59.88
   640x480       59.94
   684x384       59.88    59.85
   680x384       59.80    59.96
   640x400       59.88    59.98
   576x432       60.06
   640x360       59.86    59.83
   512x384       60.00
   512x288       60.00    59.92
   480x270       59.63    59.82
   400x300       60.32
   320x240       60.05
HDMI-2 disconnected (normal left inverted right x axis y axis)

Jian-Hong Pan

> I'm not sure on how to exactly reproduce those issues (or what they are)
> though, can you expand on this?
>
> Maxime

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
  2020-06-05  8:44                           ` Jian-Hong Pan
@ 2020-06-29 14:21                             ` Maxime Ripard
  2020-06-30  8:26                               ` Jian-Hong Pan
  0 siblings, 1 reply; 49+ messages in thread
From: Maxime Ripard @ 2020-06-29 14:21 UTC (permalink / raw)
  To: Jian-Hong Pan
  Cc: Daniel Drake, Nicolas Saenz Julienne, Eric Anholt, dri-devel,
	linux-rpi-kernel, bcm-kernel-feedback-list, linux-arm-kernel,
	Linux Kernel, devicetree, linux-clk, linux-i2c,
	Linux Upstreaming Team

[-- Attachment #1: Type: text/plain, Size: 7007 bytes --]

Hi!

On Fri, Jun 05, 2020 at 04:44:51PM +0800, Jian-Hong Pan wrote:
> Maxime Ripard <maxime@cerno.tech> 於 2020年6月2日 週二 下午7:04寫道:
> >
> > Hi,
> >
> > On Mon, Jun 01, 2020 at 03:58:26PM +0800, Jian-Hong Pan wrote:
> > > Maxime Ripard <maxime@cerno.tech> 於 2020年5月28日 週四 下午3:30寫道:
> > > >
> > > > Hi Daniel,
> > > >
> > > > On Wed, May 27, 2020 at 05:15:12PM +0800, Daniel Drake wrote:
> > > > > On Wed, May 27, 2020 at 5:13 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > > I'm about to send a v3 today or tomorrow, I can Cc you (and Jian-Hong) if you
> > > > > > want.
> > > > >
> > > > > That would be great, although given the potentially inconsistent
> > > > > results we've been seeing so far it would be great if you could
> > > > > additionally push a git branch somewhere.
> > > > > That way we can have higher confidence that we are applying exactly
> > > > > the same patches to the same base etc.
> > > >
> > > > So I sent a new iteration yesterday, and of course forgot to cc you... Sorry for
> > > > that.
> > > >
> > > > I've pushed my current branch here:
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/log/?h=rpi4-kms
> > >
> > > Thanks to Maxime!
> > >
> > > I have tried your repository on branch rpi4-kms.  The DRM VC4 is used!
> > > But got some issues:
> > > 1. Some weird error message in dmesg.  Not sure it is related, or not
> > > [    5.219321] [drm:vc5_hdmi_init_resources] *ERROR* Failed to get
> > > HDMI state machine clock
> > > https://gist.github.com/starnight/3f317dca121065a361cf08e91225e389
> >
> > That's a deferred probing. The first time the HDMI driver is being
> > probed, the firmware clock driver has not been probed yet. It's making
> > another attempt later on, which succeeds.
> >
> > > 2. The screen flashes suddenly sometimes.
> 
> I append drm.debug=0x3 to boot command.  Whenever, the screen flashes,
> I notice the logs like this:
> 
> Jun 01 15:22:40 endless kernel: [drm:drm_calc_timestamping_constants]
> crtc 64: hwmode: htotal 2200, vtotal 1125, vdisplay 1080
> Jun 01 15:22:40 endless kernel: [drm:drm_calc_timestamping_constants]
> crtc 64: clock 148500 kHz framedur 16666666 linedur 14814
> Jun 01 15:22:40 endless kernel: [drm:drm_vblank_enable] enabling
> vblank on crtc 3, ret: 0
> Jun 01 15:22:40 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 159 (2)
> Jun 01 15:22:40 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 154 (1)
> Jun 01 15:22:40 endless kernel: [drm:vblank_disable_fn] disabling
> vblank on crtc 3
> Jun 01 15:22:42 endless kernel: [drm:drm_ioctl] pid=584, dev=0xe200,
> auth=1, DRM_IOCTL_MODE_CURSOR
> Jun 01 15:22:42 endless kernel: [drm:drm_ioctl] pid=584, dev=0xe200,
> auth=1, DRM_IOCTL_MODE_CURSOR2
> Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_get] OBJ ID: 159 (1)
> Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_get] OBJ ID: 154 (1)
> Jun 01 15:22:42 endless kernel: [drm:drm_calc_timestamping_constants]
> crtc 64: hwmode: htotal 2200, vtotal 1125, vdisplay 1080
> Jun 01 15:22:42 endless kernel: [drm:drm_calc_timestamping_constants]
> crtc 64: clock 148500 kHz framedur 16666666 linedur 14814
> Jun 01 15:22:42 endless kernel: [drm:drm_vblank_enable] enabling
> vblank on crtc 3, ret: 0
> Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 159 (2)
> Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 154 (2)
> 
> Here is the full log
> https://gist.github.com/starnight/85d641819839eddc7a55ca7173990a56
> 
> > > 3. The higher resolutions, like 1920x1080 ... are lost after hot
> > > re-plug HDMI cable (HDMI0)
> 
> I should explain this in more detail.  Here are the steps to reproduce
> this issue:
> 1. Before unplug the HDMI cable from HDMI0 port.
> $ xrandr
> Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 2048 x 2048
> HDMI-1 connected primary 1920x1080+0+0 (normal left inverted right x
> axis y axis) 521mm x 293mm
>    1920x1080     60.00*+  50.00    59.94
>    1920x1080i    60.00    50.00    59.94
>    1680x1050     59.88
>    1280x1024     75.02    60.02
>    1440x900      59.90
>    1280x960      60.00
>    1152x864      75.00
>    1280x720      60.00    50.00    59.94
>    1440x576      50.00
>    1024x768      75.03    70.07    60.00
>    1440x480      60.00    59.94
>    832x624       74.55
>    800x600       72.19    75.00    60.32    56.25
>    720x576       50.00
>    720x480       60.00    59.94
>    640x480       75.00    72.81    66.67    60.00    59.94
>    720x400       70.08
> HDMI-2 disconnected (normal left inverted right x axis y axis)
> 
> 2. Unplug the HDMI cable from HDMI0 port.
> 3. Plug the HDMI cable to **HDMI1** port.
> $ xrandr
> Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 2048 x 2048
> HDMI-1 disconnected (normal left inverted right x axis y axis)
> HDMI-2 connected primary 1920x1080+0+0 (normal left inverted right x
> axis y axis) 521mm x 293mm
>    1920x1080     60.00*+  50.00    59.94
>    1920x1080i    60.00    50.00    59.94
>    1680x1050     59.88
>    1280x1024     75.02    60.02
>    1440x900      59.90
>    1280x960      60.00
>    1152x864      75.00
>    1280x720      60.00    50.00    59.94
>    1440x576      50.00
>    1024x768      75.03    70.07    60.00
>    1440x480      60.00    59.94
>    832x624       74.55
>    800x600       72.19    75.00    60.32    56.25
>    720x576       50.00
>    720x480       60.00    59.94
>    640x480       75.00    72.81    66.67    60.00    59.94
>    720x400       70.08
> 
> 4. Unplug the HDMI cable from **HDMI1** port.
> 5. Plug the HDMI cable back to HDMI0 port.
> $ xrandr
> Screen 0: minimum 320 x 200, current 1368 x 768, maximum 2048 x 2048
> HDMI-1 connected primary 1368x768+0+0 (normal left inverted right x
> axis y axis) 0mm x 0mm
>    1368x768      59.88*
>    1360x768      59.80
>    1280x800      59.81
>    1152x864      60.00
>    1280x720      59.86
>    1024x768      60.00
>    1024x576      59.90
>    960x540       59.63
>    800x600       60.32
>    800x450       59.82
>    700x450       59.88
>    640x480       59.94
>    684x384       59.88    59.85
>    680x384       59.80    59.96
>    640x400       59.88    59.98
>    576x432       60.06
>    640x360       59.86    59.83
>    512x384       60.00
>    512x288       60.00    59.92
>    480x270       59.63    59.82
>    400x300       60.32
>    320x240       60.05
> HDMI-2 disconnected (normal left inverted right x axis y axis)

Sorry for getting back at it so late. I just tested with modetest only
and my current branch and it seems to behave properly. Did you had to
run X to get that issue, or is it just how you noticed it?

Also, was that with the branch based on 5.7 I pushed on my git tree on
kernel.org or some earlier revision of the series?

Thanks!
Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
  2020-06-29 14:21                             ` Maxime Ripard
@ 2020-06-30  8:26                               ` Jian-Hong Pan
  2020-07-03 12:56                                 ` Maxime Ripard
  0 siblings, 1 reply; 49+ messages in thread
From: Jian-Hong Pan @ 2020-06-30  8:26 UTC (permalink / raw)
  To: Maxime Ripard
  Cc: Daniel Drake, Nicolas Saenz Julienne, Eric Anholt, dri-devel,
	linux-rpi-kernel, bcm-kernel-feedback-list, linux-arm-kernel,
	Linux Kernel, devicetree, linux-clk, linux-i2c,
	Linux Upstreaming Team

Maxime Ripard <maxime@cerno.tech> 於 2020年6月29日 週一 下午10:21寫道:
>
> Hi!
>
> On Fri, Jun 05, 2020 at 04:44:51PM +0800, Jian-Hong Pan wrote:
> > Maxime Ripard <maxime@cerno.tech> 於 2020年6月2日 週二 下午7:04寫道:
> > >
> > > Hi,
> > >
> > > On Mon, Jun 01, 2020 at 03:58:26PM +0800, Jian-Hong Pan wrote:
> > > > Maxime Ripard <maxime@cerno.tech> 於 2020年5月28日 週四 下午3:30寫道:
> > > > >
> > > > > Hi Daniel,
> > > > >
> > > > > On Wed, May 27, 2020 at 05:15:12PM +0800, Daniel Drake wrote:
> > > > > > On Wed, May 27, 2020 at 5:13 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > > > I'm about to send a v3 today or tomorrow, I can Cc you (and Jian-Hong) if you
> > > > > > > want.
> > > > > >
> > > > > > That would be great, although given the potentially inconsistent
> > > > > > results we've been seeing so far it would be great if you could
> > > > > > additionally push a git branch somewhere.
> > > > > > That way we can have higher confidence that we are applying exactly
> > > > > > the same patches to the same base etc.
> > > > >
> > > > > So I sent a new iteration yesterday, and of course forgot to cc you... Sorry for
> > > > > that.
> > > > >
> > > > > I've pushed my current branch here:
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/log/?h=rpi4-kms
> > > >
> > > > Thanks to Maxime!
> > > >
> > > > I have tried your repository on branch rpi4-kms.  The DRM VC4 is used!
> > > > But got some issues:
> > > > 1. Some weird error message in dmesg.  Not sure it is related, or not
> > > > [    5.219321] [drm:vc5_hdmi_init_resources] *ERROR* Failed to get
> > > > HDMI state machine clock
> > > > https://gist.github.com/starnight/3f317dca121065a361cf08e91225e389
> > >
> > > That's a deferred probing. The first time the HDMI driver is being
> > > probed, the firmware clock driver has not been probed yet. It's making
> > > another attempt later on, which succeeds.
> > >
> > > > 2. The screen flashes suddenly sometimes.
> >
> > I append drm.debug=0x3 to boot command.  Whenever, the screen flashes,
> > I notice the logs like this:
> >
> > Jun 01 15:22:40 endless kernel: [drm:drm_calc_timestamping_constants]
> > crtc 64: hwmode: htotal 2200, vtotal 1125, vdisplay 1080
> > Jun 01 15:22:40 endless kernel: [drm:drm_calc_timestamping_constants]
> > crtc 64: clock 148500 kHz framedur 16666666 linedur 14814
> > Jun 01 15:22:40 endless kernel: [drm:drm_vblank_enable] enabling
> > vblank on crtc 3, ret: 0
> > Jun 01 15:22:40 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 159 (2)
> > Jun 01 15:22:40 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 154 (1)
> > Jun 01 15:22:40 endless kernel: [drm:vblank_disable_fn] disabling
> > vblank on crtc 3
> > Jun 01 15:22:42 endless kernel: [drm:drm_ioctl] pid=584, dev=0xe200,
> > auth=1, DRM_IOCTL_MODE_CURSOR
> > Jun 01 15:22:42 endless kernel: [drm:drm_ioctl] pid=584, dev=0xe200,
> > auth=1, DRM_IOCTL_MODE_CURSOR2
> > Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_get] OBJ ID: 159 (1)
> > Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_get] OBJ ID: 154 (1)
> > Jun 01 15:22:42 endless kernel: [drm:drm_calc_timestamping_constants]
> > crtc 64: hwmode: htotal 2200, vtotal 1125, vdisplay 1080
> > Jun 01 15:22:42 endless kernel: [drm:drm_calc_timestamping_constants]
> > crtc 64: clock 148500 kHz framedur 16666666 linedur 14814
> > Jun 01 15:22:42 endless kernel: [drm:drm_vblank_enable] enabling
> > vblank on crtc 3, ret: 0
> > Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 159 (2)
> > Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 154 (2)
> >
> > Here is the full log
> > https://gist.github.com/starnight/85d641819839eddc7a55ca7173990a56
> >
> > > > 3. The higher resolutions, like 1920x1080 ... are lost after hot
> > > > re-plug HDMI cable (HDMI0)
> >
> > I should explain this in more detail.  Here are the steps to reproduce
> > this issue:
> > 1. Before unplug the HDMI cable from HDMI0 port.
> > $ xrandr
> > Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 2048 x 2048
> > HDMI-1 connected primary 1920x1080+0+0 (normal left inverted right x
> > axis y axis) 521mm x 293mm
> >    1920x1080     60.00*+  50.00    59.94
> >    1920x1080i    60.00    50.00    59.94
> >    1680x1050     59.88
> >    1280x1024     75.02    60.02
> >    1440x900      59.90
> >    1280x960      60.00
> >    1152x864      75.00
> >    1280x720      60.00    50.00    59.94
> >    1440x576      50.00
> >    1024x768      75.03    70.07    60.00
> >    1440x480      60.00    59.94
> >    832x624       74.55
> >    800x600       72.19    75.00    60.32    56.25
> >    720x576       50.00
> >    720x480       60.00    59.94
> >    640x480       75.00    72.81    66.67    60.00    59.94
> >    720x400       70.08
> > HDMI-2 disconnected (normal left inverted right x axis y axis)
> >
> > 2. Unplug the HDMI cable from HDMI0 port.
> > 3. Plug the HDMI cable to **HDMI1** port.
> > $ xrandr
> > Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 2048 x 2048
> > HDMI-1 disconnected (normal left inverted right x axis y axis)
> > HDMI-2 connected primary 1920x1080+0+0 (normal left inverted right x
> > axis y axis) 521mm x 293mm
> >    1920x1080     60.00*+  50.00    59.94
> >    1920x1080i    60.00    50.00    59.94
> >    1680x1050     59.88
> >    1280x1024     75.02    60.02
> >    1440x900      59.90
> >    1280x960      60.00
> >    1152x864      75.00
> >    1280x720      60.00    50.00    59.94
> >    1440x576      50.00
> >    1024x768      75.03    70.07    60.00
> >    1440x480      60.00    59.94
> >    832x624       74.55
> >    800x600       72.19    75.00    60.32    56.25
> >    720x576       50.00
> >    720x480       60.00    59.94
> >    640x480       75.00    72.81    66.67    60.00    59.94
> >    720x400       70.08
> >
> > 4. Unplug the HDMI cable from **HDMI1** port.
> > 5. Plug the HDMI cable back to HDMI0 port.
> > $ xrandr
> > Screen 0: minimum 320 x 200, current 1368 x 768, maximum 2048 x 2048
> > HDMI-1 connected primary 1368x768+0+0 (normal left inverted right x
> > axis y axis) 0mm x 0mm
> >    1368x768      59.88*
> >    1360x768      59.80
> >    1280x800      59.81
> >    1152x864      60.00
> >    1280x720      59.86
> >    1024x768      60.00
> >    1024x576      59.90
> >    960x540       59.63
> >    800x600       60.32
> >    800x450       59.82
> >    700x450       59.88
> >    640x480       59.94
> >    684x384       59.88    59.85
> >    680x384       59.80    59.96
> >    640x400       59.88    59.98
> >    576x432       60.06
> >    640x360       59.86    59.83
> >    512x384       60.00
> >    512x288       60.00    59.92
> >    480x270       59.63    59.82
> >    400x300       60.32
> >    320x240       60.05
> > HDMI-2 disconnected (normal left inverted right x axis y axis)
>
> Sorry for getting back at it so late. I just tested with modetest only
> and my current branch and it seems to behave properly. Did you had to
> run X to get that issue, or is it just how you noticed it?
>
> Also, was that with the branch based on 5.7 I pushed on my git tree on
> kernel.org or some earlier revision of the series?

Thanks for coming back :)

I use GNOME 3.36 with Xorg 1.20.4.

To understand when it starts to hit the issues, I separate to step by step:
1. System boots into command line mode first (systemd multi-user.target)
2. Execute Xorg, then xterm.
3. Execute mutter upon the screen of Xorg.

I tried both branches rpi4-kms and rpi4-kms-5.7 of
https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git
Both of the branches hit issues:
* The screen flashes suddenly sometimes.  This happens after mutter is launched.
* The higher resolutions, like 1920x1080 ... are lost after hot
re-plug HDMI cable (HDMI0).  HDMI cable connects to HDMI0 -> HDMI1 ->
HDMI0.  This happens not only with GNOME, but also pure Xorg.

Jian-Hong Pan

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
  2020-06-30  8:26                               ` Jian-Hong Pan
@ 2020-07-03 12:56                                 ` Maxime Ripard
  0 siblings, 0 replies; 49+ messages in thread
From: Maxime Ripard @ 2020-07-03 12:56 UTC (permalink / raw)
  To: Jian-Hong Pan
  Cc: Daniel Drake, Nicolas Saenz Julienne, Eric Anholt, dri-devel,
	linux-rpi-kernel, bcm-kernel-feedback-list, linux-arm-kernel,
	Linux Kernel, devicetree, linux-clk, linux-i2c,
	Linux Upstreaming Team

[-- Attachment #1: Type: text/plain, Size: 8826 bytes --]

Hi,

On Tue, Jun 30, 2020 at 04:26:20PM +0800, Jian-Hong Pan wrote:
> Maxime Ripard <maxime@cerno.tech> 於 2020年6月29日 週一 下午10:21寫道:
> >
> > Hi!
> >
> > On Fri, Jun 05, 2020 at 04:44:51PM +0800, Jian-Hong Pan wrote:
> > > Maxime Ripard <maxime@cerno.tech> 於 2020年6月2日 週二 下午7:04寫道:
> > > >
> > > > Hi,
> > > >
> > > > On Mon, Jun 01, 2020 at 03:58:26PM +0800, Jian-Hong Pan wrote:
> > > > > Maxime Ripard <maxime@cerno.tech> 於 2020年5月28日 週四 下午3:30寫道:
> > > > > >
> > > > > > Hi Daniel,
> > > > > >
> > > > > > On Wed, May 27, 2020 at 05:15:12PM +0800, Daniel Drake wrote:
> > > > > > > On Wed, May 27, 2020 at 5:13 PM Maxime Ripard <maxime@cerno.tech> wrote:
> > > > > > > > I'm about to send a v3 today or tomorrow, I can Cc you (and Jian-Hong) if you
> > > > > > > > want.
> > > > > > >
> > > > > > > That would be great, although given the potentially inconsistent
> > > > > > > results we've been seeing so far it would be great if you could
> > > > > > > additionally push a git branch somewhere.
> > > > > > > That way we can have higher confidence that we are applying exactly
> > > > > > > the same patches to the same base etc.
> > > > > >
> > > > > > So I sent a new iteration yesterday, and of course forgot to cc you... Sorry for
> > > > > > that.
> > > > > >
> > > > > > I've pushed my current branch here:
> > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/log/?h=rpi4-kms
> > > > >
> > > > > Thanks to Maxime!
> > > > >
> > > > > I have tried your repository on branch rpi4-kms.  The DRM VC4 is used!
> > > > > But got some issues:
> > > > > 1. Some weird error message in dmesg.  Not sure it is related, or not
> > > > > [    5.219321] [drm:vc5_hdmi_init_resources] *ERROR* Failed to get
> > > > > HDMI state machine clock
> > > > > https://gist.github.com/starnight/3f317dca121065a361cf08e91225e389
> > > >
> > > > That's a deferred probing. The first time the HDMI driver is being
> > > > probed, the firmware clock driver has not been probed yet. It's making
> > > > another attempt later on, which succeeds.
> > > >
> > > > > 2. The screen flashes suddenly sometimes.
> > >
> > > I append drm.debug=0x3 to boot command.  Whenever, the screen flashes,
> > > I notice the logs like this:
> > >
> > > Jun 01 15:22:40 endless kernel: [drm:drm_calc_timestamping_constants]
> > > crtc 64: hwmode: htotal 2200, vtotal 1125, vdisplay 1080
> > > Jun 01 15:22:40 endless kernel: [drm:drm_calc_timestamping_constants]
> > > crtc 64: clock 148500 kHz framedur 16666666 linedur 14814
> > > Jun 01 15:22:40 endless kernel: [drm:drm_vblank_enable] enabling
> > > vblank on crtc 3, ret: 0
> > > Jun 01 15:22:40 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 159 (2)
> > > Jun 01 15:22:40 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 154 (1)
> > > Jun 01 15:22:40 endless kernel: [drm:vblank_disable_fn] disabling
> > > vblank on crtc 3
> > > Jun 01 15:22:42 endless kernel: [drm:drm_ioctl] pid=584, dev=0xe200,
> > > auth=1, DRM_IOCTL_MODE_CURSOR
> > > Jun 01 15:22:42 endless kernel: [drm:drm_ioctl] pid=584, dev=0xe200,
> > > auth=1, DRM_IOCTL_MODE_CURSOR2
> > > Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_get] OBJ ID: 159 (1)
> > > Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_get] OBJ ID: 154 (1)
> > > Jun 01 15:22:42 endless kernel: [drm:drm_calc_timestamping_constants]
> > > crtc 64: hwmode: htotal 2200, vtotal 1125, vdisplay 1080
> > > Jun 01 15:22:42 endless kernel: [drm:drm_calc_timestamping_constants]
> > > crtc 64: clock 148500 kHz framedur 16666666 linedur 14814
> > > Jun 01 15:22:42 endless kernel: [drm:drm_vblank_enable] enabling
> > > vblank on crtc 3, ret: 0
> > > Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 159 (2)
> > > Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 154 (2)
> > >
> > > Here is the full log
> > > https://gist.github.com/starnight/85d641819839eddc7a55ca7173990a56
> > >
> > > > > 3. The higher resolutions, like 1920x1080 ... are lost after hot
> > > > > re-plug HDMI cable (HDMI0)
> > >
> > > I should explain this in more detail.  Here are the steps to reproduce
> > > this issue:
> > > 1. Before unplug the HDMI cable from HDMI0 port.
> > > $ xrandr
> > > Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 2048 x 2048
> > > HDMI-1 connected primary 1920x1080+0+0 (normal left inverted right x
> > > axis y axis) 521mm x 293mm
> > >    1920x1080     60.00*+  50.00    59.94
> > >    1920x1080i    60.00    50.00    59.94
> > >    1680x1050     59.88
> > >    1280x1024     75.02    60.02
> > >    1440x900      59.90
> > >    1280x960      60.00
> > >    1152x864      75.00
> > >    1280x720      60.00    50.00    59.94
> > >    1440x576      50.00
> > >    1024x768      75.03    70.07    60.00
> > >    1440x480      60.00    59.94
> > >    832x624       74.55
> > >    800x600       72.19    75.00    60.32    56.25
> > >    720x576       50.00
> > >    720x480       60.00    59.94
> > >    640x480       75.00    72.81    66.67    60.00    59.94
> > >    720x400       70.08
> > > HDMI-2 disconnected (normal left inverted right x axis y axis)
> > >
> > > 2. Unplug the HDMI cable from HDMI0 port.
> > > 3. Plug the HDMI cable to **HDMI1** port.
> > > $ xrandr
> > > Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 2048 x 2048
> > > HDMI-1 disconnected (normal left inverted right x axis y axis)
> > > HDMI-2 connected primary 1920x1080+0+0 (normal left inverted right x
> > > axis y axis) 521mm x 293mm
> > >    1920x1080     60.00*+  50.00    59.94
> > >    1920x1080i    60.00    50.00    59.94
> > >    1680x1050     59.88
> > >    1280x1024     75.02    60.02
> > >    1440x900      59.90
> > >    1280x960      60.00
> > >    1152x864      75.00
> > >    1280x720      60.00    50.00    59.94
> > >    1440x576      50.00
> > >    1024x768      75.03    70.07    60.00
> > >    1440x480      60.00    59.94
> > >    832x624       74.55
> > >    800x600       72.19    75.00    60.32    56.25
> > >    720x576       50.00
> > >    720x480       60.00    59.94
> > >    640x480       75.00    72.81    66.67    60.00    59.94
> > >    720x400       70.08
> > >
> > > 4. Unplug the HDMI cable from **HDMI1** port.
> > > 5. Plug the HDMI cable back to HDMI0 port.
> > > $ xrandr
> > > Screen 0: minimum 320 x 200, current 1368 x 768, maximum 2048 x 2048
> > > HDMI-1 connected primary 1368x768+0+0 (normal left inverted right x
> > > axis y axis) 0mm x 0mm
> > >    1368x768      59.88*
> > >    1360x768      59.80
> > >    1280x800      59.81
> > >    1152x864      60.00
> > >    1280x720      59.86
> > >    1024x768      60.00
> > >    1024x576      59.90
> > >    960x540       59.63
> > >    800x600       60.32
> > >    800x450       59.82
> > >    700x450       59.88
> > >    640x480       59.94
> > >    684x384       59.88    59.85
> > >    680x384       59.80    59.96
> > >    640x400       59.88    59.98
> > >    576x432       60.06
> > >    640x360       59.86    59.83
> > >    512x384       60.00
> > >    512x288       60.00    59.92
> > >    480x270       59.63    59.82
> > >    400x300       60.32
> > >    320x240       60.05
> > > HDMI-2 disconnected (normal left inverted right x axis y axis)
> >
> > Sorry for getting back at it so late. I just tested with modetest only
> > and my current branch and it seems to behave properly. Did you had to
> > run X to get that issue, or is it just how you noticed it?
> >
> > Also, was that with the branch based on 5.7 I pushed on my git tree on
> > kernel.org or some earlier revision of the series?
> 
> Thanks for coming back :)
> 
> I use GNOME 3.36 with Xorg 1.20.4.
> 
> To understand when it starts to hit the issues, I separate to step by step:
> 1. System boots into command line mode first (systemd multi-user.target)
> 2. Execute Xorg, then xterm.
> 3. Execute mutter upon the screen of Xorg.
> 
> I tried both branches rpi4-kms and rpi4-kms-5.7 of
> https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git
> Both of the branches hit issues:
> * The screen flashes suddenly sometimes.  This happens after mutter is launched.
> * The higher resolutions, like 1920x1080 ... are lost after hot
> re-plug HDMI cable (HDMI0).  HDMI cable connects to HDMI0 -> HDMI1 ->
> HDMI0.  This happens not only with GNOME, but also pure Xorg.

I just tested with raspbian exactly this, running the same xorg version:
https://pastebin.com/3fKeFPxf

And without X involved, modetest also reports the modes properly, so
it's probably something in either the DDX you're using or Gnome/mutter.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

end of thread, other threads:[~2020-07-03 12:56 UTC | newest]

Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-24 15:33 [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipeline Maxime Ripard
2020-04-24 15:33 ` [PATCH v2 03/91] dt-bindings: clock: Add a binding for the RPi Firmware clocks Maxime Ripard
2020-05-11 21:47   ` Rob Herring
2020-05-13  8:13     ` Maxime Ripard
2020-04-24 15:33 ` [PATCH v2 05/91] clk: bcm: rpi: Allow the driver to be probed by DT Maxime Ripard
2020-04-30 16:19   ` Nicolas Saenz Julienne
2020-04-24 15:33 ` [PATCH v2 06/91] clk: bcm: rpi: Statically init clk_init_data Maxime Ripard
2020-05-27  6:47   ` Stephen Boyd
2020-04-24 15:33 ` [PATCH v2 07/91] clk: bcm: rpi: Use clk_hw_register for pllb_arm Maxime Ripard
2020-04-24 15:33 ` [PATCH v2 08/91] clk: bcm: rpi: Remove global pllb_arm clock pointer Maxime Ripard
2020-05-27  6:48   ` Stephen Boyd
2020-04-24 15:33 ` [PATCH v2 09/91] clk: bcm: rpi: Make sure pllb_arm is removed Maxime Ripard
2020-05-27  6:48   ` Stephen Boyd
2020-04-24 15:33 ` [PATCH v2 10/91] clk: bcm: rpi: Remove pllb_arm_lookup global pointer Maxime Ripard
2020-04-24 15:33 ` [PATCH v2 11/91] clk: bcm: rpi: Switch to clk_hw_register_clkdev Maxime Ripard
2020-04-24 15:33 ` [PATCH v2 12/91] clk: bcm: rpi: Make sure the clkdev lookup is removed Maxime Ripard
2020-04-24 15:33 ` [PATCH v2 13/91] clk: bcm: rpi: Create a data structure for the clocks Maxime Ripard
2020-04-24 15:33 ` [PATCH v2 14/91] clk: bcm: rpi: Add clock id to data Maxime Ripard
2020-04-24 15:33 ` [PATCH v2 15/91] clk: bcm: rpi: Pass the clocks data to the firmware function Maxime Ripard
2020-05-27  6:49   ` Stephen Boyd
2020-04-24 15:33 ` [PATCH v2 16/91] clk: bcm: rpi: Rename is_prepared function Maxime Ripard
2020-04-24 15:33 ` [PATCH v2 17/91] clk: bcm: rpi: Split pllb clock hooks Maxime Ripard
2020-04-24 15:33 ` [PATCH v2 18/91] clk: bcm: rpi: Make the PLLB registration function return a clk_hw Maxime Ripard
2020-04-24 15:34 ` [PATCH v2 19/91] clk: bcm: rpi: Add DT provider for the clocks Maxime Ripard
2020-04-24 15:34 ` [PATCH v2 20/91] clk: bcm: rpi: Discover the firmware clocks Maxime Ripard
2020-05-04 12:05   ` Nicolas Saenz Julienne
2020-05-15  8:19     ` Maxime Ripard
2020-05-21  9:13       ` Nicolas Saenz Julienne
2020-05-27  7:03   ` Stephen Boyd
2020-04-24 15:34 ` [PATCH v2 25/91] clk: bcm: Add BCM2711 DVP driver Maxime Ripard
2020-05-27  7:06   ` Stephen Boyd
2020-04-27  7:23 ` [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin Jian-Hong Pan
2020-04-28 16:21   ` Maxime Ripard
2020-05-04  6:35     ` Jian-Hong Pan
2020-05-07 17:21       ` Maxime Ripard
2020-05-08  6:20         ` Jian-Hong Pan
2020-05-11  3:12           ` Jian-Hong Pan
2020-05-25 11:11             ` Maxime Ripard
2020-05-26 10:20             ` Maxime Ripard
2020-05-27  3:49               ` Daniel Drake
2020-05-27  9:13                 ` Maxime Ripard
2020-05-27  9:15                   ` Daniel Drake
2020-05-28  7:30                     ` Maxime Ripard
2020-06-01  7:58                       ` Jian-Hong Pan
2020-06-02 11:04                         ` Maxime Ripard
2020-06-05  8:44                           ` Jian-Hong Pan
2020-06-29 14:21                             ` Maxime Ripard
2020-06-30  8:26                               ` Jian-Hong Pan
2020-07-03 12:56                                 ` Maxime Ripard

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).