Hi,
This series add support for the USB device controller available on
the Microchip LAN966x SOCs.
This controller is the same as the one present on the SAMAD3 SOC.
Regards,
Herve
Herve Codina (3):
clk: lan966x: Fix the lan966x clock gate register address
dt-bindings: usb: atmel: Add Microchip LAN966x compatible string
ARM: dts: lan966x: Add UDPHS support
Documentation/devicetree/bindings/usb/atmel-usb.txt | 3 +++
arch/arm/boot/dts/lan966x.dtsi | 11 +++++++++++
drivers/clk/clk-lan966x.c | 2 +-
3 files changed, 15 insertions(+), 1 deletion(-)
--
2.35.1
The USB device controller available in the Microchip LAN966x SOC
is the same IP as the one present in the SAMA5D3 SOC.
Add the LAN966x compatible string and set the SAMA5D3 compatible
string as a fallback for the LAN966x.
Signed-off-by: Herve Codina <[email protected]>
---
Documentation/devicetree/bindings/usb/atmel-usb.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt
index f512f0290728..a6fab7d63f37 100644
--- a/Documentation/devicetree/bindings/usb/atmel-usb.txt
+++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt
@@ -87,6 +87,9 @@ Required properties:
"atmel,at91sam9g45-udc"
"atmel,sama5d3-udc"
"microchip,sam9x60-udc"
+ "microchip,lan996x-udc"
+ For "microchip,lan996x-udc", the fallback "atmel,sama5d3-udc"
+ is required.
- reg: Address and length of the register set for the device
- interrupts: Should contain usba interrupt
- clocks: Should reference the peripheral and host clocks
--
2.35.1
The register address used for the clock gate register is the base
register address coming from first reg map (ie. the generic
clock registers) instead of the second reg map defining the clock
gate register.
Use the correct clock gate register address.
Fixes: 5ad5915dea00 ("clk: lan966x: Extend lan966x clock driver for clock gating support")
Signed-off-by: Herve Codina <[email protected]>
---
drivers/clk/clk-lan966x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/clk-lan966x.c b/drivers/clk/clk-lan966x.c
index d1535ac13e89..81cb90955d68 100644
--- a/drivers/clk/clk-lan966x.c
+++ b/drivers/clk/clk-lan966x.c
@@ -213,7 +213,7 @@ static int lan966x_gate_clk_register(struct device *dev,
hw_data->hws[i] =
devm_clk_hw_register_gate(dev, clk_gate_desc[idx].name,
- "lan966x", 0, base,
+ "lan966x", 0, gate_base,
clk_gate_desc[idx].bit_idx,
0, &clk_gate_lock);
--
2.35.1
Add UDPHS (the USB High Speed Device Port controller) support.
The UDPHS IP present in the lan966x SOC is the same as the one
present in the SAMA5D3 SOC
Signed-off-by: Herve Codina <[email protected]>
---
arch/arm/boot/dts/lan966x.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/lan966x.dtsi b/arch/arm/boot/dts/lan966x.dtsi
index 7d2869648050..4c09f3166d27 100644
--- a/arch/arm/boot/dts/lan966x.dtsi
+++ b/arch/arm/boot/dts/lan966x.dtsi
@@ -211,6 +211,17 @@ can0: can@e081c000 {
status = "disabled";
};
+ udc: udphs@e0808000 {
+ compatible = "microchip,lan996x-udc",
+ "atmel,sama5d3-udc";
+ reg = <0x00200000 0x80000>,
+ <0xe0808000 0x400>;
+ interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks GCK_GATE_UDPHS>, <&nic_clk>;
+ clock-names = "pclk", "hclk";
+ status = "disabled";
+ };
+
gpio: pinctrl@e2004064 {
compatible = "microchip,lan966x-pinctrl";
reg = <0xe2004064 0xb4>,
--
2.35.1
Hello!
On 5/13/22 1:58 PM, Herve Codina wrote:
> Add UDPHS (the USB High Speed Device Port controller) support.
> The UDPHS IP present in the lan966x SOC is the same as the one
> present in the SAMA5D3 SOC
>
> Signed-off-by: Herve Codina <[email protected]>
> ---
> arch/arm/boot/dts/lan966x.dtsi | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/boot/dts/lan966x.dtsi b/arch/arm/boot/dts/lan966x.dtsi
> index 7d2869648050..4c09f3166d27 100644
> --- a/arch/arm/boot/dts/lan966x.dtsi
> +++ b/arch/arm/boot/dts/lan966x.dtsi
> @@ -211,6 +211,17 @@ can0: can@e081c000 {
> status = "disabled";
> };
>
> + udc: udphs@e0808000 {
Shouldn't it be:
udphs: udc@e0808000 {
(as the node names should be generic)?
[...]
MBR, Sergey
Hello,
On 20/05/2022 15:38:36+0200, Krzysztof Kozlowski wrote:
> On 20/05/2022 15:02, Herve Codina wrote:
> > On Fri, 20 May 2022 14:50:24 +0200
> > Krzysztof Kozlowski <[email protected]> wrote:
> >
> >> On 20/05/2022 14:21, Herve Codina wrote:
> >>>>> I think it makes sense to keep 'microchip,lan966x-udc' for the USB
> >>>>> device controller (same controller on LAN9662 and LAN9668) and so
> >>>>> keeping the same rules as for other common parts.
> >>>>
> >>>> Having wildcard was rather a mistake and we already started correcting
> >>>> it, so keeping the "mistake" neither gives you consistency, nor
> >>>> correctness...
> >>>>
> >>>
> >>> I think that the "family" compatible should be present.
> >>> This one allows to define the common parts in the common
> >>> .dtsi file (lan966x.dtsi in our case).
> >>>
> >>> What do you think about:
> >>> - microchip,lan9662-udc
> >>> - microchip,lan9668-udc
> >>> - microchip,lan966-udc <-- Family
> >>>
> >>> lan966 is defined as the family compatible string since (1) in
> >>> bindings/arm/atmel-at91.yaml and in Documentation/arm/microchip.rst
> >>>
> >>
> >> You can add some family compatible, if it makes sense. I don't get why
> >> do you mention it - we did not discuss family names, but using
> >> wildcards... Just please do not add wildcards.
> >
> > Well, I mentioned it as I will only use the family compatible string
> > and not the SOC (lan9662 or lan9668) compatible string in lan966x.dtsi.
> > In this case, the family compatible string can be seen as a kind of
> > "wildcard".
>
> I understood as "the "family" compatible should be present" as you want
> to add it as a fallback. It would be okay (assuming devices indeed share
> family design). If you want to use it as the only one, then it is again
> not a recommended approach. Please use specific compatibles.
>
> I mean, why do we have this discussion? What is the benefit for you to
> implement something not-recommended by Devicetree spec and style?
>
Honestly, I would just go for microchip,lan9662-udc. There is no
difference between lan9662 and lan9668 apart from the number of switch
ports.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
On 20/05/2022 13:34, Herve Codina wrote:
> On Fri, 13 May 2022 14:57:55 +0200
> Krzysztof Kozlowski <[email protected]> wrote:
>
>> On 13/05/2022 12:58, Herve Codina wrote:
>>> The USB device controller available in the Microchip LAN966x SOC
>>> is the same IP as the one present in the SAMA5D3 SOC.
>>>
>>> Add the LAN966x compatible string and set the SAMA5D3 compatible
>>> string as a fallback for the LAN966x.
>>>
>>> Signed-off-by: Herve Codina <[email protected]>
>>> ---
>>> Documentation/devicetree/bindings/usb/atmel-usb.txt | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt
>>> index f512f0290728..a6fab7d63f37 100644
>>> --- a/Documentation/devicetree/bindings/usb/atmel-usb.txt
>>> +++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt
>>> @@ -87,6 +87,9 @@ Required properties:
>>> "atmel,at91sam9g45-udc"
>>> "atmel,sama5d3-udc"
>>> "microchip,sam9x60-udc"
>>> + "microchip,lan996x-udc"
>>
>> No wildcards please, especially that it closely fits previous wildcard
>> (lan996x includes lan9960 which looks a lot like sam9x60...)
>>
>
> Well, first, I made a mistake. It should be lan966x instead of lan996x.
>
> This family is composed of the LAN9662 and the LAN9668 SOCs.
>
> Related to the wilcard, lan966x is used in several bindings for common
> parts used by both SOCs:
> - microchip,lan966x-gck
> - microchip,lan966x-cpu-syscon
> - microchip,lan966x-switch
> - microchip,lan966x-miim
> - microchip,lan966x-serdes
> - microchip,lan966x-pinctrl
And for new bindings I pointed that it is not preferred, so already few
other started using specific compatible.
>
> I think it makes sense to keep 'microchip,lan966x-udc' for the USB
> device controller (same controller on LAN9662 and LAN9668) and so
> keeping the same rules as for other common parts.
Having wildcard was rather a mistake and we already started correcting
it, so keeping the "mistake" neither gives you consistency, nor
correctness...
Best regards,
Krzysztof
On 20/05/2022 15:02, Herve Codina wrote:
> On Fri, 20 May 2022 14:50:24 +0200
> Krzysztof Kozlowski <[email protected]> wrote:
>
>> On 20/05/2022 14:21, Herve Codina wrote:
>>>>> I think it makes sense to keep 'microchip,lan966x-udc' for the USB
>>>>> device controller (same controller on LAN9662 and LAN9668) and so
>>>>> keeping the same rules as for other common parts.
>>>>
>>>> Having wildcard was rather a mistake and we already started correcting
>>>> it, so keeping the "mistake" neither gives you consistency, nor
>>>> correctness...
>>>>
>>>
>>> I think that the "family" compatible should be present.
>>> This one allows to define the common parts in the common
>>> .dtsi file (lan966x.dtsi in our case).
>>>
>>> What do you think about:
>>> - microchip,lan9662-udc
>>> - microchip,lan9668-udc
>>> - microchip,lan966-udc <-- Family
>>>
>>> lan966 is defined as the family compatible string since (1) in
>>> bindings/arm/atmel-at91.yaml and in Documentation/arm/microchip.rst
>>>
>>
>> You can add some family compatible, if it makes sense. I don't get why
>> do you mention it - we did not discuss family names, but using
>> wildcards... Just please do not add wildcards.
>
> Well, I mentioned it as I will only use the family compatible string
> and not the SOC (lan9662 or lan9668) compatible string in lan966x.dtsi.
> In this case, the family compatible string can be seen as a kind of
> "wildcard".
I understood as "the "family" compatible should be present" as you want
to add it as a fallback. It would be okay (assuming devices indeed share
family design). If you want to use it as the only one, then it is again
not a recommended approach. Please use specific compatibles.
I mean, why do we have this discussion? What is the benefit for you to
implement something not-recommended by Devicetree spec and style?
Best regards,
Krzysztof
Hi Krzysztof,
On Fri, 20 May 2022 13:40:13 +0200
Krzysztof Kozlowski <[email protected]> wrote:
> On 20/05/2022 13:34, Herve Codina wrote:
> > On Fri, 13 May 2022 14:57:55 +0200
> > Krzysztof Kozlowski <[email protected]> wrote:
> >
> >> On 13/05/2022 12:58, Herve Codina wrote:
> >>> The USB device controller available in the Microchip LAN966x SOC
> >>> is the same IP as the one present in the SAMA5D3 SOC.
> >>>
> >>> Add the LAN966x compatible string and set the SAMA5D3 compatible
> >>> string as a fallback for the LAN966x.
> >>>
> >>> Signed-off-by: Herve Codina <[email protected]>
> >>> ---
> >>> Documentation/devicetree/bindings/usb/atmel-usb.txt | 3 +++
> >>> 1 file changed, 3 insertions(+)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt
> >>> index f512f0290728..a6fab7d63f37 100644
> >>> --- a/Documentation/devicetree/bindings/usb/atmel-usb.txt
> >>> +++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt
> >>> @@ -87,6 +87,9 @@ Required properties:
> >>> "atmel,at91sam9g45-udc"
> >>> "atmel,sama5d3-udc"
> >>> "microchip,sam9x60-udc"
> >>> + "microchip,lan996x-udc"
> >>
> >> No wildcards please, especially that it closely fits previous wildcard
> >> (lan996x includes lan9960 which looks a lot like sam9x60...)
> >>
> >
> > Well, first, I made a mistake. It should be lan966x instead of lan996x.
> >
> > This family is composed of the LAN9662 and the LAN9668 SOCs.
> >
> > Related to the wilcard, lan966x is used in several bindings for common
> > parts used by both SOCs:
> > - microchip,lan966x-gck
> > - microchip,lan966x-cpu-syscon
> > - microchip,lan966x-switch
> > - microchip,lan966x-miim
> > - microchip,lan966x-serdes
> > - microchip,lan966x-pinctrl
>
> And for new bindings I pointed that it is not preferred, so already few
> other started using specific compatible.
>
> >
> > I think it makes sense to keep 'microchip,lan966x-udc' for the USB
> > device controller (same controller on LAN9662 and LAN9668) and so
> > keeping the same rules as for other common parts.
>
> Having wildcard was rather a mistake and we already started correcting
> it, so keeping the "mistake" neither gives you consistency, nor
> correctness...
>
I think that the "family" compatible should be present.
This one allows to define the common parts in the common
.dtsi file (lan966x.dtsi in our case).
What do you think about:
- microchip,lan9662-udc
- microchip,lan9668-udc
- microchip,lan966-udc <-- Family
lan966 is defined as the family compatible string since (1) in
bindings/arm/atmel-at91.yaml and in Documentation/arm/microchip.rst
(1) https://lore.kernel.org/all/[email protected]/
Regards,
Herve
--
Hervé Codina, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
On 20/05/2022 14:21, Herve Codina wrote:
>>> I think it makes sense to keep 'microchip,lan966x-udc' for the USB
>>> device controller (same controller on LAN9662 and LAN9668) and so
>>> keeping the same rules as for other common parts.
>>
>> Having wildcard was rather a mistake and we already started correcting
>> it, so keeping the "mistake" neither gives you consistency, nor
>> correctness...
>>
>
> I think that the "family" compatible should be present.
> This one allows to define the common parts in the common
> .dtsi file (lan966x.dtsi in our case).
>
> What do you think about:
> - microchip,lan9662-udc
> - microchip,lan9668-udc
> - microchip,lan966-udc <-- Family
>
> lan966 is defined as the family compatible string since (1) in
> bindings/arm/atmel-at91.yaml and in Documentation/arm/microchip.rst
>
You can add some family compatible, if it makes sense. I don't get why
do you mention it - we did not discuss family names, but using
wildcards... Just please do not add wildcards.
Best regards,
Krzysztof
Hi Alexandre,
On Fri, 20 May 2022 15:52:22 +0200
Alexandre Belloni <[email protected]> wrote:
> Hello,
>
> On 20/05/2022 15:38:36+0200, Krzysztof Kozlowski wrote:
> > On 20/05/2022 15:02, Herve Codina wrote:
> > > On Fri, 20 May 2022 14:50:24 +0200
> > > Krzysztof Kozlowski <[email protected]> wrote:
> > >
> > >> On 20/05/2022 14:21, Herve Codina wrote:
> > >>>>> I think it makes sense to keep 'microchip,lan966x-udc' for the USB
> > >>>>> device controller (same controller on LAN9662 and LAN9668) and so
> > >>>>> keeping the same rules as for other common parts.
> > >>>>
> > >>>> Having wildcard was rather a mistake and we already started correcting
> > >>>> it, so keeping the "mistake" neither gives you consistency, nor
> > >>>> correctness...
> > >>>>
> > >>>
> > >>> I think that the "family" compatible should be present.
> > >>> This one allows to define the common parts in the common
> > >>> .dtsi file (lan966x.dtsi in our case).
> > >>>
> > >>> What do you think about:
> > >>> - microchip,lan9662-udc
> > >>> - microchip,lan9668-udc
> > >>> - microchip,lan966-udc <-- Family
> > >>>
> > >>> lan966 is defined as the family compatible string since (1) in
> > >>> bindings/arm/atmel-at91.yaml and in Documentation/arm/microchip.rst
> > >>>
> > >>
> > >> You can add some family compatible, if it makes sense. I don't get why
> > >> do you mention it - we did not discuss family names, but using
> > >> wildcards... Just please do not add wildcards.
> > >
> > > Well, I mentioned it as I will only use the family compatible string
> > > and not the SOC (lan9662 or lan9668) compatible string in lan966x.dtsi.
> > > In this case, the family compatible string can be seen as a kind of
> > > "wildcard".
> >
> > I understood as "the "family" compatible should be present" as you want
> > to add it as a fallback. It would be okay (assuming devices indeed share
> > family design). If you want to use it as the only one, then it is again
> > not a recommended approach. Please use specific compatibles.
> >
> > I mean, why do we have this discussion? What is the benefit for you to
> > implement something not-recommended by Devicetree spec and style?
> >
>
> Honestly, I would just go for microchip,lan9662-udc. There is no
> difference between lan9662 and lan9668 apart from the number of switch
> ports.
>
Sounds good.
I will do that.
Thanks,
Hervé
--
Hervé Codina, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
On 20/05/2022 15:52, Alexandre Belloni wrote:
> Hello,
>
> On 20/05/2022 15:38:36+0200, Krzysztof Kozlowski wrote:
>> On 20/05/2022 15:02, Herve Codina wrote:
>>> On Fri, 20 May 2022 14:50:24 +0200
>>> Krzysztof Kozlowski <[email protected]> wrote:
>>>
>>>> On 20/05/2022 14:21, Herve Codina wrote:
>>>>>>> I think it makes sense to keep 'microchip,lan966x-udc' for the USB
>>>>>>> device controller (same controller on LAN9662 and LAN9668) and so
>>>>>>> keeping the same rules as for other common parts.
>>>>>>
>>>>>> Having wildcard was rather a mistake and we already started correcting
>>>>>> it, so keeping the "mistake" neither gives you consistency, nor
>>>>>> correctness...
>>>>>>
>>>>>
>>>>> I think that the "family" compatible should be present.
>>>>> This one allows to define the common parts in the common
>>>>> .dtsi file (lan966x.dtsi in our case).
>>>>>
>>>>> What do you think about:
>>>>> - microchip,lan9662-udc
>>>>> - microchip,lan9668-udc
>>>>> - microchip,lan966-udc <-- Family
>>>>>
>>>>> lan966 is defined as the family compatible string since (1) in
>>>>> bindings/arm/atmel-at91.yaml and in Documentation/arm/microchip.rst
>>>>>
>>>>
>>>> You can add some family compatible, if it makes sense. I don't get why
>>>> do you mention it - we did not discuss family names, but using
>>>> wildcards... Just please do not add wildcards.
>>>
>>> Well, I mentioned it as I will only use the family compatible string
>>> and not the SOC (lan9662 or lan9668) compatible string in lan966x.dtsi.
>>> In this case, the family compatible string can be seen as a kind of
>>> "wildcard".
>>
>> I understood as "the "family" compatible should be present" as you want
>> to add it as a fallback. It would be okay (assuming devices indeed share
>> family design). If you want to use it as the only one, then it is again
>> not a recommended approach. Please use specific compatibles.
>>
>> I mean, why do we have this discussion? What is the benefit for you to
>> implement something not-recommended by Devicetree spec and style?
>>
>
> Honestly, I would just go for microchip,lan9662-udc. There is no
> difference between lan9662 and lan9668 apart from the number of switch
> ports.
Thank you, and maybe that was misunderstanding - I do not propose to add
additional lan9668 compatible, if it is not actually needed.
Best regards,
Krzysztof
On Fri, 20 May 2022 14:50:24 +0200
Krzysztof Kozlowski <[email protected]> wrote:
> On 20/05/2022 14:21, Herve Codina wrote:
> >>> I think it makes sense to keep 'microchip,lan966x-udc' for the USB
> >>> device controller (same controller on LAN9662 and LAN9668) and so
> >>> keeping the same rules as for other common parts.
> >>
> >> Having wildcard was rather a mistake and we already started correcting
> >> it, so keeping the "mistake" neither gives you consistency, nor
> >> correctness...
> >>
> >
> > I think that the "family" compatible should be present.
> > This one allows to define the common parts in the common
> > .dtsi file (lan966x.dtsi in our case).
> >
> > What do you think about:
> > - microchip,lan9662-udc
> > - microchip,lan9668-udc
> > - microchip,lan966-udc <-- Family
> >
> > lan966 is defined as the family compatible string since (1) in
> > bindings/arm/atmel-at91.yaml and in Documentation/arm/microchip.rst
> >
>
> You can add some family compatible, if it makes sense. I don't get why
> do you mention it - we did not discuss family names, but using
> wildcards... Just please do not add wildcards.
Well, I mentioned it as I will only use the family compatible string
and not the SOC (lan9662 or lan9668) compatible string in lan966x.dtsi.
In this case, the family compatible string can be seen as a kind of
"wildcard".
Regards,
Hervé
--
Hervé Codina, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com