ASOC - Codecs : Renaming of spdif_tranceiver.c

ASOC - Codecs : Renaming of spdif_tranceiver.c

[Nitin PAI]

Hi,

In my project I am feeling of need to have generic_codec.  This will
provide the required codec_dais for the usecases like

-HDMI/SPDIF where there is no codec involved.
-For audio over MOST, where CPLD/glue logic is used
-For complex audio DSPs connected which will be mostly programmed in the
user-space.
-SOC manufactures who would like to ship their drivers without having to
know what will be the final codec that will be present in the system.

Currently there is spdif_tranceiver.c which serves the purpose for spdif,
but using this for other usecases will create confusion while shipping the
code.

What is the best way to carry forward?

1) Use spdif_tranceiver.c for all the purpose.
disadvantage:  this will create more confusion while shipping.

2)Deprecate spdif_transciever.c and call it generic_codec. Change the dai
names and the function names.

3)Create another generic_codec.c and keep the spdif_transceiver.c and
deprecate the latter in next version.

4) Any other ideas ?

Thanks,
Nitin

ASOC - Codecs : Renaming of spdif_tranceiver.c

[Nitin PAI]

CCing the maintainers to get attention.

---------- Forwarded message ----------
From: Nitin PAI <nitinmpai@gmail.com>
Date: Wed, Mar 7, 2012 at 12:15 PM
Subject: ASOC - Codecs : Renaming of spdif_tranceiver.c
To: alsa-devel@alsa-project.org
Cc: swarren@nvidia.com


Hi,

In my project I am feeling of need to have generic_codec.  This will
provide the required codec_dais for the usecases like

-HDMI/SPDIF where there is no codec involved.
-For audio over MOST, where CPLD/glue logic is used
-For complex audio DSPs connected which will be mostly programmed in the
user-space.
-SOC manufactures who would like to ship their drivers without having to
know what will be the final codec that will be present in the system.

Currently there is spdif_tranceiver.c which serves the purpose for spdif,
but using this for other usecases will create confusion while shipping the
code.

What is the best way to carry forward?

1) Use spdif_tranceiver.c for all the purpose.
disadvantage:  this will create more confusion while shipping.

2)Deprecate spdif_transciever.c and call it generic_codec. Change the dai
names and the function names.

3)Create another generic_codec.c and keep the spdif_transceiver.c and
deprecate the latter in next version.

4) Any other ideas ?

Thanks,
Nitin



-- 
“Karmanya vadhikaraste ma phaleshu kadachana Ma karma-phala-hetur bhu ma te
sango stav karmani”           -  Krishna

Re: ASOC - Codecs : Renaming of spdif_tranceiver.c

[Mark Brown]

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

On Wed, Mar 07, 2012 at 12:15:07PM +0530, Nitin PAI wrote:

Adding a CC to Liam.  *ALWAYS* CC the maintainers on mails, I know you
followed up adding Liam but you still missed me off.

> In my project I am feeling of need to have generic_codec.  This will
> provide the required codec_dais for the usecases like

> -HDMI/SPDIF where there is no codec involved.
> -For audio over MOST, where CPLD/glue logic is used

These still need something to say what the capabilities of the device
are - ideally users could just specify the part name and not worry about
that stuff.  If you look at how thin the drivers are it's really not
clear to me what we'd save here, though if someone did the work and it
looked useful...  Another option is to just embed all the data
structures in a single driver which binds to them all and selects the
right data structure based on the probe information, that might be
useful.

> -For complex audio DSPs connected which will be mostly programmed in the
> user-space.

These will need in kernel drivers, if only to export the interfaces
required by the application layer to userspace.  They'll also have
difficulty integrating well with the power management without an in
kernel representation of the device, especially for bypass cases like in
call audio.

> -SOC manufactures who would like to ship their drivers without having to
> know what will be the final codec that will be present in the system.

The CPU side drivers have no dependency on the CODEC drivers, these are
integrated by the machine.  The SoC vendor can easily ship drivers which
will work with any CODEC which works well on Linux.

If you actually mean machine drivers it's not really possible to write a
generic machine driver which will actually work for modern CODECs,
especially those used in smartphones and tablets, the clocking
architectures are far too varied and flexible for this to work usefully.
This is before you get into things that are genuine hardware choices and
need to be enumerated at runtime, and of course most modern devices will
require software to power them on so you need to match them up with the
relevant driver to do that.

In general pluggable reference boards really need to have some means of
identifying the connected boards if they want to support running with
different setups without recompilation.  For example, the Wolfson
reference systems have ID chips on each board which are queried during
boot to allow us to instantiate things based on what's physically
connected.  We can swap boards over and have a single system image boot
successfully without software changes.

> 4) Any other ideas ?

I don't think you've fully thought through what you're suggesting, it
doesn't seem practical for most things.

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

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

Re: ASOC - Codecs : Renaming of spdif_tranceiver.c

[Nitin PAI]

Hi Mark,

The usecase for the DSP was specifically for automotive where there is no
power requirements and the audio functionality is always on.
The programming of the codecs usually from the userspace.  However ALSA is
used  for ease of using the alsalib for its various functions (applications
standpoint).

>>The CPU side drivers have no dependency on the CODEC drivers, these are
>>integrated by the machine.  The SoC vendor can easily ship drivers which
>>will work with any CODEC which works well on Linux.
The problem with just writing the machine driver and shipping it is,
without any codec driver the cards wont be enumerated.
Having a thin codec driver to enumerate the cards and ship it will help.
(from debug and development standpoint).

 >>Another option is to just embed all the data
>>structures in a single driver which binds to them all and selects the
>>right data structure based on the probe information, that might be
>>useful.
Are you suggesting to have this in the machine driver?  I didnt understand
this, please clarify.

Thanks,
Nitin

On Wed, Mar 7, 2012 at 7:13 PM, Mark Brown <
broonie@opensource.wolfsonmicro.com> wrote:

> On Wed, Mar 07, 2012 at 12:15:07PM +0530, Nitin PAI wrote:
>
> Adding a CC to Liam.  *ALWAYS* CC the maintainers on mails, I know you
> followed up adding Liam but you still missed me off.
>
> > In my project I am feeling of need to have generic_codec.  This will
> > provide the required codec_dais for the usecases like
>
> > -HDMI/SPDIF where there is no codec involved.
> > -For audio over MOST, where CPLD/glue logic is used
>
> These still need something to say what the capabilities of the device
> are - ideally users could just specify the part name and not worry about
> that stuff.  If you look at how thin the drivers are it's really not
> clear to me what we'd save here, though if someone did the work and it
> looked useful...  Another option is to just embed all the data
> structures in a single driver which binds to them all and selects the
> right data structure based on the probe information, that might be
> useful.
>
> > -For complex audio DSPs connected which will be mostly programmed in the
> > user-space.
>
> These will need in kernel drivers, if only to export the interfaces
> required by the application layer to userspace.  They'll also have
> difficulty integrating well with the power management without an in
> kernel representation of the device, especially for bypass cases like in
> call audio.
>
> > -SOC manufactures who would like to ship their drivers without having to
> > know what will be the final codec that will be present in the system.
>
> The CPU side drivers have no dependency on the CODEC drivers, these are
> integrated by the machine.  The SoC vendor can easily ship drivers which
> will work with any CODEC which works well on Linux.
>
> If you actually mean machine drivers it's not really possible to write a
> generic machine driver which will actually work for modern CODECs,
> especially those used in smartphones and tablets, the clocking
> architectures are far too varied and flexible for this to work usefully.
> This is before you get into things that are genuine hardware choices and
> need to be enumerated at runtime, and of course most modern devices will
> require software to power them on so you need to match them up with the
> relevant driver to do that.
>
> In general pluggable reference boards really need to have some means of
> identifying the connected boards if they want to support running with
> different setups without recompilation.  For example, the Wolfson
> reference systems have ID chips on each board which are queried during
> boot to allow us to instantiate things based on what's physically
> connected.  We can swap boards over and have a single system image boot
> successfully without software changes.
>
> > 4) Any other ideas ?
>
> I don't think you've fully thought through what you're suggesting, it
> doesn't seem practical for most things.
>



-- 
“Karmanya vadhikaraste ma phaleshu kadachana Ma karma-phala-hetur bhu ma te
sango stav karmani”           -  Krishna

Re: ASOC - Codecs : Renaming of spdif_tranceiver.c

[Mark Brown]

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

On Wed, Mar 07, 2012 at 07:45:24PM +0530, Nitin PAI wrote:

Don't top post, and please don't do things like reordering content.

> The usecase for the DSP was specifically for automotive where there is no
> power requirements and the audio functionality is always on.
> The programming of the codecs usually from the userspace.  However ALSA is
> used  for ease of using the alsalib for its various functions (applications
> standpoint).

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 

> >>The CPU side drivers have no dependency on the CODEC drivers, these are
> >>integrated by the machine.  The SoC vendor can easily ship drivers which
> >>will work with any CODEC which works well on Linux.

> The problem with just writing the machine driver and shipping it is,
> without any codec driver the cards wont be enumerated.
> Having a thin codec driver to enumerate the cards and ship it will help.
> (from debug and development standpoint).

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.

>  >>Another option is to just embed all the data
> >>structures in a single driver which binds to them all and selects the
> >>right data structure based on the probe information, that might be
> >>useful.

> Are you suggesting to have this in the machine driver?  I didnt understand
> this, please clarify.

No, obviously CODEC drivers should be handling by CODECs...

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

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

Re: ASOC - Codecs : Renaming of spdif_tranceiver.c

[Nitin PAI]

Hi Mark,

>>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.

>>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?
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?
This can help in many phases of design like emulation, bringup (doing
loopback between 2 interfaces at SOC level)?

So far I have been using ALSA for the userspace utilites it supports
(alsalib), for codec support I dont feel need that
its absolutely needed (spdif/hdmi for instance) and this can be applied to
even other machine drivers.

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

Thanks,
Nitin

Re: ASOC - Codecs : Renaming of spdif_tranceiver.c

[Mark Brown]

[-- 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 --]

Re: ASOC - Codecs : Renaming of spdif_tranceiver.c

[Nitin PAI]

>You can add debugfs information to dump the capabilities and whatnot if
>>that's useful to you...
If the cards are not enumerated all these dont make any sense.

>>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.
Clocks need not come from the codec, it can come from on of the other
masters in the system.

>>Honestly it just sounds like you want to write some machine drivers for
>>your systems.
Yes, thats the purpose, but I want to ship them to for the reasons I
mentioned above.
Since the enumeration of the machine driver depends on the linkage with the
codec driver its not possible for me to write.
I wish that the spdif_tranceiver was written for more generalized cases and
not just spdif.

Thanks,
--Nitin

Re: ASOC - Codecs : Renaming of spdif_tranceiver.c

[Mark Brown]

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

On Wed, Mar 07, 2012 at 09:58:56PM +0530, Nitin PAI wrote:

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

> If the cards are not enumerated all these dont make any sense.

The DAI and so on drivers come up all by themselves and need to do so
prior to the cards actually instantiating so we can create debugfs stuff
for them as soon as they register if we want to.

> >>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.

> Clocks need not come from the codec, it can come from on of the other
> masters in the system.

Right, exactly - the point is that the machine driver makes the decision
about the clocking architecture of the given system, the individual
drivers can't reasonably make that decision themselves.

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

> Yes, thats the purpose, but I want to ship them to for the reasons I
> mentioned above.
> Since the enumeration of the machine driver depends on the linkage with the
> codec driver its not possible for me to write.
> I wish that the spdif_tranceiver was written for more generalized cases and
> not just spdif.

Well, just write a CODEC driver that matches what you've got down on
your boards.  Usually the driver does need to enforce some kind of
limits (on input format and sample rate normally) even for a simple
device with no software control otherwise the device can get driven
out of spec.

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

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

Re: ASOC - Codecs : Renaming of spdif_tranceiver.c

[Nitin PAI]

>>Well, just write a CODEC driver that matches what you've got down on
>>your boards.  Usually the driver does need to enforce some kind of
>>limits (on input format and sample rate normally) even for a simple
>>device with no software control otherwise the device can get driven
>>out of spec.
The CODEC is part of the system integration process. From SOC standpoint
the machine driver is what needs to be delivered.
I dont know finally what the final codec will be, its upto the integrator
to write.  May be he can pick the ones from the asoc:codecs list.


I dont like the dependency of the machine driver with the codec driver for
enumeration. Machine driver can self exist without having for the codec
driver. [USB, PCi, HDMI, S/PDIF]  However the vice-versa is not true and is
of no use.  Binding them together will make the usecases easy (power for
instance, user interaction), but should not have been a hardlimit.  Given
the thought process, ALSA should allow dummy_codec drivers which it does
(from spdif_tranceiver.c),  but why not make it completely generic? (remove
the s/pdif keywords).

Thanks for your ideas about the hdmi driver, will check how is that
handling this dependency on codec driver.

--Nitin

Re: ASOC - Codecs : Renaming of spdif_tranceiver.c

[Nitin PAI]

>>Usually the driver does need to enforce some kind of
>>limits (on input format and sample rate normally) even for a simple
>>device with no software control otherwise the device can get driven
>>out of spec.
Agreed. This is more of a system integration problem then the machine
driver problem.
Most of these enforcements are already present in the machine driver.


--Nitin

Re: ASOC - Codecs : Renaming of spdif_tranceiver.c

[Mark Brown]

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

On Wed, Mar 07, 2012 at 10:23:59PM +0530, Nitin PAI wrote:

Please fix your quoting, you're not attributing and you're double
quoting things.

> >>Well, just write a CODEC driver that matches what you've got down on
> >>your boards.  Usually the driver does need to enforce some kind of
> >>limits (on input format and sample rate normally) even for a simple
> >>device with no software control otherwise the device can get driven
> >>out of spec.

> The CODEC is part of the system integration process. From SOC standpoint
> the machine driver is what needs to be delivered.
> I dont know finally what the final codec will be, its upto the integrator
> to write.  May be he can pick the ones from the asoc:codecs list.

Well, quite - if you're working with a system then you need a machine
driver.

> I dont like the dependency of the machine driver with the codec driver for
> enumeration. Machine driver can self exist without having for the codec
> driver. [USB, PCi, HDMI, S/PDIF]  However the vice-versa is not true and is

In the USB case we're going to be going nowhere near ASoC anyway,
there's a totally orthogonal hardware design and set of drivers at the
ALSA level.  Similarly for PCI, though obviously it's possible to make a
PCI card which is decomposed enough to make sense to support via ASoC.

In the S/PDIF case you do actually have a CODEC - while it's common for
this to be a fixed function hardware CODEC (in which case you need a
stub driver saying what it looks like within the system as I said above)
this isn't always the case.  For example, the WM8804 in mainline is a
S/PDIF transciever with register control.  The effort required to bolt
on fixed function drivers (or try to parameterise a generic one if
someone wants to do that) is so trivial it really doesn't seem worth
caring about.  HDMI is broadly similar to S/PDIF here.

> of no use.  Binding them together will make the usecases easy (power for
> instance, user interaction), but should not have been a hardlimit.  Given
> the thought process, ALSA should allow dummy_codec drivers which it does
> (from spdif_tranceiver.c),  but why not make it completely generic? (remove
> the s/pdif keywords).

Allow me to suggest again (as I did earlier in this thread) munging all
these dumb drivers together so you just have a bunch of things in the
one driver which the driver distinguishes by ID.  To repeat once more
you're always going to need to put in at least some information about
the limits the device has.

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

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

Re: ASOC - Codecs : Renaming of spdif_tranceiver.c

[Mark Brown]

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

On Wed, Mar 07, 2012 at 10:34:21PM +0530, Nitin PAI wrote:

> >>Usually the driver does need to enforce some kind of
> >>limits (on input format and sample rate normally) even for a simple
> >>device with no software control otherwise the device can get driven
> >>out of spec.

> Agreed. This is more of a system integration problem then the machine
> driver problem.
> Most of these enforcements are already present in the machine driver.

Perhaps your BSP is doing things differently to mainline here; it's
vanishingly rare in mainline for machine drivers to enforce any limits
themselves.  Usually the CODEC and SoC drivers do this.

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

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

Re: ASOC - Codecs : Renaming of spdif_tranceiver.c

[Nitin PAI]

>>Perhaps your BSP is doing things differently to mainline here; it's
>>vanishingly rare in mainline for machine drivers to enforce any limits
>>themselves.  Usually the CODEC and SoC drivers do this.
I meant the SoC drivers can still enforce these limits, and need not rely
on CODEC driver.

--Nitin

Re: ASOC - Codecs : Renaming of spdif_tranceiver.c

[Mark Brown]

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

On Wed, Mar 07, 2012 at 11:28:49PM +0530, Nitin PAI wrote:
> >>Perhaps your BSP is doing things differently to mainline here; it's
> >>vanishingly rare in mainline for machine drivers to enforce any limits
> >>themselves.  Usually the CODEC and SoC drivers do this.

> I meant the SoC drivers can still enforce these limits, and need not rely
> on CODEC driver.

Usually the CODEC will be way more limited than the SoC, for example the
WM8727 (which is one of these dumb drivers) only supports sample rates
down to 32kHz but I'd be astonished if a SoC didn't do standard audio
rates from 8kHz up.

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

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