[alsa-devel] [PATCH 1/7] S3C AUDIO: Rename s3c24xx_pcm prefix to s3c_dma
The s3c24xx_pcm prefix for the soc_platform is inappropriate when some Samsung SoCs have PCM controllers which will eventually have drivers and hence namespace ambiguities.
To resolve naming ambiguities in future the following have been renamed in order 1) s3c24xx_pcm_dma_params -> s3c_audio_dma_params 2) s3c24xx_pcm_preallocate_dma_buffer -> s3c_preallocate_dma_buffer 3) s3c24xx_pcm_dmamask -> s3c_dmamask 4) s3c24xx_pcm_XXX -> s3c_dma_XXX
Signed-off-by: Jassi Brar jassi.brar@samsung.com --- sound/soc/s3c24xx/s3c-i2s-v2.c | 2 +- sound/soc/s3c24xx/s3c-i2s-v2.h | 4 +- sound/soc/s3c24xx/s3c2412-i2s.c | 4 +- sound/soc/s3c24xx/s3c2443-ac97.c | 10 ++-- sound/soc/s3c24xx/s3c24xx-i2s.c | 10 ++-- sound/soc/s3c24xx/s3c24xx-pcm.c | 76 +++++++++++++++++++------------------- sound/soc/s3c24xx/s3c24xx-pcm.h | 6 +- sound/soc/s3c24xx/s3c64xx-i2s.c | 4 +- 8 files changed, 58 insertions(+), 58 deletions(-)
diff --git a/sound/soc/s3c24xx/s3c-i2s-v2.c b/sound/soc/s3c24xx/s3c-i2s-v2.c index 28b0ab2..9788e65 100644 --- a/sound/soc/s3c24xx/s3c-i2s-v2.c +++ b/sound/soc/s3c24xx/s3c-i2s-v2.c @@ -394,7 +394,7 @@ static int s3c2412_i2s_trigger(struct snd_pcm_substream *substream, int cmd, int capture = (substream->stream == SNDRV_PCM_STREAM_CAPTURE); unsigned long irqs; int ret = 0; - int channel = ((struct s3c24xx_pcm_dma_params *) + int channel = ((struct s3c_audio_dma_params *) rtd->dai->cpu_dai->dma_data)->channel;
pr_debug("Entered %s\n", __func__); diff --git a/sound/soc/s3c24xx/s3c-i2s-v2.h b/sound/soc/s3c24xx/s3c-i2s-v2.h index f66854a..02e16db 100644 --- a/sound/soc/s3c24xx/s3c-i2s-v2.h +++ b/sound/soc/s3c24xx/s3c-i2s-v2.h @@ -49,8 +49,8 @@ struct s3c_i2sv2_info {
unsigned char master;
- struct s3c24xx_pcm_dma_params *dma_playback; - struct s3c24xx_pcm_dma_params *dma_capture; + struct s3c_audio_dma_params *dma_playback; + struct s3c_audio_dma_params *dma_capture;
u32 suspend_iismod; u32 suspend_iiscon; diff --git a/sound/soc/s3c24xx/s3c2412-i2s.c b/sound/soc/s3c24xx/s3c2412-i2s.c index ac5e47b..6bc13d5 100644 --- a/sound/soc/s3c24xx/s3c2412-i2s.c +++ b/sound/soc/s3c24xx/s3c2412-i2s.c @@ -50,14 +50,14 @@ static struct s3c2410_dma_client s3c2412_dma_client_in = { .name = "I2S PCM Stereo in" };
-static struct s3c24xx_pcm_dma_params s3c2412_i2s_pcm_stereo_out = { +static struct s3c_audio_dma_params s3c2412_i2s_pcm_stereo_out = { .client = &s3c2412_dma_client_out, .channel = DMACH_I2S_OUT, .dma_addr = S3C2410_PA_IIS + S3C2412_IISTXD, .dma_size = 4, };
-static struct s3c24xx_pcm_dma_params s3c2412_i2s_pcm_stereo_in = { +static struct s3c_audio_dma_params s3c2412_i2s_pcm_stereo_in = { .client = &s3c2412_dma_client_in, .channel = DMACH_I2S_IN, .dma_addr = S3C2410_PA_IIS + S3C2412_IISRXD, diff --git a/sound/soc/s3c24xx/s3c2443-ac97.c b/sound/soc/s3c24xx/s3c2443-ac97.c index b25e9f9..d3bd29a 100644 --- a/sound/soc/s3c24xx/s3c2443-ac97.c +++ b/sound/soc/s3c24xx/s3c2443-ac97.c @@ -188,21 +188,21 @@ static struct s3c2410_dma_client s3c2443_dma_client_micin = { .name = "AC97 Mic Mono in" };
-static struct s3c24xx_pcm_dma_params s3c2443_ac97_pcm_stereo_out = { +static struct s3c_audio_dma_params s3c2443_ac97_pcm_stereo_out = { .client = &s3c2443_dma_client_out, .channel = DMACH_PCM_OUT, .dma_addr = S3C2440_PA_AC97 + S3C_AC97_PCM_DATA, .dma_size = 4, };
-static struct s3c24xx_pcm_dma_params s3c2443_ac97_pcm_stereo_in = { +static struct s3c_audio_dma_params s3c2443_ac97_pcm_stereo_in = { .client = &s3c2443_dma_client_in, .channel = DMACH_PCM_IN, .dma_addr = S3C2440_PA_AC97 + S3C_AC97_PCM_DATA, .dma_size = 4, };
-static struct s3c24xx_pcm_dma_params s3c2443_ac97_mic_mono_in = { +static struct s3c_audio_dma_params s3c2443_ac97_mic_mono_in = { .client = &s3c2443_dma_client_micin, .channel = DMACH_MIC_IN, .dma_addr = S3C2440_PA_AC97 + S3C_AC97_MIC_DATA, @@ -290,7 +290,7 @@ static int s3c2443_ac97_trigger(struct snd_pcm_substream *substream, int cmd, { u32 ac_glbctrl; struct snd_soc_pcm_runtime *rtd = substream->private_data; - int channel = ((struct s3c24xx_pcm_dma_params *) + int channel = ((struct s3c_audio_dma_params *) rtd->dai->cpu_dai->dma_data)->channel;
ac_glbctrl = readl(s3c24xx_ac97.regs + S3C_AC97_GLBCTRL); @@ -339,7 +339,7 @@ static int s3c2443_ac97_mic_trigger(struct snd_pcm_substream *substream, { u32 ac_glbctrl; struct snd_soc_pcm_runtime *rtd = substream->private_data; - int channel = ((struct s3c24xx_pcm_dma_params *) + int channel = ((struct s3c_audio_dma_params *) rtd->dai->cpu_dai->dma_data)->channel;
ac_glbctrl = readl(s3c24xx_ac97.regs + S3C_AC97_GLBCTRL); diff --git a/sound/soc/s3c24xx/s3c24xx-i2s.c b/sound/soc/s3c24xx/s3c24xx-i2s.c index c76b8bb..998e752 100644 --- a/sound/soc/s3c24xx/s3c24xx-i2s.c +++ b/sound/soc/s3c24xx/s3c24xx-i2s.c @@ -49,14 +49,14 @@ static struct s3c2410_dma_client s3c24xx_dma_client_in = { .name = "I2S PCM Stereo in" };
-static struct s3c24xx_pcm_dma_params s3c24xx_i2s_pcm_stereo_out = { +static struct s3c_audio_dma_params s3c24xx_i2s_pcm_stereo_out = { .client = &s3c24xx_dma_client_out, .channel = DMACH_I2S_OUT, .dma_addr = S3C2410_PA_IIS + S3C2410_IISFIFO, .dma_size = 2, };
-static struct s3c24xx_pcm_dma_params s3c24xx_i2s_pcm_stereo_in = { +static struct s3c_audio_dma_params s3c24xx_i2s_pcm_stereo_in = { .client = &s3c24xx_dma_client_in, .channel = DMACH_I2S_IN, .dma_addr = S3C2410_PA_IIS + S3C2410_IISFIFO, @@ -258,12 +258,12 @@ static int s3c24xx_i2s_hw_params(struct snd_pcm_substream *substream, switch (params_format(params)) { case SNDRV_PCM_FORMAT_S8: iismod &= ~S3C2410_IISMOD_16BIT; - ((struct s3c24xx_pcm_dma_params *) + ((struct s3c_audio_dma_params *) rtd->dai->cpu_dai->dma_data)->dma_size = 1; break; case SNDRV_PCM_FORMAT_S16_LE: iismod |= S3C2410_IISMOD_16BIT; - ((struct s3c24xx_pcm_dma_params *) + ((struct s3c_audio_dma_params *) rtd->dai->cpu_dai->dma_data)->dma_size = 2; break; default: @@ -280,7 +280,7 @@ static int s3c24xx_i2s_trigger(struct snd_pcm_substream *substream, int cmd, { int ret = 0; struct snd_soc_pcm_runtime *rtd = substream->private_data; - int channel = ((struct s3c24xx_pcm_dma_params *) + int channel = ((struct s3c_audio_dma_params *) rtd->dai->cpu_dai->dma_data)->channel;
pr_debug("Entered %s\n", __func__); diff --git a/sound/soc/s3c24xx/s3c24xx-pcm.c b/sound/soc/s3c24xx/s3c24xx-pcm.c index 27cf097..a0be71f 100644 --- a/sound/soc/s3c24xx/s3c24xx-pcm.c +++ b/sound/soc/s3c24xx/s3c24xx-pcm.c @@ -32,7 +32,7 @@
#include "s3c24xx-pcm.h"
-static const struct snd_pcm_hardware s3c24xx_pcm_hardware = { +static const struct snd_pcm_hardware s3c_dma_hardware = { .info = SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP | @@ -62,15 +62,15 @@ struct s3c24xx_runtime_data { dma_addr_t dma_start; dma_addr_t dma_pos; dma_addr_t dma_end; - struct s3c24xx_pcm_dma_params *params; + struct s3c_audio_dma_params *params; };
-/* s3c24xx_pcm_enqueue +/* s3c_dma_enqueue * * place a dma buffer onto the queue for the dma system * to handle. */ -static void s3c24xx_pcm_enqueue(struct snd_pcm_substream *substream) +static void s3c_dma_enqueue(struct snd_pcm_substream *substream) { struct s3c24xx_runtime_data *prtd = substream->runtime->private_data; dma_addr_t pos = prtd->dma_pos; @@ -124,19 +124,19 @@ static void s3c24xx_audio_buffdone(struct s3c2410_dma_chan *channel, spin_lock(&prtd->lock); if (prtd->state & ST_RUNNING) { prtd->dma_loaded--; - s3c24xx_pcm_enqueue(substream); + s3c_dma_enqueue(substream); }
spin_unlock(&prtd->lock); }
-static int s3c24xx_pcm_hw_params(struct snd_pcm_substream *substream, +static int s3c_dma_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *params) { struct snd_pcm_runtime *runtime = substream->runtime; struct s3c24xx_runtime_data *prtd = runtime->private_data; struct snd_soc_pcm_runtime *rtd = substream->private_data; - struct s3c24xx_pcm_dma_params *dma = rtd->dai->cpu_dai->dma_data; + struct s3c_audio_dma_params *dma = rtd->dai->cpu_dai->dma_data; unsigned long totbytes = params_buffer_bytes(params); int ret = 0;
@@ -184,7 +184,7 @@ static int s3c24xx_pcm_hw_params(struct snd_pcm_substream *substream, return 0; }
-static int s3c24xx_pcm_hw_free(struct snd_pcm_substream *substream) +static int s3c_dma_hw_free(struct snd_pcm_substream *substream) { struct s3c24xx_runtime_data *prtd = substream->runtime->private_data;
@@ -201,7 +201,7 @@ static int s3c24xx_pcm_hw_free(struct snd_pcm_substream *substream) return 0; }
-static int s3c24xx_pcm_prepare(struct snd_pcm_substream *substream) +static int s3c_dma_prepare(struct snd_pcm_substream *substream) { struct s3c24xx_runtime_data *prtd = substream->runtime->private_data; int ret = 0; @@ -234,12 +234,12 @@ static int s3c24xx_pcm_prepare(struct snd_pcm_substream *substream) prtd->dma_pos = prtd->dma_start;
/* enqueue dma buffers */ - s3c24xx_pcm_enqueue(substream); + s3c_dma_enqueue(substream);
return ret; }
-static int s3c24xx_pcm_trigger(struct snd_pcm_substream *substream, int cmd) +static int s3c_dma_trigger(struct snd_pcm_substream *substream, int cmd) { struct s3c24xx_runtime_data *prtd = substream->runtime->private_data; int ret = 0; @@ -274,7 +274,7 @@ static int s3c24xx_pcm_trigger(struct snd_pcm_substream *substream, int cmd) }
static snd_pcm_uframes_t -s3c24xx_pcm_pointer(struct snd_pcm_substream *substream) +s3c_dma_pointer(struct snd_pcm_substream *substream) { struct snd_pcm_runtime *runtime = substream->runtime; struct s3c24xx_runtime_data *prtd = runtime->private_data; @@ -309,7 +309,7 @@ s3c24xx_pcm_pointer(struct snd_pcm_substream *substream) return bytes_to_frames(substream->runtime, res); }
-static int s3c24xx_pcm_open(struct snd_pcm_substream *substream) +static int s3c_dma_open(struct snd_pcm_substream *substream) { struct snd_pcm_runtime *runtime = substream->runtime; struct s3c24xx_runtime_data *prtd; @@ -317,7 +317,7 @@ static int s3c24xx_pcm_open(struct snd_pcm_substream *substream) pr_debug("Entered %s\n", __func__);
snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS); - snd_soc_set_runtime_hwparams(substream, &s3c24xx_pcm_hardware); + snd_soc_set_runtime_hwparams(substream, &s3c_dma_hardware);
prtd = kzalloc(sizeof(struct s3c24xx_runtime_data), GFP_KERNEL); if (prtd == NULL) @@ -329,7 +329,7 @@ static int s3c24xx_pcm_open(struct snd_pcm_substream *substream) return 0; }
-static int s3c24xx_pcm_close(struct snd_pcm_substream *substream) +static int s3c_dma_close(struct snd_pcm_substream *substream) { struct snd_pcm_runtime *runtime = substream->runtime; struct s3c24xx_runtime_data *prtd = runtime->private_data; @@ -337,14 +337,14 @@ static int s3c24xx_pcm_close(struct snd_pcm_substream *substream) pr_debug("Entered %s\n", __func__);
if (!prtd) - pr_debug("s3c24xx_pcm_close called with prtd == NULL\n"); + pr_debug("s3c_dma_close called with prtd == NULL\n");
kfree(prtd);
return 0; }
-static int s3c24xx_pcm_mmap(struct snd_pcm_substream *substream, +static int s3c_dma_mmap(struct snd_pcm_substream *substream, struct vm_area_struct *vma) { struct snd_pcm_runtime *runtime = substream->runtime; @@ -357,23 +357,23 @@ static int s3c24xx_pcm_mmap(struct snd_pcm_substream *substream, runtime->dma_bytes); }
-static struct snd_pcm_ops s3c24xx_pcm_ops = { - .open = s3c24xx_pcm_open, - .close = s3c24xx_pcm_close, +static struct snd_pcm_ops s3c_dma_ops = { + .open = s3c_dma_open, + .close = s3c_dma_close, .ioctl = snd_pcm_lib_ioctl, - .hw_params = s3c24xx_pcm_hw_params, - .hw_free = s3c24xx_pcm_hw_free, - .prepare = s3c24xx_pcm_prepare, - .trigger = s3c24xx_pcm_trigger, - .pointer = s3c24xx_pcm_pointer, - .mmap = s3c24xx_pcm_mmap, + .hw_params = s3c_dma_hw_params, + .hw_free = s3c_dma_hw_free, + .prepare = s3c_dma_prepare, + .trigger = s3c_dma_trigger, + .pointer = s3c_dma_pointer, + .mmap = s3c_dma_mmap, };
-static int s3c24xx_pcm_preallocate_dma_buffer(struct snd_pcm *pcm, int stream) +static int s3c_preallocate_dma_buffer(struct snd_pcm *pcm, int stream) { struct snd_pcm_substream *substream = pcm->streams[stream].substream; struct snd_dma_buffer *buf = &substream->dma_buffer; - size_t size = s3c24xx_pcm_hardware.buffer_bytes_max; + size_t size = s3c_dma_hardware.buffer_bytes_max;
pr_debug("Entered %s\n", __func__);
@@ -388,7 +388,7 @@ static int s3c24xx_pcm_preallocate_dma_buffer(struct snd_pcm *pcm, int stream) return 0; }
-static void s3c24xx_pcm_free_dma_buffers(struct snd_pcm *pcm) +static void s3c_dma_free_dma_buffers(struct snd_pcm *pcm) { struct snd_pcm_substream *substream; struct snd_dma_buffer *buf; @@ -411,9 +411,9 @@ static void s3c24xx_pcm_free_dma_buffers(struct snd_pcm *pcm) } }
-static u64 s3c24xx_pcm_dmamask = DMA_BIT_MASK(32); +static u64 s3c_dmamask = DMA_BIT_MASK(32);
-static int s3c24xx_pcm_new(struct snd_card *card, +static int s3c_dma_new(struct snd_card *card, struct snd_soc_dai *dai, struct snd_pcm *pcm) { int ret = 0; @@ -421,19 +421,19 @@ static int s3c24xx_pcm_new(struct snd_card *card, pr_debug("Entered %s\n", __func__);
if (!card->dev->dma_mask) - card->dev->dma_mask = &s3c24xx_pcm_dmamask; + card->dev->dma_mask = &s3c_dmamask; if (!card->dev->coherent_dma_mask) card->dev->coherent_dma_mask = 0xffffffff;
if (dai->playback.channels_min) { - ret = s3c24xx_pcm_preallocate_dma_buffer(pcm, + ret = s3c_preallocate_dma_buffer(pcm, SNDRV_PCM_STREAM_PLAYBACK); if (ret) goto out; }
if (dai->capture.channels_min) { - ret = s3c24xx_pcm_preallocate_dma_buffer(pcm, + ret = s3c_preallocate_dma_buffer(pcm, SNDRV_PCM_STREAM_CAPTURE); if (ret) goto out; @@ -444,9 +444,9 @@ static int s3c24xx_pcm_new(struct snd_card *card,
struct snd_soc_platform s3c24xx_soc_platform = { .name = "s3c24xx-audio", - .pcm_ops = &s3c24xx_pcm_ops, - .pcm_new = s3c24xx_pcm_new, - .pcm_free = s3c24xx_pcm_free_dma_buffers, + .pcm_ops = &s3c_dma_ops, + .pcm_new = s3c_dma_new, + .pcm_free = s3c_dma_free_dma_buffers, }; EXPORT_SYMBOL_GPL(s3c24xx_soc_platform);
@@ -463,5 +463,5 @@ static void __exit s3c24xx_soc_platform_exit(void) module_exit(s3c24xx_soc_platform_exit);
MODULE_AUTHOR("Ben Dooks, ben@simtec.co.uk"); -MODULE_DESCRIPTION("Samsung S3C24XX PCM DMA module"); +MODULE_DESCRIPTION("Samsung S3C Audio DMA module"); MODULE_LICENSE("GPL"); diff --git a/sound/soc/s3c24xx/s3c24xx-pcm.h b/sound/soc/s3c24xx/s3c24xx-pcm.h index 0088c79..d04ddf8 100644 --- a/sound/soc/s3c24xx/s3c24xx-pcm.h +++ b/sound/soc/s3c24xx/s3c24xx-pcm.h @@ -9,13 +9,13 @@ * ALSA PCM interface for the Samsung S3C24xx CPU */
-#ifndef _S3C24XX_PCM_H -#define _S3C24XX_PCM_H +#ifndef _S3C_AUDIO_H +#define _S3C_AUDIO_H
#define ST_RUNNING (1<<0) #define ST_OPENED (1<<1)
-struct s3c24xx_pcm_dma_params { +struct s3c_audio_dma_params { struct s3c2410_dma_client *client; /* stream identifier */ int channel; /* Channel ID */ dma_addr_t dma_addr; diff --git a/sound/soc/s3c24xx/s3c64xx-i2s.c b/sound/soc/s3c24xx/s3c64xx-i2s.c index b67eed5..03f5a6b 100644 --- a/sound/soc/s3c24xx/s3c64xx-i2s.c +++ b/sound/soc/s3c24xx/s3c64xx-i2s.c @@ -46,7 +46,7 @@ static struct s3c2410_dma_client s3c64xx_dma_client_in = { .name = "I2S PCM Stereo in" };
-static struct s3c24xx_pcm_dma_params s3c64xx_i2s_pcm_stereo_out[2] = { +static struct s3c_audio_dma_params s3c64xx_i2s_pcm_stereo_out[2] = { [0] = { .channel = DMACH_I2S0_OUT, .client = &s3c64xx_dma_client_out, @@ -61,7 +61,7 @@ static struct s3c24xx_pcm_dma_params s3c64xx_i2s_pcm_stereo_out[2] = { }, };
-static struct s3c24xx_pcm_dma_params s3c64xx_i2s_pcm_stereo_in[2] = { +static struct s3c_audio_dma_params s3c64xx_i2s_pcm_stereo_in[2] = { [0] = { .channel = DMACH_I2S0_IN, .client = &s3c64xx_dma_client_in,
On 11/5/2009 10:34 AM, Jassi Brar wrote:
The s3c24xx_pcm prefix for the soc_platform is inappropriate when some Samsung SoCs have PCM controllers which will eventually have drivers and hence namespace ambiguities.
To resolve naming ambiguities in future the following have been renamed in order
- s3c24xx_pcm_dma_params -> s3c_audio_dma_params
- s3c24xx_pcm_preallocate_dma_buffer -> s3c_preallocate_dma_buffer
- s3c24xx_pcm_dmamask -> s3c_dmamask
- s3c24xx_pcm_XXX -> s3c_dma_XXX
I think that it should have a consistent prefix: s3c_audio_dma_ or other prefix.
BTW, should we keep up s3c prefix? If we will change the prefix now, it is a chance alterable from s3c prefix to other prefix because there is a variety of samsung SoCs unused s3c prefix.
On Thu, Nov 5, 2009 at 12:14 PM, Joonyoung Shim jy0922.shim@samsung.com wrote:
On 11/5/2009 10:34 AM, Jassi Brar wrote:
The s3c24xx_pcm prefix for the soc_platform is inappropriate when some Samsung SoCs have PCM controllers which will eventually have drivers and hence namespace ambiguities.
To resolve naming ambiguities in future the following have been renamed in order
- s3c24xx_pcm_dma_params -> s3c_audio_dma_params
- s3c24xx_pcm_preallocate_dma_buffer -> s3c_preallocate_dma_buffer
- s3c24xx_pcm_dmamask -> s3c_dmamask
- s3c24xx_pcm_XXX -> s3c_dma_XXX
I think that it should have a consistent prefix: s3c_audio_dma_ or other prefix.
Ideally, Yes. 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.
BTW, should we keep up s3c prefix? If we will change the prefix now, it is a chance alterable from s3c prefix to other prefix because there is a variety of samsung SoCs unused s3c prefix.
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. About changing the s3c prefix is a valid discussion, though.
On 11/5/2009 1:16 PM, jassi brar wrote:
On Thu, Nov 5, 2009 at 12:14 PM, Joonyoung Shim jy0922.shim@samsung.com wrote:
On 11/5/2009 10:34 AM, Jassi Brar wrote:
The s3c24xx_pcm prefix for the soc_platform is inappropriate when some Samsung SoCs have PCM controllers which will eventually have drivers and hence namespace ambiguities.
To resolve naming ambiguities in future the following have been renamed in order
- s3c24xx_pcm_dma_params -> s3c_audio_dma_params
- s3c24xx_pcm_preallocate_dma_buffer -> s3c_preallocate_dma_buffer
- s3c24xx_pcm_dmamask -> s3c_dmamask
- s3c24xx_pcm_XXX -> s3c_dma_XXX
I think that it should have a consistent prefix: s3c_audio_dma_ or other prefix.
Ideally, Yes. but if we try so, we have the following
- s3c24xx_pcm_dma_params -> s3c_dma_dma_params
- s3c24xx_pcm_preallocate_dma_buffer -> s3c_dma_preallocate_dma_buffer
- 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.
BTW, should we keep up s3c prefix? If we will change the prefix now, it is a chance alterable from s3c prefix to other prefix because there is a variety of samsung SoCs unused s3c prefix.
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.
About changing the s3c prefix is a valid discussion, though.
On Thu, Nov 05, 2009 at 02:03:08PM +0900, Joonyoung Shim wrote:
On 11/5/2009 1:16 PM, jassi brar wrote:
but if we try so, we have the following
- s3c24xx_pcm_dma_params -> s3c_dma_dma_params
- s3c24xx_pcm_preallocate_dma_buffer -> s3c_dma_preallocate_dma_buffer
- 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.
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.
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@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
- s3c24xx_pcm_dma_params -> s3c_dma_dma_params
- s3c24xx_pcm_preallocate_dma_buffer -> s3c_dma_preallocate_dma_buffer
- 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
Please clarify your net suggestion.
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@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
- s3c24xx_pcm_dma_params -> s3c_dma_dma_params
- s3c24xx_pcm_preallocate_dma_buffer -> s3c_dma_preallocate_dma_buffer
- 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
- s3c24xx_pcm_dma_params -> samsung_dma_params
- s3c24xx_pcm_preallocate_dma_buffer -> samsung_preallocate_dma_buffer
- s3c24xx_pcm_dmamask -> samsung_dmamask
- 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....
On Mon, Nov 9, 2009 at 2:14 PM, Joonyoung Shim jy0922.shim@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@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
- s3c24xx_pcm_dma_params -> samsung_dma_params
- s3c24xx_pcm_preallocate_dma_buffer -> samsung_preallocate_dma_buffer
- s3c24xx_pcm_dmamask -> samsung_dmamask
- 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....
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.
On 11/9/2009 2:31 PM, jassi brar wrote:
On Mon, Nov 9, 2009 at 2:14 PM, Joonyoung Shim jy0922.shim@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@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
- s3c24xx_pcm_dma_params -> samsung_dma_params
- s3c24xx_pcm_preallocate_dma_buffer -> samsung_preallocate_dma_buffer
- s3c24xx_pcm_dmamask -> samsung_dmamask
- 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....
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?
On Mon, Nov 09, 2009 at 03:19:40PM +0900, Joonyoung Shim wrote:
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.
I suspect it's the latter; using the DMA API would mean updating all the existing DMA drivers.
For audio use we'd probably also want to extend the DMA API to support circular operation which I don't think it did last time I looked at it, but that was when it was very shiny and new. Ideally we'd be able to have an ASoC DMA engine API client which would work over multiple platforms which would be very nice.
participants (4)
-
Jassi Brar -
jassi brar -
Joonyoung Shim -
Mark Brown