[U-Boot] [PATCH RFC 0/2] usb: host: Add a wrapper layer for mutiple host support

Simon Glass sjg at chromium.org
Tue Jul 8 00:46:21 CEST 2014


Hi,

On 26 June 2014 03:21, Marek Vasut <marex at denx.de> wrote:
> On Thursday, June 26, 2014 at 06:46:11 AM, Vivek Gautam wrote:
>> Hi Simon, Marek,
>>
>>
>> On Thu, Jun 26, 2014 at 10:04 AM, Vivek Gautam <gautam.vivek at samsung.com>
>> wrote:
>>
>> sorry for spamming, the earlier message got sent by mistake.
>>
>> > On Thu, Jun 26, 2014 at 8:00 AM, Simon Glass <sjg at chromium.org> wrote:
>> >> Hi Marek,
>> >>
>> >> On 25 June 2014 02:33, Marek Vasut <marex at denx.de> wrote:
>> >>> On Wednesday, June 25, 2014 at 08:27:39 AM, Simon Glass wrote:
>> >>> [...]
>> >>>
>> >>>> > > > model. Instead, I'd love to see a mean to instantiate each *HCI
>> >>>> > > > controller and have a USB core which would track those
>> >>>> > > > instances. The USB core would then be able to call whatever
>> >>>> > > > generic ops on those instances as needed. Does that make sense
>> >>>> > > > please ?
>> >>>> > >
>> >>>> > > True, i understand your point here. I think the second approach i
>> >>>> > > was talking of, goes in this direction.
>> >>>> > > I think i could not put it well in words there.
>> >>>> > >
>> >>>> > > I will prepare an RFC patch for that, and post it as soon as its
>> >>>> > > ready, so that you can have
>> >>>> > > a look.
>> >>>> >
>> >>>> > Ah, this would be so very appreciated! Thank you!
>> >>>>
>> >>>> Should we consider just going straight for driver model?
>> >>>
>> >>> I was thinking about that, but I'm worried it might break USB support
>> >>> on some platforms. Also, the size of U-Boot will grow on many
>> >>> platforms, right?
>> >>>
>> >>> What do you think ?
>> >>
>> >> If you add CONFIG_DM_USB as an option, you can then pull in either
>> >> usb-uclass.c or the old usb code. Since USB is often tied to a board
>> >> then you can move just that board (or group of boards) to dm.
>> >>
>> >> I am keeping a working tree in u-boot-dm.git which does this for
>> >> serial, SPI, SPI flash and GPIO. It seems to work fairly well as a
>> >> technique for keeping both things in the tree in the interim..
>>
>> Ok, so i am having a look at the u-boot-dm tree, and also going through the
>> documentation for driver-model.
>> The driver-model looks a promising choice at the moment keeping in mind
>> that later we would need to move to it anyways.
>>
>> I will try understanding the things and raise a flag in case something
>> is not clear.
>
> Even better, if I don't have to do this myself :) I'm really glad to see how
> many people put effort into the USB and how things are coming together nicely.
> Thank you guys!

Please note I have updated the 'working' branch. A parent device (such
as a SPI bus or USB bus) can now have private data for each of its
children. This was useful for SPI and may be useful for USB.

Regards,
Simon


More information about the U-Boot mailing list