OrangePi 3 can optionally have eMMC. Add a compatible for it.
Signed-off-by: Jernej Skrabec <[email protected]>
---
Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++
1 file changed, 5 insertions(+)
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
--
2.24.1
On Wed, Jan 15, 2020 at 1:42 PM Jernej Skrabec <[email protected]> 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 <[email protected]>
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 <[email protected]>
> 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 <[email protected]>
> >
> > 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 <[email protected]>
> > >
> > > 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