public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
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



  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox