Re: [PATCH 00/13] Better handle pads for tuning/decoder part of the devices

[Mauro Carvalho Chehab <mchehab+samsung@kernel.org>]

Em Thu, 2 Aug 2018 11:12:23 +0200
Hans Verkuil <hverkuil@xs4all.nl> 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@cisco.com>
> 
> 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