On Tue, Oct 12, 2010 at 12:35 AM, Paul Walmsley <paul@xxxxxxxxx> 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. -- Felipe Contreras -- 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
