* Re: [PATCH v25 01/16] dt: bindings: Add multicolor class dt bindings documention
From: Rob Herring @ 2020-06-02 21:44 UTC (permalink / raw)
To: Pavel Machek
Cc: Dan Murphy, Jacek Anaszewski, devicetree, Linux LED Subsystem,
linux-kernel@vger.kernel.org
In-Reply-To: <20200602200436.GA6535@amd>
On Tue, Jun 2, 2020 at 2:04 PM Pavel Machek <pavel@ucw.cz> wrote:
>
> On Wed 2020-05-27 08:35:06, Rob Herring wrote:
> > On Wed, May 27, 2020 at 7:39 AM Pavel Machek <pavel@ucw.cz> wrote:
> > >
> > > Hi!
> > >
> > > Thanks for reviews!
> > >
> > > > > +additionalProperties: false
> > > > > +...
> > > > > diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
> > > >
> > > > This isn't a binding file. Belongs in another patch.
> > >
> > > These constants are directly related to the binding. It makes sense to
> > > go in one patch...
> >
> > Yes, the header does go in this patch, but kernel subsystem files do not.
> >
> > Part of the reason for separating is we generate a DT only repository
> > which filters out all the kernel code. Ideally this is just filtering
> > out commits and the commit messages still make sens
>
> Well, but the patch can't be split like that. Otherwise we risk null
> pointer dereferences when one part is applied but not the second one.
There's no risk because you are supposed to apply both patches. I
don't apply binding patches that are a part of a series like this.
Rob
^ permalink raw reply
* Re: [PATCH 0/3] ARM: dts: NSP: Add support for Cisco Meraki NSP devices
From: Florian Fainelli @ 2020-06-02 21:55 UTC (permalink / raw)
To: Matthew Hagan
Cc: Rob Herring, Ray Jui, Scott Branden, bcm-kernel-feedback-list,
devicetree, linux-arm-kernel
In-Reply-To: <cover.1591114003.git.mnhagan88@gmail.com>
Hi Matthew,
On 6/2/2020 9:11 AM, Matthew Hagan wrote:
> This patch set adds support for the Meraki MX64(W) and MX65(W) security
> devices. There are four devices in total, all using the same basic hardware.
>
> The MX64 series has five ethernet ports connected to the BCM SRAB. The MX65
> series has two ports conected to the SRAB, and two QCA8337 switches connected
> by SGMII to SRAB ports 4 and 5, each providing five additional ports.
>
> The W variants of these devices have two BCM43520s on the PCIe bus. On the
> non-wireless variants PCIe is inactive, hence separate dts files.
>
> 1/3 contains common bindings for both Meraki devices.
> 2/3 contains MX64 specific bindings.
> 3/3 contains MX65 specific bindings.
Glad to see those patches being submitted upstream to support those
devices, don't we need a change to arch/arm/boot/dts/Makefile to add
those DTS files to be built when ARCH_BCM_NSP is enabled?
>
> Note that Chris Packham's "[PATCH 2/2] ARM: dts: NSP: avoid unnecessary probe
> deferrals" is also necessary.
Humm, I am not sure this patch is really the way to go, but I have to
look at it again.
>
> Thanks,
> Matthew
>
> Matthew Hagan (3):
> ARM: dts: NSP: Add common bindings for Meraki MX64/65
> ARM: dts: NSP: Add support for Cisco Meraki MX64(W)
> ARM: dts: NSP: Add support for Cisco Meraki MX65(W)
>
> arch/arm/boot/dts/bcm958625-mx64.dts | 15 +
> arch/arm/boot/dts/bcm958625-mx64w.dts | 23 ++
> arch/arm/boot/dts/bcm958625-mx64x.dtsi | 136 ++++++++
> arch/arm/boot/dts/bcm958625-mx65.dts | 15 +
> arch/arm/boot/dts/bcm958625-mx65w.dts | 23 ++
> arch/arm/boot/dts/bcm958625-mx65x.dtsi | 321 +++++++++++++++++++
> arch/arm/boot/dts/bcm958625-mx6x-common.dtsi | 172 ++++++++++
> 7 files changed, 705 insertions(+)
> create mode 100644 arch/arm/boot/dts/bcm958625-mx64.dts
> create mode 100644 arch/arm/boot/dts/bcm958625-mx64w.dts
> create mode 100644 arch/arm/boot/dts/bcm958625-mx64x.dtsi
> create mode 100644 arch/arm/boot/dts/bcm958625-mx65.dts
> create mode 100644 arch/arm/boot/dts/bcm958625-mx65w.dts
> create mode 100644 arch/arm/boot/dts/bcm958625-mx65x.dtsi
> create mode 100644 arch/arm/boot/dts/bcm958625-mx6x-common.dtsi
>
--
Florian
^ permalink raw reply
* Re: [PATCH v2 03/14] dt-bindings: PCI: Add bindings for more Brcmstb chips
From: Jim Quinlan @ 2020-06-02 21:55 UTC (permalink / raw)
To: Rob Herring
Cc: open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS,
Christoph Hellwig, Nicolas Saenz Julienne,
maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE, Florian Fainelli,
Bjorn Helgaas,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <CAL_JsqKtASTzACSNn8BgmEBqf0eyR8RB_tjY7aUnvK+2GYXTbg@mail.gmail.com>
On Tue, Jun 2, 2020 at 5:41 PM Rob Herring <robh@kernel.org> wrote:
>
> On Tue, Jun 2, 2020 at 2:53 PM Jim Quinlan <james.quinlan@broadcom.com> wrote:
> >
> > On Fri, May 29, 2020 at 1:46 PM Rob Herring <robh@kernel.org> wrote:
> > >
> > > On Tue, May 26, 2020 at 03:12:42PM -0400, Jim Quinlan wrote:
> > > > From: Jim Quinlan <jquinlan@broadcom.com>
> > > >
> > > > - Add compatible strings for three more Broadcom STB chips: 7278, 7216,
> > > > 7211 (STB version of RPi4).
> > > > - add new property 'brcm,scb-sizes'
> > > > - add new property 'resets'
> > > > - add new property 'reset-names'
> > > > - allow 'ranges' and 'dma-ranges' to have more than one item and update
> > > > the example to show this.
> > > >
> > > > Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
> > > > ---
> > > > .../bindings/pci/brcm,stb-pcie.yaml | 40 +++++++++++++++++--
> > > > 1 file changed, 36 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > > > index 8680a0f86c5a..66a7df45983d 100644
> > > > --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > > > +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > > > @@ -14,7 +14,13 @@ allOf:
> > > >
> > > > properties:
> > > > compatible:
> > > > - const: brcm,bcm2711-pcie # The Raspberry Pi 4
> > > > + items:
> > > > + - enum:
> > >
> > > Don't need items here. Just change the const to enum.
> > >
> > > > + - brcm,bcm2711-pcie # The Raspberry Pi 4
> > > > + - brcm,bcm7211-pcie # Broadcom STB version of RPi4
> > > > + - brcm,bcm7278-pcie # Broadcom 7278 Arm
> > > > + - brcm,bcm7216-pcie # Broadcom 7216 Arm
> > > > + - brcm,bcm7445-pcie # Broadcom 7445 Arm
> > > >
> > > > reg:
> > > > maxItems: 1
> > > > @@ -34,10 +40,12 @@ properties:
> > > > - const: msi
> > > >
> > > > ranges:
> > > > - maxItems: 1
> > > > + minItems: 1
> > > > + maxItems: 4
> > > >
> > > > dma-ranges:
> > > > - maxItems: 1
> > > > + minItems: 1
> > > > + maxItems: 6
> > > >
> > > > clocks:
> > > > maxItems: 1
> > > > @@ -58,8 +66,30 @@ properties:
> > > >
> > > > aspm-no-l0s: true
> > > >
> > > > + resets:
> > > > + description: for "brcm,bcm7216-pcie", must be a valid reset
> > > > + phandle pointing to the RESCAL reset controller provider node.
> > > > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > > > +
> > > > + reset-names:
> > > > + items:
> > > > + - const: rescal
> > >
> > > These are going to need to be an if/then schema if they only apply to
> > > certain compatible(s).
> >
> > Why is that -- the code is general enough to handle its presence or
> > not (it is an optional compatibility)>
>
> Because an if/then schema expresses in a parse-able form what your
> 'description' does in free form text.
>
> Presumably a 'resets' property for !brcm,bcm7216-pcie is invalid, so
> we should check that. The schema shouldn't be just what some driver
> happens to currently allow. Also, it's not a driver's job to validate
> DT, so it shouldn't check any of this.
Got it, will fix.
>
> > > > + brcm,scb-sizes:
> > > > + description: (u32, u32) tuple giving the 64bit PCIe memory
> > > > + viewport size of a memory controller. There may be up to
> > > > + three controllers, and each size must be a power of two
> > > > + with a size greater or equal to the amount of memory the
> > > > + controller supports.
> > >
> > > This sounds like what dma-ranges should express?
> >
> > There is some overlap but this contains information that is not in the
> > dma-ranges. Believe me I tried.
>
> I don't understand. If you had 3 dma-ranges entries, you'd have 3
> sizes. Can you expand or show me what you tried?
Here is a simple example: suppose you have two dma-ranges. This could
be from one of two cases:
- Both dma-ranges are from the same memory controller (the second
range is the "extended" region).
- One dma-range can be from memc0 and the other can be from memc1; the
extensions are not used.
The driver has to determine (a) how many memory controllers there are
and (b) what the size should be for each of them. It is impossible to
do this with the case above.
>
> > > If not, we do have 64-bit size if that what you need.
> >
> > IIRC I tried the 64-bit size but the YAML validator did not like it;
> > it wanted numbers like <0x1122334455667788> while dtc wanted <
> > 0x11223344 0x55667788>. I gave up trying and switched to u32.
>
> You used the /bits/ annotation for dtc?:
>
> /bits/ 64 <0x1122334455667788>
>
> I also made a recent fix to dt-schema around handling of 64-bit sizes,
> so update if you have problems still.
I didn't try the /bits/ so I'll pursue this.
Thanks,
Jim
>
> Rob
^ permalink raw reply
* Re: [PATCH net-next v5 4/4] net: dp83869: Add RGMII internal delay configuration
From: Florian Fainelli @ 2020-06-02 22:33 UTC (permalink / raw)
To: Dan Murphy, andrew, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree
In-Reply-To: <20200602164522.3276-5-dmurphy@ti.com>
On 6/2/2020 9:45 AM, Dan Murphy wrote:
> Add RGMII internal delay configuration for Rx and Tx.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
[snip]
> +
> enum {
> DP83869_PORT_MIRRORING_KEEP,
> DP83869_PORT_MIRRORING_EN,
> @@ -108,6 +113,8 @@ enum {
> struct dp83869_private {
> int tx_fifo_depth;
> int rx_fifo_depth;
> + s32 rx_id_delay;
> + s32 tx_id_delay;
> int io_impedance;
> int port_mirroring;
> bool rxctrl_strap_quirk;
> @@ -232,6 +239,22 @@ static int dp83869_of_init(struct phy_device *phydev)
> &dp83869->tx_fifo_depth))
> dp83869->tx_fifo_depth = DP83869_PHYCR_FIFO_DEPTH_4_B_NIB;
>
> + ret = of_property_read_u32(of_node, "rx-internal-delay-ps",
> + &dp83869->rx_id_delay);
> + if (ret) {
> + dp83869->rx_id_delay =
> + dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
> + ret = 0;
> + }
> +
> + ret = of_property_read_u32(of_node, "tx-internal-delay-ps",
> + &dp83869->tx_id_delay);
> + if (ret) {
> + dp83869->tx_id_delay =
> + dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
> + ret = 0;
> + }
It is still not clear to me why is not the parsing being done by the PHY
library helper directly?
--
Florian
^ permalink raw reply
* Re: [PATCH 06/10] dt-bindings: spi: spi-dw-mchp: Add Sparx5 support
From: Serge Semin @ 2020-06-02 23:07 UTC (permalink / raw)
To: Lars Povlsen
Cc: Serge Semin, Mark Brown, SoC Team, Rob Herring, devicetree,
Alexandre Belloni, linux-kernel, linux-spi,
Microchip Linux Driver Support, linux-arm-kernel
In-Reply-To: <20200513140031.25633-7-lars.povlsen@microchip.com>
On Wed, May 13, 2020 at 04:00:27PM +0200, Lars Povlsen wrote:
> This add DT bindings for the Sparx5 SPI driver.
This whole file can be easily merged in to the generic DW APB SSI DT
binding file. Just use "if: properties: compatible: const: ..." construction
to distinguish ocelot, jaguar, sparx5 and non-sparx5 nodes.
>
> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> ---
> .../bindings/spi/mscc,ocelot-spi.yaml | 49 +++++++++++++++----
> 1 file changed, 39 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/spi/mscc,ocelot-spi.yaml b/Documentation/devicetree/bindings/spi/mscc,ocelot-spi.yaml
> index a3ac0fa576553..8beecde4b0880 100644
> --- a/Documentation/devicetree/bindings/spi/mscc,ocelot-spi.yaml
> +++ b/Documentation/devicetree/bindings/spi/mscc,ocelot-spi.yaml
> @@ -23,15 +23,23 @@ properties:
> enum:
> - mscc,ocelot-spi
> - mscc,jaguar2-spi
> + - microchip,sparx5-spi
>
> interrupts:
> maxItems: 1
>
> reg:
> minItems: 2
> - items:
> - - description: Designware SPI registers
> - - description: CS override registers
> + maxItems: 3
> + oneOf:
> + - items:
> + - description: Designware SPI registers
> + - description: CS override registers (Not sparx5).
> + - items:
> + - description: Designware SPI registers
> + - description: CS override registers (Not sparx5).
> + - description: Direct mapped SPI read area. If provided, the
> + driver will register spi_mem_op's to take advantage of it.
>
> clocks:
> maxItems: 1
> @@ -43,6 +51,23 @@ properties:
> enum: [ 2, 4 ]
> maxItems: 1
>
> + spi-rx-delay-us:
> + description: |
> + The delay (in usec) of the RX signal sample position. This can
> + be used to tne the RX timing in order to acheive higher
> + speeds. This is used for all devices on the bus.
> + default: 0
> + maxItems: 1
spi-rx-delay-us is defined for a particular SPI-slave. Please see the
DT binding file: Documentation/devicetree/bindings/spi/spi-controller.yaml .
Although as I suggested before this delay isn't what the Dw APB SSI RX sample
delay functionality does. Probably a vendor-specific property would be better
here. But I'd also define it on a SPI-slave basis, not for all devices on the
bus.
> +
> + interface-mapping-mask:
> + description: |
> + On the Sparx5 variant, two different busses are connected to the
> + controller. This property is a mask per chip-select, indicating
> + whether the CS should go to one or the other interface.
> + $ref: /schemas/types.yaml#/definitions/uint32
> + default: 0
> + maxItems: 1
As Mark rightfully suggested this seems like an SPI-slave related property, then
most likely it should be defined on the SPI-slave basis (probably as a bool
property). Additionally it's vendor-specific, so the property name should be
accordingly prefixed.
> +
> required:
> - compatible
> - reg
> @@ -50,11 +75,15 @@ required:
>
> examples:
> - |
> - spi0: spi@101000 {
> - compatible = "mscc,ocelot-spi";
> - #address-cells = <1>;
> - #size-cells = <0>;
> - reg = <0x101000 0x100>, <0x3c 0x18>;
> - interrupts = <9>;
> - clocks = <&ahb_clk>;
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + spi0: spi@600104000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "microchip,sparx5-spi";
> + reg = <0x00104000 0x40>, <0 0>, <0x3000000 0x4000000>;
I have a doubt that defining an empty reg region is a good idea, since you can
detect the reg requirements by the node compatible string.
-Sergey
> + num-cs = <16>;
> + reg-io-width = <4>;
> + reg-shift = <2>;
> + clocks = <&ahb_clk>;
> + interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH>;
> };
> --
> 2.26.2
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net-next v5 4/4] net: dp83869: Add RGMII internal delay configuration
From: Dan Murphy @ 2020-06-02 23:10 UTC (permalink / raw)
To: Florian Fainelli, andrew, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree
In-Reply-To: <c3c68dcd-ccf1-25fd-fc4c-4c30608a1cc8@gmail.com>
Florian
On 6/2/20 5:33 PM, Florian Fainelli wrote:
>
> On 6/2/2020 9:45 AM, Dan Murphy wrote:
>> Add RGMII internal delay configuration for Rx and Tx.
>>
>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>> ---
> [snip]
>
>> +
>> enum {
>> DP83869_PORT_MIRRORING_KEEP,
>> DP83869_PORT_MIRRORING_EN,
>> @@ -108,6 +113,8 @@ enum {
>> struct dp83869_private {
>> int tx_fifo_depth;
>> int rx_fifo_depth;
>> + s32 rx_id_delay;
>> + s32 tx_id_delay;
>> int io_impedance;
>> int port_mirroring;
>> bool rxctrl_strap_quirk;
>> @@ -232,6 +239,22 @@ static int dp83869_of_init(struct phy_device *phydev)
>> &dp83869->tx_fifo_depth))
>> dp83869->tx_fifo_depth = DP83869_PHYCR_FIFO_DEPTH_4_B_NIB;
>>
>> + ret = of_property_read_u32(of_node, "rx-internal-delay-ps",
>> + &dp83869->rx_id_delay);
>> + if (ret) {
>> + dp83869->rx_id_delay =
>> + dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
>> + ret = 0;
>> + }
>> +
>> + ret = of_property_read_u32(of_node, "tx-internal-delay-ps",
>> + &dp83869->tx_id_delay);
>> + if (ret) {
>> + dp83869->tx_id_delay =
>> + dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
>> + ret = 0;
>> + }
> It is still not clear to me why is not the parsing being done by the PHY
> library helper directly?
Why would we do that for these properties and not any other?
Unless there is a new precedence being set here by having the PHY
framework do all the dt node parsing for common properties.
Dan
^ permalink raw reply
* Re: [PATCH net-next v5 4/4] net: dp83869: Add RGMII internal delay configuration
From: Florian Fainelli @ 2020-06-02 23:13 UTC (permalink / raw)
To: Dan Murphy, andrew, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree
In-Reply-To: <61888788-041f-7b93-9d99-7dad4c148021@ti.com>
On 6/2/2020 4:10 PM, Dan Murphy wrote:
> Florian
>
> On 6/2/20 5:33 PM, Florian Fainelli wrote:
>>
>> On 6/2/2020 9:45 AM, Dan Murphy wrote:
>>> Add RGMII internal delay configuration for Rx and Tx.
>>>
>>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>>> ---
>> [snip]
>>
>>> +
>>> enum {
>>> DP83869_PORT_MIRRORING_KEEP,
>>> DP83869_PORT_MIRRORING_EN,
>>> @@ -108,6 +113,8 @@ enum {
>>> struct dp83869_private {
>>> int tx_fifo_depth;
>>> int rx_fifo_depth;
>>> + s32 rx_id_delay;
>>> + s32 tx_id_delay;
>>> int io_impedance;
>>> int port_mirroring;
>>> bool rxctrl_strap_quirk;
>>> @@ -232,6 +239,22 @@ static int dp83869_of_init(struct phy_device
>>> *phydev)
>>> &dp83869->tx_fifo_depth))
>>> dp83869->tx_fifo_depth = DP83869_PHYCR_FIFO_DEPTH_4_B_NIB;
>>> + ret = of_property_read_u32(of_node, "rx-internal-delay-ps",
>>> + &dp83869->rx_id_delay);
>>> + if (ret) {
>>> + dp83869->rx_id_delay =
>>> + dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
>>> + ret = 0;
>>> + }
>>> +
>>> + ret = of_property_read_u32(of_node, "tx-internal-delay-ps",
>>> + &dp83869->tx_id_delay);
>>> + if (ret) {
>>> + dp83869->tx_id_delay =
>>> + dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
>>> + ret = 0;
>>> + }
>> It is still not clear to me why is not the parsing being done by the PHY
>> library helper directly?
>
> Why would we do that for these properties and not any other?
Those properties have a standard name, which makes them suitable for
parsing by the core PHY library.
>
> Unless there is a new precedence being set here by having the PHY
> framework do all the dt node parsing for common properties.
You could parse the vendor properties through the driver, let the PHY
library parse the standard properties, and resolve any ordering
precedence within the driver. In general, I would favor standard
properties over vendor properties.
Does this help?
--
Florian
^ permalink raw reply
* Re: [PATCH 07/10] spi: spi-dw-mchp: Add Sparx5 support
From: Serge Semin @ 2020-06-02 23:22 UTC (permalink / raw)
To: Lars Povlsen
Cc: Serge Semin, Mark Brown, SoC Team, devicetree, Alexandre Belloni,
linux-kernel, linux-spi, Microchip Linux Driver Support,
linux-arm-kernel
In-Reply-To: <20200513140031.25633-8-lars.povlsen@microchip.com>
On Wed, May 13, 2020 at 04:00:28PM +0200, Lars Povlsen wrote:
> This adds support for the Sparx5 SoC in the spi-dw-mchp SPI controller.
>
> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
> ---
> drivers/spi/spi-dw-mchp.c | 211 ++++++++++++++++++++++++++++++++++----
> 1 file changed, 189 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/spi/spi-dw-mchp.c b/drivers/spi/spi-dw-mchp.c
> index 0828a7616d9ab..3abdd44a550ea 100644
> --- a/drivers/spi/spi-dw-mchp.c
> +++ b/drivers/spi/spi-dw-mchp.c
> @@ -28,21 +28,22 @@
>
> #define MAX_CS 4
>
> -#define MSCC_CPU_SYSTEM_CTRL_GENERAL_CTRL 0x24
> -#define OCELOT_IF_SI_OWNER_OFFSET 4
> -#define JAGUAR2_IF_SI_OWNER_OFFSET 6
> #define MSCC_IF_SI_OWNER_MASK GENMASK(1, 0)
> #define MSCC_IF_SI_OWNER_SISL 0
> #define MSCC_IF_SI_OWNER_SIBM 1
> #define MSCC_IF_SI_OWNER_SIMC 2
>
> #define MSCC_SPI_MST_SW_MODE 0x14
> -#define MSCC_SPI_MST_SW_MODE_SW_PIN_CTRL_MODE BIT(13)
> -#define MSCC_SPI_MST_SW_MODE_SW_SPI_CS(x) (x << 5)
>
> struct dw_spi_mchp_props {
> const char *syscon_name;
> - u32 si_owner_bit;
> + u32 general_ctrl_off;
> + u32 si_owner_bit, si_owner2_bit;
> + u32 pinctrl_bit_off;
> + u32 cs_bit_off;
> + u32 ss_force_ena_off;
> + u32 ss_force_val_off;
> + u32 bootmaster_cs;
> };
>
> struct dw_spi_mchp {
> @@ -53,44 +54,176 @@ struct dw_spi_mchp {
> void __iomem *spi_mst;
> const struct dw_spi_mchp_props *props;
> u32 gen_owner;
> + u32 if2mask;
> };
>
> static const struct dw_spi_mchp_props dw_spi_mchp_props_ocelot = {
> .syscon_name = "mscc,ocelot-cpu-syscon",
> + .general_ctrl_off = 0x24,
> .si_owner_bit = 4,
> + .pinctrl_bit_off = 13,
> + .cs_bit_off = 5,
> + .bootmaster_cs = 0,
> };
>
> static const struct dw_spi_mchp_props dw_spi_mchp_props_jaguar2 = {
> .syscon_name = "mscc,ocelot-cpu-syscon",
> + .general_ctrl_off = 0x24,
> .si_owner_bit = 6,
> + .pinctrl_bit_off = 13,
> + .cs_bit_off = 5,
> + .bootmaster_cs = 0,
> +};
> +
> +static const struct dw_spi_mchp_props dw_spi_mchp_props_sparx5 = {
> + .syscon_name = "microchip,sparx5-cpu-syscon",
> + .general_ctrl_off = 0x88,
> + .si_owner_bit = 6,
> + .si_owner2_bit = 4,
> + .ss_force_ena_off = 0xa4,
> + .ss_force_val_off = 0xa8,
> + .bootmaster_cs = 0,
> };
>
> /*
> - * The Designware SPI controller (referred to as master in the documentation)
> - * automatically deasserts chip select when the tx fifo is empty. The chip
> - * selects then needs to be either driven as GPIOs or, for the first 4 using the
> - * the SPI boot controller registers. the final chip select is an OR gate
> - * between the Designware SPI controller and the SPI boot controller.
> + * Set the owner of the SPI interface
> */
> -static void dw_spi_mchp_set_cs(struct spi_device *spi, bool enable)
> +static void dw_spi_mchp_set_owner(struct dw_spi_mchp *dwsmchp,
> + const struct dw_spi_mchp_props *props,
> + u8 owner, u8 owner2)
> +{
> + u32 val, msk;
> +
> + val = (owner << props->si_owner_bit);
> + msk = (MSCC_IF_SI_OWNER_MASK << props->si_owner_bit);
> + if (props->si_owner2_bit) {
> + val |= owner2 << props->si_owner2_bit;
> + msk |= (MSCC_IF_SI_OWNER_MASK << props->si_owner2_bit);
> + }
> + if (dwsmchp->gen_owner != val) {
> + regmap_update_bits(dwsmchp->syscon, props->general_ctrl_off,
> + msk, val);
> + dwsmchp->gen_owner = val;
> + }
> +}
> +
> +static void dw_spi_mchp_set_cs_owner(struct dw_spi_mchp *dwsmchp,
> + const struct dw_spi_mchp_props *props,
> + u8 cs, u8 owner)
> {
> + u8 dummy = (owner == MSCC_IF_SI_OWNER_SIBM ?
> + MSCC_IF_SI_OWNER_SIMC : MSCC_IF_SI_OWNER_SIBM);
> + if (props->si_owner2_bit && (dwsmchp->if2mask & BIT(cs))) {
> + /* SPI2 */
> + dw_spi_mchp_set_owner(dwsmchp, props, dummy, owner);
> + } else {
> + /* SPI1 */
> + dw_spi_mchp_set_owner(dwsmchp, props, owner, dummy);
> + }
> +}
> +
> +/*
> + * The Designware SPI controller (referred to as master in the
> + * documentation) automatically deasserts chip select when the tx fifo
> + * is empty. The chip selects then needs to be either driven as GPIOs
> + * or, for the first 4 using the the SPI boot controller
> + * registers. the final chip select is an OR gate between the
> + * Designware SPI controller and the SPI boot controller. nselect is
> + * an active low signal
> + */
> +static void dw_spi_mchp_set_cs(struct spi_device *spi, bool nEnable)
> +{
> + bool enable = !nEnable; /* This keeps changing in the API... */
> struct dw_spi *dws = spi_master_get_devdata(spi->master);
> struct dw_spi_mchp *dwsmchp = container_of(dws, struct dw_spi_mchp,
> dws);
> - u32 cs = spi->chip_select;
> + const struct dw_spi_mchp_props *props = dwsmchp->props;
> + u8 cs = spi->chip_select;
>
> - if (cs < 4) {
> - u32 sw_mode = MSCC_SPI_MST_SW_MODE_SW_PIN_CTRL_MODE;
> + if (enable)
> + dw_spi_mchp_set_cs_owner(dwsmchp, props, cs,
> + MSCC_IF_SI_OWNER_SIMC);
>
> - if (!enable)
> - sw_mode |= MSCC_SPI_MST_SW_MODE_SW_SPI_CS(BIT(cs));
> + if (dwsmchp->spi_mst && (cs < MAX_CS)) {
> + u32 sw_mode;
>
> + if (enable)
> + sw_mode = BIT(props->pinctrl_bit_off) |
> + (BIT(cs) << props->cs_bit_off);
> + else
> + sw_mode = 0;
> writel(sw_mode, dwsmchp->spi_mst + MSCC_SPI_MST_SW_MODE);
> + } else if (props->ss_force_ena_off) {
> + if (enable) {
> + /* Ensure CS toggles, so start off all disabled */
> + regmap_write(dwsmchp->syscon, props->ss_force_val_off,
> + ~0);
> + /* CS override drive enable */
> + regmap_write(dwsmchp->syscon, props->ss_force_ena_off,
> + 1);
> + /* Allow settle */
> + udelay(1);
> + /* Now set CSx enabled */
> + regmap_write(dwsmchp->syscon, props->ss_force_val_off,
> + ~BIT(cs));
> + } else {
> + /* CS value */
> + regmap_write(dwsmchp->syscon, props->ss_force_val_off,
> + ~0);
> + /* CS override drive disable */
> + regmap_write(dwsmchp->syscon, props->ss_force_ena_off,
> + 0);
> + }
> }
>
> - dw_spi_set_cs(spi, enable);
> + dw_spi_set_cs(spi, nEnable);
> +}
> +
> +static int dw_mchp_bootmaster_exec_mem_op(struct spi_mem *mem,
> + const struct spi_mem_op *op)
> +{
> + struct spi_device *spi = mem->spi;
> + int ret = -ENOTSUPP;
> +
> + /* Only reads, addrsize 1..4 */
> + if (!op->data.nbytes || !op->addr.nbytes || op->addr.nbytes > 4 ||
> + op->data.dir != SPI_MEM_DATA_IN)
> + return ret;
> +
> + /* Only handle (normal+fast) 3/4 bytes read */
> + if (op->cmd.opcode != SPINOR_OP_READ &&
> + op->cmd.opcode != SPINOR_OP_READ_FAST &&
> + op->cmd.opcode != SPINOR_OP_READ_4B &&
> + op->cmd.opcode != SPINOR_OP_READ_FAST_4B)
> + return ret;
Hm, this part most like belongs to supports_op() callback.
> +
> + /* CS0..3, only 16M reach */
> + if ((spi->chip_select < MAX_CS) &&
> + (op->addr.val + op->data.nbytes) < SZ_16M) {
The driver shouldn't return a failure if more than available data requested.
Just return the length the driver managed to read.
> + struct dw_spi *dws = spi_master_get_devdata(spi->master);
> + struct dw_spi_mchp *dwsmchp = container_of(dws,
> + struct dw_spi_mchp,
> + dws);
> + const struct dw_spi_mchp_props *props = dwsmchp->props;
> + u8 __iomem *src = dwsmchp->read_map +
> + (spi->chip_select * SZ_16M) + op->addr.val;
> +
> + if (props->bootmaster_cs != spi->chip_select)
> + return ret;
> +
> + /* Make boot master owner of SI interface */
> + dw_spi_mchp_set_cs_owner(dwsmchp, props, spi->chip_select,
> + MSCC_IF_SI_OWNER_SIBM);
> + memcpy(op->data.buf.in, src, op->data.nbytes);
So after all it's just memcpy from the directly mapped SPI-flash memory, right?
Then it's not mem_op, but I supposed it should be implemented by means of the
dirmap_{create,read,destroy}.
-Sergey
> + ret = op->data.nbytes;
> + }
> + return ret;
> }
>
> +static const struct spi_controller_mem_ops dw_mchp_bootmaster_mem_ops = {
> + .exec_op = dw_mchp_bootmaster_exec_mem_op,
> +};
> +
> static int dw_spi_mchp_init(struct platform_device *pdev,
> struct dw_spi *dws,
> struct dw_spi_mchp *dwsmchp,
> @@ -107,6 +240,18 @@ static int dw_spi_mchp_init(struct platform_device *pdev,
> }
> }
>
> + /* See if we have a direct read window */
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
> + if (res && resource_size(res) >= (SZ_16M*MAX_CS)) {
> + void __iomem *ptr = devm_ioremap_resource(&pdev->dev, res);
> +
> + if (!IS_ERR(ptr)) {
> + dwsmchp->read_map = ptr;
> + dws->mem_ops = &dw_mchp_bootmaster_mem_ops;
> + dev_info(&pdev->dev, "Enabling fast memory operations\n");
> + }
> + }
> +
> dwsmchp->syscon =
> syscon_regmap_lookup_by_compatible(props->syscon_name);
> if (IS_ERR(dwsmchp->syscon)) {
> @@ -119,10 +264,9 @@ static int dw_spi_mchp_init(struct platform_device *pdev,
> if (dwsmchp->spi_mst)
> writel(0, dwsmchp->spi_mst + MSCC_SPI_MST_SW_MODE);
>
> - /* Select the owner of the SI interface */
> - regmap_update_bits(dwsmchp->syscon, MSCC_CPU_SYSTEM_CTRL_GENERAL_CTRL,
> - MSCC_IF_SI_OWNER_MASK << props->si_owner_bit,
> - MSCC_IF_SI_OWNER_SIMC << props->si_owner_bit);
> + /* SPI2 mapping bitmask */
> + device_property_read_u32(&pdev->dev, "interface-mapping-mask",
> + &dwsmchp->if2mask);
>
> dwsmchp->dws.set_cs = dw_spi_mchp_set_cs;
>
> @@ -180,6 +324,27 @@ static int dw_spi_mchp_probe(struct platform_device *pdev)
> dws->rx_sample_dly = DIV_ROUND_UP(rx_sample_dly,
> (dws->max_freq / 1000000));
>
> + if (pdev->dev.of_node) {
> + int i;
> +
> + for (i = 0; i < dws->num_cs; i++) {
> + int cs_gpio = of_get_named_gpio(pdev->dev.of_node,
> + "cs-gpios", i);
> +
> + if (cs_gpio == -EPROBE_DEFER) {
> + ret = cs_gpio;
> + goto out;
> + }
> +
> + if (gpio_is_valid(cs_gpio)) {
> + ret = devm_gpio_request(&pdev->dev, cs_gpio,
> + dev_name(&pdev->dev));
> + if (ret)
> + goto out;
> + }
> + }
> + }
> +
> props = device_get_match_data(&pdev->dev);
> if (props)
> ret = dw_spi_mchp_init(pdev, dws, dwsmchp, props);
> @@ -213,6 +378,8 @@ static int dw_spi_mchp_remove(struct platform_device *pdev)
> static const struct of_device_id dw_spi_mchp_of_match[] = {
> { .compatible = "mscc,ocelot-spi", .data = &dw_spi_mchp_props_ocelot},
> { .compatible = "mscc,jaguar2-spi", .data = &dw_spi_mchp_props_jaguar2},
> + { .compatible = "microchip,sparx5-spi",
> + .data = &dw_spi_mchp_props_sparx5},
> { /* end of table */}
> };
> MODULE_DEVICE_TABLE(of, dw_spi_mchp_of_match);
> --
> 2.26.2
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: rectify entry in ARM SMC WATCHDOG DRIVER
From: Evan Benn @ 2020-06-02 23:22 UTC (permalink / raw)
To: Julius Werner
Cc: Guenter Roeck, Lukas Bulwahn, Wim Van Sebroeck, LINUX-WATCHDOG,
Rob Herring, devicetree, Joe Perches, kernel-janitors, LKML
In-Reply-To: <CAODwPW_oxDxF_5-icRs0eaRVLgtP+bDc_OSKa=EcfeSp=c6Fag@mail.gmail.com>
Apologies for that slip up.
Reviewed-by: Evan Benn <evanbenn@chromium.org>
On Wed, Jun 3, 2020 at 6:16 AM Julius Werner <jwerner@chromium.org> wrote:
>
> Reviewed-by: Julius Werner <jwerner@chromium.org>
^ permalink raw reply
* Re: [PATCH net-next v5 4/4] net: dp83869: Add RGMII internal delay configuration
From: Dan Murphy @ 2020-06-02 23:25 UTC (permalink / raw)
To: Florian Fainelli, andrew, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree
In-Reply-To: <f92f70b2-6e42-5bdb-187d-ecd8533b06a6@ti.com>
Florian
On 6/2/20 6:18 PM, Dan Murphy wrote:
> Florian
>
> On 6/2/20 6:13 PM, Florian Fainelli wrote:
>>
>> On 6/2/2020 4:10 PM, Dan Murphy wrote:
>>> Florian
>>>
>>> On 6/2/20 5:33 PM, Florian Fainelli wrote:
>>>> On 6/2/2020 9:45 AM, Dan Murphy wrote:
>>>>> Add RGMII internal delay configuration for Rx and Tx.
>>>>>
>>>>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>>>>> ---
>>>> [snip]
>>>>
>>>>> +
>>>>> enum {
>>>>> DP83869_PORT_MIRRORING_KEEP,
>>>>> DP83869_PORT_MIRRORING_EN,
>>>>> @@ -108,6 +113,8 @@ enum {
>>>>> struct dp83869_private {
>>>>> int tx_fifo_depth;
>>>>> int rx_fifo_depth;
>>>>> + s32 rx_id_delay;
>>>>> + s32 tx_id_delay;
>>>>> int io_impedance;
>>>>> int port_mirroring;
>>>>> bool rxctrl_strap_quirk;
>>>>> @@ -232,6 +239,22 @@ static int dp83869_of_init(struct phy_device
>>>>> *phydev)
>>>>> &dp83869->tx_fifo_depth))
>>>>> dp83869->tx_fifo_depth = DP83869_PHYCR_FIFO_DEPTH_4_B_NIB;
>>>>> + ret = of_property_read_u32(of_node, "rx-internal-delay-ps",
>>>>> + &dp83869->rx_id_delay);
>>>>> + if (ret) {
>>>>> + dp83869->rx_id_delay =
>>>>> + dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
>>>>> + ret = 0;
>>>>> + }
>>>>> +
>>>>> + ret = of_property_read_u32(of_node, "tx-internal-delay-ps",
>>>>> + &dp83869->tx_id_delay);
>>>>> + if (ret) {
>>>>> + dp83869->tx_id_delay =
>>>>> + dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
>>>>> + ret = 0;
>>>>> + }
>>>> It is still not clear to me why is not the parsing being done by
>>>> the PHY
>>>> library helper directly?
>>> Why would we do that for these properties and not any other?
>> Those properties have a standard name, which makes them suitable for
>> parsing by the core PHY library.
>>> Unless there is a new precedence being set here by having the PHY
>>> framework do all the dt node parsing for common properties.
>> You could parse the vendor properties through the driver, let the PHY
>> library parse the standard properties, and resolve any ordering
>> precedence within the driver. In general, I would favor standard
>> properties over vendor properties.
>>
>> Does this help?
>
> Ok so new precedence then.
>
> Because there are common properties like tx-fifo-depth, rx-fifo-depth,
> enet-phy-lane-swap and max_speed that the PHY framework should parse
> as well.
>
I am assuming that the retrieval of the property and getting the index
should be 2 separate APIs?
One API to get the property value and one API to find the index value.
Dan
> Dan
>
^ permalink raw reply
* Re: [PATCH net-next v5 4/4] net: dp83869: Add RGMII internal delay configuration
From: Dan Murphy @ 2020-06-02 23:18 UTC (permalink / raw)
To: Florian Fainelli, andrew, hkallweit1, davem, robh
Cc: netdev, linux-kernel, devicetree
In-Reply-To: <6981527b-f155-a46b-574a-2e6621589ca4@gmail.com>
Florian
On 6/2/20 6:13 PM, Florian Fainelli wrote:
>
> On 6/2/2020 4:10 PM, Dan Murphy wrote:
>> Florian
>>
>> On 6/2/20 5:33 PM, Florian Fainelli wrote:
>>> On 6/2/2020 9:45 AM, Dan Murphy wrote:
>>>> Add RGMII internal delay configuration for Rx and Tx.
>>>>
>>>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>>>> ---
>>> [snip]
>>>
>>>> +
>>>> enum {
>>>> DP83869_PORT_MIRRORING_KEEP,
>>>> DP83869_PORT_MIRRORING_EN,
>>>> @@ -108,6 +113,8 @@ enum {
>>>> struct dp83869_private {
>>>> int tx_fifo_depth;
>>>> int rx_fifo_depth;
>>>> + s32 rx_id_delay;
>>>> + s32 tx_id_delay;
>>>> int io_impedance;
>>>> int port_mirroring;
>>>> bool rxctrl_strap_quirk;
>>>> @@ -232,6 +239,22 @@ static int dp83869_of_init(struct phy_device
>>>> *phydev)
>>>> &dp83869->tx_fifo_depth))
>>>> dp83869->tx_fifo_depth = DP83869_PHYCR_FIFO_DEPTH_4_B_NIB;
>>>> + ret = of_property_read_u32(of_node, "rx-internal-delay-ps",
>>>> + &dp83869->rx_id_delay);
>>>> + if (ret) {
>>>> + dp83869->rx_id_delay =
>>>> + dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
>>>> + ret = 0;
>>>> + }
>>>> +
>>>> + ret = of_property_read_u32(of_node, "tx-internal-delay-ps",
>>>> + &dp83869->tx_id_delay);
>>>> + if (ret) {
>>>> + dp83869->tx_id_delay =
>>>> + dp83869_internal_delay[DP83869_CLK_DELAY_DEF];
>>>> + ret = 0;
>>>> + }
>>> It is still not clear to me why is not the parsing being done by the PHY
>>> library helper directly?
>> Why would we do that for these properties and not any other?
> Those properties have a standard name, which makes them suitable for
> parsing by the core PHY library.
>> Unless there is a new precedence being set here by having the PHY
>> framework do all the dt node parsing for common properties.
> You could parse the vendor properties through the driver, let the PHY
> library parse the standard properties, and resolve any ordering
> precedence within the driver. In general, I would favor standard
> properties over vendor properties.
>
> Does this help?
Ok so new precedence then.
Because there are common properties like tx-fifo-depth, rx-fifo-depth,
enet-phy-lane-swap and max_speed that the PHY framework should parse as
well.
Dan
^ permalink raw reply
* Re: [PATCH 1/4] drivers: clk: qcom: Add msm8992 GCC driver
From: Bryan O'Donoghue @ 2020-06-02 23:33 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Andy Gross, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Philipp Zabel, linux-arm-msm, linux-clk, devicetree,
linux-kernel
In-Reply-To: <20200531174612.260113-2-konradybcio@gmail.com>
On 31/05/2020 18:46, Konrad Dybcio wrote:
> +static struct clk_fixed_factor xo = {
> + .mult = 1,
> + .div = 1,
> + .hw.init = &(struct clk_init_data)
> + {
> + .name = "xo",
> + .parent_names = (const char *[]) { "xo_board" },
> + .num_parents = 1,
> + .ops = &clk_fixed_factor_ops,
> + },
> +};
I think you can drop that, and use the DTS definition.
xo_board: xo_board {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <19200000>;
};
sleep_clk: sleep_clk {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <32768>;
};
clock_gcc: clock-controller@fc400000 {
compatible = "qcom,gcc-msm8994";
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
reg = <0xfc400000 0x2000>;
+ clock-names = "xo",
+ "sleep_clk";
+ clocks = <&xo_board>,
+ <&sleep_clk>;
};
> +static int gcc_msm8992_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct clk *clk;
> +
> + clk = devm_clk_register(dev, &xo.hw);
> + if (IS_ERR(clk))
> + return PTR_ERR(clk);
You should drop this too.
> +MODULE_ALIAS("platform:gcc-msm8992");
and that.
---
bod
^ permalink raw reply
* Re: [PATCH 00/10] spi: Adding support for Microchip Sparx5 SoC
From: Serge Semin @ 2020-06-02 23:44 UTC (permalink / raw)
To: Lars Povlsen
Cc: Serge Semin, Mark Brown, SoC Team, devicetree, linux-kernel,
linux-spi, Microchip Linux Driver Support, linux-arm-kernel
In-Reply-To: <87img9q3sb.fsf@soft-dev15.microsemi.net>
On Tue, Jun 02, 2020 at 10:18:28AM +0200, Lars Povlsen wrote:
>
> Serge Semin writes:
>
> > Hello Lars,
> >
> > On Wed, May 13, 2020 at 04:00:21PM +0200, Lars Povlsen wrote:
> >> This is an add-on series to the main SoC Sparx5 series
> >> (Message-ID: <20200513125532.24585-1-lars.povlsen@microchip.com>).
> >>
> >> The series add support for Sparx5 on top of the existing
> >> ocelot/jaguar2 spi driver.
> >>
> >> It spins off the existing support for the MSCC platforms into a
> >> separate driver, as adding new platforms from the MSCC/Microchip
> >> product lines will further complicate (clutter) the original driver.
> >>
> >> New YAML dt-bindings are provided for the resulting driver.
> >>
> >> It is expected that the DT patches are to be taken directly by the arm-soc
> >> maintainers.
> >
> > Regarding our cooperation. It can be implemented as follows. Since your patchset
> > is less cumbersome than mine and is more ready to be integrated into the generic DW
> > APB SSI code, it would be better to first make it through Mark', Andy' and my reviews
> > to be further merged into the kernel version of the driver. After that I'll have
> > my code altered so it could be applied on top of your patches. When everything
> > is done we'll have a more comprehensive DW APB SSI driver with poll-based
> > PIO operations support, new features like rx-delay, etc.
> >
>
> Hi Serge!
>
> I think I would be able to work on the SPI patches this week. Should I
> base it on the current spi-next or 5.7? Then address the comments and
> send out a new revision?
Finally I've done a part of review. It must be enough for v2. As Mark said the
new version is supposed to be based on the spi-next, since that branch's got
all recent DW APB SSI patches applied.
-Sergey
>
> Thanks for reaching out.
>
> ---Lars
>
> > Thank you one more time for the series you've shared with us. Let's see what can
> > be done to improve it...
> >
> > -Sergey
> >
> >>
> >> Lars Povlsen (10):
> >> spi: dw: Add support for polled operation via no IRQ specified in DT
> >> spi: dw: Add support for RX sample delay register
> >> spi: dw: Add support for client driver memory operations
> >> dt-bindings: spi: Add bindings for spi-dw-mchp
> >> spi: spi-dw-mmio: Spin off MSCC platforms into spi-dw-mchp
> >> dt-bindings: spi: spi-dw-mchp: Add Sparx5 support
> >> spi: spi-dw-mchp: Add Sparx5 support
> >> arm64: dts: sparx5: Add SPI controller
> >> arm64: dts: sparx5: Add spi-nor support
> >> arm64: dts: sparx5: Add spi-nand devices
> >>
> >> .../bindings/spi/mscc,ocelot-spi.yaml | 89 ++++
> >> .../bindings/spi/snps,dw-apb-ssi.txt | 7 +-
> >> MAINTAINERS | 2 +
> >> arch/arm64/boot/dts/microchip/sparx5.dtsi | 37 ++
> >> .../boot/dts/microchip/sparx5_pcb125.dts | 16 +
> >> .../boot/dts/microchip/sparx5_pcb134.dts | 22 +
> >> .../dts/microchip/sparx5_pcb134_board.dtsi | 9 +
> >> .../boot/dts/microchip/sparx5_pcb135.dts | 23 +
> >> .../dts/microchip/sparx5_pcb135_board.dtsi | 9 +
> >> arch/mips/configs/generic/board-ocelot.config | 2 +-
> >> drivers/spi/Kconfig | 7 +
> >> drivers/spi/Makefile | 1 +
> >> drivers/spi/spi-dw-mchp.c | 399 ++++++++++++++++++
> >> drivers/spi/spi-dw-mmio.c | 93 ----
> >> drivers/spi/spi-dw.c | 31 +-
> >> drivers/spi/spi-dw.h | 4 +
> >> 16 files changed, 644 insertions(+), 107 deletions(-)
> >> create mode 100644 Documentation/devicetree/bindings/spi/mscc,ocelot-spi.yaml
> >> create mode 100644 drivers/spi/spi-dw-mchp.c
> >>
> >> --
> >> 2.26.2
> >>
> >> _______________________________________________
> >> linux-arm-kernel mailing list
> >> linux-arm-kernel@lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> --
> Lars Povlsen,
> Microchip
^ permalink raw reply
* Re: [PATCH v8 04/10] drm: bridge: dw_mipi_dsi: allow bridge daisy chaining
From: Laurent Pinchart @ 2020-06-02 23:51 UTC (permalink / raw)
To: Adrian Ratiu
Cc: linux-arm-kernel, devicetree, linux-rockchip, Andrzej Hajda,
Jonas Karlman, Jernej Skrabec, Heiko Stuebner, linux-kernel,
dri-devel, linux-imx, kernel, linux-stm32
In-Reply-To: <20200427081952.3536741-5-adrian.ratiu@collabora.com>
Hi Adrian,
Thank you for the patch.
On Mon, Apr 27, 2020 at 11:19:46AM +0300, Adrian Ratiu wrote:
> Up until now the assumption was that the synopsis dsi bridge will
> directly connect to an encoder provided by the platform driver, but
> the current practice for drivers is to leave the encoder empty via
> the simple encoder API and add their logic to their own drm_bridge.
>
> Thus we need an ablility to connect the DSI bridge to another bridge
> provided by the platform driver, so we extend the dw_mipi_dsi bind()
> API with a new "previous bridge" arg instead of just hardcoding NULL.
>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
> ---
> New in v8.
> ---
> drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 6 ++++--
> drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 2 +-
> include/drm/bridge/dw_mipi_dsi.h | 5 ++++-
> 3 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index 16fd87055e7b7..140ff40fa1b62 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -1456,11 +1456,13 @@ EXPORT_SYMBOL_GPL(dw_mipi_dsi_remove);
> /*
> * Bind/unbind API, used from platforms based on the component framework.
> */
> -int dw_mipi_dsi_bind(struct dw_mipi_dsi *dsi, struct drm_encoder *encoder)
> +int dw_mipi_dsi_bind(struct dw_mipi_dsi *dsi,
> + struct drm_encoder *encoder,
> + struct drm_bridge *prev_bridge)
> {
> int ret;
>
> - ret = drm_bridge_attach(encoder, &dsi->bridge, NULL, 0);
> + ret = drm_bridge_attach(encoder, &dsi->bridge, prev_bridge, 0);
Please note that chaining of bridges doesn't work well if multiple
bridges in the chain try to create a connector. This is why a
DRM_BRIDGE_ATTACH_NO_CONNECTOR flag has been added, with a helper to
create a connector for a chain of bridges (drm_bridge_connector_init()).
This won't play well with the component framework. I would recommend
using the of_drm_find_bridge() instead in the rockchip driver, and
deprecating dw_mipi_dsi_bind().
> if (ret) {
> DRM_ERROR("Failed to initialize bridge with drm\n");
> return ret;
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> index 3feff0c45b3f7..83ef43be78135 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
> @@ -929,7 +929,7 @@ static int dw_mipi_dsi_rockchip_bind(struct device *dev,
> return ret;
> }
>
> - ret = dw_mipi_dsi_bind(dsi->dmd, &dsi->encoder);
> + ret = dw_mipi_dsi_bind(dsi->dmd, &dsi->encoder, NULL);
> if (ret) {
> DRM_DEV_ERROR(dev, "Failed to bind: %d\n", ret);
> return ret;
> diff --git a/include/drm/bridge/dw_mipi_dsi.h b/include/drm/bridge/dw_mipi_dsi.h
> index b0e390b3288e8..699b3531f5b36 100644
> --- a/include/drm/bridge/dw_mipi_dsi.h
> +++ b/include/drm/bridge/dw_mipi_dsi.h
> @@ -14,6 +14,7 @@
> #include <drm/drm_modes.h>
>
> struct drm_display_mode;
> +struct drm_bridge;
> struct drm_encoder;
> struct dw_mipi_dsi;
> struct mipi_dsi_device;
> @@ -62,7 +63,9 @@ struct dw_mipi_dsi *dw_mipi_dsi_probe(struct platform_device *pdev,
> const struct dw_mipi_dsi_plat_data
> *plat_data);
> void dw_mipi_dsi_remove(struct dw_mipi_dsi *dsi);
> -int dw_mipi_dsi_bind(struct dw_mipi_dsi *dsi, struct drm_encoder *encoder);
> +int dw_mipi_dsi_bind(struct dw_mipi_dsi *dsi,
> + struct drm_encoder *encoder,
> + struct drm_bridge *prev_bridge);
> void dw_mipi_dsi_unbind(struct dw_mipi_dsi *dsi);
> void dw_mipi_dsi_set_slave(struct dw_mipi_dsi *dsi, struct dw_mipi_dsi *slave);
>
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v3 3/4] ARM: dts: stm32: make hdmi-transmitter node compliant with DT bindings
From: Laurent Pinchart @ 2020-06-02 23:55 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: kernel, devicetree, linux-arm-kernel, robh+dt, xuwei5,
michal.simek, mcoquelin.stm32, marex
In-Reply-To: <20200601063308.13045-4-ricardo.canuelo@collabora.com>
Hi Ricardo,
Thank you for the patch.
On Mon, Jun 01, 2020 at 08:33:07AM +0200, Ricardo Cañuelo wrote:
> Reorder the I2C slave addresses of the hdmi-transmitter node and remove
> the adi,input-style and adi,input-justification properties to meet the
> adi,adv7513 binding requirements.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
> index 930202742a3f..b67a21a8698a 100644
> --- a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
> +++ b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
> @@ -185,8 +185,8 @@
> &i2c4 {
> hdmi-transmitter@3d {
> compatible = "adi,adv7513";
> - reg = <0x3d>, <0x2d>, <0x4d>, <0x5d>;
> - reg-names = "main", "cec", "edid", "packet";
> + reg = <0x3d>, <0x4d>, <0x2d> , <0x5d>;
> + reg-names = "main", "edid", "cec", "packet";
> clocks = <&cec_clock>;
> clock-names = "cec";
>
> @@ -204,8 +204,6 @@
> adi,input-depth = <8>;
> adi,input-colorspace = "rgb";
> adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
>
> ports {
> #address-cells = <1>;
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v3 6/6] MAINTAINERS: Add maintainers for MIPS core drivers
From: Serge Semin @ 2020-06-03 0:03 UTC (permalink / raw)
To: Marc Zyngier
Cc: Serge Semin, Thomas Bogendoerfer, Thomas Gleixner,
Greg Kroah-Hartman, Alexey Malahov, Paul Burton, Rob Herring,
Arnd Bergmann, Jason Cooper, Rafael J. Wysocki, Daniel Lezcano,
James Hogan, linux-mips, devicetree, linux-kernel
In-Reply-To: <61afd4bd10ac644fa623e218f947328e@kernel.org>
On Tue, Jun 02, 2020 at 11:12:31AM +0100, Marc Zyngier wrote:
> On 2020-06-02 11:09, Serge Semin wrote:
> > Add Thomas and myself as maintainers of the MIPS CPU and GIC IRQchip,
> > MIPS
> > GIC timer and MIPS CPS CPUidle drivers.
> >
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> >
> > ---
> >
> > Changelog v3:
> > - Keep the files list alphabetically ordered.
> > - Add Thomas as the co-maintainer of the designated drivers.
> > ---
> > MAINTAINERS | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 2926327e4976..20532e0287d7 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -11278,6 +11278,17 @@
> > F: arch/mips/configs/generic/board-boston.config
> > F: drivers/clk/imgtec/clk-boston.c
> > F: include/dt-bindings/clock/boston-clock.h
> >
> > +MIPS CORE DRIVERS
> > +M: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> > +M: Serge Semin <fancer.lancer@gmail.com>
> > +L: linux-mips@vger.kernel.org
> > +S: Supported
> > +F: drivers/bus/mips_cdmm.c
> > +F: drivers/clocksource/mips-gic-timer.c
> > +F: drivers/cpuidle/cpuidle-cps.c
> > +F: drivers/irqchip/irq-mips-cpu.c
> > +F: drivers/irqchip/irq-mips-gic.c
> > +
> > MIPS GENERIC PLATFORM
> > M: Paul Burton <paulburton@kernel.org>
> > L: linux-mips@vger.kernel.org
>
> Acked-by: Marc Zyngier <maz@kernel.org>
>
> I assume this will go via the MIPS tree.
Yes, I also think so. Though I suppose first we have to get acks from
Rafael J. Wysocki (CPU IDLE) or Daniel Lezcano (CPU IDLE,
CLOCKSOURCE/CLOCKEVENT) or Thomas Gleixner (CLOCKSOURCE, CLOCKEVENT)
since we are going to maintain the drivers from the subsystems they
support. Am I right?
-Sergey
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [PATCH v3 4/4] dt-bindings: drm: bridge: adi,adv7511.txt: convert to yaml
From: Laurent Pinchart @ 2020-06-03 0:03 UTC (permalink / raw)
To: Ricardo Cañuelo
Cc: kernel, devicetree, linux-arm-kernel, robh+dt, xuwei5,
michal.simek, mcoquelin.stm32, marex
In-Reply-To: <20200601063308.13045-5-ricardo.canuelo@collabora.com>
Hi Ricardo,
Thank you for the patch.
On Mon, Jun 01, 2020 at 08:33:08AM +0200, Ricardo Cañuelo wrote:
> Convert the ADV7511/11w/13/33/35 DT bindings to json-schema. The
> original binding has been split into two files: adi,adv7511.yaml for
> ADV7511/11W/13 and adi,adv7533.yaml for ADV7533/35.
>
> Signed-off-by: Ricardo Cañuelo <ricardo.canuelo@collabora.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Great work :-)
> ---
> .../bindings/display/bridge/adi,adv7511.txt | 143 -----------
> .../bindings/display/bridge/adi,adv7511.yaml | 231 ++++++++++++++++++
> .../bindings/display/bridge/adi,adv7533.yaml | 175 +++++++++++++
> 3 files changed, 406 insertions(+), 143 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> create mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
> create mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> deleted file mode 100644
> index 659523f538bf..000000000000
> --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
> +++ /dev/null
> @@ -1,143 +0,0 @@
> -Analog Devices ADV7511(W)/13/33/35 HDMI Encoders
> -------------------------------------------------
> -
> -The ADV7511, ADV7511W, ADV7513, ADV7533 and ADV7535 are HDMI audio and video
> -transmitters compatible with HDMI 1.4 and DVI 1.0. They support color space
> -conversion, S/PDIF, CEC and HDCP. ADV7533/5 supports the DSI interface for input
> -pixels, while the others support RGB interface.
> -
> -Required properties:
> -
> -- compatible: Should be one of:
> - "adi,adv7511"
> - "adi,adv7511w"
> - "adi,adv7513"
> - "adi,adv7533"
> - "adi,adv7535"
> -
> -- reg: I2C slave addresses
> - The ADV7511 internal registers are split into four pages exposed through
> - different I2C addresses, creating four register maps. Each map has it own
> - I2C address and acts as a standard slave device on the I2C bus. The main
> - address is mandatory, others are optional and revert to defaults if not
> - specified.
> -
> -
> -The ADV7511 supports a large number of input data formats that differ by their
> -color depth, color format, clock mode, bit justification and random
> -arrangement of components on the data bus. The combination of the following
> -properties describe the input and map directly to the video input tables of the
> -ADV7511 datasheet that document all the supported combinations.
> -
> -- adi,input-depth: Number of bits per color component at the input (8, 10 or
> - 12).
> -- adi,input-colorspace: The input color space, one of "rgb", "yuv422" or
> - "yuv444".
> -- adi,input-clock: The input clock type, one of "1x" (one clock cycle per
> - pixel), "2x" (two clock cycles per pixel), "ddr" (one clock cycle per pixel,
> - data driven on both edges).
> -
> -The following input format properties are required except in "rgb 1x" and
> -"yuv444 1x" modes, in which case they must not be specified.
> -
> -- adi,input-style: The input components arrangement variant (1, 2 or 3), as
> - listed in the input format tables in the datasheet.
> -- adi,input-justification: The input bit justification ("left", "evenly",
> - "right").
> -
> -- avdd-supply: A 1.8V supply that powers up the AVDD pin on the chip.
> -- dvdd-supply: A 1.8V supply that powers up the DVDD pin on the chip.
> -- pvdd-supply: A 1.8V supply that powers up the PVDD pin on the chip.
> -- dvdd-3v-supply: A 3.3V supply that powers up the pin called DVDD_3V
> - on the chip.
> -- bgvdd-supply: A 1.8V supply that powers up the BGVDD pin. This is
> - needed only for ADV7511.
> -
> -The following properties are required for ADV7533 and ADV7535:
> -
> -- adi,dsi-lanes: Number of DSI data lanes connected to the DSI host. It should
> - be one of 1, 2, 3 or 4.
> -- a2vdd-supply: 1.8V supply that powers up the A2VDD pin on the chip.
> -- v3p3-supply: A 3.3V supply that powers up the V3P3 pin on the chip.
> -- v1p2-supply: A supply that powers up the V1P2 pin on the chip. It can be
> - either 1.2V or 1.8V for ADV7533 but only 1.8V for ADV7535.
> -
> -Optional properties:
> -
> -- interrupts: Specifier for the ADV7511 interrupt
> -- pd-gpios: Specifier for the GPIO connected to the power down signal
> -
> -- adi,clock-delay: Video data clock delay relative to the pixel clock, in ps
> - (-1200 ps .. 1600 ps). Defaults to no delay.
> -- adi,embedded-sync: The input uses synchronization signals embedded in the
> - data stream (similar to BT.656). Defaults to separate H/V synchronization
> - signals.
> -- adi,disable-timing-generator: Only for ADV7533 and ADV7535. Disables the
> - internal timing generator. The chip will rely on the sync signals in the
> - DSI data lanes, rather than generate its own timings for HDMI output.
> -- clocks: from common clock binding: reference to the CEC clock.
> -- clock-names: from common clock binding: must be "cec".
> -- reg-names : Names of maps with programmable addresses.
> - It can contain any map needing a non-default address.
> - Possible maps names are : "main", "edid", "cec", "packet"
> -
> -Required nodes:
> -
> -The ADV7511 has two video ports. Their connections are modelled using the OF
> -graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> -
> -- Video port 0 for the RGB, YUV or DSI input. In the case of ADV7533/5, the
> - remote endpoint phandle should be a reference to a valid mipi_dsi_host device
> - node.
> -- Video port 1 for the HDMI output
> -- Audio port 2 for the HDMI audio input
> -
> -
> -Example
> --------
> -
> - adv7511w: hdmi@39 {
> - compatible = "adi,adv7511w";
> - /*
> - * The EDID page will be accessible on address 0x66 on the I2C
> - * bus. All other maps continue to use their default addresses.
> - */
> - reg = <0x39>, <0x66>;
> - reg-names = "main", "edid";
> - interrupt-parent = <&gpio3>;
> - interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
> - clocks = <&cec_clock>;
> - clock-names = "cec";
> -
> - adi,input-depth = <8>;
> - adi,input-colorspace = "rgb";
> - adi,input-clock = "1x";
> - adi,input-style = <1>;
> - adi,input-justification = "evenly";
> -
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - reg = <0>;
> - adv7511w_in: endpoint {
> - remote-endpoint = <&dpi_out>;
> - };
> - };
> -
> - port@1 {
> - reg = <1>;
> - adv7511_out: endpoint {
> - remote-endpoint = <&hdmi_connector_in>;
> - };
> - };
> -
> - port@2 {
> - reg = <2>;
> - codec_endpoint: endpoint {
> - remote-endpoint = <&i2s0_cpu_endpoint>;
> - };
> - };
> - };
> - };
> diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
> new file mode 100644
> index 000000000000..71b344e812dd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
> @@ -0,0 +1,231 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/adi,adv7511.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog Devices ADV7511/11W/13 HDMI Encoders
> +
> +maintainers:
> + - Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> +
> +description: |
> + The ADV7511, ADV7511W and ADV7513 are HDMI audio and video
> + transmitters compatible with HDMI 1.4 and DVI 1.0. They support color
> + space conversion, S/PDIF, CEC and HDCP. The transmitter input is
> + parallel RGB or YUV data.
> +
> +properties:
> + compatible:
> + enum:
> + - adi,adv7511
> + - adi,adv7511w
> + - adi,adv7513
> +
> + reg:
> + description: |
> + I2C slave addresses.
> +
> + The ADV7511/11W/13 internal registers are split into four pages
> + exposed through different I2C addresses, creating four register
> + maps. Each map has it own I2C address and acts as a standard slave
> + device on the I2C bus. The main address is mandatory, others are
> + optional and revert to defaults if not specified.
> + minItems: 1
> + maxItems: 4
> +
> + reg-names:
> + description:
> + Names of maps with programmable addresses. It can contain any map
> + needing a non-default address.
> + minItems: 1
> + items:
> + - const: main
> + - const: edid
> + - const: cec
> + - const: packet
> +
> + clocks:
> + description: Reference to the CEC clock.
> + maxItems: 1
> +
> + clock-names:
> + const: cec
> +
> + interrupts:
> + maxItems: 1
> +
> + pd-gpios:
> + description: GPIO connected to the power down signal.
> + maxItems: 1
> +
> + avdd-supply:
> + description: A 1.8V supply that powers up the AVDD pin.
> +
> + dvdd-supply:
> + description: A 1.8V supply that powers up the DVDD pin.
> +
> + pvdd-supply:
> + description: A 1.8V supply that powers up the PVDD pin.
> +
> + dvdd-3v-supply:
> + description: A 3.3V supply that powers up the DVDD_3V pin.
> +
> + bgvdd-supply:
> + description: A 1.8V supply that powers up the BGVDD pin.
> +
> + adi,input-depth:
> + description: Number of bits per color component at the input.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - enum: [ 8, 10, 12 ]
> +
> + adi,input-colorspace:
> + description: Input color space.
> + enum: [ rgb, yuv422, yuv444 ]
> +
> + adi,input-clock:
> + description: |
> + Input clock type.
> + "1x": one clock cycle per pixel
> + "2x": two clock cycles per pixel
> + "dd": one clock cycle per pixel, data driven on both edges
> + enum: [ 1x, 2x, dd ]
> +
> + adi,clock-delay:
> + description:
> + Video data clock delay relative to the pixel clock, in ps
> + (-1200ps .. 1600 ps).
> + $ref: /schemas/types.yaml#/definitions/uint32
> + default: 0
> +
> + adi,embedded-sync:
> + description:
> + If defined, the input uses synchronization signals embedded in the
> + data stream (similar to BT.656).
> + type: boolean
> +
> + adi,input-style:
> + description:
> + Input components arrangement variant as listed in the input
> + format tables in the datasheet.
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [ 1, 2, 3 ]
> +
> + adi,input-justification:
> + description: Input bit justification.
> + enum: [ left, evenly, right ]
> +
> + ports:
> + description:
> + The ADV7511(W)/13 has two video ports and one audio port. This node
> + models their connections as documented in
> + Documentation/devicetree/bindings/media/video-interfaces.txt
> + Documentation/devicetree/bindings/graph.txt
> + type: object
> + properties:
> + port@0:
> + description: Video port for the RGB or YUV input.
> + type: object
> +
> + port@1:
> + description: Video port for the HDMI output.
> + type: object
> +
> + port@2:
> + description: Audio port for the HDMI output.
> + type: object
> +
> +# adi,input-colorspace and adi,input-clock are required except in
> +# "rgb 1x" and "yuv444 1x" modes, in which case they must not be
> +# specified.
> +if:
> + not:
> + properties:
> + adi,input-colorspace:
> + contains:
> + enum: [ rgb, yuv444 ]
> + adi,input-clock:
> + contains:
> + const: 1x
> +
> +then:
> + required:
> + - adi,input-style
> + - adi,input-justification
> +
> +else:
> + properties:
> + adi,input-style: false
> + adi,input-justification: false
> +
> +
> +required:
> + - compatible
> + - reg
> + - ports
> + - adi,input-depth
> + - adi,input-colorspace
> + - adi,input-clock
> + - avdd-supply
> + - dvdd-supply
> + - pvdd-supply
> + - dvdd-3v-supply
> + - bgvdd-supply
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + adv7511w: hdmi@39 {
> + compatible = "adi,adv7511w";
> + /*
> + * The EDID page will be accessible on address 0x66 on the I2C
> + * bus. All other maps continue to use their default addresses.
> + */
> + reg = <0x39>, <0x66>;
> + reg-names = "main", "edid";
> + interrupt-parent = <&gpio3>;
> + interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
> + clocks = <&cec_clock>;
> + clock-names = "cec";
> + avdd-supply = <&v1v8>;
> + dvdd-supply = <&v1v8>;
> + pvdd-supply = <&v1v8>;
> + dvdd-3v-supply = <&v3v3>;
> + bgvdd-supply = <&v1v8>;
> +
> + adi,input-depth = <8>;
> + adi,input-colorspace = "yuv422";
> + adi,input-clock = "1x";
> +
> + adi,input-style = <3>;
> + adi,input-justification = "right";
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + adv7511w_in: endpoint {
> + remote-endpoint = <&dpi_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + adv7511_out: endpoint {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> + codec_endpoint: endpoint {
> + remote-endpoint = <&i2s0_cpu_endpoint>;
> + };
> + };
> + };
> + };
> +
> +...
> diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml b/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
> new file mode 100644
> index 000000000000..18761f49e5fe
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
> @@ -0,0 +1,175 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/adi,adv7533.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Analog Devices ADV7533/35 HDMI Encoders
> +
> +maintainers:
> + - Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> +
> +description: |
> + The ADV7533 and ADV7535 are HDMI audio and video transmitters
> + compatible with HDMI 1.4 and DVI 1.0. They support color space
> + conversion, S/PDIF, CEC and HDCP. The transmitter input is MIPI DSI.
> +
> +properties:
> + compatible:
> + enum:
> + - adi,adv7533
> + - adi,adv7535
> +
> + reg:
> + description: |
> + I2C slave addresses.
> +
> + The ADV7533/35 internal registers are split into four pages
> + exposed through different I2C addresses, creating four register
> + maps. Each map has it own I2C address and acts as a standard slave
> + device on the I2C bus. The main address is mandatory, others are
> + optional and revert to defaults if not specified.
> + minItems: 1
> + maxItems: 4
> +
> + reg-names:
> + description:
> + Names of maps with programmable addresses. It can contain any map
> + needing a non-default address.
> + minItems: 1
> + items:
> + - const: main
> + - const: edid
> + - const: cec
> + - const: packet
> +
> + clocks:
> + description: Reference to the CEC clock.
> + maxItems: 1
> +
> + clock-names:
> + const: cec
> +
> + interrupts:
> + maxItems: 1
> +
> + pd-gpios:
> + description: GPIO connected to the power down signal.
> + maxItems: 1
> +
> + avdd-supply:
> + description: A 1.8V supply that powers up the AVDD pin.
> +
> + dvdd-supply:
> + description: A 1.8V supply that powers up the DVDD pin.
> +
> + pvdd-supply:
> + description: A 1.8V supply that powers up the PVDD pin.
> +
> + a2vdd-supply:
> + description: A 1.8V supply that powers up the A2VDD pin.
> +
> + v3p3-supply:
> + description: A 3.3V supply that powers up the V3P3 pin.
> +
> + v1p2-supply:
> + description:
> + A supply that powers up the V1P2 pin. It can be either 1.2V
> + or 1.8V for ADV7533 but only 1.8V for ADV7535.
> +
> + adi,disable-timing-generator:
> + description:
> + Disables the internal timing generator. The chip will rely on the
> + sync signals in the DSI data lanes, rather than generating its own
> + timings for HDMI output.
> + type: boolean
> +
> + adi,dsi-lanes:
> + description: Number of DSI data lanes connected to the DSI host.
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [ 1, 2, 3, 4 ]
> +
> + ports:
> + description:
> + The ADV7533/35 has two video ports and one audio port. This node
> + models their connections as documented in
> + Documentation/devicetree/bindings/media/video-interfaces.txt
> + Documentation/devicetree/bindings/graph.txt
> + type: object
> + properties:
> + port@0:
> + description:
> + Video port for the DSI input. The remote endpoint phandle
> + should be a reference to a valid mipi_dsi_host_device.
> + type: object
> +
> + port@1:
> + description: Video port for the HDMI output.
> + type: object
> +
> + port@2:
> + description: Audio port for the HDMI output.
> + type: object
> +
> +required:
> + - compatible
> + - reg
> + - ports
> + - adi,dsi-lanes
> + - avdd-supply
> + - dvdd-supply
> + - pvdd-supply
> + - a2vdd-supply
> + - v3p3-supply
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + adv7533: hdmi@39 {
> + compatible = "adi,adv7533";
> + /*
> + * The EDID page will be accessible on address 0x66 on the I2C
> + * bus. All other maps continue to use their default addresses.
> + */
> + reg = <0x39>, <0x66>;
> + reg-names = "main", "edid";
> + interrupt-parent = <&gpio3>;
> + interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
> + clocks = <&cec_clock>;
> + clock-names = "cec";
> + adi,dsi-lanes = <4>;
> + avdd-supply = <&v1v8>;
> + dvdd-supply = <&v1v8>;
> + pvdd-supply = <&v1v8>;
> + a2vdd-supply = <&v1v8>;
> + v3p3-supply = <&v3v3>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + adv7533_in: endpoint {
> + remote-endpoint = <&dsi_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + adv7533_out: endpoint {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> + codec_endpoint: endpoint {
> + remote-endpoint = <&i2s0_cpu_endpoint>;
> + };
> + };
> + };
> + };
> +
> +...
> --
> 2.18.0
>
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 1/2] media: dt-bindings: media: xilinx: Add Xilinx UHD-SDI Receiver Subsystem
From: Laurent Pinchart @ 2020-06-03 1:13 UTC (permalink / raw)
To: Vishal Sagar
Cc: Hyun Kwon, mchehab@kernel.org, robh+dt@kernel.org,
mark.rutland@arm.com, Michal Simek, linux-media@vger.kernel.org,
devicetree@vger.kernel.org, hans.verkuil@cisco.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Dinesh Kumar, Sandip Kothari,
Joe Perches
In-Reply-To: <DM6PR02MB6876116CECBA49741FF57E79A78A0@DM6PR02MB6876.namprd02.prod.outlook.com>
Hi Vishal,
On Mon, Jun 01, 2020 at 03:14:52PM +0000, Vishal Sagar wrote:
> On Wednesday, May 6, 2020 6:32 PM, Laurent Pinchart wrote:
> > On Wed, Apr 29, 2020 at 07:47:03PM +0530, Vishal Sagar wrote:
> > > Add bindings documentation for Xilinx UHD-SDI Receiver Subsystem.
> > >
> > > The Xilinx UHD-SDI Receiver Subsystem consists of SMPTE UHD-SDI (RX) IP
> > > core, an SDI RX to Video Bridge IP core to convert SDI video to native
> > > video and a Video In to AXI4-Stream IP core to convert native video to
> > > AXI4-Stream.
> > >
> > > Signed-off-by: Vishal Sagar <vishal.sagar@xilinx.com>
> > > ---
> > > v2
> > > - Removed references to xlnx,video*
> > > - Fixed as per Sakari Ailus and Rob Herring's comments
> > > - Converted to yaml format
> > >
> > > .../bindings/media/xilinx/xlnx,sdirxss.yaml | 132 ++++++++++++++++++
> > > 1 file changed, 132 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/media/xilinx/xlnx,sdirxss.yaml
> > >
> > > diff --git
> > a/Documentation/devicetree/bindings/media/xilinx/xlnx,sdirxss.yaml
> > b/Documentation/devicetree/bindings/media/xilinx/xlnx,sdirxss.yaml
> > > new file mode 100644
> > > index 000000000000..9133ad19df55
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/media/xilinx/xlnx,sdirxss.yaml
> > > @@ -0,0 +1,132 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/media/xilinx/xlnx,sdirxss.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +
> > > +title: Xilinx SMPTE UHD-SDI Receiver Subsystem
> > > +
> > > +maintainers:
> > > + - Vishal Sagar <vishal.sagar@xilinx.com>
> > > +
> > > +description: |
> > > + The SMPTE UHD-SDI Receiver (RX) Subsystem allows you to quickly create systems
> > > + based on SMPTE SDI protocols. It receives unaligned native SDI streams from
> > > + the SDI GT PHY and outputs an AXI4-Stream video stream, native video, or
> > > + native SDI using Xilinx transceivers as the physical layer.
> > > +
> > > + The subsystem consists of
> > > + 1 - SMPTE UHD-SDI Rx
> > > + 2 - SDI Rx to Native Video Bridge
> > > + 3 - Video In to AXI4-Stream Bridge
> > > +
> > > + The subsystem can capture SDI streams in upto 12G mode 8 data streams and output
> >
> > s/upto/up to/
>
> I will fix this in next version.
>
> > > + a dual pixel per clock RGB/YUV444,422/420 10/12 bits per component AXI4-Stream.
> > > +
> > > +properties:
> > > + compatible:
> > > + items:
> > > + - enum:
> > > + - xlnx,v-smpte-uhdsdi-rx-ss-2.0
> > > +
> > > + reg:
> > > + maxItems: 1
> > > +
> > > + interrupts:
> > > + maxItems: 1
> > > +
> > > + clocks:
> > > + description: List of clock specifiers
> > > + items:
> > > + - description: AXI4-Lite clock
> > > + - description: SMPTE UHD-SDI Rx core clock
> > > + - description: Video clock
> > > +
> > > + clock-names:
> > > + items:
> > > + - const: s_axi_aclk
> > > + - const: sdi_rx_clk
> > > + - const: video_out_clk
> > > +
> > > + xlnx,bpp:
> > > + description: Bits per pixel supported. Can be 10 or 12 bits per pixel only.
> > > + allOf:
> > > + - $ref: "/schemas/types.yaml#/definitions/uint32"
> > > + - enum: [10, 12]
> >
> > I don't see this as a design parameter in the documentation (pg290,
> > v2.0). What does it correspond to ? All the BPC mentions in the
> > documentation always state that 10-bit is the only supported value.
>
> The new version of IP being released will have 10 and 12 bit support. It is already in the Xilinx linux-xlnx repo.
> I will rename this to "xlnx,bpc" instead of "xlnx,bpp" to refer to bits per component.
Is the documentation for the new IP core version available ? Should this
property only be allowed for the new version, given that in v2.0 the BPC
is fixed to 10 ?
> > > +
> > > + xlnx,line-rate:
> > > + description: |
> > > + The maximum mode supported by the design. Possible values are as below
> > > + 12G_SDI_8DS - 12G mode with 8 data streams
> > > + 6G_SDI - 6G mode
> > > + 3G_SDI - 3G mode
> > > + enum:
> > > + - 12G_SDI_8DS
> > > + - 6G_SDI
> > > + - 3G_SDI
> >
> > How about making this an integer property, with #define in
> > include/dt-bindings/media/xilinx-sdi.h ? As far as I understand, the SDI
> > TX subsystem has the same parameter, so the #define could be shared
> > between the two.
>
> Yes that is ok with me. I will add this in the next version.
>
> > > +
> > > + xlnx,include-edh:
> > > + type: boolean
> > > + description: |
> > > + This is present when the Error Detection and Handling processor is
> > > + enabled in design.
> > > +
> > > + ports:
> > > + type: object
> > > + description: |
> > > + Generally the SDI port is connected to a device like SDI Broadcast camera
> > > + which is independently controlled. Hence port@0 is a source port which can be
> > > + connected to downstream IP which can work with AXI4 Stream data.
> >
> > We should still have an input port. It can be connected to a DT node for
> > a physical SDI connector, or any other component in the platform (I
> > expect the former to be the common case). There are DT bindings for
> > connectors in Documentation/devicetree/bindings/display/connector/, we
> > should add one for SDI.
>
> Yes the input port is a physical SDI connector connected to an equipment like broadcast camera.
> But the camera/equipment can't be controlled by the V4L2 pipeline and SDI protocol is unidirectional.
>
> If we add another dt node, then I think another dummy v4l subdev driver will need to implemented and loaded
> to complete the pipe as Xilinx Video driver will need it.
We don't necessarily need a driver for the connector (although it may be
a good idea to do so, but that's a separate question). The sdi-rx driver
could handle the SDI connector DT node by parsing its properties
manually (assuming it would contain properties that need to be parsed).
> Could you please share the reason to have this input port in the SDI Rx driver?
We try to make sure the whole pipeline is modelled in DT. This applies
to both V4L2 and DRM/KMS. While the connector doesn't need to be
controlled by software (it's just a connector), it may still have
properties that matter from a software point of view. For instance the
label property can be used to specify how the connector is labeled on
the board or on the device's case, allowing applications to display the
correct labels to the users. Another use case related to the 4-pin
mini-DIN connectors typically used for S-Video. On some devices, they
are also used for composite video, with multiple video sources connected
to the same mini-DIN connector with a special cable. Kernel drivers need
to know how signals are routed, and DT nodes help there.
> > > + properties:
> > > + port@0:
> > > + type: object
> > > + description: Source port
> > > + properties:
> > > + reg:
> > > + const: 0
> > > + endpoint:
> > > + type: object
> > > + properties:
> > > + remote-endpoint: true
> > > + required:
> > > + - remote-endpoint
> > > + additionalProperties: false
> > > + additionalProperties: false
> > > +
> > > +required:
> > > + - compatible
> > > + - reg
> > > + - interrupts
> > > + - clocks
> > > + - clock-names
> > > + - xlnx,line-rate
> > > + - xlnx,bpp
> > > + - ports
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > + - |
> > > + uhdsdirxss: v-smpte-uhdsdi-rxss@80000000 {
I forgot to mention, you can drop the label as it's not used.
> > > + compatible = "xlnx,v-smpte-uhdsdi-rx-ss-2.0";
> > > + interrupt-parent = <&gic>;
> > > + interrupts = <0 89 4>;
> > > + reg = <0x0 0x80000000 0x0 0x10000>;
> > > + xlnx,include-edh;
> > > + xlnx,line-rate = "12G_SDI_8DS";
> > > + clocks = <&clk_1>, <&si570_1>, <&clk_2>;
> > > + clock-names = "s_axi_aclk", "sdi_rx_clk", "video_out_clk";
> > > + xlnx,bpp = <10>;
And I would group the xlnx,* properties after the standard properties.
> > > +
> > > + ports {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + port@0 {
> > > + reg = <0>;
> > > + sdirx_out: endpoint {
> > > + remote-endpoint = <&vcap_sdirx_in>;
> > > + };
> > > + };
> > > + };
> > > + };
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 0/3] Convert i.MX/MXS I2C/LPI2C binding doc to json-schema
From: Anson Huang @ 2020-06-03 1:58 UTC (permalink / raw)
To: aisheng.dong, robh+dt, shawnguo, s.hauer, kernel, festevam, linux,
pandy.gao, wolfram, linux-i2c, devicetree, linux-arm-kernel,
linux-kernel
Cc: Linux-imx
Coverts i.MX/MXS I2C.LPI2C binding doc to json-schema, some examples are
too old, update them based on latest DT file, also add more compatible
based on supported SoCs.
Anson Huang (3):
dt-bindings: i2c: Convert imx lpi2c to json-schema
dt-bindings: i2c: Convert mxs i2c to json-schema
dt-bindings: i2c: Convert imx i2c to json-schema
.../devicetree/bindings/i2c/i2c-imx-lpi2c.txt | 20 ----
.../devicetree/bindings/i2c/i2c-imx-lpi2c.yaml | 45 ++++++++
Documentation/devicetree/bindings/i2c/i2c-imx.txt | 49 ---------
Documentation/devicetree/bindings/i2c/i2c-imx.yaml | 118 +++++++++++++++++++++
Documentation/devicetree/bindings/i2c/i2c-mxs.txt | 25 -----
Documentation/devicetree/bindings/i2c/i2c-mxs.yaml | 55 ++++++++++
6 files changed, 218 insertions(+), 94 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.txt
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml
delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-imx.txt
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-imx.yaml
delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-mxs.txt
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mxs.yaml
--
2.7.4
^ permalink raw reply
* [PATCH 3/3] dt-bindings: i2c: Convert imx i2c to json-schema
From: Anson Huang @ 2020-06-03 1:58 UTC (permalink / raw)
To: aisheng.dong, robh+dt, shawnguo, s.hauer, kernel, festevam, linux,
pandy.gao, wolfram, linux-i2c, devicetree, linux-arm-kernel,
linux-kernel
Cc: Linux-imx
In-Reply-To: <1591149535-342-1-git-send-email-Anson.Huang@nxp.com>
Convert the i.MX I2C binding to DT schema format using json-schema,
some improvements applied, such as update example based on latest DT
file, add more compatible for existing SoCs, and remove unnecessary
common property "pinctrl".
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
Documentation/devicetree/bindings/i2c/i2c-imx.txt | 49 ---------
Documentation/devicetree/bindings/i2c/i2c-imx.yaml | 118 +++++++++++++++++++++
2 files changed, 118 insertions(+), 49 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-imx.txt
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-imx.yaml
diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx.txt b/Documentation/devicetree/bindings/i2c/i2c-imx.txt
deleted file mode 100644
index b967544..0000000
--- a/Documentation/devicetree/bindings/i2c/i2c-imx.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-* Freescale Inter IC (I2C) and High Speed Inter IC (HS-I2C) for i.MX
-
-Required properties:
-- compatible :
- - "fsl,imx1-i2c" for I2C compatible with the one integrated on i.MX1 SoC
- - "fsl,imx21-i2c" for I2C compatible with the one integrated on i.MX21 SoC
- - "fsl,vf610-i2c" for I2C compatible with the one integrated on Vybrid vf610 SoC
-- reg : Should contain I2C/HS-I2C registers location and length
-- interrupts : Should contain I2C/HS-I2C interrupt
-- clocks : Should contain the I2C/HS-I2C clock specifier
-
-Optional properties:
-- clock-frequency : Constains desired I2C/HS-I2C bus clock frequency in Hz.
- The absence of the property indicates the default frequency 100 kHz.
-- dmas: A list of two dma specifiers, one for each entry in dma-names.
-- dma-names: should contain "tx" and "rx".
-- scl-gpios: specify the gpio related to SCL pin
-- sda-gpios: specify the gpio related to SDA pin
-- pinctrl: add extra pinctrl to configure i2c pins to gpio function for i2c
- bus recovery, call it "gpio" state
-
-Examples:
-
-i2c@83fc4000 { /* I2C2 on i.MX51 */
- compatible = "fsl,imx51-i2c", "fsl,imx21-i2c";
- reg = <0x83fc4000 0x4000>;
- interrupts = <63>;
-};
-
-i2c@70038000 { /* HS-I2C on i.MX51 */
- compatible = "fsl,imx51-i2c", "fsl,imx21-i2c";
- reg = <0x70038000 0x4000>;
- interrupts = <64>;
- clock-frequency = <400000>;
-};
-
-i2c0: i2c@40066000 { /* i2c0 on vf610 */
- compatible = "fsl,vf610-i2c";
- reg = <0x40066000 0x1000>;
- interrupts =<0 71 0x04>;
- dmas = <&edma0 0 50>,
- <&edma0 0 51>;
- dma-names = "rx","tx";
- pinctrl-names = "default", "gpio";
- pinctrl-0 = <&pinctrl_i2c1>;
- pinctrl-1 = <&pinctrl_i2c1_gpio>;
- scl-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH>;
- sda-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>;
-};
diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx.yaml b/Documentation/devicetree/bindings/i2c/i2c-imx.yaml
new file mode 100644
index 0000000..0d31d1c
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-imx.yaml
@@ -0,0 +1,118 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/i2c-imx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Inter IC (I2C) and High Speed Inter IC (HS-I2C) for i.MX
+
+maintainers:
+ - Wolfram Sang <wolfram@the-dreams.de>
+
+properties:
+ compatible:
+ oneOf:
+ - const: fsl,imx1-i2c
+ - const: fsl,imx21-i2c
+ - const: fsl,vf610-i2c
+ - items:
+ - const: fsl,imx35-i2c
+ - const: fsl,imx1-i2c
+ - items:
+ - enum:
+ - fsl,imx25-i2c
+ - fsl,imx27-i2c
+ - fsl,imx31-i2c
+ - fsl,imx50-i2c
+ - fsl,imx51-i2c
+ - fsl,imx53-i2c
+ - fsl,imx6q-i2c
+ - fsl,imx6sl-i2c
+ - fsl,imx6sx-i2c
+ - fsl,imx6sll-i2c
+ - fsl,imx6ul-i2c
+ - fsl,imx7s-i2c
+ - fsl,imx8mq-i2c
+ - fsl,imx8mm-i2c
+ - fsl,imx8mn-i2c
+ - fsl,imx8mp-i2c
+ - const: fsl,imx21-i2c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-frequency:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Constains desired I2C/HS-I2C bus clock frequency in Hz.
+ The absence of the property indicates the default frequency 100 kHz.
+ default: 100000
+
+ dmas:
+ items:
+ - description: DMA controller phandle and request line for RX
+ - description: DMA controller phandle and request line for TX
+
+ dma-names:
+ items:
+ - const: rx
+ - const: tx
+
+ sda-gpios:
+ $ref: '/schemas/types.yaml#/definitions/phandle'
+ description: |
+ gpio used for the sda signal, this should be flagged as
+ active high using open drain with (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)
+ from <dt-bindings/gpio/gpio.h> since the signal is by definition
+ open drain.
+ maxItems: 1
+
+ scl-gpios:
+ $ref: '/schemas/types.yaml#/definitions/phandle'
+ description: |
+ gpio used for the scl signal, this should be flagged as
+ active high using open drain with (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)
+ from <dt-bindings/gpio/gpio.h> since the signal is by definition
+ open drain.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx5-clock.h>
+ #include <dt-bindings/clock/vf610-clock.h>
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ i2c@83fc4000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,imx51-i2c", "fsl,imx21-i2c";
+ reg = <0x83fc4000 0x4000>;
+ interrupts = <63>;
+ clocks = <&clks IMX5_CLK_I2C2_GATE>;
+ };
+
+ i2c@40066000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,vf610-i2c";
+ reg = <0x40066000 0x1000>;
+ interrupts = <71 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks VF610_CLK_I2C0>;
+ clock-names = "ipg";
+ dmas = <&edma0 0 50>,
+ <&edma0 0 51>;
+ dma-names = "rx","tx";
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: i2c: Convert mxs i2c to json-schema
From: Anson Huang @ 2020-06-03 1:58 UTC (permalink / raw)
To: aisheng.dong, robh+dt, shawnguo, s.hauer, kernel, festevam, linux,
pandy.gao, wolfram, linux-i2c, devicetree, linux-arm-kernel,
linux-kernel
Cc: Linux-imx
In-Reply-To: <1591149535-342-1-git-send-email-Anson.Huang@nxp.com>
Convert the MXS I2C binding to DT schema format using json-schema
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
Documentation/devicetree/bindings/i2c/i2c-mxs.txt | 25 ----------
Documentation/devicetree/bindings/i2c/i2c-mxs.yaml | 55 ++++++++++++++++++++++
2 files changed, 55 insertions(+), 25 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-mxs.txt
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mxs.yaml
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mxs.txt b/Documentation/devicetree/bindings/i2c/i2c-mxs.txt
deleted file mode 100644
index 4e1c8ac..0000000
--- a/Documentation/devicetree/bindings/i2c/i2c-mxs.txt
+++ /dev/null
@@ -1,25 +0,0 @@
-* Freescale MXS Inter IC (I2C) Controller
-
-Required properties:
-- compatible: Should be "fsl,<chip>-i2c"
-- reg: Should contain registers location and length
-- interrupts: Should contain ERROR interrupt number
-- clock-frequency: Desired I2C bus clock frequency in Hz.
- Only 100000Hz and 400000Hz modes are supported.
-- dmas: DMA specifier, consisting of a phandle to DMA controller node
- and I2C DMA channel ID.
- Refer to dma.txt and fsl-mxs-dma.txt for details.
-- dma-names: Must be "rx-tx".
-
-Examples:
-
-i2c0: i2c@80058000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "fsl,imx28-i2c";
- reg = <0x80058000 2000>;
- interrupts = <111>;
- clock-frequency = <100000>;
- dmas = <&dma_apbx 6>;
- dma-names = "rx-tx";
-};
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mxs.yaml b/Documentation/devicetree/bindings/i2c/i2c-mxs.yaml
new file mode 100644
index 0000000..7adcba3
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-mxs.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/i2c-mxs.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale MXS Inter IC (I2C) Controller
+
+maintainers:
+ - Shawn Guo <shawn.guo@linaro.org>
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx23-i2c
+ - fsl,imx28-i2c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clock-frequency:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Desired I2C bus clock frequency in Hz, only 100000Hz and 400000Hz
+ modes are supported.
+ default: 100000
+
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ const: rx-tx
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - dmas
+ - dma-names
+
+examples:
+ - |
+ i2c@80058000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,imx28-i2c";
+ reg = <0x80058000 2000>;
+ interrupts = <111>;
+ clock-frequency = <100000>;
+ dmas = <&dma_apbx 6>;
+ dma-names = "rx-tx";
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: i2c: Convert imx lpi2c to json-schema
From: Anson Huang @ 2020-06-03 1:58 UTC (permalink / raw)
To: aisheng.dong, robh+dt, shawnguo, s.hauer, kernel, festevam, linux,
pandy.gao, wolfram, linux-i2c, devicetree, linux-arm-kernel,
linux-kernel
Cc: Linux-imx
In-Reply-To: <1591149535-342-1-git-send-email-Anson.Huang@nxp.com>
Convert the i.MX LPI2C binding to DT schema format using json-schema
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
---
.../devicetree/bindings/i2c/i2c-imx-lpi2c.txt | 20 ----------
.../devicetree/bindings/i2c/i2c-imx-lpi2c.yaml | 45 ++++++++++++++++++++++
2 files changed, 45 insertions(+), 20 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.txt
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml
diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.txt b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.txt
deleted file mode 100644
index f0c072f..0000000
--- a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-* Freescale Low Power Inter IC (LPI2C) for i.MX
-
-Required properties:
-- compatible :
- - "fsl,imx7ulp-lpi2c" for LPI2C compatible with the one integrated on i.MX7ULP soc
- - "fsl,imx8qxp-lpi2c" for LPI2C compatible with the one integrated on i.MX8QXP soc
- - "fsl,imx8qm-lpi2c" for LPI2C compatible with the one integrated on i.MX8QM soc
-- reg : address and length of the lpi2c master registers
-- interrupts : lpi2c interrupt
-- clocks : lpi2c clock specifier
-
-Examples:
-
-lpi2c7: lpi2c7@40a50000 {
- compatible = "fsl,imx7ulp-lpi2c";
- reg = <0x40A50000 0x10000>;
- interrupt-parent = <&intc>;
- interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&clks IMX7ULP_CLK_LPI2C7>;
-};
diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml
new file mode 100644
index 0000000..3c0be0c
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-imx-lpi2c.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/i2c-imx-lpi2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Low Power Inter IC (LPI2C) for i.MX
+
+maintainers:
+ - Anson Huang <Anson.Huang@nxp.com>
+
+properties:
+ compatible:
+ enum:
+ - fsl,imx7ulp-lpi2c
+ - fsl,imx8qxp-lpi2c
+ - fsl,imx8qm-lpi2c
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx7ulp-clock.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ lpi2c7@40a50000 {
+ compatible = "fsl,imx7ulp-lpi2c";
+ reg = <0x40A50000 0x10000>;
+ interrupt-parent = <&intc>;
+ interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX7ULP_CLK_LPI2C7>;
+ };
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v10 00/10] exynos-ufs: Add support for UFS HCI
From: Martin K. Petersen @ 2020-06-03 2:31 UTC (permalink / raw)
To: robh, Alim Akhtar
Cc: Martin K . Petersen, krzk, linux-samsung-soc, avri.altman,
stanley.chu, linux-scsi, linux-arm-kernel, cang, devicetree,
kwmad.kim, linux-kernel
In-Reply-To: <20200528011658.71590-1-alim.akhtar@samsung.com>
On Thu, 28 May 2020 06:46:48 +0530, Alim Akhtar wrote:
> This patch-set introduces UFS (Universal Flash Storage) host
> controller support for Samsung family SoC. Mostly, it consists of
> UFS PHY and host specific driver.
> [...]
Applied [1,2,3,4,5,9] to 5.9/scsi-queue. The series won't show up in
my public tree until shortly after -rc1 is released.
Thanks!
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* RE: [PATCH V3 1/3] dt-bindings: mailbox: imx-mu: support i.MX8M
From: Peng Fan @ 2020-06-03 3:10 UTC (permalink / raw)
To: Peng Fan, shawnguo@kernel.org, Fabio Estevam,
kernel@pengutronix.de, Aisheng Dong, robh+dt@kernel.org,
sboyd@kernel.org, linux@rempel-privat.de,
jaswinder.singh@linaro.org
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, dl-linux-imx, Leonard Crestez,
Daniel Baluta, l.stach@pengutronix.de, devicetree@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <1590999602-29482-2-git-send-email-peng.fan@nxp.com>
> Subject: [PATCH V3 1/3] dt-bindings: mailbox: imx-mu: support i.MX8M
I'll drop this patch for yaml update, since https://lkml.org/lkml/2020/6/1/370
includes imx8mq/mm/n/p.
Thanks,
Peng.
>
> From: Peng Fan <peng.fan@nxp.com>
>
> Add i.MX8MQ/M/N/P compatible string to support i.MX8M SoCs
>
> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> Documentation/devicetree/bindings/mailbox/fsl,mu.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> index 26b7a88c2fea..906377acf2cd 100644
> --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> @@ -18,7 +18,8 @@ Messaging Unit Device Node:
> Required properties:
> -------------------
> - compatible : should be "fsl,<chip>-mu", the supported chips include
> - imx6sx, imx7s, imx8qxp, imx8qm.
> + imx6sx, imx7s, imx8qxp, imx8qm, imx8mq, imx8mm, imx8mn,
> + imx8mp.
> The "fsl,imx6sx-mu" compatible is seen as generic and should
> be included together with SoC specific compatible.
> There is a version 1.0 MU on imx7ulp, use "fsl,imx7ulp-mu"
> --
> 2.16.4
^ permalink raw reply
* [PATCH V4 0/2] imx8m: add mu support
From: peng.fan @ 2020-06-03 3:35 UTC (permalink / raw)
To: shawnguo, fabio.estevam, kernel, aisheng.dong, robh+dt, sboyd,
linux
Cc: linux-arm-kernel, linux-kernel, linux-imx, leonard.crestez,
daniel.baluta, l.stach, devicetree, linux-clk, Peng Fan
From: Peng Fan <peng.fan@nxp.com>
V4:
Drop patch 1/3, since https://lkml.org/lkml/2020/6/1/370 already
has the yaml changes
V3:
Add R-b tag
Remove undocumented property
V2:
Add dt-bindings
Merge dts changes into one patch, since all is to add mu node
Add mu dt bindings
Add mu node
Add i.MX8MP mu root clk
Peng Fan (2):
arm64: dts: imx8m: add mu node
clk: imx8mp: add mu root clk
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 8 ++++++++
arch/arm64/boot/dts/freescale/imx8mn.dtsi | 8 ++++++++
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 8 ++++++++
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 8 ++++++++
drivers/clk/imx/clk-imx8mp.c | 1 +
5 files changed, 33 insertions(+)
--
2.16.4
^ permalink raw reply
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