| Message ID | 20230802150105.24604-2-pierre-louis.bossart@linux.intel.com |
|---|---|
| State | New |
| Headers | show |
| Series | ALSA/PCI: hda: add ARL-S support, config for MTL/LNL | expand |
On Wed, Aug 02, 2023 at 10:01:01AM -0500, Pierre-Louis Bossart wrote: > Add part ID to common include file Please drop period at end of subject and add one at the end of the commit log. Also mention the drivers that will use this new #define; looks like hda_intel.c and ... Well, actually, I only see that one use, which means we probably shouldn't add this #define to pci_ids.h, per the comment at the top of the file. If there's only one use, use the hex ID in the driver (or add a #define in the driver itself). > Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> > Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> > Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> > --- > include/linux/pci_ids.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h > index 3066660cd39b..a6411aa4c331 100644 > --- a/include/linux/pci_ids.h > +++ b/include/linux/pci_ids.h > @@ -3058,6 +3058,7 @@ > #define PCI_DEVICE_ID_INTEL_HDA_RPL_S 0x7a50 > #define PCI_DEVICE_ID_INTEL_HDA_ADL_S 0x7ad0 > #define PCI_DEVICE_ID_INTEL_HDA_MTL 0x7e28 > +#define PCI_DEVICE_ID_INTEL_HDA_ARL_S 0x7f50 > #define PCI_DEVICE_ID_INTEL_SCH_LPC 0x8119 > #define PCI_DEVICE_ID_INTEL_SCH_IDE 0x811a > #define PCI_DEVICE_ID_INTEL_HDA_POULSBO 0x811b > -- > 2.39.2 >
On Wed, 02 Aug 2023 17:52:26 +0200, Bjorn Helgaas wrote: > > On Wed, Aug 02, 2023 at 10:01:01AM -0500, Pierre-Louis Bossart wrote: > > Add part ID to common include file > > Please drop period at end of subject and add one at the end of the > commit log. > > Also mention the drivers that will use this new #define; looks like > hda_intel.c and ... > > Well, actually, I only see that one use, which means we probably > shouldn't add this #define to pci_ids.h, per the comment at the top of > the file. If there's only one use, use the hex ID in the driver (or > add a #define in the driver itself). Judging from the previous patterns, the same ID could be required for ASoC SOF driver, too, which isn't included in this patch set. In that case, it's worth to put to pci_ids.h. (OTOH, it can be done at a later stage, too.) thanks, Takashi
On 8/2/23 10:57, Takashi Iwai wrote: > On Wed, 02 Aug 2023 17:52:26 +0200, > Bjorn Helgaas wrote: >> >> On Wed, Aug 02, 2023 at 10:01:01AM -0500, Pierre-Louis Bossart wrote: >>> Add part ID to common include file >> >> Please drop period at end of subject and add one at the end of the >> commit log. >> >> Also mention the drivers that will use this new #define; looks like >> hda_intel.c and ... >> >> Well, actually, I only see that one use, which means we probably >> shouldn't add this #define to pci_ids.h, per the comment at the top of >> the file. If there's only one use, use the hex ID in the driver (or >> add a #define in the driver itself). > > Judging from the previous patterns, the same ID could be required for > ASoC SOF driver, too, which isn't included in this patch set. In > that case, it's worth to put to pci_ids.h. > (OTOH, it can be done at a later stage, too.) I am not following. we just agreed a couple of weeks ago to record ALL Intel/HDaudio PCI IDs in the same pci_ids.h include file. ArrowLake-S is the first addition to first file after the work done by Cezary/Amadeusz. Yes it's required to be added since it'll be used in other parts later on. But even if there was ONE use of this PCI ID, why would we not add it for consistency to the global pci_ids.h file? Takashi's hda_intel.c file would look really bad if we have a mix of single-use PCIs and shared ones... Oh and heads-up that I have a change for LunarLake that will require Mark to pull the branch from Takashi :-)
On Wed, Aug 02, 2023 at 11:07:36AM -0500, Pierre-Louis Bossart wrote: > On 8/2/23 10:57, Takashi Iwai wrote: > > On Wed, 02 Aug 2023 17:52:26 +0200, > > Bjorn Helgaas wrote: > >> On Wed, Aug 02, 2023 at 10:01:01AM -0500, Pierre-Louis Bossart wrote: > >>> Add part ID to common include file > >> > >> Please drop period at end of subject and add one at the end of the > >> commit log. > >> > >> Also mention the drivers that will use this new #define; looks like > >> hda_intel.c and ... > >> > >> Well, actually, I only see that one use, which means we probably > >> shouldn't add this #define to pci_ids.h, per the comment at the top of > >> the file. If there's only one use, use the hex ID in the driver (or > >> add a #define in the driver itself). > > > > Judging from the previous patterns, the same ID could be required for > > ASoC SOF driver, too, which isn't included in this patch set. In > > that case, it's worth to put to pci_ids.h. > > (OTOH, it can be done at a later stage, too.) When it becomes shared is the standard point at which we add to pci_ids.h. > I am not following. we just agreed a couple of weeks ago to record ALL > Intel/HDaudio PCI IDs in the same pci_ids.h include file. I'm not sure who "we" is here. If it included me and I signed up to it, I apologize for forgetting, and go ahead and add my: Acked-by: Bjorn Helgaas <bhelgaas@google.com> I'm just pointing out the usual practice for pci_ids.h, as mentioned in the file itself. > ArrowLake-S is the first addition to first file after the work done by > Cezary/Amadeusz. Yes it's required to be added since it'll be used in > other parts later on. But even if there was ONE use of this PCI ID, why > would we not add it for consistency to the global pci_ids.h file? > Takashi's hda_intel.c file would look really bad if we have a mix of > single-use PCIs and shared ones... We already have a mix: static const struct pci_device_id azx_ids[] = { /* CPT */ { PCI_DEVICE(0x8086, 0x1c20), .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH_NOPM }, /* PBG */ { PCI_DEVICE(0x8086, 0x1d20), .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_PCH_NOPM }, /* Panther Point */ I think the reason we don't add names used only once is because it makes backporting things harder because it leads to more merge conflicts in pci_ids.h. Bjorn
On Wed, Aug 02, 2023 at 11:25:41AM -0500, Bjorn Helgaas wrote: > On Wed, Aug 02, 2023 at 11:07:36AM -0500, Pierre-Louis Bossart wrote: > > I am not following. we just agreed a couple of weeks ago to record ALL > > Intel/HDaudio PCI IDs in the same pci_ids.h include file. > I'm not sure who "we" is here. If it included me and I signed up to > it, I apologize for forgetting, and go ahead and add my: > Acked-by: Bjorn Helgaas <bhelgaas@google.com> > I'm just pointing out the usual practice for pci_ids.h, as mentioned > in the file itself. I think the thing with these drivers is that we know they will become shared in fairly short order so it just becomes overhead to add then move the identifier and update.
On 8/2/23 11:34, Mark Brown wrote: > On Wed, Aug 02, 2023 at 11:25:41AM -0500, Bjorn Helgaas wrote: >> On Wed, Aug 02, 2023 at 11:07:36AM -0500, Pierre-Louis Bossart wrote: > >>> I am not following. we just agreed a couple of weeks ago to record ALL >>> Intel/HDaudio PCI IDs in the same pci_ids.h include file. > >> I'm not sure who "we" is here. If it included me and I signed up to >> it, I apologize for forgetting, and go ahead and add my: > >> Acked-by: Bjorn Helgaas <bhelgaas@google.com> This was the original thread for the record https://lore.kernel.org/alsa-devel/20230717114511.484999-3-amadeuszx.slawinski@linux.intel.com/ >> I'm just pointing out the usual practice for pci_ids.h, as mentioned >> in the file itself. You're actually right that we didn't talk about the minimum criterion to add a PCI ID to this file. To me it was a central place similar to the cpu ids, etc., if it wasn't clear to everyone than it's good to agree on this second point. > I think the thing with these drivers is that we know they will become > shared in fairly short order so it just becomes overhead to add then > move the identifier and update. Indeed, the sharing part is not always predictable and is subject to roadmap changes made above my pay grade. The intended use of the devices can vary as well, some PCI IDs for desktops are intended to be used only by snd-hda-intel, but if one OEM starts adding digital microphones then the SOF driver becomes required. So rather than force everyone to follow changes at Intel or Intel customers it's simpler to just add PCI IDs in pci_ids.h. We typically deal with 3-4 PCI IDS per year
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index 3066660cd39b..a6411aa4c331 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -3058,6 +3058,7 @@ #define PCI_DEVICE_ID_INTEL_HDA_RPL_S 0x7a50 #define PCI_DEVICE_ID_INTEL_HDA_ADL_S 0x7ad0 #define PCI_DEVICE_ID_INTEL_HDA_MTL 0x7e28 +#define PCI_DEVICE_ID_INTEL_HDA_ARL_S 0x7f50 #define PCI_DEVICE_ID_INTEL_SCH_LPC 0x8119 #define PCI_DEVICE_ID_INTEL_SCH_IDE 0x811a #define PCI_DEVICE_ID_INTEL_HDA_POULSBO 0x811b