[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 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 ?

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 |