linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Ben Zhang <benzh@chromium.org>
Cc: alsa-devel@alsa-project.org, Liam Girdwood <lgirdwood@gmail.com>,
	Bard Liao <bardliao@realtek.com>,
	Oder Chiou <oder_chiou@realtek.com>,
	Anatol Pomozov <anatol@google.com>,
	Dylan Reid <dgreid@chromium.org>,
	flove@realtek.com, linux-kernel@vger.kernel.org,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Darren Hart <dvhart@linux.intel.com>,
	Grant Likely <grant.likely@linaro.org>,
	Vinod Koul <vinod.koul@intel.com>
Subject: Re: [PATCH 1/2] ASoC: rt5677: Add ACPI device probing
Date: Tue, 25 Nov 2014 12:07:24 +0000	[thread overview]
Message-ID: <20141125120724.GP7712@sirena.org.uk> (raw)
In-Reply-To: <1416034608-24238-1-git-send-email-benzh@chromium.org>

[-- Attachment #1: Type: text/plain, Size: 2646 bytes --]

On Fri, Nov 14, 2014 at 10:56:47PM -0800, Ben Zhang wrote:

> The rt5677 codec driver looks for ACPI device ID "RT5677CE",
> which is specified in coreboot. This patch allows platform
> data to be obtained via ACPI

This actually does two things - it adds the ACPI device probing and it
adds the ACPI platform data.  That last bit is a bit fun, I've added
several of the people working on ACPI here since this is another variant
on the whole ACPI platform data thing which probably needs addressing in
the best practice dissemination which ought to be going on now.

> +static unsigned long long rt5677_parse_acpi_entry(struct device *dev,
> +		acpi_string name)
> +{
> +	acpi_handle handle = ACPI_HANDLE(dev);
> +	unsigned long long val;
> +	acpi_status status;
> +
> +	status = acpi_evaluate_integer(handle, name, NULL, &val);
> +	if (ACPI_FAILURE(status)) {

So, here were defining what's essentially an ACPI property read API
which uses something other than _DSD which is the way all the ACPI
platform data specification for devices is apparently supposed to be
going in order to reuse work between DT and ACPI.

> +static void rt5677_parse_acpi(struct rt5677_priv *rt5677, struct device *dev)
> +{
> +	rt5677->pdata.dmic2_clk_pin = (enum rt5677_dmic2_clk)
> +		rt5677_parse_acpi_entry(dev, "DCLK");
> +	rt5677->pdata.in1_diff = (bool)rt5677_parse_acpi_entry(dev, "IN1");
> +	rt5677->pdata.in2_diff = (bool)rt5677_parse_acpi_entry(dev, "IN2");
> +	rt5677->pdata.lout1_diff = (bool)rt5677_parse_acpi_entry(dev, "OUT1");
> +	rt5677->pdata.lout2_diff = (bool)rt5677_parse_acpi_entry(dev, "OUT2");
> +	rt5677->pdata.lout3_diff = (bool)rt5677_parse_acpi_entry(dev, "OUT3");
> +	rt5677->pdata.jd1_gpio = rt5677_parse_acpi_entry(dev, "JD1");
> +	rt5677->pdata.jd2_gpio = rt5677_parse_acpi_entry(dev, "JD2");
> +	rt5677->pdata.jd3_gpio = rt5677_parse_acpi_entry(dev, "JD3");

Here we read a bunch of properties named with a most definitely non-DT
idiom.  The names here don't look great in general, in particular all
the properties for differential outputs are just boolean flags for the
output name which I'd expect to be flags saying if the output is in use
or not rather than saying if it's in differential mode or single ended
mode.  Things like foo_DIFF would seem better.

My understanding is that best practice for ACPI is to use the new
device_property_read_ APIs which idiomatically take DT style property
names.  However if there's BIOSs out there we need to support perhaps we
just have to deal with this but judging from your e-mail address it
seems this may be for a system intended to run Linux natively so perhaps
that's not an issue.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  parent reply	other threads:[~2014-11-25 12:09 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-15  6:56 [PATCH 1/2] ASoC: rt5677: Add ACPI device probing Ben Zhang
2014-11-15  6:56 ` [PATCH 2/2] ASoC: rt5677: add a platform config option for PDM clock divider Ben Zhang
2014-11-25 12:07 ` Mark Brown [this message]
2014-11-25 12:11 ` [PATCH 1/2] ASoC: rt5677: Add ACPI device probing Grant Likely
2014-11-25 14:28   ` [alsa-devel] " Liam Girdwood
2014-11-25 16:01     ` Darren Hart
2014-11-25 18:37       ` Liam Girdwood
2014-11-25 16:00   ` Darren Hart
2014-11-25 17:21     ` Mark Brown
2014-11-25 18:33       ` Darren Hart
2014-11-25 18:43         ` Mark Brown
2014-11-25 19:07           ` Darren Hart
2014-11-25 19:36             ` Mark Brown
2014-11-25 20:32               ` Rafael J. Wysocki
2014-11-25 20:31             ` Rafael J. Wysocki
2014-11-25 20:27               ` Mark Brown
2014-11-25 21:40                 ` Rafael J. Wysocki
2014-11-25 22:15                   ` Mark Brown
2014-11-25 22:41                   ` Ben Zhang
2014-11-25 22:45                     ` Mark Brown
2014-12-04 10:48                   ` Grant Likely
2014-12-04 16:46                     ` Mark Brown
2014-12-04 21:53                     ` Rafael J. Wysocki
2014-11-26  1:48           ` Darren Hart
2014-11-26 11:17             ` Mark Brown
2014-11-26 23:09               ` Rafael J. Wysocki
2014-11-28 16:00                 ` Mark Brown
2014-11-28 23:51                   ` Rafael J. Wysocki
2014-11-29 11:52                     ` Mark Brown
2014-11-29 22:27                       ` Rafael J. Wysocki
2014-12-01 17:51                         ` Mark Brown
2014-12-01 22:16                           ` Rafael J. Wysocki
2014-12-01 22:19                             ` Mark Brown
2014-12-01 22:55                               ` Rafael J. Wysocki
2014-12-04 11:12                         ` Grant Likely
2014-12-04 11:51                           ` Mark Brown

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=20141125120724.GP7712@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=anatol@google.com \
    --cc=bardliao@realtek.com \
    --cc=benzh@chromium.org \
    --cc=dgreid@chromium.org \
    --cc=dvhart@linux.intel.com \
    --cc=flove@realtek.com \
    --cc=grant.likely@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oder_chiou@realtek.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=vinod.koul@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;
as well as URLs for NNTP newsgroup(s).