[PATCH 1/2] arm64: dts: allwinner: Olimex A64-OLinuXino: enable eMMC.

[PATCH 1/2] arm64: dts: allwinner: Olimex A64-OLinuXino: enable eMMC.

[Rodrigo Exterckötter Tjäder]

Copied snippet from A64-TERES I.

Signed-off-by: Rodrigo Exterckötter Tjäder <rodrigo@tjader.xyz>
---
 .../arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
index 657f58def54c..5245de3a1f35 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-olinuxino.dts
@@ -128,6 +128,17 @@
 	};
 };
 
+&mmc2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc2_pins>;
+	vmmc-supply = <&reg_dcdc1>;
+	vqmmc-supply = <&reg_dcdc1>;
+	bus-width = <8>;
+	non-removable;
+	cap-mmc-hw-reset;
+	status = "okay";
+};
+
 &ohci0 {
 	status = "okay";
 };
-- 
2.18.0

Re: [PATCH 1/2] arm64: dts: allwinner: Olimex A64-OLinuXino: enable eMMC.

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 503 bytes --]

Hi!

On Wed, Sep 19, 2018 at 11:18:13AM -0300, Rodrigo Exterckötter Tjäder wrote:
> Copied snippet from A64-TERES I.
> 
> Signed-off-by: Rodrigo Exterckötter Tjäder <rodrigo@tjader.xyz>

Expanding a bit more that commit log would be helpful. What is the
eMMC connected to that board? Do all versions have it? Which modes are
supposed to be supported, and which one have been tested?

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 1/2] arm64: dts: allwinner: Olimex A64-OLinuXino: enable eMMC.

[Rodrigo Exterckötter Tjäder]

On Fri, Sep 21, 2018 at 11:28 AM Maxime Ripard
<maxime.ripard@bootlin.com> wrote:
> Expanding a bit more that commit log would be helpful. What is the
> eMMC connected to that board? Do all versions have it? Which modes are
> supposed to be supported, and which one have been tested?

The terseness of the commit message was already pointed out to me on
#linux-sunxi. I was waiting for more comments before sending a v2.

But you do touch on something I also realized: there are actually
three versions of the A64-OLinuXino. In fact only one of them has the
WiFi board, which is already enabled in the current device tree.
Wouldn't it be better to split it into three separate device trees? I
have made a patch that does that[1], if you think that is a good
approach I can submit that as a patch and then later submit a patch on
top of that to enable the eMMC only on the two boards that have it.

I only have the A64-OLinuXino model that has both eMMC and WiFi. I
have tested all three of the split device trees on it and they worked
as expected.

[1] https://github.com/RodrigoTjader/linux/commit/9f7cb025afbcb4b40d24c038fd976c7090d87d24

Re: [PATCH 1/2] arm64: dts: allwinner: Olimex A64-OLinuXino: enable eMMC.

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 1312 bytes --]

On Fri, Sep 21, 2018 at 11:54:07AM -0300, Rodrigo Exterckötter Tjäder wrote:
> On Fri, Sep 21, 2018 at 11:28 AM Maxime Ripard
> <maxime.ripard@bootlin.com> wrote:
> > Expanding a bit more that commit log would be helpful. What is the
> > eMMC connected to that board? Do all versions have it? Which modes are
> > supposed to be supported, and which one have been tested?
> 
> The terseness of the commit message was already pointed out to me on
> #linux-sunxi. I was waiting for more comments before sending a v2.
> 
> But you do touch on something I also realized: there are actually
> three versions of the A64-OLinuXino. In fact only one of them has the
> WiFi board, which is already enabled in the current device tree.

Sigh, ok..

> Wouldn't it be better to split it into three separate device trees? I
> have made a patch that does that[1], if you think that is a good
> approach I can submit that as a patch and then later submit a patch on
> top of that to enable the eMMC only on the two boards that have it.

We can't really do that, unfortunately. If the device tree name was to
change for a given board, we'd break all the build systems, boot
scripts and distros out there.

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 1/2] arm64: dts: allwinner: Olimex A64-OLinuXino: enable eMMC.

[Rodrigo Exterckötter Tjäder]

On Tue, Sep 25, 2018 at 6:01 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> We can't really do that, unfortunately. If the device tree name was to
> change for a given board, we'd break all the build systems, boot
> scripts and distros out there.

What if we keep the device tree for the version without WiFi and eMMC
with the current name and create new device trees for the other two
versions?

Re: [PATCH 1/2] arm64: dts: allwinner: Olimex A64-OLinuXino: enable eMMC.

[Maxime Ripard]

On Tue, Sep 25, 2018 at 02:47:59PM -0300, Rodrigo Exterckötter Tjäder wrote:
> On Tue, Sep 25, 2018 at 6:01 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > We can't really do that, unfortunately. If the device tree name was to
> > change for a given board, we'd break all the build systems, boot
> > scripts and distros out there.
> 
> What if we keep the device tree for the version without WiFi and eMMC
> with the current name and create new device trees for the other two
> versions?

Wifi and Bluetooth should be dealt with with overlays in this case,
and since the eMMC is already enabled, then there's nothing to do, I
guess.

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH 1/2] arm64: dts: allwinner: Olimex A64-OLinuXino: enable eMMC.

[Rodrigo Exterckötter Tjäder]

On Thu, Sep 27, 2018 at 5:17 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Tue, Sep 25, 2018 at 02:47:59PM -0300, Rodrigo Exterckötter Tjäder wrote:
> > On Tue, Sep 25, 2018 at 6:01 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > We can't really do that, unfortunately. If the device tree name was to
> > > change for a given board, we'd break all the build systems, boot
> > > scripts and distros out there.
> >
> > What if we keep the device tree for the version without WiFi and eMMC
> > with the current name and create new device trees for the other two
> > versions?
>
> Wifi and Bluetooth should be dealt with with overlays in this case,
> and since the eMMC is already enabled, then there's nothing to do, I
> guess.

It's WiFi that is already enabled, not eMMC. Only one of the three
variants has WiFi.

We can't even remove a node from a device tree? Removing the WiFi node
from the current tree would make it correspond to the variant with the
least features.

About device tree overlays, I read overlay-notes.txt, but I went
looking for an example with "git grep /plugin/ arch" and it came
empty. Is this approach not used for other boards?

Does the overlay approach make the device available at boot time? That
is important for a storage device such as eMMC.

I went with the separate dts approach because that's what I saw was
done for other similar cases, like Pine64 and Pine64+, OLinuXino-LIME2
and its variant with eMMC, among others.

Re: [PATCH 1/2] arm64: dts: allwinner: Olimex A64-OLinuXino: enable eMMC.

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2164 bytes --]

On Thu, Sep 27, 2018 at 11:49:20AM -0300, Rodrigo Exterckötter Tjäder wrote:
> On Thu, Sep 27, 2018 at 5:17 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> >
> > On Tue, Sep 25, 2018 at 02:47:59PM -0300, Rodrigo Exterckötter Tjäder wrote:
> > > On Tue, Sep 25, 2018 at 6:01 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > > We can't really do that, unfortunately. If the device tree name was to
> > > > change for a given board, we'd break all the build systems, boot
> > > > scripts and distros out there.
> > >
> > > What if we keep the device tree for the version without WiFi and eMMC
> > > with the current name and create new device trees for the other two
> > > versions?
> >
> > Wifi and Bluetooth should be dealt with with overlays in this case,
> > and since the eMMC is already enabled, then there's nothing to do, I
> > guess.
> 
> It's WiFi that is already enabled, not eMMC. Only one of the three
> variants has WiFi.

Ah, right, sorry. In the board that doesn't have an emmc, are the pins
usable for something else?

> We can't even remove a node from a device tree? Removing the WiFi node
> from the current tree would make it correspond to the variant with the
> least features.

Not really. How pissed would you be if you were a user, had wifi
running on your board, you upgrade your kernel, and then it's just
gone? :)

> About device tree overlays, I read overlay-notes.txt, but I went
> looking for an example with "git grep /plugin/ arch" and it came
> empty. Is this approach not used for other boards?

It is, it's simply not stored in the kernel, but through other third
party repos.

> Does the overlay approach make the device available at boot time? That
> is important for a storage device such as eMMC.
> 
> I went with the separate dts approach because that's what I saw was
> done for other similar cases, like Pine64 and Pine64+, OLinuXino-LIME2
> and its variant with eMMC, among others.

Yeah, but in all these cases, it was done from day one, not after the
facts.

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 1/2] arm64: dts: allwinner: Olimex A64-OLinuXino: enable eMMC.

[Rodrigo Exterckötter Tjäder]

On Sat, Sep 29, 2018 at 12:47 PM Maxime Ripard
<maxime.ripard@bootlin.com> wrote:
>
> On Thu, Sep 27, 2018 at 11:49:20AM -0300, Rodrigo Exterckötter Tjäder wrote:
> > On Thu, Sep 27, 2018 at 5:17 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > >
> > > On Tue, Sep 25, 2018 at 02:47:59PM -0300, Rodrigo Exterckötter Tjäder wrote:
> > > > On Tue, Sep 25, 2018 at 6:01 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > > > We can't really do that, unfortunately. If the device tree name was to
> > > > > change for a given board, we'd break all the build systems, boot
> > > > > scripts and distros out there.
> > > >
> > > > What if we keep the device tree for the version without WiFi and eMMC
> > > > with the current name and create new device trees for the other two
> > > > versions?
> > >
> > > Wifi and Bluetooth should be dealt with with overlays in this case,
> > > and since the eMMC is already enabled, then there's nothing to do, I
> > > guess.
> >
> > It's WiFi that is already enabled, not eMMC. Only one of the three
> > variants has WiFi.
>
> Ah, right, sorry. In the board that doesn't have an emmc, are the pins
> usable for something else?

I don't have the variant without eMMC nor could I find pictures of it.
The schematics do mention that the A64 pins could be used to control
NAND flash, but you'd have to solder that yourself.

> > We can't even remove a node from a device tree? Removing the WiFi node
> > from the current tree would make it correspond to the variant with the
> > least features.
>
> Not really. How pissed would you be if you were a user, had wifi
> running on your board, you upgrade your kernel, and then it's just
> gone? :)

That would suck, but what about someone who has the board with no wifi
and problems start happening because the wifi is enabled on the device
tree?

> > About device tree overlays, I read overlay-notes.txt, but I went
> > looking for an example with "git grep /plugin/ arch" and it came
> > empty. Is this approach not used for other boards?
>
> It is, it's simply not stored in the kernel, but through other third
> party repos.

So that would mean that it's up to every distro to support the boards
instead of relying on mainline support?

> > Does the overlay approach make the device available at boot time? That
> > is important for a storage device such as eMMC.
> >
> > I went with the separate dts approach because that's what I saw was
> > done for other similar cases, like Pine64 and Pine64+, OLinuXino-LIME2
> > and its variant with eMMC, among others.
>
> Yeah, but in all these cases, it was done from day one, not after the
> facts.

For the LIME2 the dts for the emmc variant was commited two years
after the base LIME2 dts.


What if instead of keeping the current dt for the least featureful
model we keep it for the most featureful model and create new dts for
the two less featureful models?

Re: [PATCH 1/2] arm64: dts: allwinner: Olimex A64-OLinuXino: enable eMMC.

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 3670 bytes --]

On Sat, Sep 29, 2018 at 01:51:02PM -0300, Rodrigo Exterckötter Tjäder wrote:
> On Sat, Sep 29, 2018 at 12:47 PM Maxime Ripard
> <maxime.ripard@bootlin.com> wrote:
> >
> > On Thu, Sep 27, 2018 at 11:49:20AM -0300, Rodrigo Exterckötter Tjäder wrote:
> > > On Thu, Sep 27, 2018 at 5:17 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > >
> > > > On Tue, Sep 25, 2018 at 02:47:59PM -0300, Rodrigo Exterckötter Tjäder wrote:
> > > > > On Tue, Sep 25, 2018 at 6:01 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > > > > > We can't really do that, unfortunately. If the device tree name was to
> > > > > > change for a given board, we'd break all the build systems, boot
> > > > > > scripts and distros out there.
> > > > >
> > > > > What if we keep the device tree for the version without WiFi and eMMC
> > > > > with the current name and create new device trees for the other two
> > > > > versions?
> > > >
> > > > Wifi and Bluetooth should be dealt with with overlays in this case,
> > > > and since the eMMC is already enabled, then there's nothing to do, I
> > > > guess.
> > >
> > > It's WiFi that is already enabled, not eMMC. Only one of the three
> > > variants has WiFi.
> >
> > Ah, right, sorry. In the board that doesn't have an emmc, are the pins
> > usable for something else?
> 
> I don't have the variant without eMMC nor could I find pictures of it.
> The schematics do mention that the A64 pins could be used to control
> NAND flash, but you'd have to solder that yourself.

Ok.

> > > We can't even remove a node from a device tree? Removing the WiFi node
> > > from the current tree would make it correspond to the variant with the
> > > least features.
> >
> > Not really. How pissed would you be if you were a user, had wifi
> > running on your board, you upgrade your kernel, and then it's just
> > gone? :)
> 
> That would suck, but what about someone who has the board with no wifi
> and problems start happening because the wifi is enabled on the device
> tree?

Did that happen or is it a theoretical issue?

> > > About device tree overlays, I read overlay-notes.txt, but I went
> > > looking for an example with "git grep /plugin/ arch" and it came
> > > empty. Is this approach not used for other boards?
> >
> > It is, it's simply not stored in the kernel, but through other third
> > party repos.
> 
> So that would mean that it's up to every distro to support the boards
> instead of relying on mainline support?

Distros would have to integrate it either way. One would need to
detect and / or ask for the board variant in order to load say the BT
stack, or to know if you want to boot from the eMMC or from the SD
card.

> > > Does the overlay approach make the device available at boot time? That
> > > is important for a storage device such as eMMC.
> > >
> > > I went with the separate dts approach because that's what I saw was
> > > done for other similar cases, like Pine64 and Pine64+, OLinuXino-LIME2
> > > and its variant with eMMC, among others.
> >
> > Yeah, but in all these cases, it was done from day one, not after the
> > facts.
> 
> For the LIME2 the dts for the emmc variant was commited two years
> after the base LIME2 dts.
> 
> What if instead of keeping the current dt for the least featureful
> model we keep it for the most featureful model and create new dts for
> the two less featureful models?

This is a different story though. The LIME2 eMMC variant was created
way after the original LIME2, with a separate name.

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 1/2] arm64: dts: allwinner: Olimex A64-OLinuXino: enable eMMC.

[Rodrigo Exterckötter Tjäder]

On Tue, Oct 2, 2018 at 10:13 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Sat, Sep 29, 2018 at 01:51:02PM -0300, Rodrigo Exterckötter Tjäder wrote:
> > On Sat, Sep 29, 2018 at 12:47 PM Maxime Ripard
> > <maxime.ripard@bootlin.com> wrote:
> > > > We can't even remove a node from a device tree? Removing the WiFi node
> > > > from the current tree would make it correspond to the variant with the
> > > > least features.
> > >
> > > Not really. How pissed would you be if you were a user, had wifi
> > > running on your board, you upgrade your kernel, and then it's just
> > > gone? :)
> >
> > That would suck, but what about someone who has the board with no wifi
> > and problems start happening because the wifi is enabled on the device
> > tree?
>
> Did that happen or is it a theoretical issue?

Theoretical. I don't know how likely having a non-existant device
enabled is to cause problems.

> > > > About device tree overlays, I read overlay-notes.txt, but I went
> > > > looking for an example with "git grep /plugin/ arch" and it came
> > > > empty. Is this approach not used for other boards?
> > >
> > > It is, it's simply not stored in the kernel, but through other third
> > > party repos.
> >
> > So that would mean that it's up to every distro to support the boards
> > instead of relying on mainline support?
>
> Distros would have to integrate it either way. One would need to
> detect and / or ask for the board variant in order to load say the BT
> stack, or to know if you want to boot from the eMMC or from the SD
> card.

Yeah, but now if a bug is found in the device tree it has to be fixed
once per distro instead of only on mainline.

> > > > Does the overlay approach make the device available at boot time? That
> > > > is important for a storage device such as eMMC.
> > > >
> > > > I went with the separate dts approach because that's what I saw was
> > > > done for other similar cases, like Pine64 and Pine64+, OLinuXino-LIME2
> > > > and its variant with eMMC, among others.
> > >
> > > Yeah, but in all these cases, it was done from day one, not after the
> > > facts.
> >
> > For the LIME2 the dts for the emmc variant was commited two years
> > after the base LIME2 dts.
> >
> > What if instead of keeping the current dt for the least featureful
> > model we keep it for the most featureful model and create new dts for
> > the two less featureful models?
>
> This is a different story though. The LIME2 eMMC variant was created
> way after the original LIME2, with a separate name.

What about the idea of keeping the current dt for the most featureful
variant and creating new dts for the other two?

That would make it so that no one's device stops working and would
have mailine support for all three devices.

Also, the current device tree doesn't represent any existing device:
it has wifi on but no emmc. That variation does not exist.

Re: [PATCH 1/2] arm64: dts: allwinner: Olimex A64-OLinuXino: enable eMMC.

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 2525 bytes --]

On Tue, Oct 02, 2018 at 01:47:33PM -0300, Rodrigo Exterckötter Tjäder wrote:
> > > > > About device tree overlays, I read overlay-notes.txt, but I went
> > > > > looking for an example with "git grep /plugin/ arch" and it came
> > > > > empty. Is this approach not used for other boards?
> > > >
> > > > It is, it's simply not stored in the kernel, but through other third
> > > > party repos.
> > >
> > > So that would mean that it's up to every distro to support the boards
> > > instead of relying on mainline support?
> >
> > Distros would have to integrate it either way. One would need to
> > detect and / or ask for the board variant in order to load say the BT
> > stack, or to know if you want to boot from the eMMC or from the SD
> > card.
> 
> Yeah, but now if a bug is found in the device tree it has to be fixed
> once per distro instead of only on mainline.

Yeah, well, I never said it was perfect.

> > > > > Does the overlay approach make the device available at boot time? That
> > > > > is important for a storage device such as eMMC.
> > > > >
> > > > > I went with the separate dts approach because that's what I saw was
> > > > > done for other similar cases, like Pine64 and Pine64+, OLinuXino-LIME2
> > > > > and its variant with eMMC, among others.
> > > >
> > > > Yeah, but in all these cases, it was done from day one, not after the
> > > > facts.
> > >
> > > For the LIME2 the dts for the emmc variant was commited two years
> > > after the base LIME2 dts.
> > >
> > > What if instead of keeping the current dt for the least featureful
> > > model we keep it for the most featureful model and create new dts for
> > > the two less featureful models?
> >
> > This is a different story though. The LIME2 eMMC variant was created
> > way after the original LIME2, with a separate name.
> 
> What about the idea of keeping the current dt for the most featureful
> variant and creating new dts for the other two?
>
> That would make it so that no one's device stops working and would
> have mailine support for all three devices.

IIRC that has been the first introduced version, so that would make
sense. Chen-Yu, any opinion?

> Also, the current device tree doesn't represent any existing device:
> it has wifi on but no emmc. That variation does not exist.

Most of our device tree are far from complete, so you shouldn't treat
them as such.

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 1/2] arm64: dts: allwinner: Olimex A64-OLinuXino: enable eMMC.

[Rodrigo Exterckötter Tjäder]

On Fri, Oct 5, 2018 at 12:48 PM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > What about the idea of keeping the current dt for the most featureful
> > variant and creating new dts for the other two?
> >
> > That would make it so that no one's device stops working and would
> > have mailine support for all three devices.
>
> IIRC that has been the first introduced version, so that would make
> sense. Chen-Yu, any opinion?
>
> > Also, the current device tree doesn't represent any existing device:
> > it has wifi on but no emmc. That variation does not exist.
>
> Most of our device tree are far from complete, so you shouldn't treat
> them as such.

So, any agreement on what is to be done about the devices tree for the
A64-OLinuXino devices?

In my opinion the best path would be keeping the current dt for the
most featureful variant and creating new dts for the other two.