[alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms

On 02.10.2012 13:06, Sekhar Nori wrote:

On 10/2/2012 4:03 PM, Daniel Mack wrote:

quoted

On 02.10.2012 11:37, Mark Brown wrote:

quoted

On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:

quoted

I also agree that ifdef is not a good solution.
It is better to have this information passed as device_data and via DT it can
be decided based on the compatible property for the device.

That's not really the problem here - the problem is that the APIs used
to get the SRAM are DaVinci only so it's not possible to build on OMAP
or other platforms.  The SRAM code needs to move to a standard API.

What about following Matt Porter's idea and ignore the SRAM code
entirely and port the entire PCM code to generic dmaengine code first?
The EDMA driver needs to learn support for cyclic DMA for that, and I
might give that a try in near future.

Later on, the SRAM ping-pong code can get added back using genalloc
functions, as Sekhar proposed. That needs to be done by someone who has
access to a Davinci board though, I only have a AM33xx/OMAP here.

We cannot "get rid" of SRAM code and add it back "later". It is required
for most DaVinci parts. The SRAM code can be converted to use genalloc
(conversion should be straightforward and I can help test it) and the
code that uses SRAM can probably keep using the private EDMA API till
the dmaengine EDMA driver has cyclic DMA support. Matt has already
posted patches to move private EDMA APIs to a common location. That
should keep AM335x build from breaking. Is this something that is feasible?

Yes - by "later" I just meant in a subsequent patch. But you're probably
right, we can also do that first.

I'm looking at that right now and the problem seems that we don't have a
sane way to dynamically look up gen_pools independently of the actual
run-time platform. All users of gen_pools seem to know which platform
they run on and access a platform-specific pool. So I don't currently
see how we could implement multi-platform code, gen_pools are fine but
don't solve the problem here.

Would it be an idea to add a char* member to gen_pools and a function
that can be used to dynamically look it up again? If a buffer with a
certain name exists, we can use it and install that ping-pong buffer,
otherwise we just don't. While that would be easy to do, it's a
tree-wide change.

Is there a better way that I miss?


Daniel