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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
