On 10/11/2010 4:35 PM, Paul Walmsley 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.
I was working on the 3rd point, but wanted to populate hmods for iommu
and reuse the patches for hwmod mailbox too, before sending.
Also some stuff needed:
- iommu patches[2], this is under discussion, to get iommu + tidspbridge
working.
Regards,
Omar
--
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
