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

From: Marek Vasut <marex@denx.de>
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 11:21:34 +0200	[thread overview]
Message-ID: <201406261121.34497.marex@denx.de> (raw)
In-Reply-To: <CAFp+6iEWYzkzfVs6CdtFopKbbSS+TfCAYS6uLcittrKsxU=eJg@mail.gmail.com>

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@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.

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!

Best regards,
Marek Vasut