Re: [PATCH 2/3] ARM: dts: omap3-igep0020: Add HS USB Host support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 10/07/2013 01:22 PM, Javier Martinez Canillas wrote:
> On Mon, Oct 7, 2013 at 11:13 AM, Javier Martinez Canillas
> <javier.martinez@xxxxxxxxxxxxxxx> wrote:
>> On 10/07/2013 11:06 AM, Roger Quadros wrote:
>>>>
>>>> Well that's a very good question indeed.
>>>>
>>>> The thing is that the IGEP0030 is a Computer-on-Module [1] that is used in
>>>> conjunction with expansion boards and some of them have USB HOST support such as
>>>> IGEP Paris [2] and IGEP Berlin [3].
>>>>
>>>> Support for this expansion boards is still not in mainline but there are plans
>>>> to add them using Device Tree overlays [4] once/if this land on mainline.
>>>>
>>>
>>> Why would your boards need Device Tree overlays? From the looks of it, the configuration
>>> of SOM + base board don't seem to change at runtime.
>>>
>>
>> Indeed, a static configuration (DTS) would be enough now that I think about it.
>>
> 
> Hi Roger,
> 
> Now that I had coffee I remember why I think that even when Device
> Tree overlays are not strictly required for a SOM + base board it
> could be handy to use. If we use a static configuration (DTB) then the
> same firmware can't be used by any IGEP COM Module user. She would
> have to choose a DTB to pass to the kernel on boot.
> 
> While using DT overlays the same firmware that provides a minimal DTB
> can be used regardless of the base board used (as long as there are
> all the needed fragment/overlays hooks in the DTS).
> 
> After all the SOM has a NAND flash memory and a uSD/MMC slot so a
> minimal DTB is needed to boot and the support for all the peripherals
> present on the base board can be added by triggering a device tree
> overlay load from user-space.

Consider this example. You need to boot your board using NFS over ethernet
dongle connected to USB host. If you need user space to get that to work,
it will be a unnecessary challenge, whereas you can easily do that if you
have a static DT blob.

> 
> Or maybe I'm misunderstanding the use case for DT overlays since I had
> just read about it but I don't have practical experience with it.
> 

DT overlays is a solution to the problem faced by the beagle bone community.
There they have a relatively large number of accessories (called capes).
Since the capes don't use a dynamically probed interface like USB/MMC, 
the hardware information needs to be hard coded somewhere and loaded
into the DT at runtime whenever a new cape is connected.

Using overlays for a SOM + base board architecture is an overkill IMO. A base board
is not an accessory, but the platform board itself, hence qualifies for it's own
dts file.

It is much easier to use a base dts for the SOM which contains all the information
for the SOM and leaves the base board details to the base board specific dts.
Each base board can be considered to be a extended variant of the SOM.

cheers,
-roger
--
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




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux