From patchwork Sat Sep 15 20:14:15 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mauro Carvalho Chehab X-Patchwork-Id: 10601565 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 5137715E8 for ; Sat, 15 Sep 2018 20:14:41 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 381432A9D4 for ; Sat, 15 Sep 2018 20:14:41 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 18B80294C7; Sat, 15 Sep 2018 20:14:41 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 950D2294C7 for ; Sat, 15 Sep 2018 20:14:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727746AbeIPBer (ORCPT ); Sat, 15 Sep 2018 21:34:47 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:43364 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727691AbeIPBer (ORCPT ); Sat, 15 Sep 2018 21:34:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=Sender:Message-Id:Date:Subject:Cc:To: From:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=hHrLbWxjZ3/+/NQWLbhO8t59+XQf3/tdBj0yw2BqYwM=; b=GrT0XSyOhM6IUAoGYvp6k+wSxN auuEXK0/z4mSjp/usa/dtsMCjWjjVYdBuXKUl3Wifv4VwuwihDiCq130uuj/1yYG/5Ib1VPSjJhYB 5PINYJmlsvNwJO+IfvC7RP4fGwQTfYDP4MQvYeIFpp3y+La9bDav5GYS8lNXtr9+xC+CiTJ5CZh6Q tDvB54YMBr/SZ3+N6ZVirP50xBUrpxVrY9DktnGudsKx+u9sL20a4BAufskw6kJxK5ENXP4aW8wiQ /R9mfViSBHJcmAfjTSXQrtSWbKIeyX4jOtIUlhjiJqvsrjQte8RhLE2lNx/9ywcLlNXdBB/piX3Fh igaHVrOw==; Received: from [179.95.0.169] (helo=bombadil.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1g1Gxe-0002Oy-I9; Sat, 15 Sep 2018 20:14:35 +0000 Received: from mchehab by bombadil.infradead.org with local (Exim 4.91) (envelope-from ) id 1g1Gxb-0008Re-OU; Sat, 15 Sep 2018 17:14:31 -0300 From: Mauro Carvalho Chehab To: Linux Media Mailing List Cc: Mauro Carvalho Chehab , Mauro Carvalho Chehab Subject: [PATCH v2 00/14] Better handle pads for tuning/decoder part of the devices Date: Sat, 15 Sep 2018 17:14:15 -0300 Message-Id: X-Mailer: git-send-email 2.17.1 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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. --- v2: - Fix some issues noticed while testing with WinTV USB2. As result of such tests, I opted to use just one type for all analog signals. - Added a patch to provide some info if something gets wrong while creating the links. Mauro Carvalho Chehab (14): media: v4l2: remove VBI output pad media: v4l2: taint pads with the signal types for consumer devices v4l2-mc: switch it to use the new approach to setup pipelines media: v4l2-mc: add print messages when media graph fails media: dvb: use signals to discover pads media: au0828: use signals instead of hardcoding a pad number media: au8522: declare its own pads media: msp3400: declare its own pads media: saa7115: declare its own pads media: tvp5150: declare its own pads media: si2157: declare its own pads media: saa7134: declare its own pads media: mxl111sf: declare its own pads media: v4l2-mc: get rid of global pad indexes drivers/media/dvb-core/dvbdev.c | 19 ++- drivers/media/dvb-frontends/au8522_decoder.c | 10 +- drivers/media/dvb-frontends/au8522_priv.h | 9 +- drivers/media/i2c/msp3400-driver.c | 6 +- drivers/media/i2c/msp3400-driver.h | 8 +- drivers/media/i2c/saa7115.c | 18 ++- drivers/media/i2c/tvp5150.c | 21 ++- drivers/media/media-entity.c | 26 ++++ drivers/media/pci/saa7134/saa7134-core.c | 9 +- drivers/media/pci/saa7134/saa7134.h | 8 +- drivers/media/tuners/si2157.c | 11 +- drivers/media/tuners/si2157_priv.h | 9 +- drivers/media/usb/au0828/au0828-core.c | 12 +- drivers/media/usb/dvb-usb-v2/mxl111sf.c | 8 +- drivers/media/usb/dvb-usb-v2/mxl111sf.h | 8 +- drivers/media/v4l2-core/tuner-core.c | 54 +++++++- drivers/media/v4l2-core/v4l2-mc.c | 135 +++++++++++++++---- include/media/media-entity.h | 48 +++++++ include/media/v4l2-mc.h | 78 ----------- 19 files changed, 347 insertions(+), 150 deletions(-)