On Thu, 7 Jun 2012, Tony Lindgren wrote:
> Until we have something generic in place to deal with stuff like unused driver
> reset and idle, how about we set up the driver specific reset parts as inline
> functions in the driver header?
You're referring to the driver integration header files in
arch/arm/plat-omap/include/ and arch/arm/mach-omap2/, right? That would
avoid the need for "sideways" includes from drivers/.
> That way the hwmod code can include those functions using the driver register
> defines. Something like:
>
> static inline int xyz_driver_reset(void __iomem *base, int flags)
> {
> ...
> }
>
> Then instead of having a separate platform init file for each driver,
> we could just have a list of reset functions:
>
> static int hwmod_xyz_driver_reset(void __iomem *base, int flags)
This should probably be passed a struct omap_hwmod * instead of base so
it can call the existing hwmod bus related reset functions like
omap_hwmod_softreset(). Or were you thinking about open-coding those into
this reset function?
Just as an aside, this function will probably need to be marked
__maybe_unused, so the compiler doesn't warn when other files include this
header, but don't call the function.
> {
> int res;
>
> /* do bus related reset here */
> ...
>
> /* call the driver reset */
> res = xyz_driver_reset(base, flags)
>
>
> /* do more bus related reset here */
> ...
> }
That's fine with me. It doesn't matter to me where that code lives as
long as it makes technical sense.
I'm hoping that in the near future that we can get rid of these
hwmod_xyz_driver_reset() functions. Instead it should be possible to have
the hwmod reset code call functions like xyz_driver_reset_pre_wait() and
xyz_driver_reset_post_ocpreset() via optional function pointers at
different points in the reset process. That should allow us to remove the
omap_hwmod function calls from the I2C, MSDI, etc. reset functions, and
also remove some needlessly duplicated code.
- 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
