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