Monday 14 December 2009 07:05:06 Varadarajan, Charu Latha napisał(a):
> <snip>
>
> >> >@@ -612,7 +597,6 @@ EXPORT_SYMBOL(omap_mcbsp_stop);
> >> > int omap_mcbsp_pollwrite(unsigned int id, u16 buf)
> >> > {
> >> > struct omap_mcbsp *mcbsp;
> >> >- void __iomem *base;
> >> >
> >> > if (!omap_mcbsp_check_valid_id(id)) {
> >> > printk(KERN_ERR "%s: Invalid id (%d)\n",
> >> >__func__, id + 1);
> >> >@@ -620,28 +604,25 @@ int omap_mcbsp_pollwrite(unsigned int id
> >> > }
> >> >
> >> > mcbsp = id_to_mcbsp_ptr(id);
> >> >- base = mcbsp->io_base;
> >> >
> >> >- OMAP_MCBSP_WRITE(base, DXR1, buf);
> >> >+ MCBSP_WRITE(mcbsp, DXR1, buf);
> >>
> >> OMAP3/4 allows 32 bit data access also.
> >> How is it taken care?
> >
> >Not at all in case of those several particular changes above.
> >I'm pretty sure
> >that just replacing old OMAP_MCBSP_WRITE(base, ...) with new
> >MCBSP_WRITE(mcbsp, ...) changed nothing in terms of OMAP3/4
> >32-bit data
> >access. Again, beyond the scope.
> >
> >> Please refer to
> >> http://patchwork.kernel.org/patch/54896/ for more details.
> >>
> >> Quoting Tony's words:
> >> "To me it smells like the all drivers using the the
> >> omap_mcbsp_pollread/write are broken legacy drivers.
> >> So maybe we should just remove these two functions?
> >> If we really want to keep these around, we should review
> >> the drivers using these functions. "
> >
> >Please have a look at patch 1/5, there readw()/writew() has
> >been replaced with
> >OMAP_MCBSP_READ()/_WRITE() inside
> >omap_mcbsp_pollwrite()/_pollread(). If you
> >think there is something wrong with it, please comment that
> >patch, not this
> >one that changes nothing related here, I believe.
>
> The point here is to review the driver before pushing any patch
> touching these functions.
>
> <snip>
If these functions are obsolete and going to be removed, I don't think it
could be of any importance whether they are modified before removal or not.
Otherwise, a solution seems simple to me: you submit a patch that addresses
all concearns, yours, Tony's (BTW, have you already reviewed the drivers as
Tony suggested?), maybe others. Then, after your patch is accepted for
inclusion and it appears in conflict with this series still not applied for
any reason (possibly waiting for your changes if that decided), Jarkko, or
Tony, or anyone else pointed out by Tony, decides which one goes first and
which is going to be refreshed on top of the other. Does it sound like a good
plan for you?
Thanks,
Janusz
--
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
