Re: [PATCH 1/5 v13] arm: omap: usb: ehci and ohci hwmod structuresfor omap4

[Paul Walmsley]

Hi
On Mon, 10 Oct 2011, Felipe Balbi wrote:

> On Mon, Oct 10, 2011 at 02:22:23PM +0530, Munegowda, Keshava wrote:
>
> > Here is the highlights of the change in the design of  USB Host which
> > we can do after kernel 3.2 release;
> > 
> > 1. separate the TLL changes  from UHH
> > 2. The TLL is be a new platform driver in ./drivers/mfd
> > 3. the TLL platform driver will export apis  for enable/disable clocks
> > and settings.
> 
> TLL should control its clocks through pm_runtime APIs like anything
> else. If you really must export APIs to be used by UHH, you need to have
> an API so that you can claim/release a TLL channel and get/put for
> increasing/decreasing PM counters.
> 
> I still think though, you should try to avoid exporting OMAP-specific
> APIs all over the place. Ideally, we would be able to have some way of
> saying that UHH and TLL are closely related... something like having the
> ability to say e.g. two devices are sibblings of each other, so that we
> could ask for a sibbling to wakeup/sleep depending if we need it or not.
> 
> Dunno, maybe I'm drifting here, but I don't think exposing OMAP-specific
> APIs is wise.

I'm not an USBHOST expert, but I don't think any special sibling 
relationships or OMAP subarchitecture-specific APIs are needed.  The OMAP 
EHCI/OHCI drivers just need to call a couple of functions in the OMAP TLL 
driver.  Linux already handles function call dependencies between 
loadable modules transparently (see "man 8 depmod" and EXPORT_SYMBOL).

Looks to me like the TLL IP block is only needed for OHCI and some EHCI 
port modes[1].  The TLL doesn't seem to need much care and feeding.  
Currently it's programmed during init[2] and then you just enable it when 
the port is in use[3] and disable it when it is no longer in use[4].  
Looks to me like the TLL init function could be rolled into the enable 
function.

So then you'd just create a TLL driver with something like these two 
symbols exported:

omap_usbhost_tll_enable_port();
omap_usbhost_tll_disable_port(); 

The first function would be called from drivers/usb/host/ehci-omap.c or 
drivers/usb/host/ohci-omap3.c during omap_usbhs_enable().  It would take 
the TLL configuration for that port and would reserve it while it is in 
use.  It would call pm_runtime_get_sync() to ensure its clocks were on, 
etc.

The second function would be called from drivers/usb/host/ehci-omap.c or
drivers/usb/host/ohci-omap3.c during omap_usbhs_disable().  It would 
release an already in-use TLL port and would call pm_runtime_put_sync() to 
allow its clocks to be cut, etc.

So it doesn't seem like any extraordinary Linux support is needed to 
handle this cleanly.  But maybe I'm missing something?


- Paul

All references are as of Linux v3.1-rc9.

1. drivers/mfd/omap-usb-host.c:887,
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/mfd/omap-usb-host.c;h=86e14583a08276fd7f76dddd3afe3433f1dfa9a8;hb=976d167615b64e14bc1491ca51d424e2ba9a5e84#l887

2. drivers/mfd/omap-usb-host.c:894,
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/mfd/omap-usb-host.c;h=86e14583a08276fd7f76dddd3afe3433f1dfa9a8;hb=976d167615b64e14bc1491ca51d424e2ba9a5e84#l894

3. drivers/mfd/omap-usb-host.c:845,
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/mfd/omap-usb-host.c;h=86e14583a08276fd7f76dddd3afe3433f1dfa9a8;hb=976d167615b64e14bc1491ca51d424e2ba9a5e84#l845

4. drivers/mfd/omap-usb-host.c:999,
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/mfd/omap-usb-host.c;h=86e14583a08276fd7f76dddd3afe3433f1dfa9a8;hb=976d167615b64e14bc1491ca51d424e2ba9a5e84#l999

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/