Messages in this thread | | | Subject | Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI | From | Giulio Benetti <> | Date | Wed, 25 Apr 2018 22:08:06 +0200 |
| |
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 >
| |