Re: [PATCH v7.1 00/19] Rework OMAP4+ HDMI audio support

On 21/11/14 18:14, Mark Brown wrote:

On Fri, Nov 21, 2014 at 02:35:07PM +0200, Jyri Sarha wrote:

quoted

On 11/21/2014 01:23 PM, Mark Brown wrote:

quoted

quoted

With this specific series I also need to figure out what all the video
side is about (like I said earlier a lot of the patches look like
they're supposed to be simple fixes for the video code not terribly
closely tied to the rest of the series but none of them are getting
applied) and what the end goal is beyond mechanically moving code.

quoted

The end goal of this series is to fix OMAP HDMI audio, that got broken
couple of releases ago. At the same time I cleaned up the old complex scheme
to make the connection between the video and audio parts and allow multiple
HDMI devices (DSS side is not ready for this yet, but audio side is).

But in what way is it broken and how did this happen?  Why are none of

I don't have a clear answer, but it probably involves lack of use, and
buggy and hard to use implementation. Things have changed around the
original HDMI audio implementation, and it stopped working at some point.

As the original implementation was found rather lacking, and with some
fundamental issues, it was deemed better to have a fresh approach.

the patches which look like they're supposed to be bug fixes early on in
the series getting applied?  I had thought this was just a lack of
interest on the video side but it seems there's some other problems
since the series has apparently been discussed off-list and still it's
just as big as it was initially.

The whole series is about HDMI audio, not video.

The main HDMI driver resides in the fbdev directory, as the video side
is the "master" here, and it contains the code to access the registers
(including audio related registers). The sound/ part in this series acts
as a logic between the asoc and the low level HDMI driver.

This series only touch the parts about HDMI audio, so the fixes early on
don't really fix anything without the rest of the series (as the current
HDMI audio doesn't work).

And in any case, I don't like applying individual patches from a series.
Usually that just complicates things. If I would apply some of the early
patches to fbdev, then this series would no longer work on plain
mainline kernel, and would instead depend on fbdev tree. The situation
would be ever worse if you'd also pick some of the audio patches to
sound tree, creating a dependency to two subsystem trees.

So if there's no particular important reason to pick patches from a
series, I rather keep it as a whole to simplify merging and testing.

 Tomi