Re: [PATCH 1/3] OMAP: control: add functions for DSP boot address/mode control

[Tony Lindgren <tony@atomide.com>]

* Paul Walmsley <paul@pwsan.com> [101011 13:45]:
> (adding Tony)
> 
> On Mon, 11 Oct 2010, Felipe Contreras wrote:
> 
> > On Mon, Oct 11, 2010 at 11:37 PM, Paul Walmsley <paul@pwsan.com> wrote:
> > > Add two functions for OMAP2430/OMAP3 IVA2 DSP boot control.  These
> > > registers wound up in the System Control Module.  Other kernel code
> > > that wishes to control the DSP's boot process should now use these
> > > functions to do so; subsequent patches implement this in the two
> > > in-tree users of these functions.
> > >
> > > This patch is functionally untested; that is for the DSP/Bridge
> > > programmers to do.
> > >
> > > Signed-off-by: Paul Walmsley <paul@pwsan.com>
> > > ---
> > >  arch/arm/mach-omap2/control.c              |   51 ++++++++++++++++++++++++++
> > >  arch/arm/mach-omap2/control.h              |   16 +++++---
> > >  arch/arm/plat-omap/include/plat/iva2_dsp.h |   56 ++++++++++++++++++++++++++++
> > >  3 files changed, 116 insertions(+), 7 deletions(-)
> > >  create mode 100644 arch/arm/plat-omap/include/plat/iva2_dsp.h
> > 
> > This doesn't seem to be aligned with staging-next, that's where
> > tidspbridge is supposed to reside.
> 
> The patch series is based on Tony's current tree.  It is not intended to 
> be applied as-is.  The series is meant for people working on DSPBridge to 
> know what the expectations are of the OMAP maintainers, and also to give 
> them a quick way forward to getting their code to compile again.

This series seems like a sane way to sort out the dspbridge control
register tinkering.
 
> > I proposed this patch to be applied to linux-omap, but I guess it didn't 
> > seem necessary at the time: 
> > http://article.gmane.org/gmane.linux.kernel/1044209
> 
> I doubt that that's the reason, but you'd have to ask Tony about the 
> details.  But I'd NACK it due to the PRM/CM function pointers.  As I 
> mentioned in the previous messages, no driver should be touching PRM/CM 
> bits directly.

Hmm I acked that patch, but considering the above it should be updated
according to Paul's comments.

Would be nice to get the dspbridge into working shape. Sounds we still
need the following:

- memblock fixes
- this series to fix the control module related issues
- platform data for the boards

Is that all, or are we also missing something else?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html