On 2015年11月03日 19:24, Mark Brown wrote:
On Mon, Nov 02, 2015 at 09:02:29PM +0530, Vinod Koul wrote:
On Mon, Nov 02, 2015 at 12:07:27PM +0000, Mark Brown wrote:
On Mon, Nov 02, 2015 at 03:41:08PM +0530, Vinod Koul wrote:
It is similar but sst_machines structure is entirely different. In Skylake
case we only need machine entry name and rest of the information is coming
So what exactly is the "machine entry name" supposed to be here and why
don't we use any board specific information?
For this case the machine entry name is "skl_alc286s_i2s", which is the RT
ALC 286 codec combination on Skylake.
The SKL machine driver needs this as platform device and we create it here
+static struct sst_machines sst_skl_devdata[] = {
+ { "INT343A", "skl_alc286s_i2s" },
+};
This says for SKL, with codec ID "INT343A" create "skl_alc286s_i2s" machine
platform device
For different codec combination we can use codec ACPI names to match
I'm having a hard time seeing the difference between this and what's
going on in sst-acpi. They seem to be doing the same thing in slightly
different ways, they both match tables of CODEC IDs to machine driver
names with the distinction being that this doesn't provide a firmware
filename whereas sst-acpi does but the mechanics of mapping a CODEC to a
machine driver seem otherwise the same.
agree that it may be better if we can reuse(or merge with) sst driver
(intel/common/sst-acpi.c) for SKL.
thanks,
~Keyon
I am not sure I follow the comment on user, the SKL driver here is user in
this
There are no machines defined for this.
sound/soc/intel/boards/skl_rt286.c
Ugh, the machines table is *really* buried at the bottom of the file
here :(
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
