Hi, On Tue, Oct 11, 2011 at 10:04:28AM -0400, Alan Stern wrote: > On Tue, 11 Oct 2011, Felipe Balbi wrote: > > > > > It doesn't shown here, but the TLL link is completely optional. It's > > > > mainly used for modem integration, IIRC. Still, if we're using TLL, EHCI > > > > and OHCI will depend on a clock provided by the USBTLL block. > > > > > > > > Clearly, USBTLL isn't either a parent of UHH, nor a parent of EHCI/OHCI > > > > blocks. We can, from a code perspective, make USBTLL into a parent of > > > > UHH to make things simpler, but this will mean that calling > > > > pm_runtime_get() will also unconditionaly turn on TLL clock, unless we > > > > add some nasty hacks to allow TLL know if *HCI port is in TLL mode. > > > > > > > > That's why I decided for making TLL and UHH siblings, because that's a > > > > closer relationship than parent-child. > > > > > > > > Can you see the problem now ? > > > > > > Okay, now I understand better. The word "sibling" implies that the two > > > objects have the same parent, so a different word would describe this > > > relationship better. Something like "friend" or "associate". > > > > > > Or maybe, following Paul's suggestion, the driver core doesn't have to > > > be changed at all. > > > > I see... I just thought that if there are other similar cases, it might > > make sense to have a more generic way to make those two devices talk to > > each other. But if you all agree that an EXPORT_SYMBOL_GPL() is enough, > > then it's ok ;-) > > At the moment, I can't see any way to set up a more generic mechanism > that wouldn't be more complicated and have higher overhead than a > simple EXPORT_SYMBOL_GPL. > > Can this be handled by adding another resource to a platform_device? > That at least would make use of an already-existing mechanism. maybe, but let's go with EXPORT_SYMBOL_GPL(). My only concern is that this IP comes from synopsys, and I'm not really keen on adding OMAP-specific, integration-related knowledge on a driver which was supposed to be reusable ;-) But at least for the time being, I guess that's what we need to do ;-) tks -- balbi
Attachment:
signature.asc
Description: Digital signature
