[Intel-gfx] Need your advice: Add a new communication inteface between HD-Audio and Gfx drivers for hotplug notification/ELD update

[Rob Clark]

On Wed, Jan 22, 2014 at 10:20 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Wed, Jan 22, 2014 at 10:04:14AM -0500, Rob Clark wrote:
>> sorry to jump into this a bit late, so maybe this was covered already earlier..
>
> It just started, I've quoted everything when cc'ing dri-devel. But good to
> have examples outside of x86 (where things are mostly standardized by the
> Eye of Redmond).

perhaps the arm/SoC stuff was standardized by the Eye of Cthulhu

btw, added a few other SoC drm types who might be interested in the topic

>> For drm/msm the hdmi code needs something along these lines from audio:
>>
>> int hdmi_audio_info_setup(struct platform_device *pdev, bool enabled,
>>         uint32_t num_of_channels, uint32_t channel_allocation,
>>         uint32_t level_shift, bool down_mix);
>> void hdmi_audio_set_sample_rate(struct platform_device *pdev, int rate);
>>
>> (former is mainly to setup avi audio infoframe, latter for clks)
>>
>> in addition to hotplug and ELD stuff
>
> Can you elaborate a bit on what you need for msm? On intel (and I think
> the other x86 platforms are similar) we have separate buffers in the hw
> for avi infoframes and audio infoframes, so the drm and alsa driver can
> bash the right stuff into the hardware on their own. I'm mostly confused
> since you say _AVI_ infoframe here, which is purely generated by the drm
> side of the code here. Or at least that's been my understanding.

Sorry, typo, meant audio infoframe

We could have the API such that the audio driver constructs the
infoframe.. that probably makes more sense and simplifies things.  But
the drm driver is the one that needs to bash that constructed buffer
into the hw.  Or, well, either that or both drivers ioremap the same
block of registers, but that seems somewhat lame.

But I do need to know some basic things, like # of channels.. and
would kinda prefer not to have to parse the audio infoframe to get
that info.

> The clocks are also funny really, but I'm not sure whether this fits. I'd
> have expected some DT-based generic clock source which the audio driver
> just grabs as part of his multi-device beast (maybe using Russell's new
> driver core code) and used directly. What's the reason that this has to go
> through the drm driverr?

possibly it could be exposed to the audio driver as a 'struct clk'
that is implemented/registered/exported by the drm driver, I guess?


fwiw, if curious, what I have on msm so far is at:

https://github.com/freedreno/kernel-msm/commit/6ffd278d39a3ff8712c70b5fd98dc135bd6c7b8a

It works on downstream qcom android kernel.. the API exported by drm
driver, called by audio driver, is basically just a clone of the hack
that was already there between fbdev and alsa.  I haven't tried to
clean that up at all yet.  It was enough work just untangling ION (!!)
from alsa in that kernel :-/

BR,
-R

> Cheers, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch