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

[Paul Walmsley]

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