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

["Cousson, Benoit" <b-cousson-l0cyMroinI0@public.gmane.org>]

On 1/11/2012 4:22 PM, Paul Walmsley wrote:
> 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.

For reset, maybe the custom bus is a better approach, since it is 
something that is handled by the OMAP core infrastructure.
I was referring more to all the other function pointer we have today in 
driver like MMC, DSS that does not necessarily belong to a OMAP core stuff.

>> 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?

Well, the point is that a lot of that code should not be in the omap 
arch directory at the first place.
For example, the MMC is using extensively function pointers because of 
the control module dependency.
Having a control module driver will allow stacking the drivers without 
having to get any code in mach-omap directory.

Otherwise, there is as well a dedicated drivers/platform directory that 
can store some platform specific drivers. So far it looks like it is 
used for x86 board kind of drivers only.

Regards,
Benoit