[alsa-devel] [PATCH 1/3] ASoC: bt-sco: enable OF support
From: Rongjun Ying Rongjun.Ying@csr.com
this makes users be able to add a bt-sco node in dts instead of hardcoding a platform device in mach.
Signed-off-by: Rongjun Ying Rongjun.Ying@csr.com Signed-off-by: Barry Song Baohua.Song@csr.com --- sound/soc/codecs/bt-sco.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/sound/soc/codecs/bt-sco.c b/sound/soc/codecs/bt-sco.c index a081d9f..39e7ebe 100644 --- a/sound/soc/codecs/bt-sco.c +++ b/sound/soc/codecs/bt-sco.c @@ -46,6 +46,14 @@ static int bt_sco_remove(struct platform_device *pdev) return 0; }
+#ifdef CONFIG_OF +static const struct of_device_id bt_sco_of_match[] = { + { .compatible = "bt-sco-codec", }, + {} +}; +MODULE_DEVICE_TABLE(of, bt_sco_of_match); +#endif + static struct platform_device_id bt_sco_driver_ids[] = { { .name = "dfbmcs320", @@ -58,6 +66,9 @@ static struct platform_driver bt_sco_driver = { .driver = { .name = "bt-sco", .owner = THIS_MODULE, +#ifdef CONFIG_OF + .of_match_table = bt_sco_of_match, +#endif }, .probe = bt_sco_probe, .remove = bt_sco_remove,
From: Rongjun Ying Rongjun.Ying@csr.com
this makes users be able to add a hdmi-codec node in dts instead of hardcoding a platform device in mach.
Signed-off-by: Rongjun Ying Rongjun.Ying@csr.com Signed-off-by: Barry Song Baohua.Song@csr.com --- sound/soc/codecs/hdmi.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/sound/soc/codecs/hdmi.c b/sound/soc/codecs/hdmi.c index 2bcae2b..78c7b15 100644 --- a/sound/soc/codecs/hdmi.c +++ b/sound/soc/codecs/hdmi.c @@ -51,10 +51,21 @@ static int hdmi_codec_remove(struct platform_device *pdev) return 0; }
+#ifdef CONFIG_OF +static const struct of_device_id hdmi_audio_codec_ids[] = { + { .compatible = "hdmi-audio-codec", }, + {} +}; +MODULE_DEVICE_TABLE(of, hdmi_audio_codec_ids); +#endif + static struct platform_driver hdmi_codec_driver = { .driver = { .name = DRV_NAME, .owner = THIS_MODULE, +#ifdef CONFIG_OF + .of_match_table = hdmi_audio_codec_ids, +#endif },
.probe = hdmi_codec_probe,
On Wed, Jul 17, 2013 at 07:12:15AM +0100, Barry Song wrote:
From: Rongjun Ying Rongjun.Ying@csr.com
this makes users be able to add a hdmi-codec node in dts instead of hardcoding a platform device in mach.
Similarly to my comment on the first patch, I'm not sure this is the best way to wire this up to devicetree. Can this not be hung off of hdmi controller drivers?
Thanks, Mark.
Signed-off-by: Rongjun Ying Rongjun.Ying@csr.com Signed-off-by: Barry Song Baohua.Song@csr.com
sound/soc/codecs/hdmi.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/sound/soc/codecs/hdmi.c b/sound/soc/codecs/hdmi.c index 2bcae2b..78c7b15 100644 --- a/sound/soc/codecs/hdmi.c +++ b/sound/soc/codecs/hdmi.c @@ -51,10 +51,21 @@ static int hdmi_codec_remove(struct platform_device *pdev) return 0; }
+#ifdef CONFIG_OF +static const struct of_device_id hdmi_audio_codec_ids[] = {
- { .compatible = "hdmi-audio-codec", },
- {}
+}; +MODULE_DEVICE_TABLE(of, hdmi_audio_codec_ids); +#endif
static struct platform_driver hdmi_codec_driver = { .driver = { .name = DRV_NAME, .owner = THIS_MODULE, +#ifdef CONFIG_OF
.of_match_table = hdmi_audio_codec_ids,+#endif },
.probe = hdmi_codec_probe,
1.8.2.3
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog
linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, Jul 17, 2013 at 09:49:10AM +0100, Mark Rutland wrote:
On Wed, Jul 17, 2013 at 07:12:15AM +0100, Barry Song wrote:
this makes users be able to add a hdmi-codec node in dts instead of hardcoding a platform device in mach.
Similarly to my comment on the first patch, I'm not sure this is the best way to wire this up to devicetree. Can this not be hung off of hdmi controller drivers?
This one is different to the BT case - as you say it's hanging off the HDMI controller so the HDMI controller ought to enumerate it either as a stub or by actually seeing a device. The platform device is fine but it's not something that should appear in the DT unless it's conveying some information about what's connected there (eg, power supplies for something soldered down on the board).
2013/7/17 Mark Brown broonie@kernel.org:
On Wed, Jul 17, 2013 at 09:49:10AM +0100, Mark Rutland wrote:
On Wed, Jul 17, 2013 at 07:12:15AM +0100, Barry Song wrote:
this makes users be able to add a hdmi-codec node in dts instead of hardcoding a platform device in mach.
Similarly to my comment on the first patch, I'm not sure this is the best way to wire this up to devicetree. Can this not be hung off of hdmi controller drivers?
This one is different to the BT case - as you say it's hanging off the HDMI controller so the HDMI controller ought to enumerate it either as a stub or by actually seeing a device. The platform device is fine but it's not something that should appear in the DT unless it's conveying some information about what's connected there (eg, power supplies for something soldered down on the board).
it should be ok that the platform_device is allocated and added in the HDMI controller codes.
-barry
From: Rongjun Ying Rongjun.Ying@csr.com
Devices like mobilephones, computers are typically used as HDMI sources, but devices like TV, navigators will be HDMI sinks.
for auto scenerios, In-Vehicle Infotainment(IVI) can be HDMI sink to display movies from mobilephones.
Signed-off-by: Rongjun Ying Rongjun.Ying@csr.com Signed-off-by: Barry Song Baohua.Song@csr.com --- sound/soc/codecs/hdmi.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/sound/soc/codecs/hdmi.c b/sound/soc/codecs/hdmi.c index 78c7b15..0fdcaf9 100644 --- a/sound/soc/codecs/hdmi.c +++ b/sound/soc/codecs/hdmi.c @@ -37,6 +37,17 @@ static struct snd_soc_dai_driver hdmi_codec_dai = { .formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE, }, + .capture = { + .channels_min = 2, + .channels_max = 2, + .rates = SNDRV_PCM_RATE_32000 | + SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000 | + SNDRV_PCM_RATE_88200 | SNDRV_PCM_RATE_96000 | + SNDRV_PCM_RATE_176400 | SNDRV_PCM_RATE_192000, + .formats = SNDRV_PCM_FMTBIT_S16_LE | + SNDRV_PCM_FMTBIT_S24_LE, + }, + };
static int hdmi_codec_probe(struct platform_device *pdev)
On Wed, Jul 17, 2013 at 02:12:16PM +0800, Barry Song wrote:
From: Rongjun Ying Rongjun.Ying@csr.com
Devices like mobilephones, computers are typically used as HDMI sources, but devices like TV, navigators will be HDMI sinks.
Applied, thanks.
On Wed, Jul 17, 2013 at 07:12:14AM +0100, Barry Song wrote:
From: Rongjun Ying Rongjun.Ying@csr.com
this makes users be able to add a bt-sco node in dts instead of hardcoding a platform device in mach.
I'm slightly confused by this. The driver doesn't seem to pick up any information out of the dts, and the binding doesn't even describe any linkage to a piece of hardware. I'm not familiar with bluetooth or ASoC, could you give an explanation as to why this is needed?
I don't think this should be in the dt as is. Could this not be registered based on the presence of a bluetooth controller that supports this?
Thanks, Mark.
Signed-off-by: Rongjun Ying Rongjun.Ying@csr.com Signed-off-by: Barry Song Baohua.Song@csr.com
sound/soc/codecs/bt-sco.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/sound/soc/codecs/bt-sco.c b/sound/soc/codecs/bt-sco.c index a081d9f..39e7ebe 100644 --- a/sound/soc/codecs/bt-sco.c +++ b/sound/soc/codecs/bt-sco.c @@ -46,6 +46,14 @@ static int bt_sco_remove(struct platform_device *pdev) return 0; }
+#ifdef CONFIG_OF +static const struct of_device_id bt_sco_of_match[] = {
- { .compatible = "bt-sco-codec", },
- {}
+}; +MODULE_DEVICE_TABLE(of, bt_sco_of_match); +#endif
static struct platform_device_id bt_sco_driver_ids[] = { { .name = "dfbmcs320", @@ -58,6 +66,9 @@ static struct platform_driver bt_sco_driver = { .driver = { .name = "bt-sco", .owner = THIS_MODULE, +#ifdef CONFIG_OF
.of_match_table = bt_sco_of_match,+#endif }, .probe = bt_sco_probe, .remove = bt_sco_remove, -- 1.8.2.3
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog
linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, Jul 17, 2013 at 09:40:39AM +0100, Mark Rutland wrote:
On Wed, Jul 17, 2013 at 07:12:14AM +0100, Barry Song wrote:
this makes users be able to add a bt-sco node in dts instead of hardcoding a platform device in mach.
I'm slightly confused by this. The driver doesn't seem to pick up any information out of the dts, and the binding doesn't even describe any linkage to a piece of hardware. I'm not familiar with bluetooth or ASoC, could you give an explanation as to why this is needed?
I don't think this should be in the dt as is. Could this not be registered based on the presence of a bluetooth controller that supports this?
Audio devices are linked together by a separate board binding which specifies how all the different components in the audio subsystem on the board are wired together. Even where things have no meanignful software control (as is the case here and for a lot of simple DACs or ADCs) the rest of the system needs information on their capabilites and ideally the ability to interchange them with more substantial devices. If there were meaningful control there'd be a control bus here.
There is likely to be a control interface for the BT device hanging off a UART but it's not clear there's much more meaningful data for those than there is here.
2013/7/17 Mark Brown broonie@kernel.org:
On Wed, Jul 17, 2013 at 09:40:39AM +0100, Mark Rutland wrote:
On Wed, Jul 17, 2013 at 07:12:14AM +0100, Barry Song wrote:
this makes users be able to add a bt-sco node in dts instead of hardcoding a platform device in mach.
I'm slightly confused by this. The driver doesn't seem to pick up any information out of the dts, and the binding doesn't even describe any linkage to a piece of hardware. I'm not familiar with bluetooth or ASoC, could you give an explanation as to why this is needed?
I don't think this should be in the dt as is. Could this not be registered based on the presence of a bluetooth controller that supports this?
Audio devices are linked together by a separate board binding which specifies how all the different components in the audio subsystem on the board are wired together. Even where things have no meanignful software control (as is the case here and for a lot of simple DACs or ADCs) the rest of the system needs information on their capabilites and ideally the ability to interchange them with more substantial devices. If there were meaningful control there'd be a control bus here.
There is likely to be a control interface for the BT device hanging off a UART but it's not clear there's much more meaningful data for those than there is here.
so the idea is that we don't add codec platform device in uart, and we add a dt node for it as we are doing here?
-barry
On Tue, Aug 06, 2013 at 08:09:18AM +0800, Barry Song wrote:
2013/7/17 Mark Brown broonie@kernel.org:
There is likely to be a control interface for the BT device hanging off a UART but it's not clear there's much more meaningful data for those than there is here.
so the idea is that we don't add codec platform device in uart, and we add a dt node for it as we are doing here?
Well, I think it's more OK to add a node like this one (possibly with a link to the UART) but if you can add it based on it hanging off the UART that's even better.
2013/8/7 Mark Brown broonie@kernel.org:
On Tue, Aug 06, 2013 at 08:09:18AM +0800, Barry Song wrote:
2013/7/17 Mark Brown broonie@kernel.org:
There is likely to be a control interface for the BT device hanging off a UART but it's not clear there's much more meaningful data for those than there is here.
so the idea is that we don't add codec platform device in uart, and we add a dt node for it as we are doing here?
Well, I think it's more OK to add a node like this one (possibly with a link to the UART) but if you can add it based on it hanging off the UART that's even better.
For 1, what kind of codes will have in the codec driver if adding a link to UART in codec dts node? UART is very generic to transfer path. it even doesn't know bluetooth is running on top of it.
For 2, if the case is that we add codec subnode in UART node, the UART driver will need to walk child nodes and extend platform device for them, it seems it is not uart driver likes.
-barry
On Wed, Aug 07, 2013 at 03:59:46PM +0800, Barry Song wrote:
For 1, what kind of codes will have in the codec driver if adding a link to UART in codec dts node? UART is very generic to transfer path. it even doesn't know bluetooth is running on top of it.
For 2, if the case is that we add codec subnode in UART node, the UART driver will need to walk child nodes and extend platform device for them, it seems it is not uart driver likes.
I don't know what 1 and 2 are (they weren't numbered in the mail you're replying to)... I'd expect that any intelligence would go into frameworks or into the device for the BT so for example if the BT device was hanging off the UART then the kernel would have generic support for parsing the DT and knowing that a fixed device was connected to the UART and be able to handle that - AIUI line disciplines are often used for this stuff.
2013/8/7 Mark Brown broonie@kernel.org:
On Wed, Aug 07, 2013 at 03:59:46PM +0800, Barry Song wrote:
For 1, what kind of codes will have in the codec driver if adding a link to UART in codec dts node? UART is very generic to transfer path. it even doesn't know bluetooth is running on top of it.
For 2, if the case is that we add codec subnode in UART node, the UART driver will need to walk child nodes and extend platform device for them, it seems it is not uart driver likes.
I don't know what 1 and 2 are (they weren't numbered in the mail you're replying to)... I'd expect that any intelligence would go into frameworks or into the device for the BT so for example if the BT device was hanging off the UART then the kernel would have generic support for parsing the DT and knowing that a fixed device was connected to the UART and be able to handle that - AIUI line disciplines are often used for this stuff.
it is fine. but it seems we are not easy to achieve this goal as we actually want to do that at uart or tty core instead of specific uart driver instance.
-barry
On Fri, Aug 09, 2013 at 04:41:57PM +0800, Barry Song wrote:
it is fine. but it seems we are not easy to achieve this goal as we actually want to do that at uart or tty core instead of specific uart driver instance.
Yes, this is one of the problems with DT - it forces things to be solved in a full and complete fashion since it defines ABI.
Hello.
On 17-07-2013 10:12, Barry Song wrote:
From: Rongjun Ying Rongjun.Ying@csr.com
this makes users be able to add a bt-sco node in dts instead of hardcoding a platform device in mach.
Signed-off-by: Rongjun Ying Rongjun.Ying@csr.com Signed-off-by: Barry Song Baohua.Song@csr.com
sound/soc/codecs/bt-sco.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
diff --git a/sound/soc/codecs/bt-sco.c b/sound/soc/codecs/bt-sco.c index a081d9f..39e7ebe 100644 --- a/sound/soc/codecs/bt-sco.c +++ b/sound/soc/codecs/bt-sco.c
[...]
@@ -58,6 +66,9 @@ static struct platform_driver bt_sco_driver = { .driver = { .name = "bt-sco", .owner = THIS_MODULE, +#ifdef CONFIG_OF
.of_match_table = bt_sco_of_match,+#endif
.of_match_table = of_match_ptr(bt_sco_of_match),
will get rid of #ifdef here.
WBR, Sergei
participants (5)
-
Barry Song -
Barry Song -
Mark Brown -
Mark Rutland -
Sergei Shtylyov