Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

[Giulio Benetti]

Hi Maxime,

Il 25/04/2018 20:40, Maxime Ripard ha scritto:
> Hi Giulio,
>
> On Tue, Apr 24, 2018 at 08:31:44PM +0200, Giulio Benetti wrote:
> > LiNova1 is not a board with various headers to connect other peripherals
> > such display, pcap etc.
> > It's an HMI that I would consider the same as a Tablet, because it has a
> > plastic enclosure also.
> >
> > So I would like to understand how to manage it in the best way.
> > Try to consider LiNova1 as a Tablet series, with following list:
> > LiNova1 4.3" ctp
> > LiNova1 7" ctp
> > LiNova1 10.1" ctp
> > LiNova1 4.3" rtp
> > LiNova1 7" rtp
> > LiNova1 10.1" rtp
> >
> > Every of those has a slightly different BOM, so they are 6 different
> > boards with a common base(uP, ram). And same pcb.
>
> So the LiNova1 is exactly the same in all these setups, the only
> difference is that it has a connector that you connect a different
> display / touchscreen to?
>
> If so, that's definitely a case for device tree overlays.

Yes it is that way. So I proceed with dt overlays.

> > So I don't know if submit only the common base and provide
> > separately on our github DT-overlays, or provide as many dts patches
> > as the HMI number with a base dtsi.
>
> That's really up to you, but the overlays will make this much simpler
> to handle precisely because it will reduce the amount of combinations
> you have.
>
> You can even reduce it in your case to 5 of them, 3 for each panel and
> 2 for each touchscreen.

Ah, that's right! Good idea, more "encapsulation".

> > Basically Micronova provides entire system without the capability to hack
> > hardware adding shields of various type.
> >
> > There are also other 2 LiNova:
> > LiNova2 and LiNova3
>
> Which SoCs are these boards based on?

A20 on all three. They are slightly between each other.
Some RS485 more, 1 USB more etc.

> > So I understand that this could lead to 18 different dts files and 3
> > dtsi files.
>
> Yeah, I'd really like to keep this under control :)

:)

> > But with Tablet it should be the same way.  For sure people would be
> > more interested on famous tablets instead of our HMI.
> >
> > In the case I need to use dt-overlays, you mean .dto files with
> > fragments inside loaded by u-boot or runtime, right?
>
> You don't have to handcode the fragments anymore with the new syntax,
> and U-Boot makes it really trivial to use if you use the FIT image
> format to have multiple overlays bundled in the same image. You can
> choose to apply them dynamically, for example based on an EEPROM or
> some other metric to see which combination you have.

Ah, this is interesting. I'm going to experiment with that.

> > > > > > +&usb_otg {
> > > > > > +	dr_mode = "otg";
> > > > >
> > > > > You're saying that this is a USB-A connector? Then it's not OTG since
> > > > > it doesn't have an ID pin, this is an host.
> > > >
> > > > Right, with a special overlay I will activate Usb Device for RNDIS,
> > > > so modified as host
> > >
> > > That doesn't really make much sense. The USB OTG is wired only using a
> > > daughter board?
> >
> > My fault, I've meant "peripheral" in one case and "host" in another case.
> > Usually "host".
> > Are there problem with this?
> > There is no daughter board.
>
> If you have an ID pin and the ability to control VBUS, then you don't
> need to change the device tree, it's done automatically at runtime by
> Linux.

Unfortanetely I don't have ID pin and a common mosfet to control VBUS.
"peripheral" mode should be used only in debug mode,
so right dt-overlay can be written to sd-card by ourself or some of our 
customers.

Thank you very much for all clarifications!

Giulio.

> Maxime