| Message ID | 20180919141815.18737-1-rodrigo@tjader.xyz |
|---|---|
| State | New |
| Headers | show |
| Series | [1/2] arm64: dts: allwinner: Olimex A64-OLinuXino: enable eMMC. | expand |
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
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
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
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?
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
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.
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
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?
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
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.
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
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.
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 = <®_dcdc1>; + vqmmc-supply = <®_dcdc1>; + bus-width = <8>; + non-removable; + cap-mmc-hw-reset; + status = "okay"; +}; + &ohci0 { status = "okay"; };
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(+)