[PATCHv8 4/5] OMAP: I2C: Remove the reset in the init path

[Paul Walmsley]

On Wed, 11 Jan 2012, Shubhrajyoti wrote:

> On Wednesday 11 January 2012 06:59 PM, Paul Walmsley wrote:
>
> > The real question is how you plan to handle the device reset function, 
> > given that the driver should compile on a non-OMAP build (meaning that you 
> > can't call omap_device*() functions from the driver directly), nor should 
> > the driver touch the SYSCONFIG register directly.
> 
> Paul I thought through it myself not very clear.
> - One way is to find some way for the dt to pass function pointer. Or maybe
> a flag that  activates a static function / hwmod func.
>  
> Will give this a little more thought and get back. I have not any answer
> right now.

Well, if it makes you feel any better, no one else seems to have thought 
through it very much either :-(

To me this is essentially implementing a bus-level (or really, 
integration-level) reset of the device.  This seems to be a function that 
many other buses might support.  So let's look at some of the other 
common Linux bus implementations.

PCI has pci_reset_function() in drivers/pci/pci.c, which a handful of 
PCI-specific drivers call. USB has usb_reset_device() in 
drivers/usb/core/hub.c, also called by a handful of devices.

So there's precedent for the use case.

Incidentally, this is the kind of thing that ideally should be supported 
via a common function pointer in struct bus_type or maybe struct device. 
So rather than the driver calling pci_reset_function() or 
usb_reset_device(), it seems preferable for the driver to do something 
like:

    if (dev->bus->device_reset)
        dev->bus->device_reset(dev);

It seems best to avoid binding a driver tightly to a particular bus 
whenever possible.

...

Now to consider something like this from an OMAP perspective.

In a rough approximation of an ideal world, much of the hwmod and 
omap_device code would live somewhere like drivers/omap_bus/.  Our devices 
would be omap_device based rather than platform_device or of_device based.  
We could export omap_device_reset() and then the I2C driver could call 
this directly.  We're at least a year away from this (if ever): we need 
PRM, CM, SCM drivers; we'd need to have a real omap_bus and omap_device 
that our drivers would use, unlike the faux omap_device we have now.  
Maybe the latter is never going to happen now due to the DT situation.
So any solution that would depend on these steps as prerequisites might 
easily be delayed for an infinite amount of time.

But let's say that a device_reset() function pointer existed inside the 
common struct bus_type in include/linux/device.h, as discussed above.  
>From an OMAP perspective, we could simply set that to point to 
omap_device_reset() in the OMAP-specific device creation code or DT 
notifier callback code.  PCI and USB code could set it to point to their 
own reset functions.  Something like the code fragment above would be 
recommended for all device drivers to do an integration device reset.

Anyway, just an idea.


- Paul