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

[Daniel Mack]

On 04.10.2012 11:38, Porter, Matt wrote:
> 
> On Oct 4, 2012, at 5:21 AM, Daniel Mack wrote:
> 
>>
>>
>> On 02.10.2012 18:50, Daniel Mack wrote:
>>> On 02.10.2012 18:41, Matt Porter wrote:
>>>> On Tue, Oct 02, 2012 at 03:42:47PM +0200, Daniel Mack wrote:
>>>>> On 02.10.2012 13:06, Sekhar Nori wrote:
>>>>>> On 10/2/2012 4:03 PM, Daniel Mack wrote:
>>>>>>> On 02.10.2012 11:37, Mark Brown wrote:
>>>>>>>> On Tue, Oct 02, 2012 at 10:48:53AM +0300, Peter Ujfalusi wrote:
>>>>>>>>
>>>>>>>>> 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?
>>>>
>>>> At the high level there's two platform models we have to handle, the
>>>> boot from board file !DT case, and then the boot from DT case. Since
>>>> Davinci is just starting DT conversion, we mostly care about the !DT
>>>> base in which the struct gen_pool * is passed in pdata to the ASoC
>>>> driver. It is then selectable on a per-platform basis where the decision
>>>> should be made.
>>>>
>>>> Given a separate discussion with Sekhar, we're only going to have one
>>>> SRAM pool on any DaVinci part right now...this was only a question on
>>>> L138 anyway. But regardless, the created gen_pool will be passed via
>>>> pdata.
>>>
>>> I thought about this too, as mmp does it that way.
>>>
>>>> Since DT conversion is starting and we need to consider that now,
>>>> the idea there is to use the DT-based generic sram driver [1] such that
>>>> when we do boot from DT on Davinci, the genpool is provided via phandle
>>>> and the pointer extracted with the OF helpers that are part of the
>>>> series.
>>>
>>> A phandle is the cleanest way I think, yes.
>>>
>>>> That's pretty much it. I'm reworking the backend support as discussed
>>>> with Sekhar wrt to my uio_pruss series. I can post a standalone series
>>>> that just replaces sram_* with genalloc for davinci ASoC.
>>>
>>> As you can also test it, it would be easiest if you came up with a patch
>>> for that, yes. I can have a look at the dma bits laters, once my OMAP
>>> board finally works with the code as it currently stands. I'm still
>>> fighting with the mcasp driver right now ...
>>
>> I quickly prepared two patches to change that, so that topic is out of
>> the way. But I did only compile-test them on OMAP - could you check on
>> your Davinci platform? Note that these apply on top of the patch in
>> discussion here (which isn't applied to the asoc tree yet).
> 
> I put a series together yesterday, just ran out of time to post
> last night after testing. I'm posting that now...it's on top of my
> uio_pruss/genalloc series and only addresss switching davinci-pcm to
> genalloc (and actually enabling ping-pon from sram).

Ok, I don't care which version makes it in after all :)

> I'll take a look a your OMAP patches.

The patches I just sent out are only for Davinci and change the SRAM
functions to genalloc in the mcasp driver. They work just fine on OMAP
of course, as the code is disabled in there.


Daniel