* Felipe Contreras <felipe.contre...@gmail.com> [101012 03:52]: > On Tue, Oct 12, 2010 at 12:35 AM, Paul Walmsley <p...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
