On 11/9/2009 2:31 PM, jassi brar wrote: > On Mon, Nov 9, 2009 at 2:14 PM, Joonyoung Shim <jy0922.shim@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 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? _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
