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

[Tony Lindgren <tony@atomide.com>]

* Felipe Contreras <felipe.contreras@gmail.com> [101012 03:52]:
> On Tue, Oct 12, 2010 at 12:35 AM, Paul Walmsley <paul@pwsan.com> wrote:
> > On Mon, 11 Oct 2010, Tony Lindgren wrote:
> >> 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?
> >
> > A few other things should be done also.
> >
> > 1. Most of the code in drivers/staging/tidspbridge/code/tiomap3430.c in
> > the bridge_brd_monitor(), bridge_brd_start(), and bridge_brd_stop() should
> > be moved into a file in arch/arm/mach-omap2.  The DSPBridge driver should
> > call those functions (to reset the DSP, start it, etc.) through
> > platform_data function pointers.  Once that happens, patch 3 of the
> > control module-related series would not be needed, since that code would
> > be in arch/arm/mach-omap2 anyway.
> >
> > 2. The direct CM/PRM/RM register access should be removed from that
> > arch/arm/mach-omap2 code.  That should be handled directly by the
> > clock/hwmod/whatever code.
> >
> > 3. DSPBridge should be converted to use PM runtime, and the
> > arch/arm/mach-omap2 portion should use omap_device, omap_hwmod, etc.
> 
> Before starting to clean things up, I would rather have something that
> works, which AFAIK includes:
> 
>  1) revert or fix iommu migration
>  2) fix ioremap() usage on RAM
> 
> Only then we can have some minimal confidence that the cleaning up is
> not introducing further breakage.

Well we should get it working, but we should also do it in a sane way :)

I guess you're now looking into this patch from Russell?

https://patchwork.kernel.org/patch/245631/

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