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?