On 12/16/21 8:37 AM, Cezary Rojewski wrote:
On 2021-12-16 3:11 PM, Pierre-Louis Bossart wrote:
The intent of soc-acpi files is to establish a match between ACPI _HID and machine driver, this is now duplicated, and it makes limited sense to add machine driver dependencies in a platform driver.
Nothing was broken with the existing code.
Hello,
Yes, nothing is broken in the existing code. The intention is different
- be cohesive about what is actually used by the driver.
PCI-ids table is duplicated already for the Intel audio drivers. And it's OK to do so - one knows which ids are covered by given driver and how. Here, it's clear that haswell_machines are only used by catpt-driver and so are some fields for broadwell_machines. In time I believe that we will be able to reduce the number of fields for struct snd_soc_acpi_mach i.e. have a single fw_filename and single tplg_filename field without some driver-specific duplicates.
I don't really see the point about the number of fields, this is a generic descriptor used for I2S/SoundWire devices so mechanically there are things are are not used in all platforms.
Another example is the quirks field, it's only meant to be used when there's actually a quirk.
Note that I am planning to remove the sof_fw_filename field since it's redundant with what is part of the PCI descriptor, but the topology will remain there: it has to match with the machine driver.
About the last, there could be a case where no topology file is available for certain configuration and given entry should not be taken into account. While catpt-driver does not make use of soc-topology feature, that isn't true for other drivers.
Again if a feature is not needed/not supported, the field can remain empty.