From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: David Jander <david.jander@protonic.nl>
Cc: Grant Likely <grant.likely@secretlab.ca>,
alsa-devel@alsa-project.org, lrg@ti.com,
devicetree-discuss@lists.ozlabs.org, torbenh <torbenh@gmx.de>
Subject: Re: ASoC audio fabric OF bindings RFC. was: Re: ASoC MPC5xxx PSC AC97 audio driver
Date: Mon, 12 Sep 2011 15:52:14 +0100 [thread overview]
Message-ID: <20110912145214.GC5887@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20110912155905.35cda85b@archvile>
On Mon, Sep 12, 2011 at 03:59:05PM +0200, David Jander wrote:
> Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
> > Note the "dynamic" bit - the configuration changes at runtime.
> > Describing the hardware for something like a modern smartphone isn't
> > particularly useful due to the flexibility, there are too many different
> > ways of configuring the system and we need code to acutally take those
> > decision.
> Ok, but you could still describe the hardwired part of it (Audio muxes,
> codecs, busses and physical interfaces). Isn't that what OF is all about?
> In our case, its just a simple AC97 codec connected to a simple AC97 bus.
> Sounds like total overkill having to write a "fabric driver" for this....
> while there are already quite a few that are all 99% the same!
I'm not sure I understand what you are talking about. As I've already
said at least once having a *machine* driver which covers multiple
machines is absolutely OK. We already have several such drivers in
kernel.
*Please* look at the existing code and read what I'm saying, and ideally
also read the prior discussions on this topic. Please also try to avoid
inventing your own techncial terms. It's enormously repetitive and not
terribly useful to have to go through all this stuff from square one
every single time someone looks at this stuff.
> > > > The plan is to push the device trees out of the kernel into a separate
> > > > repository.
> > > Good idea.... but where should such a repository be hosted?
> > Still an open issue.
> Seems like its hard to find a vendor- and OS-neutral entity to host this?
> OpenBIOS maybe?
More a problem of deciding which of the many available options to
choose.
next prev parent reply other threads:[~2011-09-12 14:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20110908121600.267dee07@archvile>
[not found] ` <CAKON4OzsMd0T6KyDK_5P_pz8R5Pax+Bd+f5+00cO5E0OMCYQpQ@mail.gmail.com>
[not found] ` <20110908124529.520c1388@archvile>
[not found] ` <CAKON4OwvYy6Dy-MfHT90syPyAUcTVRXqXca-qAVjk-KWkak53A@mail.gmail.com>
[not found] ` <20110908163231.4b721973@archvile>
[not found] ` <20110908184441.GD16989@siel.b>
[not found] ` <20110909082844.3dbf0e72@archvile>
2011-09-09 10:02 ` ASoC audio fabric OF bindings RFC. was: Re: ASoC MPC5xxx PSC AC97 audio driver David Jander
2011-09-09 16:37 ` Mark Brown
2011-09-12 6:31 ` David Jander
2011-09-12 11:09 ` Mark Brown
2011-09-12 12:55 ` David Jander
2011-09-12 13:19 ` Mark Brown
2011-09-12 13:59 ` David Jander
2011-09-12 14:52 ` Mark Brown [this message]
2011-09-12 19:48 ` Grant Likely
2011-09-13 6:31 ` David Jander
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=20110912145214.GC5887@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=david.jander@protonic.nl \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=lrg@ti.com \
--cc=torbenh@gmx.de \
/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).