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.
> 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.
> 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?
> 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.
> > > > > +&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.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
