| Message ID | 20250404094953.3657679-1-cezary.rojewski@intel.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | ASoC: Intel: avs: Add support for MTL-FCL platforms | expand |
On Fri, 2025-04-04 at 11:49 +0200, Cezary Rojewski wrote: > Cezary Rojewski (11): > ALSA: hda: Allow to fetch hlink by ID > ASoC: Intel: avs: Ignore Vendor-space manipulation for ACE > ASoC: Intel: avs: Read HW capabilities when possible > ASoC: Intel: avs: Relocate DSP status registers > ASoC: Intel: avs: MTL-based platforms support > ASoC: Intel: avs: LNL-based platforms support > ASoC: Intel: avs: PTL-based platforms support > ASoC: Intel: avs: PCM operations for LNL-based platforms > Sorry - AVS is not officially supported for MTL, LNL and PTL on Linux. NAK. The rest is fine. Liam
On 2025-04-04 2:52 PM, Girdwood, Liam R wrote: > On Fri, 2025-04-04 at 11:49 +0200, Cezary Rojewski wrote: >> Cezary Rojewski (11): >> ALSA: hda: Allow to fetch hlink by ID >> ASoC: Intel: avs: Ignore Vendor-space manipulation for ACE >> ASoC: Intel: avs: Read HW capabilities when possible >> ASoC: Intel: avs: Relocate DSP status registers >> ASoC: Intel: avs: MTL-based platforms support >> ASoC: Intel: avs: LNL-based platforms support >> ASoC: Intel: avs: PTL-based platforms support >> ASoC: Intel: avs: PCM operations for LNL-based platforms >> > Sorry - AVS is not officially supported for MTL, LNL and PTL on Linux. > > NAK. FCL is a PTL-A, PTL-based platform. The driver is officially supported on the ACE architecture with clients utilizing it on distributions such as Android and Yocto. As software needs little to no changes to cover PTL alone it is preferable to have clear division: ace1.0 <- ace2.0 <- ace3.0. The code is maintainable and readable this way. And then we have validation point. intel-dsp-config remains intact (no selection changes for MTL/LNL) but still leaves window for the AVS-validation to have high code coverage. Unless you can bring technical arguments, 'NAK' does not apply. The requirements for the project state clearly - upstream the code for the architectures we do support. Kind regards, Czarek
On Fri, 2025-04-04 at 15:09 +0200, Cezary Rojewski wrote: > On 2025-04-04 2:52 PM, Girdwood, Liam R wrote: > > On Fri, 2025-04-04 at 11:49 +0200, Cezary Rojewski wrote: > > > Cezary Rojewski (11): > > > ALSA: hda: Allow to fetch hlink by ID > > > ASoC: Intel: avs: Ignore Vendor-space manipulation for ACE > > > ASoC: Intel: avs: Read HW capabilities when possible > > > ASoC: Intel: avs: Relocate DSP status registers > > > ASoC: Intel: avs: MTL-based platforms support > > > ASoC: Intel: avs: LNL-based platforms support > > > ASoC: Intel: avs: PTL-based platforms support > > > ASoC: Intel: avs: PCM operations for LNL-based platforms > > > > > Sorry - AVS is not officially supported for MTL, LNL and PTL on > > Linux. > > > > NAK. > > > FCL is a PTL-A, PTL-based platform. The driver is officially > supported > on the ACE architecture with clients utilizing it on distributions > such > as Android and Yocto. As software needs little to no changes to cover > PTL alone it is preferable to have clear division: ace1.0 <- ace2.0 > <- > ace3.0. The code is maintainable and readable this way. No argument with FCL or any non client devices. If you do need to support IP versions, then use the correct non client product name and PCI IDs. Don't confuse users and claim client device names or IDs that you have no way to support. > > And then we have validation point. intel-dsp-config remains intact > (no > selection changes for MTL/LNL) but still leaves window for the > AVS-validation to have high code coverage. So this is for internal IP testing reasons and its best to carry these out of tree like everyone else does. > > Unless you can bring technical arguments, 'NAK' does not apply. The > requirements for the project state clearly - upstream the code for > the > architectures we do support. > Sorry, we have not even crossed the threshold for a technical argument, this is an unsupported driver and an unsupported FW for these devices on Linux. Period. The SOF FW and driver is the supported driver and FW for these devices on Linux. Please do point me internally to where AVS is plan of record for Linux client MTL, LNL and PTL and I will approve. Thanks Liam > > Kind regards, > Czarek
On 2025-04-04 3:28 PM, Girdwood, Liam R wrote: > On Fri, 2025-04-04 at 15:09 +0200, Cezary Rojewski wrote: >> On 2025-04-04 2:52 PM, Girdwood, Liam R wrote: >>> On Fri, 2025-04-04 at 11:49 +0200, Cezary Rojewski wrote: >>>> Cezary Rojewski (11): >>>> ALSA: hda: Allow to fetch hlink by ID >>>> ASoC: Intel: avs: Ignore Vendor-space manipulation for ACE >>>> ASoC: Intel: avs: Read HW capabilities when possible >>>> ASoC: Intel: avs: Relocate DSP status registers >>>> ASoC: Intel: avs: MTL-based platforms support >>>> ASoC: Intel: avs: LNL-based platforms support >>>> ASoC: Intel: avs: PTL-based platforms support >>>> ASoC: Intel: avs: PCM operations for LNL-based platforms >>>> >>> Sorry - AVS is not officially supported for MTL, LNL and PTL on >>> Linux. >>> >>> NAK. >> >> >> FCL is a PTL-A, PTL-based platform. The driver is officially >> supported >> on the ACE architecture with clients utilizing it on distributions >> such >> as Android and Yocto. As software needs little to no changes to cover >> PTL alone it is preferable to have clear division: ace1.0 <- ace2.0 >> <- >> ace3.0. The code is maintainable and readable this way. > > No argument with FCL or any non client devices. I see. So we're talking about pci_ids and their attached descriptors, and _not_ removing the functional code that enables avs-driver on ACE architecture? The filenames/prefixes shall remain as-is given the driver's design - platform that starts given arch, becomes its namesake. Kind regards, Czarek
On Mon, 2025-04-07 at 10:04 +0200, Cezary Rojewski wrote: > On 2025-04-04 3:28 PM, Girdwood, Liam R wrote: > > On Fri, 2025-04-04 at 15:09 +0200, Cezary Rojewski wrote: > > > On 2025-04-04 2:52 PM, Girdwood, Liam R wrote: > > > > On Fri, 2025-04-04 at 11:49 +0200, Cezary Rojewski wrote: > > > > > Cezary Rojewski (11): > > > > > ALSA: hda: Allow to fetch hlink by ID > > > > > ASoC: Intel: avs: Ignore Vendor-space manipulation for > > > > > ACE > > > > > ASoC: Intel: avs: Read HW capabilities when possible > > > > > ASoC: Intel: avs: Relocate DSP status registers > > > > > ASoC: Intel: avs: MTL-based platforms support > > > > > ASoC: Intel: avs: LNL-based platforms support > > > > > ASoC: Intel: avs: PTL-based platforms support > > > > > ASoC: Intel: avs: PCM operations for LNL-based platforms > > > > > > > > > Sorry - AVS is not officially supported for MTL, LNL and PTL on > > > > Linux. > > > > > > > > NAK. > > > > > > > > > FCL is a PTL-A, PTL-based platform. The driver is officially > > > supported > > > on the ACE architecture with clients utilizing it on > > > distributions > > > such > > > as Android and Yocto. As software needs little to no changes to > > > cover > > > PTL alone it is preferable to have clear division: ace1.0 <- > > > ace2.0 > > > <- > > > ace3.0. The code is maintainable and readable this way. > > > > No argument with FCL or any non client devices. > > I see. So we're talking about pci_ids and their attached descriptors, > and _not_ removing the functional code that enables avs-driver on ACE > architecture? Yes, lets not cause any confusion with duplicated IDs or product names across different drivers. Not removing any AVS code :) > > The filenames/prefixes shall remain as-is given the driver's design - > platform that starts given arch, becomes its namesake. > No issue if you want to rename any IP code filename to e.g. ACE2 instead of LNL as this makes it obvious for anyone reading the code and you can add my Ack to that if wanted. Thanks Liam > Kind regards, > Czarek
On 2025-04-07 11:36 AM, Girdwood, Liam R wrote: > On Mon, 2025-04-07 at 10:04 +0200, Cezary Rojewski wrote: >>>> FCL is a PTL-A, PTL-based platform. The driver is officially >>>> supported >>>> on the ACE architecture with clients utilizing it on >>>> distributions >>>> such >>>> as Android and Yocto. As software needs little to no changes to >>>> cover >>>> PTL alone it is preferable to have clear division: ace1.0 <- >>>> ace2.0 >>>> <- >>>> ace3.0. The code is maintainable and readable this way. >>> >>> No argument with FCL or any non client devices. >> >> I see. So we're talking about pci_ids and their attached descriptors, >> and _not_ removing the functional code that enables avs-driver on ACE >> architecture? > > Yes, lets not cause any confusion with duplicated IDs or product names > across different drivers. Not removing any AVS code :) Ack. >> >> The filenames/prefixes shall remain as-is given the driver's design - >> platform that starts given arch, becomes its namesake. >> > > No issue if you want to rename any IP code filename to e.g. ACE2 > instead of LNL as this makes it obvious for anyone reading the code and > you can add my Ack to that if wanted. I opted out of cavs15, cavs25, avs10 (just few examples but I bet the idea is visible) long time ago due to Pierre's feedback. Suggestion was: it is easier for the non-Intel people to understand the "architecture" concept for Intel AudioDSP if it's tied to platform name. As all the files within the avs/ folder follow that scheme now, I'm not keen going against that pattern now. I can 3 commits adding mtl.c, lnl.c and ptl.c into a single commit, drop the pci_ids and their contexts so it aligns with your comment about leaving out the confusion. Does that suffice? Kind regards, Czarek
On Mon, 2025-04-07 at 11:45 +0200, Cezary Rojewski wrote: > I can 3 commits adding mtl.c, lnl.c and ptl.c into a single commit, > drop > the pci_ids and their contexts so it aligns with your comment about > leaving out the confusion. Does that suffice? Yes. Thanks Liam