* [PATCH] ARM: dts: imx6qdl-gw53xx: allow boot firmware to set eth1 MAC
From: Tim Harvey @ 2020-05-28 19:53 UTC (permalink / raw)
To: Shawn Guo, Sascha Hauer
Cc: Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
devicetree, linux-arm-kernel, linux-kernel, Rob Herring,
Tim Harvey
The GW53xx has a PCIe based GbE as the 2nd ethernet device. The
boot firmware will populate the local-mac-address field of the
device aliased to ethernet1 thus adding the PCIe device to
dt allows boot firmware to set its MAC address.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
---
arch/arm/boot/dts/imx6qdl-gw53xx.dtsi | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
index 8942bec..6601d07 100644
--- a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
@@ -8,6 +8,7 @@
/ {
/* these are used by bootloader for disabling nodes */
aliases {
+ ethernet1 = ð1;
led0 = &led0;
led1 = &led1;
led2 = &led2;
@@ -341,6 +342,23 @@
pinctrl-0 = <&pinctrl_pcie>;
reset-gpio = <&gpio1 29 GPIO_ACTIVE_LOW>;
status = "okay";
+
+ pcie@0,0,0 {
+ reg = <0x0000 0 0 0 0>;
+
+ pcie@1,0,0 {
+ reg = <0x0000 0 0 0 0>;
+
+ pcie@2,4,0 {
+ reg = <0x2000 0 0 0 0>;
+
+ eth1: pcie@4,0,0 {
+ reg = <0x0000 0 0 0 0>;
+ local-mac-address = [00 00 00 00 00 00];
+ };
+ };
+ };
+ };
};
&pwm2 {
--
2.7.4
^ permalink raw reply related
* Re: [RFC PATCH 1/6] dt-bindings: display/bridge: Add binding for input mux bridge
From: Rob Herring @ 2020-05-28 19:48 UTC (permalink / raw)
To: Guido Günther
Cc: Laurent Pinchart, David Airlie, Daniel Vetter, Shawn Guo,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Andrzej Hajda, Sam Ravnborg, Anson Huang, Leonard Crestez,
Lucas Stach, Peng Fan, Robert Chiras, dri-devel, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <14a44a664f40584ffa25c1764aab5ebf97809c71.1589548223.git.agx@sigxcpu.org>
On Fri, May 15, 2020 at 03:12:10PM +0200, Guido Günther wrote:
> The bridge allows to select the input source via a mux controller.
>
> Signed-off-by: Guido Günther <agx@sigxcpu.org>
> ---
> .../display/bridge/mux-input-bridge.yaml | 123 ++++++++++++++++++
> 1 file changed, 123 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml b/Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml
> new file mode 100644
> index 000000000000..4029cf63ee5c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/mux-input-bridge.yaml
> @@ -0,0 +1,123 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/mux-input-bridge.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: DRM input source selection via multiplexer
DRM is not a hardware thing.
The graph binding is already designed to support muxing. Generally,
multiple endpoints on an input node is a mux. So either the device with
the input ports knows how to select the input, or you just need a
mux-control property for the port to have some other device implement
the control.
You could do it like you have below. That would be appropriate if
there's a separate h/w device controlling the muxing. Say for example
some board level device controlled by i2c.
Rob
^ permalink raw reply
* Re: [PATCH 5/5] dt-bindings: timer: Add CLINT bindings
From: Sean Anderson @ 2020-05-28 19:37 UTC (permalink / raw)
To: Palmer Dabbelt
Cc: anup, Anup Patel, Paul Walmsley, aou, robh+dt, daniel.lezcano,
tglx, devicetree, Damien Le Moal, linux-kernel, Atish Patra,
Alistair Francis, linux-riscv
In-Reply-To: <mhng-0995a264-b39c-4790-9aa5-b8c598b43ffd@palmerdabbelt-glaptop1>
On 5/26/20 8:32 PM, Palmer Dabbelt wrote:
> On Thu, 21 May 2020 23:29:36 PDT (-0700), seanga2@gmail.com wrote:
>> On 5/22/20 1:54 AM, Anup Patel wrote:
>>> On Fri, May 22, 2020 at 1:35 AM Sean Anderson <seanga2@gmail.com> wrote:
>>>>
>>>> On 5/21/20 9:45 AM, Anup Patel wrote:
>>>>> +Required properties:
>>>>> +- compatible : "sifive,clint-1.0.0" and a string identifying the actual
>>>>> + detailed implementation in case that specific bugs need to be worked around.
>>>>
>>>> Should the "riscv,clint0" compatible string be documented here? This
>>>
>>> Yes, I forgot to add this compatible string. I will add in v2.
>>>
>>>> peripheral is not really specific to sifive, as it is present in most
>>>> rocket-chip cores.
>>>
>>> I agree that CLINT is present in a lot of non-SiFive RISC-V SOCs and
>>> FPGAs but this IP is only documented as part of SiFive FU540 SOC.
>>> (Refer, https://static.dev.sifive.com/FU540-C000-v1.0.pdf)
>>>
>>> The RISC-V foundation should host the CLINT spec independently
>>> under https://github.com/riscv and make CLINT spec totally open.
>>>
>>> For now, I have documented it just like PLIC DT bindings found at:
>>> Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.txt
>>
>> The PLIC seems to have its own RISC-V-sponsored documentation [1] which
>> was split off from the older privileged specs. By your logic above,
>> should it be renamed to riscv,plic0.txt (with a corresponding change in
>> the documented compatible strings)?
>>
>> [1] https://github.com/riscv/riscv-plic-spec
>
> Let's propose tagging that PLIC spec as v1.0.0 in the platform spec group, but
> I don't see a reason why that wouldn't be viable. Assuming that's all OK, we
> can start calling this a RISC-V PLIC (in addition to a SiFive PLIC, as they'll
> be compatible).
Is there a version anyewhere in that spec? I looked around a bit and
couldn't find one.
>>>
>>> If RISC-V maintainers agree then I will document it as "RISC-V CLINT".
>>>
>>> @Palmer ?? @Paul ??
>
> The CLINT is a SiFive spec. It has open source RTL so it's been implemented in
> other designs, but it's not a RISC-V spec. The CLIC, which is a superset of
> the CLINT, is a RISC-V spec. IIRC it's not finished yet (it's the fast
> interrupts task group), but presumably we should have a "riscv,clic-2.0.0" (or
> whatever it ends up being called) compat string to go along with the
> specification.
The rocket chip is a Chips Alliance project on github; presumably the
"proper" compatibility string would be something like
"chips-alliance,clint"? Alternatively, it is already referred to as
"riscv,clint0" in U-Boot, following the pattern of the plic.
--Sean
^ permalink raw reply
* Re: [PATCH v2 03/10] dt-bindings: serial: renesas,scifa: Document r8a7742 bindings
From: Rob Herring @ 2020-05-28 19:36 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Linus Walleij, linux-renesas-soc, linux-mmc, linux-serial,
Greg Kroah-Hartman, Vinod Koul, Prabhakar, devicetree, dmaengine,
Magnus Damm, Geert Uytterhoeven, Ulf Hansson, linux-kernel,
linux-gpio
In-Reply-To: <20200512222056.GA7267@bogus>
On Tue, May 12, 2020 at 05:20:56PM -0500, Rob Herring wrote:
> On Sun, 3 May 2020 22:46:47 +0100, Lad Prabhakar wrote:
> > RZ/G1H (R8A7742) SoC also has the R-Car gen2 compatible SCIFA ports,
> > so document the SoC specific bindings.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> > Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > ---
> > Documentation/devicetree/bindings/serial/renesas,scifa.yaml | 1 +
> > 1 file changed, 1 insertion(+)
> >
>
> Acked-by: Rob Herring <robh@kernel.org>
Geert asked me to apply this one, so I have now.
Rob
^ permalink raw reply
* Re: [PATCH v2 2/7] dt-bindings: usb: atmel: Update DT bindings documentation for sam9x60
From: Rob Herring @ 2020-05-28 19:26 UTC (permalink / raw)
To: cristian.birsan
Cc: linux-kernel, ludovic.desroches, alexandre.belloni,
linux-arm-kernel, balbi, robh+dt, devicetree, mark.rutland,
linux-usb, gregkh, nicolas.ferre
In-Reply-To: <20200515111631.31210-3-cristian.birsan@microchip.com>
On Fri, 15 May 2020 14:16:26 +0300, cristian.birsan@microchip.com wrote:
> From: Cristian Birsan <cristian.birsan@microchip.com>
>
> Add sam9x60 binding.
>
> Signed-off-by: Cristian Birsan <cristian.birsan@microchip.com>
> ---
> Documentation/devicetree/bindings/usb/atmel-usb.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 3/5] dt-bindings: PCI: uniphier: Add iATU register description
From: Rob Herring @ 2020-05-28 19:25 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: linux-kernel, Gustavo Pimentel, devicetree, Lorenzo Pieralisi,
Bjorn Helgaas, Masahiro Yamada, Rob Herring, linux-arm-kernel,
Jassi Brar, linux-pci, Jingoo Han, Masami Hiramatsu
In-Reply-To: <1589536743-6684-4-git-send-email-hayashi.kunihiko@socionext.com>
On Fri, 15 May 2020 18:59:01 +0900, Kunihiko Hayashi wrote:
> In the dt-bindings, "atu" reg-names is required to get the register space
> for iATU in Synopsis DWC version 4.80 or later.
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> ---
> Documentation/devicetree/bindings/pci/uniphier-pcie.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/4] dt-binding: phy: convert ti,omap-usb2 to YAML
From: Rob Herring @ 2020-05-28 19:24 UTC (permalink / raw)
To: Roger Quadros; +Cc: kishon, b-liu, devicetree, vigneshr, nsekhar
In-Reply-To: <20200515080518.26870-3-rogerq@ti.com>
On Fri, May 15, 2020 at 11:05:16AM +0300, Roger Quadros wrote:
> Move ti,omap-usb2 to its own YAML schema.
>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
> ---
> .../devicetree/bindings/phy/ti,omap-usb2.yaml | 73 +++++++++++++++++++
> .../devicetree/bindings/phy/ti-phy.txt | 37 ----------
> 2 files changed, 73 insertions(+), 37 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/phy/ti,omap-usb2.yaml
>
> diff --git a/Documentation/devicetree/bindings/phy/ti,omap-usb2.yaml b/Documentation/devicetree/bindings/phy/ti,omap-usb2.yaml
> new file mode 100644
> index 000000000000..ecfb28f714ea
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/ti,omap-usb2.yaml
> @@ -0,0 +1,73 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/phy/ti,omap-usb2.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: OMAP USB2 PHY
> +
> +maintainers:
> + - Kishon Vijay Abraham I <kishon@ti.com>
> + - Roger Quadros <rogerq@ti.com>
> +
> +properties:
> + compatible:
> + anyOf:
Only 1 entry, don't need anyOf.
> + - items:
> + - enum:
> + - "ti,dra7x-usb2"
> + - "ti,dra7x-usb2-phy2"
> + - "ti,am654-usb2"
> + - enum:
> + - "ti,omap-usb2"
> +
> + reg:
> + maxItems: 1
> + description: address and length of the register set for the device.
Drop. That's every 'reg'.
> +
> + '#phy-cells':
> + description:
> + Number of cells in a PHY specifier. The meaning of all those
> + cells is defined by the binding for the phy node. The PHY
> + provider can use the values in cells to find the appropriate PHY.
Yes, and this is a phy bindings, so you need to define the value.
> + $ref: /schemas/types.yaml#/definitions/uint32
#*-cells already has a type.
> +
> + clocks:
> + minItems: 1
> + items:
> + - description: wakeup clock
> + - description: reference clock
> +
> + clock-names:
> + minItems: 1
> + items:
> + - const: "wkupclk"
> + - const: "refclk"
Don't need quotes.
> +
> + syscon-phy-power:
> + description:
> + phandle/offset pair. Phandle to the system control module
> + register offset to power on/off the PHY.
> +
> + ctrl-module:
> + description:
> + (deprecated) phandle of the control module used by PHY driver
> + to power on the PHY. Use syscon-phy-power instead.
These 2 need a type reference.
> +
> +required:
> + - compatible
> + - reg
> + - '#phy-cells'
> + - clocks
> + - clock-names
> +
> +examples:
> + - |
> + usb0_phy: phy@4100000 {
> + compatible = "ti,am654-usb2", "ti,omap-usb2";
> + reg = <0x0 0x4100000 0x0 0x54>;
> + syscon-phy-power = <&scm_conf 0x4000>;
> + clocks = <&k3_clks 151 0>, <&k3_clks 151 1>;
> + clock-names = "wkupclk", "refclk";
> + #phy-cells = <0>;
> + };
> diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt
> index 8f93c3b694a7..60c9d0ac75e6 100644
> --- a/Documentation/devicetree/bindings/phy/ti-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
> @@ -27,43 +27,6 @@ omap_control_usb: omap-control-usb@4a002300 {
> reg-names = "otghs_control";
> };
>
> -OMAP USB2 PHY
> -
> -Required properties:
> - - compatible: Should be "ti,omap-usb2"
> - Should be "ti,dra7x-usb2" for the 1st instance of USB2 PHY on
> - DRA7x
> - Should be "ti,dra7x-usb2-phy2" for the 2nd instance of USB2 PHY
> - in DRA7x
> - Should be "ti,am654-usb2" for the USB2 PHYs on AM654.
> - - reg : Address and length of the register set for the device.
> - - #phy-cells: determine the number of cells that should be given in the
> - phandle while referencing this phy.
> - - clocks: a list of phandles and clock-specifier pairs, one for each entry in
> - clock-names.
> - - clock-names: should include:
> - * "wkupclk" - wakeup clock.
> - * "refclk" - reference clock (optional).
> -
> -Deprecated properties:
> - - ctrl-module : phandle of the control module used by PHY driver to power on
> - the PHY.
> -
> -Recommended properies:
> -- syscon-phy-power : phandle/offset pair. Phandle to the system control
> - module and the register offset to power on/off the PHY.
> -
> -This is usually a subnode of ocp2scp to which it is connected.
> -
> -usb2phy@4a0ad080 {
> - compatible = "ti,omap-usb2";
> - reg = <0x4a0ad080 0x58>;
> - ctrl-module = <&omap_control_usb>;
> - #phy-cells = <0>;
> - clocks = <&usb_phy_cm_clk32k>, <&usb_otg_ss_refclk960m>;
> - clock-names = "wkupclk", "refclk";
> -};
> -
> TI PIPE3 PHY
>
> Required properties:
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>
^ permalink raw reply
* [PATCH 2/4] dt-bindings: pinctrl: Document optional BCM7211 wake-up interrupts
From: Florian Fainelli @ 2020-05-28 19:21 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Linus Walleij, Rob Herring, Ray Jui,
Scott Branden,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
Nicolas Saenz Julienne, Stefan Wahren, Geert Uytterhoeven,
Matti Vaittinen, open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200528192112.26123-1-f.fainelli@gmail.com>
BCM7211 supports wake-up interrupts in the form of optional interrupt
lines, one per bank, plus the "all banks" interrupt line.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
.../devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
index dfc67b90591c..5682b2010e50 100644
--- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
@@ -16,7 +16,9 @@ Required properties:
second cell is used to specify optional parameters:
- bit 0 specifies polarity (0 for normal, 1 for inverted)
- interrupts : The interrupt outputs from the controller. One interrupt per
- individual bank followed by the "all banks" interrupt.
+ individual bank followed by the "all banks" interrupt. For BCM7211, an
+ additional set of per-bank interrupt line and an "all banks" wake-up
+ interrupt may be specified.
- interrupt-controller: Marks the device node as an interrupt controller.
- #interrupt-cells : Should be 2.
The first cell is the GPIO number.
--
2.17.1
^ permalink raw reply related
* [PATCH 0/4] pinctrl: bcm2835: Support for wake-up interrupts
From: Florian Fainelli @ 2020-05-28 19:21 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Linus Walleij, Rob Herring, Ray Jui,
Scott Branden,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
Nicolas Saenz Julienne, Stefan Wahren, Geert Uytterhoeven,
Matti Vaittinen, open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
Hi Linus,
This patch series updates the bcm2835 pinctrl driver to support
the BCM7211 SoC which is quite similar to 2711 (Raspberry Pi 4)
except that it also supports wake-up interrupts.
Thanks!
Florian Fainelli (4):
dt-bindings: pinctrl: Document 7211 compatible for
brcm,bcm2835-gpio.txt
dt-bindings: pinctrl: Document optional BCM7211 wake-up interrupts
pinctrl: bcm2835: Match BCM7211 compatible string
pinctrl: bcm2835: Add support for wake-up interrupts
.../bindings/pinctrl/brcm,bcm2835-gpio.txt | 5 +-
drivers/pinctrl/bcm/pinctrl-bcm2835.c | 62 ++++++++++++++++++-
2 files changed, 65 insertions(+), 2 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH 4/4] pinctrl: bcm2835: Add support for wake-up interrupts
From: Florian Fainelli @ 2020-05-28 19:21 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Linus Walleij, Rob Herring, Ray Jui,
Scott Branden,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
Nicolas Saenz Julienne, Stefan Wahren, Geert Uytterhoeven,
Matti Vaittinen, open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200528192112.26123-1-f.fainelli@gmail.com>
Leverage the IRQCHIP_MASK_ON_SUSPEND flag in order to avoid having to
specifically treat the GPIO interrupts during suspend and resume, and
simply implement an irq_set_wake() callback that is responsible for
enabling the parent wake-up interrupt as a wake-up interrupt.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/pinctrl/bcm/pinctrl-bcm2835.c | 58 ++++++++++++++++++++++++++-
1 file changed, 57 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index e8ad1824c6b3..367fd8e19f92 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -19,6 +19,7 @@
#include <linux/irq.h>
#include <linux/irqdesc.h>
#include <linux/init.h>
+#include <linux/interrupt.h>
#include <linux/of_address.h>
#include <linux/of.h>
#include <linux/of_irq.h>
@@ -76,6 +77,7 @@
struct bcm2835_pinctrl {
struct device *dev;
void __iomem *base;
+ int wake_irq[BCM2835_NUM_IRQS];
/* note: locking assumes each bank will have its own unsigned long */
unsigned long enabled_irq_map[BCM2835_NUM_BANKS];
@@ -435,6 +437,11 @@ static void bcm2835_gpio_irq_handler(struct irq_desc *desc)
chained_irq_exit(host_chip, desc);
}
+static irqreturn_t bcm2835_gpio_wake_irq_handler(int irq, void *dev_id)
+{
+ return IRQ_HANDLED;
+}
+
static inline void __bcm2835_gpio_irq_config(struct bcm2835_pinctrl *pc,
unsigned reg, unsigned offset, bool enable)
{
@@ -634,6 +641,31 @@ static void bcm2835_gpio_irq_ack(struct irq_data *data)
bcm2835_gpio_set_bit(pc, GPEDS0, gpio);
}
+static int bcm2835_gpio_irq_set_wake(struct irq_data *data, unsigned int on)
+{
+ struct gpio_chip *chip = irq_data_get_irq_chip_data(data);
+ struct bcm2835_pinctrl *pc = gpiochip_get_data(chip);
+ unsigned gpio = irqd_to_hwirq(data);
+ unsigned int irqgroup;
+ int ret = -EINVAL;
+
+ if (gpio <= 27)
+ irqgroup = 0;
+ else if (gpio >= 28 && gpio <= 45)
+ irqgroup = 1;
+ else if (gpio >= 46 && gpio <= 53)
+ irqgroup = 2;
+ else
+ return ret;
+
+ if (on)
+ ret = enable_irq_wake(pc->wake_irq[irqgroup]);
+ else
+ ret = disable_irq_wake(pc->wake_irq[irqgroup]);
+
+ return ret;
+}
+
static struct irq_chip bcm2835_gpio_irq_chip = {
.name = MODULE_NAME,
.irq_enable = bcm2835_gpio_irq_enable,
@@ -642,6 +674,8 @@ static struct irq_chip bcm2835_gpio_irq_chip = {
.irq_ack = bcm2835_gpio_irq_ack,
.irq_mask = bcm2835_gpio_irq_disable,
.irq_unmask = bcm2835_gpio_irq_enable,
+ .irq_set_wake = bcm2835_gpio_irq_set_wake,
+ .flags = IRQCHIP_MASK_ON_SUSPEND,
};
static int bcm2835_pctl_get_groups_count(struct pinctrl_dev *pctldev)
@@ -1221,8 +1255,30 @@ static int bcm2835_pinctrl_probe(struct platform_device *pdev)
* bank that was firing the IRQ and look up the per-group
* and bank data.
*/
- for (i = 0; i < BCM2835_NUM_IRQS; i++)
+ for (i = 0; i < BCM2835_NUM_IRQS; i++) {
+ int len;
+ char *name;
+
girq->parents[i] = irq_of_parse_and_map(np, i);
+ /* Skip over the all banks interrupts */
+ pc->wake_irq[i] = irq_of_parse_and_map(np, i +
+ BCM2835_NUM_IRQS + 1);
+
+ len = strlen(dev_name(pc->dev)) + 16;
+ name = devm_kzalloc(pc->dev, len, GFP_KERNEL);
+ if (!name)
+ return -ENOMEM;
+
+ snprintf(name, len, "%s:bank%d", dev_name(pc->dev), i);
+
+ /* These are optional interrupts */
+ err = devm_request_irq(dev, pc->wake_irq[i],
+ bcm2835_gpio_wake_irq_handler,
+ IRQF_SHARED, name, pc);
+ if (err)
+ dev_warn(dev, "unable to request wake IRQ %d\n",
+ pc->wake_irq[i]);
+ }
girq->default_type = IRQ_TYPE_NONE;
girq->handler = handle_level_irq;
--
2.17.1
^ permalink raw reply related
* [PATCH 1/4] dt-bindings: pinctrl: Document 7211 compatible for brcm,bcm2835-gpio.txt
From: Florian Fainelli @ 2020-05-28 19:21 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Linus Walleij, Rob Herring, Ray Jui,
Scott Branden,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
Nicolas Saenz Julienne, Stefan Wahren, Geert Uytterhoeven,
Matti Vaittinen, open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200528192112.26123-1-f.fainelli@gmail.com>
Document the brcm,bcm7211-gpio compatible string in the
brcm,bcm2835-gpio.txt document.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
index 3cab7336a326..dfc67b90591c 100644
--- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
@@ -9,6 +9,7 @@ Required properties:
"brcm,bcm2835-gpio" - BCM2835 compatible pinctrl
"brcm,bcm7211-gpio" - BCM7211 compatible pinctrl
"brcm,bcm2711-gpio" - BCM2711 compatible pinctrl
+ "brcm,bcm7211-gpio" - BCM7211 compatible pinctrl
- reg: Should contain the physical address of the GPIO module's registers.
- gpio-controller: Marks the device node as a GPIO controller.
- #gpio-cells : Should be two. The first cell is the pin number and the
--
2.17.1
^ permalink raw reply related
* [PATCH 3/4] pinctrl: bcm2835: Match BCM7211 compatible string
From: Florian Fainelli @ 2020-05-28 19:21 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Linus Walleij, Rob Herring, Ray Jui,
Scott Branden,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
Nicolas Saenz Julienne, Stefan Wahren, Geert Uytterhoeven,
Matti Vaittinen, open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200528192112.26123-1-f.fainelli@gmail.com>
The BCM7211 SoC uses the same pinconf_ops as the ones defined for the
BCM2711 SoC, match the compatible string and use the correct set of
options.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/pinctrl/bcm/pinctrl-bcm2835.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index 06bd2b70af3c..e8ad1824c6b3 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -1137,6 +1137,10 @@ static const struct of_device_id bcm2835_pinctrl_match[] = {
.compatible = "brcm,bcm2711-gpio",
.data = &bcm2711_plat_data,
},
+ {
+ .compatible = "brcm,bcm7211-gpio",
+ .data = &bcm2711_pinconf_ops,
+ },
{}
};
--
2.17.1
^ permalink raw reply related
* Re: [RFC] dt-bindings: mailbox: add doorbell support to ARM MHU
From: Rob Herring @ 2020-05-28 19:20 UTC (permalink / raw)
To: Viresh Kumar
Cc: Jassi Brar, Arnd Bergmann, Frank Rowand, Bjorn Andersson,
Vincent Guittot, linux-arm-kernel, Sudeep Holla, devicetree,
linux-kernel
In-Reply-To: <0a50f0cf5593baeb628dc8606c523665e5e2ae6c.1589519600.git.viresh.kumar@linaro.org>
On Fri, May 15, 2020 at 10:47:38AM +0530, Viresh Kumar wrote:
> From: Sudeep Holla <sudeep.holla@arm.com>
>
> Hi Rob, Arnd and Jassi,
>
> This stuff has been doing rounds on the mailing list since several years
> now with no agreed conclusion by all the parties. And here is another
> attempt to get some feedback from everyone involved to close this once
> and for ever. Your comments will very much be appreciated.
>
> The ARM MHU is defined here in the TRM [1] for your reference, which
> states following:
>
> "The MHU drives the signal using a 32-bit register, with all 32
> bits logically ORed together. The MHU provides a set of
> registers to enable software to set, clear, and check the status
> of each of the bits of this register independently. The use of
> 32 bits for each interrupt line enables software to provide more
> information about the source of the interrupt. For example, each
> bit of the register can be associated with a type of event that
> can contribute to raising the interrupt."
>
> On few other platforms, like qcom, similar doorbell mechanism is present
> with separate interrupt for each of the bits (that's how I understood
> it), while in case of ARM MHU, there is a single interrupt line for all
> the 32 bits. Also in case of ARM MHU, these registers and interrupts
> have 3 copies for different priority levels, i.e. low priority
> non-secure, high priority non-secure and secure channels.
>
> For ARM MHU, both the dt bindings and the Linux driver support 3
> channels for the different priorities right now and support sending a 32
> bit data on every transfer in a locked fashion, i.e. only one transfer
> can be done at once and the other have to wait for it to finish first.
>
> Here are the point of view of the parties involved on this subject:
>
> Jassi's viewpoint:
>
> - Virtualization of channels should be discouraged in software based on
> specific usecases of the application. This may invite other mailbox
> driver authors to ask for doing virtualization in their drivers.
>
> - In mailbox's terminology, every channel is equivalent to a signal,
> since there is only one signal generated here by the MHU, there should
> be only one channel per priority level.
>
> - The clients should send data (of just setting 1 bit or many in the 32
> bit word) using the existing mechanism as the delays due to
> serialization shouldn't be significant anyway.
>
> - The driver supports 90% of the users with the current implementation
> and it shouldn't be extended to support doorbell and implement two
> different modes by changing value of #mbox-cells field in bindings.
>
> Sudeep (ARM) and myself as well to some extent:
>
> - The hardware gives us the capability to write the register in
> parallel, i.e. we can write 0x800 and 0x400 together without any
> software locks, and so these 32 bits should be considered as separate
> channel even if only one interrupt is issued by the hardware finally.
> This shouldn't be called as virtualization of the channels, as the
> hardware supports this (as clearly mentioned in the TRM) and it takes
> care of handling the signal properly.
>
> - With serialization, if we use only one channel as today at every
> priority, if there are 5 requests to send signal to the receiver and
> the dvfs request is the last one in queue (which may be called from
> scheduler's hot path with fast switching), it unnecessarily needs to
> wait for the first four transfers to finish due to the software
> locking imposed by the mailbox framework. This adds additional delay,
> maybe of few ms only, which isn't required by the hardware but just by
> the software and few ms can be important in scheduler's hotpath.
>
> - With the current approach it isn't possible to assign different bits
> (or doorbell numbers) to clients from DT and the only way of doing
> that without adding new bindings is by extending #mbox-cells to accept
> a value of 2 as done in this patch.
>
> Jassi and Sudeep, I hope I was able to represent both the view points
> properly here. Please correct me if I have made a mistake here.
>
> This is it. It would be nice to get the views of everyone now on this
> and how should this be handled.
I am perfectly fine with adding another cell which seems appropriate
here. You can have 5 cells for all I care if that makes sense for
the h/w. That has nothing to do with the Linux design. Whether Linux
requires serializing mailbox accesses is a separate issue. On that side,
it seems silly to not allow driving the h/w in the most efficient way
possible.
Rob
^ permalink raw reply
* Re: [PATCH v6 15/18] mtd: nand: Introduce the ECC engine abstraction
From: Boris Brezillon @ 2020-05-28 18:52 UTC (permalink / raw)
To: Miquel Raynal
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree, Julien Su, Weijie Gao,
Paul Cercueil, Thomas Petazzoni, Mason Yang, Chuanhong Guo,
linux-arm-kernel
In-Reply-To: <20200528113113.9166-16-miquel.raynal@bootlin.com>
On Thu, 28 May 2020 13:31:10 +0200
Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> Create a generic ECC engine object.
>
> Later the ecc.c file will receive more generic code coming from
> the raw NAND specific part. This is a base to instantiate ECC engine
> objects.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> ---
> drivers/mtd/nand/Kconfig | 7 ++
> drivers/mtd/nand/Makefile | 2 +
> drivers/mtd/nand/ecc.c | 138 ++++++++++++++++++++++++++++++++++++++
> include/linux/mtd/nand.h | 67 ++++++++++++++++++
> 4 files changed, 214 insertions(+)
> create mode 100644 drivers/mtd/nand/ecc.c
>
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index c1a45b071165..a4478ffa279d 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -9,4 +9,11 @@ source "drivers/mtd/nand/onenand/Kconfig"
> source "drivers/mtd/nand/raw/Kconfig"
> source "drivers/mtd/nand/spi/Kconfig"
>
> +menu "ECC engine support"
> +
> +config MTD_NAND_ECC
> + bool
> +
> +endmenu
> +
> endmenu
> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
> index 7ecd80c0a66e..981372953b56 100644
> --- a/drivers/mtd/nand/Makefile
> +++ b/drivers/mtd/nand/Makefile
> @@ -6,3 +6,5 @@ obj-$(CONFIG_MTD_NAND_CORE) += nandcore.o
> obj-y += onenand/
> obj-y += raw/
> obj-y += spi/
> +
> +nandcore-$(CONFIG_MTD_NAND_ECC) += ecc.o
> diff --git a/drivers/mtd/nand/ecc.c b/drivers/mtd/nand/ecc.c
> new file mode 100644
> index 000000000000..e4f2b6fcbb12
> --- /dev/null
> +++ b/drivers/mtd/nand/ecc.c
> @@ -0,0 +1,138 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Generic Error-Correcting Code (ECC) engine
> + *
> + * Copyright (C) 2019 Macronix
> + * Author:
> + * Miquèl RAYNAL <miquel.raynal@bootlin.com>
> + *
> + *
> + * This file describes the abstraction of any NAND ECC engine. It has been
> + * designed to fit most cases, including parallel NANDs and SPI-NANDs.
> + *
> + * There are three main situations where instantiating this ECC engine makes
> + * sense:
> + * - "external": The ECC engine is outside the NAND pipeline, typically this
I'm not sure why you put quotes around those names.
> + * is a software ECC engine. One can also imagine a generic
^ or an hardware
engine that's outside the NAND controller pipeline.
You can the drop the "One can also imagine ..." since it's more than a
theoretical use case, we already have a few engines that fall in this
category.
> + * hardware ECC engine which would be an IP itself. Interacting
> + * with a SPI-NAND device without on-die ECC could be achieved
^can
> + * thanks to the use of such external engine.
But I think I would simply drop this last sentence.
> + * - "pipelined": The ECC engine is inside the NAND pipeline, ie. on the
> + * controller's side. This is the case of most of the raw NAND
> + * controllers. These controllers usually embed an hardware ECC
> + * engine which is managed thanks to the same register set as
> + * the controller's.
Again, I would drop the last sentence here. I think saying the ECC
bytes are generated/data corrected on the fly when a page is
written/read would be more useful.
> + * - "ondie": The ECC engine is inside the NAND pipeline, on the chip's side.
> + * Some NAND chips can correct themselves the data. The on-die
> + * correction can be enabled, disabled and the status of the
> + * correction after a read may be retrieved with a NAND command
> + * (may be vendor specific).
"The on-die correction can be enabled, disabled" -> this is true for
any kind of ECC engine :P.
> + *
> + * Besides the initial setup and final cleanups, the interfaces are rather
> + * simple:
> + * - "prepare": Prepare an I/O request, check the ECC engine is enabled or
^if/whether
> + * disabled as requested before the I/O. In case of software
How about "Enable/disable the ECC engine based on the I/O request type."
> + * correction, this step may involve to derive the ECC bytes and
> + * place them in the OOB area before a write.
This is also true for external hardware ECC engines.
> + * - "finish": Finish an I/O request, check the status of the operation ie.
> + * the data validity in case of a read (report to the upper layer
> + * any bitflip/errors).
It's all about correcting/reporting errors, right. Let's try to put
that into simple words: "Correct the data in case of a read request and
report the number of corrected bits/uncorrectable errors. Most likely
empty for write operations, unless you have hardware specific stuff to
do, like shutting down the engine to save some power"
> + *
> + * Both prepare/finish callbacks are supposed to enclose I/O request and will
"The I/O request should be enclosed in a prepare()/finish() pair of
calls" or "The prepare/finish call should surround the I/O request".
> + * behave differently depending on the desired correction:
^requested I/O type
> + * - "raw": Correction disabled
> + * - "ecc": Correction enabled
> + *
> + * The request direction is impacting the logic as well:
> + * - "read": Load data from the NAND chip
> + * - "write": Store data in the NAND chip
> + *
> + * Mixing all this combinations together gives the following behavior.
Mention that those are just examples, and drivers are free to add
custom steps in their prepare/finish hooks.
> + *
> + * ["external" ECC engine]
> + * - external + prepare + raw + read: do nothing
> + * - external + finish + raw + read: do nothing
> + * - external + prepare + raw + write: do nothing
> + * - external + finish + raw + write: do nothing
> + * - external + prepare + ecc + read: do nothing
> + * - external + finish + ecc + read: calculate expected ECC bytes, extract
> + * ECC bytes from OOB buffer, correct
> + * and report any bitflip/error
> + * - external + prepare + ecc + write: calculate ECC bytes and store them at
> + * the right place in the OOB buffer based
> + * on the OOB layout
> + * - external + finish + ecc + write: do nothing
> + *
> + * ["pipelined" ECC engine]
> + * - pipelined + prepare + raw + read: disable the controller's ECC engine if
> + * activated
> + * - pipelined + finish + raw + read: do nothing
> + * - pipelined + prepare + raw + write: disable the controller's ECC engine if
> + * activated
> + * - pipelined + finish + raw + write: do nothing
> + * - pipelined + prepare + ecc + read: enable the controller's ECC engine if
> + * deactivated
> + * - pipelined + finish + ecc + read: check the status, report any
> + * error/bitflip
> + * - pipelined + prepare + ecc + write: enable the controller's ECC engine if
> + * deactivated
> + * - pipelined + finish + ecc + write: do nothing
> + *
> + * ["ondie" ECC engine]
> + * - ondie + prepare + raw + read: send commands to disable the on-chip ECC
> + * engine if activated
> + * - ondie + finish + raw + read: do nothing
> + * - ondie + prepare + raw + write: send commands to disable the on-chip ECC
> + * engine if activated
> + * - ondie + finish + raw + write: do nothing
> + * - ondie + prepare + ecc + read: send commands to enable the on-chip ECC
> + * engine if deactivated
> + * - ondie + finish + ecc + read: send commands to check the status, report
> + * any error/bitflip
> + * - ondie + prepare + ecc + write: send commands to enable the on-chip ECC
> + * engine if deactivated
> + * - ondie + finish + ecc + write: do nothing
> + */
> +
> +#include <linux/module.h>
> +#include <linux/mtd/nand.h>
> +
Shouldn't we have kernel-docs for those functions?
> +int nand_ecc_init_ctx(struct nand_device *nand)
> +{
> + if (!nand->ecc.engine->ops->init_ctx)
> + return 0;
> +
> + return nand->ecc.engine->ops->init_ctx(nand);
> +}
> +EXPORT_SYMBOL(nand_ecc_init_ctx);
> +
> +void nand_ecc_cleanup_ctx(struct nand_device *nand)
> +{
> + if (nand->ecc.engine->ops->cleanup_ctx)
> + nand->ecc.engine->ops->cleanup_ctx(nand);
> +}
> +EXPORT_SYMBOL(nand_ecc_cleanup_ctx);
> +
> +int nand_ecc_prepare_io_req(struct nand_device *nand,
> + struct nand_page_io_req *req)
> +{
> + if (!nand->ecc.engine->ops->prepare_io_req)
> + return 0;
> +
> + return nand->ecc.engine->ops->prepare_io_req(nand, req);
> +}
> +EXPORT_SYMBOL(nand_ecc_prepare_io_req);
> +
> +int nand_ecc_finish_io_req(struct nand_device *nand,
> + struct nand_page_io_req *req)
> +{
> + if (!nand->ecc.engine->ops->finish_io_req)
> + return 0;
> +
> + return nand->ecc.engine->ops->finish_io_req(nand, req);
> +}
> +EXPORT_SYMBOL(nand_ecc_finish_io_req);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Miquel Raynal <miquel.raynal@bootlin.com>");
> +MODULE_DESCRIPTION("Generic ECC engine");
> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> index 2e9af24936cd..0be260fd2f86 100644
> --- a/include/linux/mtd/nand.h
> +++ b/include/linux/mtd/nand.h
> @@ -221,6 +221,73 @@ struct nand_ops {
> bool (*isbad)(struct nand_device *nand, const struct nand_pos *pos);
> };
>
> +/**
> + * struct nand_ecc_context - Context for the ECC engine
> + * @conf: basic ECC engine parameters
> + * @total: Total number of bytes used for storing ECC codes, this is used by
Sometimes you start your description with an uppercase, sometimes not.
> + * generic OOB layouts
> + * @priv: ECC engine driver private data
> + */
> +struct nand_ecc_context {
> + struct nand_ecc_props conf;
> + unsigned int total;
> + void *priv;
> +};
> +
> +/**
> + * struct nand_ecc_engine_ops - Generic ECC engine operations
^s/Generic//
> + * @init_ctx: given a desired user configuration for the pointed NAND device,
> + * requests the ECC engine driver to setup a configuration with
> + * values it supports.
> + * @cleanup_ctx: clean the context initialized by @init_ctx.
> + * @prepare_io_req: is called before reading/writing a page to prepare the I/O
> + * request to be performed with ECC correction.
> + * @finish_io_req: is called after reading/writing a page to terminate the I/O
> + * request and ensure proper ECC correction.
> + */
> +struct nand_ecc_engine_ops {
> + int (*init_ctx)(struct nand_device *nand);
> + void (*cleanup_ctx)(struct nand_device *nand);
> + int (*prepare_io_req)(struct nand_device *nand,
> + struct nand_page_io_req *req);
> + int (*finish_io_req)(struct nand_device *nand,
> + struct nand_page_io_req *req);
> +};
> +
> +/**
> + * struct nand_ecc_engine - Generic ECC engine abstraction for NAND devices
^s/Generic//
> + * @ops: ECC engine operations
> + */
> +struct nand_ecc_engine {
> + struct nand_ecc_engine_ops *ops;
> +};
> +
> +int nand_ecc_init_ctx(struct nand_device *nand);
> +void nand_ecc_cleanup_ctx(struct nand_device *nand);
> +int nand_ecc_prepare_io_req(struct nand_device *nand,
> + struct nand_page_io_req *req);
> +int nand_ecc_finish_io_req(struct nand_device *nand,
> + struct nand_page_io_req *req);
> +
> +/**
> + * struct nand_ecc - High-level ECC object
I think you can drop the "High-level" and just say "Information
relative to the ECC"
> + * @defaults: Default values, depend on the underlying subsystem
> + * @requirements: ECC requirements from the NAND chip perspective
> + * @user_conf: User desires in terms of ECC parameters
> + * @ctx: ECC context for the ECC engine, derived from the device @requirements
> + * the @user_conf and the @defaults
> + * @ondie_engine: On-die ECC engine reference, if any
> + * @engine: ECC engine actually bound
> + */
> +struct nand_ecc {
> + struct nand_ecc_props defaults;
> + struct nand_ecc_props requirements;
> + struct nand_ecc_props user_conf;
> + struct nand_ecc_context ctx;
> + struct nand_ecc_engine *ondie_engine;
> + struct nand_ecc_engine *engine;
> +};
> +
> /**
> * struct nand_device - NAND device
> * @mtd: MTD instance attached to the NAND device
^ permalink raw reply
* Re: [PATCH] dt-bindings: display: renesas,du: Convert binding to YAML
From: Rob Herring @ 2020-05-28 18:52 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: dri-devel, devicetree, linux-renesas-soc, Kieran Bingham
In-Reply-To: <20200515003340.18191-1-laurent.pinchart+renesas@ideasonboard.com>
On Fri, May 15, 2020 at 03:33:40AM +0300, Laurent Pinchart wrote:
> Convert the Renesas R-Car DU text binding to YAML.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> .../bindings/display/renesas,du.txt | 139 ---
> .../bindings/display/renesas,du.yaml | 915 ++++++++++++++++++
A 'normal' conversion is about double the lines. I guess this is a sign
that the original was not well specified.
Maybe this can be split to reduce some of the if/then? One way is define
a common 'include' file that each specific instance can reference
[...]
> diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml b/Documentation/devicetree/bindings/display/renesas,du.yaml
> new file mode 100644
> index 000000000000..ca48065afe1f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml
> @@ -0,0 +1,915 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/renesas,du.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas R-Car Display Unit (DU)
> +
> +maintainers:
> + - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> +
> +description: |
> + These DT bindings describe the Display Unit embedded in the Renesas R-Car
> + Gen1, R-Car Gen2, R-Car Gen3, RZ/G1 and RZ/G2 SoCs.
> +
> +properties:
> + compatible:
> + enum:
> + - renesas,du-r8a7743 # for RZ/G1M compatible DU
> + - renesas,du-r8a7744 # for RZ/G1N compatible DU
> + - renesas,du-r8a7745 # for RZ/G1E compatible DU
> + - renesas,du-r8a77470 # for RZ/G1C compatible DU
> + - renesas,du-r8a774a1 # for RZ/G2M compatible DU
> + - renesas,du-r8a774b1 # for RZ/G2N compatible DU
> + - renesas,du-r8a774c0 # for RZ/G2E compatible DU
> + - renesas,du-r8a7779 # for R-Car H1 compatible DU
> + - renesas,du-r8a7790 # for R-Car H2 compatible DU
> + - renesas,du-r8a7791 # for R-Car M2-W compatible DU
> + - renesas,du-r8a7792 # for R-Car V2H compatible DU
> + - renesas,du-r8a7793 # for R-Car M2-N compatible DU
> + - renesas,du-r8a7794 # for R-Car E2 compatible DU
> + - renesas,du-r8a7795 # for R-Car H3 compatible DU
> + - renesas,du-r8a7796 # for R-Car M3-W compatible DU
> + - renesas,du-r8a77965 # for R-Car M3-N compatible DU
> + - renesas,du-r8a77970 # for R-Car V3M compatible DU
> + - renesas,du-r8a77980 # for R-Car V3H compatible DU
> + - renesas,du-r8a77990 # for R-Car E3 compatible DU
> + - renesas,du-r8a77995 # for R-Car D3 compatible DU
> +
> + reg:
> + maxItems: 1
> +
> + # See compatible-specific constraints below.
> + clocks: true
> + clock-names: true
> + interrupts: true
> + resets: true
> + reset-names: true
> +
> + ports:
> + type: object
> + description: |
> + The connections to the DU output video ports are modeled using the OF
> + graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> + The number of ports and their assignment are model-dependent. Each port
> + shall have a single endpoint.
> +
> + properties:
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
> +
> + patternProperties:
> + "^port@[0-3]$":
> + type: object
> +
> + properties:
> + reg:
> + maxItems: 1
> +
> + endpoint:
> + type: object
> +
> + properties:
> + remote-endpoint:
> + $ref: /schemas/types.yaml#/definitions/phandle
> +
> + required:
> + - remote-endpoint
> +
> + additionalProperties: false
> +
> + additionalProperties: false
You can drop this and assume there's a generic check for this. Though I
guess this does ensure only 'remote-endpoint' is present which a generic
schema couldn't do.
> +
> + required:
> + - port@0
> + - port@1
> +
> + additionalProperties: false
> +
> + renesas,cmms:
> + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> + description:
> + A list of phandles to the CMM instances present in the SoC, one for each
> + available DU channel.
> +
> + renesas,vsps:
> + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> + description:
> + A list of phandle and channel index tuples to the VSPs that handle the
> + memory interfaces for the DU channels. The phandle identifies the VSP
> + instance that serves the DU channel, and the channel index identifies
> + the LIF instance in that VSP.
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - interrupts
> + - resets
> + - ports
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: renesas,du-r8a7779
> + then:
> + properties:
> + clocks:
> + minItems: 1
> + maxItems: 3
> + items:
> + - description: Functional clock
> + - description: DU_DOTCLKIN0 input clock
> + - description: DU_DOTCLKIN1 input clock
> +
> + clock-names:
> + minItems: 1
> + maxItems: 3
> + items:
> + - const: du.0
> + - enum:
> + - dclkin.0
> + - dclkin.1
Here and elsewhere:
- pattern: "^dclkin\.[01]$"
> + - enum:
> + - dclkin.0
> + - dclkin.1
> +
> + interrupts:
> + maxItems: 1
> +
> + resets:
> + maxItems: 1
> +
> + ports:
> + properties:
> + port@0:
> + description: DPAD 0
> + port@1:
> + description: DPAD 1
> + # port@2 is TCON, not supported yet
Does that matter?
> + port@2: false
> + port@3: false
> +
> + required:
> + - port@0
> + - port@1
> +
> + required:
> + - interrupts
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - renesas,du-r8a7743
> + - renesas,du-r8a7744
> + - renesas,du-r8a7791
> + - renesas,du-r8a7793
> + then:
> + properties:
> + clocks:
> + minItems: 2
> + maxItems: 4
> + items:
> + - description: Functional clock for DU0
> + - description: Functional clock for DU1
> + - description: DU_DOTCLKIN0 input clock
> + - description: DU_DOTCLKIN1 input clock
> +
> + clock-names:
> + minItems: 2
> + maxItems: 4
> + items:
> + - const: du.0
> + - const: du.1
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - enum:
> + - dclkin.0
> + - dclkin.1
> +
> + interrupts:
> + maxItems: 2
> +
> + resets:
> + maxItems: 1
> +
> + reset-names:
> + items:
> + - const: du.0
> +
> + ports:
> + properties:
> + port@0:
> + description: DPAD 0
> + port@1:
> + description: LVDS 0
> + # port@2 is TCON, not supported yet
> + port@2: false
> + port@3: false
> +
> + required:
> + - port@0
> + - port@1
> +
> + required:
> + - clock-names
> + - interrupts
> + - resets
> + - reset-names
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - renesas,du-r8a7745
> + - renesas,du-r8a7792
> + then:
> + properties:
> + clocks:
> + minItems: 2
> + maxItems: 4
> + items:
> + - description: Functional clock for DU0
> + - description: Functional clock for DU1
> + - description: DU_DOTCLKIN0 input clock
> + - description: DU_DOTCLKIN1 input clock
> +
> + clock-names:
> + minItems: 2
> + maxItems: 4
> + items:
> + - const: du.0
> + - const: du.1
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - enum:
> + - dclkin.0
> + - dclkin.1
> +
> + interrupts:
> + maxItems: 2
> +
> + resets:
> + maxItems: 1
> +
> + reset-names:
> + items:
> + - const: du.0
> +
> + ports:
> + properties:
> + port@0:
> + description: DPAD 0
> + port@1:
> + description: DPAD 1
> + port@2: false
> + port@3: false
> +
> + required:
> + - port@0
> + - port@1
> +
> + required:
> + - clock-names
> + - interrupts
> + - resets
> + - reset-names
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - renesas,du-r8a7794
> + then:
> + properties:
> + clocks:
> + minItems: 2
> + maxItems: 4
> + items:
> + - description: Functional clock for DU0
> + - description: Functional clock for DU1
> + - description: DU_DOTCLKIN0 input clock
> + - description: DU_DOTCLKIN1 input clock
> +
> + clock-names:
> + minItems: 2
> + maxItems: 4
> + items:
> + - const: du.0
> + - const: du.1
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - enum:
> + - dclkin.0
> + - dclkin.1
> +
> + interrupts:
> + maxItems: 2
> +
> + resets:
> + maxItems: 1
> +
> + reset-names:
> + items:
> + - const: du.0
> +
> + ports:
> + properties:
> + port@0:
> + description: DPAD 0
> + port@1:
> + description: DPAD 1
> + # port@2 is TCON, not supported yet
> + port@2: false
> + port@3: false
> +
> + required:
> + - port@0
> + - port@1
> +
> + required:
> + - clock-names
> + - interrupts
> + - resets
> + - reset-names
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - renesas,du-r8a77470
> + then:
> + properties:
> + clocks:
> + minItems: 2
> + maxItems: 4
> + items:
> + - description: Functional clock for DU0
> + - description: Functional clock for DU1
> + - description: DU_DOTCLKIN0 input clock
> + - description: DU_DOTCLKIN1 input clock
> +
> + clock-names:
> + minItems: 2
> + maxItems: 4
> + items:
> + - const: du.0
> + - const: du.1
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - enum:
> + - dclkin.0
> + - dclkin.1
> +
> + interrupts:
> + maxItems: 2
> +
> + resets:
> + maxItems: 1
> +
> + reset-names:
> + items:
> + - const: du.0
> +
> + ports:
> + properties:
> + port@0:
> + description: DPAD 0
> + port@1:
> + description: DPAD 1
> + port@2:
> + description: LVDS 0
> + # port@3 is DVENC, not supported yet
> + port@3: false
> +
> + required:
> + - port@0
> + - port@1
> + - port@2
> +
> + required:
> + - clock-names
> + - interrupts
> + - resets
> + - reset-names
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - renesas,du-r8a7790
> + then:
> + properties:
> + clocks:
> + minItems: 3
> + maxItems: 6
> + items:
> + - description: Functional clock for DU0
> + - description: Functional clock for DU1
> + - description: Functional clock for DU2
> + - description: DU_DOTCLKIN0 input clock
> + - description: DU_DOTCLKIN1 input clock
> + - description: DU_DOTCLKIN2 input clock
> +
> + clock-names:
> + minItems: 3
> + maxItems: 6
> + items:
> + - const: du.0
> + - const: du.1
> + - const: du.2
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - dclkin.2
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - dclkin.2
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - dclkin.2
> +
> + interrupts:
> + maxItems: 3
> +
> + resets:
> + maxItems: 1
> +
> + reset-names:
> + items:
> + - const: du.0
> +
> + ports:
> + properties:
> + port@0:
> + description: DPAD 0
> + port@1:
> + description: LVDS 0
> + port@2:
> + description: LVDS 1
> + # port@3 is TCON, not supported yet
> + port@3: false
> +
> + required:
> + - port@0
> + - port@1
> + - port@2
> +
> + required:
> + - clock-names
> + - interrupts
> + - resets
> + - reset-names
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - renesas,du-r8a7795
> + then:
> + properties:
> + clocks:
> + minItems: 4
> + maxItems: 8
> + items:
> + - description: Functional clock for DU0
> + - description: Functional clock for DU1
> + - description: Functional clock for DU2
> + - description: Functional clock for DU4
> + - description: DU_DOTCLKIN0 input clock
> + - description: DU_DOTCLKIN1 input clock
> + - description: DU_DOTCLKIN2 input clock
> + - description: DU_DOTCLKIN3 input clock
> +
> + clock-names:
> + minItems: 4
> + maxItems: 8
> + items:
> + - const: du.0
> + - const: du.1
> + - const: du.2
> + - const: du.3
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - dclkin.2
> + - dclkin.3
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - dclkin.2
> + - dclkin.3
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - dclkin.2
> + - dclkin.3
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - dclkin.2
> + - dclkin.3
> +
> + interrupts:
> + maxItems: 4
> +
> + resets:
> + maxItems: 2
> +
> + reset-names:
> + items:
> + - const: du.0
> + - const: du.2
> +
> + ports:
> + properties:
> + port@0:
> + description: DPAD 0
> + port@1:
> + description: HDMI 0
> + port@2:
> + description: HDMI 1
> + port@3:
> + description: LVDS 0
> +
> + required:
> + - port@0
> + - port@1
> + - port@2
> + - port@3
> +
> + renesas,cmms:
> + minItems: 4
> +
> + renesas,vsps:
> + minItems: 4
> +
> + required:
> + - clock-names
> + - interrupts
> + - resets
> + - reset-names
> + - renesas,vsps
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - renesas,du-r8a774a1
> + - renesas,du-r8a7796
> + then:
> + properties:
> + clocks:
> + minItems: 3
> + maxItems: 6
> + items:
> + - description: Functional clock for DU0
> + - description: Functional clock for DU1
> + - description: Functional clock for DU2
> + - description: DU_DOTCLKIN0 input clock
> + - description: DU_DOTCLKIN1 input clock
> + - description: DU_DOTCLKIN2 input clock
> +
> + clock-names:
> + minItems: 3
> + maxItems: 6
> + items:
> + - const: du.0
> + - const: du.1
> + - const: du.2
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - dclkin.2
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - dclkin.2
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - dclkin.2
> +
> + interrupts:
> + maxItems: 3
> +
> + resets:
> + maxItems: 2
> +
> + reset-names:
> + items:
> + - const: du.0
> + - const: du.2
> +
> + ports:
> + properties:
> + port@0:
> + description: DPAD 0
> + port@1:
> + description: HDMI 0
> + port@2:
> + description: LVDS 0
> + port@3: false
> +
> + required:
> + - port@0
> + - port@1
> + - port@2
> +
> + renesas,cmms:
> + minItems: 3
> +
> + renesas,vsps:
> + minItems: 3
> +
> + required:
> + - clock-names
> + - interrupts
> + - resets
> + - reset-names
> + - renesas,vsps
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - renesas,du-r8a774b1
> + - renesas,du-r8a77965
> + then:
> + properties:
> + clocks:
> + minItems: 3
> + maxItems: 6
> + items:
> + - description: Functional clock for DU0
> + - description: Functional clock for DU1
> + - description: Functional clock for DU3
> + - description: DU_DOTCLKIN0 input clock
> + - description: DU_DOTCLKIN1 input clock
> + - description: DU_DOTCLKIN3 input clock
> +
> + clock-names:
> + minItems: 3
> + maxItems: 6
> + items:
> + - const: du.0
> + - const: du.1
> + - const: du.3
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - dclkin.3
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - dclkin.3
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - dclkin.3
> +
> + interrupts:
> + maxItems: 3
> +
> + resets:
> + maxItems: 2
> +
> + reset-names:
> + items:
> + - const: du.0
> + - const: du.3
> +
> + ports:
> + properties:
> + port@0:
> + description: DPAD 0
> + port@1:
> + description: HDMI 0
> + port@2:
> + description: LVDS 0
> + port@3: false
> +
> + required:
> + - port@0
> + - port@1
> + - port@2
> +
> + renesas,cmms:
> + minItems: 3
> +
> + renesas,vsps:
> + minItems: 3
> +
> + required:
> + - clock-names
> + - interrupts
> + - resets
> + - reset-names
> + - renesas,vsps
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - renesas,du-r8a77970
> + - renesas,du-r8a77980
> + then:
> + properties:
> + clocks:
> + minItems: 1
> + maxItems: 2
> + items:
> + - description: Functional clock for DU0
> + - description: DU_DOTCLKIN0 input clock
> +
> + clock-names:
> + minItems: 1
> + maxItems: 2
> + items:
> + - const: du.0
> + - const: dclkin.0
> +
> + interrupts:
> + maxItems: 1
> +
> + resets:
> + maxItems: 1
> +
> + reset-names:
> + items:
> + - const: du.0
> +
> + ports:
> + properties:
> + port@0:
> + description: DPAD 0
> + port@1:
> + description: LVDS 0
> + port@2: false
> + port@3: false
> +
> + required:
> + - port@0
> + - port@1
> +
> + renesas,vsps:
> + minItems: 1
> +
> + required:
> + - clock-names
> + - interrupts
> + - resets
> + - reset-names
> + - renesas,vsps
> +
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - renesas,du-r8a774c0
> + - renesas,du-r8a77990
> + - renesas,du-r8a77995
> + then:
> + properties:
> + clocks:
> + minItems: 2
> + maxItems: 4
> + items:
> + - description: Functional clock for DU0
> + - description: Functional clock for DU1
> + - description: DU_DOTCLKIN0 input clock
> + - description: DU_DOTCLKIN1 input clock
> +
> + clock-names:
> + minItems: 2
> + maxItems: 4
> + items:
> + - const: du.0
> + - const: du.1
> + - enum:
> + - dclkin.0
> + - dclkin.1
> + - enum:
> + - dclkin.0
> + - dclkin.1
> +
> + interrupts:
> + maxItems: 2
> +
> + resets:
> + maxItems: 1
> +
> + reset-names:
> + items:
> + - const: du.0
> +
> + ports:
> + properties:
> + port@0:
> + description: DPAD 0
> + port@1:
> + description: LVDS 0
> + port@2:
> + description: LVDS 1
> + # port@3 is TCON, not supported yet
> + port@3: false
> +
> + required:
> + - port@0
> + - port@1
> + - port@2
> +
> + renesas,cmms:
> + minItems: 2
> +
> + renesas,vsps:
> + minItems: 2
> +
> + required:
> + - clock-names
> + - interrupts
> + - resets
> + - reset-names
> + - renesas,vsps
> +
> +additionalProperties: false
> +
> +examples:
> + # R-Car H3 ES2.0 DU
> + - |
> + #include <dt-bindings/clock/renesas-cpg-mssr.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + display@feb00000 {
> + compatible = "renesas,du-r8a7795";
> + reg = <0xfeb00000 0x80000>;
> + interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 269 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 270 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_MOD 724>,
> + <&cpg CPG_MOD 723>,
> + <&cpg CPG_MOD 722>,
> + <&cpg CPG_MOD 721>;
> + clock-names = "du.0", "du.1", "du.2", "du.3";
> + resets = <&cpg 724>, <&cpg 722>;
> + reset-names = "du.0", "du.2";
> +
> + renesas,cmms = <&cmm0>, <&cmm1>, <&cmm2>, <&cmm3>;
> + renesas,vsps = <&vspd0 0>, <&vspd1 0>, <&vspd2 0>, <&vspd0 1>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + endpoint {
> + remote-endpoint = <&adv7123_in>;
> + };
> + };
> + port@1 {
> + reg = <1>;
> + endpoint {
> + remote-endpoint = <&dw_hdmi0_in>;
> + };
> + };
> + port@2 {
> + reg = <2>;
> + endpoint {
> + remote-endpoint = <&dw_hdmi1_in>;
> + };
> + };
> + port@3 {
> + reg = <3>;
> + endpoint {
> + remote-endpoint = <&lvds0_in>;
> + };
> + };
> + };
> + };
> +
> +...
> --
> Regards,
>
> Laurent Pinchart
>
^ permalink raw reply
* Re: [PATCH 10/10] dt-bindings: power: supply: Cleanup charger-manager bindings
From: Rob Herring @ 2020-05-28 17:54 UTC (permalink / raw)
To: Jonathan Bakker
Cc: sre, krzk, jonghwa3.lee, tglx, kstewart, baolin.wang7, linux-pm,
devicetree, linux-kernel
In-Reply-To: <BN6PR04MB0660E57423994D19C84370A3A3BC0@BN6PR04MB0660.namprd04.prod.outlook.com>
On Thu, May 14, 2020 at 04:04:35PM -0700, Jonathan Bakker wrote:
> The bindings for charger-manager were very unclear and didn't
> specify allowable values in many cases. Clean these up to show
> what each value does and make sure all properties are documented
> here rather than using wildcards.
>
> Signed-off-by: Jonathan Bakker <xc-racer2@live.ca>
> ---
> .../bindings/power/supply/charger-manager.txt | 30 ++++++++++++-------
> 1 file changed, 20 insertions(+), 10 deletions(-)
I guess you're just documenting what already exists, but I think this is
not really a binding we want to continue using...
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v1.2 4/4] dt-bindings: display: bridge: renesas, lvds: Convert binding to YAML
From: Rob Herring @ 2020-05-28 17:50 UTC (permalink / raw)
To: Laurent Pinchart
Cc: devicetree, linux-renesas-soc, dri-devel, Geert Uytterhoeven,
Rob Herring
In-Reply-To: <20200514214211.9036-1-laurent.pinchart+renesas@ideasonboard.com>
On Fri, 15 May 2020 00:42:11 +0300, Laurent Pinchart wrote:
> Convert the Renesas R-Car LVDS encoder text binding to YAML.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Acked-by: Maxime Ripard <mripard@kernel.org>
> ---
> Changes since v1:
>
> - Mention RZ/G1 and R2/G2 explicitly
> - Drop the part numbers in comments, only keep the SoC names
> - Use one address and size cell in the examples
> ---
> .../bindings/display/bridge/renesas,lvds.txt | 85 ------
> .../bindings/display/bridge/renesas,lvds.yaml | 248 ++++++++++++++++++
> 2 files changed, 248 insertions(+), 85 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt
> create mode 100644 Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next 1/2] dt-bindings: net: dp83822: Add TI dp83822 phy
From: Rob Herring @ 2020-05-28 17:48 UTC (permalink / raw)
To: Dan Murphy
Cc: andrew, f.fainelli, hkallweit1, davem, netdev, linux-kernel,
devicetree
In-Reply-To: <20200514173055.15013-2-dmurphy@ti.com>
On Thu, May 14, 2020 at 12:30:54PM -0500, Dan Murphy wrote:
> Add a dt binding for the TI dp83822 ethernet phy device.
>
> CC: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
> .../devicetree/bindings/net/ti,dp83822.yaml | 49 +++++++++++++++++++
> 1 file changed, 49 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/ti,dp83822.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/ti,dp83822.yaml b/Documentation/devicetree/bindings/net/ti,dp83822.yaml
> new file mode 100644
> index 000000000000..60afd43ad3b6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/ti,dp83822.yaml
> @@ -0,0 +1,49 @@
> +# SPDX-License-Identifier: (GPL-2.0+ OR BSD-2-Clause)
> +# Copyright (C) 2020 Texas Instruments Incorporated
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/net/ti,dp83822.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +title: TI DP83822 ethernet PHY
> +
> +allOf:
> + - $ref: "ethernet-controller.yaml#"
Not an ethernet controller. Drop. (The ethernet-phy.yaml schema will be
applied based on node name).
> +
> +maintainers:
> + - Dan Murphy <dmurphy@ti.com>
> +
> +description: |
> + The DP83822 is a low-power, single-port, 10/100 Mbps Ethernet PHY. It
> + provides all of the physical layer functions needed to transmit and receive
> + data over standard, twisted-pair cables or to connect to an external,
> + fiber-optic transceiver. Additionally, the DP83822 provides flexibility to
> + connect to a MAC through a standard MII, RMII, or RGMII interface
> +
> + Specifications about the charger can be found at:
> + http://www.ti.com/lit/ds/symlink/dp83822i.pdf
> +
> +properties:
> + reg:
> + maxItems: 1
> +
> + ti,signal-polarity-low:
What signal?
> + type: boolean
> + description: |
> + DP83822 PHY in Fiber mode only.
> + Sets the DP83822 to detect a link drop condition when the signal goes
> + high. If not set then link drop will occur when the signal goes low.
The naming is not clear that low is for link drop. So maybe:
ti,link-loss-low
Rob
^ permalink raw reply
* [PATCH 1/1] arm64: dts: rockchip: add fuel gauge to Pinebook Pro dts
From: Tobias Schramm @ 2020-05-28 17:25 UTC (permalink / raw)
To: Rob Herring, Heiko Stuebner
Cc: devicetree, linux-rockchip, linux-kernel, Tobias Schramm
In-Reply-To: <20200528172550.2324722-1-t.schramm@manjaro.org>
This commit adds cw2015 fuel gauge and battery to the Pinebook Pro dts.
Signed-off-by: Tobias Schramm <t.schramm@manjaro.org>
---
.../boot/dts/rockchip/rk3399-pinebook-pro.dts | 25 +++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
index 5ea281b55fe2..28afe89ca283 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
@@ -28,6 +28,13 @@ backlight: edp-backlight {
pwms = <&pwm0 0 740740 0>;
};
+ bat: battery {
+ compatible = "simple-battery";
+ charge-full-design-microamp-hours = <9800000>;
+ voltage-max-design-microvolt = <4350000>;
+ voltage-min-design-microvolt = <3000000>;
+ };
+
edp_panel: edp-panel {
compatible = "boe,nv140fhmn49";
backlight = <&backlight>;
@@ -740,6 +747,24 @@ usbc_dp: endpoint {
};
};
};
+
+ cw2015@62 {
+ compatible = "cellwise,cw2015";
+ reg = <0x62>;
+ cellwise,battery-profile = /bits/ 8 <
+ 0x17 0x67 0x80 0x73 0x6E 0x6C 0x6B 0x63
+ 0x77 0x51 0x5C 0x58 0x50 0x4C 0x48 0x36
+ 0x15 0x0C 0x0C 0x19 0x5B 0x7D 0x6F 0x69
+ 0x69 0x5B 0x0C 0x29 0x20 0x40 0x52 0x59
+ 0x57 0x56 0x54 0x4F 0x3B 0x1F 0x7F 0x17
+ 0x06 0x1A 0x30 0x5A 0x85 0x93 0x96 0x2D
+ 0x48 0x77 0x9C 0xB3 0x80 0x52 0x94 0xCB
+ 0x2F 0x00 0x64 0xA5 0xB5 0x11 0xF0 0x11
+ >;
+ cellwise,monitor-interval-ms = <5000>;
+ monitored-battery = <&bat>;
+ power-supplies = <&mains_charger>, <&fusb0>;
+ };
};
&i2s1 {
--
2.26.0
^ permalink raw reply related
* [PATCH 0/1] Add fuel gauge to Pinbook Pro dts
From: Tobias Schramm @ 2020-05-28 17:25 UTC (permalink / raw)
To: Rob Herring, Heiko Stuebner
Cc: devicetree, linux-rockchip, linux-kernel, Tobias Schramm
Hi,
since the cw2015 fuel gauge will be supported in 5.8 this patch
adds a node for it to the Pinbook Pro device tree.
Best regards,
Tobias
Tobias Schramm (1):
arm64: dts: rockchip: add fuel gauge to Pinebook Pro dts
.../boot/dts/rockchip/rk3399-pinebook-pro.dts | 25 +++++++++++++++++++
1 file changed, 25 insertions(+)
--
2.26.0
^ permalink raw reply
* Re: [PATCHv3 0/2] Add support for replicators which loses context on clock removal
From: Mathieu Poirier @ 2020-05-28 17:40 UTC (permalink / raw)
To: Rob Herring
Cc: Sai Prakash Ranjan, Suzuki K Poulose, Mike Leach, devicetree,
linux-arm-kernel, linux-kernel, linux-arm-msm, Stephen Boyd
In-Reply-To: <20200528144803.GA36440@bogus>
On Thu, May 28, 2020 at 08:48:03AM -0600, Rob Herring wrote:
> On Mon, May 25, 2020 at 10:15:53AM -0600, Mathieu Poirier wrote:
> > Hi Sai,
> >
> > On Sat, May 23, 2020 at 12:06:50AM +0530, Sai Prakash Ranjan wrote:
> > > This series is mainly to add support for replicators
> > > which lose context on removing AMBA clock like on SC7180
> > > SoC where replicator in AOSS domain loses context.
> > >
> >
> > I am good with this set but need a reviewed-by on the DT binding before I can
> > add it to my tree. The same goes for your other set[1].
>
> Then why is it already in linux-next?
I wanted the patches to get exposure to linux-next before sending them on to
Greg for inclusion in the next merge window. Rest assured that I would not have
moved forward without your consent.
>
> In any case,
>
> Acked-by: Rob Herring <robh@kernel.org>
Thank you for that.
Mathieu
^ permalink raw reply
* Re: [PATCH v2 1/4] ARM: dts: dove: Make the DT compliant with the ti,tfp410 binding
From: Rob Herring @ 2020-05-28 17:37 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: Laurent.pinchart, kernel, devicetree, dri-devel, linux-arm-kernel,
jason, tomi.valkeinen, airlied, shawnguo
In-Reply-To: <20200514143612.2094-2-ricardo.canuelo@collabora.com>
On Thu, May 14, 2020 at 04:36:09PM +0200, Ricardo Cañuelo wrote:
> Define a 'ports' node for 'dvi: video@39' and use the proper naming for
> the powerdown-gpios property to make it compliant with the ti,tfp410
> binding.
>
> This fills the minimum requirements to meet the binding requirements,
> port endpoints are not defined.
Just make 'ports' optional. This isn't really any better unless you add
endpoints too.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
> ---
> arch/arm/boot/dts/dove-sbc-a510.dts | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/dove-sbc-a510.dts b/arch/arm/boot/dts/dove-sbc-a510.dts
> index 2bb85a9b7614..32804c981625 100644
> --- a/arch/arm/boot/dts/dove-sbc-a510.dts
> +++ b/arch/arm/boot/dts/dove-sbc-a510.dts
> @@ -132,7 +132,18 @@
> dvi: video@39 {
> compatible = "ti,tfp410";
> reg = <0x39>;
> - powerdown-gpio = <&gpio_ext 3 GPIO_ACTIVE_LOW>;
> + powerdown-gpios = <&gpio_ext 3 GPIO_ACTIVE_LOW>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + };
> + port@1 {
> + reg = <1>;
> + };
> + };
> };
> };
>
> --
> 2.18.0
>
^ permalink raw reply
* [PATCH v6] support gce on mt6779 platform
From: Dennis YC Hsieh @ 2020-05-28 17:04 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Matthias Brugger, Jassi Brar,
Philipp Zabel, David Airlie, Daniel Vetter
Cc: linux-kernel, linux-mediatek, devicetree, wsd_upstream, dri-devel,
Bibby Hsieh, CK Hu, Houlong Wei, linux-arm-kernel, HS Liao
This patch support gce on mt6779 platform.
Change since v5:
- spearate address shift code in client helper and mailbox controller
- separate write_s/write_s_mask and write_s_value/write_s_mask_value so that
client can decide use mask or not
- fix typo in header
Change since v4:
- do not clear disp event again in drm driver
- symbolize value 1 to jump relative
[... snip ...]
Dennis YC Hsieh (16):
dt-binding: gce: add gce header file for mt6779
mailbox: cmdq: variablize address shift in platform
mailbox: cmdq: support mt6779 gce platform definition
mailbox: mediatek: cmdq: clear task in channel before shutdown
soc: mediatek: cmdq: return send msg error code
soc: mediatek: cmdq: add address shift in jump
soc: mediatek: cmdq: add assign function
soc: mediatek: cmdq: add write_s function
soc: mediatek: cmdq: add write_s_mask function
soc: mediatek: cmdq: add read_s function
soc: mediatek: cmdq: add write_s value function
soc: mediatek: cmdq: add write_s_mask value function
soc: mediatek: cmdq: export finalize function
soc: mediatek: cmdq: add jump function
soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api
soc: mediatek: cmdq: add set event function
.../devicetree/bindings/mailbox/mtk-gce.txt | 8 +-
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +-
drivers/mailbox/mtk-cmdq-mailbox.c | 101 ++++++--
drivers/soc/mediatek/mtk-cmdq-helper.c | 163 ++++++++++++-
include/dt-bindings/gce/mt6779-gce.h | 222 ++++++++++++++++++
include/linux/mailbox/mtk-cmdq-mailbox.h | 10 +-
include/linux/soc/mediatek/mtk-cmdq.h | 125 +++++++++-
7 files changed, 599 insertions(+), 33 deletions(-)
create mode 100644 include/dt-bindings/gce/mt6779-gce.h
--
2.18.0
^ permalink raw reply
* [PATCH v6 07/16] soc: mediatek: cmdq: add assign function
From: Dennis YC Hsieh @ 2020-05-28 17:04 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Matthias Brugger, Jassi Brar,
Philipp Zabel, David Airlie, Daniel Vetter
Cc: linux-kernel, linux-mediatek, devicetree, wsd_upstream, dri-devel,
Bibby Hsieh, CK Hu, Houlong Wei, linux-arm-kernel, HS Liao,
Dennis YC Hsieh
In-Reply-To: <1590685491-17107-1-git-send-email-dennis-yc.hsieh@mediatek.com>
Add assign function in cmdq helper which assign constant value into
internal register by index.
Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 24 +++++++++++++++++++++++-
include/linux/mailbox/mtk-cmdq-mailbox.h | 1 +
include/linux/soc/mediatek/mtk-cmdq.h | 14 ++++++++++++++
3 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
index 98f23ba3ba47..33153d17c9d9 100644
--- a/drivers/soc/mediatek/mtk-cmdq-helper.c
+++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
@@ -12,6 +12,7 @@
#define CMDQ_WRITE_ENABLE_MASK BIT(0)
#define CMDQ_POLL_ENABLE_MASK BIT(0)
#define CMDQ_EOC_IRQ_EN BIT(0)
+#define CMDQ_REG_TYPE 1
struct cmdq_instruction {
union {
@@ -21,8 +22,17 @@ struct cmdq_instruction {
union {
u16 offset;
u16 event;
+ u16 reg_dst;
+ };
+ union {
+ u8 subsys;
+ struct {
+ u8 sop:5;
+ u8 arg_c_t:1;
+ u8 arg_b_t:1;
+ u8 dst_t:1;
+ };
};
- u8 subsys;
u8 op;
};
@@ -277,6 +287,18 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
}
EXPORT_SYMBOL(cmdq_pkt_poll_mask);
+int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value)
+{
+ struct cmdq_instruction inst = { {0} };
+
+ inst.op = CMDQ_CODE_LOGIC;
+ inst.dst_t = CMDQ_REG_TYPE;
+ inst.reg_dst = reg_idx;
+ inst.value = value;
+ return cmdq_pkt_append_command(pkt, inst);
+}
+EXPORT_SYMBOL(cmdq_pkt_assign);
+
static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
{
struct cmdq_instruction inst = { {0} };
diff --git a/include/linux/mailbox/mtk-cmdq-mailbox.h b/include/linux/mailbox/mtk-cmdq-mailbox.h
index dfe5b2eb85cc..121c3bb6d3de 100644
--- a/include/linux/mailbox/mtk-cmdq-mailbox.h
+++ b/include/linux/mailbox/mtk-cmdq-mailbox.h
@@ -59,6 +59,7 @@ enum cmdq_code {
CMDQ_CODE_JUMP = 0x10,
CMDQ_CODE_WFE = 0x20,
CMDQ_CODE_EOC = 0x40,
+ CMDQ_CODE_LOGIC = 0xa0,
};
enum cmdq_cb_status {
diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
index a74c1d5acdf3..83340211e1d3 100644
--- a/include/linux/soc/mediatek/mtk-cmdq.h
+++ b/include/linux/soc/mediatek/mtk-cmdq.h
@@ -152,6 +152,20 @@ int cmdq_pkt_poll(struct cmdq_pkt *pkt, u8 subsys,
*/
int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
u16 offset, u32 value, u32 mask);
+
+/**
+ * cmdq_pkt_assign() - Append logic assign command to the CMDQ packet, ask GCE
+ * to execute an instruction that set a constant value into
+ * internal register and use as value, mask or address in
+ * read/write instruction.
+ * @pkt: the CMDQ packet
+ * @reg_idx: the CMDQ internal register ID
+ * @value: the specified value
+ *
+ * Return: 0 for success; else the error code is returned
+ */
+int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value);
+
/**
* cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
* packet and call back at the end of done packet
--
2.18.0
^ permalink raw reply related
* [PATCH v6 01/16] dt-binding: gce: add gce header file for mt6779
From: Dennis YC Hsieh @ 2020-05-28 17:04 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Matthias Brugger, Jassi Brar,
Philipp Zabel, David Airlie, Daniel Vetter
Cc: linux-kernel, linux-mediatek, devicetree, wsd_upstream, dri-devel,
Bibby Hsieh, CK Hu, Houlong Wei, linux-arm-kernel, HS Liao,
Dennis YC Hsieh
In-Reply-To: <1590685491-17107-1-git-send-email-dennis-yc.hsieh@mediatek.com>
Add documentation for the mt6779 gce.
Add gce header file defined the gce hardware event,
subsys number and constant for mt6779.
Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
---
.../devicetree/bindings/mailbox/mtk-gce.txt | 8 +-
include/dt-bindings/gce/mt6779-gce.h | 222 ++++++++++++++++++
2 files changed, 227 insertions(+), 3 deletions(-)
create mode 100644 include/dt-bindings/gce/mt6779-gce.h
diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
index 7b13787ab13d..82c0a83fed09 100644
--- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
+++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt
@@ -9,7 +9,8 @@ CMDQ driver uses mailbox framework for communication. Please refer to
mailbox.txt for generic information about mailbox device-tree bindings.
Required properties:
-- compatible: can be "mediatek,mt8173-gce" or "mediatek,mt8183-gce"
+- compatible: can be "mediatek,mt8173-gce", "mediatek,mt8183-gce" or
+ "mediatek,mt6779-gce".
- reg: Address range of the GCE unit
- interrupts: The interrupt signal from the GCE block
- clock: Clocks according to the common clock binding
@@ -36,8 +37,9 @@ Optional properties for a client device:
start_offset: the start offset of register address that GCE can access.
size: the total size of register address that GCE can access.
-Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h'
-or 'dt-binding/gce/mt8183-gce.h'. Such as sub-system ids, thread priority, event ids.
+Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h',
+'dt-binding/gce/mt8183-gce.h' or 'dt-bindings/gce/mt6779-gce.h'. Such as
+sub-system ids, thread priority, event ids.
Example:
diff --git a/include/dt-bindings/gce/mt6779-gce.h b/include/dt-bindings/gce/mt6779-gce.h
new file mode 100644
index 000000000000..06101316ace4
--- /dev/null
+++ b/include/dt-bindings/gce/mt6779-gce.h
@@ -0,0 +1,222 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2019 MediaTek Inc.
+ * Author: Dennis-YC Hsieh <dennis-yc.hsieh@mediatek.com>
+ */
+
+#ifndef _DT_BINDINGS_GCE_MT6779_H
+#define _DT_BINDINGS_GCE_MT6779_H
+
+#define CMDQ_NO_TIMEOUT 0xffffffff
+
+/* GCE HW thread priority */
+#define CMDQ_THR_PRIO_LOWEST 0
+#define CMDQ_THR_PRIO_1 1
+#define CMDQ_THR_PRIO_2 2
+#define CMDQ_THR_PRIO_3 3
+#define CMDQ_THR_PRIO_4 4
+#define CMDQ_THR_PRIO_5 5
+#define CMDQ_THR_PRIO_6 6
+#define CMDQ_THR_PRIO_HIGHEST 7
+
+/* GCE subsys table */
+#define SUBSYS_1300XXXX 0
+#define SUBSYS_1400XXXX 1
+#define SUBSYS_1401XXXX 2
+#define SUBSYS_1402XXXX 3
+#define SUBSYS_1502XXXX 4
+#define SUBSYS_1880XXXX 5
+#define SUBSYS_1881XXXX 6
+#define SUBSYS_1882XXXX 7
+#define SUBSYS_1883XXXX 8
+#define SUBSYS_1884XXXX 9
+#define SUBSYS_1000XXXX 10
+#define SUBSYS_1001XXXX 11
+#define SUBSYS_1002XXXX 12
+#define SUBSYS_1003XXXX 13
+#define SUBSYS_1004XXXX 14
+#define SUBSYS_1005XXXX 15
+#define SUBSYS_1020XXXX 16
+#define SUBSYS_1028XXXX 17
+#define SUBSYS_1700XXXX 18
+#define SUBSYS_1701XXXX 19
+#define SUBSYS_1702XXXX 20
+#define SUBSYS_1703XXXX 21
+#define SUBSYS_1800XXXX 22
+#define SUBSYS_1801XXXX 23
+#define SUBSYS_1802XXXX 24
+#define SUBSYS_1804XXXX 25
+#define SUBSYS_1805XXXX 26
+#define SUBSYS_1808XXXX 27
+#define SUBSYS_180aXXXX 28
+#define SUBSYS_180bXXXX 29
+#define CMDQ_SUBSYS_OFF 32
+
+/* GCE hardware events */
+#define CMDQ_EVENT_DISP_RDMA0_SOF 0
+#define CMDQ_EVENT_DISP_RDMA1_SOF 1
+#define CMDQ_EVENT_MDP_RDMA0_SOF 2
+#define CMDQ_EVENT_MDP_RDMA1_SOF 3
+#define CMDQ_EVENT_MDP_RSZ0_SOF 4
+#define CMDQ_EVENT_MDP_RSZ1_SOF 5
+#define CMDQ_EVENT_MDP_TDSHP_SOF 6
+#define CMDQ_EVENT_MDP_WROT0_SOF 7
+#define CMDQ_EVENT_MDP_WROT1_SOF 8
+#define CMDQ_EVENT_DISP_OVL0_SOF 9
+#define CMDQ_EVENT_DISP_2L_OVL0_SOF 10
+#define CMDQ_EVENT_DISP_2L_OVL1_SOF 11
+#define CMDQ_EVENT_DISP_WDMA0_SOF 12
+#define CMDQ_EVENT_DISP_COLOR0_SOF 13
+#define CMDQ_EVENT_DISP_CCORR0_SOF 14
+#define CMDQ_EVENT_DISP_AAL0_SOF 15
+#define CMDQ_EVENT_DISP_GAMMA0_SOF 16
+#define CMDQ_EVENT_DISP_DITHER0_SOF 17
+#define CMDQ_EVENT_DISP_PWM0_SOF 18
+#define CMDQ_EVENT_DISP_DSI0_SOF 19
+#define CMDQ_EVENT_DISP_DPI0_SOF 20
+#define CMDQ_EVENT_DISP_POSTMASK0_SOF 21
+#define CMDQ_EVENT_DISP_RSZ0_SOF 22
+#define CMDQ_EVENT_MDP_AAL_SOF 23
+#define CMDQ_EVENT_MDP_CCORR_SOF 24
+#define CMDQ_EVENT_DISP_DBI0_SOF 25
+#define CMDQ_EVENT_ISP_RELAY_SOF 26
+#define CMDQ_EVENT_IPU_RELAY_SOF 27
+#define CMDQ_EVENT_DISP_RDMA0_EOF 28
+#define CMDQ_EVENT_DISP_RDMA1_EOF 29
+#define CMDQ_EVENT_MDP_RDMA0_EOF 30
+#define CMDQ_EVENT_MDP_RDMA1_EOF 31
+#define CMDQ_EVENT_MDP_RSZ0_EOF 32
+#define CMDQ_EVENT_MDP_RSZ1_EOF 33
+#define CMDQ_EVENT_MDP_TDSHP_EOF 34
+#define CMDQ_EVENT_MDP_WROT0_W_EOF 35
+#define CMDQ_EVENT_MDP_WROT1_W_EOF 36
+#define CMDQ_EVENT_DISP_OVL0_EOF 37
+#define CMDQ_EVENT_DISP_2L_OVL0_EOF 38
+#define CMDQ_EVENT_DISP_2L_OVL1_EOF 39
+#define CMDQ_EVENT_DISP_WDMA0_EOF 40
+#define CMDQ_EVENT_DISP_COLOR0_EOF 41
+#define CMDQ_EVENT_DISP_CCORR0_EOF 42
+#define CMDQ_EVENT_DISP_AAL0_EOF 43
+#define CMDQ_EVENT_DISP_GAMMA0_EOF 44
+#define CMDQ_EVENT_DISP_DITHER0_EOF 45
+#define CMDQ_EVENT_DISP_DSI0_EOF 46
+#define CMDQ_EVENT_DISP_DPI0_EOF 47
+#define CMDQ_EVENT_DISP_RSZ0_EOF 49
+#define CMDQ_EVENT_MDP_AAL_FRAME_DONE 50
+#define CMDQ_EVENT_MDP_CCORR_FRAME_DONE 51
+#define CMDQ_EVENT_DISP_POSTMASK0_FRAME_DONE 52
+#define CMDQ_EVENT_MUTEX0_STREAM_EOF 130
+#define CMDQ_EVENT_MUTEX1_STREAM_EOF 131
+#define CMDQ_EVENT_MUTEX2_STREAM_EOF 132
+#define CMDQ_EVENT_MUTEX3_STREAM_EOF 133
+#define CMDQ_EVENT_MUTEX4_STREAM_EOF 134
+#define CMDQ_EVENT_MUTEX5_STREAM_EOF 135
+#define CMDQ_EVENT_MUTEX6_STREAM_EOF 136
+#define CMDQ_EVENT_MUTEX7_STREAM_EOF 137
+#define CMDQ_EVENT_MUTEX8_STREAM_EOF 138
+#define CMDQ_EVENT_MUTEX9_STREAM_EOF 139
+#define CMDQ_EVENT_MUTEX10_STREAM_EOF 140
+#define CMDQ_EVENT_MUTEX11_STREAM_EOF 141
+#define CMDQ_EVENT_DISP_RDMA0_UNDERRUN 142
+#define CMDQ_EVENT_DISP_RDMA1_UNDERRUN 143
+#define CMDQ_EVENT_DISP_RDMA2_UNDERRUN 144
+#define CMDQ_EVENT_DISP_RDMA3_UNDERRUN 145
+#define CMDQ_EVENT_DSI0_TE 146
+#define CMDQ_EVENT_DSI0_IRQ_EVENT 147
+#define CMDQ_EVENT_DSI0_DONE_EVENT 148
+#define CMDQ_EVENT_DISP_POSTMASK0_RST_DONE 150
+#define CMDQ_EVENT_DISP_WDMA0_RST_DONE 151
+#define CMDQ_EVENT_MDP_WROT0_RST_DONE 153
+#define CMDQ_EVENT_MDP_RDMA0_RST_DONE 154
+#define CMDQ_EVENT_DISP_OVL0_RST_DONE 155
+#define CMDQ_EVENT_DISP_OVL0_2L_RST_DONE 156
+#define CMDQ_EVENT_DISP_OVL1_2L_RST_DONE 157
+#define CMDQ_EVENT_DIP_CQ_THREAD0_EOF 257
+#define CMDQ_EVENT_DIP_CQ_THREAD1_EOF 258
+#define CMDQ_EVENT_DIP_CQ_THREAD2_EOF 259
+#define CMDQ_EVENT_DIP_CQ_THREAD3_EOF 260
+#define CMDQ_EVENT_DIP_CQ_THREAD4_EOF 261
+#define CMDQ_EVENT_DIP_CQ_THREAD5_EOF 262
+#define CMDQ_EVENT_DIP_CQ_THREAD6_EOF 263
+#define CMDQ_EVENT_DIP_CQ_THREAD7_EOF 264
+#define CMDQ_EVENT_DIP_CQ_THREAD8_EOF 265
+#define CMDQ_EVENT_DIP_CQ_THREAD9_EOF 266
+#define CMDQ_EVENT_DIP_CQ_THREAD10_EOF 267
+#define CMDQ_EVENT_DIP_CQ_THREAD11_EOF 268
+#define CMDQ_EVENT_DIP_CQ_THREAD12_EOF 269
+#define CMDQ_EVENT_DIP_CQ_THREAD13_EOF 270
+#define CMDQ_EVENT_DIP_CQ_THREAD14_EOF 271
+#define CMDQ_EVENT_DIP_CQ_THREAD15_EOF 272
+#define CMDQ_EVENT_DIP_CQ_THREAD16_EOF 273
+#define CMDQ_EVENT_DIP_CQ_THREAD17_EOF 274
+#define CMDQ_EVENT_DIP_CQ_THREAD18_EOF 275
+#define CMDQ_EVENT_DIP_DMA_ERR_EVENT 276
+#define CMDQ_EVENT_AMD_FRAME_DONE 277
+#define CMDQ_EVENT_MFB_DONE 278
+#define CMDQ_EVENT_WPE_A_EOF 279
+#define CMDQ_EVENT_VENC_EOF 289
+#define CMDQ_EVENT_VENC_CMDQ_PAUSE_DONE 290
+#define CMDQ_EVENT_JPEG_ENC_EOF 291
+#define CMDQ_EVENT_VENC_MB_DONE 292
+#define CMDQ_EVENT_VENC_128BYTE_CNT_DONE 293
+#define CMDQ_EVENT_ISP_FRAME_DONE_A 321
+#define CMDQ_EVENT_ISP_FRAME_DONE_B 322
+#define CMDQ_EVENT_ISP_FRAME_DONE_C 323
+#define CMDQ_EVENT_ISP_CAMSV_0_PASS1_DONE 324
+#define CMDQ_EVENT_ISP_CAMSV_0_2_PASS1_DONE 325
+#define CMDQ_EVENT_ISP_CAMSV_1_PASS1_DONE 326
+#define CMDQ_EVENT_ISP_CAMSV_2_PASS1_DONE 327
+#define CMDQ_EVENT_ISP_CAMSV_3_PASS1_DONE 328
+#define CMDQ_EVENT_ISP_TSF_DONE 329
+#define CMDQ_EVENT_SENINF_0_FIFO_FULL 330
+#define CMDQ_EVENT_SENINF_1_FIFO_FULL 331
+#define CMDQ_EVENT_SENINF_2_FIFO_FULL 332
+#define CMDQ_EVENT_SENINF_3_FIFO_FULL 333
+#define CMDQ_EVENT_SENINF_4_FIFO_FULL 334
+#define CMDQ_EVENT_SENINF_5_FIFO_FULL 335
+#define CMDQ_EVENT_SENINF_6_FIFO_FULL 336
+#define CMDQ_EVENT_SENINF_7_FIFO_FULL 337
+#define CMDQ_EVENT_TG_OVRUN_A_INT_DLY 338
+#define CMDQ_EVENT_TG_OVRUN_B_INT_DLY 339
+#define CMDQ_EVENT_TG_OVRUN_C_INT 340
+#define CMDQ_EVENT_TG_GRABERR_A_INT_DLY 341
+#define CMDQ_EVENT_TG_GRABERR_B_INT_DLY 342
+#define CMDQ_EVENT_TG_GRABERR_C_INT 343
+#define CMDQ_EVENT_CQ_VR_SNAP_A_INT_DLY 344
+#define CMDQ_EVENT_CQ_VR_SNAP_B_INT_DLY 345
+#define CMDQ_EVENT_CQ_VR_SNAP_C_INT 346
+#define CMDQ_EVENT_DMA_R1_ERROR_A_INT_DLY 347
+#define CMDQ_EVENT_DMA_R1_ERROR_B_INT_DLY 348
+#define CMDQ_EVENT_DMA_R1_ERROR_C_INT 349
+#define CMDQ_EVENT_APU_GCE_CORE0_EVENT_0 353
+#define CMDQ_EVENT_APU_GCE_CORE0_EVENT_1 354
+#define CMDQ_EVENT_APU_GCE_CORE0_EVENT_2 355
+#define CMDQ_EVENT_APU_GCE_CORE0_EVENT_3 356
+#define CMDQ_EVENT_APU_GCE_CORE1_EVENT_0 385
+#define CMDQ_EVENT_APU_GCE_CORE1_EVENT_1 386
+#define CMDQ_EVENT_APU_GCE_CORE1_EVENT_2 387
+#define CMDQ_EVENT_APU_GCE_CORE1_EVENT_3 388
+#define CMDQ_EVENT_VDEC_EVENT_0 416
+#define CMDQ_EVENT_VDEC_EVENT_1 417
+#define CMDQ_EVENT_VDEC_EVENT_2 418
+#define CMDQ_EVENT_VDEC_EVENT_3 419
+#define CMDQ_EVENT_VDEC_EVENT_4 420
+#define CMDQ_EVENT_VDEC_EVENT_5 421
+#define CMDQ_EVENT_VDEC_EVENT_6 422
+#define CMDQ_EVENT_VDEC_EVENT_7 423
+#define CMDQ_EVENT_VDEC_EVENT_8 424
+#define CMDQ_EVENT_VDEC_EVENT_9 425
+#define CMDQ_EVENT_VDEC_EVENT_10 426
+#define CMDQ_EVENT_VDEC_EVENT_11 427
+#define CMDQ_EVENT_VDEC_EVENT_12 428
+#define CMDQ_EVENT_VDEC_EVENT_13 429
+#define CMDQ_EVENT_VDEC_EVENT_14 430
+#define CMDQ_EVENT_VDEC_EVENT_15 431
+#define CMDQ_EVENT_FDVT_DONE 449
+#define CMDQ_EVENT_FE_DONE 450
+#define CMDQ_EVENT_RSC_EOF 451
+#define CMDQ_EVENT_DVS_DONE_ASYNC_SHOT 452
+#define CMDQ_EVENT_DVP_DONE_ASYNC_SHOT 453
+#define CMDQ_EVENT_DSI0_TE_INFRA 898
+
+#endif
--
2.18.0
^ 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