Re: Merging the new firmware files for CA0132 into alsa-firmware

Re: Merging the new firmware files for CA0132 into alsa-firmware

[Jaroslav Kysela]

Dne 28. 05. 19 v 16:54 Takashi Iwai napsal(a):
> Hi,
> 
> it seems that Connor's previous attempt to put a couple of ca0132
> firmware files into linux-firmware tree didn't go through,
> unfortunately.  And now I'm thinking of taking them into alsa-firmware
> package as a stop-gap.  We already distribute other ca0132 firmware
> files, so the addition shouldn't be a big problem.
> 
> Jaroslav, what do you think?

No problem. The same situation is for the SoC SOF firmware files (drivers are
in kernel, firmware files are missing). Perhaps, we can release those files
quickly in alsa-firmware and then migrate them slowly to linux-firmware.

					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: Merging the new firmware files for CA0132 into alsa-firmware

[Curtis Malainey]

On Tue, May 28, 2019 at 9:39 AM Jaroslav Kysela <perex@perex.cz> wrote:
>
> Dne 28. 05. 19 v 16:54 Takashi Iwai napsal(a):
> > Hi,
> >
> > it seems that Connor's previous attempt to put a couple of ca0132
> > firmware files into linux-firmware tree didn't go through,
> > unfortunately.  And now I'm thinking of taking them into alsa-firmware
> > package as a stop-gap.  We already distribute other ca0132 firmware
> > files, so the addition shouldn't be a big problem.
> >
> > Jaroslav, what do you think?
>
> No problem. The same situation is for the SoC SOF firmware files (drivers are
> in kernel, firmware files are missing). Perhaps, we can release those files
> quickly in alsa-firmware and then migrate them slowly to linux-firmware.
>
>                                         Jaroslav
>
I have some firmware I need to add for the RT5677, should I also just
add this to alsa-firmware instead of straight into linux-firmware?
> --
> Jaroslav Kysela <perex@perex.cz>
> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Merging the new firmware files for CA0132 into alsa-firmware

[Takashi Iwai]

On Tue, 28 May 2019 18:46:25 +0200,
Curtis Malainey wrote:
> 
> On Tue, May 28, 2019 at 9:39 AM Jaroslav Kysela <perex@perex.cz> wrote:
> >
> > Dne 28. 05. 19 v 16:54 Takashi Iwai napsal(a):
> > > Hi,
> > >
> > > it seems that Connor's previous attempt to put a couple of ca0132
> > > firmware files into linux-firmware tree didn't go through,
> > > unfortunately.  And now I'm thinking of taking them into alsa-firmware
> > > package as a stop-gap.  We already distribute other ca0132 firmware
> > > files, so the addition shouldn't be a big problem.
> > >
> > > Jaroslav, what do you think?
> >
> > No problem. The same situation is for the SoC SOF firmware files (drivers are
> > in kernel, firmware files are missing). Perhaps, we can release those files
> > quickly in alsa-firmware and then migrate them slowly to linux-firmware.
> >
> >                                         Jaroslav
> >
> I have some firmware I need to add for the RT5677, should I also just
> add this to alsa-firmware instead of straight into linux-firmware?

The best would be to linux-firmware tree.  We can put to alsa-firmware
repo as a stop-gap, e.g. if it's difficult by some reason or if it
takes too long, though.


thanks,

Takashi

Re: Merging the new firmware files for CA0132 into alsa-firmware

[Pierre-Louis Bossart]

On 5/28/19 11:38 AM, Jaroslav Kysela wrote:
> Dne 28. 05. 19 v 16:54 Takashi Iwai napsal(a):
>> Hi,
>>
>> it seems that Connor's previous attempt to put a couple of ca0132
>> firmware files into linux-firmware tree didn't go through,
>> unfortunately.  And now I'm thinking of taking them into alsa-firmware
>> package as a stop-gap.  We already distribute other ca0132 firmware
>> files, so the addition shouldn't be a big problem.
>>
>> Jaroslav, what do you think?
> 
> No problem. The same situation is for the SoC SOF firmware files (drivers are
> in kernel, firmware files are missing). Perhaps, we can release those files
> quickly in alsa-firmware and then migrate them slowly to linux-firmware.

for SOF there are 4 cases

1. developers/integrators build from scratch themselves from the public 
tree.
2. integrators build from scratch with their own secret sauce added.
3. distros want a binary since they don't want to build from source 
and/or don't have access to all the DSP tools
4. distros needs a binary signed with the Intel production key (e.g. to 
run on devices initially designed for Windows).

So far we were mostly dealing with case 1. Case 2 is allowed by the SOF 
permissive license and there's no need to look into this. We are 
planning releases for the last two cases, with a cadence aligned with 
kernel updates. It's not fully clear to me if the linux-firmware tree is 
the 'right' solution since ideally we'd want to have firmware, topology 
and UCM files released at the same time.

SOF firmware/ucm/topology packaging (was: CA0132 firmware)

[Jaroslav Kysela]

I believe that we need to discuss this more.

Dne 28. 05. 19 v 18:59 Pierre-Louis Bossart napsal(a):
> 
> 
> On 5/28/19 11:38 AM, Jaroslav Kysela wrote:
>
>> The same situation is for the SoC SOF firmware files (drivers are
>> in kernel, firmware files are missing). Perhaps, we can release those files
>> quickly in alsa-firmware and then migrate them slowly to linux-firmware.
> 
> for SOF there are 4 cases
> 
> 1. developers/integrators build from scratch themselves from the public 
> tree.
> 2. integrators build from scratch with their own secret sauce added.
> 3. distros want a binary since they don't want to build from source 
> and/or don't have access to all the DSP tools
> 4. distros needs a binary signed with the Intel production key (e.g. to 
> run on devices initially designed for Windows).

Do you mean that the firmware should be signed because the hardware is doing a
check, if the hardware vendor enables it and rejects the unsigned binaries?

> So far we were mostly dealing with case 1. Case 2 is allowed by the SOF 
> permissive license and there's no need to look into this. We are 
> planning releases for the last two cases, with a cadence aligned with 
> kernel updates. It's not fully clear to me if the linux-firmware tree is 
> the 'right' solution since ideally we'd want to have firmware, topology 
> and UCM files released at the same time.

Do you plan to create a new package for this? I can eventually offer the space
/ docker build system on the ALSA server, if you like. The github releases
work fine, too. The question is, if it's the right way. It seems that the
firmware/topology files are read-only chunks used by the driver (standard
usage) and the UCM config is for alsa-lib (the user space). It might make
probably sense to add compatibility IDs to link/check the correct parts
together at runtime and keep the standard (binary) code distribution for the
most of users (linux-firmware / alsa-lib).

Speaking for distributions, we need to correctly identify the driver which
will load the proper firmware files. From notes posted to the alsa-devel ML,
it seems that there are three drivers for similar hardware (sound bridges) now
and it is not easy to identify the proper driver, because the similar PCI ID
is registered in all of them:

1) legacy HDA
2) sound/soc/intel
3) sound/soc/sof/intel

Do not forget that the distributions include all driver modules in their
universal kernels. It seems like a problem for the Intel hardware at the
moment. Perhaps, you may give us some recommendations / hints.

Totaly another topic is the on-demand installation of firmware files (and
eventually ALSA configuration files). The linux-firmware package has over
180MB now and it's growing. It makes sense to install only useable firmware
files - ommit the files for hardware / drivers which are not detected and
used. It's probably a topic for linux-firmware rather then the ALSA project.

					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: SOF firmware/ucm/topology packaging

[Pierre-Louis Bossart]

On 5/28/19 2:15 PM, Jaroslav Kysela wrote:
> I believe that we need to discuss this more.

Yep, absolutely!

> Dne 28. 05. 19 v 18:59 Pierre-Louis Bossart napsal(a):
>>
>>
>> On 5/28/19 11:38 AM, Jaroslav Kysela wrote:
>>
>>> The same situation is for the SoC SOF firmware files (drivers are
>>> in kernel, firmware files are missing). Perhaps, we can release those files
>>> quickly in alsa-firmware and then migrate them slowly to linux-firmware.
>>
>> for SOF there are 4 cases
>>
>> 1. developers/integrators build from scratch themselves from the public
>> tree.
>> 2. integrators build from scratch with their own secret sauce added.
>> 3. distros want a binary since they don't want to build from source
>> and/or don't have access to all the DSP tools
>> 4. distros needs a binary signed with the Intel production key (e.g. to
>> run on devices initially designed for Windows).
> 
> Do you mean that the firmware should be signed because the hardware is doing a
> check, if the hardware vendor enables it and rejects the unsigned binaries?

It depends on the platforms.
Baytrail/Cherrytrail/Broadwell don't need any signature.
Starting with Skylake, the firmware is authenticated and the DSP will 
not boot unless it's signed with the relevant key, but different 
platforms chose different protections. Most of the Windows platforms use 
a strong authentication based on a non-public 'production key', which 
prevents people from installing their own firmware. Other solutions such 
as Up Squared boards or 2019 Chromebooks use a public key that is 
already part of the SOF tree.
Unfortunately I didn't find a way to detect which key is used, and it's 
not wise to try multiple keys since it adds a lot of latency on startup, 
so we are leaning to use DMI-based quirks to detect which key is used by 
what.

> 
>> So far we were mostly dealing with case 1. Case 2 is allowed by the SOF
>> permissive license and there's no need to look into this. We are
>> planning releases for the last two cases, with a cadence aligned with
>> kernel updates. It's not fully clear to me if the linux-firmware tree is
>> the 'right' solution since ideally we'd want to have firmware, topology
>> and UCM files released at the same time.
> 
> Do you plan to create a new package for this? I can eventually offer the space
> / docker build system on the ALSA server, if you like. The github releases
> work fine, too. The question is, if it's the right way. It seems that the
> firmware/topology files are read-only chunks used by the driver (standard
> usage) and the UCM config is for alsa-lib (the user space). It might make
> probably sense to add compatibility IDs to link/check the correct parts
> together at runtime and keep the standard (binary) code distribution for the
> most of users (linux-firmware / alsa-lib).

There is a connection mostly between topology and UCM: the device 
numbers used for the PCM streams have to match. If you add/remove a 
stream in the topology, then UCM will use numbers that aren't quite 
right. Same if you have a volume control used in UCM, you need to make 
sure that volume control is actually part of the topology.

In the past, we discussed about moving UCM files and topology out of the 
alsa-lib umbrella (and clarify what the license is for these 
configuration files), it's probably a good time to revisit this.

> 
> Speaking for distributions, we need to correctly identify the driver which
> will load the proper firmware files. From notes posted to the alsa-devel ML,
> it seems that there are three drivers for similar hardware (sound bridges) now
> and it is not easy to identify the proper driver, because the similar PCI ID
> is registered in all of them:
> 
> 1) legacy HDA
> 2) sound/soc/intel
> 3) sound/soc/sof/intel
> 
> Do not forget that the distributions include all driver modules in their
> universal kernels. It seems like a problem for the Intel hardware at the
> moment. Perhaps, you may give us some recommendations / hints.

Yes, I've started working on this, it's part of the same "distro 
enabling" discussion.
In most of the cases, the legacy HDaudio driver can be used, unless 
there are DMICs attached. I submitted an RFC to try to add an 
auto-detection.
I also added a build-time exclusion between SOF and SST drivers, and a 
smarter run-time detection I am still working on.

> 
> Totaly another topic is the on-demand installation of firmware files (and
> eventually ALSA configuration files). The linux-firmware package has over
> 180MB now and it's growing. It makes sense to install only useable firmware
> files - ommit the files for hardware / drivers which are not detected and
> used. It's probably a topic for linux-firmware rather then the ALSA project.

Indeed, for SOF we already have 6 or 7 firmwares for different SOCs and 
all the possible topologies.

Re: SOF firmware/ucm/topology packaging

[Jaroslav Kysela]

Dne 28. 05. 19 v 23:32 Pierre-Louis Bossart napsal(a):
> On 5/28/19 2:15 PM, Jaroslav Kysela wrote:
>> I believe that we need to discuss this more.
> 
> Yep, absolutely!
> 
>> Dne 28. 05. 19 v 18:59 Pierre-Louis Bossart napsal(a):
>>>
>>>
>>> On 5/28/19 11:38 AM, Jaroslav Kysela wrote:
>>>
>>>> The same situation is for the SoC SOF firmware files (drivers are
>>>> in kernel, firmware files are missing). Perhaps, we can release those files
>>>> quickly in alsa-firmware and then migrate them slowly to linux-firmware.
>>>
>>> for SOF there are 4 cases
>>>
>>> 1. developers/integrators build from scratch themselves from the public
>>> tree.
>>> 2. integrators build from scratch with their own secret sauce added.
>>> 3. distros want a binary since they don't want to build from source
>>> and/or don't have access to all the DSP tools
>>> 4. distros needs a binary signed with the Intel production key (e.g. to
>>> run on devices initially designed for Windows).
>>
>> Do you mean that the firmware should be signed because the hardware is doing a
>> check, if the hardware vendor enables it and rejects the unsigned binaries?
> 
> It depends on the platforms.
> Baytrail/Cherrytrail/Broadwell don't need any signature.
> Starting with Skylake, the firmware is authenticated and the DSP will 
> not boot unless it's signed with the relevant key, but different 
> platforms chose different protections. Most of the Windows platforms use 
> a strong authentication based on a non-public 'production key', which 
> prevents people from installing their own firmware. Other solutions such 
> as Up Squared boards or 2019 Chromebooks use a public key that is 
> already part of the SOF tree.
> Unfortunately I didn't find a way to detect which key is used, and it's 
> not wise to try multiple keys since it adds a lot of latency on startup, 
> so we are leaning to use DMI-based quirks to detect which key is used by 
> what.

Any ETA when then signed firmware will be available?

>>> So far we were mostly dealing with case 1. Case 2 is allowed by the SOF
>>> permissive license and there's no need to look into this. We are
>>> planning releases for the last two cases, with a cadence aligned with
>>> kernel updates. It's not fully clear to me if the linux-firmware tree is
>>> the 'right' solution since ideally we'd want to have firmware, topology
>>> and UCM files released at the same time.
>>
>> Do you plan to create a new package for this? I can eventually offer the space
>> / docker build system on the ALSA server, if you like. The github releases
>> work fine, too. The question is, if it's the right way. It seems that the
>> firmware/topology files are read-only chunks used by the driver (standard
>> usage) and the UCM config is for alsa-lib (the user space). It might make
>> probably sense to add compatibility IDs to link/check the correct parts
>> together at runtime and keep the standard (binary) code distribution for the
>> most of users (linux-firmware / alsa-lib).
> 
> There is a connection mostly between topology and UCM: the device 
> numbers used for the PCM streams have to match. If you add/remove a 
> stream in the topology, then UCM will use numbers that aren't quite 
> right. Same if you have a volume control used in UCM, you need to make 
> sure that volume control is actually part of the topology.
> 
> In the past, we discussed about moving UCM files and topology out of the 
> alsa-lib umbrella (and clarify what the license is for these 
> configuration files), it's probably a good time to revisit this.

It is also the packaging issue. This situation complicates the package
dependency tree. Basically, it might not be ideal to force users to install
extra package to support the specific hardware platform with fw/ucm/tplg
files. On the other side, there is no reason to have those bits installed on
system where the hardware does not exist. There should be an automatic way to
install the required bits on demand in the distribution in my opinion. I know,
it's not your issue.

I see those ways:

1) package everything hw specific to one package (fw/ucm/tplg), let distros to
handle the automatic installation when the hardware is detected or the
integration to the current alsa-lib/linux-firmware packages to avoid on-demand
installation

2) use some versioning / linking IDs for the firmware/topology/ucm, so we can
have more topology/ucm files for one hardware; the driver can use the
component field in the ALSA's control interface to notify the user space which
firmware / topology was loaded, so the correct UCM files can be used

>> Speaking for distributions, we need to correctly identify the driver which
>> will load the proper firmware files. From notes posted to the alsa-devel ML,
>> it seems that there are three drivers for similar hardware (sound bridges) now
>> and it is not easy to identify the proper driver, because the similar PCI ID
>> is registered in all of them:
>>
>> 1) legacy HDA
>> 2) sound/soc/intel
>> 3) sound/soc/sof/intel
>>
>> Do not forget that the distributions include all driver modules in their
>> universal kernels. It seems like a problem for the Intel hardware at the
>> moment. Perhaps, you may give us some recommendations / hints.
> 
> Yes, I've started working on this, it's part of the same "distro 
> enabling" discussion.
> In most of the cases, the legacy HDaudio driver can be used, unless 
> there are DMICs attached. I submitted an RFC to try to add an 
> auto-detection.
> I also added a build-time exclusion between SOF and SST drivers, and a 
> smarter run-time detection I am still working on.

Great. Thanks. It seems that the DMIC support is sensitive for the hardware
vendors now.

					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: SOF firmware/ucm/topology packaging

[Pierre-Louis Bossart]

>>>>> The same situation is for the SoC SOF firmware files (drivers are
>>>>> in kernel, firmware files are missing). Perhaps, we can release those files
>>>>> quickly in alsa-firmware and then migrate them slowly to linux-firmware.
>>>>
>>>> for SOF there are 4 cases
>>>>
>>>> 1. developers/integrators build from scratch themselves from the public
>>>> tree.
>>>> 2. integrators build from scratch with their own secret sauce added.
>>>> 3. distros want a binary since they don't want to build from source
>>>> and/or don't have access to all the DSP tools
>>>> 4. distros needs a binary signed with the Intel production key (e.g. to
>>>> run on devices initially designed for Windows).
>>>
>>> Do you mean that the firmware should be signed because the hardware is doing a
>>> check, if the hardware vendor enables it and rejects the unsigned binaries?
>>
>> It depends on the platforms.
>> Baytrail/Cherrytrail/Broadwell don't need any signature.
>> Starting with Skylake, the firmware is authenticated and the DSP will
>> not boot unless it's signed with the relevant key, but different
>> platforms chose different protections. Most of the Windows platforms use
>> a strong authentication based on a non-public 'production key', which
>> prevents people from installing their own firmware. Other solutions such
>> as Up Squared boards or 2019 Chromebooks use a public key that is
>> already part of the SOF tree.
>> Unfortunately I didn't find a way to detect which key is used, and it's
>> not wise to try multiple keys since it adds a lot of latency on startup,
>> so we are leaning to use DMI-based quirks to detect which key is used by
>> what.
> 
> Any ETA when then signed firmware will be available?

it's being productized as we speak and it's my understanding that SOF 
1.3 will provide a signed firmware for recent chipsets.

>>>> So far we were mostly dealing with case 1. Case 2 is allowed by the SOF
>>>> permissive license and there's no need to look into this. We are
>>>> planning releases for the last two cases, with a cadence aligned with
>>>> kernel updates. It's not fully clear to me if the linux-firmware tree is
>>>> the 'right' solution since ideally we'd want to have firmware, topology
>>>> and UCM files released at the same time.
>>>
>>> Do you plan to create a new package for this? I can eventually offer the space
>>> / docker build system on the ALSA server, if you like. The github releases
>>> work fine, too. The question is, if it's the right way. It seems that the
>>> firmware/topology files are read-only chunks used by the driver (standard
>>> usage) and the UCM config is for alsa-lib (the user space). It might make
>>> probably sense to add compatibility IDs to link/check the correct parts
>>> together at runtime and keep the standard (binary) code distribution for the
>>> most of users (linux-firmware / alsa-lib).
>>
>> There is a connection mostly between topology and UCM: the device
>> numbers used for the PCM streams have to match. If you add/remove a
>> stream in the topology, then UCM will use numbers that aren't quite
>> right. Same if you have a volume control used in UCM, you need to make
>> sure that volume control is actually part of the topology.
>>
>> In the past, we discussed about moving UCM files and topology out of the
>> alsa-lib umbrella (and clarify what the license is for these
>> configuration files), it's probably a good time to revisit this.
> 
> It is also the packaging issue. This situation complicates the package
> dependency tree. Basically, it might not be ideal to force users to install
> extra package to support the specific hardware platform with fw/ucm/tplg
> files. On the other side, there is no reason to have those bits installed on
> system where the hardware does not exist. There should be an automatic way to
> install the required bits on demand in the distribution in my opinion. I know,
> it's not your issue.
> 
> I see those ways:
> 
> 1) package everything hw specific to one package (fw/ucm/tplg), let distros to
> handle the automatic installation when the hardware is detected or the
> integration to the current alsa-lib/linux-firmware packages to avoid on-demand
> installation
> 
> 2) use some versioning / linking IDs for the firmware/topology/ucm, so we can
> have more topology/ucm files for one hardware; the driver can use the
> component field in the ALSA's control interface to notify the user space which
> firmware / topology was loaded, so the correct UCM files can be used

Unfortunately that would not work. The UCM file needs to be aligned with 
the topology but also with the hardware peripherals used. The topology 
file only describes the DSP graph, all the way from PCM streams to DAIs. 
The platform hardware can be very different even when you use the same 
topology file. A simple example is that some platforms have a single 
speaker or others two. The mics may be analog or digital. That 
hardware-level information that UCM needs to know is not discoverable 
and we have to rely on DMI-based quirks to set a long name. Knowing 
which topology file was used will not help.
Even finding out which topology file is needed is not obvious. We 
currently use the codec ACPI ID as a key to look-up a set of static 
tables to figure out which firmware and topology files need to be used, 
but it's likely we will have multiple platforms which will end-up using 
the same generic topology even though they'd need a different one to 
account for form-factor or acoustics. Again we will have to use quirks here.

> 
>>> Speaking for distributions, we need to correctly identify the driver which
>>> will load the proper firmware files. From notes posted to the alsa-devel ML,
>>> it seems that there are three drivers for similar hardware (sound bridges) now
>>> and it is not easy to identify the proper driver, because the similar PCI ID
>>> is registered in all of them:
>>>
>>> 1) legacy HDA
>>> 2) sound/soc/intel
>>> 3) sound/soc/sof/intel
>>>
>>> Do not forget that the distributions include all driver modules in their
>>> universal kernels. It seems like a problem for the Intel hardware at the
>>> moment. Perhaps, you may give us some recommendations / hints.
>>
>> Yes, I've started working on this, it's part of the same "distro
>> enabling" discussion.
>> In most of the cases, the legacy HDaudio driver can be used, unless
>> there are DMICs attached. I submitted an RFC to try to add an
>> auto-detection.
>> I also added a build-time exclusion between SOF and SST drivers, and a
>> smarter run-time detection I am still working on.
> 
> Great. Thanks. It seems that the DMIC support is sensitive for the hardware
> vendors now.

Indeed, the combination of HDAudio codecs+ DMIC keeps most of the SOF 
team busy at the moment.

Re: SOF firmware/ucm/topology packaging

[Jaroslav Kysela]

Dne 30. 05. 19 v 13:21 Pierre-Louis Bossart napsal(a):
> 
>>>>>> The same situation is for the SoC SOF firmware files (drivers are
>>>>>> in kernel, firmware files are missing). Perhaps, we can release those files
>>>>>> quickly in alsa-firmware and then migrate them slowly to linux-firmware.
>>>>>
>>>>> for SOF there are 4 cases
>>>>>
>>>>> 1. developers/integrators build from scratch themselves from the public
>>>>> tree.
>>>>> 2. integrators build from scratch with their own secret sauce added.
>>>>> 3. distros want a binary since they don't want to build from source
>>>>> and/or don't have access to all the DSP tools
>>>>> 4. distros needs a binary signed with the Intel production key (e.g. to
>>>>> run on devices initially designed for Windows).
>>>>
>>>> Do you mean that the firmware should be signed because the hardware is doing a
>>>> check, if the hardware vendor enables it and rejects the unsigned binaries?
>>>
>>> It depends on the platforms.
>>> Baytrail/Cherrytrail/Broadwell don't need any signature.
>>> Starting with Skylake, the firmware is authenticated and the DSP will
>>> not boot unless it's signed with the relevant key, but different
>>> platforms chose different protections. Most of the Windows platforms use
>>> a strong authentication based on a non-public 'production key', which
>>> prevents people from installing their own firmware. Other solutions such
>>> as Up Squared boards or 2019 Chromebooks use a public key that is
>>> already part of the SOF tree.
>>> Unfortunately I didn't find a way to detect which key is used, and it's
>>> not wise to try multiple keys since it adds a lot of latency on startup,
>>> so we are leaning to use DMI-based quirks to detect which key is used by
>>> what.
>>
>> Any ETA when then signed firmware will be available?
> 
> it's being productized as we speak and it's my understanding that SOF 
> 1.3 will provide a signed firmware for recent chipsets.
> 
>>>>> So far we were mostly dealing with case 1. Case 2 is allowed by the SOF
>>>>> permissive license and there's no need to look into this. We are
>>>>> planning releases for the last two cases, with a cadence aligned with
>>>>> kernel updates. It's not fully clear to me if the linux-firmware tree is
>>>>> the 'right' solution since ideally we'd want to have firmware, topology
>>>>> and UCM files released at the same time.
>>>>
>>>> Do you plan to create a new package for this? I can eventually offer the space
>>>> / docker build system on the ALSA server, if you like. The github releases
>>>> work fine, too. The question is, if it's the right way. It seems that the
>>>> firmware/topology files are read-only chunks used by the driver (standard
>>>> usage) and the UCM config is for alsa-lib (the user space). It might make
>>>> probably sense to add compatibility IDs to link/check the correct parts
>>>> together at runtime and keep the standard (binary) code distribution for the
>>>> most of users (linux-firmware / alsa-lib).
>>>
>>> There is a connection mostly between topology and UCM: the device
>>> numbers used for the PCM streams have to match. If you add/remove a
>>> stream in the topology, then UCM will use numbers that aren't quite
>>> right. Same if you have a volume control used in UCM, you need to make
>>> sure that volume control is actually part of the topology.
>>>
>>> In the past, we discussed about moving UCM files and topology out of the
>>> alsa-lib umbrella (and clarify what the license is for these
>>> configuration files), it's probably a good time to revisit this.
>>
>> It is also the packaging issue. This situation complicates the package
>> dependency tree. Basically, it might not be ideal to force users to install
>> extra package to support the specific hardware platform with fw/ucm/tplg
>> files. On the other side, there is no reason to have those bits installed on
>> system where the hardware does not exist. There should be an automatic way to
>> install the required bits on demand in the distribution in my opinion. I know,
>> it's not your issue.
>>
>> I see those ways:
>>
>> 1) package everything hw specific to one package (fw/ucm/tplg), let distros to
>> handle the automatic installation when the hardware is detected or the
>> integration to the current alsa-lib/linux-firmware packages to avoid on-demand
>> installation
>>
>> 2) use some versioning / linking IDs for the firmware/topology/ucm, so we can
>> have more topology/ucm files for one hardware; the driver can use the
>> component field in the ALSA's control interface to notify the user space which
>> firmware / topology was loaded, so the correct UCM files can be used
> 
> Unfortunately that would not work. The UCM file needs to be aligned with 
> the topology but also with the hardware peripherals used. The topology 
> file only describes the DSP graph, all the way from PCM streams to DAIs. 
> The platform hardware can be very different even when you use the same 
> topology file. A simple example is that some platforms have a single 
> speaker or others two. The mics may be analog or digital. That 
> hardware-level information that UCM needs to know is not discoverable 
> and we have to rely on DMI-based quirks to set a long name. Knowing 
> which topology file was used will not help.
> Even finding out which topology file is needed is not obvious. We 
> currently use the codec ACPI ID as a key to look-up a set of static 
> tables to figure out which firmware and topology files need to be used, 
> but it's likely we will have multiple platforms which will end-up using 
> the same generic topology even though they'd need a different one to 
> account for form-factor or acoustics. Again we will have to use quirks here.

I think that we're talking about different components. We have
snd_component_add() function in the ALSA kernel core interface which can send
any ASCII identification of used components to the user space (ALSA card
level). So the driver can detect and describe the hardware in a more verbose
way. We can use this string later in alsa-lib/ucm and load and use the proper
UCM config based on the driver detection. So you may use quirks in the driver,
compose the runtime ASCII component list and let alsa-lib to choose the right
UCM config.

					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: Merging the new firmware files for CA0132 into alsa-firmware

[Takashi Iwai]

On Tue, 28 May 2019 18:38:48 +0200,
Jaroslav Kysela wrote:
> 
> Dne 28. 05. 19 v 16:54 Takashi Iwai napsal(a):
> > Hi,
> > 
> > it seems that Connor's previous attempt to put a couple of ca0132
> > firmware files into linux-firmware tree didn't go through,
> > unfortunately.  And now I'm thinking of taking them into alsa-firmware
> > package as a stop-gap.  We already distribute other ca0132 firmware
> > files, so the addition shouldn't be a big problem.
> > 
> > Jaroslav, what do you think?
> 
> No problem. The same situation is for the SoC SOF firmware files (drivers are
> in kernel, firmware files are missing). Perhaps, we can release those files
> quickly in alsa-firmware and then migrate them slowly to linux-firmware.

OK, now pushed to alsa-firmware git repo.

BTW, the situation is slightly different from SOF.  At this time, the
problem was that it's been submitted by a third person.


thanks,

Takashi

Re: Merging the new firmware files for CA0132 into alsa-firmware

[Jaroslav Kysela]

Dne 28. 05. 19 v 19:47 Takashi Iwai napsal(a):
> On Tue, 28 May 2019 18:38:48 +0200,
> Jaroslav Kysela wrote:
>>
>> Dne 28. 05. 19 v 16:54 Takashi Iwai napsal(a):
>>> Hi,
>>>
>>> it seems that Connor's previous attempt to put a couple of ca0132
>>> firmware files into linux-firmware tree didn't go through,
>>> unfortunately.  And now I'm thinking of taking them into alsa-firmware
>>> package as a stop-gap.  We already distribute other ca0132 firmware
>>> files, so the addition shouldn't be a big problem.
>>>
>>> Jaroslav, what do you think?
>>
>> No problem. The same situation is for the SoC SOF firmware files (drivers are
>> in kernel, firmware files are missing). Perhaps, we can release those files
>> quickly in alsa-firmware and then migrate them slowly to linux-firmware.
> 
> OK, now pushed to alsa-firmware git repo.
> 
> BTW, the situation is slightly different from SOF.  At this time, the
> problem was that it's been submitted by a third person.

Ok, so we don't have a licence for those files? Connor, have you tried to
contact Creative for a permission to use/distribute those files?

						Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: Merging the new firmware files for CA0132 into alsa-firmware

[Connor McAdams]

Yes, I did end up getting permission from Creative themselves to
redistribute the files. That was back in November of 2018.

I also asked them to email Takashi Iwai to confirm, which I think they
ended up doing.

My contact within Creative has not responded since December of 2018,
when I asked for a name to go with the email he told me to use for the
sign-off, and I think that was why the Linux firmware people weren't
willing to accept it.

If you need any more information, let me know.

On Tue, May 28, 2019 at 3:19 PM Jaroslav Kysela <perex@perex.cz> wrote:
>
> Dne 28. 05. 19 v 19:47 Takashi Iwai napsal(a):
> > On Tue, 28 May 2019 18:38:48 +0200,
> > Jaroslav Kysela wrote:
> >>
> >> Dne 28. 05. 19 v 16:54 Takashi Iwai napsal(a):
> >>> Hi,
> >>>
> >>> it seems that Connor's previous attempt to put a couple of ca0132
> >>> firmware files into linux-firmware tree didn't go through,
> >>> unfortunately.  And now I'm thinking of taking them into alsa-firmware
> >>> package as a stop-gap.  We already distribute other ca0132 firmware
> >>> files, so the addition shouldn't be a big problem.
> >>>
> >>> Jaroslav, what do you think?
> >>
> >> No problem. The same situation is for the SoC SOF firmware files (drivers are
> >> in kernel, firmware files are missing). Perhaps, we can release those files
> >> quickly in alsa-firmware and then migrate them slowly to linux-firmware.
> >
> > OK, now pushed to alsa-firmware git repo.
> >
> > BTW, the situation is slightly different from SOF.  At this time, the
> > problem was that it's been submitted by a third person.
>
> Ok, so we don't have a licence for those files? Connor, have you tried to
> contact Creative for a permission to use/distribute those files?
>
>                                                 Jaroslav
>
> --
> Jaroslav Kysela <perex@perex.cz>
> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: Merging the new firmware files for CA0132 into alsa-firmware

[Takashi Iwai]

On Tue, 28 May 2019 21:24:39 +0200,
Connor McAdams wrote:
> 
> Yes, I did end up getting permission from Creative themselves to
> redistribute the files. That was back in November of 2018.
> 
> I also asked them to email Takashi Iwai to confirm, which I think they
> ended up doing.
> 
> My contact within Creative has not responded since December of 2018,
> when I asked for a name to go with the email he told me to use for the
> sign-off, and I think that was why the Linux firmware people weren't
> willing to accept it.

Right, basically these two files align with the already existing other
ca0132 firmware files in the repo.  But the problem was just that the
submitter was the third person, which is quite unusual.


Takashi

> 
> If you need any more information, let me know.
> 
> On Tue, May 28, 2019 at 3:19 PM Jaroslav Kysela <perex@perex.cz> wrote:
> >
> > Dne 28. 05. 19 v 19:47 Takashi Iwai napsal(a):
> > > On Tue, 28 May 2019 18:38:48 +0200,
> > > Jaroslav Kysela wrote:
> > >>
> > >> Dne 28. 05. 19 v 16:54 Takashi Iwai napsal(a):
> > >>> Hi,
> > >>>
> > >>> it seems that Connor's previous attempt to put a couple of ca0132
> > >>> firmware files into linux-firmware tree didn't go through,
> > >>> unfortunately.  And now I'm thinking of taking them into alsa-firmware
> > >>> package as a stop-gap.  We already distribute other ca0132 firmware
> > >>> files, so the addition shouldn't be a big problem.
> > >>>
> > >>> Jaroslav, what do you think?
> > >>
> > >> No problem. The same situation is for the SoC SOF firmware files (drivers are
> > >> in kernel, firmware files are missing). Perhaps, we can release those files
> > >> quickly in alsa-firmware and then migrate them slowly to linux-firmware.
> > >
> > > OK, now pushed to alsa-firmware git repo.
> > >
> > > BTW, the situation is slightly different from SOF.  At this time, the
> > > problem was that it's been submitted by a third person.
> >
> > Ok, so we don't have a licence for those files? Connor, have you tried to
> > contact Creative for a permission to use/distribute those files?
> >
> >                                                 Jaroslav
> >
> > --
> > Jaroslav Kysela <perex@perex.cz>
> > Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
> 

Re: Merging the new firmware files for CA0132 into alsa-firmware

[Jaroslav Kysela]

Dne 28. 05. 19 v 21:37 Takashi Iwai napsal(a):
> On Tue, 28 May 2019 21:24:39 +0200,
> Connor McAdams wrote:
>>
>> Yes, I did end up getting permission from Creative themselves to
>> redistribute the files. That was back in November of 2018.
>>
>> I also asked them to email Takashi Iwai to confirm, which I think they
>> ended up doing.
>>
>> My contact within Creative has not responded since December of 2018,
>> when I asked for a name to go with the email he told me to use for the
>> sign-off, and I think that was why the Linux firmware people weren't
>> willing to accept it.
> 
> Right, basically these two files align with the already existing other
> ca0132 firmware files in the repo.  But the problem was just that the
> submitter was the third person, which is quite unusual.

Ok, thanks. It might make sense to indicate this in the commit message
(clarify the licence - use forced push, if you like).

					Jaroslav

> 
> 
> Takashi
> 
>>
>> If you need any more information, let me know.
>>
>> On Tue, May 28, 2019 at 3:19 PM Jaroslav Kysela <perex@perex.cz> wrote:
>>>
>>> Dne 28. 05. 19 v 19:47 Takashi Iwai napsal(a):
>>>> On Tue, 28 May 2019 18:38:48 +0200,
>>>> Jaroslav Kysela wrote:
>>>>>
>>>>> Dne 28. 05. 19 v 16:54 Takashi Iwai napsal(a):
>>>>>> Hi,
>>>>>>
>>>>>> it seems that Connor's previous attempt to put a couple of ca0132
>>>>>> firmware files into linux-firmware tree didn't go through,
>>>>>> unfortunately.  And now I'm thinking of taking them into alsa-firmware
>>>>>> package as a stop-gap.  We already distribute other ca0132 firmware
>>>>>> files, so the addition shouldn't be a big problem.
>>>>>>
>>>>>> Jaroslav, what do you think?
>>>>>
>>>>> No problem. The same situation is for the SoC SOF firmware files (drivers are
>>>>> in kernel, firmware files are missing). Perhaps, we can release those files
>>>>> quickly in alsa-firmware and then migrate them slowly to linux-firmware.
>>>>
>>>> OK, now pushed to alsa-firmware git repo.
>>>>
>>>> BTW, the situation is slightly different from SOF.  At this time, the
>>>> problem was that it's been submitted by a third person.
>>>
>>> Ok, so we don't have a licence for those files? Connor, have you tried to
>>> contact Creative for a permission to use/distribute those files?
>>>
>>>                                                 Jaroslav
>>>
>>> --
>>> Jaroslav Kysela <perex@perex.cz>
>>> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
>>


-- 
Jaroslav Kysela <perex@perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

Re: Merging the new firmware files for CA0132 into alsa-firmware

[Takashi Iwai]

On Tue, 28 May 2019 21:46:35 +0200,
Jaroslav Kysela wrote:
> 
> Dne 28. 05. 19 v 21:37 Takashi Iwai napsal(a):
> > On Tue, 28 May 2019 21:24:39 +0200,
> > Connor McAdams wrote:
> >>
> >> Yes, I did end up getting permission from Creative themselves to
> >> redistribute the files. That was back in November of 2018.
> >>
> >> I also asked them to email Takashi Iwai to confirm, which I think they
> >> ended up doing.
> >>
> >> My contact within Creative has not responded since December of 2018,
> >> when I asked for a name to go with the email he told me to use for the
> >> sign-off, and I think that was why the Linux firmware people weren't
> >> willing to accept it.
> > 
> > Right, basically these two files align with the already existing other
> > ca0132 firmware files in the repo.  But the problem was just that the
> > submitter was the third person, which is quite unusual.
> 
> Ok, thanks. It might make sense to indicate this in the commit message
> (clarify the licence - use forced push, if you like).

OK, done.


thanks,

Takashi