On Sat, Aug 01, 2015 at 12:44:06PM +0300, Laurent Pinchart wrote:
On Friday 31 July 2015 08:21:16 Kuninori Morimoto wrote:
Hi Lars
The reason why the driver is not upstream at the moment is that the way it implements things is definitely not the right way. But there is still a lot of discussion on what actually is the right way to implement audio support for HDMI devices. Once that has been sorted out the driver will hopefully go upstream.
Beside the in-kernel API, have you given a thought to DT bindings for HDMI encoders ? Some platforms use DT bindings based on OF graph for the video path, would it make sense to model the audio path similarly ? The implementation could become a bit of a challenge though.
It's a bit of a struggle to get anyone to consider the generic problems for HDMI at all - Russell did some really nice work with the EDID handling but that's been about it. There was some talk about replacing simple card with a graph based simple card but it hasn't been moving quickly.
Personally I'm not 100% sure how relevant binding issues will be to the HDMI integration - as far as I can tell the integration of audio and video is generally happening within a single device (either an external encoder or the SoC itself) so it's not something that needs to be represented externally to that device and there's sometimes some flexibility about the connections internal to the device so we don't want to nail things up entirely in DT even if it was needed. There may be other kinds of hardware I'm not familiar with here where it does become important though, or I may be missing things.