All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Piotr Maziarz <piotrx.maziarz@linux.intel.com>,
	Cezary Rojewski <cezary.rojewski@intel.com>,
	alsa-devel@alsa-project.org, broonie@kernel.org
Cc: upstream@semihalf.com, harshapriya.n@intel.com, rad@semihalf.com,
	tiwai@suse.com, hdegoede@redhat.com,
	amadeuszx.slawinski@linux.intel.com, cujomalainey@chromium.org,
	lma@semihalf.com
Subject: Re: [PATCH 01/14] ASoC: Intel: avs: Account for libraries when booting basefw
Date: Fri, 6 May 2022 10:47:06 -0500	[thread overview]
Message-ID: <c642d518-3ccd-8c11-ec96-aa1286288499@linux.intel.com> (raw)
In-Reply-To: <f14701db-94fa-ba3f-87fc-dc91177abff7@linux.intel.com>


>>>>   +int avs_dsp_load_libraries(struct avs_dev *adev, struct
>>>> avs_tplg_library *libs, u32 num_libs)
>>>> +{
>>>> +    int start, id, i = 0;
>>>> +    int ret;
>>>> +
>>>> +    /* Calculate the id to assign for the next lib. */
>>>> +    for (id = 0; id < adev->fw_cfg.max_libs_count; id++)
>>>> +        if (adev->lib_names[id][0] == '\0')
>>>> +            break;
>>>> +    if (id + num_libs >= adev->fw_cfg.max_libs_count)
>>>> +        return -EINVAL;
>>>
>>> use ida_alloc_max() ?
>>
>>
>> After reading this one couple of times I'm keen to agree that IDA
>> should have been used for library ID allocation and a at the same
>> time, surprised it has't done that already. Till now we used IDA
>> 'only' when allocating pipeline IDs and module instance IDs. Pipeline
>> allocation is good comparison here - makes use of ida_alloc_max()
>> already - library one should follow.
>>
>> This finding is much appreciated, Pierre.
> 
> I think that using ida here is a bit of an overkill. Ida works fine when
> there can be both id allocation and freeing and that's how it work with
> pipelines and modules IDs in avs. However there is no mechanism for
> unloading libraries in cAVS firmware, therefore ida would be used here
> only to increase the ID, so it needlessly complicates the code while not
> giving much of a benefit. Also our approach to check if we can load all
> libraries before the loop makes it problematic with ida because we would
> need to allocate an id at start and calculate if all libs would fit and
> then either free it instantly or complicate the loop to use id allocated
> before. Therefore I suggest to leave this code unchanged. I've synced
> with Cezary on this and provided explanation convinced him too.

That's fine, you should however capture this design decision with a
comment or a clarification in the commit message. "libraries" mean
different things to different people, and it's hard to review without
context.


  reply	other threads:[~2022-05-06 15:48 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-26 17:23 [PATCH 00/14] ASoC: Intel: avs: Driver core and PCM operations Cezary Rojewski
2022-04-26 17:23 ` [PATCH 01/14] ASoC: Intel: avs: Account for libraries when booting basefw Cezary Rojewski
2022-04-26 21:21   ` Pierre-Louis Bossart
2022-05-01  9:45     ` Cezary Rojewski
2022-05-06 15:25       ` Piotr Maziarz
2022-05-06 15:47         ` Pierre-Louis Bossart [this message]
2022-04-26 17:23 ` [PATCH 02/14] ASoC: Intel: avs: Generic soc component driver Cezary Rojewski
2022-04-26 21:33   ` Pierre-Louis Bossart
2022-05-01 10:45     ` Cezary Rojewski
2022-04-26 17:23 ` [PATCH 03/14] ASoC: Intel: avs: Generic PCM FE operations Cezary Rojewski
2022-04-26 17:23 ` [PATCH 04/14] ASoC: Intel: avs: non-HDA PCM BE operations Cezary Rojewski
2022-04-26 21:40   ` Pierre-Louis Bossart
2022-05-01 10:48     ` Cezary Rojewski
2022-04-26 17:23 ` [PATCH 05/14] ASoC: Intel: avs: HDA " Cezary Rojewski
2022-04-26 21:45   ` Pierre-Louis Bossart
2022-05-01 10:55     ` Cezary Rojewski
2022-04-26 17:23 ` [PATCH 06/14] ASoC: Intel: avs: Coredump and recovery flow Cezary Rojewski
2022-04-26 21:53   ` Pierre-Louis Bossart
2022-05-01 15:32     ` Cezary Rojewski
2022-05-02 13:53       ` Pierre-Louis Bossart
2022-04-26 17:23 ` [PATCH 07/14] ASoC: Intel: avs: Prepare for firmware tracing Cezary Rojewski
2022-04-26 17:23 ` [PATCH 08/14] ASoC: Intel: avs: D0ix power state support Cezary Rojewski
2022-04-26 21:58   ` Pierre-Louis Bossart
2022-04-29 14:19     ` Cezary Rojewski
2022-04-29 14:33       ` Cezary Rojewski
2022-04-26 17:23 ` [PATCH 09/14] ASoC: Intel: avs: Event tracing Cezary Rojewski
2022-04-26 17:23 ` [PATCH 10/14] ASoC: Intel: avs: Machine board registration Cezary Rojewski
2022-04-26 22:12   ` Pierre-Louis Bossart
2022-04-29 14:01     ` Cezary Rojewski
2022-05-04  9:41       ` Amadeusz Sławiński
2022-05-04 11:12         ` Cezary Rojewski
2022-05-04 11:26         ` Péter Ujfalusi
2022-05-04 12:33           ` Cezary Rojewski
2022-04-26 17:23 ` [PATCH 11/14] ASoC: Intel: avs: PCI driver implementation Cezary Rojewski
2022-04-26 17:23 ` [PATCH 12/14] ASoC: Intel: avs: Power management Cezary Rojewski
2022-04-26 22:18   ` Pierre-Louis Bossart
2022-04-29 13:44     ` Cezary Rojewski
2022-04-26 17:23 ` [PATCH 13/14] ASoC: Intel: avs: SKL-based platforms support Cezary Rojewski
2022-04-26 17:23 ` [PATCH 14/14] ASoC: Intel: avs: APL-based " Cezary Rojewski
2022-04-27  8:15 ` [PATCH 00/14] ASoC: Intel: avs: Driver core and PCM operations Cezary Rojewski

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=c642d518-3ccd-8c11-ec96-aa1286288499@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=cujomalainey@chromium.org \
    --cc=harshapriya.n@intel.com \
    --cc=hdegoede@redhat.com \
    --cc=lma@semihalf.com \
    --cc=piotrx.maziarz@linux.intel.com \
    --cc=rad@semihalf.com \
    --cc=tiwai@suse.com \
    --cc=upstream@semihalf.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.