[alsa-devel] [PATCH] ASoC: multi-component: SAMSUNG: Modify the name of I2S driver
This patch modify the name of I2S driver(S3C64XX/S3C24xx /S3C2412) from "*-iis-*" to "*-i2s-*". The mismatch of I2S name exist in the following sound driver. These files write the "cpu_dai_name" of I2S as "*-i2s-*".
- sound/soc/s3c24xx/aquila_wm8994.c : "s3c64xx-i2s-v4-dai" - sound/soc/s3c24xx/goni_wm8994.c : "s3c64xx-i2s-v4-dai" - sound/soc/s3c24xx/smdk64xx_wm8580.c "s3c64xx-i2s-v4-dai" - sound/soc/s3c24xx/jive_wm8750.c : "s3c2412-i2s-dai" - sound/soc/s3c24xx/neo1973_wm8753.c : "s3c24xx-i2s-dai" - sound/soc/s3c24xx/neo1973_gta02_wm8753.c : "s3c24xx-i2s-dai" - sound/soc/s3c24xx/s3c24xx_simtec_hermes.c : "s3c24xx-i2s-dai" - sound/soc/s3c24xx/s3c24xx_simtec_tlv320aic23.c : "s3c24xx-i2s-dai" - sound/soc/s3c24xx/s3c24xx_uda134x.c : "s3c24xx-i2s-dai" - sound/soc/s3c24xx/smartq_wm8987.c : "s3c64xx-i2s-dai.0"
or, It is should modify "cpu_dai_name" of sound drvier files instead of modifying the name of I2S driver.
Signed-off-by: Chanwoo Choi cw00.choi@samsung.com Signed-off-by: Kyungmin Park kyungmin.park@samsung.com --- sound/soc/s3c24xx/s3c2412-i2s.c | 2 +- sound/soc/s3c24xx/s3c24xx-i2s.c | 2 +- sound/soc/s3c24xx/s3c64xx-i2s-v4.c | 2 +- sound/soc/s3c24xx/s3c64xx-i2s.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/sound/soc/s3c24xx/s3c2412-i2s.c b/sound/soc/s3c24xx/s3c2412-i2s.c index aa116f6..f7c23ae 100644 --- a/sound/soc/s3c24xx/s3c2412-i2s.c +++ b/sound/soc/s3c24xx/s3c2412-i2s.c @@ -188,7 +188,7 @@ static struct platform_driver s3c2412_iis_driver = { .probe = s3c2412_iis_dev_probe, .remove = s3c2412_iis_dev_remove, .driver = { - .name = "s3c2412-iis-dai", + .name = "s3c2412-i2s-dai", .owner = THIS_MODULE, }, }; diff --git a/sound/soc/s3c24xx/s3c24xx-i2s.c b/sound/soc/s3c24xx/s3c24xx-i2s.c index a6cbeef..20712ad 100644 --- a/sound/soc/s3c24xx/s3c24xx-i2s.c +++ b/sound/soc/s3c24xx/s3c24xx-i2s.c @@ -495,7 +495,7 @@ static struct platform_driver s3c24xx_iis_driver = { .probe = s3c24xx_iis_dev_probe, .remove = s3c24xx_iis_dev_remove, .driver = { - .name = "s3c24xx-iis-dai", + .name = "s3c24xx-i2s-dai", .owner = THIS_MODULE, }, }; diff --git a/sound/soc/s3c24xx/s3c64xx-i2s-v4.c b/sound/soc/s3c24xx/s3c64xx-i2s-v4.c index 885040b..2846ea2 100644 --- a/sound/soc/s3c24xx/s3c64xx-i2s-v4.c +++ b/sound/soc/s3c24xx/s3c64xx-i2s-v4.c @@ -195,7 +195,7 @@ static struct platform_driver s3c64xx_i2sv4_driver = { .probe = s3c64xx_i2sv4_dev_probe, .remove = s3c64xx_i2sv4_dev_remove, .driver = { - .name = "s3c64xx-iis-v4-dai", + .name = "s3c64xx-i2s-v4-dai", .owner = THIS_MODULE, }, }; diff --git a/sound/soc/s3c24xx/s3c64xx-i2s.c b/sound/soc/s3c24xx/s3c64xx-i2s.c index 161189b..2017639 100644 --- a/sound/soc/s3c24xx/s3c64xx-i2s.c +++ b/sound/soc/s3c24xx/s3c64xx-i2s.c @@ -218,7 +218,7 @@ static struct platform_driver s3c64xx_iis_driver = { .probe = s3c64xx_iis_dev_probe, .remove = s3c64xx_iis_dev_remove, .driver = { - .name = "s3c64xx-iis-dai", + .name = "s3c64xx-i2s-dai", .owner = THIS_MODULE, }, };
On 25 Jul 2010, at 19:07, Chanwoo Choi cw00.choi@samsung.com wrote:
This patch modify the name of I2S driver(S3C64XX/S3C24xx /S3C2412) from "*-iis-*" to "*-i2s-*". The mismatch of I2S name exist in the following sound driver. These files write the "cpu_dai_name" of I2S as "*-i2s-*".
- sound/soc/s3c24xx/aquila_wm8994.c : "s3c64xx-i2s-v4-dai"
- sound/soc/s3c24xx/goni_wm8994.c : "s3c64xx-i2s-v4-dai"
- sound/soc/s3c24xx/smdk64xx_wm8580.c "s3c64xx-i2s-v4-dai"
- sound/soc/s3c24xx/jive_wm8750.c : "s3c2412-i2s-dai"
- sound/soc/s3c24xx/neo1973_wm8753.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/neo1973_gta02_wm8753.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/s3c24xx_simtec_hermes.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/s3c24xx_simtec_tlv320aic23.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/s3c24xx_uda134x.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/smartq_wm8987.c : "s3c64xx-i2s-dai.0"
or, It is should modify "cpu_dai_name" of sound drvier files instead of modifying the name of I2S driver.
Acked-by: Mark Brown broonie@opensource.wolfsonmicro.com
but Jassi really should also comment here.
Signed-off-by: Chanwoo Choi cw00.choi@samsung.com Signed-off-by: Kyungmin Park kyungmin.park@samsung.com
sound/soc/s3c24xx/s3c2412-i2s.c | 2 +- sound/soc/s3c24xx/s3c24xx-i2s.c | 2 +- sound/soc/s3c24xx/s3c64xx-i2s-v4.c | 2 +- sound/soc/s3c24xx/s3c64xx-i2s.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/sound/soc/s3c24xx/s3c2412-i2s.c b/sound/soc/s3c24xx/s3c2412-i2s.c index aa116f6..f7c23ae 100644 --- a/sound/soc/s3c24xx/s3c2412-i2s.c +++ b/sound/soc/s3c24xx/s3c2412-i2s.c @@ -188,7 +188,7 @@ static struct platform_driver s3c2412_iis_driver = { .probe = s3c2412_iis_dev_probe, .remove = s3c2412_iis_dev_remove, .driver = {
.name = "s3c2412-iis-dai",
.name = "s3c2412-i2s-dai",}; diff --git a/sound/soc/s3c24xx/s3c24xx-i2s.c b/sound/soc/s3c24xx/s3c24xx-i2s.c index a6cbeef..20712ad 100644 --- a/sound/soc/s3c24xx/s3c24xx-i2s.c +++ b/sound/soc/s3c24xx/s3c24xx-i2s.c @@ -495,7 +495,7 @@ static struct platform_driver s3c24xx_iis_driver = { .probe = s3c24xx_iis_dev_probe, .remove = s3c24xx_iis_dev_remove, .driver = {
.name = "s3c24xx-iis-dai",
.name = "s3c24xx-i2s-dai",}; diff --git a/sound/soc/s3c24xx/s3c64xx-i2s-v4.c b/sound/soc/s3c24xx/s3c64xx-i2s-v4.c index 885040b..2846ea2 100644 --- a/sound/soc/s3c24xx/s3c64xx-i2s-v4.c +++ b/sound/soc/s3c24xx/s3c64xx-i2s-v4.c @@ -195,7 +195,7 @@ static struct platform_driver s3c64xx_i2sv4_driver = { .probe = s3c64xx_i2sv4_dev_probe, .remove = s3c64xx_i2sv4_dev_remove, .driver = {
.name = "s3c64xx-iis-v4-dai",
.name = "s3c64xx-i2s-v4-dai",}; diff --git a/sound/soc/s3c24xx/s3c64xx-i2s.c b/sound/soc/s3c24xx/s3c64xx-i2s.c index 161189b..2017639 100644 --- a/sound/soc/s3c24xx/s3c64xx-i2s.c +++ b/sound/soc/s3c24xx/s3c64xx-i2s.c @@ -218,7 +218,7 @@ static struct platform_driver s3c64xx_iis_driver = { .probe = s3c64xx_iis_dev_probe, .remove = s3c64xx_iis_dev_remove, .driver = {
.name = "s3c64xx-iis-dai",
.name = "s3c64xx-i2s-dai",};
1.6.3.3
On Mon, Jul 26, 2010 at 3:57 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On 25 Jul 2010, at 19:07, Chanwoo Choi cw00.choi@samsung.com wrote:
This patch modify the name of I2S driver(S3C64XX/S3C24xx /S3C2412) from "*-iis-*" to "*-i2s-*". The mismatch of I2S name exist in the following sound driver. These files write the "cpu_dai_name" of I2S as "*-i2s-*".
- sound/soc/s3c24xx/aquila_wm8994.c : "s3c64xx-i2s-v4-dai"
- sound/soc/s3c24xx/goni_wm8994.c : "s3c64xx-i2s-v4-dai"
- sound/soc/s3c24xx/smdk64xx_wm8580.c "s3c64xx-i2s-v4-dai"
- sound/soc/s3c24xx/jive_wm8750.c : "s3c2412-i2s-dai"
- sound/soc/s3c24xx/neo1973_wm8753.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/neo1973_gta02_wm8753.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/s3c24xx_simtec_hermes.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/s3c24xx_simtec_tlv320aic23.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/s3c24xx_uda134x.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/smartq_wm8987.c : "s3c64xx-i2s-dai.0"
or, It is should modify "cpu_dai_name" of sound drvier files instead of modifying the name of I2S driver.
Acked-by: Mark Brown broonie@opensource.wolfsonmicro.com
but Jassi really should also comment here.
I already talked to Ben about renaming drivers but he doesn't like the idea of breaking loadable drivers in distributions and I buy his opinion. So, Ben really has the say on the matter.
Thanks.
On Mon, Jul 26, 2010 at 4:22 PM, Jassi Brar jassisinghbrar@gmail.com wrote:
On Mon, Jul 26, 2010 at 3:57 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On 25 Jul 2010, at 19:07, Chanwoo Choi cw00.choi@samsung.com wrote:
This patch modify the name of I2S driver(S3C64XX/S3C24xx /S3C2412) from "*-iis-*" to "*-i2s-*". The mismatch of I2S name exist in the following sound driver. These files write the "cpu_dai_name" of I2S as "*-i2s-*".
- sound/soc/s3c24xx/aquila_wm8994.c : "s3c64xx-i2s-v4-dai"
- sound/soc/s3c24xx/goni_wm8994.c : "s3c64xx-i2s-v4-dai"
- sound/soc/s3c24xx/smdk64xx_wm8580.c "s3c64xx-i2s-v4-dai"
- sound/soc/s3c24xx/jive_wm8750.c : "s3c2412-i2s-dai"
- sound/soc/s3c24xx/neo1973_wm8753.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/neo1973_gta02_wm8753.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/s3c24xx_simtec_hermes.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/s3c24xx_simtec_tlv320aic23.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/s3c24xx_uda134x.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/smartq_wm8987.c : "s3c64xx-i2s-dai.0"
or, It is should modify "cpu_dai_name" of sound drvier files instead of modifying the name of I2S driver.
Acked-by: Mark Brown broonie@opensource.wolfsonmicro.com
but Jassi really should also comment here.
I already talked to Ben about renaming drivers but he doesn't like the idea of breaking loadable drivers in distributions and I buy his opinion. So, Ben really has the say on the matter.
Plus how to change the directory name to "samsung'?
Thank you, Kyungmin Park
On Mon, 2010-07-26 at 16:37 +0900, Kyungmin Park wrote:
On Mon, Jul 26, 2010 at 4:22 PM, Jassi Brar jassisinghbrar@gmail.com wrote:
On Mon, Jul 26, 2010 at 3:57 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On 25 Jul 2010, at 19:07, Chanwoo Choi cw00.choi@samsung.com wrote:
This patch modify the name of I2S driver(S3C64XX/S3C24xx /S3C2412) from "*-iis-*" to "*-i2s-*". The mismatch of I2S name exist in the following sound driver. These files write the "cpu_dai_name" of I2S as "*-i2s-*".
- sound/soc/s3c24xx/aquila_wm8994.c : "s3c64xx-i2s-v4-dai"
- sound/soc/s3c24xx/goni_wm8994.c : "s3c64xx-i2s-v4-dai"
- sound/soc/s3c24xx/smdk64xx_wm8580.c "s3c64xx-i2s-v4-dai"
- sound/soc/s3c24xx/jive_wm8750.c : "s3c2412-i2s-dai"
- sound/soc/s3c24xx/neo1973_wm8753.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/neo1973_gta02_wm8753.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/s3c24xx_simtec_hermes.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/s3c24xx_simtec_tlv320aic23.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/s3c24xx_uda134x.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/smartq_wm8987.c : "s3c64xx-i2s-dai.0"
or, It is should modify "cpu_dai_name" of sound drvier files instead of modifying the name of I2S driver.
Acked-by: Mark Brown broonie@opensource.wolfsonmicro.com
but Jassi really should also comment here.
I already talked to Ben about renaming drivers but he doesn't like the idea of breaking loadable drivers in distributions and I buy his opinion. So, Ben really has the say on the matter.
I'll explain the reasoning behind the "-dai" suffix.
The "-dai" suffix name change is all about preventing naming collisions. I'm not sure if this may affect the Samsung platforms atm, but it does affect other platforms like OMAP, PXA, DaVinci, I.MX, FSL and Blackfin atm. (Now that _all_ ASoC components are devices)
The problem is that digital audio interfaces are typically now being implemented in silicon as part of platform general purpose serial buses. So on OMAP, we can use the McBSP interface for audio and any other general purpose serial type data. So this leads to the problem where you want to use McBSP2 for audio and McBSP1 for some non audio serial device and have to name the McBSP client bus drivers for probing().
Btw shouldn't correct MODULE_ALIAS() information allow the distributions to load the renamed module drivers ?
Plus how to change the directory name to "samsung'?
I guess the s3c24xx directory name is actually quite misleading now. Although this should probably be looked at after the multi-component merge.
Thanks
Liam
On Mon, Jul 26, 2010 at 7:44 PM, Liam Girdwood lrg@slimlogic.co.uk wrote:
On Mon, 2010-07-26 at 16:37 +0900, Kyungmin Park wrote:
On Mon, Jul 26, 2010 at 4:22 PM, Jassi Brar jassisinghbrar@gmail.com wrote:
On Mon, Jul 26, 2010 at 3:57 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On 25 Jul 2010, at 19:07, Chanwoo Choi cw00.choi@samsung.com wrote:
This patch modify the name of I2S driver(S3C64XX/S3C24xx /S3C2412) from "*-iis-*" to "*-i2s-*". The mismatch of I2S name exist in the following sound driver. These files write the "cpu_dai_name" of I2S as "*-i2s-*".
- sound/soc/s3c24xx/aquila_wm8994.c : "s3c64xx-i2s-v4-dai"
- sound/soc/s3c24xx/goni_wm8994.c : "s3c64xx-i2s-v4-dai"
- sound/soc/s3c24xx/smdk64xx_wm8580.c "s3c64xx-i2s-v4-dai"
- sound/soc/s3c24xx/jive_wm8750.c : "s3c2412-i2s-dai"
- sound/soc/s3c24xx/neo1973_wm8753.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/neo1973_gta02_wm8753.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/s3c24xx_simtec_hermes.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/s3c24xx_simtec_tlv320aic23.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/s3c24xx_uda134x.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/smartq_wm8987.c : "s3c64xx-i2s-dai.0"
or, It is should modify "cpu_dai_name" of sound drvier files instead of modifying the name of I2S driver.
Acked-by: Mark Brown broonie@opensource.wolfsonmicro.com
but Jassi really should also comment here.
I already talked to Ben about renaming drivers but he doesn't like the idea of breaking loadable drivers in distributions and I buy his opinion. So, Ben really has the say on the matter.
I'll explain the reasoning behind the "-dai" suffix.
The "-dai" suffix name change is all about preventing naming collisions. I'm not sure if this may affect the Samsung platforms atm, but it does affect other platforms like OMAP, PXA, DaVinci, I.MX, FSL and Blackfin atm. (Now that _all_ ASoC components are devices)
The problem is that digital audio interfaces are typically now being implemented in silicon as part of platform general purpose serial buses. So on OMAP, we can use the McBSP interface for audio and any other general purpose serial type data. So this leads to the problem where you want to use McBSP2 for audio and McBSP1 for some non audio serial device and have to name the McBSP client bus drivers for probing().
Btw shouldn't correct MODULE_ALIAS() information allow the distributions to load the renamed module drivers ?
Plus how to change the directory name to "samsung'?
I guess the s3c24xx directory name is actually quite misleading now. Although this should probably be looked at after the multi-component merge.
Thanks
Liam
Since the changes due to multi-component support has already overridden the 'prohibitions' Ben had put in place and Ben doesn't seem to be bothered by these changes(no reply)... I guess we can move ahead with further cosmetic and name changing that people so long for ?
On Tue, Sep 07, 2010 at 04:32:17PM +0900, Jassi Brar wrote:
Since the changes due to multi-component support has already overridden the 'prohibitions' Ben had put in place and Ben doesn't seem to be bothered by these changes(no reply)... I guess we can move ahead with further cosmetic and name changing that people so long for ?
I guess now's a good time to look at it, yes.
On Wed, Sep 8, 2010 at 12:39 AM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Tue, Sep 07, 2010 at 04:32:17PM +0900, Jassi Brar wrote:
Since the changes due to multi-component support has already overridden the 'prohibitions' Ben had put in place and Ben doesn't seem to be bothered by these changes(no reply)... I guess we can move ahead with further cosmetic and name changing that people so long for ?
I guess now's a good time to look at it, yes.
Ok, so the work is under progress. I would like to have points to consider from every stakeholder.
On Thu, Sep 09, 2010 at 09:56:23PM +0900, Jassi Brar wrote:
I would like to have points to consider from every stakeholder.
I don't really have anything myself, though I may have some comments on the actual proposal I guess.
On Thu, Sep 9, 2010 at 10:22 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Thu, Sep 09, 2010 at 09:56:23PM +0900, Jassi Brar wrote:
I would like to have points to consider from every stakeholder.
I don't really have anything myself, though I may have some comments on the actual proposal I guess.
Btw, AC97, PCM and DMA were easy kill.
It's I2S that's PITA. I am thinking of leaving 24xx-i2s, i.e pre-64xx(shared with 2412), unchanged and letting them die of old age (obsoleted and dropped duly if no stakeholder keeps up).
I plan to categorize the newer I2S blocks into i2s_v2(s3c2412), i2s_v3(v2 with minor variation in reg field order), i2s_v4 (v3 plus 5.1 channel support) and v5 (v4 plus Secondary Stereo-Channel for h/w mixing support). A new flag 'version' in 'struct s3c_audio_pdata' passed via platform_data can be used to differentiate quirks and features run-time in a single CPU driver.
Ben, Mark and other interested parties:- Any opinions, before I have spent too many hours working on it?
Thanks.
On Fri, Sep 10, 2010 at 05:43:14PM +0900, Jassi Brar wrote:
It's I2S that's PITA. I am thinking of leaving 24xx-i2s, i.e pre-64xx(shared with 2412), unchanged and letting them die of old age (obsoleted and dropped duly if no stakeholder keeps up).
This seems resonable; there is a reasonable degree of interest in them so probably the community support will keep them going.
I plan to categorize the newer I2S blocks into i2s_v2(s3c2412), i2s_v3(v2 with minor variation in reg field order), i2s_v4 (v3 plus 5.1 channel support) and v5 (v4 plus Secondary Stereo-Channel for h/w mixing support). A new flag 'version' in 'struct s3c_audio_pdata' passed via platform_data can be used to differentiate quirks and features run-time in a single CPU driver.
As I've said in the past the concern I have with all this stuff is that outside of Samsung there's no documentation of the IIS block versions or their relationships, the only references I've seen to versions have been for chips with multiple versions (like the 6410) and there it's just a mention that versions exist and the register documentation is completely cut'n'pasted. It would be good if you could make sure that any platform data for identifying the versions is sufficiently clear to allow someone to go from datasheet to knowing which IP version they have.
On Fri, Sep 10, 2010 at 6:39 PM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Fri, Sep 10, 2010 at 05:43:14PM +0900, Jassi Brar wrote:
I plan to categorize the newer I2S blocks into i2s_v2(s3c2412), i2s_v3(v2 with minor variation in reg field order), i2s_v4 (v3 plus 5.1 channel support) and v5 (v4 plus Secondary Stereo-Channel for h/w mixing support). A new flag 'version' in 'struct s3c_audio_pdata' passed via platform_data can be used to differentiate quirks and features run-time in a single CPU driver.
As I've said in the past the concern I have with all this stuff is that outside of Samsung there's no documentation of the IIS block versions or their relationships, the only references I've seen to versions have been for chips with multiple versions (like the 6410) and there it's just a mention that versions exist and the register documentation is completely cut'n'pasted.
All this info could be gotten by comparing the I2S chapters of relevant SoCs... which is what I do. I don't have any special documentation either.... there is none. The only luxury I have is to be able to get clarifications via appropriate channels of info.
It would be good if you could make sure that any platform data for identifying the versions is sufficiently clear to allow someone to go from datasheet to knowing which IP version they have.
Actually I plan to use enum for I2S types and assign them alongside platform_device definition of I2S blocks and their platform_data. Any I2S block that matches register description of 2-channel block of 6410 is v3, that with 5.1 is v4 and that with 5.1 of C100 is v5. There are no differentiating IDs to be read from any register.
On Fri, Sep 10, 2010 at 08:32:46PM +0900, Jassi Brar wrote:
On Fri, Sep 10, 2010 at 6:39 PM, Mark Brown
On Fri, Sep 10, 2010 at 05:43:14PM +0900, Jassi Brar wrote:
As I've said in the past the concern I have with all this stuff is that outside of Samsung there's no documentation of the IIS block versions or their relationships, the only references I've seen to versions have been for chips with multiple versions (like the 6410) and there it's just a mention that versions exist and the register documentation is completely
cut'n'pasted.
All this info could be gotten by comparing the I2S chapters of relevant SoCs... which is what I do. I don't have any special documentation either.... there is none. The only luxury I have is to be able to get clarifications via appropriate channels of info.
You appear to be at least aware of the versions :) Most of us were going on naming based on CPU names.
It would be good if you could make sure that any platform data for identifying the versions is sufficiently clear to allow someone to go from datasheet to knowing which IP version they have.
Actually I plan to use enum for I2S types and assign them alongside platform_device definition of I2S blocks and their platform_data. Any I2S block that matches register description of 2-channel block of 6410 is v3, that with 5.1 is v4 and that with 5.1 of C100 is v5.
Including a listing of the registers you look at when doing the comparison would be useful here - some sort of flow chart to work through, for example. Bear in mind that the datasheets for the CPUs aren't (all?) public either so people might not be able to look at the register maps for older CPUs if they only have the datasheet for the CPU they have been working on.
There are no differentiating IDs to be read from any register.
Yup, I'm aware of this.
В сообщении от 10 сентября 2010 11:43:14 автор Jassi Brar написал:
On Thu, Sep 9, 2010 at 10:22 PM, Mark Brown
broonie@opensource.wolfsonmicro.com wrote:
On Thu, Sep 09, 2010 at 09:56:23PM +0900, Jassi Brar wrote:
I would like to have points to consider from every stakeholder.
I don't really have anything myself, though I may have some comments on the actual proposal I guess.
Btw, AC97, PCM and DMA were easy kill.
It's I2S that's PITA. I am thinking of leaving 24xx-i2s, i.e pre-64xx(shared with 2412), unchanged and letting them die of old age (obsoleted and dropped duly if no stakeholder keeps up).
Does it mean there's no one to support s3c24xx-i2s (for s3c24xx socs)?
On Sat, Sep 11, 2010 at 6:40 AM, Vasily Khoruzhick anarsoul@gmail.com wrote:
В сообщении от 10 сентября 2010 11:43:14 автор Jassi Brar написал:
On Thu, Sep 9, 2010 at 10:22 PM, Mark Brown
broonie@opensource.wolfsonmicro.com wrote:
On Thu, Sep 09, 2010 at 09:56:23PM +0900, Jassi Brar wrote:
I would like to have points to consider from every stakeholder.
I don't really have anything myself, though I may have some comments on the actual proposal I guess.
Btw, AC97, PCM and DMA were easy kill.
It's I2S that's PITA. I am thinking of leaving 24xx-i2s, i.e pre-64xx(shared with 2412), unchanged and letting them die of old age (obsoleted and dropped duly if no stakeholder keeps up).
Does it mean there's no one to support s3c24xx-i2s (for s3c24xx socs)?
As Mark said, there are indeed some people. Just I don't have the h/w handy to work and test any changes.
On 26 Jul 2010, at 00:22, Jassi Brar jassisinghbrar@gmail.com wrote:
I already talked to Ben about renaming drivers but he doesn't like the idea of breaking loadable drivers in distributions and I buy his opinion. So, Ben really has the say on the matter.
I don't think it's a big deal for distros - they will generally only explicitly load the final machine driver for a device rather than the individual component drivers which will get pulled in automatically by the kernel infrastructure anyway (either module dependencies or hotplug depending) and the board drivers keep their names.
Hi,
On Mon, Jul 26, 2010 at 11:07 AM, Chanwoo Choi cw00.choi@samsung.com wrote:
This patch modify the name of I2S driver(S3C64XX/S3C24xx /S3C2412) from "*-iis-*" to "*-i2s-*". The mismatch of I2S name exist in the following sound driver. These files write the "cpu_dai_name" of I2S as "*-i2s-*".
I think that you should CC Mr. Jassi and Mr. Ben Dooks. Because they should know about this 'naming issue' that they can consider this with the 'arch/arm/...', and also they are the original author of these files.
- sound/soc/s3c24xx/aquila_wm8994.c : "s3c64xx-i2s-v4-dai"
- sound/soc/s3c24xx/goni_wm8994.c : "s3c64xx-i2s-v4-dai"
- sound/soc/s3c24xx/smdk64xx_wm8580.c "s3c64xx-i2s-v4-dai"
- sound/soc/s3c24xx/jive_wm8750.c : "s3c2412-i2s-dai"
- sound/soc/s3c24xx/neo1973_wm8753.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/neo1973_gta02_wm8753.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/s3c24xx_simtec_hermes.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/s3c24xx_simtec_tlv320aic23.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/s3c24xx_uda134x.c : "s3c24xx-i2s-dai"
- sound/soc/s3c24xx/smartq_wm8987.c : "s3c64xx-i2s-dai.0"
or, It is should modify "cpu_dai_name" of sound drvier files instead of modifying the name of I2S driver.
Signed-off-by: Chanwoo Choi cw00.choi@samsung.com Signed-off-by: Kyungmin Park kyungmin.park@samsung.com
sound/soc/s3c24xx/s3c2412-i2s.c | 2 +- sound/soc/s3c24xx/s3c24xx-i2s.c | 2 +- sound/soc/s3c24xx/s3c64xx-i2s-v4.c | 2 +- sound/soc/s3c24xx/s3c64xx-i2s.c | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/sound/soc/s3c24xx/s3c2412-i2s.c b/sound/soc/s3c24xx/s3c2412-i2s.c index aa116f6..f7c23ae 100644 --- a/sound/soc/s3c24xx/s3c2412-i2s.c +++ b/sound/soc/s3c24xx/s3c2412-i2s.c @@ -188,7 +188,7 @@ static struct platform_driver s3c2412_iis_driver = { .probe = s3c2412_iis_dev_probe, .remove = s3c2412_iis_dev_remove, .driver = {
- .name = "s3c2412-iis-dai",
- .name = "s3c2412-i2s-dai",
.owner = THIS_MODULE, }, }; diff --git a/sound/soc/s3c24xx/s3c24xx-i2s.c b/sound/soc/s3c24xx/s3c24xx-i2s.c index a6cbeef..20712ad 100644 --- a/sound/soc/s3c24xx/s3c24xx-i2s.c +++ b/sound/soc/s3c24xx/s3c24xx-i2s.c @@ -495,7 +495,7 @@ static struct platform_driver s3c24xx_iis_driver = { .probe = s3c24xx_iis_dev_probe, .remove = s3c24xx_iis_dev_remove, .driver = {
- .name = "s3c24xx-iis-dai",
- .name = "s3c24xx-i2s-dai",
.owner = THIS_MODULE, }, }; diff --git a/sound/soc/s3c24xx/s3c64xx-i2s-v4.c b/sound/soc/s3c24xx/s3c64xx-i2s-v4.c index 885040b..2846ea2 100644 --- a/sound/soc/s3c24xx/s3c64xx-i2s-v4.c +++ b/sound/soc/s3c24xx/s3c64xx-i2s-v4.c @@ -195,7 +195,7 @@ static struct platform_driver s3c64xx_i2sv4_driver = { .probe = s3c64xx_i2sv4_dev_probe, .remove = s3c64xx_i2sv4_dev_remove, .driver = {
- .name = "s3c64xx-iis-v4-dai",
- .name = "s3c64xx-i2s-v4-dai",
.owner = THIS_MODULE, }, }; diff --git a/sound/soc/s3c24xx/s3c64xx-i2s.c b/sound/soc/s3c24xx/s3c64xx-i2s.c index 161189b..2017639 100644 --- a/sound/soc/s3c24xx/s3c64xx-i2s.c +++ b/sound/soc/s3c24xx/s3c64xx-i2s.c @@ -218,7 +218,7 @@ static struct platform_driver s3c64xx_iis_driver = { .probe = s3c64xx_iis_dev_probe, .remove = s3c64xx_iis_dev_remove, .driver = {
- .name = "s3c64xx-iis-dai",
- .name = "s3c64xx-i2s-dai",
.owner = THIS_MODULE, }, }; -- 1.6.3.3
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
participants (7)
-
Chanwoo Choi -
Jassi Brar -
Kyungmin Park -
Liam Girdwood -
Mark Brown -
Seungwhan Youn -
Vasily Khoruzhick