* Re: [PATCH v5 08/11] i2c: designware: Convert driver to using regmap API
From: Andy Shevchenko @ 2020-05-27 16:03 UTC (permalink / raw)
To: Serge Semin
Cc: Jarkko Nikula, Wolfram Sang, Mika Westerberg, Serge Semin,
Alexey Malahov, Thomas Bogendoerfer, Rob Herring, devicetree,
linux-mips, linux-i2c, linux-kernel
In-Reply-To: <20200527153046.6172-9-Sergey.Semin@baikalelectronics.ru>
On Wed, May 27, 2020 at 06:30:43PM +0300, Serge Semin wrote:
> Seeing the DW I2C driver is using flags-based accessors with two
> conditional clauses it would be better to replace them with the regmap
> API IO methods and to initialize the regmap object with read/write
> callbacks specific to the controller registers map implementation. This
> will be also handy for the drivers with non-standard registers mapping
> (like an embedded into the Baikal-T1 System Controller DW I2C block, which
> glue-driver is a part of this series).
>
> As before the driver tries to detect the mapping setup at probe stage and
> creates a regmap object accordingly, which will be used by the rest of the
> code to correctly access the controller registers. In two places it was
> appropriate to convert the hand-written read-modify-write and
> read-poll-loop design patterns to the corresponding regmap API
> ready-to-use methods.
>
> Note the regmap IO methods return value is checked only at the probe
> stage. The rest of the code won't do this because basically we have
> MMIO-based regmap so non of the read/write methods can fail (this also
> won't be needed for the Baikal-T1-specific I2C controller).
...
> + struct regmap_config map_cfg = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> + .disable_locking = true,
> + .reg_read = dw_reg_read,
> + .reg_write = dw_reg_write,
> + .max_register = DW_IC_COMP_TYPE
Perhaps leave comma here as well.
> + };
...
> + /*
> + * Note we'll check the return value of the regmap IO accessors only
> + * at the probe stage. The rest of the code won't do this because
> + * basically we have MMIO-based regmap so non of the read/write methods
> + * can fail.
> + */
> + dev->map = devm_regmap_init(dev->dev, NULL, dev, &map_cfg);
> + if (IS_ERR(dev->map)) {
> + dev_err(dev->dev, "Failed to init the registers map\n");
> + return PTR_ERR(dev->map);
> + }
> +
> return 0;
return PTR_ERR_OR_ZERO(dev->map);
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 06/11] i2c: designware: Add Baytrail sem config DW I2C platform dependency
From: Serge Semin @ 2020-05-27 16:00 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Serge Semin, Jarkko Nikula, Wolfram Sang, Alexey Malahov,
Thomas Bogendoerfer, Mika Westerberg, Rob Herring, linux-mips,
devicetree, linux-i2c, linux-kernel
In-Reply-To: <20200527154632.GG1634618@smile.fi.intel.com>
On Wed, May 27, 2020 at 06:46:32PM +0300, Andy Shevchenko wrote:
> On Wed, May 27, 2020 at 05:24:06PM +0300, Serge Semin wrote:
> > On Wed, May 27, 2020 at 04:42:20PM +0300, Andy Shevchenko wrote:
> > > On Wed, May 27, 2020 at 03:01:06PM +0300, Serge Semin wrote:
> > > > Currently Intel Baytrail I2C semaphore is a feature of the DW APB I2C
> > > > platform driver. It's a bit confusing to see it's config in the menu at
> > > > some separated place with no reference to the platform code. Let's move the
> > > > config definition to be below the I2C_DESIGNWARE_PLATFORM config and mark
> > > > it with "depends on I2C_DESIGNWARE_PLATFORM" statement. By doing so the
> > > > config menu will display the feature right below the DW I2C platform
> > > > driver item and will indent it to the right so signifying its belonging.
>
> ...
>
> > > > config I2C_DESIGNWARE_BAYTRAIL
> > > > bool "Intel Baytrail I2C semaphore support"
> > > > depends on ACPI
> > > > + depends on I2C_DESIGNWARE_PLATFORM
> > > > depends on (I2C_DESIGNWARE_PLATFORM=m && IOSF_MBI) || \
> > > > (I2C_DESIGNWARE_PLATFORM=y && IOSF_MBI=y)
> > >
> > > I didn't get this. What is broken now with existing dependencies?
> >
> > With no explicit "depends on I2C_DESIGNWARE_PLATFORM" the entry isn't right
> > shifted with respect to the I2C_DESIGNWARE_PLATFORM config entry in the kernel
> > menuconfig. So it looks like a normal no-yes driver without it.
>
> I didn't get. Is there problems with current case? (I don't see it).
> If there is a problem, it should have a separate patch and commit message.
>
> As for now above excerpt seems redundant and unneeded churn.
Please read the commit log more carefully.
Without explicit "depends on I2C_DESIGNWARE_PLATFORM" you'd see the DW
I2C-related menuconfig as:
[*] Synopsys DesignWare Platform
[ ] Intel Baytrail I2C semaphore support
with that "depends on I2C_DESIGNWARE_PLATFORM" added:
[*] Synopsys DesignWare Platform
[ ] Intel Baytrail I2C semaphore support
The second case presents the Baytrail semaphore as the DW I2C platform
feature. Otherwise it's just a simple menuentry. As I see it without adding
the explicit "depends on I2C_DESIGNWARE_PLATFORM" there is no need in moving
the config at all. So if you think it's a churn. Well, I'll wait for
Jarkko' comment in this regard.
BTW Jarkko asked in v3 whether it would work with just explicit "depends on"
without if-endif enclosing the config.
-Sergey
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* [PATCH v3 006/105] dt-bindings: display: Convert VC4 bindings to schemas
From: Maxime Ripard @ 2020-05-27 15:47 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, Rob Herring, devicetree
In-Reply-To: <cover.aaf2100bd7da4609f8bcb8216247d4b4e4379639.1590594512.git-series.maxime@cerno.tech>
The BCM283x SoCs have a display pipeline composed of several controllers
with device tree bindings that are supported by Linux.
Now that we have the DT validation in place, let's split into separate
files and convert the device tree bindings for those controllers to
schemas.
This is just a 1:1 conversion though, and some bindings were incomplete so
it results in example validation warnings that are going to be addressed in
the following patches.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt | 174 +------------------------------------------------------------------------
Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml | 66 +++++++++++++++++++++++++++-
Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml | 73 ++++++++++++++++++++++++++++++-
Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml | 75 +++++++++++++++++++++++++++++++-
Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml | 37 +++++++++++++++-
Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml | 40 +++++++++++++++++-
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 | 34 ++++++++++++++-
Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml | 44 ++++++++++++++++++-
MAINTAINERS | 2 +-
11 files changed, 449 insertions(+), 175 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
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
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
deleted file mode 100644
index 26649b4c4dd8..000000000000
--- a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
+++ /dev/null
@@ -1,174 +0,0 @@
-Broadcom VC4 (VideoCore4) GPU
-
-The VC4 device present on the Raspberry Pi includes a display system
-with HDMI output and the HVS (Hardware Video Scaler) for compositing
-display planes.
-
-Required properties for VC4:
-- compatible: Should be "brcm,bcm2835-vc4" or "brcm,cygnus-vc4"
-
-Required properties for Pixel Valve:
-- compatible: Should be one of "brcm,bcm2835-pixelvalve0",
- "brcm,bcm2835-pixelvalve1", or "brcm,bcm2835-pixelvalve2"
-- reg: Physical base address and length of the PV's registers
-- interrupts: The interrupt number
- See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
-
-Required properties for HVS:
-- compatible: Should be "brcm,bcm2835-hvs"
-- reg: Physical base address and length of the HVS's registers
-- interrupts: The interrupt number
- See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
-
-Required properties for HDMI
-- compatible: Should be "brcm,bcm2835-hdmi"
-- reg: Physical base address and length of the two register ranges
- ("HDMI" and "HD", in that order)
-- interrupts: The interrupt numbers
- See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
-- ddc: phandle of the I2C controller used for DDC EDID probing
-- clocks: a) hdmi: The HDMI state machine clock
- b) pixel: The pixel clock.
-
-Optional properties for HDMI:
-- hpd-gpios: The GPIO pin for HDMI hotplug detect (if it doesn't appear
- as an interrupt/status bit in the HDMI controller
- itself). See bindings/pinctrl/brcm,bcm2835-gpio.txt
-- dmas: Should contain one entry pointing to the DMA channel used to
- transfer audio data
-- dma-names: Should contain "audio-rx"
-
-Required properties for DPI:
-- compatible: Should be "brcm,bcm2835-dpi"
-- reg: Physical base address and length of the registers
-- clocks: a) core: The core clock the unit runs on
- b) pixel: The pixel clock that feeds the pixelvalve
-- port: Port node with a single endpoint connecting to the panel
- device, as defined in [1]
-
-Required properties for VEC:
-- compatible: Should be "brcm,bcm2835-vec"
-- reg: Physical base address and length of the registers
-- clocks: The core clock the unit runs on
-- interrupts: The interrupt number
- See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
-
-Required properties for V3D:
-- compatible: Should be "brcm,bcm2835-v3d" or "brcm,cygnus-v3d"
-- reg: Physical base address and length of the V3D's registers
-- interrupts: The interrupt number
- See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
-
-Optional properties for V3D:
-- clocks: The clock the unit runs on
-
-Required properties for DSI:
-- compatible: Should be "brcm,bcm2835-dsi0" or "brcm,bcm2835-dsi1"
-- reg: Physical base address and length of the DSI block's registers
-- interrupts: The interrupt number
- See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
-- clocks: a) phy: The DSI PLL clock feeding the DSI analog PHY
- b) escape: The DSI ESC clock from CPRMAN
- c) pixel: The DSI pixel clock from CPRMAN
-- clock-output-names:
- The 3 clocks output from the DSI analog PHY: dsi[01]_byte,
- dsi[01]_ddr2, and dsi[01]_ddr
-
-Required properties for the TXP (writeback) block:
-- compatible: Should be "brcm,bcm2835-txp"
-- reg: Physical base address and length of the TXP block's registers
-- interrupts: The interrupt number
- See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
-
-[1] Documentation/devicetree/bindings/media/video-interfaces.txt
-
-Example:
-pixelvalve@7e807000 {
- compatible = "brcm,bcm2835-pixelvalve2";
- reg = <0x7e807000 0x100>;
- interrupts = <2 10>; /* pixelvalve */
-};
-
-hvs@7e400000 {
- compatible = "brcm,bcm2835-hvs";
- reg = <0x7e400000 0x6000>;
- interrupts = <2 1>;
-};
-
-hdmi: hdmi@7e902000 {
- compatible = "brcm,bcm2835-hdmi";
- reg = <0x7e902000 0x600>,
- <0x7e808000 0x100>;
- interrupts = <2 8>, <2 9>;
- ddc = <&i2c2>;
- hpd-gpios = <&gpio 46 GPIO_ACTIVE_HIGH>;
- clocks = <&clocks BCM2835_PLLH_PIX>,
- <&clocks BCM2835_CLOCK_HSM>;
- clock-names = "pixel", "hdmi";
-};
-
-dpi: dpi@7e208000 {
- compatible = "brcm,bcm2835-dpi";
- reg = <0x7e208000 0x8c>;
- clocks = <&clocks BCM2835_CLOCK_VPU>,
- <&clocks BCM2835_CLOCK_DPI>;
- clock-names = "core", "pixel";
- #address-cells = <1>;
- #size-cells = <0>;
-
- port {
- dpi_out: endpoint@0 {
- remote-endpoint = <&panel_in>;
- };
- };
-};
-
-dsi1: dsi@7e700000 {
- compatible = "brcm,bcm2835-dsi1";
- reg = <0x7e700000 0x8c>;
- interrupts = <2 12>;
- #address-cells = <1>;
- #size-cells = <0>;
- #clock-cells = <1>;
-
- clocks = <&clocks BCM2835_PLLD_DSI1>,
- <&clocks BCM2835_CLOCK_DSI1E>,
- <&clocks BCM2835_CLOCK_DSI1P>;
- clock-names = "phy", "escape", "pixel";
-
- clock-output-names = "dsi1_byte", "dsi1_ddr2", "dsi1_ddr";
-
- pitouchscreen: panel@0 {
- compatible = "raspberrypi,touchscreen";
- reg = <0>;
-
- <...>
- };
-};
-
-vec: vec@7e806000 {
- compatible = "brcm,bcm2835-vec";
- reg = <0x7e806000 0x1000>;
- clocks = <&clocks BCM2835_CLOCK_VEC>;
- interrupts = <2 27>;
-};
-
-v3d: v3d@7ec00000 {
- compatible = "brcm,bcm2835-v3d";
- reg = <0x7ec00000 0x1000>;
- interrupts = <1 10>;
-};
-
-vc4: gpu {
- compatible = "brcm,bcm2835-vc4";
-};
-
-panel: panel {
- compatible = "ontat,yx700wv03", "simple-panel";
-
- port {
- panel_in: endpoint {
- remote-endpoint = <&dpi_out>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml
new file mode 100644
index 000000000000..288494b70e82
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/brcm,bcm2835-dpi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom VC4 (VideoCore4) DPI Controller
+
+maintainers:
+ - Eric Anholt <eric@anholt.net>
+
+properties:
+ compatible:
+ const: brcm,bcm2835-dpi
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: The core clock the unit runs on
+ - description: The pixel clock that feeds the pixelvalve
+
+ port:
+ type: object
+ description: >
+ Port node with a single endpoint connecting to the panel, as
+ defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/bcm2835.h>
+
+ panel: panel {
+ compatible = "ontat,yx700wv03", "simple-panel";
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+ };
+
+ dpi: dpi@7e208000 {
+ compatible = "brcm,bcm2835-dpi";
+ reg = <0x7e208000 0x8c>;
+ clocks = <&clocks BCM2835_CLOCK_VPU>,
+ <&clocks BCM2835_CLOCK_DPI>;
+ clock-names = "core", "pixel";
+
+ port {
+ dpi_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml
new file mode 100644
index 000000000000..3887675f844e
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/brcm,bcm2835-dsi0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom VC4 (VideoCore4) DSI Controller
+
+maintainers:
+ - Eric Anholt <eric@anholt.net>
+
+properties:
+ compatible:
+ enum:
+ - brcm,bcm2835-dsi0
+ - brcm,bcm2835-dsi1
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: The DSI PLL clock feeding the DSI analog PHY
+ - description: The DSI ESC clock
+ - description: The DSI pixel clock
+
+ clock-output-names: true
+ # FIXME: The meta-schemas don't seem to allow it for now
+ # items:
+ # - description: The DSI byte clock for the PHY
+ # - description: The DSI DDR2 clock
+ # - description: The DSI DDR clock
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-output-names
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/bcm2835.h>
+
+ dsi1: dsi@7e700000 {
+ compatible = "brcm,bcm2835-dsi1";
+ reg = <0x7e700000 0x8c>;
+ interrupts = <2 12>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #clock-cells = <1>;
+
+ clocks = <&clocks BCM2835_PLLD_DSI1>,
+ <&clocks BCM2835_CLOCK_DSI1E>,
+ <&clocks BCM2835_CLOCK_DSI1P>;
+ clock-names = "phy", "escape", "pixel";
+
+ clock-output-names = "dsi1_byte", "dsi1_ddr2", "dsi1_ddr";
+
+ pitouchscreen: panel@0 {
+ compatible = "raspberrypi,touchscreen";
+ reg = <0>;
+
+ /* ... */
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml
new file mode 100644
index 000000000000..834cc5f1c254
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml
@@ -0,0 +1,75 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/brcm,bcm2835-hdmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom VC4 (VideoCore4) HDMI Controller
+
+maintainers:
+ - Eric Anholt <eric@anholt.net>
+
+properties:
+ compatible:
+ const: brcm,bcm2835-hdmi
+
+ reg:
+ items:
+ - description: HDMI register range
+ - description: HD register range
+
+ interrupts:
+ minItems: 2
+
+ clocks:
+ items:
+ - description: The HDMI state machine clock
+ - description: The pixel clock
+
+ ddc:
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/phandle
+ description: >
+ Phandle of the I2C controller used for DDC EDID probing
+
+ hpd-gpios:
+ description: >
+ The GPIO pin for the HDMI hotplug detect (if it doesn't appear
+ as an interrupt/status bit in the HDMI controller itself)
+
+ dmas:
+ maxItems: 1
+ description: >
+ Should contain one entry pointing to the DMA channel used to
+ transfer audio data.
+
+ dma-names:
+ const: audio-rx
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - ddc
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/bcm2835.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ hdmi: hdmi@7e902000 {
+ compatible = "brcm,bcm2835-hdmi";
+ reg = <0x7e902000 0x600>,
+ <0x7e808000 0x100>;
+ interrupts = <2 8>, <2 9>;
+ ddc = <&i2c2>;
+ hpd-gpios = <&gpio 46 GPIO_ACTIVE_HIGH>;
+ clocks = <&clocks BCM2835_PLLH_PIX>,
+ <&clocks BCM2835_CLOCK_HSM>;
+ clock-names = "pixel", "hdmi";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml
new file mode 100644
index 000000000000..02410f8d6d49
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-hvs.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/brcm,bcm2835-hvs.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom VC4 (VideoCore4) Hardware Video Scaler
+
+maintainers:
+ - Eric Anholt <eric@anholt.net>
+
+properties:
+ compatible:
+ const: brcm,bcm2835-hvs
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ hvs@7e400000 {
+ compatible = "brcm,bcm2835-hvs";
+ reg = <0x7e400000 0x6000>;
+ interrupts = <2 1>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml
new file mode 100644
index 000000000000..e60791db1fa1
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/brcm,bcm2835-pixelvalve0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom VC4 (VideoCore4) PixelValve
+
+maintainers:
+ - Eric Anholt <eric@anholt.net>
+
+properties:
+ compatible:
+ enum:
+ - brcm,bcm2835-pixelvalve0
+ - brcm,bcm2835-pixelvalve1
+ - brcm,bcm2835-pixelvalve2
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ pixelvalve@7e807000 {
+ compatible = "brcm,bcm2835-pixelvalve2";
+ reg = <0x7e807000 0x100>;
+ interrupts = <2 10>; /* pixelvalve */
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml
new file mode 100644
index 000000000000..bb186197e471
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-txp.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/brcm,bcm2835-txp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom VC4 (VideoCore4) TXP (writeback) Controller
+
+maintainers:
+ - Eric Anholt <eric@anholt.net>
+
+properties:
+ compatible:
+ const: brcm,bcm2835-txp
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ txp: txp@7e004000 {
+ compatible = "brcm,bcm2835-txp";
+ reg = <0x7e004000 0x20>;
+ interrupts = <1 11>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-v3d.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-v3d.yaml
new file mode 100644
index 000000000000..8a73780f573d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-v3d.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/brcm,bcm2835-v3d.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom VC4 (VideoCore4) V3D GPU
+
+maintainers:
+ - Eric Anholt <eric@anholt.net>
+
+properties:
+ compatible:
+ enum:
+ - brcm,bcm2835-v3d
+ - brcm,cygnus-v3d
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ v3d: v3d@7ec00000 {
+ compatible = "brcm,bcm2835-v3d";
+ reg = <0x7ec00000 0x1000>;
+ interrupts = <1 10>;
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml
new file mode 100644
index 000000000000..0dcf0c397375
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml
@@ -0,0 +1,34 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/brcm,bcm2835-vc4.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom VC4 (VideoCore4) GPU
+
+maintainers:
+ - Eric Anholt <eric@anholt.net>
+
+description: >
+ The VC4 device present on the Raspberry Pi includes a display system
+ with HDMI output and the HVS (Hardware Video Scaler) for compositing
+ display planes.
+
+properties:
+ compatible:
+ enum:
+ - brcm,bcm2835-vc4
+ - brcm,cygnus-vc4
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ vc4: gpu {
+ compatible = "brcm,bcm2835-vc4";
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml
new file mode 100644
index 000000000000..d900cc57b4ec
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/brcm,bcm2835-vec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom VC4 (VideoCore4) VEC
+
+maintainers:
+ - Eric Anholt <eric@anholt.net>
+
+properties:
+ compatible:
+ const: brcm,bcm2835-vec
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/bcm2835.h>
+
+ vec: vec@7e806000 {
+ compatible = "brcm,bcm2835-vec";
+ reg = <0x7e806000 0x1000>;
+ clocks = <&clocks BCM2835_CLOCK_VEC>;
+ interrupts = <2 27>;
+ };
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 3a003f310574..8d17e2e402fa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5818,7 +5818,7 @@ M: Eric Anholt <eric@anholt.net>
S: Supported
T: git git://github.com/anholt/linux
T: git git://anongit.freedesktop.org/drm/drm-misc
-F: Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
+F: Documentation/devicetree/bindings/display/brcm,bcm2835-*.yaml
F: drivers/gpu/drm/vc4/
F: include/uapi/drm/vc4_drm.h
--
git-series 0.9.1
^ permalink raw reply related
* [PATCH v3 007/105] dt-bindings: display: vc4: dpi: Add missing clock-names property
From: Maxime Ripard @ 2020-05-27 15:47 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, Rob Herring
In-Reply-To: <cover.aaf2100bd7da4609f8bcb8216247d4b4e4379639.1590594512.git-series.maxime@cerno.tech>
While the device tree and the driver expected a clock-names property, it
wasn't explicitly documented in the previous binding. Make sure it is now.
Cc: devicetree@vger.kernel.org
Reviewed-by: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml
index 288494b70e82..58213c564e03 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml
@@ -21,6 +21,11 @@ properties:
- description: The core clock the unit runs on
- description: The pixel clock that feeds the pixelvalve
+ clock-names:
+ items:
+ - const: core
+ - const: pixel
+
port:
type: object
description: >
@@ -31,6 +36,7 @@ required:
- compatible
- reg
- clocks
+ - clock-names
- port
additionalProperties: false
--
git-series 0.9.1
^ permalink raw reply related
* [PATCH v3 008/105] dt-bindings: display: vc4: dsi: Add missing clock properties
From: Maxime Ripard @ 2020-05-27 15:47 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, Rob Herring
In-Reply-To: <cover.aaf2100bd7da4609f8bcb8216247d4b4e4379639.1590594512.git-series.maxime@cerno.tech>
While the device tree and the driver expected a clock-names and a
clock-cells properties, it wasn't explicitly documented in the previous
binding. Make sure it is now.
Cc: devicetree@vger.kernel.org
Reviewed-by: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml | 11 +++++++-
1 file changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml
index 3887675f844e..3c643b227a70 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-dsi0.yaml
@@ -10,6 +10,9 @@ maintainers:
- Eric Anholt <eric@anholt.net>
properties:
+ "#clock-cells":
+ const: 1
+
compatible:
enum:
- brcm,bcm2835-dsi0
@@ -24,6 +27,12 @@ properties:
- description: The DSI ESC clock
- description: The DSI pixel clock
+ clock-names:
+ items:
+ - const: phy
+ - const: escape
+ - const: pixel
+
clock-output-names: true
# FIXME: The meta-schemas don't seem to allow it for now
# items:
@@ -35,9 +44,11 @@ properties:
maxItems: 1
required:
+ - "#clock-cells"
- compatible
- reg
- clocks
+ - clock-names
- clock-output-names
- interrupts
--
git-series 0.9.1
^ permalink raw reply related
* Re: [PATCH v5 07/11] i2c: designware: Discard Cherry Trail model flag
From: Andy Shevchenko @ 2020-05-27 15:57 UTC (permalink / raw)
To: Serge Semin
Cc: Jarkko Nikula, Wolfram Sang, Mika Westerberg, Serge Semin,
Alexey Malahov, Thomas Bogendoerfer, Rob Herring, linux-mips,
devicetree, linux-i2c, linux-kernel
In-Reply-To: <20200527153046.6172-8-Sergey.Semin@baikalelectronics.ru>
On Wed, May 27, 2020 at 06:30:42PM +0300, Serge Semin wrote:
> A PM workaround activated by the flag MODEL_CHERRYTRAIL has been removed
> since commit 9cbeeca05049 ("i2c: designware: Remove Cherry Trail PMIC I2C
> bus pm_disabled workaround"), but the flag most likely by mistake has been
> left in the Dw I2C drivers. Let's remove it.
Same comment as per previous version.
> Since MODEL_MSCC_OCELOT is
> the only model-flag left, redefine it to be 0x100 so setting a very first
> bit in the MODEL_MASK bits range.
Cool, but why should we care?
> -#define MODEL_MSCC_OCELOT 0x00000200
> +#define MODEL_MSCC_OCELOT 0x00000100
We have 4 bits for that, and you are going to reuse this anyway.
I consider this unneeded churn.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v3 010/105] dt-bindings: display: vc4: Document BCM2711 VC5
From: Maxime Ripard @ 2020-05-27 15:47 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, Rob Herring
In-Reply-To: <cover.aaf2100bd7da4609f8bcb8216247d4b4e4379639.1590594512.git-series.maxime@cerno.tech>
The BCM2711 comes with a new VideoCore. Add a compatible for it.
Cc: devicetree@vger.kernel.org
Reviewed-by: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml
index 0dcf0c397375..49a5e041aa49 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-vc4.yaml
@@ -17,6 +17,7 @@ description: >
properties:
compatible:
enum:
+ - brcm,bcm2711-vc5
- brcm,bcm2835-vc4
- brcm,cygnus-vc4
--
git-series 0.9.1
^ permalink raw reply related
* Re: [PATCH v5 06/11] i2c: designware: Add Baytrail sem config DW I2C platform dependency
From: Andy Shevchenko @ 2020-05-27 15:55 UTC (permalink / raw)
To: Serge Semin
Cc: Jarkko Nikula, Wolfram Sang, Serge Semin, Alexey Malahov,
Thomas Bogendoerfer, Mika Westerberg, Rob Herring, linux-mips,
devicetree, linux-i2c, linux-kernel
In-Reply-To: <20200527153046.6172-7-Sergey.Semin@baikalelectronics.ru>
On Wed, May 27, 2020 at 06:30:41PM +0300, Serge Semin wrote:
> Currently Intel Baytrail I2C semaphore is a feature of the DW APB I2C
> platform driver. It's a bit confusing to see it's config in the menu at
> some separated place with no reference to the platform code. Let's move the
> config definition to be below the I2C_DESIGNWARE_PLATFORM config and mark
> it with "depends on I2C_DESIGNWARE_PLATFORM" statement. By doing so the
> config menu will display the feature right below the DW I2C platform
> driver item and will indent it to the right so signifying its belonging.
Same comment as per previous version.
> config I2C_DESIGNWARE_BAYTRAIL
> bool "Intel Baytrail I2C semaphore support"
> depends on ACPI
> + depends on I2C_DESIGNWARE_PLATFORM
> depends on (I2C_DESIGNWARE_PLATFORM=m && IOSF_MBI) || \
> (I2C_DESIGNWARE_PLATFORM=y && IOSF_MBI=y)
i.e. this change is not needed.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v3 104/105] dt-bindings: display: vc4: hdmi: Add BCM2711 HDMI controllers bindings
From: Maxime Ripard @ 2020-05-27 15:49 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, Rob Herring, devicetree
In-Reply-To: <cover.aaf2100bd7da4609f8bcb8216247d4b4e4379639.1590594512.git-series.maxime@cerno.tech>
The HDMI controllers found in the BCM2711 SoC need some adjustments to the
bindings, especially since the registers have been shuffled around in more
register ranges.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 109 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
new file mode 100644
index 000000000000..6091fe3d315b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
@@ -0,0 +1,109 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/brcm,bcm2711-hdmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM2711 HDMI Controller Device Tree Bindings
+
+maintainers:
+ - Eric Anholt <eric@anholt.net>
+
+properties:
+ compatible:
+ enum:
+ - brcm,bcm2711-hdmi0
+ - brcm,bcm2711-hdmi1
+
+ reg:
+ items:
+ - description: HDMI controller register range
+ - description: DVP register range
+ - description: HDMI PHY register range
+ - description: Rate Manager register range
+ - description: Packet RAM register range
+ - description: Metadata RAM register range
+ - description: CSC register range
+ - description: CEC register range
+ - description: HD register range
+
+ reg-names:
+ items:
+ - const: hdmi
+ - const: dvp
+ - const: phy
+ - const: rm
+ - const: packet
+ - const: metadata
+ - const: csc
+ - const: cec
+ - const: hd
+
+ clocks:
+ description: The HDMI state machine clock
+
+ clock-names:
+ const: hdmi
+
+ ddc:
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/phandle
+ description: >
+ Phandle of the I2C controller used for DDC EDID probing
+
+ hpd-gpios:
+ description: >
+ The GPIO pin for the HDMI hotplug detect (if it doesn't appear
+ as an interrupt/status bit in the HDMI controller itself)
+
+ dmas:
+ maxItems: 1
+ description: >
+ Should contain one entry pointing to the DMA channel used to
+ transfer audio data.
+
+ dma-names:
+ const: audio-rx
+
+ resets:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - resets
+ - ddc
+
+additionalProperties: false
+
+examples:
+ - |
+ hdmi0: hdmi@7ef00700 {
+ compatible = "brcm,bcm2711-hdmi0";
+ reg = <0x7ef00700 0x300>,
+ <0x7ef00300 0x200>,
+ <0x7ef00f00 0x80>,
+ <0x7ef00f80 0x80>,
+ <0x7ef01b00 0x200>,
+ <0x7ef01f00 0x400>,
+ <0x7ef00200 0x80>,
+ <0x7ef04300 0x100>,
+ <0x7ef20000 0x100>;
+ reg-names = "hdmi",
+ "dvp",
+ "phy",
+ "rm",
+ "packet",
+ "metadata",
+ "csc",
+ "cec",
+ "hd";
+ clocks = <&firmware_clocks 13>;
+ clock-names = "hdmi";
+ resets = <&dvp 0>;
+ ddc = <&ddc0>;
+ };
+
+...
--
git-series 0.9.1
^ permalink raw reply related
* Re: [PATCH v4 11/11] i2c: designware: Add Baikal-T1 System I2C support
From: Andy Shevchenko @ 2020-05-27 15:52 UTC (permalink / raw)
To: Serge Semin
Cc: Serge Semin, Jarkko Nikula, Wolfram Sang, Mika Westerberg,
Alexey Malahov, Thomas Bogendoerfer, Rob Herring, linux-mips,
devicetree, linux-i2c, linux-kernel
In-Reply-To: <20200527150431.z25aibkn6edplneh@mobilestation>
On Wed, May 27, 2020 at 06:04:31PM +0300, Serge Semin wrote:
> On Wed, May 27, 2020 at 05:03:03PM +0300, Andy Shevchenko wrote:
> > On Wed, May 27, 2020 at 03:01:11PM +0300, Serge Semin wrote:
...
> > > +static struct regmap_config bt1_i2c_cfg = {
> > > + .reg_bits = 32,
> > > + .val_bits = 32,
> > > + .reg_stride = 4,
> > > + .fast_io = true,
> > > + .reg_read = bt1_i2c_read,
> > > + .reg_write = bt1_i2c_write,
> > > + .max_register = DW_IC_COMP_TYPE
And perhaps add a comma?
> > > +};
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v3 058/105] dt-bindings: display: vc4: pv: Add BCM2711 pixel valves
From: Maxime Ripard @ 2020-05-27 15:48 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, Rob Herring
In-Reply-To: <cover.aaf2100bd7da4609f8bcb8216247d4b4e4379639.1590594512.git-series.maxime@cerno.tech>
The BCM2711 comes with other pixelvalves that have different requirements
and capabilities. Let's document their compatible.
Cc: devicetree@vger.kernel.org
Reviewed-by: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml
index e60791db1fa1..4e1ba03f6477 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-pixelvalve0.yaml
@@ -15,6 +15,11 @@ properties:
- brcm,bcm2835-pixelvalve0
- brcm,bcm2835-pixelvalve1
- brcm,bcm2835-pixelvalve2
+ - brcm,bcm2711-pixelvalve0
+ - brcm,bcm2711-pixelvalve1
+ - brcm,bcm2711-pixelvalve2
+ - brcm,bcm2711-pixelvalve3
+ - brcm,bcm2711-pixelvalve4
reg:
maxItems: 1
--
git-series 0.9.1
^ permalink raw reply related
* [PATCH v3 009/105] dt-bindings: display: vc4: hdmi: Add missing clock-names property
From: Maxime Ripard @ 2020-05-27 15:47 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, Rob Herring
In-Reply-To: <cover.aaf2100bd7da4609f8bcb8216247d4b4e4379639.1590594512.git-series.maxime@cerno.tech>
While the device tree and the driver expected a clock-names property, it
wasn't explicitly documented in the previous binding. The documented order
was wrong too, so make sure clock-names is there and in the proper order.
Cc: devicetree@vger.kernel.org
Reviewed-by: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml
index 834cc5f1c254..52b3cdac0bdf 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-hdmi.yaml
@@ -23,8 +23,13 @@ properties:
clocks:
items:
- - description: The HDMI state machine clock
- description: The pixel clock
+ - description: The HDMI state machine clock
+
+ clock-names:
+ items:
+ - const: pixel
+ - const: hdmi
ddc:
allOf:
--
git-series 0.9.1
^ permalink raw reply related
* [PATCH v3 004/105] clk: bcm: Add BCM2711 DVP driver
From: Maxime Ripard @ 2020-05-27 15:47 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
In-Reply-To: <cover.aaf2100bd7da4609f8bcb8216247d4b4e4379639.1590594512.git-series.maxime@cerno.tech>
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
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
drivers/clk/bcm/Kconfig | 11 +++-
drivers/clk/bcm/Makefile | 1 +-
drivers/clk/bcm/clk-bcm2711-dvp.c | 127 +++++++++++++++++++++++++++++++-
3 files changed, 139 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..784f12c72365 100644
--- a/drivers/clk/bcm/Kconfig
+++ b/drivers/clk/bcm/Kconfig
@@ -1,4 +1,15 @@
# SPDX-License-Identifier: GPL-2.0-only
+
+config CLK_BCM2711_DVP
+ tristate "Broadcom BCM2711 DVP support"
+ depends on ARCH_BCM2835 ||COMPILE_TEST
+ depends on COMMON_CLK
+ default ARCH_BCM2835
+ select RESET_SIMPLE
+ help
+ Enable common clock framework support for the Broadcom BCM2711
+ DVP Controller.
+
config CLK_BCM2835
bool "Broadcom BCM2835 clock support"
depends on ARCH_BCM2835 || ARCH_BRCMSTB || COMPILE_TEST
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
* [PATCH v3 003/105] dt-bindings: clock: Add BCM2711 DVP binding
From: Maxime Ripard @ 2020-05-27 15:47 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, Philipp Zabel, Rob Herring,
devicetree
In-Reply-To: <cover.aaf2100bd7da4609f8bcb8216247d4b4e4379639.1590594512.git-series.maxime@cerno.tech>
The BCM2711 has a unit controlling the HDMI0 and HDMI1 clock and reset
signals. Let's add a binding for it.
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Reviewed-by: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
---
Documentation/devicetree/bindings/clock/brcm,bcm2711-dvp.yaml | 47 +++++++-
1 file changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm2711-dvp.yaml
diff --git a/Documentation/devicetree/bindings/clock/brcm,bcm2711-dvp.yaml b/Documentation/devicetree/bindings/clock/brcm,bcm2711-dvp.yaml
new file mode 100644
index 000000000000..08543ecbe35b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/brcm,bcm2711-dvp.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/brcm,bcm2711-dvp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Broadcom BCM2711 HDMI DVP Device Tree Bindings
+
+maintainers:
+ - Maxime Ripard <mripard@kernel.org>
+
+properties:
+ "#clock-cells":
+ const: 1
+
+ "#reset-cells":
+ const: 1
+
+ compatible:
+ const: brcm,brcm2711-dvp
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - "#clock-cells"
+ - "#reset-cells"
+ - compatible
+ - reg
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ dvp: clock@7ef00000 {
+ compatible = "brcm,brcm2711-dvp";
+ reg = <0x7ef00000 0x10>;
+ clocks = <&clk_108MHz>;
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+...
--
git-series 0.9.1
^ permalink raw reply related
* [PATCH v3 000/105] drm/vc4: Support BCM2711 Display Pipeline
From: Maxime Ripard @ 2020-05-27 15:47 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,
Michael Turquette, Philipp Zabel, Rob Herring, Stephen Boyd
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).
This is based on the firmware clocks series sent separately:
https://lore.kernel.org/lkml/cover.662a8d401787ef33780d91252a352de91dc4be10.1590594293.git-series.maxime@cerno.tech/
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: 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>
Changes from v2:
- Rebased on top of next-20200526
- Split the firmware clock series away
- Removed the stuck pixel (with all the subsequent pixels being shifted
by one
- Fixed the writeback issue too.
- Fix the dual output
- Fixed the return value of phy_get_cp_current
- Enhanced the comment on the reset delay
- Increase the max width and height
- Made a proper Kconfig option for the DVP clock driver
- Fixed the alsa card name collision
Changes from v1:
- Rebased on top of 5.7-rc1
- Run checkpatch
- Added audio support
- Fixed some HDMI timeouts
- Swiched to clk_hw_register_gate_parent_data
- Reorder Kconfig symbols in drivers/i2c/busses
- Make the firmware clocks a child of the firmware node
- Switch DVP clock driver to clk_hw interface
- constify raspberrypi_clk_data in raspberrypi_clock_property
- Don't mark firmware clocks as IGNORE_UNUSED
- Change from reset_ms to reset_us in reset-simple, and add a bit more
comments
- Remove generic clk patch to test if a NULL pointer is returned
- Removed misleading message in the is_prepared renaming patch commit
message
- Constify HDMI controller variants
- Fix a bug in the allocation size of the clk data array
- Added a mention in the DT binding conversion patches about the breakage
- Merged a few fixes from kbuild
- Fixed a few bisection and CEC build issues
- Collected Acked-by and Reviewed-by
- Change Dave email address to raspberrypi.com
Dave Stevenson (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
Maxime Ripard (99):
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: Switch to of_device_get_match_data
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: Restrict HACT_ACT setup to DSI
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
drm/vc4: crtc: Turn pixelvalve reset into a function
drm/vc4: crtc: Move HVS mode config to HVS file
drm/vc4: crtc: Move PV dump to config_pv
drm/vc4: crtc: Move HVS init and close to a function
drm/vc4: crtc: Move the HVS gamma LUT setup to our init function
drm/vc4: hvs: Make sure our channel is reset
drm/vc4: hvs: Remove mode_set_nofb
drm/vc4: crtc: Remove mode_set_nofb
drm/vc4: crtc: Remove redundant pixelvalve reset
drm/vc4: crtc: Move HVS channel init before the PV initialisation
drm/vc4: encoder: Add finer-grained encoder callbacks
drm/vc4: crtc: Add a delay after disabling the PixelValve output
drm/vc4: crtc: Clear the PixelValve FIFO on disable
drm/vc4: crtc: Clear the PixelValve FIFO during configuration
drm/vc4: hvs: Make the stop_channel function public
drm/vc4: hvs: Introduce a function to get the assigned FIFO
drm/vc4: crtc: Move the CRTC disable out
drm/vc4: drv: Disable the CRTC at boot time
dt-bindings: display: vc4: pv: Add BCM2711 pixel valves
drm/vc4: crtc: Add BCM2711 pixelvalves
drm/vc4: crtc: Make state functions public
drm/vc4: crtc: Split CRTC data in two
drm/vc4: crtc: Only access the PixelValve registers if we have to
drm/vc4: crtc: Move the CRTC initialisation to a separate function
drm/vc4: crtc: Change the HVS5 test for of_device_is_compatible
drm/vc4: crtc: Move the txp_armed function to the TXP
drm/vc4: txp: Turn the TXP into a CRTC of its own
drm/vc4: crtc: Remove the feed_txp tests
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: Use clk_set_min_rate instead
drm/vc4: hdmi: Deal with multiple ALSA cards
drm/vc4: hdmi: Remove register dumps in enable
drm/vc4: hdmi: Always recenter the HDMI FIFO
drm/vc4: hdmi: Implement finer-grained hooks
drm/vc4: hdmi: Do the VID_CTL configuration at once
drm/vc4: hdmi: Switch to blank pixels when disabled
drm/vc4: hdmi: Support the BCM2711 HDMI controllers
dt-bindings: display: vc4: hdmi: Add BCM2711 HDMI controllers bindings
ARM: dts: bcm2711: Enable the display pipeline
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 | 46 ++-
arch/arm/boot/dts/bcm2711.dtsi | 130 +++++-
drivers/clk/bcm/Kconfig | 11 +-
drivers/clk/bcm/Makefile | 1 +-
drivers/clk/bcm/clk-bcm2711-dvp.c | 127 ++++++-
drivers/gpu/drm/vc4/Makefile | 1 +-
drivers/gpu/drm/vc4/vc4_crtc.c | 776 ++++++++++++++---------------------
drivers/gpu/drm/vc4/vc4_drv.c | 9 +-
drivers/gpu/drm/vc4/vc4_drv.h | 105 ++++-
drivers/gpu/drm/vc4/vc4_hdmi.c | 1610 ++++++++++++++++++++++++++++++++++++++++++------------------------------
drivers/gpu/drm/vc4/vc4_hdmi.h | 183 ++++++++-
drivers/gpu/drm/vc4/vc4_hdmi_phy.c | 520 +++++++++++++++++++++++-
drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 451 ++++++++++++++++++++-
drivers/gpu/drm/vc4/vc4_hvs.c | 362 +++++++++++++++-
drivers/gpu/drm/vc4/vc4_kms.c | 191 ++++++++-
drivers/gpu/drm/vc4/vc4_plane.c | 271 +++++++++---
drivers/gpu/drm/vc4/vc4_regs.h | 176 +++-----
drivers/gpu/drm/vc4/vc4_txp.c | 109 ++++-
drivers/reset/reset-simple.c | 23 +-
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 | 48 ++-
37 files changed, 4510 insertions(+), 1514 deletions(-)
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: ec9e6942c9f16390e530c2aea2a565f95fe6e929
--
git-series 0.9.1
^ permalink raw reply
* Re: [PATCH v4 07/11] i2c: designware: Discard Cherry Trail model flag
From: Andy Shevchenko @ 2020-05-27 15:48 UTC (permalink / raw)
To: Serge Semin
Cc: Serge Semin, Jarkko Nikula, Wolfram Sang, Mika Westerberg,
Alexey Malahov, Thomas Bogendoerfer, Rob Herring, linux-mips,
devicetree, linux-i2c, linux-kernel
In-Reply-To: <20200527142902.2xpteguuotsl3z7y@mobilestation>
On Wed, May 27, 2020 at 05:29:02PM +0300, Serge Semin wrote:
> On Wed, May 27, 2020 at 04:43:39PM +0300, Andy Shevchenko wrote:
> > On Wed, May 27, 2020 at 03:01:07PM +0300, Serge Semin wrote:
> > > A PM workaround activated by the flag MODEL_CHERRYTRAIL has been removed
> > > since commit 9cbeeca05049 ("i2c: designware: Remove Cherry Trail PMIC I2C
> > > bus pm_disabled workaround"), but the flag most likely by mistake has been
> > > left in the Dw I2C drivers. Let's remove it.
> >
> > ...
> >
> > > -#define MODEL_MSCC_OCELOT 0x00000200
> > > +#define MODEL_MSCC_OCELOT 0x00000100
> >
> > But why?
> >
> > Does 0x200 work or not? I didn't see this in commit message.
>
> I removed the MODEL_CHERRYTRAIL flag and redefined the only left
> MODEL_MSCC_OCELOT flag to set the very first bit allocated for the model
> flags. Isn't that obvious?
Yes, but how it's related to the MSCC_OCELOT?
Can't you simple put your define later to that number if absence of 0x100
provokes an exception when reading this code.
Again, unneeded churn.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v3 02/25] dt-bindings: clock: Add a binding for the RPi Firmware clocks
From: Maxime Ripard @ 2020-05-27 15:44 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: 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
In-Reply-To: <cover.662a8d401787ef33780d91252a352de91dc4be10.1590594293.git-series.maxime@cerno.tech>
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
* Re: [PATCH v4 06/11] i2c: designware: Add Baytrail sem config DW I2C platform dependency
From: Andy Shevchenko @ 2020-05-27 15:46 UTC (permalink / raw)
To: Serge Semin
Cc: Serge Semin, Jarkko Nikula, Wolfram Sang, Alexey Malahov,
Thomas Bogendoerfer, Mika Westerberg, Rob Herring, linux-mips,
devicetree, linux-i2c, linux-kernel
In-Reply-To: <20200527142406.jzdtkbdb2q6st7e6@mobilestation>
On Wed, May 27, 2020 at 05:24:06PM +0300, Serge Semin wrote:
> On Wed, May 27, 2020 at 04:42:20PM +0300, Andy Shevchenko wrote:
> > On Wed, May 27, 2020 at 03:01:06PM +0300, Serge Semin wrote:
> > > Currently Intel Baytrail I2C semaphore is a feature of the DW APB I2C
> > > platform driver. It's a bit confusing to see it's config in the menu at
> > > some separated place with no reference to the platform code. Let's move the
> > > config definition to be below the I2C_DESIGNWARE_PLATFORM config and mark
> > > it with "depends on I2C_DESIGNWARE_PLATFORM" statement. By doing so the
> > > config menu will display the feature right below the DW I2C platform
> > > driver item and will indent it to the right so signifying its belonging.
...
> > > config I2C_DESIGNWARE_BAYTRAIL
> > > bool "Intel Baytrail I2C semaphore support"
> > > depends on ACPI
> > > + depends on I2C_DESIGNWARE_PLATFORM
> > > depends on (I2C_DESIGNWARE_PLATFORM=m && IOSF_MBI) || \
> > > (I2C_DESIGNWARE_PLATFORM=y && IOSF_MBI=y)
> >
> > I didn't get this. What is broken now with existing dependencies?
>
> With no explicit "depends on I2C_DESIGNWARE_PLATFORM" the entry isn't right
> shifted with respect to the I2C_DESIGNWARE_PLATFORM config entry in the kernel
> menuconfig. So it looks like a normal no-yes driver without it.
I didn't get. Is there problems with current case? (I don't see it).
If there is a problem, it should have a separate patch and commit message.
As for now above excerpt seems redundant and unneeded churn.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v3 00/25] clk: bcm: rpi: Add support for BCM2711 firmware clocks
From: Maxime Ripard @ 2020-05-27 15:44 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: 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,
Michael Turquette, Rob Herring, Stephen Boyd
Hi,
Since the whole DRM/HDMI support began to grow fairly big, I've chosen
to split away the two discussions between the firmware clocks and the
HDMI support.
Let me know what you think,
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: Michael Turquette <mturquette@baylibre.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Stephen Boyd <sboyd@kernel.org>
Changes from v2:
- Rebased on top of next-20200526
- Split away from the HDMI series
- Fixed an of_node leakage in the firmware driver
- Fixed an of_node leakage in the firmware clocks driver
- Added the min/max rate retrieval to all the firmware clocks
- Added proper name for the firmware clocks
- Removed the PLLB setup from the firmware clocks and moved it back to
the MMIO driver
Florian Fainelli (1):
dt-bindings: arm: bcm: Convert BCM2835 firmware binding to YAML
Maxime Ripard (24):
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: Use CCF boundaries instead of rolling our own
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: Add an enum for the firmware clocks
clk: bcm: rpi: Discover the firmware clocks
clk: bcm: rpi: Give firmware clocks a name
Revert "clk: bcm2835: remove pllb"
clk: bcm: rpi: Remove the quirks for the CPU clock
ARM: dts: bcm2711: Add firmware clocks node
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt | 14 +---
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 59 ++++++++++++++-
arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 5 +-
drivers/clk/bcm/clk-bcm2835.c | 30 ++++++-
drivers/clk/bcm/clk-raspberrypi.c | 299 ++++++++++++++++++++++++++++++++++++++++++++----------------------------
drivers/firmware/raspberrypi.c | 14 +++-
include/soc/bcm2835/raspberrypi-firmware.h | 5 +-
7 files changed, 293 insertions(+), 133 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
base-commit: b0523c7b1c9d0edcd6c0fe6d2cb558a9ad5c60a8
--
git-series 0.9.1
^ permalink raw reply
* Re: [PATCH v2 09/14] device core: Add ability to handle multiple dma offsets
From: Jim Quinlan @ 2020-05-27 15:43 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS,
Christoph Hellwig, maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE,
Rob Herring, Frank Rowand, Greg Kroah-Hartman, Marek Szyprowski,
Robin Murphy, Alan Stern, Oliver Neukum, Rafael J. Wysocki,
Andy Shevchenko, Wolfram Sang, Corey Minyard, Srinivas Kandagatla,
Suzuki K Poulose, Saravana Kannan, Heikki Krogerus, Dan Williams,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list,
open list:USB SUBSYSTEM, open list:DMA MAPPING HELPERS
In-Reply-To: <59a0b4e1454a8ef4d3e4ebaf55dcbf3dcd2d73a2.camel@suse.de>
Hi Nicolas,
On Wed, May 27, 2020 at 11:00 AM Nicolas Saenz Julienne
<nsaenzjulienne@suse.de> wrote:
>
> Hi Jim,
> one thing comes to mind, there is a small test suite in drivers/of/unittest.c
> (specifically of_unittest_pci_dma_ranges()) you could extend it to include your
> use cases.
Sure, will check out.
>
> On Tue, 2020-05-26 at 15:12 -0400, Jim Quinlan wrote:
> > The new field in struct device 'dma_pfn_offset_map' is used to facilitate
> > the use of multiple pfn offsets between cpu addrs and dma addrs. It is
> > similar to 'dma_pfn_offset' except that the offset chosen depends on the
> > cpu or dma address involved.
> >
> > Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> > ---
> > drivers/of/address.c | 65 +++++++++++++++++++++++++++++++++++--
> > drivers/usb/core/message.c | 3 ++
> > drivers/usb/core/usb.c | 3 ++
> > include/linux/device.h | 10 +++++-
> > include/linux/dma-direct.h | 10 ++++--
> > include/linux/dma-mapping.h | 46 ++++++++++++++++++++++++++
> > kernel/dma/Kconfig | 13 ++++++++
> > 7 files changed, 144 insertions(+), 6 deletions(-)
> >
>
> [...]
>
> > @@ -977,10 +1020,19 @@ int of_dma_get_range(struct device *dev, struct
> > device_node *np, u64 *dma_addr,
> > pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
> > range.bus_addr, range.cpu_addr, range.size);
> >
> > + num_ranges++;
> > if (dma_offset && range.cpu_addr - range.bus_addr != dma_offset)
> > {
> > - pr_warn("Can't handle multiple dma-ranges with different
> > offsets on node(%pOF)\n", node);
> > - /* Don't error out as we'd break some existing DTs */
> > - continue;
> > + if (!IS_ENABLED(CONFIG_DMA_PFN_OFFSET_MAP)) {
> > + pr_warn("Can't handle multiple dma-ranges with
> > different offsets on node(%pOF)\n", node);
> > + pr_warn("Perhaps set DMA_PFN_OFFSET_MAP=y?\n");
> > + /*
> > + * Don't error out as we'd break some existing
> > + * DTs that are using configs w/o
> > + * CONFIG_DMA_PFN_OFFSET_MAP set.
> > + */
> > + continue;
>
> dev->bus_dma_limit is set in of_dma_configure(), this function's caller, based
> on dma_start's value (set after this continue). So you'd be effectively setting
> the dev->bus_dma_limit to whatever we get from the first dma-range.
I'm not seeing that at all. On the evaluation of each dma-range,
dma_start and dma_end are re-evaluated to be the lowest and highest
bus values of the dma-ranges seen so far. After all dma-ranges are
examined, dev->bus_dma_limit being set to the highest. In fact, the
current code -- ie before my commits -- already does this for multiple
dma-ranges as long as the cpu-bus offset is the same in the
dma-ranges.
>
> This can be troublesome depending on how the dma-ranges are setup, for example
> if the first dma-range doesn't include the CMA area, in arm64 generally set as
> high as possible in ZONE_DMA32, that would render it useless for
> dma/{direct/swiotlb}. Again depending on the bus_dma_limit value, if smaller
> than ZONE_DMA you'd be unable to allocate any DMA memory.
>
> IMO, a solution to this calls for a revamp of dma-direct's dma_capable(): match
> the target DMA memory area with each dma-range we have to see if it fits.
>
> > + }
> > + dma_multi_pfn_offset = true;
> > }
> > dma_offset = range.cpu_addr - range.bus_addr;
> >
> > @@ -991,6 +1043,13 @@ int of_dma_get_range(struct device *dev, struct
> > device_node *np, u64 *dma_addr,
> > dma_end = range.bus_addr + range.size;
> > }
> >
> > + if (dma_multi_pfn_offset) {
> > + dma_offset = 0;
> > + ret = attach_dma_pfn_offset_map(dev, node, num_ranges);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > if (dma_start >= dma_end) {
> > ret = -EINVAL;
> > pr_debug("Invalid DMA ranges configuration on node(%pOF)\n",
> > diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
> > index 6197938dcc2d..aaa3e58f5eb4 100644
> > --- a/drivers/usb/core/message.c
> > +++ b/drivers/usb/core/message.c
> > @@ -1960,6 +1960,9 @@ int usb_set_configuration(struct usb_device *dev, int
> > configuration)
> > */
> > intf->dev.dma_mask = dev->dev.dma_mask;
> > intf->dev.dma_pfn_offset = dev->dev.dma_pfn_offset;
> > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> > + intf->dev.dma_pfn_offset_map = dev->dev.dma_pfn_offset_map;
> > +#endif
>
> Thanks for looking at this, that said, I see more instances of drivers changing
> dma_pfn_offset outside of the core code. Why not doing this there too?
>
> Also, are we 100% sure that dev->dev.dma_pfn_offset isn't going to be freed
> before we're done using intf->dev? Maybe it's safer to copy the ranges?
>
> > INIT_WORK(&intf->reset_ws, __usb_queue_reset_device);
> > intf->minor = -1;
> > device_initialize(&intf->dev);
> > diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
> > index f16c26dc079d..d2ed4d90e56e 100644
> > --- a/drivers/usb/core/usb.c
> > +++ b/drivers/usb/core/usb.c
> > @@ -612,6 +612,9 @@ struct usb_device *usb_alloc_dev(struct usb_device
> > *parent,
> > */
> > dev->dev.dma_mask = bus->sysdev->dma_mask;
> > dev->dev.dma_pfn_offset = bus->sysdev->dma_pfn_offset;
> > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> > + dev->dev.dma_pfn_offset_map = bus->sysdev->dma_pfn_offset_map;
> > +#endif
> > set_dev_node(&dev->dev, dev_to_node(bus->sysdev));
> > dev->state = USB_STATE_ATTACHED;
> > dev->lpm_disable_count = 1;
> > diff --git a/include/linux/device.h b/include/linux/device.h
> > index ac8e37cd716a..67a240ad4fc5 100644
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -493,6 +493,8 @@ struct dev_links_info {
> > * @bus_dma_limit: Limit of an upstream bridge or bus which imposes a smaller
> > * DMA limit than the device itself supports.
> > * @dma_pfn_offset: offset of DMA memory range relatively of RAM
> > + * @dma_pfn_offset_map: Like dma_pfn_offset but used when there are
> > multiple
> > + * pfn offsets for multiple dma-ranges.
> > * @dma_parms: A low level driver may set these to teach IOMMU code
> > about
> > * segment limitations.
> > * @dma_pools: Dma pools (if dma'ble device).
> > @@ -578,7 +580,13 @@ struct device {
> > allocations such descriptors. */
> > u64 bus_dma_limit; /* upstream dma constraint */
> > unsigned long dma_pfn_offset;
> > -
> > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> > + const struct dma_pfn_offset_region *dma_pfn_offset_map;
> > + /* Like dma_pfn_offset, but for
> > + * the unlikely case of multiple
> > + * offsets. If non-null, dma_pfn_offset
> > + * will be set to 0. */
> > +#endif
>
> I'm still sad this doesn't fully replace dma_pfn_offset & bus_dma_limit. I feel
> the extra logic involved in incorporating this as default isn't going to be
> noticeable as far as performance is concerned to single dma-range users, and
> it'd make for a nicer DMA code. Also you'd force everyone to test their changes
> on the multi dma-ranges code path, as opposed to having this disabled 99.9% of
> the time (hence broken every so often).
Good point.
>
> Note that I sympathize with the amount of work involved on improving that, so
> better wait to hear what more knowledgeable people have to say about this :)
Yes, I agree. I want to avoid coding and testing one solution only to
have a different reviewer NAK it.
Many thanks,
Jim
>
> Regards,
> Nicolas
>
^ permalink raw reply
* Re: [PATCH v25 06/16] dt: bindings: lp55xx: Update binding for Multicolor Framework
From: Dan Murphy @ 2020-05-27 15:41 UTC (permalink / raw)
To: Rob Herring
Cc: jacek.anaszewski, pavel, devicetree, linux-leds, linux-kernel,
Linus Walleij, Tony Lindgren, Benoît Cousson, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team
In-Reply-To: <20200527020101.GA891065@bogus>
Rob
On 5/26/20 9:01 PM, Rob Herring wrote:
> On Tue, May 26, 2020 at 11:46:42AM -0500, Dan Murphy wrote:
>> Update the DT binding to include the properties to use the
>> multicolor framework for the devices that use the LP55xx
>> framework.
>>
>> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
>> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>> CC: Tony Lindgren <tony@atomide.com>
>> CC: "Benoît Cousson" <bcousson@baylibre.com>
>> CC: Linus Walleij <linus.walleij@linaro.org>
>> CC: Shawn Guo <shawnguo@kernel.org>
>> CC: Sascha Hauer <s.hauer@pengutronix.de>
>> CC: Pengutronix Kernel Team <kernel@pengutronix.de>
>> CC: Fabio Estevam <festevam@gmail.com>
>> CC: NXP Linux Team <linux-imx@nxp.com>
>> ---
>> .../devicetree/bindings/leds/leds-lp55xx.txt | 149 +++++++++++++++---
>> 1 file changed, 124 insertions(+), 25 deletions(-)
> Convert this to schema first because it's going to need to reference
> the multi-color schema.
OK. This seems to be my life recently converting txt to yaml ;)
Dan
> Rob
^ permalink raw reply
* Re: [Freedreno] [PATCH 5/6] drm: msm: a6xx: use dev_pm_opp_set_bw to set DDR bandwidth
From: Rob Clark @ 2020-05-27 15:38 UTC (permalink / raw)
To: Sharat Masetty
Cc: freedreno,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
dri-devel, linux-arm-msm, Linux Kernel Mailing List,
Georgi Djakov, Matthias Kaehlcke, Viresh Kumar, saravanak,
Sibi Sankar, Rajendra Nayak, Jordan Crouse
In-Reply-To: <c8a514c9-5e48-b561-4b45-47cde3bdfb34@codeaurora.org>
On Wed, May 27, 2020 at 1:47 AM Sharat Masetty <smasetty@codeaurora.org> wrote:
>
> + more folks
>
> On 5/18/2020 9:55 PM, Rob Clark wrote:
> > On Mon, May 18, 2020 at 7:23 AM Jordan Crouse <jcrouse@codeaurora.org> wrote:
> >> On Thu, May 14, 2020 at 04:24:18PM +0530, Sharat Masetty wrote:
> >>> This patches replaces the previously used static DDR vote and uses
> >>> dev_pm_opp_set_bw() to scale GPU->DDR bandwidth along with scaling
> >>> GPU frequency.
> >>>
> >>> Signed-off-by: Sharat Masetty <smasetty@codeaurora.org>
> >>> ---
> >>> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 6 +-----
> >>> 1 file changed, 1 insertion(+), 5 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> >>> index 2d8124b..79433d3 100644
> >>> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> >>> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> >>> @@ -141,11 +141,7 @@ void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct dev_pm_opp *opp)
> >>>
> >>> gmu->freq = gmu->gpu_freqs[perf_index];
> >>>
> >>> - /*
> >>> - * Eventually we will want to scale the path vote with the frequency but
> >>> - * for now leave it at max so that the performance is nominal.
> >>> - */
> >>> - icc_set_bw(gpu->icc_path, 0, MBps_to_icc(7216));
> >>> + dev_pm_opp_set_bw(&gpu->pdev->dev, opp);
> >>> }
> >> This adds an implicit requirement that all targets need bandwidth settings
> >> defined in the OPP or they won't get a bus vote at all. I would prefer that
> >> there be an default escape valve but if not you'll need to add
> >> bandwidth values for the sdm845 OPP that target doesn't regress.
> >>
> > it looks like we could maybe do something like:
> >
> > ret = dev_pm_opp_set_bw(...);
> > if (ret) {
> > dev_warn_once(dev, "no bandwidth settings");
> > icc_set_bw(...);
> > }
> >
> > ?
> >
> > BR,
> > -R
>
> There is a bit of an issue here - Looks like its not possible to two icc
> handles to the same path. Its causing double enumeration of the paths
> in the icc core and messing up path votes. With [1] Since opp/core
> already gets a handle to the icc path as part of table add, drm/msm
> could do either
>
> a) Conditionally enumerate gpu->icc_path handle only when pm/opp core
> has not got the icc path handle. I could use something like [2] to
> determine if should initialize gpu->icc_path*
>
> b) Add peak-opp-configs in 845 dt and mandate all future versions to use
> this bindings. With this, I can remove gpu->icc_path from msm/drm
> completely and only rely on opp/core for bw voting.
The main thing is that we want to make sure newer dtb always works on
an older kernel without regression.. but, hmm.. I guess the
interconnects/interconnects-names properties haven't landed yet in
sdm845.dtsi? Maybe that lets us go with the simpler approach (b).
Looks like we haven't wired up interconnect for 8916 or 8996 either,
so probably we can just mandate this for all of them?
If we have landed the interconnect dts hookup for gpu somewhere that
I'm overlooking, I guess we would have to go with (a) and keep the
existing interconnects/interconnects-names properties.
BR,
-R
> [1] - https://lore.kernel.org/patchwork/cover/1240687/
>
> [2] - https://patchwork.kernel.org/patch/11527573/
>
> Let me know your thoughts
>
> Sharat
>
> >
> >> Jordan
> >>
> >>> unsigned long a6xx_gmu_get_freq(struct msm_gpu *gpu)
> >>> --
> >>> 2.7.4
> >>>
> >> --
> >> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> >> a Linux Foundation Collaborative Project
> >> _______________________________________________
> >> Freedreno mailing list
> >> Freedreno@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply
* Re: [PATCH v5 03/11] dt-bindings: i2c: dw: Add Baikal-T1 SoC I2C controller
From: Serge Semin @ 2020-05-27 15:35 UTC (permalink / raw)
To: Rob Herring
Cc: Serge Semin, Jarkko Nikula, Wolfram Sang, Alexey Malahov,
Thomas Bogendoerfer, Andy Shevchenko, Mika Westerberg, linux-mips,
linux-i2c, devicetree, linux-kernel
In-Reply-To: <20200527153046.6172-4-Sergey.Semin@baikalelectronics.ru>
Rob,
Could you please pay attention to this patch? The patchset review procedure
is nearly over, while the DT part is only partly reviewed by you.
Thanks
-Sergey
On Wed, May 27, 2020 at 06:30:38PM +0300, Serge Semin wrote:
> Add the "baikal,bt1-sys-i2c" compatible string to the DW I2C binding. Even
> though the corresponding node is supposed to be a child of the Baikal-T1
> System Controller, its reg property is left required for compatibility.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> Cc: linux-mips@vger.kernel.org
>
> ---
>
> Changelog v2:
> - Make the reg property being optional if it's Baikal-T1 System I2C DT
> node.
>
> Changelog v3:
> - Get back the reg property being mandatory even if it's Baikal-T1 System
> I2C DT node. Rob says it has to be in the DT node if there is a
> dedicated registers range in the System Controller registers space.
> ---
> Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
> index 101d78e8f19d..8c9b3db1b1b8 100644
> --- a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
> +++ b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
> @@ -31,6 +31,8 @@ properties:
> items:
> - const: mscc,ocelot-i2c
> - const: snps,designware-i2c
> + - description: Baikal-T1 SoC System I2C controller
> + const: baikal,bt1-sys-i2c
>
> reg:
> minItems: 1
> --
> 2.26.2
>
^ permalink raw reply
* Re: [PATCH v5 02/11] dt-bindings: i2c: Discard i2c-slave flag from the DW I2C example
From: Serge Semin @ 2020-05-27 15:33 UTC (permalink / raw)
To: Rob Herring
Cc: Serge Semin, Jarkko Nikula, Wolfram Sang, Alexey Malahov,
Thomas Bogendoerfer, Andy Shevchenko, Mika Westerberg, linux-mips,
linux-i2c, devicetree, linux-kernel
In-Reply-To: <20200527153046.6172-3-Sergey.Semin@baikalelectronics.ru>
Rob,
Could you pay attention to this patch? The patchset review procedure is
nearly over, while the DT part is only partly reviewed by you.
Thanks
-Sergey
On Wed, May 27, 2020 at 06:30:37PM +0300, Serge Semin wrote:
> dtc currently doesn't support I2C_OWN_SLAVE_ADDRESS flag set in the
> i2c "reg" property. If it is the compiler will print a warning:
>
> Warning (i2c_bus_reg): /example-2/i2c@1120000/eeprom@64: I2C bus unit address format error, expected "40000064"
> Warning (i2c_bus_reg): /example-2/i2c@1120000/eeprom@64:reg: I2C address must be less than 10-bits, got "0x40000064"
>
> In order to silence dtc up let's discard the flag from the DW I2C DT
> binding example for now. Just revert this commit when dtc is fixed.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> Cc: linux-mips@vger.kernel.org
>
> ---
>
> Changelog v3:
> - This is a new patch created as a result of the Rob request to remove
> the EEPROM-slave bit setting in the DT binndings example until the dtc
> is fixed.
> ---
> Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
> index 4bd430b2b41d..101d78e8f19d 100644
> --- a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
> +++ b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
> @@ -137,7 +137,7 @@ examples:
>
> eeprom@64 {
> compatible = "linux,slave-24c02";
> - reg = <0x40000064>;
> + reg = <0x64>;
> };
> };
> - |
> --
> 2.26.2
>
^ permalink raw reply
* [PATCH v5 03/11] dt-bindings: i2c: dw: Add Baikal-T1 SoC I2C controller
From: Serge Semin @ 2020-05-27 15:30 UTC (permalink / raw)
To: Jarkko Nikula, Wolfram Sang, Rob Herring
Cc: Serge Semin, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Andy Shevchenko, Mika Westerberg, linux-mips, linux-i2c,
devicetree, linux-kernel
In-Reply-To: <20200527153046.6172-1-Sergey.Semin@baikalelectronics.ru>
Add the "baikal,bt1-sys-i2c" compatible string to the DW I2C binding. Even
though the corresponding node is supposed to be a child of the Baikal-T1
System Controller, its reg property is left required for compatibility.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: linux-mips@vger.kernel.org
---
Changelog v2:
- Make the reg property being optional if it's Baikal-T1 System I2C DT
node.
Changelog v3:
- Get back the reg property being mandatory even if it's Baikal-T1 System
I2C DT node. Rob says it has to be in the DT node if there is a
dedicated registers range in the System Controller registers space.
---
Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
index 101d78e8f19d..8c9b3db1b1b8 100644
--- a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
@@ -31,6 +31,8 @@ properties:
items:
- const: mscc,ocelot-i2c
- const: snps,designware-i2c
+ - description: Baikal-T1 SoC System I2C controller
+ const: baikal,bt1-sys-i2c
reg:
minItems: 1
--
2.26.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox