On Sat, Jan 24, 2015 at 08:30:27AM +0100, Jean-Francois Moine wrote:
> Mark Brown <[email protected]> wrote:
> > On Fri, Jan 23, 2015 at 07:34:56PM +0100, Jean-Francois Moine wrote:
> > > The simple card builder, 'dt-card' (maybe a better name would have been
> > > 'graph-card'), acts just like the simple-card except that it does not
> > > appear in the DT. Its creation is done by an audio controller.
> > Which audio controller? There may be several CPU side audio interfaces
> > in the same card. For example people often want to have both low
> > latency and high latency audio paths from the CPU into the hardware (low
> > latency tends to increase power burn). SoC centric system designs do
> > sometimes also have PDM I/O, expecting to be directly connected to DMICs
> > and so on, which results in a relatively large number of CPU interfaces.
> The audio controller which creates the card depends on the complexity
> of the card. When there are many controllers, it is up to the designer
> to define either a master audio controller or to instantiate a 'card'
> device via the DT for doing the job.
So how does the simple controller interact with a more complex one given
that it's somehow picking some controller node to start from?
> > > Well, forget about this. I never clearly understood why some widgets
> > > and routes had to be defined at card level.
> > Please do try to understand the idea of representing simple components
> > on the board and analogue interconects between devices - it's really
> > important and not something that can be neglected.
> The problem is that this understanding would stay abstract: I have no
> such a hardware. Anyway, if the representation can be done with the
> simple-card, it may also be done with a graph of ports.
If you have a device with any sort of speaker or microphone, or any sort
of external connector for interfacing with an external device like a
headphone jack, then you have something that could be a widget.
> > That DT binding was done entirely in the context of video applications
> > IIRC, this is the first time it's been discussed in this context.
> http://mailman.alsa-project.org/pipermail/alsa-devel/2014-January/070622.html
> http://mailman.alsa-project.org/pipermail/alsa-devel/2015-January/086273.html
So there's been some in passing mentions, not really serious discussion
though...
On Tue, 3 Feb 2015 16:47:48 +0000
Mark Brown <[email protected]> wrote:
> On Sat, Jan 24, 2015 at 08:30:27AM +0100, Jean-Francois Moine wrote:
> > Mark Brown <[email protected]> wrote:
> > > On Fri, Jan 23, 2015 at 07:34:56PM +0100, Jean-Francois Moine wrote:
>
> > > > The simple card builder, 'dt-card' (maybe a better name would have been
> > > > 'graph-card'), acts just like the simple-card except that it does not
> > > > appear in the DT. Its creation is done by an audio controller.
>
> > > Which audio controller? There may be several CPU side audio interfaces
> > > in the same card. For example people often want to have both low
> > > latency and high latency audio paths from the CPU into the hardware (low
> > > latency tends to increase power burn). SoC centric system designs do
> > > sometimes also have PDM I/O, expecting to be directly connected to DMICs
> > > and so on, which results in a relatively large number of CPU interfaces.
>
> > The audio controller which creates the card depends on the complexity
> > of the card. When there are many controllers, it is up to the designer
> > to define either a master audio controller or to instantiate a 'card'
> > device via the DT for doing the job.
>
> So how does the simple controller interact with a more complex one given
> that it's somehow picking some controller node to start from?
A way to solve this problem could be to create only one card builder.
This creation could be explicit (created by the first active audio
controller) or implicit by the audio subsystem on the first controller or
CODEC creation.
Then, the card builder could scan all the DT looking for the audio
ports and create one or more cards according to the graph connectivity.
> > > > Well, forget about this. I never clearly understood why some widgets
> > > > and routes had to be defined at card level.
>
> > > Please do try to understand the idea of representing simple components
> > > on the board and analogue interconects between devices - it's really
> > > important and not something that can be neglected.
>
> > The problem is that this understanding would stay abstract: I have no
> > such a hardware. Anyway, if the representation can be done with the
> > simple-card, it may also be done with a graph of ports.
>
> If you have a device with any sort of speaker or microphone, or any sort
> of external connector for interfacing with an external device like a
> headphone jack, then you have something that could be a widget.
I know what are the widgets and routes, I was just wondering why they
(especially the widgets) need to appear at the card level instead of
just being declared in the DAIs (from the platform or the DT).
And the same question may also be raised about the audio formats, clocks,
tdm's...
> > > That DT binding was done entirely in the context of video applications
> > > IIRC, this is the first time it's been discussed in this context.
>
> > http://mailman.alsa-project.org/pipermail/alsa-devel/2014-January/070622.html
> > http://mailman.alsa-project.org/pipermail/alsa-devel/2015-January/086273.html
>
> So there's been some in passing mentions, not really serious discussion
> though...
I may go back about the card builder, but Russell's idea about
declaring the tda998x audio parameters by a port as declared in a graph
of ports seems fine to me. This declaration should be compatible with
the use of the simple-card.
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
On Tue, Feb 03, 2015 at 08:31:30PM +0100, Jean-Francois Moine wrote:
> Mark Brown <[email protected]> wrote:
> > So how does the simple controller interact with a more complex one given
> > that it's somehow picking some controller node to start from?
> A way to solve this problem could be to create only one card builder.
> This creation could be explicit (created by the first active audio
> controller) or implicit by the audio subsystem on the first controller or
> CODEC creation.
> Then, the card builder could scan all the DT looking for the audio
> ports and create one or more cards according to the graph
> connectivity.
How is this going to work with dynamically instantiated hardware like DT
overlays?
> > If you have a device with any sort of speaker or microphone, or any sort
> > of external connector for interfacing with an external device like a
> > headphone jack, then you have something that could be a widget.
> I know what are the widgets and routes, I was just wondering why they
> (especially the widgets) need to appear at the card level instead of
> just being declared in the DAIs (from the platform or the DT).
As previously and repeatedly discussed DAIs have no special place in
a general audio system and we can't base the entire system off them.
Which DAI should have the headphone jack connected to the analogue only
headphone driver in my system (there may not even be a way to route
digital audio to it)? How does this work for off-SoC audio hubs where
there is a device with multiple DAIs connected to both one or more other
digital devices and the analogue?
Please go and research this if you're intending to work on generic
bindings, it gets extremely repetitive to have to go over this again and
again. We already have simple-card to provide a binding for trivial
systems and don't want to end up with a never ending series of slightly
more complicated bindings which each cover slightly different sets of
systems in ways that users struggle to differentiate between.
> And the same question may also be raised about the audio formats, clocks,
> tdm's...
Similar things here - which of the two or more devices on a digital
audio link (yes, they're buses not point to point links) has the
configuration and how do we stitch them together? How do we figure out
when and how to do runtime reconfiguration of the clock tree (which is
needed by some systems)?
Again, please do some research on this. If you are trying to define
generic device tree bindings it is really important that you understand
what you are trying to model with those bindings.