[PATCH] imx: dma: remove SDMA_IS_MERGED

[Arnaud Patard (Rtp)]

Sascha Hauer <s.hauer at 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 at 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