mbox series

[RFC,0/8] PCI: Define Intel PCI IDs and use them in drivers

Message ID 20230628205135.517241-1-amadeuszx.slawinski@linux.intel.com
Headers
Series PCI: Define Intel PCI IDs and use them in drivers |

Message

Amadeusz Sławiński June 28, 2023, 8:51 p.m. UTC 
  PCI IDs for Intel HDA are duplicated across quite a few drivers, due to
various configurations and historical reasons. Currently almost all uses
of HDA PCI IDs have corresponding comment telling which platform it is.
Additionally there are some inconsistencies between drivers about which
ID corresponds to which device.

Simplify things, by adding PCI IDs to global header and make use of them
in drivers. This allows for removal of comments by having IDs themselves
being self explanatory. Additionally it allows for removal of existing
inconsistencies by having one source of truth.

Amadeusz Sławiński (8):
  PCI: Add Intel Audio DSP devices to pci_ids.h
  ALSA: intel-dsp-config: Update PCI ID list
  ALSA: hda: Update PCI ID list
  ALSA: hda/i915: Update PCI IDs
  ASoC: Intel: avs: Update PCI ID list
  ASoC: Intel: avs: Update PCI ID list
  ASoC: Intel: Skylake: Update PCI ID list
  ASoC: SOF: Intel: Update PCI ID list

 include/linux/pci_ids.h                |  44 ++++
 sound/hda/hdac_i915.c                  |   8 +-
 sound/hda/intel-dsp-config.c           | 119 +++++-----
 sound/pci/hda/hda_intel.c              | 292 ++++++++++++-------------
 sound/soc/intel/avs/board_selection.c  |  10 +-
 sound/soc/intel/avs/core.c             |  16 +-
 sound/soc/intel/skylake/skl-messages.c |  16 +-
 sound/soc/intel/skylake/skl.c          |  36 +--
 sound/soc/sof/intel/pci-apl.c          |   9 +-
 sound/soc/sof/intel/pci-cnl.c          |  15 +-
 sound/soc/sof/intel/pci-icl.c          |  12 +-
 sound/soc/sof/intel/pci-mtl.c          |   3 +-
 sound/soc/sof/intel/pci-skl.c          |   6 +-
 sound/soc/sof/intel/pci-tgl.c          |  45 ++--
 sound/soc/sof/intel/pci-tng.c          |   3 +-
 15 files changed, 311 insertions(+), 323 deletions(-)

Comments

Mark Brown June 28, 2023, 1 p.m. UTC | #1 
On Wed, Jun 28, 2023 at 10:51:27PM +0200, Amadeusz Sławiński wrote:
> PCI IDs for Intel HDA are duplicated across quite a few drivers, due to
> various configurations and historical reasons. Currently almost all uses
> of HDA PCI IDs have corresponding comment telling which platform it is.
> Additionally there are some inconsistencies between drivers about which
> ID corresponds to which device.

Acked-by: Mark Brown <broonie@kernel.org>
Andy Shevchenko June 28, 2023, 2:49 p.m. UTC | #2 
On Wed, Jun 28, 2023 at 10:51:27PM +0200, Amadeusz Sławiński wrote:
> PCI IDs for Intel HDA are duplicated across quite a few drivers, due to
> various configurations and historical reasons. Currently almost all uses
> of HDA PCI IDs have corresponding comment telling which platform it is.
> Additionally there are some inconsistencies between drivers about which
> ID corresponds to which device.
> 
> Simplify things, by adding PCI IDs to global header and make use of them
> in drivers. This allows for removal of comments by having IDs themselves
> being self explanatory. Additionally it allows for removal of existing
> inconsistencies by having one source of truth.

I'm in favour of this series. It allows to use PCI_DEVICE_DATA() in many places.
With that said, I think you can also add some more definitions to PCI IDs header
for the sake of being able to use that macro.
Pierre-Louis Bossart June 28, 2023, 3:57 p.m. UTC | #3 
On 6/28/23 16:49, Andy Shevchenko wrote:
> On Wed, Jun 28, 2023 at 10:51:27PM +0200, Amadeusz Sławiński wrote:
>> PCI IDs for Intel HDA are duplicated across quite a few drivers, due to
>> various configurations and historical reasons. Currently almost all uses
>> of HDA PCI IDs have corresponding comment telling which platform it is.
>> Additionally there are some inconsistencies between drivers about which
>> ID corresponds to which device.
>>
>> Simplify things, by adding PCI IDs to global header and make use of them
>> in drivers. This allows for removal of comments by having IDs themselves
>> being self explanatory. Additionally it allows for removal of existing
>> inconsistencies by having one source of truth.
> 
> I'm in favour of this series. It allows to use PCI_DEVICE_DATA() in many places.
> With that said, I think you can also add some more definitions to PCI IDs header
> for the sake of being able to use that macro.

I don't have any objections on the change.

The big open is how we add new definitions without a 3-way deadlock
between PCI, sound and ASoC trees, and how those definitions can be
added to the -stable trees.

This isn't an hypothetical case, we have 2 pending submissions for
LunarLake [1] and ArrowLake [2] which will be provided as soon as the
merge window closes.

It's not clear to me if Bjorn is ok to let those audio-specific PCI IDs
go the audio trees, and how things would work between Mark and Takashi.

[1] https://github.com/thesofproject/linux/pull/4425
[2] https://github.com/thesofproject/linux/pull/4437