* Re: [PATCH 1/8] ARM: dts: dra7: Add vbb-supply to cpu and additional voltages
From: Dave Gerlach @ 2017-12-21 15:40 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Nishanth Menon
In-Reply-To: <20171221151536.GR3875-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
On 12/21/2017 09:15 AM, Tony Lindgren wrote:
> * Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org> [171219 15:27]:
>> Add a vbb-supply phandle to the cpus node and also add an additional
>> triplet of voltages for each OPP in the operating-points-v2 table to
>> make use of the multi regulator support in the OPP core and provide the
>> vbb regulator for use by the ti-opp-supply driver.
>
> Sounds like these depend on the ti-opp-supply being available first?
>
Yes that would be best, but the ti-opp-supply patches are already in linux-next.
Regards,
Dave
> Regards,
>
> Tony
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: sunxi: Add sid for a83t
From: Chen-Yu Tsai @ 2017-12-21 15:39 UTC (permalink / raw)
To: Maxime Ripard
Cc: Kyle Evans, Srinivas Kandagatla, Rob Herring, Mark Rutland,
Chen-Yu Tsai, Russell King, devicetree, linux-arm-kernel,
linux-kernel, linux-sunxi
In-Reply-To: <20171221152630.2vf57x5o2yi5sv3n-ZC1Zs529Oq4@public.gmane.org>
On Thu, Dec 21, 2017 at 11:26 PM, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Hi,
>
> On Thu, Dec 21, 2017 at 09:19:24AM -0600, Kyle Evans wrote:
>> On Thu, Dec 21, 2017 at 8:55 AM, Maxime Ripard
>> <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>> > Hi Kyle,
>> >
>> > On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevans91-OYTqUY/oFF8@public.gmane.org wrote:
>> >> Allwinner a83t has a 1 KB sid block with efuse for security rootkey and
>> >> thermal calibration data, add node to describe it.
>> >>
>> >> a83t-sid is not currently supported by nvmem/sunxi-sid, but it is
>> >> supported in an external driver for FreeBSD.
>> >>
>> >> Signed-off-by: Kyle Evans <kevans91-OYTqUY/oFF8@public.gmane.org>
>> >
>> > The patch looks fine in itself, but we've had a number of issues with
>> > the register layout (and access patterns) in the past, so I'd rather
>> > have something that works in Linux too if possible.
>>
>> I have a patch that I think should make it work fine on Linux [1], but
>> I'm afraid I have little to no capability to test it myself and so I
>> did not add it as well.
>>
>> I do know that the rootkey is offset 0x200 into the given space [2],
>> as is the case with the H3, and that the readout quirk is not needed.
>> I wasn't 100% sure that the a83t has 2Kbit worth of efuse space as the
>> H3, but I do know that thermal data can be found at 0x34 and 0x38 in
>> this space.
>
> Then maybe we should leave it aside until someone takes some time on
> the A83t. The good news is that the binding itself looks fine, so as
> far as FreeBSD goes, there shouldn't be anything preventing you from
> using it I guess.
>
> Chen-Yu, what do you think?
Looks good to me.
ChenYu
^ permalink raw reply
* [PATCH] ARM: dts: ls1021a: add nodes for on-chip ram
From: Rasmus Villemoes @ 2017-12-21 15:38 UTC (permalink / raw)
To: Shawn Guo, Rob Herring, Mark Rutland, Russell King
Cc: Rasmus Villemoes, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Signed-off-by: Rasmus Villemoes <rasmus.villemoes-rjjw5hvvQKZaa/9Udqfwiw@public.gmane.org>
---
arch/arm/boot/dts/ls1021a.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index bd6622f10046..6f53e6aefb63 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -748,5 +748,21 @@
<0000 0 0 3 &gic GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>,
<0000 0 0 4 &gic GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>;
};
+
+ ocram1: sram@10000000 {
+ compatible = "mmio-sram";
+ reg = <0x0 0x10000000 0x0 0x10000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x10000000 0x10000>;
+ };
+
+ ocram2: sram@10010000 {
+ compatible = "mmio-sram";
+ reg = <0x0 0x10010000 0x0 0x10000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x10010000 0x10000>;
+ };
};
};
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2] ARM: dts: sunxi: Add sid for a83t
From: Kyle Evans @ 2017-12-21 15:30 UTC (permalink / raw)
To: Maxime Ripard
Cc: Srinivas Kandagatla, Rob Herring, Mark Rutland, Chen-Yu Tsai,
Russell King, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171221152630.2vf57x5o2yi5sv3n-ZC1Zs529Oq4@public.gmane.org>
On Thu, Dec 21, 2017 at 9:26 AM, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Hi,
>
> On Thu, Dec 21, 2017 at 09:19:24AM -0600, Kyle Evans wrote:
>> On Thu, Dec 21, 2017 at 8:55 AM, Maxime Ripard
>> <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>> > Hi Kyle,
>> >
>> > On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevans91-OYTqUY/oFF8@public.gmane.org wrote:
>> >> Allwinner a83t has a 1 KB sid block with efuse for security rootkey and
>> >> thermal calibration data, add node to describe it.
>> >>
>> >> a83t-sid is not currently supported by nvmem/sunxi-sid, but it is
>> >> supported in an external driver for FreeBSD.
>> >>
>> >> Signed-off-by: Kyle Evans <kevans91-OYTqUY/oFF8@public.gmane.org>
>> >
>> > The patch looks fine in itself, but we've had a number of issues with
>> > the register layout (and access patterns) in the past, so I'd rather
>> > have something that works in Linux too if possible.
>>
>> I have a patch that I think should make it work fine on Linux [1], but
>> I'm afraid I have little to no capability to test it myself and so I
>> did not add it as well.
>>
>> I do know that the rootkey is offset 0x200 into the given space [2],
>> as is the case with the H3, and that the readout quirk is not needed.
>> I wasn't 100% sure that the a83t has 2Kbit worth of efuse space as the
>> H3, but I do know that thermal data can be found at 0x34 and 0x38 in
>> this space.
>
> Then maybe we should leave it aside until someone takes some time on
> the A83t. The good news is that the binding itself looks fine, so as
> far as FreeBSD goes, there shouldn't be anything preventing you from
> using it I guess.
Yeah, we've had this exact binding in our own copy of DTS up until a
recent point when we flipped the switch to pulling DT from Mainline
Linux and trying to upstream changes instead of having a bunch of
local modifications in our tree.
> Chen-Yu, what do you think?
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/9] dt-bindings: ti-sysc: Update binding for timers and capabilities
From: Tony Lindgren @ 2017-12-21 15:29 UTC (permalink / raw)
To: Rob Herring
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA, Nishanth Menon,
devicetree-u79uwXL29TY76Z2rM5mHXA, Paul Walmsley, Dave Gerlach,
Tomi Valkeinen, Matthijs van Duin,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Liam Girdwood, Tero Kristo,
Mark Brown, Sakari Ailus, Laurent Pinchart, Benoît Cousson,
Mark Rutland, Mauro Carvalho Chehab,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20171220181051.eoftsww6463hyak3@rob-hp-laptop>
* Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> [171220 18:13]:
> On Sat, Dec 16, 2017 at 11:22:22AM -0800, Tony Lindgren wrote:
> > I was planning to have "ti,sysc-delay-us" only in the driver, but
> > the same IP needs it set on dm814x while not on omap4 for OTG
> > for example. I could add SoC specific quirks to the driver
> > for that one if you prefer that instead?
>
> No, I don't have a preference.
OK
> > > Are the bits you've defined all of them or there's more?
> >
> > That's it, with this binding I've allocated the data from dts
> > for the tests I've done. So that should allow us to replace the
> > static data to start with as seen with the following command:
> >
> > $ git grep -A10 "struct omap_hwmod_class_sysconfig" \
> > arch/arm/*hwmod*data*.c
> > ...
> >
> > So that's to configure a big pile of different module
> > configurations we currently have as can be seen with:
> >
> > $ git grep "struct omap_hwmod_class_sysconfig" \
> > arch/arm/*hwmod*data*.c | wc -l
> > 194
> >
> > I'm sure there's still few duplicates there though..
>
> Okay, then I guess I'm okay with this.
>
> Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
OK thanks for the review.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: sunxi: Add sid for a83t
From: Maxime Ripard @ 2017-12-21 15:26 UTC (permalink / raw)
To: Kyle Evans
Cc: Srinivas Kandagatla, Rob Herring, Mark Rutland, Chen-Yu Tsai,
Russell King, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <CACNAnaE9GiVTXD-TV1xXyBJKtTGKpdA6n0REk6a=qm218EgHbg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1685 bytes --]
Hi,
On Thu, Dec 21, 2017 at 09:19:24AM -0600, Kyle Evans wrote:
> On Thu, Dec 21, 2017 at 8:55 AM, Maxime Ripard
> <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> > Hi Kyle,
> >
> > On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevans91-OYTqUY/oFF8@public.gmane.org wrote:
> >> Allwinner a83t has a 1 KB sid block with efuse for security rootkey and
> >> thermal calibration data, add node to describe it.
> >>
> >> a83t-sid is not currently supported by nvmem/sunxi-sid, but it is
> >> supported in an external driver for FreeBSD.
> >>
> >> Signed-off-by: Kyle Evans <kevans91-OYTqUY/oFF8@public.gmane.org>
> >
> > The patch looks fine in itself, but we've had a number of issues with
> > the register layout (and access patterns) in the past, so I'd rather
> > have something that works in Linux too if possible.
>
> I have a patch that I think should make it work fine on Linux [1], but
> I'm afraid I have little to no capability to test it myself and so I
> did not add it as well.
>
> I do know that the rootkey is offset 0x200 into the given space [2],
> as is the case with the H3, and that the readout quirk is not needed.
> I wasn't 100% sure that the a83t has 2Kbit worth of efuse space as the
> H3, but I do know that thermal data can be found at 0x34 and 0x38 in
> this space.
Then maybe we should leave it aside until someone takes some time on
the A83t. The good news is that the binding itself looks fine, so as
far as FreeBSD goes, there shouldn't be anything preventing you from
using it I guess.
Chen-Yu, what do you think?
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 1/2] ARM: sun8i: v3s: add EHCI/OHCI0 device nodes
From: Maxime Ripard @ 2017-12-21 15:22 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171221150537.20304-2-icenowy-h8G6r0blFSE@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 878 bytes --]
On Thu, Dec 21, 2017 at 11:05:36PM +0800, Icenowy Zheng wrote:
> The USB PHY 0 on V3s SoC can also be routed to a pair of EHCI/OHCI
> controllers.
>
> Add the device nodes for the controllers.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> arch/arm/boot/dts/sun8i-v3s.dtsi | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
> index 443b083c6adc..cc315dc742d2 100644
> --- a/arch/arm/boot/dts/sun8i-v3s.dtsi
> +++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
> @@ -264,6 +264,25 @@
> #phy-cells = <1>;
> };
>
> + ehci0: usb@01c1a000 {
And you should also drop the leading zero on your two nodes
unit-address.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] Add EHCI/OHCI nodes for V3s and Lichee Pi Zero
From: Maxime Ripard @ 2017-12-21 15:21 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171221150537.20304-1-icenowy-h8G6r0blFSE@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 430 bytes --]
On Thu, Dec 21, 2017 at 11:05:35PM +0800, Icenowy Zheng wrote:
> As the PHY dual-route property is added to 4.15-rc, the EHCI/OHCI nodes
> are now necessary.
>
> Please apply these patches to 4.15, Thanks!
There's no reason to have it merged in 4.15. It's not a regression,
so 4.15 should work just as 4.14 worked, right?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: Document mti,mips-cpc binding
From: Aleksandar Markovic @ 2017-12-21 15:20 UTC (permalink / raw)
To: linux-mips-6z/3iImG2C8G8FEW9MqTrA
Cc: Paul Burton, Aleksandar Markovic,
devicetree-u79uwXL29TY76Z2rM5mHXA, Douglas Leung, Goran Ferenc,
James Hogan, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
Miodrag Dinic, Petar Jovanovic, Raghu Gandham, Rob Herring
In-Reply-To: <1513869627-15391-1-git-send-email-aleksandar.markovic-FblTVreYubkAvxtiuMwx3w@public.gmane.org>
From: Paul Burton <paul.burton-8NJIiSa5LzA@public.gmane.org>
Document a binding for the MIPS Cluster Power Controller (CPC) which
simply allows the device tree to specify where the CPC registers are
located.
Signed-off-by: Paul Burton <paul.burton-8NJIiSa5LzA@public.gmane.org>
Signed-off-by: Aleksandar Markovic <aleksandar.markovic-8NJIiSa5LzA@public.gmane.org>
---
Documentation/devicetree/bindings/misc/mti,mips-cpc.txt | 8 ++++++++
1 file changed, 8 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/mti,mips-cpc.txt
diff --git a/Documentation/devicetree/bindings/misc/mti,mips-cpc.txt b/Documentation/devicetree/bindings/misc/mti,mips-cpc.txt
new file mode 100644
index 0000000..c6b8251
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/mti,mips-cpc.txt
@@ -0,0 +1,8 @@
+Binding for MIPS Cluster Power Controller (CPC).
+
+This binding allows a system to specify where the CPC registers are
+located.
+
+Required properties:
+compatible : Should be "mti,mips-cpc".
+regs: Should describe the address & size of the CPC register region.
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2] ARM: dts: sunxi: Add sid for a83t
From: Kyle Evans @ 2017-12-21 15:19 UTC (permalink / raw)
To: Maxime Ripard
Cc: Srinivas Kandagatla, Rob Herring, Mark Rutland, Chen-Yu Tsai,
Russell King, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171221145512.llxvzkcrjpquhczi-ZC1Zs529Oq4@public.gmane.org>
On Thu, Dec 21, 2017 at 8:55 AM, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Hi Kyle,
>
> On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevans91-OYTqUY/oFF8@public.gmane.org wrote:
>> Allwinner a83t has a 1 KB sid block with efuse for security rootkey and
>> thermal calibration data, add node to describe it.
>>
>> a83t-sid is not currently supported by nvmem/sunxi-sid, but it is
>> supported in an external driver for FreeBSD.
>>
>> Signed-off-by: Kyle Evans <kevans91-OYTqUY/oFF8@public.gmane.org>
>
> The patch looks fine in itself, but we've had a number of issues with
> the register layout (and access patterns) in the past, so I'd rather
> have something that works in Linux too if possible.
Hello!
I have a patch that I think should make it work fine on Linux [1], but
I'm afraid I have little to no capability to test it myself and so I
did not add it as well.
I do know that the rootkey is offset 0x200 into the given space [2],
as is the case with the H3, and that the readout quirk is not needed.
I wasn't 100% sure that the a83t has 2Kbit worth of efuse space as the
H3, but I do know that thermal data can be found at 0x34 and 0x38 in
this space.
[1] https://people.freebsd.org/~kevans/sunxi-sid.diff
[2] https://svnweb.freebsd.org/base/head/sys/arm/allwinner/aw_sid.c?view=markup#l56
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: renesas: ulcb: Remove renesas,no-ether-link property
From: Vladimir Zapolskiy @ 2017-12-21 15:18 UTC (permalink / raw)
To: Simon Horman, Sergei Shtylyov
Cc: Bogdan Mirea, linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1513869539-18803-1-git-send-email-vladimir_zapolskiy-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
From: Bogdan Mirea <Bogdan-Stefan_Mirea-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
The present change is a bug fix for AVB link iteratively up/down.
Steps to reproduce:
- start AVB TX stream (Using aplay via MSE),
- disconnect+reconnect the eth cable,
- after a reconnection the eth connection goes iteratively up/down
without user interaction,
- this may heal after some seconds or even stay for minutes.
As the documentation specifies, the "renesas,no-ether-link" option
should be used when a board does not provide a proper AVB_LINK signal.
There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
and ULCB starter kits since the AVB_LINK is correctly handled by HW.
Choosing to keep or remove the "renesas,no-ether-link" option will
have impact on the code flow in the following ways:
- keeping this option enabled may lead to unexpected behavior since
the RX & TX are enabled/disabled directly from adjust_link function
without any HW interrogation,
- removing this option, the RX & TX will only be enabled/disabled after
HW interrogation. The HW check is made through the LMON pin in PSR
register which specifies AVB_LINK signal value (0 - at low level;
1 - at high level).
In conclusion, the present change is also a safety improvement because
it removes the "renesas,no-ether-link" option leading to a proper way
of detecting the link state based on HW interrogation and not on
software heuristic.
Fixes: 253ed045a34d ("arm64: dts: renesas: Extract common ULCB board support")
Signed-off-by: Bogdan Mirea <Bogdan-Stefan_Mirea-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
---
arch/arm64/boot/dts/renesas/ulcb.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/ulcb.dtsi b/arch/arm64/boot/dts/renesas/ulcb.dtsi
index be91016e0b48..3e7a6b94e9f8 100644
--- a/arch/arm64/boot/dts/renesas/ulcb.dtsi
+++ b/arch/arm64/boot/dts/renesas/ulcb.dtsi
@@ -145,7 +145,6 @@
&avb {
pinctrl-0 = <&avb_pins>;
pinctrl-names = "default";
- renesas,no-ether-link;
phy-handle = <&phy0>;
status = "okay";
--
2.8.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 1/2] arm64: dts: renesas: salvator-x: Remove renesas,no-ether-link property
From: Vladimir Zapolskiy @ 2017-12-21 15:18 UTC (permalink / raw)
To: Simon Horman, Sergei Shtylyov
Cc: Bogdan Mirea, linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1513869539-18803-1-git-send-email-vladimir_zapolskiy-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
From: Bogdan Mirea <Bogdan-Stefan_Mirea-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
The present change is a bug fix for AVB link iteratively up/down.
Steps to reproduce:
- start AVB TX stream (Using aplay via MSE),
- disconnect+reconnect the eth cable,
- after a reconnection the eth connection goes iteratively up/down
without user interaction,
- this may heal after some seconds or even stay for minutes.
As the documentation specifies, the "renesas,no-ether-link" option
should be used when a board does not provide a proper AVB_LINK signal.
There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
and ULCB starter kits since the AVB_LINK is correctly handled by HW.
Choosing to keep or remove the "renesas,no-ether-link" option will
have impact on the code flow in the following ways:
- keeping this option enabled may lead to unexpected behavior since
the RX & TX are enabled/disabled directly from adjust_link function
without any HW interrogation,
- removing this option, the RX & TX will only be enabled/disabled after
HW interrogation. The HW check is made through the LMON pin in PSR
register which specifies AVB_LINK signal value (0 - at low level;
1 - at high level).
In conclusion, the present change is also a safety improvement because
it removes the "renesas,no-ether-link" option leading to a proper way
of detecting the link state based on HW interrogation and not on
software heuristic.
Fixes: d25e8ff0d5aa ("arm64: dts: renesas: Extract common Salvator-X board support")
Signed-off-by: Bogdan Mirea <Bogdan-Stefan_Mirea-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
---
arch/arm64/boot/dts/renesas/salvator-common.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
index 4e800e933944..c3095bd575d7 100644
--- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
+++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
@@ -255,7 +255,6 @@
&avb {
pinctrl-0 = <&avb_pins>;
pinctrl-names = "default";
- renesas,no-ether-link;
phy-handle = <&phy0>;
status = "okay";
--
2.8.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 0/2] arm64: dts: renesas: Remove renesas,no-ether-link property
From: Vladimir Zapolskiy @ 2017-12-21 15:18 UTC (permalink / raw)
To: Simon Horman, Sergei Shtylyov
Cc: Bogdan Mirea, linux-renesas-soc, devicetree, linux-arm-kernel
The present change is a bug fix for AVB link iteratively up/down.
Steps to reproduce:
- start AVB TX stream (Using aplay via MSE),
- disconnect+reconnect the eth cable,
- after a reconnection the eth connection goes iteratively up/down
without user interaction,
- this may heal after some seconds or even stay for minutes.
As the documentation specifies, the "renesas,no-ether-link" option
should be used when a board does not provide a proper AVB_LINK signal.
There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
and ULCB starter kits since the AVB_LINK is correctly handled by HW.
Choosing to keep or remove the "renesas,no-ether-link" option will
have impact on the code flow in the following ways:
- keeping this option enabled may lead to unexpected behavior since
the RX & TX are enabled/disabled directly from adjust_link function
without any HW interrogation,
- removing this option, the RX & TX will only be enabled/disabled after
HW interrogation. The HW check is made through the LMON pin in PSR
register which specifies AVB_LINK signal value (0 - at low level;
1 - at high level).
In conclusion, the change is also a safety improvement because it
removes the "renesas,no-ether-link" option leading to a proper way
of detecting the link state based on HW interrogation and not on
software heuristic.
Note that DTS files for V3M Starter Kit, Draak and Eagle boards
contain the same property, the files are untouched due to unavailable
schematics to verify if the fix applies to these boards as well.
Changes from v1 to v2:
* per a request from Simon added Fixes tags to both changes,
the specified commits generalize Salvator-X and ULCB dtsi files
and the fixes should be applicable without a conflict, however
similar but virtually different fixes can be spread into Salvator-X
and ULCB board DTS files of older kernel revisions as well.
Bogdan Mirea (2):
arm64: dts: renesas: salvator-x: Remove renesas,no-ether-link property
arm64: dts: renesas: ulcb: Remove renesas,no-ether-link property
arch/arm64/boot/dts/renesas/salvator-common.dtsi | 1 -
arch/arm64/boot/dts/renesas/ulcb.dtsi | 1 -
2 files changed, 2 deletions(-)
--
2.8.1
^ permalink raw reply
* Re: [PATCH 1/3] ARM: dts: am335x-boneblue: fix wl1835 IRQ pin
From: Tony Lindgren @ 2017-12-21 15:18 UTC (permalink / raw)
To: Robert Nelson
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jason Kridner,
Drew Fustini
In-Reply-To: <20171219223242.21386-1-robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
* Robert Nelson <robertcnelson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [171219 14:35]:
> Use the correct IRQ gpio pin on the BeagleBone Blue to allow the
> wl1835 wireless module to actually work.
Thanks applying all three into omap-for-v4.16/dt.
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 0/4] arm64: defconfig: enable additional led triggers
From: Arnd Bergmann @ 2017-12-21 15:16 UTC (permalink / raw)
To: Amit Kucheria
Cc: LKML, Andy Gross, linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, lakml,
Wei Xu, Manivannan Sadhasivam, DTML, Timur Tabi
In-Reply-To: <CAHLCerN4sYpU7PJG7JLhAy644s3jz9KD_myKWfOoOkEResPu-Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Dec 6, 2017 at 9:57 AM, Amit Kucheria <amit.kucheria-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> (Adding Arnd)
>
> Now that the merge window rush has abated, can you please apply this
> trivial series?
>
> On Mon, Nov 6, 2017 at 12:38 PM, Amit Kucheria <amit.kucheria-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> This patchset enables the kernel panic and disk-activity trigger for LEDs
>> and then enables the panic trigger for three 96Boards - DB410c, Hikey and
>> Hikey960.
>>
>> DB410c and Hikey panic behaviour has been tested by triggering a panic
>> through /proc/sysrq-trigger, while Hikey960 is only compile-tested.
I applied all four now, but it would have been easier for me if you had either
sent them to the platform maintainers, or to arm-DgEjT+Ai2yi4UlQgPVntAg@public.gmane.org
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] ARM: sun8i: v3s: add EHCI/OHCI0 device nodes
From: Maxime Ripard @ 2017-12-21 15:16 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Chen-Yu Tsai, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20171221150537.20304-2-icenowy-h8G6r0blFSE@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]
Hi,
On Thu, Dec 21, 2017 at 11:05:36PM +0800, Icenowy Zheng wrote:
> The USB PHY 0 on V3s SoC can also be routed to a pair of EHCI/OHCI
> controllers.
>
> Add the device nodes for the controllers.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> arch/arm/boot/dts/sun8i-v3s.dtsi | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
> index 443b083c6adc..cc315dc742d2 100644
> --- a/arch/arm/boot/dts/sun8i-v3s.dtsi
> +++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
> @@ -264,6 +264,25 @@
> #phy-cells = <1>;
> };
>
> + ehci0: usb@01c1a000 {
> + compatible = "allwinner,sun8i-v3s-ehci", "generic-ehci";
> + reg = <0x01c1a000 0x100>;
> + interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_EHCI0>, <&ccu CLK_BUS_OHCI0>;
> + resets = <&ccu RST_BUS_EHCI0>, <&ccu RST_BUS_OHCI0>;
Why are you taking the OHCI clocks and resets in the OHCI node..
> + status = "disabled";
> + };
> +
> + ohci0: usb@01c1a400 {
> + compatible = "allwinner,sun8i-v3s-ohci", "generic-ohci";
> + reg = <0x01c1a400 0x100>;
> + interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_EHCI0>, <&ccu CLK_BUS_OHCI0>,
> + <&ccu CLK_USB_OHCI0>;
> + resets = <&ccu RST_BUS_EHCI0>, <&ccu RST_BUS_OHCI0>;
... And the EHCI clocks and resets in the OHCI node?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/8] ARM: dts: dra7: Add vbb-supply to cpu and additional voltages
From: Tony Lindgren @ 2017-12-21 15:15 UTC (permalink / raw)
To: Dave Gerlach
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Nishanth Menon
In-Reply-To: <1513697066-27732-2-git-send-email-d-gerlach-l0cyMroinI0@public.gmane.org>
* Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org> [171219 15:27]:
> Add a vbb-supply phandle to the cpus node and also add an additional
> triplet of voltages for each OPP in the operating-points-v2 table to
> make use of the multi regulator support in the OPP core and provide the
> vbb regulator for use by the ti-opp-supply driver.
Sounds like these depend on the ti-opp-supply being available first?
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/7] ARM: dts: dra7: Enable x2 lane mode support
From: Tony Lindgren @ 2017-12-21 15:13 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: bcousson, Rob Herring, Mark Rutland, Russell King, linux-pci,
devicetree, linux-kernel, linux-omap, linux-arm-kernel, nsekhar
In-Reply-To: <20171219093133.16565-1-kishon@ti.com>
* Kishon Vijay Abraham I <kishon@ti.com> [171219 01:34]:
> Add properties to enable PCIe x2 lane mode since all dra7
> based SoCs support x2 lane mode.
>
> However only dra76-evm has a slot which can support x2 lane
> cards. Hence only enable x2 lane mode in dra76-evm.
> (am571x-idk can support x2 lane mode but that makes usb port
> not functional so not including the patch to enable
> x2 mode in am571x-idk)
>
> Also included in this series is patch to enable PCIe configs
> (both host and device) in omap2plus_defconfig and
> multi_v7_defconfig
>
> In order to get x2 mode working [1] is required.
>
> However by keeping the older compatible, this series won't
> break functionality if this series is merged before [1]
OK applying into omap-for-v4.16/dt and omap-for-v4.16/defconfig.
Thanks,
Tony
^ permalink raw reply
* Re: [PATCH] ARM: make ARCH_S3C24XX select USE_OF and clean-up boot/dts/Makefile
From: Arnd Bergmann @ 2017-12-21 15:11 UTC (permalink / raw)
To: Masahiro Yamada
Cc: arm-soc, Olof Johansson, Mark Rutland, DTML,
Linux Kernel Mailing List, Russell King, Rob Herring, Linux ARM
In-Reply-To: <1511749163-11057-1-git-send-email-yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
On Mon, Nov 27, 2017 at 3:19 AM, Masahiro Yamada
<yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org> wrote:
> ARCH_S3C24XX is a very exceptional platform that some DT files in
> arch/arm/boot/dts/, but does not select USE_OF.
>
> All the other platforms with DT files correctly select USE_OF
> directly or indirectly (Most of them are either ARCH_MULTIPLATFORM
> or ARM_SINGLE_ARMV7M).
>
> With ARCH_S3C24XX fixed, "ifeq ($(CONFIG_OF),y)" in DT Makefile
> can be deleted.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro-uWyLwvC0a2jby3iVrkZq2A@public.gmane.org>
Applied to next/dt, thanks!
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RESEND PATCH 4/4] ARM: dts: socfpga: Add generic compatible string for I2C EEPROM
From: Arnd Bergmann @ 2017-12-21 15:08 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Linux Kernel Mailing List, Olof Johansson, arm-soc, DTML,
Dinh Nguyen, Rob Herring, Mark Rutland, Russell King, Linux ARM
In-Reply-To: <20171124162750.18756-4-javierm@redhat.com>
On Fri, Nov 24, 2017 at 5:27 PM, Javier Martinez Canillas
<javierm@redhat.com> wrote:
> The at24 driver allows to register I2C EEPROM chips using different vendor
> and devices, but the I2C subsystem does not take the vendor into account
> when matching using the I2C table since it only has device entries.
>
> But when matching using an OF table, both the vendor and device has to be
> taken into account so the driver defines only a set of compatible strings
> using the "atmel" vendor as a generic fallback for compatible I2C devices.
>
> So add this generic fallback to the device node compatible string to make
> the device to match the driver using the OF device ID table.
>
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Applied, thanks!
Arnd
^ permalink raw reply
* Re: [RESEND PATCH 3/4] ARM: dts: lpc18xx: Add generic compatible string for I2C EEPROM
From: Arnd Bergmann @ 2017-12-21 15:08 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Linux Kernel Mailing List, Olof Johansson, arm-soc, DTML,
Joachim Eastwood, Rob Herring, Mark Rutland, Russell King,
Linux ARM
In-Reply-To: <20171124162750.18756-3-javierm@redhat.com>
On Fri, Nov 24, 2017 at 5:27 PM, Javier Martinez Canillas
<javierm@redhat.com> wrote:
> The at24 driver allows to register I2C EEPROM chips using different vendor
> and devices, but the I2C subsystem does not take the vendor into account
> when matching using the I2C table since it only has device entries.
>
> But when matching using an OF table, both the vendor and device has to be
> taken into account so the driver defines only a set of compatible strings
> using the "atmel" vendor as a generic fallback for compatible I2C devices.
>
> So add this generic fallback to the device node compatible string to make
> the device to match the driver using the OF device ID table.
>
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Applied, thanks
Arnd
^ permalink raw reply
* Re: [PATCH 0/3] ARM: am57xx: Add support for am574x-idk
From: Tony Lindgren @ 2017-12-21 15:07 UTC (permalink / raw)
To: Lokesh Vutla
Cc: Linux OMAP Mailing List, Tero Kristo, Sekhar Nori, Rob Herring,
Device Tree Mailing List
In-Reply-To: <20171218062003.9024-1-lokeshvutla-l0cyMroinI0@public.gmane.org>
* Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org> [171217 22:23]:
> am574x-idk board is similar to am572x-idk with am574x SoC.
> This series adds support for this board.
Applying these into omap-for-v4.16/soc and omap-for-v4.16/dt
branches.
Thanks,
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RESEND PATCH 1/4] ARM: dts: efm32: Add generic compatible string for I2C EEPROM
From: Arnd Bergmann @ 2017-12-21 15:06 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Linux Kernel Mailing List, Olof Johansson, arm-soc, DTML,
Rob Herring, Mark Rutland, Russell King, Linux ARM
In-Reply-To: <20171124162750.18756-1-javierm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Fri, Nov 24, 2017 at 5:27 PM, Javier Martinez Canillas
<javierm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> The at24 driver allows to register I2C EEPROM chips using different vendor
> and devices, but the I2C subsystem does not take the vendor into account
> when matching using the I2C table since it only has device entries.
>
> But when matching using an OF table, both the vendor and device has to be
> taken into account so the driver defines only a set of compatible strings
> using the "atmel" vendor as a generic fallback for compatible I2C devices.
>
> So add this generic fallback to the device node compatible string to make
> the device to match the driver using the OF device ID table.
>
> Signed-off-by: Javier Martinez Canillas <javierm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Applied to next/dt, thanks
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 2/2] ARM: sun8i: v3s: enable EHCI/OHCI for Lichee Pi Zero
From: Icenowy Zheng @ 2017-12-21 15:05 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20171221150537.20304-1-icenowy-h8G6r0blFSE@public.gmane.org>
As the USB port on Lichee Pi Zero works in the OTG mode, enable the
EHCI/OHCI controllers for it.
Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
---
arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
index 387fc2aa546d..cf2d9fe3bbb7 100644
--- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
+++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
@@ -77,6 +77,10 @@
};
};
+&ehci0 {
+ status = "okay";
+};
+
&mmc0 {
pinctrl-0 = <&mmc0_pins_a>;
pinctrl-names = "default";
@@ -86,6 +90,10 @@
status = "okay";
};
+&ohci0 {
+ status = "okay";
+};
+
&uart0 {
pinctrl-0 = <&uart0_pins_a>;
pinctrl-names = "default";
--
2.14.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 1/2] ARM: sun8i: v3s: add EHCI/OHCI0 device nodes
From: Icenowy Zheng @ 2017-12-21 15:05 UTC (permalink / raw)
To: Maxime Ripard, Chen-Yu Tsai
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Icenowy Zheng
In-Reply-To: <20171221150537.20304-1-icenowy-h8G6r0blFSE@public.gmane.org>
The USB PHY 0 on V3s SoC can also be routed to a pair of EHCI/OHCI
controllers.
Add the device nodes for the controllers.
Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 443b083c6adc..cc315dc742d2 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -264,6 +264,25 @@
#phy-cells = <1>;
};
+ ehci0: usb@01c1a000 {
+ compatible = "allwinner,sun8i-v3s-ehci", "generic-ehci";
+ reg = <0x01c1a000 0x100>;
+ interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_EHCI0>, <&ccu CLK_BUS_OHCI0>;
+ resets = <&ccu RST_BUS_EHCI0>, <&ccu RST_BUS_OHCI0>;
+ status = "disabled";
+ };
+
+ ohci0: usb@01c1a400 {
+ compatible = "allwinner,sun8i-v3s-ohci", "generic-ohci";
+ reg = <0x01c1a400 0x100>;
+ interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_EHCI0>, <&ccu CLK_BUS_OHCI0>,
+ <&ccu CLK_USB_OHCI0>;
+ resets = <&ccu RST_BUS_EHCI0>, <&ccu RST_BUS_OHCI0>;
+ status = "disabled";
+ };
+
ccu: clock@1c20000 {
compatible = "allwinner,sun8i-v3s-ccu";
reg = <0x01c20000 0x400>;
--
2.14.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox