[PATCH] imx: dma: remove SDMA_IS_MERGED

[s.hauer@pengutronix.de (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 |