On Wed, 11 Jan 2012, Cousson, Benoit wrote:
> Something that puzzle me on that point is most architecture does not use
> plateform_device and thus does not have any pdata to hack some custom function
> pointers here an there.
> It means that there is probably some better solution to handle that.
PCI and USB have their own bus-level device reset functions that are
exported from bus code that lives under drivers/. In a similar fashion,
we could export omap_device_reset() from our arch/arm/plat-omap code.
But that would require that arch/arm/plat-omap and arch/arm/mach-omap2
code to be compiled for any ARM build that includes i2c-omap.c. This
would be good to avoid, under the principle that drivers should be
buildable for any architecture. (This is also why we wish to remove
omap_{read,write}*() and cpu_is_omap() from any drivers which contain
those.)
The intention a few years ago was to eventually create a a real omap_bus
and omap_device, with the bus/device integration code living under
drivers. In such a situation, we'd be able to use something like the
PCI/USB approach cleanly, since there wouldn't be dependencies to arch/
code.
> AFAIU, the way PPC is handling that is by splitting the driver in a generic
> part and in a platform specific part.
>
> You can then add any OMAP specific hacks in the OMAP specific part while
> keeping most of generic code in a generic driver.
>
> In this case, we just have to implement a small shim that will handle the OMAP
> specific code for the reset. The generic driver will handle the rest.
>
> Maybe I'm missing some important details, but that does seems easily doable
> for the i2c case.
Hmm. How do those drivers call the platform-specific code in a way that
allows those drivers to be built for non-PPC platforms?
- 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
