From: Mark Brown <broonie@kernel.org>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Takashi Iwai <tiwai@suse.com>,
Matthias Kaehlcke <mka@chromium.org>,
"Tc, Jenny" <jenny.tc@intel.com>
Subject: Re: [PATCH 0/2] Introduce dmic mode switch delay parameter
Date: Wed, 24 Oct 2018 14:40:30 +0100 [thread overview]
Message-ID: <20181024134030.GS2103@sirena.org.uk> (raw)
In-Reply-To: <a07a0b87-d9ee-f5f9-6a81-6ec2379e1a5f@linux.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 1255 bytes --]
On Tue, Oct 23, 2018 at 01:22:18PM -0500, Pierre-Louis Bossart wrote:
> ok, but not sure what to define. You don't want too many identifiers either,
> this generated lots of patches for no good reason. What are the needs here?
> You probably don't want to identify the DMIC vendor so this could be an
> Intel-defined ID. But I wonder if this might be reused on AMD platforms?
There's nothing stopping AMD systems using the Intel device IDs. We
already get some of that with the other non-Intel components that have
been assigned Intel IDs due to their presence on Intel reference
systems.
> Changing the dailink to point to one device instead of another is not a good
> idea, the machine driver should be independent from all this, and be
> reusable between the SKL driver or SOF drivers. The last thing you want is a
> hack in there.
The firmware binding really ought to be OS neutral, never mind driver
neutral :(
> ok, makes sense. Do you think it'd be possible to use ACPI initrd overlays
> to add support for those parameters if they don't natively exist in the
> BIOS?
Don't know about that (I'm not familiar enough with how this stuff gets
shipped on x86 systems) but the traditionl solution for ACPI appears to
be to have DMI based quirks.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2018-10-24 13:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-02 5:57 [PATCH 0/2] Introduce dmic mode switch delay parameter Jenny TC
2018-10-02 5:57 ` [PATCH 1/2] ASoC: dmic: Enable ACPI device entry Jenny TC
2018-10-02 15:00 ` Mark Brown
2018-10-02 17:12 ` Matthias Kaehlcke
2018-10-02 5:57 ` [PATCH 2/2] ASoC: dmic: Introduce mode switch delay Jenny TC
2018-10-22 3:42 ` [PATCH 0/2] Introduce dmic mode switch delay parameter Pierre-Louis Bossart
2018-10-22 14:31 ` Pierre-Louis Bossart
2018-10-23 17:11 ` Tc, Jenny
2018-10-23 18:22 ` Pierre-Louis Bossart
2018-10-24 13:40 ` Mark Brown [this message]
2018-10-24 13:35 ` Mark Brown
2018-10-25 16:08 ` Vinod Koul
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=20181024134030.GS2103@sirena.org.uk \
--to=broonie@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=jenny.tc@intel.com \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=lgirdwood@gmail.com \
--cc=mka@chromium.org \
--cc=pierre-louis.bossart@linux.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.