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

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

[Paul Walmsley]

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 <paul@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

diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 1fa3294..90fae36 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -209,6 +209,57 @@ void omap4_ctrl_pad_writel(u32 val, u16 offset)
 	__raw_writel(val, OMAP4_CTRL_PAD_REGADDR(offset));
 }
 
+/*
+ * OMAP3 DSP control functions
+ */
+
+/**
+ * omap2430_ctrl_set_dsp_bootaddr - set the DSP's boot address
+ * @pa: DSP boot address (in physical memory)
+ *
+ * Set the DSP's boot address.  This is an address in physical memory.
+ * No return value.  XXX The TRM claims that this is an "index to a
+ * 4kByte page".  If so, why is the bitfield 21 bits wide, rather than
+ * 20?
+ */
+void omap2430_ctrl_set_dsp_bootaddr(u32 pa)
+{
+	if (!(cpu_is_omap2430() || cpu_is_omap34xx())) {
+		WARN(1, "control: %s: not supported on this SoC\n", __func__);
+		return;
+	}
+
+	WARN(pa & ~OMAP_CTRL_DSP_BOOTADDR_MASK,
+	     "control: %s: invalid DSP boot address %08x\n", __func__, pa);
+
+	omap_ctrl_writel(pa, OMAP243X_CONTROL_IVA2_BOOTADDR);
+}
+
+/**
+ * omap2430_ctrl_set_dsp_bootmode - set the DSP's boot mode
+ * @mode: DSP boot mode (described below)
+ *
+ * Sets the DSP boot mode - see OMAP3 TRM revision ZH section 7.4.7.4
+ * "IVA2.2 Boot Registers".  Known values of @mode include 0, to boot
+ * directly to the address supplied by omap2_ctrl_set_dsp_bootaddr();
+ * 1, to boot to the DSP's ROM code and idle, waiting for interrupts;
+ * 2, to boot to the DSP's ROM code and spin in an idle loop; 3, to
+ * copy the user's bootstrap code from the DSP's internal memory and
+ * execute it (XXX how does the DSP know where to copy from?); and 4,
+ * to execute the DSP ROM code's context restore code.  No return
+ * value.
+ */
+void omap2430_ctrl_set_dsp_bootmode(u8 mode)
+{
+	if (!(cpu_is_omap2430() || cpu_is_omap34xx())) {
+		WARN(1, "control: %s: not supported on this SoC\n", __func__);
+		return;
+	}
+
+	omap_ctrl_writel(mode, OMAP243X_CONTROL_IVA2_BOOTMOD);
+}
+
+
 #if defined(CONFIG_ARCH_OMAP3) && defined(CONFIG_PM)
 /*
  * Clears the scratchpad contents in case of cold boot-
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index b6c6b7c..ac14e0a 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -258,11 +258,6 @@
 /* CONTROL_PROG_IO1 bits */
 #define OMAP3630_PRG_SDMMC1_SPEEDCTRL	(1 << 20)
 
-/* CONTROL_IVA2_BOOTMOD bits */
-#define OMAP3_IVA2_BOOTMOD_SHIFT	0
-#define OMAP3_IVA2_BOOTMOD_MASK		(0xf << 0)
-#define OMAP3_IVA2_BOOTMOD_IDLE		(0x1 << 0)
-
 /* CONTROL_PADCONF_X bits */
 #define OMAP3_PADCONF_WAKEUPEVENT0	(1 << 15)
 #define OMAP3_PADCONF_WAKEUPENABLE0	(1 << 14)
@@ -280,7 +275,7 @@
 #define AM35XX_CPGMAC_FCLK_SHIFT        9
 #define AM35XX_VPFE_FCLK_SHIFT          10
 
-/*AM35XX CONTROL_LVL_INTR_CLEAR bits*/
+/* AM35XX CONTROL_LVL_INTR_CLEAR bits */
 #define AM35XX_CPGMAC_C0_MISC_PULSE_CLR	BIT(0)
 #define AM35XX_CPGMAC_C0_RX_PULSE_CLR	BIT(1)
 #define AM35XX_CPGMAC_C0_RX_THRESH_CLR	BIT(2)
@@ -290,7 +285,7 @@
 #define AM35XX_VPFE_CCDC_VD1_INT_CLR	BIT(6)
 #define AM35XX_VPFE_CCDC_VD2_INT_CLR	BIT(7)
 
-/*AM35XX CONTROL_IP_SW_RESET bits*/
+/* AM35XX CONTROL_IP_SW_RESET bits */
 #define AM35XX_USBOTGSS_SW_RST		BIT(0)
 #define AM35XX_CPGMACSS_SW_RST		BIT(1)
 #define AM35XX_VPFE_VBUSP_SW_RST	BIT(2)
@@ -330,6 +325,10 @@
 #define		FEAT_NEON		0
 #define		FEAT_NEON_NONE		1
 
+/*
+ * DSP booting-related constants
+ */
+#define OMAP_CTRL_DSP_BOOTADDR_MASK	0xfffffc00
 
 #ifndef __ASSEMBLY__
 #ifdef CONFIG_ARCH_OMAP2PLUS
@@ -351,6 +350,9 @@ extern u32 omap3_arm_context[128];
 extern void omap3_control_save_context(void);
 extern void omap3_control_restore_context(void);
 
+extern void omap2430_ctrl_set_dsp_bootaddr(u32 pa);
+extern void omap2430_ctrl_set_dsp_bootmode(u8 mode);
+
 #else
 #define omap_ctrl_base_get()		0
 #define omap_ctrl_readb(x)		0
diff --git a/arch/arm/plat-omap/include/plat/iva2_dsp.h b/arch/arm/plat-omap/include/plat/iva2_dsp.h
new file mode 100644
index 0000000..495c6a9
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/iva2_dsp.h
@@ -0,0 +1,56 @@
+/*
+ * OMAP2430/OMAP3 IVA2 DSP control headers
+ *
+ * Copyright (C) 2010 Nokia Corporation
+ * Paul Walmsley
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
+ * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write  to the Free Software Foundation, Inc.,
+ * 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef __ARCH_ARM_PLAT_OMAP_IVA2_DSP_H
+#define __ARCH_ARM_PLAT_OMAP_IVA2_DSP_H
+
+/*
+ * OMAP2430_IVA2_DSP_BOOTMODE_* values:
+ *
+ * Parameters for omap2430_ctrl_set_dsp_bootmode()
+ * (see e.g. OMAP34XX TRM revision ZH section 7.4.7.4
+ * "IVA2.2 Boot Registers"; OMAP2430 TRM revision Z table 7-181
+ * "CONTROL_IVA2_BOOTMOD")
+ *
+ * 0 is defined by the 2430 and 3xxx hardware to boot directly to the
+ * address supplied by omap2_ctrl_set_dsp_bootaddr().  The remainder
+ * of the values are firmware-dependent on the IVA2 ROM code.  Known
+ * values (from the 34XX TRM reference above) include 1, to boot to
+ * the DSP's ROM code and idle, waiting for interrupts; 2, to boot to
+ * the DSP's ROM code and spin in an idle loop; 3, to copy the user's
+ * bootstrap code from the DSP's internal memory and execute it (XXX
+ * how does the DSP know where to copy from?); and 4, to execute the
+ * DSP ROM code's context restore code.  It's unclear if all of these
+ * are present on 2430.
+ */
+#define OMAP_IVA2_DSP_BOOTMODE_USER		0
+#define OMAP_IVA2_DSP_BOOTMODE_IDLE		1
+#define OMAP_IVA2_DSP_BOOTMODE_BUSYLOOP		2
+#define OMAP_IVA2_DSP_BOOTMODE_COPY		3
+#define OMAP_IVA2_DSP_BOOTMODE_RESTORE		4
+
+#endif

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

[Felipe Contreras]

On Mon, Oct 11, 2010 at 11:37 PM, Paul Walmsley <paul@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 <paul@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 majordomo@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

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1824 bytes --]

(adding Tony)

On Mon, 11 Oct 2010, Felipe Contreras wrote:

> On Mon, Oct 11, 2010 at 11:37 PM, Paul Walmsley <paul@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 <paul@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

[Tony Lindgren]

* Paul Walmsley <paul@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 <paul@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 <paul@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 majordomo@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

[Paul Walmsley]

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

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

[Omar Ramirez Luna]

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

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

[Paul Walmsley]

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

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

[Omar Ramirez Luna]

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

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

[Felipe Contreras]

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.

-- 
Felipe Contreras
--
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

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

[Tony Lindgren]

* 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

[PATCH 2/3] OMAP3: PM: update DSP reset code to use new SCM DSP boot control functions

[Paul Walmsley]

Update the DSP reset code in pm34xx.c to use one of the new SCM DSP
boot control functions, omap2430_ctrl_set_dsp_bootmode().

This reset code should be moved out to a separate function to be
called by the hwmod reset process at some point.  Also, 2430
should be initializing the DSP in a similar fashion.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
---
 arch/arm/mach-omap2/pm34xx.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 8c8f1ac..b90b1fb 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -37,6 +37,7 @@
 #include <plat/prcm.h>
 #include <plat/gpmc.h>
 #include <plat/dma.h>
+#include <plat/iva2_dsp.h>
 
 #include <asm/tlbflush.h>
 
@@ -614,6 +615,7 @@ static struct platform_suspend_ops omap_pm_ops = {
  * function forces the IVA2 into idle state so it can go
  * into retention/off and thus allow full-chip retention/off.
  *
+ * XXX This should be handled by the hwmod.
  **/
 static void __init omap3_iva_idle(void)
 {
@@ -635,9 +637,7 @@ static void __init omap3_iva_idle(void)
 	cm_write_mod_reg(OMAP3430_CM_FCLKEN_IVA2_EN_IVA2_MASK,
 			 OMAP3430_IVA2_MOD, CM_FCLKEN);
 
-	/* Set IVA2 boot mode to 'idle' */
-	omap_ctrl_writel(OMAP3_IVA2_BOOTMOD_IDLE,
-			 OMAP343X_CONTROL_IVA2_BOOTMOD);
+	omap2430_ctrl_set_dsp_bootmode(OMAP_IVA2_DSP_BOOTMODE_IDLE);
 
 	/* Un-reset IVA2 */
 	prm_write_mod_reg(0, OMAP3430_IVA2_MOD, OMAP2_RM_RSTCTRL);

[PATCH 3/3] DSPBridge: convert OMAP3430 adaptation layer to use new SCM DSP boot control fns

[Paul Walmsley]

DSPBridge currently tries to __raw_writel() to the System Control
Module to control the DSP boot process.  This is a layering violation;
this is SoC-specific code, and belongs in a file in
arch/arm/mach-omap2/*.  None of those CM and PRM register accesses
through struct platform_data belong under drivers/.  (Nor would they
belong in DSP platform init code in arch/arm/mach-omap2/* - such code
must use the clock, clockdomain, powerdomain, omap_device, and
omap_hwmod layers that are provided for this purpose.)

The immediate problem, however, is that after commit
346a5c890a55495c718394b74214be1de9303cf6, this code can no longer compile.
So to fix this immediate problem, convert the DSP boot control code to
use platform_data function pointers.

The DSPBridge-on-OMAP3 people also need to implement a file in
arch/arm/mach-omap2/ to populate the platform_data function pointers.
Such a file does not yet exist in the mainline tree, so it's unlikely
that DSPBridge is usable in the mainline until this is done.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: <fernando.lugo@ti.com>
---
 drivers/staging/tidspbridge/core/tiomap3430.c      |   13 ++++++-------
 .../tidspbridge/include/dspbridge/host_os.h        |    4 ++++
 2 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c b/drivers/staging/tidspbridge/core/tiomap3430.c
index f914829..3fd9551 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -21,7 +21,7 @@
 #include <dspbridge/host_os.h>
 #include <linux/mm.h>
 #include <linux/mmzone.h>
-#include <plat/control.h>
+#include <plat/iva2_dsp.h>
 
 /*  ----------------------------------- DSP/BIOS Bridge */
 #include <dspbridge/dbdefs.h>
@@ -374,6 +374,7 @@ static int bridge_brd_start(struct bridge_dev_context *dev_ctxt,
 	u32 clk_cmd;
 	struct io_mgr *hio_mgr;
 	u32 ul_load_monitor_timer;
+	u8 bootmode;
 	struct dspbridge_platform_data *pdata =
 				omap_dspbridge_dev->dev.platform_data;
 
@@ -415,15 +416,13 @@ static int bridge_brd_start(struct bridge_dev_context *dev_ctxt,
 					OMAP3430_RST1_IVA2_MASK, OMAP3430_IVA2_MOD,
 					OMAP2_RM_RSTCTRL);
 			/* Mask address with 1K for compatibility */
-			__raw_writel(dsp_addr & OMAP3_IVA2_BOOTADDR_MASK,
-					OMAP343X_CTRL_REGADDR(
-					OMAP343X_CONTROL_IVA2_BOOTADDR));
+			dsp_addr &= OMAP3_IVA2_BOOTADDR_MASK;
+			(*pdata->set_dsp_bootaddr)(dsp_addr);
 			/*
 			 * Set bootmode to self loop if dsp_debug flag is true
 			 */
-			__raw_writel((dsp_debug) ? OMAP3_IVA2_BOOTMOD_IDLE : 0,
-					OMAP343X_CTRL_REGADDR(
-					OMAP343X_CONTROL_IVA2_BOOTMOD));
+			bootmode = dsp_debug ? OMAP_IVA2_DSP_BOOTMODE_IDLE : 0;
+			(*pdata->set_dsp_bootmode)(bootmode);
 		}
 	}
 	if (!status) {
diff --git a/drivers/staging/tidspbridge/include/dspbridge/host_os.h b/drivers/staging/tidspbridge/include/dspbridge/host_os.h
index 6b4feb4..a251fe4 100644
--- a/drivers/staging/tidspbridge/include/dspbridge/host_os.h
+++ b/drivers/staging/tidspbridge/include/dspbridge/host_os.h
@@ -59,7 +59,11 @@ struct dspbridge_platform_data {
 	unsigned long (*cpu_get_freq) (void);
 	unsigned long mpu_speed[6];
 
+	void (*set_dsp_bootaddr)(u32 pa);
+	void (*set_dsp_bootmode)(u8 mode);
+
 	/* functions to write and read PRCM registers */
+	/* XXX None of this should be here */
 	void (*dsp_prm_write)(u32, s16 , u16);
 	u32 (*dsp_prm_read)(s16 , u16);
 	u32 (*dsp_prm_rmw_bits)(u32, u32, s16, s16);

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

[Omar Ramirez Luna]

From: Paul Walmsley <paul@pwsan.com>

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.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
---

Updated description, removed:

"This patch is functionally untested; that is for the DSP/Bridge
programmers to do."

Tested on OMAP3430 and 3630.

 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

diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 1fa3294..90fae36 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -209,6 +209,57 @@ void omap4_ctrl_pad_writel(u32 val, u16 offset)
 	__raw_writel(val, OMAP4_CTRL_PAD_REGADDR(offset));
 }
 
+/*
+ * OMAP3 DSP control functions
+ */
+
+/**
+ * omap2430_ctrl_set_dsp_bootaddr - set the DSP's boot address
+ * @pa: DSP boot address (in physical memory)
+ *
+ * Set the DSP's boot address.  This is an address in physical memory.
+ * No return value.  XXX The TRM claims that this is an "index to a
+ * 4kByte page".  If so, why is the bitfield 21 bits wide, rather than
+ * 20?
+ */
+void omap2430_ctrl_set_dsp_bootaddr(u32 pa)
+{
+	if (!(cpu_is_omap2430() || cpu_is_omap34xx())) {
+		WARN(1, "control: %s: not supported on this SoC\n", __func__);
+		return;
+	}
+
+	WARN(pa & ~OMAP_CTRL_DSP_BOOTADDR_MASK,
+	     "control: %s: invalid DSP boot address %08x\n", __func__, pa);
+
+	omap_ctrl_writel(pa, OMAP243X_CONTROL_IVA2_BOOTADDR);
+}
+
+/**
+ * omap2430_ctrl_set_dsp_bootmode - set the DSP's boot mode
+ * @mode: DSP boot mode (described below)
+ *
+ * Sets the DSP boot mode - see OMAP3 TRM revision ZH section 7.4.7.4
+ * "IVA2.2 Boot Registers".  Known values of @mode include 0, to boot
+ * directly to the address supplied by omap2_ctrl_set_dsp_bootaddr();
+ * 1, to boot to the DSP's ROM code and idle, waiting for interrupts;
+ * 2, to boot to the DSP's ROM code and spin in an idle loop; 3, to
+ * copy the user's bootstrap code from the DSP's internal memory and
+ * execute it (XXX how does the DSP know where to copy from?); and 4,
+ * to execute the DSP ROM code's context restore code.  No return
+ * value.
+ */
+void omap2430_ctrl_set_dsp_bootmode(u8 mode)
+{
+	if (!(cpu_is_omap2430() || cpu_is_omap34xx())) {
+		WARN(1, "control: %s: not supported on this SoC\n", __func__);
+		return;
+	}
+
+	omap_ctrl_writel(mode, OMAP243X_CONTROL_IVA2_BOOTMOD);
+}
+
+
 #if defined(CONFIG_ARCH_OMAP3) && defined(CONFIG_PM)
 /*
  * Clears the scratchpad contents in case of cold boot-
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index b6c6b7c..ac14e0a 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -258,11 +258,6 @@
 /* CONTROL_PROG_IO1 bits */
 #define OMAP3630_PRG_SDMMC1_SPEEDCTRL	(1 << 20)
 
-/* CONTROL_IVA2_BOOTMOD bits */
-#define OMAP3_IVA2_BOOTMOD_SHIFT	0
-#define OMAP3_IVA2_BOOTMOD_MASK		(0xf << 0)
-#define OMAP3_IVA2_BOOTMOD_IDLE		(0x1 << 0)
-
 /* CONTROL_PADCONF_X bits */
 #define OMAP3_PADCONF_WAKEUPEVENT0	(1 << 15)
 #define OMAP3_PADCONF_WAKEUPENABLE0	(1 << 14)
@@ -280,7 +275,7 @@
 #define AM35XX_CPGMAC_FCLK_SHIFT        9
 #define AM35XX_VPFE_FCLK_SHIFT          10
 
-/*AM35XX CONTROL_LVL_INTR_CLEAR bits*/
+/* AM35XX CONTROL_LVL_INTR_CLEAR bits */
 #define AM35XX_CPGMAC_C0_MISC_PULSE_CLR	BIT(0)
 #define AM35XX_CPGMAC_C0_RX_PULSE_CLR	BIT(1)
 #define AM35XX_CPGMAC_C0_RX_THRESH_CLR	BIT(2)
@@ -290,7 +285,7 @@
 #define AM35XX_VPFE_CCDC_VD1_INT_CLR	BIT(6)
 #define AM35XX_VPFE_CCDC_VD2_INT_CLR	BIT(7)
 
-/*AM35XX CONTROL_IP_SW_RESET bits*/
+/* AM35XX CONTROL_IP_SW_RESET bits */
 #define AM35XX_USBOTGSS_SW_RST		BIT(0)
 #define AM35XX_CPGMACSS_SW_RST		BIT(1)
 #define AM35XX_VPFE_VBUSP_SW_RST	BIT(2)
@@ -330,6 +325,10 @@
 #define		FEAT_NEON		0
 #define		FEAT_NEON_NONE		1
 
+/*
+ * DSP booting-related constants
+ */
+#define OMAP_CTRL_DSP_BOOTADDR_MASK	0xfffffc00
 
 #ifndef __ASSEMBLY__
 #ifdef CONFIG_ARCH_OMAP2PLUS
@@ -351,6 +350,9 @@ extern u32 omap3_arm_context[128];
 extern void omap3_control_save_context(void);
 extern void omap3_control_restore_context(void);
 
+extern void omap2430_ctrl_set_dsp_bootaddr(u32 pa);
+extern void omap2430_ctrl_set_dsp_bootmode(u8 mode);
+
 #else
 #define omap_ctrl_base_get()		0
 #define omap_ctrl_readb(x)		0
diff --git a/arch/arm/plat-omap/include/plat/iva2_dsp.h b/arch/arm/plat-omap/include/plat/iva2_dsp.h
new file mode 100644
index 0000000..495c6a9
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/iva2_dsp.h
@@ -0,0 +1,56 @@
+/*
+ * OMAP2430/OMAP3 IVA2 DSP control headers
+ *
+ * Copyright (C) 2010 Nokia Corporation
+ * Paul Walmsley
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN
+ * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write  to the Free Software Foundation, Inc.,
+ * 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef __ARCH_ARM_PLAT_OMAP_IVA2_DSP_H
+#define __ARCH_ARM_PLAT_OMAP_IVA2_DSP_H
+
+/*
+ * OMAP2430_IVA2_DSP_BOOTMODE_* values:
+ *
+ * Parameters for omap2430_ctrl_set_dsp_bootmode()
+ * (see e.g. OMAP34XX TRM revision ZH section 7.4.7.4
+ * "IVA2.2 Boot Registers"; OMAP2430 TRM revision Z table 7-181
+ * "CONTROL_IVA2_BOOTMOD")
+ *
+ * 0 is defined by the 2430 and 3xxx hardware to boot directly to the
+ * address supplied by omap2_ctrl_set_dsp_bootaddr().  The remainder
+ * of the values are firmware-dependent on the IVA2 ROM code.  Known
+ * values (from the 34XX TRM reference above) include 1, to boot to
+ * the DSP's ROM code and idle, waiting for interrupts; 2, to boot to
+ * the DSP's ROM code and spin in an idle loop; 3, to copy the user's
+ * bootstrap code from the DSP's internal memory and execute it (XXX
+ * how does the DSP know where to copy from?); and 4, to execute the
+ * DSP ROM code's context restore code.  It's unclear if all of these
+ * are present on 2430.
+ */
+#define OMAP_IVA2_DSP_BOOTMODE_USER		0
+#define OMAP_IVA2_DSP_BOOTMODE_IDLE		1
+#define OMAP_IVA2_DSP_BOOTMODE_BUSYLOOP		2
+#define OMAP_IVA2_DSP_BOOTMODE_COPY		3
+#define OMAP_IVA2_DSP_BOOTMODE_RESTORE		4
+
+#endif
-- 
1.7.1