Re: [PATCH v3 4/5] ASoC: davinci: HDMI audio build for AM33XX and TDA998x

[Jean-Francois Moine <moinejf@free.fr>]

On Thu, 18 Sep 2014 00:13:09 +0300
Jyri Sarha <jsarha@ti.com> wrote:

> > So, Jean-Francois is also trying to do things with the TDA998x - what's
> > the story with that, is this joined up at all?
> 
> Not really. This basic functionality does not touch tda998x at all on 
> the fly, but just sets i2s configuation in the beginning and bangs the 
> bits trough McASP. But as long as the old platform data for tda998x 
> still works after Jean-Francois' patches I should be safe.

It should. And you may test it.

> The problem with the Jean-Francois' patches is the DT support. The BBB 
> HDMI video is implemented trough tilcdc-slave mechanism without a DT 
> node for the tda encoder, which renders Jean-Francois' approach unusable 
> for BBB.

I used the TDA998x with DT support for a long time with a hack by using
parts of drm_i2c_encoder_init(). Now, I think that this function could
be used as it is just setting no platform_data in info.

> The whole tilcdc slave approach may not be the most elegant way to use 
> the tda driver, but it does not look like it is going to change any time 
> soon.

Right: I proposed a patch for that and it was rejected.

> Best regards,
> Jyri
> 
> ps. I have been thinking on something similar to Jean-Francois' patch 
> for SiI9022 which I have been working on lately. Also I have been 
> wondering if it would be possible to come up with a generic ASoC codec 
> component driver or library that could be used with any HDMI encoder to 
> produce the ASoC codec component. Unfortunately I am in too early stage 
> to produce anything more concrete.

Here are some thoughts about this topic.

The video and audio worlds don't know about each other.
The only solution I found is to let the encoder create the codec as
a child device. Then, the codec knows from which encoder it depends.
This could have been done using Russell's components, but the codec
should have been declared in the DT. This is not useful.

The codec interacts with the encoder in 2 ways:
- it uses the HDMI parameters retrieved by the encoder,
- it gives the audio source type to the encoder.
I used exported functions for that, but, for a generic codec, theses
functions could be given through the codec platform_data.

The codec declares the DAI(s) prior to know the encoder. The DAI table
must be in the codec because of the snd_soc_dai_ops.
For a generic codec, this DAI table could be built dynamically from
information (name, id) also given through the codec platform_data.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html