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

From: Vivek Gautam <gautam.vivek@samsung.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH RFC 0/2] usb: host: Add a wrapper layer for mutiple host support
Date: Thu, 26 Jun 2014 10:16:11 +0530	[thread overview]
Message-ID: <CAFp+6iEWYzkzfVs6CdtFopKbbSS+TfCAYS6uLcittrKsxU=eJg@mail.gmail.com> (raw)
In-Reply-To: <CAFp+6iHtxYUhQj3NL28LH2HTKjoR6_vsUtqF1XUEvWJeRk=ZiQ@mail.gmail.com>

Hi Simon, Marek,

On Thu, Jun 26, 2014 at 10:04 AM, Vivek Gautam <gautam.vivek@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@chromium.org> wrote:
>> Hi Marek,
>>
>> On 25 June 2014 02:33, Marek Vasut <marex@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.

>>
>> As to the size increase, yes it will increase the size, but not that
>> much, and after all, aren't we trying to move the code to dm?

-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India