On Wed, Jan 22, 2014 at 10:20 AM, Daniel Vetter daniel@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/6ffd278d39a3ff8712c70b5fd98dc...
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