All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: "Amadeusz Sławiński" <amadeuszx.slawinski@linux.intel.com>,
	"Mark Brown" <broonie@kernel.org>,
	"Cezary Rojewski" <cezary.rojewski@intel.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
	alsa-devel@alsa-project.org, Takashi Iwai <tiwai@suse.com>,
	kernel test robot <lkp@intel.com>
Subject: Re: [PATCH] ASoC: Intel: avs: Depend on CONFIG_ACPI
Date: Tue, 26 Apr 2022 14:16:33 -0500	[thread overview]
Message-ID: <04d652ae-60df-88ad-518f-bbcedc0f1de3@linux.intel.com> (raw)
In-Reply-To: <54e21f85-ecbe-2a88-0557-0f810b45f1eb@linux.intel.com>



On 4/26/22 14:07, Amadeusz Sławiński wrote:
> On 4/26/2022 8:26 PM, Pierre-Louis Bossart wrote:
>>
>>
>> On 4/26/22 13:25, Mark Brown wrote:
>>> On Tue, Apr 26, 2022 at 08:07:22PM +0200, Cezary Rojewski wrote:
>>>
>>>> Would you like the change proposed by Pierre to be part of this patch or a
>>>> separate one?
>>>
>>> Either is fine.
>>>
>>>> Also, I assume the above code does not change, just:
>>>> s/select SND_SOC_ACPI/select SND_SOC_ACPI if ACPI/
>>>
>>>> is applied on top of what's already in the patch. Is my deduction correct?
>>>
>>> AIUI the current patch and associated hard dependency on ACPI could be
>>> dropped but I've not checked or thought too deeply about it
>>
>>
>> my suggestion was the following:
>>
>> depends on PCI
>> depends on COMMON_CLK
>> select SND_SOC_ACPI if ACPI
> 
> Thanks for suggestion, I tested with it, but it doesn't work as we access fields from struct nhlt_specific_cfg which is available only if ACPI support is enabled:
> 
> sound/soc/intel/avs/path.c: In function ‘avs_copier_create’:
> sound/soc/intel/avs/path.c:186:17: error: ‘struct nhlt_specific_cfg’ has no member named ‘caps’
>   186 |   data = ep_blob->caps;
>       |                 ^~
> sound/soc/intel/avs/path.c:187:22: error: ‘struct nhlt_specific_cfg’ has no member named ‘size’
>   187 |   data_size = ep_blob->size;
>       |                      ^~
> sound/soc/intel/avs/path.c:210:17: error: ‘struct nhlt_specific_cfg’ has no member named ‘caps’
>   210 |   data = ep_blob->caps;
>       |                 ^~
> sound/soc/intel/avs/path.c:211:22: error: ‘struct nhlt_specific_cfg’ has no member named ‘size’
>   211 |   data_size = ep_blob->size;
>       |                      ^~
> 
> Now there are few ways this can be solved:
> 1. Move the struct nhlt_specific_cfg definition out of define check... in include/sound/intel-nhlt.h, but that seems kind of sloppy to me, even if it makes sense.

That would be my preference. There's no real reason to hide those definitions that are pure C, and only have some enums exposed and others not.


diff --git a/include/sound/intel-nhlt.h b/include/sound/intel-nhlt.h

index 6fb2d5e378fdd..340584d9515f4 100644

--- a/include/sound/intel-nhlt.h

+++ b/include/sound/intel-nhlt.h

@@ -25,8 +25,6 @@ enum nhlt_device_type {

        NHLT_DEVICE_INVALID

 };

 

-#if IS_ENABLED(CONFIG_ACPI) && IS_ENABLED(CONFIG_SND_INTEL_NHLT)

-

 struct wav_fmt {

        u16 fmt_tag;

        u16 channels;

@@ -126,6 +124,8 @@ enum {

        NHLT_MIC_ARRAY_VENDOR_DEFINED = 0xf,

 };

 

+#if IS_ENABLED(CONFIG_ACPI) && IS_ENABLED(CONFIG_SND_INTEL_NHLT)

+

 struct nhlt_acpi_table *intel_nhlt_init(struct device *dev);

 

 void intel_nhlt_free(struct nhlt_acpi_table *addr);



> 2. NHLT is only needed for I2S and DMIC configuration, so we could in theory add #ifdef ACPI around configuration for those endpoints in sound/soc/intel/avs/path.c - but it introduces potential problems on x86 platforms with users doing some weird config.
> 3. Depend directly on ACPI (current patch) causing NHLT support to be always enabled. And then apply change suggested by Pierre when we rewrite NHLT support to use NHLT structures in include/acpi/actbl2.h header as it as far as I can tell exposes all structures unconditionally.
> 
> I've discussed with Cezary and we are leaning towards option 3. but if there is any other preference we can prepare patch for that option.


      reply	other threads:[~2022-04-26 19:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-26 11:54 [PATCH] ASoC: Intel: avs: Depend on CONFIG_ACPI Amadeusz Sławiński
2022-04-26 13:33 ` Pierre-Louis Bossart
2022-04-26 17:08   ` Mark Brown
2022-04-26 18:07     ` Cezary Rojewski
2022-04-26 18:25       ` Mark Brown
2022-04-26 18:26         ` Pierre-Louis Bossart
2022-04-26 18:38           ` Mark Brown
2022-04-26 18:42             ` Pierre-Louis Bossart
2022-04-26 19:07           ` Amadeusz Sławiński
2022-04-26 19:16             ` Pierre-Louis Bossart [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=04d652ae-60df-88ad-518f-bbcedc0f1de3@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=amadeuszx.slawinski@linux.intel.com \
    --cc=broonie@kernel.org \
    --cc=cezary.rojewski@intel.com \
    --cc=lgirdwood@gmail.com \
    --cc=lkp@intel.com \
    --cc=tiwai@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.