[lkml]   [2018]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI
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

Thank you very much for all clarifications!


> Maxime

 \ /
  Last update: 2018-04-25 22:08    [W:0.098 / U:5.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site