From: Robert Jarzmik <robert.jarzmik@free.fr>
To: Rob Herring <robh+dt@kernel.org>
Cc: Linux-ALSA <alsa-devel@alsa-project.org>,
Mark Brown <broonie@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Daniel Mack <zonque@gmail.com>
Subject: Re: ASoC: new ac97 bus and codec clock
Date: Wed, 20 Jun 2018 21:36:59 +0200 [thread overview]
Message-ID: <87h8lxp7vo.fsf@belgarion.home> (raw)
In-Reply-To: <CAL_JsqKBOdZBuDnRUAcpARP1fFquc7vpcUayYRaJAMSPrhsPdg@mail.gmail.com> (Rob Herring's message of "Wed, 20 Jun 2018 11:16:15 -0600")
Rob Herring <robh+dt@kernel.org> writes:
> Does AC97 specify a common programming model? That's were a common
> compatible is used (though experience has proven things like
> "generic-ehci" are don't work).
If regmap is enough "common programming model" then yes. If you think of a
common layout of AC97 registers and a common dynamics to program them across all
ac97 controllers, then no, as far as I'm aware it does not.
>> If the purpose for this compatible string is to filter the child nodes which are
>> only ac97 codecs, so that the ac97 framework can act upon them (ie. acquire the
>> clock for example), then wm9713 is too specific ... That won't work for another
>> device with an Analog Devices AD1835 for example.
> Are there ID registers? If so, then just construct a compatible string
> from them and just find the compatible child node. See USB bindings
> for an example using VID/PID.
There is an AC97 ID register, yes, a key as VID/PID is a key for USB.
So my example, where the id is 0x574d4c13, would become :
ac97: sound@40500000 {
compatible = "marvell,pxa270-ac97";
reg = < 0x40500000 0x1000 >;
interrupts = <14>;
reset-gpios = <&gpio 95 GPIO_ACTIVE_HIGH>;
#sound-dai-cells = <1>;
pinctrl-names = "default";
pinctrl-0 = < &pinctrl_ac97_default >;
clocks = <&clks CLK_AC97>, <&clks CLK_AC97CONF>;
clock-names = "AC97CLK", "AC97CONFCLK";
audio-codec@0 {
reg = <0>; /* Codex index (between 0 and 3) */
compatible = "ac97id574d4c13";
clocks = <&fixed_wm9713_clock>;
clock-names = "ac97_clk";
}
};
Once we have converged on this example, I will post the patches for the binding,
and the adaptation of the ac97 bus of course. Gives me a better chance to shoot
in the right direction first :)
Cheers.
--
Robert
next prev parent reply other threads:[~2018-06-20 19:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-17 20:03 ASoC: new ac97 bus and codec clock Robert Jarzmik
2018-06-19 15:02 ` Mark Brown
2018-06-19 17:56 ` Rob Herring
2018-06-20 14:52 ` Robert Jarzmik
2018-06-20 15:10 ` Rob Herring
2018-06-20 17:04 ` Robert Jarzmik
2018-06-20 17:16 ` Rob Herring
2018-06-20 19:36 ` Robert Jarzmik [this message]
2018-06-20 20:00 ` Rob Herring
2018-06-27 11:23 ` 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=87h8lxp7vo.fsf@belgarion.home \
--to=robert.jarzmik@free.fr \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=frowand.list@gmail.com \
--cc=robh+dt@kernel.org \
--cc=zonque@gmail.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