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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
