[PATCH 1/3] ASoC: bt-sco: enable OF support

[PATCH 1/3] ASoC: bt-sco: enable OF support

[Barry Song]

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,
-- 
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

[PATCH 2/3] ASoC: hdmi-codec: enable OF support

[Barry Song]

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,
-- 
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

[PATCH 2/3] ASoC: hdmi-codec: enable OF support

[Mark Rutland]

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 at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

[PATCH 2/3] ASoC: hdmi-codec: enable OF support

[Mark Brown]

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).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130717/2dca995c/attachment.sig>

[alsa-devel] [PATCH 2/3] ASoC: hdmi-codec: enable OF support

[Barry Song]

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

[PATCH 3/3] ASoC: hdmi-codec: let the driver support HDMI sink

[Barry Song]

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)
-- 
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

[PATCH 3/3] ASoC: hdmi-codec: let the driver support HDMI sink

[Mark Brown]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130717/3e21df67/attachment.sig>

[PATCH 1/3] ASoC: bt-sco: enable OF support

[Mark Rutland]

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 at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

[PATCH 1/3] ASoC: bt-sco: enable OF support

[Mark Brown]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130717/419fecfc/attachment.sig>

[alsa-devel] [PATCH 1/3] ASoC: bt-sco: enable OF support

[Barry Song]

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

[alsa-devel] [PATCH 1/3] ASoC: bt-sco: enable OF support

[Mark Brown]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130806/e86652a7/attachment.sig>

[alsa-devel] [PATCH 1/3] ASoC: bt-sco: enable OF support

[Barry Song]

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

[alsa-devel] [PATCH 1/3] ASoC: bt-sco: enable OF support

[Mark Brown]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130807/da61f05a/attachment.sig>

[alsa-devel] [PATCH 1/3] ASoC: bt-sco: enable OF support

[Barry Song]

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

[alsa-devel] [PATCH 1/3] ASoC: bt-sco: enable OF support

[Mark Brown]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130811/cd7a9959/attachment.sig>

[PATCH 1/3] ASoC: bt-sco: enable OF support

[Sergei Shtylyov]

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