From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Mon, 7 Jul 2014 16:46:21 -0600 Subject: [U-Boot] [PATCH RFC 0/2] usb: host: Add a wrapper layer for mutiple host support In-Reply-To: <201406261121.34497.marex@denx.de> References: <1403619022-15662-1-git-send-email-gautam.vivek@samsung.com> <201406261121.34497.marex@denx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi, On 26 June 2014 03:21, Marek Vasut 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 >> wrote: >> >> sorry for spamming, the earlier message got sent by mistake. >> >> > On Thu, Jun 26, 2014 at 8:00 AM, Simon Glass wrote: >> >> Hi Marek, >> >> >> >> On 25 June 2014 02:33, Marek Vasut 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