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

[Giulio Benetti <giulio.benetti@micronovasrl.com>]

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
>