exynos drm hdmi audio: how to recieve audio parameters (sf, bps, channel count)

[Lars-Peter Clausen]

On 07/20/2012 01:44 PM, RAHUL SHARMA wrote:
> 
> On Fri, Jul 20, 2012 at 11:40 AM, RAHUL SHARMA <rahul.sharma at samsung.com> wrote:
>>
>>
>> ------- Original Message -------
>> Sender : Lars-Peter Clausen<lars at metafoo.de>
>> Date : Jul 19, 2012 19:12 (GMT+05:30)
>> Title : Re: exynos drm hdmi audio: how to recieve audio parameters (sf, bps, channel count)
>>
>> On 07/19/2012 02:22 PM, Rob Clark wrote:
>>> On Tue, Jul 17, 2012 at 1:12 AM, RAHUL SHARMA wrote:
>>>> hi,
>>>>
>>>> I am adding support for hdmi audio, inside exynos drm hdmi driver. Hdmi audio is initialized with default parameters. I want to implement the mechanism to update hdmi registers, whenever audio properties got changed (i2s/spdif). raedon/r600 drm dirver is polling the audio ip every 100 ms and reconfigure the hdmi audio block. This is not possible with exynos as all information cannot be collected from i2s tx registers. It is directly set on wm8994 connected through i2c.
>>>> Possible solution:
>>>> 1) drm driver exposing ioctl for setting audio parameters.
>>>> 2) alsa driver notifying the change in audio parameters through kernel notifiers. drm hdmi driver subscribed for the same.
>>>
>>> I am certainly not an audio expert, but I am pretty sure something
>>> along the lines of solution #2 would be better.  I don't think
>>> userspace would want to know about some exynos drm specific ioctls in
>>> order to make audio work.
>>>
>>> BR,
>>> -R
>>
>>
>> I don't know how the audio setup for exynos HDMI hardware looks like, so
>> this might not be applicable in this case. But what I did for HDMI
>> transmitter I was working on, is to register a ASoC codec device as a
>> subdevice to the HDMI transmitter. All access to the sound registers is done
>> from that subdevice and you don't need any special notifier hooks, since you
>> can use the normal alsa driver callbacks.
>>
>> It might be a good idea if you could describe how your setup looks exactly.
>> E.g. which components does the audio stream pass through, where does it
>> originate and how the different components related to each other.
>>
>> - Lars
> 
> Thanks Lars, Rob, Kyungmin,
> 
> In exynos, i2s and spdif DAIs configure the i2s, spdif tx IP regs. In hw, I2s and
> spdif tx o/p pins are also connected to the i2s-In and spdif-In blocks of hdmi tx.
> Drm hdmi sub driver needs to configure the i2s-In and spdif-In blocks with the
> same setting as in i2s and spdif tx IPs. Hdmi is solely accessed by drm driver
> where hdmi is registered as a sub-driver along with lcd sub-driver. I hope, I am
> able to explain the flow and connections, through above.

With this setup, I think, implementing the HDMI audio as a ASoC codec driver
is the right approach.

> 
> Lars, how can I refer your implementation where Adding 'hdmi audio' as a seperate
> subdrv. If I understand correctly, it will be exposed as a seperate sound card,
> parallel to i2s and spdif cards, which user app accesses and configure and about
> scenarios with hpd.

With ASoC you can build complex sound card consisting out of multiple
components. E.g. SPDIF DAI + HDMI codec is a sound card and the settings
applied to that sound card will be send to both the SPDIF DAI and the HDMI
codec, so you can be sure that both have a matching config. You need to have
a ASoC board driver though which describes how DAI and codec are
interconnected, but you'll need that anyway to get a sound card for the
SPDIF controller instantiated, so that should not be a problem.

> 
> Kyungmin, about adding ioctl; it looks clean, but as Rob stated, is it a right way as drm
> framework is primarily meant for gfx/video configurations? Please exaplin me this point.

>From a technical point of view using a custom IOCTL for this is a bad idea,
since you'll require special tools to make sound over HDMI work, while by
using the method described above the standard tools will work out of the box.

- Lars