Re: ASOC - Codecs : Renaming of spdif_tranceiver.c

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2573 bytes --]

On Wed, Mar 07, 2012 at 08:48:09PM +0530, Nitin PAI wrote:

> >>Even with automotive there's *some* power limits and obviously the power
> >>control also includes things like syncing startup of the algorithms with
> >>the data path

> I dont think that needs to be absolutely done as a part of kernel layer.

In general it really does - things get sensitive about their clocks and
algorithms get sensitive about their inputs.  You can often get
something together that isn't joined together but usually there's a
stack of simplifying assumptions in there which can break easily enough.
Besides, you still need something there which exposes whatever physical
interfaces userspace needs to use to program things.  If userspace can
just randomly interact with hardware that's a bit of a failure.

> >>Well, yes.  Unless someone writes a card driver the CPU driver won't do
> >>anything useful but then without the card driver you've no idea how the
> >>system is actually wired up and the chances of it doing anything useful
> >>are close to zero.  There's no getting out of the machine driver.

> This is the point. Why write a card driver? For example audio over MOST or
> for HDMI audio?

If the same driver works on all systems then you can just write the
driver and it'll work for everyone.  Nothing at the CODEC level is going
to make this more or less easy, you're actually saying you've got some
hardware for which you can write a generic machine driver.  If that's
the case you should just do that, there's some examples of this already
like the fsi-hdmi driver.

> Or when I have some utility in userspace to test the functionality.
> Wont it be better to atleast enumerate the driver and show the capabilities
> it supports?

You can add debugfs information to dump the capabilities and whatnot if
that's useful to you...

> This can help in many phases of design like emulation, bringup (doing
> loopback between 2 interfaces at SOC level)?

If you're doing stuff like this you're probably more than capable of
tweaking things to suit your needs, and probably be prepared to accept a
level of brokenness while you're at it.  For example, if you've not got
clocks then you won't transfer data and userspace tends to get upset
with you.  You'd still need to do things like set up the clocking even
for the SoC loopback case, everything is going to need to agree on where
the clocks come from and how they flow.

> Cant we have support for all this, if not codec, somewhere else?

Honestly it just sounds like you want to write some machine drivers for
your systems.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]