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

On Thu, 18 Sep 2014 00:13:09 +0300
Jyri Sarha [off-list ref] wrote:

quoted

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