From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D70AAC388F9 for ; Wed, 4 Nov 2020 16:39:04 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6449A2072E for ; Wed, 4 Nov 2020 16:39:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="JmKcM/rQ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6449A2072E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=collabora.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=I+DBYbRz1PAEUbr2ElIXgZzh74TCjZ/+X43AzXZBUPU=; b=JmKcM/rQkN1iTt7N7W5wNaZ24 /psafYT46IIwPUyBs06TP4vBVlHG4PfY5Tbs0SRUrf1X44MNynoWhlm6LEROScZRlMiFBszCClHSY dDRx+d2ptNqS+1MCOx1yqxVWH47SVEhIMWDy2BAi83KIqzU3mvzwDxi6+pX9z6836kAfQ4HVFKoW8 lcbNar/TbgUyTl02q/FO7kgDPeeTFaNijsr/xQ9n5ZZOlecF1GX+SyFlKfg4AZaP+JCOSNGlQKLyL PbRjjO717CJPw2k3xZkuSeehly/ICuqLDstrassvJbS18oK81QMAS+1DeomG+xxgoJfQMYdZ2NLBQ KvWdT5HYA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kaLnv-0005PY-4S; Wed, 04 Nov 2020 16:38:35 +0000 Received: from bhuna.collabora.co.uk ([2a00:1098:0:82:1000:25:2eeb:e3e3]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kaLnr-0005O7-Gm for linux-arm-kernel@lists.infradead.org; Wed, 04 Nov 2020 16:38:32 +0000 Received: from [IPv6:2804:14c:483:7e3e::1003] (unknown [IPv6:2804:14c:483:7e3e::1003]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: koike) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 65BCE1F45ADE; Wed, 4 Nov 2020 16:38:12 +0000 (GMT) Subject: Re: [PATCH 08/14] media: sunxi: Add support for the A31 MIPI CSI-2 controller To: Paul Kocialkowski , Maxime Ripard References: <20201023174546.504028-1-paul.kocialkowski@bootlin.com> <20201023174546.504028-9-paul.kocialkowski@bootlin.com> <1a3a615c-a058-e282-2dbb-c99dfa98be68@collabora.com> <20201102092110.ro6a456lvbrktwoz@gilmour.lan> <20201104111710.GB287014@aptenodytes> From: Helen Koike Message-ID: Date: Wed, 4 Nov 2020 13:38:08 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <20201104111710.GB287014@aptenodytes> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201104_113831_681737_A5644A38 X-CRM114-Status: GOOD ( 24.28 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devel@driverdev.osuosl.org, devicetree@vger.kernel.org, Philipp Zabel , Kishon Vijay Abraham I , Thomas Petazzoni , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Chen-Yu Tsai , Hans Verkuil , linux-sunxi@googlegroups.com, Rob Herring , Vinod Koul , Yong Deng , Sakari Ailus , Hans Verkuil , Mauro Carvalho Chehab , kevin.lhopital@hotmail.com, linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 11/4/20 8:17 AM, Paul Kocialkowski wrote: > Hi, > > On Mon 02 Nov 20, 10:21, Maxime Ripard wrote: >> On Fri, Oct 30, 2020 at 07:45:18PM -0300, Helen Koike wrote: >>> On 10/23/20 2:45 PM, Paul Kocialkowski wrote: >>>> The A31 MIPI CSI-2 controller is a dedicated MIPI CSI-2 controller >>>> found on Allwinner SoCs such as the A31 and V3/V3s. >>>> >>>> It is a standalone block, connected to the CSI controller on one side >>>> and to the MIPI D-PHY block on the other. It has a dedicated address >>>> space, interrupt line and clock. >>>> >>>> Currently, the MIPI CSI-2 controller is hard-tied to a specific CSI >>>> controller (CSI0) but newer SoCs (such as the V5) may allow switching >>>> MIPI CSI-2 controllers between CSI controllers. >>>> >>>> It is represented as a V4L2 subdev to the CSI controller and takes a >>>> MIPI CSI-2 sensor as its own subdev, all using the fwnode graph and >>>> media controller API. >>> >>> Maybe this is a bad idea, but I was thinking: >>> This driver basically just turn on/off and catch some interrupts for errors, >>> and all the rest of v4l2 config you just forward to the next subdevice >>> on the pipeline. >>> >>> So instead of exposing it as a subdevice, I was wondering if modeling >>> this driver also through the phy subsystem wouldn't be cleaner, so >>> you won't need all the v4l2 subdevice/topology boilerplate code that >>> it seems you are not using (unless you have plans to add controls or >>> some specific configuration on this node later). >>> >>> But this would require changes on the sun6i-csi driver. >>> >>> What do you think? >> >> Eventually we'll need to filter the virtual channels / datatypes I >> guess, so it's definitely valuable to have it in v4l2 Which kind of datatypes? I ask to know if this shouldn't be configured through the video node instead of subdevice. Regarding channels, we had a discussion to implement it through the video node (and not subdevice) [1]. But we discussed about blitters and multi-scalers, so now I'm wondering if we could use the same API for mipi-csi virtual channels in the video entity device, or if it doesn't apply and we need another API for that in a subdevice instead. [1] https://patchwork.linuxtv.org/project/linux-media/cover/20200717115435.2632623-1-helen.koike@collabora.com/ > > Agreed and like I mentionned in the discussion on 00/14 I don't think it > would be a cleaner way to expose things. > > There's also the fact that newer SoCs like the V5 seem to allow connecting > any MIPI CSI-2 controller to any CSI controller, so the graph representation > is definitely welcome here. I'm not sure this is an advantage in userspace pov, because it means we'll have different topologies for basically the same end result to userspace. But as I mentioned, I don't mind keeping it in the media topology. Helen > > Paul > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel