From patchwork Tue Jul 31 17:02:09 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: 10551077 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 4331B15E2 for ; Tue, 31 Jul 2018 17:02:22 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2FDD12B0B6 for ; Tue, 31 Jul 2018 17:02:22 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 23F202B0F8; Tue, 31 Jul 2018 17:02:22 +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 BC0FE2B0B6 for ; Tue, 31 Jul 2018 17:02:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732223AbeGaSnd (ORCPT ); Tue, 31 Jul 2018 14:43:33 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:36672 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732215AbeGaSnc (ORCPT ); Tue, 31 Jul 2018 14:43:32 -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=Pk//gvtxir31bnE8TbxH95WhB9bOxPrwvBmta6QsC0o=; b=t35/L7kyBuNnIV1ulNlx5x75f2 tSblruDgPp0JCpgXooKtzK26MPGsmnUs57tYkyMhI/GinJrPWiM3G/PRWSUumzpNrFZdvA1Wb/LJD K/1KXhIqaaXomSFDwqyb2YsXvsJPr+B0Sfu0Vv0wgo5K1UCrTxAl2HYNHukz5Af7h8qrbL/88VAZ+ 78fWKgc9EN6TAW5H/rB6268+Xyb+i9+53H70SqHZ+7wjFUYYkRsQCAmfzk3pRph2FeB1tb6yqus6Q 0LMARfPlVSa6na0U6N3xmB9jRrn0ryJbDbwfr9WDDGMFN+N520eB2I8NkOQl26WyCVIV288gKCW2e CmwOU/kg==; Received: from [179.182.165.210] (helo=bombadil.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1fkY2L-0002av-QK; Tue, 31 Jul 2018 17:02:17 +0000 Received: from mchehab by bombadil.infradead.org with local (Exim 4.91) (envelope-from ) id 1fkY2J-0007c7-8J; Tue, 31 Jul 2018 14:02:15 -0300 From: Mauro Carvalho Chehab To: Linux Media Mailing List Cc: Mauro Carvalho Chehab , Mauro Carvalho Chehab , Kees Cook , Brian Warner , Hans Verkuil , Antti Palosaari , Sakari Ailus , Laurent Pinchart , Shuah Khan , Michael Krufky , Pravin Shedge Subject: [PATCH RFC 0/4] Better handle pads for tuning/decoder part of the devices Date: Tue, 31 Jul 2018 14:02:09 -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. However, I'm not inspired today to give names to the signals each pad contain. So, feel free to give better suggestions if this one doesn't fit too well. For now, this is just a RFC, compile-tested only, as the main goal here is to discuss about an approach. Once I get enough feedback, I'll do some tests. Mauro Carvalho Chehab (4): 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: dvb: use signals to discover pads drivers/media/dvb-core/dvbdev.c | 37 ++++++++- drivers/media/dvb-frontends/au8522_decoder.c | 4 +- drivers/media/i2c/msp3400-driver.c | 2 + drivers/media/i2c/saa7115.c | 3 +- drivers/media/i2c/tvp5150.c | 3 +- drivers/media/pci/saa7134/saa7134-core.c | 3 +- drivers/media/tuners/si2157.c | 3 + drivers/media/usb/dvb-usb-v2/mxl111sf.c | 2 + drivers/media/v4l2-core/tuner-core.c | 5 ++ drivers/media/v4l2-core/v4l2-mc.c | 87 ++++++++++++++++---- include/media/media-entity.h | 33 ++++++++ include/media/v4l2-mc.h | 2 - 12 files changed, 158 insertions(+), 26 deletions(-)