| Message ID | 20200115194216.173117-2-jernej.skrabec@siol.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm64: dts: allwinner: h6: Introduce OrangePi 3 eMMC board | expand |
On Wed, Jan 15, 2020 at 1:42 PM Jernej Skrabec <jernej.skrabec@siol.net> wrote: > > OrangePi 3 can optionally have eMMC. Add a compatible for it. Is this just a population option or a different board layout? If the former, I don't think you need a new compatible, just add/enable a node for the eMMC. Rob
Hi! Dne sreda, 15. januar 2020 ob 22:57:31 CET je Rob Herring napisal(a): > On Wed, Jan 15, 2020 at 1:42 PM Jernej Skrabec <jernej.skrabec@siol.net> wrote: > > OrangePi 3 can optionally have eMMC. Add a compatible for it. > > Is this just a population option or a different board layout? If the > former, I don't think you need a new compatible, just add/enable a > node for the eMMC. I have only board with eMMC but I imagine it's the former. Even so, current approach with Allwinner boards is to have two different board DT files, one for each variant. This can be seen from Documentation/devicetree/bindings/arm/ sunxi.yaml which has a lot of compatibles ending with "-emmc". I guess reason for that is to avoid having MMC controller being powered on for no reason. Best regards, Jernej
On Thu, Jan 16, 2020 at 12:10:58AM +0100, Jernej Škrabec wrote: > Hi! > > Dne sreda, 15. januar 2020 ob 22:57:31 CET je Rob Herring napisal(a): > > On Wed, Jan 15, 2020 at 1:42 PM Jernej Skrabec <jernej.skrabec@siol.net> > wrote: > > > OrangePi 3 can optionally have eMMC. Add a compatible for it. > > > > Is this just a population option or a different board layout? If the > > former, I don't think you need a new compatible, just add/enable a > > node for the eMMC. > > I have only board with eMMC but I imagine it's the former. Even so, current > approach with Allwinner boards is to have two different board DT files, one for > each variant. This can be seen from Documentation/devicetree/bindings/arm/ > sunxi.yaml which has a lot of compatibles ending with "-emmc". I guess reason > for that is to avoid having MMC controller being powered on for no reason. The main reason for that is that those populating options can be conflicting. For example, last week we discussed an issue about the eMMC being on the same pin set than an SPI flash, both options being available. The solution Andre suggested then was to let the eMMC be disabled, and have the bootloader probe the emmc, and if found, enable it. Otherwise, it means that you have a SPI flash (and enable it). I guess a similar solution would apply here. Maxime
Dne četrtek, 16. januar 2020 ob 13:29:44 CET je Maxime Ripard napisal(a): > On Thu, Jan 16, 2020 at 12:10:58AM +0100, Jernej Škrabec wrote: > > Hi! > > > > Dne sreda, 15. januar 2020 ob 22:57:31 CET je Rob Herring napisal(a): > > > On Wed, Jan 15, 2020 at 1:42 PM Jernej Skrabec <jernej.skrabec@siol.net> > > > > wrote: > > > > OrangePi 3 can optionally have eMMC. Add a compatible for it. > > > > > > Is this just a population option or a different board layout? If the > > > former, I don't think you need a new compatible, just add/enable a > > > node for the eMMC. > > > > I have only board with eMMC but I imagine it's the former. Even so, > > current > > approach with Allwinner boards is to have two different board DT files, > > one for each variant. This can be seen from > > Documentation/devicetree/bindings/arm/ sunxi.yaml which has a lot of > > compatibles ending with "-emmc". I guess reason for that is to avoid > > having MMC controller being powered on for no reason. > The main reason for that is that those populating options can be > conflicting. For example, last week we discussed an issue about the > eMMC being on the same pin set than an SPI flash, both options being > available. > > The solution Andre suggested then was to let the eMMC be disabled, and > have the bootloader probe the emmc, and if found, enable > it. Otherwise, it means that you have a SPI flash (and enable it). > > I guess a similar solution would apply here. From what I can tell from schematic, pins are dedicated for eMMC. So what solution do you suggest? Put eMMC node in original OrangePi 3 DT and set status to disabled? Best regards, Jernej
Hi, On Thu, Jan 16, 2020 at 05:33:45PM +0100, Jernej Škrabec wrote: > Dne četrtek, 16. januar 2020 ob 13:29:44 CET je Maxime Ripard napisal(a): > > On Thu, Jan 16, 2020 at 12:10:58AM +0100, Jernej Škrabec wrote: > > > Hi! > > > > > > Dne sreda, 15. januar 2020 ob 22:57:31 CET je Rob Herring napisal(a): > > > > On Wed, Jan 15, 2020 at 1:42 PM Jernej Skrabec <jernej.skrabec@siol.net> > > > > > > wrote: > > > > > OrangePi 3 can optionally have eMMC. Add a compatible for it. > > > > > > > > Is this just a population option or a different board layout? If the > > > > former, I don't think you need a new compatible, just add/enable a > > > > node for the eMMC. > > > > > > I have only board with eMMC but I imagine it's the former. Even so, > > > current > > > approach with Allwinner boards is to have two different board DT files, > > > one for each variant. This can be seen from > > > Documentation/devicetree/bindings/arm/ sunxi.yaml which has a lot of > > > compatibles ending with "-emmc". I guess reason for that is to avoid > > > having MMC controller being powered on for no reason. > > The main reason for that is that those populating options can be > > conflicting. For example, last week we discussed an issue about the > > eMMC being on the same pin set than an SPI flash, both options being > > available. > > > > The solution Andre suggested then was to let the eMMC be disabled, and > > have the bootloader probe the emmc, and if found, enable > > it. Otherwise, it means that you have a SPI flash (and enable it). > > > > I guess a similar solution would apply here. > > From what I can tell from schematic, pins are dedicated for eMMC. > > So what solution do you suggest? Put eMMC node in original OrangePi 3 DT and > set status to disabled? If it's always dedicated to eMMC, but the eMMC is not always there, I guess we could remove the non-removable property from the eMMC mode. IIRC, without it (and without CD GPIO), it will fall-back to polling the card and will be able to detect it if it's there (and not use it if it's not). Maxime
diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 327ce6730823..c1e447915c59 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -763,6 +763,11 @@ properties: - const: xunlong,orangepi-3 - const: allwinner,sun50i-h6 + - description: Xunlong OrangePi 3 (with eMMC) + items: + - const: xunlong,orangepi-3-emmc + - const: allwinner,sun50i-h6 + - description: Xunlong OrangePi Lite items: - const: xunlong,orangepi-lite
OrangePi 3 can optionally have eMMC. Add a compatible for it. Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> --- Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++ 1 file changed, 5 insertions(+)