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

[jassi brar]

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.