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

[Javier Martinez Canillas <javier.martinez@collabora.co.uk>]

On 10/07/2013 12:42 PM, Roger Quadros wrote:
> 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@collabora.co.uk> 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
> 

Hi Roger,

Thanks a lot for the explanation, is very clear for me now.

Best regards,
Javier