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

[Joonyoung Shim]

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?