[RFC] ASoC: core: Allow DAI links to be specified by using ACPI names

[RFC] ASoC: core: Allow DAI links to be specified by using ACPI names

[Jarkko Nikula]

This patch adds alternative way to specify DAI links by using ACPI names.
ACPI name here is considered to be used as an alias for device name during
DAI link binding time.

Rationale behind this is that device name especially with bus connected
codecs may not be constant enough to be used in machines with dynamic and
variable amount of bus controllers due changing bus/adapter number.

One way to solve this problem on ACPI 5 based systems is to use ACPI names
of those devices that are enumerated by the ACPI subsystem.

For instance, matchine drivers could specify codec in DAI link by using:
	.codec_name = "INT33CA:00",
instead of
	.codec_name = "rt5640.0-001c",

Note that ACPI name is used just an alias during bind time and core
continues to use device name. In fact, machine drivers could use either
names.

Thanks to Mika Westerberg for initial idea to use ACPI handles for binding.
Author extended and simplified the idea so that struct snd_soc_dai_link
doesn't need a new field, machine drivers don't need any additional code
and soc-core.c can handle matching when executing soc_bind_dai_link().

Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
---
linux-acpi@vger.kernel.org cc'd if ACPI folks would like to check API usage
here.
---
 sound/soc/soc-core.c | 38 ++++++++++++++++++++++++++++++++------
 1 file changed, 32 insertions(+), 6 deletions(-)

diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 4280c70..5cb440e 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -36,6 +36,7 @@
 #include <linux/of.h>
 #include <linux/gpio.h>
 #include <linux/of_gpio.h>
+#include <linux/acpi.h>
 #include <sound/ac97_codec.h>
 #include <sound/core.h>
 #include <sound/jack.h>
@@ -836,6 +837,27 @@ EXPORT_SYMBOL_GPL(snd_soc_resume);
 static const struct snd_soc_dai_ops null_dai_ops = {
 };
 
+static bool soc_match_name(struct device *dev,
+			   const char *comp_name, const char *bind_name)
+{
+	if (!strcmp(comp_name, bind_name))
+		return true;
+
+#if IS_ENABLED(CONFIG_ACPI)
+	if (ACPI_HANDLE(dev)) {
+		struct acpi_device *adev;
+		if (!acpi_bus_get_device(ACPI_HANDLE(dev), &adev) &&
+		    !strcmp(dev_name(&adev->dev), bind_name)) {
+			dev_dbg(dev, "Matching with ACPI name %s\n",
+				dev_name(&adev->dev));
+			return true;
+		}
+	}
+#endif
+
+	return false;
+}
+
 static int soc_bind_dai_link(struct snd_soc_card *card, int num)
 {
 	struct snd_soc_dai_link *dai_link = &card->dai_link[num];
@@ -853,10 +875,12 @@ static int soc_bind_dai_link(struct snd_soc_card *card, int num)
 		    (cpu_dai->dev->of_node != dai_link->cpu_of_node))
 			continue;
 		if (dai_link->cpu_name &&
-		    strcmp(dev_name(cpu_dai->dev), dai_link->cpu_name))
+		    !soc_match_name(cpu_dai->dev, dev_name(cpu_dai->dev),
+				    dai_link->cpu_name))
 			continue;
 		if (dai_link->cpu_dai_name &&
-		    strcmp(cpu_dai->name, dai_link->cpu_dai_name))
+		    !soc_match_name(cpu_dai->dev, cpu_dai->name,
+				    dai_link->cpu_dai_name))
 			continue;
 
 		rtd->cpu_dai = cpu_dai;
@@ -874,7 +898,8 @@ static int soc_bind_dai_link(struct snd_soc_card *card, int num)
 			if (codec->dev->of_node != dai_link->codec_of_node)
 				continue;
 		} else {
-			if (strcmp(codec->name, dai_link->codec_name))
+			if (!soc_match_name(codec->dev, codec->name,
+					    dai_link->codec_name))
 				continue;
 		}
 
@@ -886,8 +911,8 @@ static int soc_bind_dai_link(struct snd_soc_card *card, int num)
 		 */
 		list_for_each_entry(codec_dai, &dai_list, list) {
 			if (codec->dev == codec_dai->dev &&
-				!strcmp(codec_dai->name,
-					dai_link->codec_dai_name)) {
+			    soc_match_name(codec->dev, codec_dai->name,
+					   dai_link->codec_dai_name)) {
 
 				rtd->codec_dai = codec_dai;
 			}
@@ -918,7 +943,8 @@ static int soc_bind_dai_link(struct snd_soc_card *card, int num)
 			    dai_link->platform_of_node)
 				continue;
 		} else {
-			if (strcmp(platform->name, platform_name))
+			if (!soc_match_name(platform->dev, platform->name,
+					    platform_name))
 				continue;
 		}
 
-- 
1.8.4.rc3

Re: [RFC] ASoC: core: Allow DAI links to be specified by using ACPI names

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 601 bytes --]

On Thu, Oct 03, 2013 at 03:33:56PM +0300, Jarkko Nikula wrote:

> For instance, matchine drivers could specify codec in DAI link by using:
> 	.codec_name = "INT33CA:00",
> instead of
> 	.codec_name = "rt5640.0-001c",

> Note that ACPI name is used just an alias during bind time and core
> continues to use device name. In fact, machine drivers could use either
> names.

This is making me wonder if we shouldn't be taking the stable names we
get from ACPI as the dev_name() instead of our internal ones on ACPI
systems (and possibly something similar on DT) rather than adding custom
code like this.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [RFC] ASoC: core: Allow DAI links to be specified by using ACPI names

[Jarkko Nikula]

On 10/03/2013 04:37 PM, Mark Brown wrote:
> On Thu, Oct 03, 2013 at 03:33:56PM +0300, Jarkko Nikula wrote:
>
>> For instance, matchine drivers could specify codec in DAI link by using:
>> 	.codec_name = "INT33CA:00",
>> instead of
>> 	.codec_name = "rt5640.0-001c",
>> Note that ACPI name is used just an alias during bind time and core
>> continues to use device name. In fact, machine drivers could use either
>> names.
> This is making me wonder if we shouldn't be taking the stable names we
> get from ACPI as the dev_name() instead of our internal ones on ACPI
> systems (and possibly something similar on DT) rather than adding custom
> code like this.
This is actually somewhat confusing issue. I think it's relatively easy 
to switch using ACPI names within ASoC core (by modifying 
fmt_single_name or something like that).

Problem is that for ACPI enumerated client devices the dev_name(dev) 
still comes from those subsystems as before. So for instance dev_ prints 
in codec driver or ASoC core keeps printing "rt5640 0-001c:" as before 
and I personally find it a bit more confusing if internal ASoC names 
don't match as easily with dev_ prints.

But yes, I agree. This alias name in DAI link is not that clear either 
as it exists only during bind time.

-- 
Jarkko

Re: [alsa-devel] [RFC] ASoC: core: Allow DAI links to be specified by using ACPI names

[Vinod Koul]

On Thu, Oct 03, 2013 at 05:22:45PM +0300, Jarkko Nikula wrote:
> On 10/03/2013 04:37 PM, Mark Brown wrote:
> >On Thu, Oct 03, 2013 at 03:33:56PM +0300, Jarkko Nikula wrote:
> >
> >>For instance, matchine drivers could specify codec in DAI link by using:
> >>	.codec_name = "INT33CA:00",
> >>instead of
> >>	.codec_name = "rt5640.0-001c",
> >>Note that ACPI name is used just an alias during bind time and core
> >>continues to use device name. In fact, machine drivers could use either
> >>names.
> >This is making me wonder if we shouldn't be taking the stable names we
> >get from ACPI as the dev_name() instead of our internal ones on ACPI
> >systems (and possibly something similar on DT) rather than adding custom
> >code like this.
> This is actually somewhat confusing issue. I think it's relatively
> easy to switch using ACPI names within ASoC core (by modifying
> fmt_single_name or something like that).
> 
> Problem is that for ACPI enumerated client devices the dev_name(dev)
> still comes from those subsystems as before. So for instance dev_
> prints in codec driver or ASoC core keeps printing "rt5640 0-001c:"
> as before and I personally find it a bit more confusing if internal
> ASoC names don't match as easily with dev_ prints.
> 
> But yes, I agree. This alias name in DAI link is not that clear
> either as it exists only during bind time.
Sorry am very ignorant about ACPI, but cant resist asking why should ACPI
allocate some internal name and then we go about figuring the bus, slave and
codec. Wouldn't it make sense to just get "rt5640.0-001c" as device from ACPI
and use it.

-- 
~Vinod

Re: [RFC] ASoC: core: Allow DAI links to be specified by using ACPI names

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1135 bytes --]

On Thu, Oct 03, 2013 at 05:22:45PM +0300, Jarkko Nikula wrote:
> On 10/03/2013 04:37 PM, Mark Brown wrote:

> >This is making me wonder if we shouldn't be taking the stable names we
> >get from ACPI as the dev_name() instead of our internal ones on ACPI
> >systems (and possibly something similar on DT) rather than adding custom
> >code like this.

> This is actually somewhat confusing issue. I think it's relatively
> easy to switch using ACPI names within ASoC core (by modifying
> fmt_single_name or something like that).

> Problem is that for ACPI enumerated client devices the dev_name(dev)
> still comes from those subsystems as before. So for instance dev_
> prints in codec driver or ASoC core keeps printing "rt5640 0-001c:"
> as before and I personally find it a bit more confusing if internal
> ASoC names don't match as easily with dev_ prints.

You're misreading my suggestion.  What I'm saying is that it seems like
it might be useful to have dev_name() return the ACPI name - this would
mean that everything, including all the dev_ prints, would use the same
name which would then become stable and tied to hardware.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [alsa-devel] [RFC] ASoC: core: Allow DAI links to be specified by using ACPI names

[Liam Girdwood]

On Thu, 2013-10-03 at 20:59 +0530, Vinod Koul wrote:
> On Thu, Oct 03, 2013 at 05:22:45PM +0300, Jarkko Nikula wrote:
> > On 10/03/2013 04:37 PM, Mark Brown wrote:
> > >On Thu, Oct 03, 2013 at 03:33:56PM +0300, Jarkko Nikula wrote:
> > >
> > >>For instance, matchine drivers could specify codec in DAI link by using:
> > >>	.codec_name = "INT33CA:00",
> > >>instead of
> > >>	.codec_name = "rt5640.0-001c",
> > >>Note that ACPI name is used just an alias during bind time and core
> > >>continues to use device name. In fact, machine drivers could use either
> > >>names.
> > >This is making me wonder if we shouldn't be taking the stable names we
> > >get from ACPI as the dev_name() instead of our internal ones on ACPI
> > >systems (and possibly something similar on DT) rather than adding custom
> > >code like this.
> > This is actually somewhat confusing issue. I think it's relatively
> > easy to switch using ACPI names within ASoC core (by modifying
> > fmt_single_name or something like that).
> > 
> > Problem is that for ACPI enumerated client devices the dev_name(dev)
> > still comes from those subsystems as before. So for instance dev_
> > prints in codec driver or ASoC core keeps printing "rt5640 0-001c:"
> > as before and I personally find it a bit more confusing if internal
> > ASoC names don't match as easily with dev_ prints.
> > 
> > But yes, I agree. This alias name in DAI link is not that clear
> > either as it exists only during bind time.
> Sorry am very ignorant about ACPI, but cant resist asking why should ACPI
> allocate some internal name and then we go about figuring the bus, slave and
> codec. Wouldn't it make sense to just get "rt5640.0-001c" as device from ACPI
> and use it.
> 

We have the situation whereby some BIOS settings can alter the I2C bus
number used by the codec. i.e. matching fail on "rt5640.0-001c" but
would succeed on "rt5640.7-001c".

Moving this to also support ACPI names would be a bonus since we would
only need to match on the static ACPI device name.

Liam

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [RFC] ASoC: core: Allow DAI links to be specified by using ACPI names

[Jarkko Nikula]

On 10/03/2013 07:19 PM, Mark Brown wrote:
> On Thu, Oct 03, 2013 at 05:22:45PM +0300, Jarkko Nikula wrote:
>> On 10/03/2013 04:37 PM, Mark Brown wrote:
>>> This is making me wonder if we shouldn't be taking the stable names we
>>> get from ACPI as the dev_name() instead of our internal ones on ACPI
>>> systems (and possibly something similar on DT) rather than adding custom
>>> code like this.
>> This is actually somewhat confusing issue. I think it's relatively
>> easy to switch using ACPI names within ASoC core (by modifying
>> fmt_single_name or something like that).
>> Problem is that for ACPI enumerated client devices the dev_name(dev)
>> still comes from those subsystems as before. So for instance dev_
>> prints in codec driver or ASoC core keeps printing "rt5640 0-001c:"
>> as before and I personally find it a bit more confusing if internal
>> ASoC names don't match as easily with dev_ prints.
> You're misreading my suggestion.  What I'm saying is that it seems like
> it might be useful to have dev_name() return the ACPI name - this would
> mean that everything, including all the dev_ prints, would use the same
> name which would then become stable and tied to hardware.
I see. Indeed, this sounds a better idea. At quick look is even more simple.

-- 
Jarkko

Re: [RFC] ASoC: core: Allow DAI links to be specified by using ACPI names

[Rafael J. Wysocki]

On Thursday, October 03, 2013 03:33:56 PM Jarkko Nikula wrote:
> This patch adds alternative way to specify DAI links by using ACPI names.
> ACPI name here is considered to be used as an alias for device name during
> DAI link binding time.

What's DAI?

> Rationale behind this is that device name especially with bus connected
> codecs may not be constant enough to be used in machines with dynamic and
> variable amount of bus controllers due changing bus/adapter number.
> 
> One way to solve this problem on ACPI 5 based systems is to use ACPI names
> of those devices that are enumerated by the ACPI subsystem.
> 
> For instance, matchine drivers could specify codec in DAI link by using:
> 	.codec_name = "INT33CA:00",
> instead of
> 	.codec_name = "rt5640.0-001c",
> 
> Note that ACPI name is used just an alias during bind time and core
> continues to use device name. In fact, machine drivers could use either
> names.
> 
> Thanks to Mika Westerberg for initial idea to use ACPI handles for binding.
> Author extended and simplified the idea so that struct snd_soc_dai_link
> doesn't need a new field, machine drivers don't need any additional code
> and soc-core.c can handle matching when executing soc_bind_dai_link().
> 
> Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
> Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> ---
> linux-acpi@vger.kernel.org cc'd if ACPI folks would like to check API usage
> here.
> ---
>  sound/soc/soc-core.c | 38 ++++++++++++++++++++++++++++++++------
>  1 file changed, 32 insertions(+), 6 deletions(-)
> 
> diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
> index 4280c70..5cb440e 100644
> --- a/sound/soc/soc-core.c
> +++ b/sound/soc/soc-core.c
> @@ -36,6 +36,7 @@
>  #include <linux/of.h>
>  #include <linux/gpio.h>
>  #include <linux/of_gpio.h>
> +#include <linux/acpi.h>
>  #include <sound/ac97_codec.h>
>  #include <sound/core.h>
>  #include <sound/jack.h>
> @@ -836,6 +837,27 @@ EXPORT_SYMBOL_GPL(snd_soc_resume);
>  static const struct snd_soc_dai_ops null_dai_ops = {
>  };
>  
> +static bool soc_match_name(struct device *dev,
> +			   const char *comp_name, const char *bind_name)
> +{
> +	if (!strcmp(comp_name, bind_name))
> +		return true;
> +
> +#if IS_ENABLED(CONFIG_ACPI)

That's not necessary, because ACPI_HANDLE() is defined as false for
CONFIG_ACPI unset.

> +	if (ACPI_HANDLE(dev)) {
> +		struct acpi_device *adev;
> +		if (!acpi_bus_get_device(ACPI_HANDLE(dev), &adev) &&
> +		    !strcmp(dev_name(&adev->dev), bind_name)) {
> +			dev_dbg(dev, "Matching with ACPI name %s\n",
> +				dev_name(&adev->dev));
> +			return true;
> +		}
> +	}
> +#endif
> +
> +	return false;
> +}
> +
>  static int soc_bind_dai_link(struct snd_soc_card *card, int num)
>  {
>  	struct snd_soc_dai_link *dai_link = &card->dai_link[num];
> @@ -853,10 +875,12 @@ static int soc_bind_dai_link(struct snd_soc_card *card, int num)
>  		    (cpu_dai->dev->of_node != dai_link->cpu_of_node))
>  			continue;
>  		if (dai_link->cpu_name &&
> -		    strcmp(dev_name(cpu_dai->dev), dai_link->cpu_name))
> +		    !soc_match_name(cpu_dai->dev, dev_name(cpu_dai->dev),
> +				    dai_link->cpu_name))
>  			continue;
>  		if (dai_link->cpu_dai_name &&
> -		    strcmp(cpu_dai->name, dai_link->cpu_dai_name))
> +		    !soc_match_name(cpu_dai->dev, cpu_dai->name,
> +				    dai_link->cpu_dai_name))
>  			continue;
>  
>  		rtd->cpu_dai = cpu_dai;
> @@ -874,7 +898,8 @@ static int soc_bind_dai_link(struct snd_soc_card *card, int num)
>  			if (codec->dev->of_node != dai_link->codec_of_node)
>  				continue;
>  		} else {
> -			if (strcmp(codec->name, dai_link->codec_name))
> +			if (!soc_match_name(codec->dev, codec->name,
> +					    dai_link->codec_name))
>  				continue;
>  		}
>  
> @@ -886,8 +911,8 @@ static int soc_bind_dai_link(struct snd_soc_card *card, int num)
>  		 */
>  		list_for_each_entry(codec_dai, &dai_list, list) {
>  			if (codec->dev == codec_dai->dev &&
> -				!strcmp(codec_dai->name,
> -					dai_link->codec_dai_name)) {
> +			    soc_match_name(codec->dev, codec_dai->name,
> +					   dai_link->codec_dai_name)) {
>  
>  				rtd->codec_dai = codec_dai;
>  			}
> @@ -918,7 +943,8 @@ static int soc_bind_dai_link(struct snd_soc_card *card, int num)
>  			    dai_link->platform_of_node)
>  				continue;
>  		} else {
> -			if (strcmp(platform->name, platform_name))
> +			if (!soc_match_name(platform->dev, platform->name,
> +					    platform_name))
>  				continue;
>  		}
>  

Thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [RFC] ASoC: core: Allow DAI links to be specified by using ACPI names

[Rafael J. Wysocki]

On Friday, October 04, 2013 09:28:27 AM Jarkko Nikula wrote:
> On 10/03/2013 07:19 PM, Mark Brown wrote:
> > On Thu, Oct 03, 2013 at 05:22:45PM +0300, Jarkko Nikula wrote:
> >> On 10/03/2013 04:37 PM, Mark Brown wrote:
> >>> This is making me wonder if we shouldn't be taking the stable names we
> >>> get from ACPI as the dev_name() instead of our internal ones on ACPI
> >>> systems (and possibly something similar on DT) rather than adding custom
> >>> code like this.
> >> This is actually somewhat confusing issue. I think it's relatively
> >> easy to switch using ACPI names within ASoC core (by modifying
> >> fmt_single_name or something like that).
> >> Problem is that for ACPI enumerated client devices the dev_name(dev)
> >> still comes from those subsystems as before. So for instance dev_
> >> prints in codec driver or ASoC core keeps printing "rt5640 0-001c:"
> >> as before and I personally find it a bit more confusing if internal
> >> ASoC names don't match as easily with dev_ prints.
> > You're misreading my suggestion.  What I'm saying is that it seems like
> > it might be useful to have dev_name() return the ACPI name - this would
> > mean that everything, including all the dev_ prints, would use the same
> > name which would then become stable and tied to hardware.
> I see. Indeed, this sounds a better idea. At quick look is even more simple.

Well, this is slightly ambiguous.  What exactly do you mean by "ACPI names"?

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [RFC] ASoC: core: Allow DAI links to be specified by using ACPI names

[Jarkko Nikula]

On 10/04/2013 09:53 AM, Rafael J. Wysocki wrote:
> On Thursday, October 03, 2013 03:33:56 PM Jarkko Nikula wrote:
>> This patch adds alternative way to specify DAI links by using ACPI names.
>> ACPI name here is considered to be used as an alias for device name during
>> DAI link binding time.
> What's DAI?
It comes from Digital Audio Interface, and DAI link in ALSA SoC 
basically ties together platform, DAI and codec devices by name or 
device tree node.

> +#if IS_ENABLED(CONFIG_ACPI)
> That's not necessary, because ACPI_HANDLE() is defined as false for
> CONFIG_ACPI unset.
Actually problem acpi_bus_get_device() that is not available if 
CONFIG_ACPI is not set. Which suggests was it even meant to be used in 
drivers that are build for non ACPI systems too?

-- 
Jarkko

Re: [RFC] ASoC: core: Allow DAI links to be specified by using ACPI names

[Jarkko Nikula]

On 10/04/2013 09:55 AM, Rafael J. Wysocki wrote:
> You're misreading my suggestion.  What I'm saying is that it seems like
> it might be useful to have dev_name() return the ACPI name - this would
> mean that everything, including all the dev_ prints, would use the same
> name which would then become stable and tied to hardware.
>> I see. Indeed, this sounds a better idea. At quick look is even more simple.
> Well, this is slightly ambiguous.  What exactly do you mean by "ACPI names"?
>
Ah, yes. What I meant as ACPI name was the <bus_id:instance> based ACPI 
device name/object (or what is the correct terminology), not the 
hardware ID.

-- 
Jarkko

Re: [RFC] ASoC: core: Allow DAI links to be specified by using ACPI names

[Rafael J. Wysocki]

On Friday, October 04, 2013 10:22:43 AM Jarkko Nikula wrote:
> On 10/04/2013 09:53 AM, Rafael J. Wysocki wrote:
> > On Thursday, October 03, 2013 03:33:56 PM Jarkko Nikula wrote:
> >> This patch adds alternative way to specify DAI links by using ACPI names.
> >> ACPI name here is considered to be used as an alias for device name during
> >> DAI link binding time.
> > What's DAI?
> It comes from Digital Audio Interface, and DAI link in ALSA SoC 
> basically ties together platform, DAI and codec devices by name or 
> device tree node.
> 
> > +#if IS_ENABLED(CONFIG_ACPI)
> > That's not necessary, because ACPI_HANDLE() is defined as false for
> > CONFIG_ACPI unset.
> Actually problem acpi_bus_get_device() that is not available if 
> CONFIG_ACPI is not set. Which suggests was it even meant to be used in 
> drivers that are build for non ACPI systems too?

No, acpi_bus_get_device() shoudn't be used if CONFIG_ACPI is not set.

Thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [RFC] ASoC: core: Allow DAI links to be specified by using ACPI names

[Rafael J. Wysocki]

On Friday, October 04, 2013 10:38:10 AM Jarkko Nikula wrote:
> On 10/04/2013 09:55 AM, Rafael J. Wysocki wrote:
> > You're misreading my suggestion.  What I'm saying is that it seems like
> > it might be useful to have dev_name() return the ACPI name - this would
> > mean that everything, including all the dev_ prints, would use the same
> > name which would then become stable and tied to hardware.
> >> I see. Indeed, this sounds a better idea. At quick look is even more simple.
> > Well, this is slightly ambiguous.  What exactly do you mean by "ACPI names"?
> >
> Ah, yes. What I meant as ACPI name was the <bus_id:instance> based ACPI 
> device name/object (or what is the correct terminology), not the 
> hardware ID.

OK

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [RFC] ASoC: core: Allow DAI links to be specified by using ACPI names

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 316 bytes --]

On Thu, Oct 03, 2013 at 03:33:56PM +0300, Jarkko Nikula wrote:
> This patch adds alternative way to specify DAI links by using ACPI names.
> ACPI name here is considered to be used as an alias for device name during
> DAI link binding time.

Did anything happen with the idea of making dev_name() use the ACPI
name?

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [RFC] ASoC: core: Allow DAI links to be specified by using ACPI names

[Jarkko Nikula]

On 10/24/2013 12:51 PM, Mark Brown wrote:
> On Thu, Oct 03, 2013 at 03:33:56PM +0300, Jarkko Nikula wrote:
>> This patch adds alternative way to specify DAI links by using ACPI names.
>> ACPI name here is considered to be used as an alias for device name during
>> DAI link binding time.
> Did anything happen with the idea of making dev_name() use the ACPI
> name?
Well, looks like I manage to put it aside. I'll spin it again as next 
merge window starts to be too near now.

-- 
Jarkko

Re: [RFC] ASoC: core: Allow DAI links to be specified by using ACPI names

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 592 bytes --]

On Fri, Oct 25, 2013 at 09:53:28AM +0300, Jarkko Nikula wrote:
> On 10/24/2013 12:51 PM, Mark Brown wrote:

> >Did anything happen with the idea of making dev_name() use the ACPI
> >name?

> Well, looks like I manage to put it aside. I'll spin it again as
> next merge window starts to be too near now.

OK, I was asking because I was thinking of applying the patch for now;
it's not that it's a bad idea it just seems like it's something that
might might make sense solved at that level.  Equally well I don't know
if these systems will work with v3.13 anyway so perhaps it's not so
urgent.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [RFC] ASoC: core: Allow DAI links to be specified by using ACPI names

[Jarkko Nikula]

On 10/25/2013 01:06 PM, Mark Brown wrote:
> OK, I was asking because I was thinking of applying the patch for now; 
> it's not that it's a bad idea it just seems like it's something that 
> might might make sense solved at that level. Equally well I don't know 
> if these systems will work with v3.13 anyway so perhaps it's not so 
> urgent. 
Yes, I don't see any urgent reason to push this hack in. Better to check 
dev_name change first. What I'm going to propose there is "spix.y" to 
"spi-INTABCD:xy" and "x-00yz" to "i2c-INTABCD:xy"

-- 
Jarkko

Re: [alsa-devel] [RFC] ASoC: core: Allow DAI links to be specified by using ACPI names

[Liam Girdwood]

On Fri, 2013-10-25 at 13:42 +0300, Jarkko Nikula wrote:
> On 10/25/2013 01:06 PM, Mark Brown wrote:
> > OK, I was asking because I was thinking of applying the patch for now; 
> > it's not that it's a bad idea it just seems like it's something that 
> > might might make sense solved at that level. Equally well I don't know 
> > if these systems will work with v3.13 anyway so perhaps it's not so 
> > urgent. 
> Yes, I don't see any urgent reason to push this hack in. Better to check 
> dev_name change first. What I'm going to propose there is "spix.y" to 
> "spi-INTABCD:xy" and "x-00yz" to "i2c-INTABCD:xy"
> 

We probably need to be able to match on ACPI name alone as some BIOS
settings can change the I2C bus number and break the name match used at
bind time. e.g. on Haswell the codec can either be on I2C bus 0 or 7.

Liam

Re: [alsa-devel] [RFC] ASoC: core: Allow DAI links to be specified by using ACPI names

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 760 bytes --]

On Mon, Oct 28, 2013 at 11:53:14AM +0000, Liam Girdwood wrote:
> On Fri, 2013-10-25 at 13:42 +0300, Jarkko Nikula wrote:

> > Yes, I don't see any urgent reason to push this hack in. Better to check 
> > dev_name change first. What I'm going to propose there is "spix.y" to 
> > "spi-INTABCD:xy" and "x-00yz" to "i2c-INTABCD:xy"

> We probably need to be able to match on ACPI name alone as some BIOS
> settings can change the I2C bus number and break the name match used at
> bind time. e.g. on Haswell the codec can either be on I2C bus 0 or 7.

Indeed.  The way I initially read the suggestion above the idea was to
replace the bus number with the ACPI name for the device which seemed
sensible but now I reread the bus number is still there.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [alsa-devel] [RFC] ASoC: core: Allow DAI links to be specified by using ACPI names

[Jarkko Nikula]

On 10/28/2013 05:06 PM, Mark Brown wrote:
> On Mon, Oct 28, 2013 at 11:53:14AM +0000, Liam Girdwood wrote:
>> On Fri, 2013-10-25 at 13:42 +0300, Jarkko Nikula wrote:
>>> Yes, I don't see any urgent reason to push this hack in. Better to check
>>> dev_name change first. What I'm going to propose there is "spix.y" to
>>> "spi-INTABCD:xy" and "x-00yz" to "i2c-INTABCD:xy"
>> We probably need to be able to match on ACPI name alone as some BIOS
>> settings can change the I2C bus number and break the name match used at
>> bind time. e.g. on Haswell the codec can either be on I2C bus 0 or 7.
> Indeed.  The way I initially read the suggestion above the idea was to
> replace the bus number with the ACPI name for the device which seemed
> sensible but now I reread the bus number is still there.
Sorry, my textual proposal above was confusing and should have used 
different variables for ACPI name. What I meant was "spix.y" -> 
"spi-INTABCD:ij" and "x-00yz" to "i2c-INTABCD:ij" where "INTABCD:ij" was 
the ACPI device name which contains the device instance in "ij".

-- 
Jarkko

Re: [alsa-devel] [RFC] ASoC: core: Allow DAI links to be specified by using ACPI names

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

On Mon, Oct 28, 2013 at 05:23:45PM +0200, Jarkko Nikula wrote:
> On 10/28/2013 05:06 PM, Mark Brown wrote:

> >Indeed.  The way I initially read the suggestion above the idea was to
> >replace the bus number with the ACPI name for the device which seemed
> >sensible but now I reread the bus number is still there.

> Sorry, my textual proposal above was confusing and should have used
> different variables for ACPI name. What I meant was "spix.y" ->
> "spi-INTABCD:ij" and "x-00yz" to "i2c-INTABCD:ij" where "INTABCD:ij"
> was the ACPI device name which contains the device instance in "ij".

Ah, OK - it's actually what I read it as in the first place then!

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]