[alsa-devel] [PATCH 1/7] S3C AUDIO: Rename s3c24xx_pcm prefix to s3c_dma

Joonyoung Shim jy0922.shim at samsung.com
Mon Nov 9 07:19:40 CET 2009

On 11/9/2009 2:31 PM, jassi brar wrote:
> On Mon, Nov 9, 2009 at 2:14 PM, Joonyoung Shim <jy0922.shim at samsung.com> wrote:
>> On 11/7/2009 12:46 PM, jassi brar wrote:
>>>> On Thu, Nov 05, 2009 at 02:03:08PM +0900, Joonyoung Shim wrote:
>>>>> On 11/5/2009 1:16 PM, jassi brar wrote:
>>> On Sat, Nov 7, 2009 at 1:23 AM, Mark Brown
>>> <broonie at opensource.wolfsonmicro.com> wrote:
>>>>>> These patches is not about changing naming conventions. Only changes, necessary
>>>>>> to have a clean and consistent namespace after integrating PCM driver, have
>>>>>> been made.
>>>>> Agree, but you already are changing the prefix from s3c24xx to s3c.
>>>> I also agree with this - if we're renaming this driver anyway then
>>>> changing the prefix for it while we're at it seems reasonable, it means
>>>> one less change in the future.
>>> renaming is a box of worms which i dont wanna be the first to open.
>>> I would wait for a complete discussion on the naming conventions to happen
>>> and have a decision made before I do renaming.
>>> Though, I can resend the patch with samsung_ prefix too, if everyone
>>> is willing to
>>> hold their peace forever.
>>>>>> but if we try so, we have the following
>>>>>> 혻1) s3c24xx_pcm_dma_params -> s3c_dma_dma_params
>>>>>> 혻2) s3c24xx_pcm_preallocate_dma_buffer -> s3c_dma_preallocate_dma_buffer
>>>>>> 혻3) s3c24xx_pcm_dmamask -> s3c_dma_dmamask
>>>>>> none of which seem very nice.
>>>>> You can modify the names for the consistent prefix. If you
>>>>> use s3c_dma_ prefix, for example, s3c24xx_pcm_dma_params can be to
>>>>> s3c_dma_params.
>>>> I tend to agree with this. 혻The actual rename needs to happen to free up
>>>> the PCM name for the driver for the PCM hardware.
>>> So taking into account the aforementioned point as well, you suggest
>>> 1) s3c24xx_pcm_dma_params -> samsung_dma_params
>>> 2) s3c24xx_pcm_preallocate_dma_buffer -> samsung_preallocate_dma_buffer
>>> 3) s3c24xx_pcm_dmamask -> samsung_dmamask
>>> 4) s3c24xx_pcm_XXX -> samsung_dma_XXX
>> Hmm, i was missing about the DMA on the prior mail. We should consider
>> the DMA with this. The DMA chip(PL330) of s5p CPUs differs with s3c
>> CPUs. We first should desided whether use the existing DMA interface of
>> s3c. If we use it, this prefix is better samsung than s3c.
>> The other option is using the DMA subsystem about s5p DMA. This need
>> also implementing ASoC platform driver of s5p for DMA, so it is better
>> two each different prefix than samsung. I have posted the s5p DMA driver
>> using the DMA subsystem.
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2009-September/000810.html
> It doesn't make much sense to base new drivers over a DMA driver which hasn't
> been accepted(no ACK no NAK to your code). So, currently I assume
> PL330 DMA api same as that of PL080.

I'm not sure which is better, but i think above option all is possible.
I just concerns if use the existing s3c DMA interface, are not there some
implementation problems or the naming problems?

I don't know why Ben doesn't use the DMA subsystem at s3c64xx
CPU(PL080). I just think because the PL080 chip of s3c64xx has some
customized parts or for the DMA interface compatibility of s3c24xx.

Ben, what do you think about this issue?

More information about the Alsa-devel mailing list