On Mon, Nov 24, 2014 at 10:18:31AM +0200, Tomi Valkeinen wrote: > On 21/11/14 18:14, Mark Brown wrote: > > 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. OK... this is all telling me that I *really* need to scrub this in detail. It's all sounding very vague, it's an area which seems to cause lots of problems and I don't want to be sitting here next time around trying to figure out if another rewrite makes things better or worse or if another driver should look similar or different. > > 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. You know exactly what I mean - the early patches are in drivers/video, don't touch anything outside of that and have no obvious dependencies. > 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 But I thought everyone was saying this hardware doesn't work anyway and that you want to apply all these changes to fbdev? > 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. This means we're all then stuck reading reposts of the same enormous series over and over again - as a reviewer a really big series that appears from the subject lines to be mostly about another system is really offputting. If you're going to do something like this please at least reply to the messages, that way it's clearer that there's not going to be a dependency problem getting the patches applied (which is part of what makes things offputting).
Attachment:
signature.asc
Description: Digital signature
