On 2019-08-27 17:00, Pierre-Louis Bossart wrote:
On the second thought what if instead of duplicating kernel
code, binaries would be duplicated?
I.e. rather than targeting /intel/dsp_fw_cnl.bin, _new_
/skylake would be expecting /intel/dsp_fw_cnl_release.bin? Same
with topology binaries.
In such case, we "only" need to figure out how to propagate new
files to Linux distos so whenever someone updates their kernel,
new binaries are already present in their /lib/firmware.
If such option is valid, we can postpone /skylake upgrade till
5.4 merging window closes and the patches (rough estimation is
150) would descend upon alsa-devel in time between 5.4 and 5.5.
If the driver and FW update will be within the same kernel
release then IMHO
there should be no compatibility problem between those two
components, right?
This way kernel users willing to stick to old FW can stay on
older kernel version while
others can update and receive all the latest FW functionality
that was developed and enabled.
I am not comfortable with precluding a kernel update because of a
single firmware file. There are all sort of reasons for updating
a kernel, security, sideband attacks and Android CDD
compatibility being the most obvious ones.
The single firmware file will not be a blocker as the driver
included in updated kernel will support it.
All you have to do is the little effort to re-generate your custom
topology for the new firmware target.
The entire operation should not be a problem as there are dedicated
utilities like FDK to do that.
The issue is the same whether it's a topology file or a firmware
file. The ideal situation is that when the kernel is updated it
handles both in backwards compatible ways.
If to deal with a new firmware file you have to regenerate a new
topology, you are in a different model altogether.
Your statement Pierre suggest that everyone should avoid any
functional changes in kernel
that are not critical because that would be problematic for others
who switch from older kernel version.
All I said was that you cannot assume that people who are using an
old firmware/driver will remain on an old kernel.
Mark made an initial proposal to essentially freeze the current
solution, which would make it possible to update the kernel but keep
the same skylake driver in legacy/maintenance mode only, and an 'new'
option that would rely on an updated distribution of firmware/driver.
I did not get the counter proposal from Cezary at all.
Ain't my previous message:
-
On the second thought what if instead of duplicating kernel code,
binaries would be duplicated?
I.e. rather than targeting /intel/dsp_fw_cnl.bin, _new_ /skylake would
be expecting /intel/dsp_fw_cnl_release.bin? Same with topology binaries.
In such case, we "only" need to figure out how to propagate new files
to Linux distos so whenever someone updates their kernel, new binaries
are already present in their /lib/firmware.
If such option is valid, we can postpone /skylake upgrade till 5.4
merging window closes and the patches (rough estimation is 150) would
descend upon alsa-devel in time between 5.4 and 5.5.
-
a counter proposal?
you didn't explain how the 'duplicated binaries' would be selected. And
'instead of' means you suggested an alternative to Mark's proposal.
What I have in mind:
We leave the old stuff as is, e.g:
/lib/firmware/intel/dsp_fw_cnl.bin -> points to _old_ FW binaries
/lib/firmware/<PCI-ID>-INTEL-<oem_data_from_NHLT -> points to old topology
Existing /skylake i.e. before our initialization refactor would (kernels
<5.5?) would still point to these and since they are not being removed
from linux-firmware, nothing gets broken.
And then we "duplicate" and simply append the new ones:
/lib/firmware/intel/dsp_fw_cnl_release.bin -> points to _new_ FW
/lib/firmware/dfw_cnl_rt274 -> points to _new_ topology
Updated /skylake would simply expect the _new_ files and totally ignore
the old ones i.e.: descriptors would be pointing to dsp_fw_cnl_release
and dfw_cnl_rt274.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
