(adding Tony) On Mon, 11 Oct 2010, Felipe Contreras wrote: > On Mon, Oct 11, 2010 at 11:37 PM, Paul Walmsley <paul@xxxxxxxxx> 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@xxxxxxxxx> > > --- > > Â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. > 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. - Paul
