Em Thu, 2 Aug 2018 11:12:23 +0200 Hans Verkuil <hverkuil@xxxxxxxxx> escreveu: > On 08/01/18 17:55, Mauro Carvalho Chehab wrote: > > At PC consumer devices, it is very common that the bridge same driver > > to be attached to different types of tuners and demods. We need a way > > for the Kernel to properly identify what kind of signal is provided by each > > PAD, in order to properly setup the pipelines. > > > > The previous approach were to hardcode a fixed number of PADs for all > > elements of the same type. This is not good, as different devices may > > actually have a different number of pads. > > > > It was acceptable in the past, as there were a promisse of adding "soon" > > a properties API that would allow to identify the type for each PADs, but > > this was never merged (or even a patchset got submitted). > > > > So, replace this approach by another one: add a "taint" mark to pads that > > contain different types of signals. > > > > I tried to minimize the number of signals, in order to make it simpler to > > convert from the past way. > > > > For now, it is tested only with a simple grabber device. I intend to do > > more tests before merging it, but it would be interesting to have this > > merged for Kernel 4.19, as we'll now be exposing the pad index via > > the MC API version 2. > > Other than a small comment for the last patch I didn't see anything > problematical in this series. It doesn't touch on the public API or > on any of the non-tuner drivers. So for patches 1-12: > > Acked-by: Hans Verkuil <hans.verkuil@xxxxxxxxx> > > And after adding back the documentation for the enums in patch 13 you > can add my Ack to that one as well. Thank you! I changed patch 13 to keep the documentation and added your ack: https://git.linuxtv.org/mchehab/experimental.git/log/?h=pad-fix-3 Thanks, Mauro
