Hi Alan, On Wed, Jun 15, 2011 at 01:22:19AM +0300, Felipe Balbi wrote: > On Tue, Jun 14, 2011 at 02:32:30PM -0700, Sarah Sharp wrote: > > On Tue, Jun 14, 2011 at 03:39:30PM +0300, Felipe Balbi wrote: > > > Hi Sarah, > > > > > > following we have two patches for XHCI. The first > > > one can be applied now and it's just a Kconfig change. > > > > > > The second one, I wanted to discuss with you in more > > > detail. It's adding a platform_device to xhci.c. I > > > want to do that because it will us to add more xhci > > > glue/link/name-it-as-you-wish layers without having > > > to touch xhci.c and will avoid the ifdeffery mess > > > we have on EHCI/OHCI modules. > > > > I'm not familiar with the platform device code, but I would like to > > avoid excessive ifdefferies. :) > > good :-) > > > > The idea is that we will always have (at least I > > > think) memory mapped controllers, > > > > I'm pretty sure the xHCI spec requires memory mapped controllers. I > > think it may also require interrupts, although I suppose a driver could > > poll the event ring if interrupts aren't possible. > > Well, we can handle interrupt/polling by a feature flag. See more below. > > > > so it doesn't > > > really matter if it's PCI or integrated in a SoC > > > environment; as long as we long we setup the > > > IP integration context, the core driver shouldn't > > > really care where it's running. > > > > Do you think platform xHCI drivers in an SOC will need to careful how > > much memory they allocate for xHCI structures? For example, the ring > > segments could be smaller if necessary, as long as all the segments are > > the same size. > > I don't think they'll need to be too careful about memory allocation, > no. But the thing is that generally, you will an IP core which probably > talks AMBA, then you have a PCI or OMAP or FreeScale or STE bridge > around that core. So, it could very well be that the IP core on OMAP > ends up been the same one as in STE. While in this case the IP core > itself doesn't matter much as they're all xHCI. > > Anyway, I'm trying to avoid lots of rework when adding support to more > devices to xHCI driver. The same could be done for EHCI/OHCI/UHCI too. Now that you're maintainer EHCI/OHCI, would you be willing to take similar patches (well, when they're finished) for those drivers too ? We can, then, get rid of most of the ehci-*.c files by doing this, or at least some amount of lines of code. -- balbi
Attachment:
signature.asc
Description: Digital signature
