Re: [PATCH 1/3] OMAP: control: add functions for DSP boot address/mode control
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. -- Felipe Contreras -- 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
Re: [PATCH 1/3] OMAP: control: add functions for DSP boot address/mode control
* 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
Re: [PATCH 1/3] OMAP: control: add functions for DSP boot address/mode control
On Mon, Oct 11, 2010 at 11:37 PM, Paul Walmsley p...@pwsan.com 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 p...@pwsan.com --- 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. 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 -- Felipe Contreras -- 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
Re: [PATCH 1/3] OMAP: control: add functions for DSP boot address/mode control
(adding Tony) On Mon, 11 Oct 2010, Felipe Contreras wrote: On Mon, Oct 11, 2010 at 11:37 PM, Paul Walmsley p...@pwsan.com 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 p...@pwsan.com --- 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
Re: [PATCH 1/3] OMAP: control: add functions for DSP boot address/mode control
* Paul Walmsley p...@pwsan.com [101011 13:45]: (adding Tony) On Mon, 11 Oct 2010, Felipe Contreras wrote: On Mon, Oct 11, 2010 at 11:37 PM, Paul Walmsley p...@pwsan.com 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 p...@pwsan.com --- 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. This series seems like a sane way to sort out the dspbridge control register tinkering. 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. Hmm I acked that patch, but considering the above it should be updated according to Paul's comments. 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? 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
Re: [PATCH 1/3] OMAP: control: add functions for DSP boot address/mode control
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. - Paul -- 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
Re: [PATCH 1/3] OMAP: control: add functions for DSP boot address/mode control
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] OMAP: control: add functions for DSP boot address/mode control
A few other items: On Mon, 11 Oct 2010, Paul Walmsley wrote: 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. This also includes some of the code from core/tiomap3430_pwr.c, such as handle_hibernation_from_dsp() and dsp_clk_wakeup_event_ctrl(). Basically, all of the other code that directly reads or writes registers outside the IVA2 directly needs to be moved into arch/arm/mach-omap2. 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. 4. If the DSP uses a peripheral, such as a GPTIMER or a McBSP, DSPBridge needs to reserve that device with the rest of Linux so some other Linux code isn't using it or doesn't try to use it, causing conflicts with DSPBridge. I guess the list that we need to worry about is in _tiomap.h as l4_peripheral_table[]. - Paul -- 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
Re: [PATCH 1/3] OMAP: control: add functions for DSP boot address/mode control
On 10/11/2010 5:16 PM, Paul Walmsley wrote: 4. If the DSP uses a peripheral, such as a GPTIMER or a McBSP, DSPBridge needs to reserve that device with the rest of Linux so some other Linux code isn't using it or doesn't try to use it, causing conflicts with DSPBridge. I guess the list that we need to worry about is in _tiomap.h as l4_peripheral_table[]. this is done by using dmtimer fwk, mcbsp are also requested using mcbsp code (however I think functions to enable/disable mcbsp clocks should be added to mcbsp fwk)... There is no code (that I'm aware of) to control wdt3 nor ssi so this is still there. I still have to review the code to find any place were the registers are written directly though. The other peripherals, at the moment, doesn't have a direct interaction with bridge, although they might be interconnected to iva. I guess we can remove some of the mapped peripherals (like dsi, gpio, uart) and add them back on request and by implementing the code to request them on arm side. - omar -- 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
