* Paul Walmsley <paul@xxxxxxxxx> [120607 03:24]:
> On Thu, 7 Jun 2012, Tony Lindgren wrote:
>
> > * Paul Walmsley <paul@xxxxxxxxx> [120607 00:44]:
> > > On Thu, 7 Jun 2012, Tony Lindgren wrote:
> > >
> > > > Here too I think driver like features like this should live in the
> > > > driver init for omap OHCI driver. In the likely case that FS OHCI is
> > > > not in use on the board, the OHCI glue can just reset it.
> > >
> > > What if the driver is not compiled into the kernel, but instead is built
> > > as a loadable module?
> >
> > You can still have a core piece of the driver that's always built in, such
> > as omap-ohci-common. But it should live under drivers, not in the bus level
> > code. Or you can insmod/rmmod it to reset things properly.
>
> Do you know of any device drivers that do this now, with a core built-in
> piece separate from a dynamically loadable part?
Hmm yeah good point, only driver frameworks tend to do that. It would require
the module registering with the core driver.
> Seems like it would be tricky to avoid linking in the entire driver, due
> to the symbol dependencies. Either that, or an extra, largely useless,
> layer of indirection would be needed in the shim layer.
Yes probably better approach would be to only build in the reset and idle
part of the driver in the minimal case. And that too can get messy as the
makefiles may not even be included.
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?
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)
{
int res;
/* do bus related reset here */
...
/* call the driver reset */
res = xyz_driver_reset(base, flags)
/* do more bus related reset here */
...
}
Regards,
Tony
--
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
