From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Cezary Rojewski <cezary.rojewski@intel.com>
Cc: rafael@kernel.org, linux-acpi@vger.kernel.org,
robert.moore@intel.com, erik.kaneda@intel.com,
pierre-louis.bossart@linux.intel.com,
amadeuszx.slawinski@linux.intel.com, lenb@kernel.org
Subject: Re: [PATCH 4/4] ACPI: NHLT: Add query functions
Date: Wed, 12 Jul 2023 18:48:57 +0300 [thread overview]
Message-ID: <ZK7LadhJSBjJUNqs@smile.fi.intel.com> (raw)
In-Reply-To: <20230712091048.2545319-5-cezary.rojewski@intel.com>
On Wed, Jul 12, 2023 at 11:10:48AM +0200, Cezary Rojewski wrote:
> With iteration helpers added there is a room for more complex query
> tasks which are commonly performed by sound drivers. Implement them in
> common API so that a unified mechanism is available for all of them.
>
> While the acpi_nhlt_endpoint_dmic_count() stands out a bit, it is a
> critical component for any AudioDSP driver to know how many digital
> microphones it is dealing with. There is no one perfect method, but the
> best one available is provided.
...
> +bool acpi_nhlt_endpoint_match(const struct acpi_nhlt_endpoint *ep,
> + int link_type, int dev_type, int dir, int bus_id)
> +{
> + return ep &&
> + (link_type < 0 || ep->link_type == link_type) &&
> + (dev_type < 0 || ep->device_type == dev_type) &&
> + (dir < 0 || ep->direction == dir) &&
> + (bus_id < 0 || ep->virtual_bus_id == bus_id);
I think you can split these for better reading.
if (!ep)
return false;
if (link_type >= 0 && ep->link_type != link_type)
return false;
if (dev_type >= 0 && ep->device_type != dev_type)
return false;
if (dir >= 0 && ep->direction != dir)
return false;
if (bus_id >= 0 && ep->virtual_bus_id != bus_id)
return false;
return true;
Yes, much more lines, but readability is better in my opinion.
I also believe that code generation on x86_64 will be the same.
> +}
...
> +struct acpi_nhlt_endpoint *
> +acpi_nhlt_find_endpoint(const struct acpi_table_nhlt *tb,
> + int link_type, int dev_type, int dir, int bus_id)
> +{
> + struct acpi_nhlt_endpoint *ep;
> + if (!tb)
> + return ERR_PTR(-EINVAL);
Just wondering how often we will have a caller that supplies NULL for tb.
> + for_each_nhlt_endpoint(tb, ep)
> + if (acpi_nhlt_endpoint_match(ep, link_type, dev_type, dir, bus_id))
> + return ep;
> + return NULL;
> +}
...
> +struct acpi_nhlt_format_config *
> +acpi_nhlt_endpoint_find_fmtcfg(const struct acpi_nhlt_endpoint *ep,
> + u16 ch, u32 rate, u16 vbps, u16 bps)
> +{
> + struct acpi_nhlt_wave_extensible *wav;
> + struct acpi_nhlt_format_config *fmt;
> + if (!ep)
> + return ERR_PTR(-EINVAL);
Similar Q as above.
> + for_each_nhlt_endpoint_fmtcfg(ep, fmt) {
> + wav = &fmt->format;
> +
> + if (wav->channel_count == ch &&
> + wav->valid_bits_per_sample == vbps &&
> + wav->bits_per_sample == bps &&
> + wav->samples_per_sec == rate)
Also can be split, but this one readable in the original form.
> + return fmt;
> + }
> +
> + return NULL;
> +}
...
> +struct acpi_nhlt_format_config *
> +acpi_nhlt_find_fmtcfg(const struct acpi_table_nhlt *tb,
> + int link_type, int dev_type, int dir, int bus_id,
> + u16 ch, u32 rate, u16 vbps, u16 bps)
> +{
> + struct acpi_nhlt_format_config *fmt;
> + struct acpi_nhlt_endpoint *ep;
> + if (!tb)
> + return ERR_PTR(-EINVAL);
Same as above.
Looking at them, wouldn't simply returning NULL suffice?
> + for_each_nhlt_endpoint(tb, ep) {
> + if (!acpi_nhlt_endpoint_match(ep, link_type, dev_type, dir, bus_id))
> + continue;
> +
> + fmt = acpi_nhlt_endpoint_find_fmtcfg(ep, ch, rate, vbps, bps);
> + if (fmt)
> + return fmt;
> + }
> +
> + return NULL;
> +}
...
> +int acpi_nhlt_endpoint_dmic_count(const struct acpi_nhlt_endpoint *ep)
> +{
> + struct acpi_nhlt_vendor_mic_devcfg *vendor_cfg;
> + struct acpi_nhlt_format_config *fmt;
> + struct acpi_nhlt_mic_devcfg *devcfg;
> + u16 max_ch = 0;
> +
> + if (!ep || ep->link_type != ACPI_NHLT_PDM)
> + return -EINVAL;
> +
> + /* Find max number of channels based on formats configuration. */
> + for_each_nhlt_endpoint_fmtcfg(ep, fmt)
> + max_ch = max(fmt->format.channel_count, max_ch);
> +
> + /* If @ep not a mic array, fallback to channels count. */
> + devcfg = acpi_nhlt_endpoint_mic_devcfg(ep);
> + if (!devcfg || devcfg->config_type != ACPI_NHLT_CONFIG_TYPE_MIC_ARRAY)
> + return max_ch;
> +
> + switch (devcfg->array_type) {
> + case ACPI_NHLT_SMALL_LINEAR_2ELEMENT:
> + case ACPI_NHLT_BIG_LINEAR_2ELEMENT:
> + return 2;
> +
> + case ACPI_NHLT_FIRST_GEOMETRY_LINEAR_4ELEMENT:
> + case ACPI_NHLT_PLANAR_LSHAPED_4ELEMENT:
> + case ACPI_NHLT_SECOND_GEOMETRY_LINEAR_4ELEMENT:
> + return 4;
> +
> + case ACPI_NHLT_VENDOR_DEFINED:
> + vendor_cfg = acpi_nhlt_endpoint_vendor_mic_devcfg(ep);
> + if (!vendor_cfg)
> + return -EINVAL;
> + return vendor_cfg->num_mics;
> +
> + default:
> + pr_warn("undefined mic array type: %#x\n", devcfg->array_type);
Is this function can ever be called without backing device? If not,
I would supply (ACPI?) device pointer and use dev_warn() instead.
But I'm not sure about this. Up to you, folks.
> + return max_ch;
> + }
> +}
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2023-07-12 15:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-12 9:10 [PATCH 0/4] ACPI: NHLT: Access and query helpers Cezary Rojewski
2023-07-12 9:10 ` [PATCH 1/4] ACPI: NHLT: Device configuration access interface Cezary Rojewski
2023-07-12 9:10 ` [PATCH 2/4] ACPI: NHLT: Introduce acpi_gbl_NHLT Cezary Rojewski
2023-07-12 9:10 ` [PATCH 3/4] ACPI: NHLT: Table manipulation helpers Cezary Rojewski
2023-07-12 15:36 ` Andy Shevchenko
2023-07-17 8:08 ` Cezary Rojewski
2023-07-12 9:10 ` [PATCH 4/4] ACPI: NHLT: Add query functions Cezary Rojewski
2023-07-12 15:48 ` Andy Shevchenko [this message]
2023-07-17 8:29 ` Cezary Rojewski
2023-07-17 9:47 ` Andy Shevchenko
2023-07-17 11:25 ` Cezary Rojewski
2023-07-18 11:11 ` Cezary Rojewski
2023-07-18 14:17 ` Andy Shevchenko
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=ZK7LadhJSBjJUNqs@smile.fi.intel.com \
--to=andriy.shevchenko@intel.com \
--cc=amadeuszx.slawinski@linux.intel.com \
--cc=cezary.rojewski@intel.com \
--cc=erik.kaneda@intel.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=rafael@kernel.org \
--cc=robert.moore@intel.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.