Re: [PATCH 00/14] SPDIF support

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Sun, Sep 01, 2013 at 09:42:29AM +0200, Lars-Peter Clausen wrote:
> Lets try to wrap up the situation:
> 
> * The hardware has one audio stream, but two DAIs, one for SPDIF one for
> I2S. The same audio stream is sent to both DAIs at the same time (It is
> possible though to disable one or both of the DAIs).

More or less.  To be more clear: audio DMA commences when either one or
both outputs are enabled, and stops when both are disabled.

This is why either only one can be enabled, or if both are to be enabled,
both enable bits must be set in one register write, and when disabled,
both bits must be cleared in one register write.

So, lets say for argument sake that you wanted to go from disabled to a
single output, then to dual output, back to single output, and finally
back to disabled.  You would need this sequence:

- enable single output
...
- disable single output
- wait for audio unit to indicate not busy
- enable both outputs
...
- disable both outputs
- wait for audio unit to indicate not busy
- enable single output
...
- disable single output
- wait for audio unit to indicate not busy

> * This is something new and not supported by classical ASoC.
> 
> * DPCM has support for this, but DPCM is still new, unstable,
> under-documented and apparently has a couple of bugs.
> 
> * With non-DPCM ASoC it is possible to have two DAIs if they are not used at
> the same time (which is what I recommend you implement first, before trying
> to get DPCM running).

If you'd look at my other responses, you'll see that this is what I tried
back in May, and I was unhappy about that solution because:

1. there is no guarantee that they couldn't be used at the same time.
2. this results in two entirely separate "CPU DAI"s, each with their
   own independent sample rate/format settings, which if they happen
   to be used together will result in fighting over the same register(s).

Moreover, this results in a completely different set of changes to the
driver which are in an opposing direction to the DPCM approach.

> I still don't know if you actually need to feature of being able to output
> the same audio signal to both DAIs, do you have such a board?

This board has the SPDIF connected to a TOSlink and a HDMI transmitter.
It also has the I2S connected only to the HDMI transmitter, though it's
common at the moment to only use the SPDIF output to drive them both.

Having recently changed the TV connected to the HDMI, I find that where
audio used to work at 48kHz and 44.1kHz with the old TV, it no longer
works on anything but 44.1kHz.  The old TV converted everything to
analogue internally in its HDMI receiver before passing it for further
processing.  The new TV is a modern full HD model, so keeps everything in
the digital domain.  I have yet to work out why the TV is muting itself
with 48kHz audio.  However, audio continues to work via the TOSlink output
at both sample rates.

What I'm saying there is that we may need to have another codec in there
so the HDMI transmitter has access to parameters like the sample rate,
or we may have to switch it to using I2S for PCM audio and back to SPDIF
for compressed audio (I'm hoping not because I think that's going to be
an extremely hard problem to solve.)

This is a brand new problem which I've only discovered during last week.
As I have no SPDIF or HDMI analysers, I don't have an answer for this
at the moment, and the only way I can solve it is by verifying the
existing setup (which I believe is correct to the HDMI v1.3 spec) and
experimenting, which will take some time.

However, that's not a reason to hold up these patches - these patches
do work, and allow audio to be used on this platform in at least some
configurations.

> But even then
> I still recommend to first get the non-DPCM either/or approach implemented
> and once that's working try to get DPCM running. Which probably involves
> fixing some of the DPCM issues in the core. As I said sending the same audio
> streams to two DAIs is something new and if there was no DPCM yet you'd need
> to add support for sending the same stream to multiple DAIs. So either way
> you'd have to get your hands dirty.

Could you comment on the patch which creates the two front-end DAIs which
I sent in a different sub-thread - the one which I indicated was from back
in May time.  It isn't quite suitable for submission because the base it
applies to has changed since then, but it should be sufficient to give an
idea of the solution I was trying to implement there.

> And I'm sure people are willing to help
> you figure out the parts you don't understand yet if you ask _nicely_.

Can you then please explain why when I ask for help understanding DAPM
in a "nice" way, the response I get is just "it's just a graph walk"
and no further technical details?

I explained DAPM as I understood it to someone who knows nothing about it
a fortnight ago, and this is how I described DAPM with only a basic
understanding of it, most of that gathered by having been through some of
the code with printk()s to work out some of the problems I was seeing:

| DAPM is a set of "widgets" representing various components of an
| audio system.  The widgets are linked together by a graph.  Each
| widget lives in a context - cpu, platform or codec.  Some bindings
| only happen within a context, others cross contexts (so linking the
| CPU audio stream to the codec for example)

I didn't want to go into the complexities of which widgets are activated
when a stream starts playing, or the special cases with the various
different types of widget that affect the walking and activation of the
graph.

Notice how much more information there - though it wasn't _that_ coherent
(rather than using "linked" it should've been "bound").  The point is,
I've described that there are widgets, there's a binding of widgets
together, the widgets are associated with a context, and finally that
there are restrictions on what bindings can happen.

I've probably missed out quite a bit too without really knowing it -
because I don't know it yet either.  Yes, I do know about the
Documentation/sound/alsa/soc/dapm.txt document.

> I mean I don't come to you either if I have a new ARM SoC that's not
> supported yet and demand that you implement support for it and exclaim
> that the ARM port sucks because it doesn't support that SoC yet.

If you come to me and ask about something in ARM, then you will most
likely get something more than a few words explaining a big chunk of
code - a bit like the oops report I disected last night and provided
full reasoning of the conclusion that I came to (SDRAM failure /
hardware fault on bit 8 of the SDRAM data bus.)