[PATCH] imx: dma: remove SDMA_IS_MERGED

[PATCH] imx: dma: remove SDMA_IS_MERGED

[Fabio Estevam]

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
This allows imx-for-2.6.38 tree to build again.

 arch/arm/plat-mxc/devices/platform-imx-dma.c |    8 --------
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/arch/arm/plat-mxc/devices/platform-imx-dma.c b/arch/arm/plat-mxc/devices/platform-imx-dma.c
index 93e2fdc..89ec637 100644
--- a/arch/arm/plat-mxc/devices/platform-imx-dma.c
+++ b/arch/arm/plat-mxc/devices/platform-imx-dma.c
@@ -12,15 +12,7 @@
 
 #include <mach/hardware.h>
 #include <mach/devices-common.h>
-#ifdef SDMA_IS_MERGED
 #include <mach/sdma.h>
-#else
-struct sdma_platform_data {
-	int sdma_version;
-	char *cpu_name;
-	int to_version;
-};
-#endif
 
 struct imx_imx_sdma_data {
 	resource_size_t iobase;
-- 
1.6.0.4

[PATCH] imx: dma: remove SDMA_IS_MERGED

[Uwe Kleine-König]

Hello Fabio,

On Wed, Nov 24, 2010 at 05:29:31PM -0200, Fabio Estevam wrote:
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> This allows imx-for-2.6.38 tree to build again.
The same patch is already in Sascha's imx-for-2.6.37 branch (and so in
for-next, too).  There are some more fixes in for-.37 so I'd use the
for-next branch for now.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH] imx: dma: remove SDMA_IS_MERGED

[Fabio Estevam]

Hi Uwe,

2010/11/24 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> Hello Fabio,
>
> On Wed, Nov 24, 2010 at 05:29:31PM -0200, Fabio Estevam wrote:
>> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
>> ---
>> This allows imx-for-2.6.38 tree to build again.
> The same patch is already in Sascha's imx-for-2.6.37 branch (and so in
> for-next, too). ?There are some more fixes in for-.37 so I'd use the
> for-next branch for now.

Thanks, I haven't noticed this. Will use for-next branch for now.

While at the dma topic: is anyone able to boot a kernel on MX51 with
IMX_SDMA=y?

I enabled early printk support, but no kernel messages appear after:
Uncompressing Linux... done, booting the kernel.

This also happens on the for-next branch.

Regards,

Fabio Estevam

[PATCH] imx: dma: remove SDMA_IS_MERGED

[Uwe Kleine-König]

On Wed, Nov 24, 2010 at 06:07:18PM -0200, Fabio Estevam wrote:
> Hi Uwe,
> 
> 2010/11/24 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> > Hello Fabio,
> >
> > On Wed, Nov 24, 2010 at 05:29:31PM -0200, Fabio Estevam wrote:
> >> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> >> ---
> >> This allows imx-for-2.6.38 tree to build again.
> > The same patch is already in Sascha's imx-for-2.6.37 branch (and so in
> > for-next, too). ?There are some more fixes in for-.37 so I'd use the
> > for-next branch for now.
> 
> Thanks, I haven't noticed this. Will use for-next branch for now.
> 
> While at the dma topic: is anyone able to boot a kernel on MX51 with
> IMX_SDMA=y?
> 
> I enabled early printk support, but no kernel messages appear after:
> Uncompressing Linux... done, booting the kernel.
> 
> This also happens on the for-next branch.
I usually prefer just using DEBUG_LL and put

	#ifdef CONFIG_DEBUG_LL
		void printch(char);
		printch(c);
	#endif

into emit_log_char.  But I think that's only because I don't know how to
use early printk properly.  (You might need an additional kernel
parameter?!)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH] imx: dma: remove SDMA_IS_MERGED

[Fabio Estevam]

Hi Uwe,

2010/11/24 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
....
> I usually prefer just using DEBUG_LL and put
>
> ? ? ? ?#ifdef CONFIG_DEBUG_LL
> ? ? ? ? ? ? ? ?void printch(char);
> ? ? ? ? ? ? ? ?printch(c);
> ? ? ? ?#endif
>
> into emit_log_char. ?But I think that's only because I don't know how to
> use early printk properly. ?(You might need an additional kernel
> parameter?!)

Thanks. I see that the kernel crashes at sdma_get_firmware.

Will try to build a firmware using Sascha's SDMA utility.

Regards,

Fabio Estevam

[PATCH] imx: dma: remove SDMA_IS_MERGED

[Uwe Kleine-König]

On Wed, Nov 24, 2010 at 07:42:31PM -0200, Fabio Estevam wrote:
> Hi Uwe,
> 
> 2010/11/24 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> ....
> > I usually prefer just using DEBUG_LL and put
> >
> > ? ? ? ?#ifdef CONFIG_DEBUG_LL
> > ? ? ? ? ? ? ? ?void printch(char);
> > ? ? ? ? ? ? ? ?printch(c);
> > ? ? ? ?#endif
> >
> > into emit_log_char. ?But I think that's only because I don't know how to
> > use early printk properly. ?(You might need an additional kernel
> > parameter?!)
> 
> Thanks. I see that the kernel crashes at sdma_get_firmware.
> 
> Will try to build a firmware using Sascha's SDMA utility.
Maybe there is a fix needed to make the machine boot even if no firmware
is found?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH] imx: dma: remove SDMA_IS_MERGED

[Richard Zhao]

2010/11/25 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> On Wed, Nov 24, 2010 at 07:42:31PM -0200, Fabio Estevam wrote:
>> Hi Uwe,
>>
>> 2010/11/24 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
>> ....
>> > I usually prefer just using DEBUG_LL and put
>> >
>> > ? ? ? ?#ifdef CONFIG_DEBUG_LL
>> > ? ? ? ? ? ? ? ?void printch(char);
>> > ? ? ? ? ? ? ? ?printch(c);
>> > ? ? ? ?#endif
>> >
>> > into emit_log_char. ?But I think that's only because I don't know how to
>> > use early printk properly. ?(You might need an additional kernel
>> > parameter?!)
>>
>> Thanks. I see that the kernel crashes at sdma_get_firmware.
>>
>> Will try to build a firmware using Sascha's SDMA utility.
> Maybe there is a fix needed to make the machine boot even if no firmware
> is found?
Some Freescale guy is preparing sdma patch. Maybe he can fix this.

Thanks
Richard

[PATCH] imx: dma: remove SDMA_IS_MERGED

[Sascha Hauer]

On Wed, Nov 24, 2010 at 09:18:31PM +0100, Uwe Kleine-K?nig wrote:
> On Wed, Nov 24, 2010 at 06:07:18PM -0200, Fabio Estevam wrote:
> > Hi Uwe,
> > 
> > 2010/11/24 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> > > Hello Fabio,
> > >
> > > On Wed, Nov 24, 2010 at 05:29:31PM -0200, Fabio Estevam wrote:
> > >> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> > >> ---
> > >> This allows imx-for-2.6.38 tree to build again.
> > > The same patch is already in Sascha's imx-for-2.6.37 branch (and so in
> > > for-next, too). ?There are some more fixes in for-.37 so I'd use the
> > > for-next branch for now.
> > 
> > Thanks, I haven't noticed this. Will use for-next branch for now.
> > 
> > While at the dma topic: is anyone able to boot a kernel on MX51 with
> > IMX_SDMA=y?
> > 
> > I enabled early printk support, but no kernel messages appear after:
> > Uncompressing Linux... done, booting the kernel.
> > 
> > This also happens on the for-next branch.
> I usually prefer just using DEBUG_LL and put
> 
> 	#ifdef CONFIG_DEBUG_LL
> 		void printch(char);
> 		printch(c);
> 	#endif
> 
> into emit_log_char.  But I think that's only because I don't know how to
> use early printk properly.  (You might need an additional kernel
> parameter?!)

Yes, 'earlyprintk'.


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH] imx: dma: remove SDMA_IS_MERGED

[Sascha Hauer]

On Wed, Nov 24, 2010 at 07:42:31PM -0200, Fabio Estevam wrote:
> Hi Uwe,
> 
> 2010/11/24 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> ....
> > I usually prefer just using DEBUG_LL and put
> >
> > ? ? ? ?#ifdef CONFIG_DEBUG_LL
> > ? ? ? ? ? ? ? ?void printch(char);
> > ? ? ? ? ? ? ? ?printch(c);
> > ? ? ? ?#endif
> >
> > into emit_log_char. ?But I think that's only because I don't know how to
> > use early printk properly. ?(You might need an additional kernel
> > parameter?!)
> 
> Thanks. I see that the kernel crashes at sdma_get_firmware.

This is a bug which should be fixed in this -rc cycle. Anyway, note
that I have a patch in my for-2.6.38 queue which makes the SDMA work
without a valid firmware. In this case only the scripts in ROM are used.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH] imx: dma: remove SDMA_IS_MERGED

[Fabio Estevam]

Hi Sascha,

On Thu, Nov 25, 2010 at 7:13 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Wed, Nov 24, 2010 at 07:42:31PM -0200, Fabio Estevam wrote:
>> Hi Uwe,
>>
>> 2010/11/24 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
>> ....
>> > I usually prefer just using DEBUG_LL and put
>> >
>> > ? ? ? ?#ifdef CONFIG_DEBUG_LL
>> > ? ? ? ? ? ? ? ?void printch(char);
>> > ? ? ? ? ? ? ? ?printch(c);
>> > ? ? ? ?#endif
>> >
>> > into emit_log_char. ?But I think that's only because I don't know how to
>> > use early printk properly. ?(You might need an additional kernel
>> > parameter?!)
>>
>> Thanks. I see that the kernel crashes at sdma_get_firmware.
>
> This is a bug which should be fixed in this -rc cycle. Anyway, note
> that I have a patch in my for-2.6.38 queue which makes the SDMA work
> without a valid firmware. In this case only the scripts in ROM are used.

Yes, I am using your for-next branch, which contains the patch to make
SDMA work without a valid firmware.

I also generated the SDMA firmware (sdma-imx51-to1.bin) via your sdma
tool and placed it under /lib/firmware, but the result is the same
with or without a valid firmware: when request_firmware is called the
following crash happens:

Unable to handle kernel NULL pointer dereference at virtual address 00000048
pgd = c0004000
[00000048] *pgd=00000000
Internal error: Oops: 5 [#1]
last sysfs file:
Modules linked in:
CPU: 0    Not tainted  (2.6.37-rc3+ #324)
PC is at get_device_parent+0x80/0x168
LR is at mutex_lock+0x14/0x34
pc : [<c01cac88>]    lr : [<c029d81c>]    psr: 60000013
sp : df83bd78  ip : df83bd60  fp : df83bd94
r10: c037edf8  r9 : 00000001  r8 : 00000000
r7 : df861540  r6 : df84ba10  r5 : df85c640  r4 : df85c640
r3 : 00000000  r2 : 00000000  r1 : df84ba08  r0 : 00000000
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5387f  Table: 90004019  DAC: 00000017
Process swapper (pid: 1, stack limit = 0xdf83a2e8)
Stack: (0xdf83bd78 to 0xdf83c000)
bd60:                                                       df861580 df85c640
bd80: df85c648 00000000 df83bddc df83bd98 c01cbc38 c01cac14 00000000 df84ba08
bda0: df85c600 df85c640 df83bdd0 df83bdb8 c01cb028 df84ba08 df85c600 df85c640
bdc0: df861540 00000000 00000001 c037edf8 df83be14 df83bde0 c01d47a4 c01cbbb4
bde0: c036cef8 df83be58 df80a000 df80a000 df861500 00000000 df851b00 00001508
be00: df80a004 00000000 df83be2c df83be18 c01d4a50 c01d4654 00000000 c0019754
be20: df83be8c df83be30 c0019774 c01d4a3c c031d457 df80a000 df83be74 df83be48
be40: df852c90 df84ba08 df80b51c 00000006 00000000 c0381c68 df861540 00000000
be60: df83be7c df84ba08 df84ba08 c0381c68 c0381c68 00000000 00000000 00000000
be80: df83be9c df83be90 c01cf1f0 c00193ac df83bebc df83bea0 c01ce1c8 c01cf1e0
bea0: df84ba08 df84ba3c c0381c68 00000000 df83bedc df83bec0 c01ce2e0 c01ce124
bec0: 00000000 c0381c68 c01ce278 00000000 df83bf04 df83bee0 c01cd9c8 c01ce284
bee0: df81cab8 df84a7b0 c01a0bc4 c0381c68 df859c80 c037eb00 df83bf14 df83bf08
bf00: c01ce00c c01cd980 df83bf44 df83bf18 c01cd2b4 c01cdff8 c031d453 df83bf28
bf20: c0381c68 c001937c c003c3e8 00000000 00000000 00000000 df83bf6c df83bf48
bf40: c01ce5f8 c01cd20c 00000000 c0381c54 c001937c c003c3e8 00000000 00000000
bf60: df83bf7c df83bf70 c01cf64c c01ce554 df83bf94 df83bf80 c01cf680 c01cf60c
bf80: c001ed30 c001937c df83bfa4 df83bf98 c0019394 c01cf66c df83bfdc df83bfa8
bfa0: c00243d4 c0019388 0000010f c0008504 c003c3e8 00000013 c001ed30 c0008504
bfc0: c003c3e8 00000013 00000000 00000000 df83bff4 df83bfe0 c00085a0 c002430c
bfe0: 00000000 00000000 00000000 df83bff8 c003c3e8 c0008510 10109206 dbd6f7f5
Backtrace:
[<c01cac08>] (get_device_parent+0x0/0x168) from [<c01cbc38>] (device_add+0x90/0x
480)
 r6:00000000 r5:df85c648 r4:df85c640 r3:df861580
[<c01cbba8>] (device_add+0x0/0x480) from [<c01d47a4>] (_request_firmware+0x15c/0
x364)
[<c01d4648>] (_request_firmware+0x0/0x364) from [<c01d4a50>] (request_firmware+0
x20/0x28)
[<c01d4a30>] (request_firmware+0x0/0x28) from [<c0019774>] (sdma_probe+0x3d4/0x6
9c)
[<c00193a0>] (sdma_probe+0x0/0x69c) from [<c01cf1f0>] (platform_drv_probe+0x1c/0
x20)
[<c01cf1d4>] (platform_drv_probe+0x0/0x20) from [<c01ce1c8>] (driver_probe_devic
e+0xb0/0x160)
[<c01ce118>] (driver_probe_device+0x0/0x160) from [<c01ce2e0>] (__driver_attach+
0x68/0x8c)
 r7:00000000 r6:c0381c68 r5:df84ba3c r4:df84ba08
[<c01ce278>] (__driver_attach+0x0/0x8c) from [<c01cd9c8>] (bus_for_each_dev+0x54
/0x84)
 r6:00000000 r5:c01ce278 r4:c0381c68 r3:00000000
[<c01cd974>] (bus_for_each_dev+0x0/0x84) from [<c01ce00c>] (driver_attach+0x20/0
x28)
 r6:c037eb00 r5:df859c80 r4:c0381c68
[<c01cdfec>] (driver_attach+0x0/0x28) from [<c01cd2b4>] (bus_add_driver+0xb4/0x2
28)
[<c01cd200>] (bus_add_driver+0x0/0x228) from [<c01ce5f8>] (driver_register+0xb0/
0x13c)
[<c01ce548>] (driver_register+0x0/0x13c) from [<c01cf64c>] (platform_driver_regi
ster+0x4c/0x60)
 r8:00000000 r7:00000000 r6:c003c3e8 r5:c001937c r4:c0381c54
r3:00000000
[<c01cf600>] (platform_driver_register+0x0/0x60) from [<c01cf680>] (platform_dri
ver_probe+0x20/0x70)
[<c01cf660>] (platform_driver_probe+0x0/0x70) from [<c0019394>] (sdma_module_ini
t+0x18/0x24)
 r5:c001937c r4:c001ed30
[<c001937c>] (sdma_module_init+0x0/0x24) from [<c00243d4>] (do_one_initcall+0xd4
/0x1a8)
[<c0024300>] (do_one_initcall+0x0/0x1a8) from [<c00085a0>] (kernel_init+0x9c/0x1
54)
[<c0008504>] (kernel_init+0x0/0x154) from [<c003c3e8>] (do_exit+0x0/0x58c)
 r4:00000000 r3:00000000
Code: e59f00e0 eb034ae1 e59530ac e5933038 (e5b30048)
---[ end trace 1b75b31a2719ed1c ]---
Kernel panic - not syncing: Attempted to kill init!

I am trying to fix this, but suggestions are welcome.

Thanks,

Fabio Estevam

[PATCH] imx: dma: remove SDMA_IS_MERGED

[Arnaud Patard (Rtp)]

Fabio Estevam <festevam@gmail.com> writes:

Hi,
> Hi Sascha,
>
> On Thu, Nov 25, 2010 at 7:13 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
>> On Wed, Nov 24, 2010 at 07:42:31PM -0200, Fabio Estevam wrote:
>>> Hi Uwe,
>>>
>>> 2010/11/24 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
>>> ....
>>> > I usually prefer just using DEBUG_LL and put
>>> >
>>> > ? ? ? ?#ifdef CONFIG_DEBUG_LL
>>> > ? ? ? ? ? ? ? ?void printch(char);
>>> > ? ? ? ? ? ? ? ?printch(c);
>>> > ? ? ? ?#endif
>>> >
>>> > into emit_log_char. ?But I think that's only because I don't know how to
>>> > use early printk properly. ?(You might need an additional kernel
>>> > parameter?!)
>>>
>>> Thanks. I see that the kernel crashes at sdma_get_firmware.
>>
>> This is a bug which should be fixed in this -rc cycle. Anyway, note
>> that I have a patch in my for-2.6.38 queue which makes the SDMA work
>> without a valid firmware. In this case only the scripts in ROM are used.
>
> Yes, I am using your for-next branch, which contains the patch to make
> SDMA work without a valid firmware.
>
> I also generated the SDMA firmware (sdma-imx51-to1.bin) via your sdma
> tool and placed it under /lib/firmware, but the result is the same

I've tried some weeks ago to boot with sdma support enabled and found
out that it was looking for sdma-imx51-to0.bin so I thought it was still
early work and gave up. Maybe it's still not fixed.

> with or without a valid firmware: when request_firmware is called the
> following crash happens:
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000048
> pgd = c0004000
> [00000048] *pgd=00000000
> Internal error: Oops: 5 [#1]
> last sysfs file:
> Modules linked in:
> CPU: 0    Not tainted  (2.6.37-rc3+ #324)
> PC is at get_device_parent+0x80/0x168
> LR is at mutex_lock+0x14/0x34
> pc : [<c01cac88>]    lr : [<c029d81c>]    psr: 60000013
> sp : df83bd78  ip : df83bd60  fp : df83bd94
> r10: c037edf8  r9 : 00000001  r8 : 00000000
> r7 : df861540  r6 : df84ba10  r5 : df85c640  r4 : df85c640
> r3 : 00000000  r2 : 00000000  r1 : df84ba08  r0 : 00000000
> Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
> Control: 10c5387f  Table: 90004019  DAC: 00000017
> Process swapper (pid: 1, stack limit = 0xdf83a2e8)
> Stack: (0xdf83bd78 to 0xdf83c000)
> bd60:                                                       df861580 df85c640
> bd80: df85c648 00000000 df83bddc df83bd98 c01cbc38 c01cac14 00000000 df84ba08
> bda0: df85c600 df85c640 df83bdd0 df83bdb8 c01cb028 df84ba08 df85c600 df85c640
> bdc0: df861540 00000000 00000001 c037edf8 df83be14 df83bde0 c01d47a4 c01cbbb4
> bde0: c036cef8 df83be58 df80a000 df80a000 df861500 00000000 df851b00 00001508
> be00: df80a004 00000000 df83be2c df83be18 c01d4a50 c01d4654 00000000 c0019754
> be20: df83be8c df83be30 c0019774 c01d4a3c c031d457 df80a000 df83be74 df83be48
> be40: df852c90 df84ba08 df80b51c 00000006 00000000 c0381c68 df861540 00000000
> be60: df83be7c df84ba08 df84ba08 c0381c68 c0381c68 00000000 00000000 00000000
> be80: df83be9c df83be90 c01cf1f0 c00193ac df83bebc df83bea0 c01ce1c8 c01cf1e0
> bea0: df84ba08 df84ba3c c0381c68 00000000 df83bedc df83bec0 c01ce2e0 c01ce124
> bec0: 00000000 c0381c68 c01ce278 00000000 df83bf04 df83bee0 c01cd9c8 c01ce284
> bee0: df81cab8 df84a7b0 c01a0bc4 c0381c68 df859c80 c037eb00 df83bf14 df83bf08
> bf00: c01ce00c c01cd980 df83bf44 df83bf18 c01cd2b4 c01cdff8 c031d453 df83bf28
> bf20: c0381c68 c001937c c003c3e8 00000000 00000000 00000000 df83bf6c df83bf48
> bf40: c01ce5f8 c01cd20c 00000000 c0381c54 c001937c c003c3e8 00000000 00000000
> bf60: df83bf7c df83bf70 c01cf64c c01ce554 df83bf94 df83bf80 c01cf680 c01cf60c
> bf80: c001ed30 c001937c df83bfa4 df83bf98 c0019394 c01cf66c df83bfdc df83bfa8
> bfa0: c00243d4 c0019388 0000010f c0008504 c003c3e8 00000013 c001ed30 c0008504
> bfc0: c003c3e8 00000013 00000000 00000000 df83bff4 df83bfe0 c00085a0 c002430c
> bfe0: 00000000 00000000 00000000 df83bff8 c003c3e8 c0008510 10109206 dbd6f7f5
> Backtrace:
> [<c01cac08>] (get_device_parent+0x0/0x168) from [<c01cbc38>] (device_add+0x90/0x
> 480)
>  r6:00000000 r5:df85c648 r4:df85c640 r3:df861580
> [<c01cbba8>] (device_add+0x0/0x480) from [<c01d47a4>] (_request_firmware+0x15c/0
> x364)
> [<c01d4648>] (_request_firmware+0x0/0x364) from [<c01d4a50>] (request_firmware+0
> x20/0x28)
> [<c01d4a30>] (request_firmware+0x0/0x28) from [<c0019774>] (sdma_probe+0x3d4/0x6
> 9c)
> [<c00193a0>] (sdma_probe+0x0/0x69c) from [<c01cf1f0>] (platform_drv_probe+0x1c/0
> x20)
> [<c01cf1d4>] (platform_drv_probe+0x0/0x20) from [<c01ce1c8>] (driver_probe_devic
> e+0xb0/0x160)
> [<c01ce118>] (driver_probe_device+0x0/0x160) from [<c01ce2e0>] (__driver_attach+
> 0x68/0x8c)
>  r7:00000000 r6:c0381c68 r5:df84ba3c r4:df84ba08
> [<c01ce278>] (__driver_attach+0x0/0x8c) from [<c01cd9c8>] (bus_for_each_dev+0x54
> /0x84)
>  r6:00000000 r5:c01ce278 r4:c0381c68 r3:00000000
> [<c01cd974>] (bus_for_each_dev+0x0/0x84) from [<c01ce00c>] (driver_attach+0x20/0
> x28)
>  r6:c037eb00 r5:df859c80 r4:c0381c68
> [<c01cdfec>] (driver_attach+0x0/0x28) from [<c01cd2b4>] (bus_add_driver+0xb4/0x2
> 28)
> [<c01cd200>] (bus_add_driver+0x0/0x228) from [<c01ce5f8>] (driver_register+0xb0/
> 0x13c)
> [<c01ce548>] (driver_register+0x0/0x13c) from [<c01cf64c>] (platform_driver_regi
> ster+0x4c/0x60)
>  r8:00000000 r7:00000000 r6:c003c3e8 r5:c001937c r4:c0381c54
> r3:00000000
> [<c01cf600>] (platform_driver_register+0x0/0x60) from [<c01cf680>] (platform_dri
> ver_probe+0x20/0x70)
> [<c01cf660>] (platform_driver_probe+0x0/0x70) from [<c0019394>] (sdma_module_ini
> t+0x18/0x24)
>  r5:c001937c r4:c001ed30
> [<c001937c>] (sdma_module_init+0x0/0x24) from [<c00243d4>] (do_one_initcall+0xd4
> /0x1a8)
> [<c0024300>] (do_one_initcall+0x0/0x1a8) from [<c00085a0>] (kernel_init+0x9c/0x1
> 54)
> [<c0008504>] (kernel_init+0x0/0x154) from [<c003c3e8>] (do_exit+0x0/0x58c)
>  r4:00000000 r3:00000000
> Code: e59f00e0 eb034ae1 e59530ac e5933038 (e5b30048)
> ---[ end trace 1b75b31a2719ed1c ]---
> Kernel panic - not syncing: Attempted to kill init!
>
> I am trying to fix this, but suggestions are welcome.

Even if the fw name is bad, it should not crash. Maybe missing some
checks or init code ? Of course, it's only an idea. Your problem may
have nothing to do with missing firmware.

Arnaud

[PATCH] imx: dma: remove SDMA_IS_MERGED

[Fabio Estevam]

Hi Arnaud,

On Thu, Nov 25, 2010 at 10:29 AM, Arnaud Patard
<arnaud.patard@rtp-net.org> wrote:
> Fabio Estevam <festevam@gmail.com> writes:
...
> I've tried some weeks ago to boot with sdma support enabled and found
> out that it was looking for sdma-imx51-to0.bin so I thought it was still
> early work and gave up. Maybe it's still not fixed.

Yes, I fixed this by passing the correct tape-out version into the
sdma platform, so that it searches for sdma-imx51-to1.bin now.

I can send a patch for this later.
....
>> I am trying to fix this, but suggestions are welcome.
>
> Even if the fw name is bad, it should not crash. Maybe missing some
> checks or init code ? Of course, it's only an idea. Your problem may
> have nothing to do with missing firmware.

Yes, this crash problem is not related to the missing firmware.

Thanks,

Fabio Estevam

[PATCH] imx: dma: remove SDMA_IS_MERGED

[Uwe Kleine-König]

On Thu, Nov 25, 2010 at 10:32:59AM -0200, Fabio Estevam wrote:
> Hi Arnaud,
> 
> On Thu, Nov 25, 2010 at 10:29 AM, Arnaud Patard
> <arnaud.patard@rtp-net.org> wrote:
> > Fabio Estevam <festevam@gmail.com> writes:
> ...
> > I've tried some weeks ago to boot with sdma support enabled and found
> > out that it was looking for sdma-imx51-to0.bin so I thought it was still
> > early work and gave up. Maybe it's still not fixed.
> 
> Yes, I fixed this by passing the correct tape-out version into the
> sdma platform, so that it searches for sdma-imx51-to1.bin now.
> 
> I can send a patch for this later.
> ....
> >> I am trying to fix this, but suggestions are welcome.
> >
> > Even if the fw name is bad, it should not crash. Maybe missing some
> > checks or init code ? Of course, it's only an idea. Your problem may
> > have nothing to do with missing firmware.
> 
> Yes, this crash problem is not related to the missing firmware.
I think you need to build the firmware in.  When it's requested
userspace isn't ready yet to serve it.

Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[PATCH] imx: dma: remove SDMA_IS_MERGED

[Sascha Hauer]

On Thu, Nov 25, 2010 at 10:09:58AM -0200, Fabio Estevam wrote:
> Hi Sascha,
> 
> On Thu, Nov 25, 2010 at 7:13 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > On Wed, Nov 24, 2010 at 07:42:31PM -0200, Fabio Estevam wrote:
> >> Hi Uwe,
> >>
> >> 2010/11/24 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
> >> ....
> >> > I usually prefer just using DEBUG_LL and put
> >> >
> >> > ? ? ? ?#ifdef CONFIG_DEBUG_LL
> >> > ? ? ? ? ? ? ? ?void printch(char);
> >> > ? ? ? ? ? ? ? ?printch(c);
> >> > ? ? ? ?#endif
> >> >
> >> > into emit_log_char. ?But I think that's only because I don't know how to
> >> > use early printk properly. ?(You might need an additional kernel
> >> > parameter?!)
> >>
> >> Thanks. I see that the kernel crashes at sdma_get_firmware.
> >
> > This is a bug which should be fixed in this -rc cycle. Anyway, note
> > that I have a patch in my for-2.6.38 queue which makes the SDMA work
> > without a valid firmware. In this case only the scripts in ROM are used.
> 
> Yes, I am using your for-next branch, which contains the patch to make
> SDMA work without a valid firmware.
> 
> I also generated the SDMA firmware (sdma-imx51-to1.bin) via your sdma
> tool and placed it under /lib/firmware, but the result is the same
> with or without a valid firmware: when request_firmware is called the
> following crash happens:

I tried to reproduce this today. Instead of crashing my kernel simply
hangs. This seems to be because request_firmware waits till the firmware
appears which never happens. I remember a crash like this though, I
think it has something to do with the firmware related kconfig options.
I hope to find a time slot later this week to track this down.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH] imx: dma: remove SDMA_IS_MERGED

[Fabio Estevam]

Hi Sascha,

On Mon, Nov 29, 2010 at 7:24 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
....
>> I also generated the SDMA firmware (sdma-imx51-to1.bin) via your sdma
>> tool and placed it under /lib/firmware, but the result is the same
>> with or without a valid firmware: when request_firmware is called the
>> following crash happens:
>
> I tried to reproduce this today. Instead of crashing my kernel simply
> hangs. This seems to be because request_firmware waits till the firmware
> appears which never happens. I remember a crash like this though, I
> think it has something to do with the firmware related kconfig options.
> I hope to find a time slot later this week to track this down.

Could you please share your .config?

I would like to compare what may be causing the different behaviours
we are seeing.

Thanks,

Fabio Estevam

[PATCH] imx: dma: remove SDMA_IS_MERGED

[Sascha Hauer]

On Mon, Nov 29, 2010 at 08:27:21PM -0200, Fabio Estevam wrote:
> Hi Sascha,
> 
> On Mon, Nov 29, 2010 at 7:24 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> ....
> >> I also generated the SDMA firmware (sdma-imx51-to1.bin) via your sdma
> >> tool and placed it under /lib/firmware, but the result is the same
> >> with or without a valid firmware: when request_firmware is called the
> >> following crash happens:
> >
> > I tried to reproduce this today. Instead of crashing my kernel simply
> > hangs. This seems to be because request_firmware waits till the firmware
> > appears which never happens. I remember a crash like this though, I
> > think it has something to do with the firmware related kconfig options.
> > I hope to find a time slot later this week to track this down.
> 
> Could you please share your .config?
> 
> I would like to compare what may be causing the different behaviours
> we are seeing.

It seems the reason for the crash is that firmware_class registers in
fs_initcall whereas the sdma driver uses it at subsys_initcall time.
Solution is to either use module_init in the sdma driver or
subsys_initcall in drivers/base/firmware_class.c.

When given a firmware it works, when no firmware is given the kernel
locks for some time because it waits for the firmware to appear which
never happens. We should probably use request_firmware_nowait in the
sdma driver.

I put together a branch with sdma sound working on the babbage and
mx35-3ds boards using mx3_defconfig/mx51_defconfig from this branch.
The branch works with and without firmware with the mentioned wait time
when the firmware is not available.

BTW I changed the SDMA firmware repository to name the i.MX51 firmware
*to3.bin instead of to1, because that's what it actually is.

Sound support is a story with many frameworks and a lot of board
specifics involved, but I hope we manage to sort this out for i.MX soon.
Sorry for the inconvenience.

It would be great if someone steps forward and mainlines this sgtl5000
codec driver, that's currently the main showstopper for sound support on
the Freescale boards.

Sascha


The following changes since commit 72083646528d4887b920deb71b37e09bc7d227bb:

  Un-inline get_pipe_info() helper function (2010-11-28 16:27:19 -0800)

are available in the git repository at:
  git://git.pengutronix.de/git/imx/linux-2.6.git imx-sdma-sound-mx353ds-mx51_babbage

Sascha Hauer (22):
      ASoC: i.MX31ads: initialize only on correct machine
      dmaengine i.MX SDMA: Allow to run without firmware
      ARM i.MX SDMA: Add ROM script addresses to platform_data
      ASoC i.MX DMA: add forgotten dma burstsize settings
      drivers/base: move firmware_class_init to subsys_initcall
      ARM i.MX3: add dma request defines
      ARM i.MX3: add dma request resources to ssi/sdhc devices
      imx-pcm-fiq: We can support mono
      ASoC: i.MX: we can do mono
      ASoC: Add bluetooth codec support
      ASoC: Add mc13783 codec support (multicomponent fixes untested)
      ASoC: Add sgtl5000 codec support
      ASoC: Add sound support for i.MX baords based on the sgtl5000 codec
      ASoC: Add phyCORE mc13783 audio support (multicomponent fixes untested)
      ARM i.MX pcm038: Add sound support
      ARM i.MX pcm037: Add sound support
      ARM i.MX35 3stack: Add sound support
      wip: ASoC: imx-ssi: Fix occasional AC97 reset failure
      mxcmmc: use new dma api
      ARM MX51 babbage: Add sound support
      update mx51_defconfig (with sound for i.MX51 babbage)
      update mx3_defconfig (with sound for i.MX35 3ds)

Uwe Kleine-K?nig (2):
      ARM: imx: microoptimize ssi fiq handler
      ASoC: imx-ssi: instrument register accesses

 arch/arm/configs/mx3_defconfig               |   67 ++-
 arch/arm/configs/mx51_defconfig              |   61 ++-
 arch/arm/mach-imx/mach-pcm038.c              |   24 +-
 arch/arm/mach-mx3/clock-imx35.c              |    5 +
 arch/arm/mach-mx3/devices.c                  |    8 +
 arch/arm/mach-mx3/mach-mx35_3ds.c            |   51 ++
 arch/arm/mach-mx3/mach-pcm037.c              |   67 ++
 arch/arm/mach-mx5/Kconfig                    |    1 +
 arch/arm/mach-mx5/board-mx51_babbage.c       |   40 ++
 arch/arm/plat-mxc/devices/platform-imx-dma.c |  104 +++-
 arch/arm/plat-mxc/include/mach/mx31.h        |   13 +
 arch/arm/plat-mxc/include/mach/mx35.h        |   25 +
 arch/arm/plat-mxc/include/mach/mx3x.h        |   29 +
 arch/arm/plat-mxc/include/mach/sdma.h        |   46 ++
 arch/arm/plat-mxc/ssi-fiq.S                  |   10 +-
 drivers/base/firmware_class.c                |    2 +-
 drivers/dma/imx-sdma.c                       |  174 +++---
 drivers/mmc/host/mxcmmc.c                    |  172 +++--
 sound/soc/codecs/Kconfig                     |   11 +
 sound/soc/codecs/Makefile                    |    6 +
 sound/soc/codecs/bluetooth.c                 |  156 +++++
 sound/soc/codecs/mc13783.c                   |  656 ++++++++++++++++++
 sound/soc/codecs/mc13783.h                   |   29 +
 sound/soc/codecs/sgtl5000.c                  |  953 ++++++++++++++++++++++++++
 sound/soc/codecs/sgtl5000.h                  |  396 +++++++++++
 sound/soc/imx/Kconfig                        |   24 +
 sound/soc/imx/Makefile                       |    4 +
 sound/soc/imx/imx-pcm-dma-mx2.c              |    5 +
 sound/soc/imx/imx-pcm-fiq.c                  |    2 +-
 sound/soc/imx/imx-sgtl5000.c                 |  287 ++++++++
 sound/soc/imx/imx-ssi.c                      |  124 ++--
 sound/soc/imx/phycore-mc13783.c              |  152 ++++
 sound/soc/imx/wm1133-ev1.c                   |    4 +
 33 files changed, 3447 insertions(+), 261 deletions(-)
 create mode 100644 sound/soc/codecs/bluetooth.c
 create mode 100644 sound/soc/codecs/mc13783.c
 create mode 100644 sound/soc/codecs/mc13783.h
 create mode 100644 sound/soc/codecs/sgtl5000.c
 create mode 100644 sound/soc/codecs/sgtl5000.h
 create mode 100644 sound/soc/imx/imx-sgtl5000.c
 create mode 100644 sound/soc/imx/phycore-mc13783.c

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH] imx: dma: remove SDMA_IS_MERGED

[Arnaud Patard (Rtp)]

Sascha Hauer <s.hauer@pengutronix.de> writes:

> On Mon, Nov 29, 2010 at 08:27:21PM -0200, Fabio Estevam wrote:
>> Hi Sascha,
>> 
>> On Mon, Nov 29, 2010 at 7:24 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
>> ....
>> >> I also generated the SDMA firmware (sdma-imx51-to1.bin) via your sdma
>> >> tool and placed it under /lib/firmware, but the result is the same
>> >> with or without a valid firmware: when request_firmware is called the
>> >> following crash happens:
>> >
>> > I tried to reproduce this today. Instead of crashing my kernel simply
>> > hangs. This seems to be because request_firmware waits till the firmware
>> > appears which never happens. I remember a crash like this though, I
>> > think it has something to do with the firmware related kconfig options.
>> > I hope to find a time slot later this week to track this down.
>> 
>> Could you please share your .config?
>> 
>> I would like to compare what may be causing the different behaviours
>> we are seeing.
>
> It seems the reason for the crash is that firmware_class registers in
> fs_initcall whereas the sdma driver uses it at subsys_initcall time.
> Solution is to either use module_init in the sdma driver or
> subsys_initcall in drivers/base/firmware_class.c.

When do we need to get sdma initialised & working ? if it's needed only
by drivers, module_init should be fine, right ?

>
> When given a firmware it works, when no firmware is given the kernel
> locks for some time because it waits for the firmware to appear which
> never happens. We should probably use request_firmware_nowait in the
> sdma driver.

what will happen if request_firmware_nowait() fails ? sdma becomes
non-functionnal ?

>
> I put together a branch with sdma sound working on the babbage and
> mx35-3ds boards using mx3_defconfig/mx51_defconfig from this branch.
> The branch works with and without firmware with the mentioned wait time
> when the firmware is not available.

oh, you have a working sgtl5000 driver ready for mainline ?

>
> BTW I changed the SDMA firmware repository to name the i.MX51 firmware
> *to3.bin instead of to1, because that's what it actually is.
>
> Sound support is a story with many frameworks and a lot of board
> specifics involved, but I hope we manage to sort this out for i.MX soon.
> Sorry for the inconvenience.
>
> It would be great if someone steps forward and mainlines this sgtl5000
> codec driver, that's currently the main showstopper for sound support on
> the Freescale boards.

hmm.... so I guess that I can answer myself at my last question: no. At
least your sound branch can be used to test sound support ?

Arnaud

[PATCH] imx: dma: remove SDMA_IS_MERGED

[Fabio Estevam]

Hi Sascha,

On Wed, Dec 1, 2010 at 9:14 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
...
> It seems the reason for the crash is that firmware_class registers in
> fs_initcall whereas the sdma driver uses it at subsys_initcall time.
> Solution is to either use module_init in the sdma driver or
> subsys_initcall in drivers/base/firmware_class.c.
>
> When given a firmware it works, when no firmware is given the kernel
> locks for some time because it waits for the firmware to appear which
> never happens. We should probably use request_firmware_nowait in the
> sdma driver.
>
> I put together a branch with sdma sound working on the babbage and
> mx35-3ds boards using mx3_defconfig/mx51_defconfig from this branch.
> The branch works with and without firmware with the mentioned wait time
> when the firmware is not available.
>
> BTW I changed the SDMA firmware repository to name the i.MX51 firmware
> *to3.bin instead of to1, because that's what it actually is.
>
> Sound support is a story with many frameworks and a lot of board
> specifics involved, but I hope we manage to sort this out for i.MX soon.
> Sorry for the inconvenience.
>
> It would be great if someone steps forward and mainlines this sgtl5000
> codec driver, that's currently the main showstopper for sound support on
> the Freescale boards.

Thanks a lot for setting up this branch. I can confirm that audio
works on MX51 Babbage on this branch.

I will check internally if someone is willing to mainline sgtl5000.

Thanks,

Fabio Estevam

[PATCH] imx: dma: remove SDMA_IS_MERGED

[Sascha Hauer]

On Wed, Dec 01, 2010 at 12:35:17PM +0100, Arnaud Patard wrote:
> Sascha Hauer <s.hauer@pengutronix.de> writes:
> 
> > On Mon, Nov 29, 2010 at 08:27:21PM -0200, Fabio Estevam wrote:
> >> Hi Sascha,
> >> 
> >> On Mon, Nov 29, 2010 at 7:24 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> >> ....
> >> >> I also generated the SDMA firmware (sdma-imx51-to1.bin) via your sdma
> >> >> tool and placed it under /lib/firmware, but the result is the same
> >> >> with or without a valid firmware: when request_firmware is called the
> >> >> following crash happens:
> >> >
> >> > I tried to reproduce this today. Instead of crashing my kernel simply
> >> > hangs. This seems to be because request_firmware waits till the firmware
> >> > appears which never happens. I remember a crash like this though, I
> >> > think it has something to do with the firmware related kconfig options.
> >> > I hope to find a time slot later this week to track this down.
> >> 
> >> Could you please share your .config?
> >> 
> >> I would like to compare what may be causing the different behaviours
> >> we are seeing.
> >
> > It seems the reason for the crash is that firmware_class registers in
> > fs_initcall whereas the sdma driver uses it at subsys_initcall time.
> > Solution is to either use module_init in the sdma driver or
> > subsys_initcall in drivers/base/firmware_class.c.
> 
> When do we need to get sdma initialised & working ? if it's needed only
> by drivers, module_init should be fine, right ?

It's needed only by drivers, yes. If it's fine depends on the link
order. The SDMA code is needed by the mxcmmc driver dor example, which
happens to be initialized after the dma code (see drivers/Makefile). So
it's fine as long nobody changes this order.

> 
> >
> > When given a firmware it works, when no firmware is given the kernel
> > locks for some time because it waits for the firmware to appear which
> > never happens. We should probably use request_firmware_nowait in the
> > sdma driver.
> 
> what will happen if request_firmware_nowait() fails ? sdma becomes
> non-functionnal ?

I haven't really looked into it. With one patch of my for-next queue the
SDMA engine runs will run without any firmware using the scripts in ROM.
So I suppose we can change the code so that once the firmware actually
is available we can add the missing RAM script pointers.

> 
> >
> > I put together a branch with sdma sound working on the babbage and
> > mx35-3ds boards using mx3_defconfig/mx51_defconfig from this branch.
> > The branch works with and without firmware with the mentioned wait time
> > when the firmware is not available.
> 
> oh, you have a working sgtl5000 driver ready for mainline ?

In the said branch there is a cleaned up sgtl5000 driver. What I would
do next is to post it and see what reactions I get. Unfortunately I
don't have the time to react on the reviews at the moment.

> 
> >
> > BTW I changed the SDMA firmware repository to name the i.MX51 firmware
> > *to3.bin instead of to1, because that's what it actually is.
> >
> > Sound support is a story with many frameworks and a lot of board
> > specifics involved, but I hope we manage to sort this out for i.MX soon.
> > Sorry for the inconvenience.
> >
> > It would be great if someone steps forward and mainlines this sgtl5000
> > codec driver, that's currently the main showstopper for sound support on
> > the Freescale boards.
> 
> hmm.... so I guess that I can answer myself at my last question: no.

Well, as said I consider it ready for a first try. I don't now what Mark
Brown says to it though.

> At
> least your sound branch can be used to test sound support ?

Yes. It works on my babbage board and on a i.MX35 3ds board.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH] imx: dma: remove SDMA_IS_MERGED

[Arnaud Patard (Rtp)]

Sascha Hauer <s.hauer@pengutronix.de> writes:

Hi,
> On Wed, Dec 01, 2010 at 12:35:17PM +0100, Arnaud Patard wrote:
>> Sascha Hauer <s.hauer@pengutronix.de> writes:
>> 
>> > On Mon, Nov 29, 2010 at 08:27:21PM -0200, Fabio Estevam wrote:
>> >> Hi Sascha,
>> >> 
>> >> On Mon, Nov 29, 2010 at 7:24 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
>> >> ....
>> >> >> I also generated the SDMA firmware (sdma-imx51-to1.bin) via your sdma
>> >> >> tool and placed it under /lib/firmware, but the result is the same
>> >> >> with or without a valid firmware: when request_firmware is called the
>> >> >> following crash happens:
>> >> >
>> >> > I tried to reproduce this today. Instead of crashing my kernel simply
>> >> > hangs. This seems to be because request_firmware waits till the firmware
>> >> > appears which never happens. I remember a crash like this though, I
>> >> > think it has something to do with the firmware related kconfig options.
>> >> > I hope to find a time slot later this week to track this down.
>> >> 
>> >> Could you please share your .config?
>> >> 
>> >> I would like to compare what may be causing the different behaviours
>> >> we are seeing.
>> >
>> > It seems the reason for the crash is that firmware_class registers in
>> > fs_initcall whereas the sdma driver uses it at subsys_initcall time.
>> > Solution is to either use module_init in the sdma driver or
>> > subsys_initcall in drivers/base/firmware_class.c.
>> 
>> When do we need to get sdma initialised & working ? if it's needed only
>> by drivers, module_init should be fine, right ?
>
> It's needed only by drivers, yes. If it's fine depends on the link
> order. The SDMA code is needed by the mxcmmc driver dor example, which
> happens to be initialized after the dma code (see drivers/Makefile). So
> it's fine as long nobody changes this order.
>

I think that the pata driver in freescale tree is using SDMA... so it
won't work ?

>> 
>> >
>> > When given a firmware it works, when no firmware is given the kernel
>> > locks for some time because it waits for the firmware to appear which
>> > never happens. We should probably use request_firmware_nowait in the
>> > sdma driver.
>> 
>> what will happen if request_firmware_nowait() fails ? sdma becomes
>> non-functionnal ?
>
> I haven't really looked into it. With one patch of my for-next queue the
> SDMA engine runs will run without any firmware using the scripts in ROM.
> So I suppose we can change the code so that once the firmware actually
> is available we can add the missing RAM script pointers.
>
>> 
>> >
>> > I put together a branch with sdma sound working on the babbage and
>> > mx35-3ds boards using mx3_defconfig/mx51_defconfig from this branch.
>> > The branch works with and without firmware with the mentioned wait time
>> > when the firmware is not available.
>> 
>> oh, you have a working sgtl5000 driver ready for mainline ?
>
> In the said branch there is a cleaned up sgtl5000 driver. What I would
> do next is to post it and see what reactions I get. Unfortunately I
> don't have the time to react on the reviews at the moment.
>
>> 
>> >
>> > BTW I changed the SDMA firmware repository to name the i.MX51 firmware
>> > *to3.bin instead of to1, because that's what it actually is.
>> >

what about to2 ?

>> > Sound support is a story with many frameworks and a lot of board
>> > specifics involved, but I hope we manage to sort this out for i.MX soon.
>> > Sorry for the inconvenience.
>> >
>> > It would be great if someone steps forward and mainlines this sgtl5000
>> > codec driver, that's currently the main showstopper for sound support on
>> > the Freescale boards.
>> 
>> hmm.... so I guess that I can answer myself at my last question: no.
>
> Well, as said I consider it ready for a first try. I don't now what Mark
> Brown says to it though.
>
>> At
>> least your sound branch can be used to test sound support ?
>
> Yes. It works on my babbage board and on a i.MX35 3ds board.

so, after fighting a little bit (my work is based on your 2.6.38 branch
so I've made a patch to get you sdma sound branch on it), sound started
to work here too. Once the patch ported, my main troubles were :
- no license on snd-soc-imx-mx2.ko
- sgtl5000 doesn't support regulator

Arnaud

[PATCH] imx: dma: remove SDMA_IS_MERGED

[Sascha Hauer]

On Thu, Dec 02, 2010 at 12:44:29AM +0100, Arnaud Patard wrote:
> Sascha Hauer <s.hauer@pengutronix.de> writes:
> 
> Hi,
> > On Wed, Dec 01, 2010 at 12:35:17PM +0100, Arnaud Patard wrote:
> >> Sascha Hauer <s.hauer@pengutronix.de> writes:
> >> 
> >> > On Mon, Nov 29, 2010 at 08:27:21PM -0200, Fabio Estevam wrote:
> >> >> Hi Sascha,
> >> >> 
> >> >> On Mon, Nov 29, 2010 at 7:24 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> >> >> ....
> >> >> >> I also generated the SDMA firmware (sdma-imx51-to1.bin) via your sdma
> >> >> >> tool and placed it under /lib/firmware, but the result is the same
> >> >> >> with or without a valid firmware: when request_firmware is called the
> >> >> >> following crash happens:
> >> >> >
> >> >> > I tried to reproduce this today. Instead of crashing my kernel simply
> >> >> > hangs. This seems to be because request_firmware waits till the firmware
> >> >> > appears which never happens. I remember a crash like this though, I
> >> >> > think it has something to do with the firmware related kconfig options.
> >> >> > I hope to find a time slot later this week to track this down.
> >> >> 
> >> >> Could you please share your .config?
> >> >> 
> >> >> I would like to compare what may be causing the different behaviours
> >> >> we are seeing.
> >> >
> >> > It seems the reason for the crash is that firmware_class registers in
> >> > fs_initcall whereas the sdma driver uses it at subsys_initcall time.
> >> > Solution is to either use module_init in the sdma driver or
> >> > subsys_initcall in drivers/base/firmware_class.c.
> >> 
> >> When do we need to get sdma initialised & working ? if it's needed only
> >> by drivers, module_init should be fine, right ?
> >
> > It's needed only by drivers, yes. If it's fine depends on the link
> > order. The SDMA code is needed by the mxcmmc driver dor example, which
> > happens to be initialized after the dma code (see drivers/Makefile). So
> > it's fine as long nobody changes this order.
> >
> 
> I think that the pata driver in freescale tree is using SDMA... so it
> won't work ?

Probably not.

> 
> >> 
> >> >
> >> > When given a firmware it works, when no firmware is given the kernel
> >> > locks for some time because it waits for the firmware to appear which
> >> > never happens. We should probably use request_firmware_nowait in the
> >> > sdma driver.
> >> 
> >> what will happen if request_firmware_nowait() fails ? sdma becomes
> >> non-functionnal ?
> >
> > I haven't really looked into it. With one patch of my for-next queue the
> > SDMA engine runs will run without any firmware using the scripts in ROM.
> > So I suppose we can change the code so that once the firmware actually
> > is available we can add the missing RAM script pointers.
> >
> >> 
> >> >
> >> > I put together a branch with sdma sound working on the babbage and
> >> > mx35-3ds boards using mx3_defconfig/mx51_defconfig from this branch.
> >> > The branch works with and without firmware with the mentioned wait time
> >> > when the firmware is not available.
> >> 
> >> oh, you have a working sgtl5000 driver ready for mainline ?
> >
> > In the said branch there is a cleaned up sgtl5000 driver. What I would
> > do next is to post it and see what reactions I get. Unfortunately I
> > don't have the time to react on the reviews at the moment.
> >
> >> 
> >> >
> >> > BTW I changed the SDMA firmware repository to name the i.MX51 firmware
> >> > *to3.bin instead of to1, because that's what it actually is.
> >> >
> 
> what about to2 ?

Someone from Freescale (I think it was Yong) said to me 'if you find a
board with an i.MX51 older than to3 outside of Freescale, just throw it
away'. I don't know which SDMA code we have to use for to2.

> 
> >> > Sound support is a story with many frameworks and a lot of board
> >> > specifics involved, but I hope we manage to sort this out for i.MX soon.
> >> > Sorry for the inconvenience.
> >> >
> >> > It would be great if someone steps forward and mainlines this sgtl5000
> >> > codec driver, that's currently the main showstopper for sound support on
> >> > the Freescale boards.
> >> 
> >> hmm.... so I guess that I can answer myself at my last question: no.
> >
> > Well, as said I consider it ready for a first try. I don't now what Mark
> > Brown says to it though.
> >
> >> At
> >> least your sound branch can be used to test sound support ?
> >
> > Yes. It works on my babbage board and on a i.MX35 3ds board.
> 
> so, after fighting a little bit (my work is based on your 2.6.38 branch
> so I've made a patch to get you sdma sound branch on it), sound started
> to work here too. Once the patch ported, my main troubles were :
> - no license on snd-soc-imx-mx2.ko
> - sgtl5000 doesn't support regulator

Let's wait for Yongs MC13892 regulator driver then.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH] imx: dma: remove SDMA_IS_MERGED

[Fabio Estevam]

On Thu, Dec 2, 2010 at 10:14 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
...
>> what about to2 ?
>
> Someone from Freescale (I think it was Yong) said to me 'if you find a
> board with an i.MX51 older than to3 outside of Freescale, just throw it
> away'. I don't know which SDMA code we have to use for to2.

MX51TO2 and MX51TO3 use the same SDMA firmware.

Regards,

Fabio Estevam

[PATCH] imx: dma: remove SDMA_IS_MERGED

[Arnaud Patard (Rtp)]

Fabio Estevam <festevam@gmail.com> writes:

Hi,

[...]

>> It would be great if someone steps forward and mainlines this sgtl5000
>> codec driver, that's currently the main showstopper for sound support on
>> the Freescale boards.
>
> Thanks a lot for setting up this branch. I can confirm that audio
> works on MX51 Babbage on this branch.
>
> I will check internally if someone is willing to mainline sgtl5000.

If you find no vic^H^H^Hvolunteer, I'll look at it. Looks like the
sgtl5000 chipset is not very complicated.

Arnaud

[PATCH] imx: dma: remove SDMA_IS_MERGED

[Fabio Estevam]

Arnaud,

On Fri, Dec 3, 2010 at 11:00 AM, Arnaud Patard
<arnaud.patard@rtp-net.org> wrote:
> Fabio Estevam <festevam@gmail.com> writes:
>
> Hi,
>
> [...]
>
>>> It would be great if someone steps forward and mainlines this sgtl5000
>>> codec driver, that's currently the main showstopper for sound support on
>>> the Freescale boards.
>>
>> Thanks a lot for setting up this branch. I can confirm that audio
>> works on MX51 Babbage on this branch.
>>
>> I will check internally if someone is willing to mainline sgtl5000.
>
> If you find no vic^H^H^Hvolunteer, I'll look at it. Looks like the
> sgtl5000 chipset is not very complicated.

Ok, please go ahead.

Regards,

Fabio Estevam