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.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,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 968D1C2D0A8 for ; Mon, 28 Sep 2020 11:38:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 46EC121D95 for ; Mon, 28 Sep 2020 11:38:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BKUXY08C" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726711AbgI1LiF (ORCPT ); Mon, 28 Sep 2020 07:38:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41768 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726477AbgI1LiE (ORCPT ); Mon, 28 Sep 2020 07:38:04 -0400 Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 84BA4C061755; Mon, 28 Sep 2020 04:38:04 -0700 (PDT) Received: by mail-wr1-x441.google.com with SMTP id g4so940228wrs.5; Mon, 28 Sep 2020 04:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=/DSfl3PhmxyqK4cCLrMlHEsrYZk0SosXscE+a3oAY9s=; b=BKUXY08CAONse8WpQ7sUrmd1q/uBCMq1YsJ7kY2YHySsvfSynLm2E6t5oCMCNvBn2T V4kwJbsEvli/SsBH76PZ7yPrZZ+nOkqXa5wFpaDpSt3EVO95vRFKVDEcRupq1zSENVb0 L6inXyTM8LbbJyYQgch0NOpYZ23Yfo2agilZtogNs3qd4r9kLZqk7pOsAVu9gJtAQOP0 ec6FQQWIk+srdEQdJH3nEMM6XyGzZaHgBRDDrzcGVoiWMllGCbeEIwrOiMj/ceNymZ1A oJpP1+GJ2hKsSURadWl+NIetcMzZMmtoSLAgskc/RKuJlRNzarujyV7A2TAUGtFdZQLg aszw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=/DSfl3PhmxyqK4cCLrMlHEsrYZk0SosXscE+a3oAY9s=; b=Prov/8FczqIOF0l5/cVWCwQs9yS+eC/DHRnEkNlqQ01RHQQIW/pIju8EzLiHKcFmW1 DkoLNE9ahEfiiv5hfivMWIJm4NuLT8akrCUdBXeMqS+qAyNZ7ple+VaGOO64XgK8KbC5 86kAy7NsTbJJZlMhbBPpltZ6oZ0eA9mSLJ7b85KJbFzDkVfo2oKufUZaSCSLGJg83U0A m4FWTVANh4ngyvcVE1Ltnu/Ntb0K6LUc2qPxcLHfYj4CoaXrGyHKkPyFwQp2BCZKWZHt zhk5KMe9VPp3IkxAMfaSm1vtq4cTY9OR3eFOS4R9H8IWN7FknvgqHwrc5W7JfL5vDsmP IB5g== X-Gm-Message-State: AOAM532Qdp0laX0TjgGFq96ibAko3YeVipZYAkmvJhT066ThMzMnk4kD h7wYdKSoKlf1xk42WZCxxAM= X-Google-Smtp-Source: ABdhPJzqVbAgm8Mpq/f7Lw5cB88wTQXRr/O+Mg6pfxX0WJsJ3kspBzf3nQPqzm47Ga4SBXFb3SkYLA== X-Received: by 2002:adf:ec92:: with SMTP id z18mr1317347wrn.53.1601293077673; Mon, 28 Sep 2020 04:37:57 -0700 (PDT) Received: from [192.168.1.211] ([95.144.134.217]) by smtp.gmail.com with ESMTPSA id r14sm1028721wrn.56.2020.09.28.04.37.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Sep 2020 04:37:56 -0700 (PDT) From: Dan Scally Subject: Re: [RFC PATCH] Add bridge driver to connect sensors to CIO2 device via software nodes on ACPI platforms To: Sakari Ailus Cc: yong.zhi@intel.com, bingbu.cao@intel.com, tian.shu.qiu@intel.com, mchehab@kernel.org, gregkh@linuxfoundation.org, davem@davemloft.net, robh@kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, devel@driverdev.osuosl.org, jorhand@linux.microsoft.com, kitakar@gmail.com, kieran.bingham@ideasonboard.com, andriy.shevchenko@linux.intel.com References: <20200916213618.8003-1-djrscally@gmail.com> <20200917103343.GW26842@paasikivi.fi.intel.com> Message-ID: <060b458e-66ee-ab22-5c4c-c8e04affff7b@gmail.com> Date: Mon, 28 Sep 2020 12:37:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200917103343.GW26842@paasikivi.fi.intel.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 17/09/2020 11:33, Sakari Ailus wrote: >> + sensor_props[3] = PROPERTY_ENTRY_U32_ARRAY_LEN("data-lanes", >> + data_lanes, >> + (int)ssdb->lanes); >> + sensor_props[4] = remote_endpoints[(bridge.n_sensors * 2) + ENDPOINT_SENSOR]; >> + sensor_props[5] = PROPERTY_ENTRY_NULL; >> + >> + cio2_props[0] = PROPERTY_ENTRY_U32_ARRAY_LEN("data-lanes", >> + data_lanes, >> + (int)ssdb->lanes); >> + cio2_props[1] = remote_endpoints[(bridge.n_sensors * 2) + ENDPOINT_CIO2]; >> + cio2_props[2] = PROPERTY_ENTRY_NULL; > I suppose the CSI-2 link frequency is generally encoded in drivers in this > case. A lot of drivers already check for those, could you add the > frequencies here as well (as they are known)? This one caused me some consternation; I mentioned in a previous email that I was overwriting the v4l2_subdev's fwnode directly because I couldn't reprobe() the devices after changing their fwnode. Turns out that's probably not ok, because as you point out there are some drivers that check for properties in firmware as part of their .probe() call, so they _have_ to be there for those to work (including ov5670, which is the canonical ipu3 driver in the kernel docs). imx258 and ov13858 are also affected, and I'm aware of at least one other driver in development that would be affected. The problem preventing the reprobe working is that i2c_device_match() relies on a device's fwnode having acpi_device_fwnode_ops to perform ACPI matching, so after giving the device our software nodes the matching just fails. I thrashed out a way to make the reprobe work, but I don't really like the solution so I wanted to talk about it. The long story short is; clone the driver but add an i2c_device_id matching the existing i2c_client's name, then use i2c_add_driver() to install it to the bus before calling device_reprobe(). This does work; it makes the devices reprobe cleanly at the end of cio2-bridge's init, but it feels a little bit hacky. Any thoughts? Or if it makes it easier to discuss, I can just post the v2 containing all the changes that people suggested after the v1, and showing how this reprobe would work. 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=-4.8 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 88568C4727F for ; Mon, 28 Sep 2020 11:38:12 +0000 (UTC) Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) (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 05322221E8 for ; Mon, 28 Sep 2020 11:38:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BKUXY08C" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 05322221E8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=driverdev-devel-bounces@linuxdriverproject.org Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 7961920131; Mon, 28 Sep 2020 11:38:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ymx5KXZCiad; Mon, 28 Sep 2020 11:38:08 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by silver.osuosl.org (Postfix) with ESMTP id 3C2B720022; Mon, 28 Sep 2020 11:38:08 +0000 (UTC) Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by ash.osuosl.org (Postfix) with ESMTP id 0BEB71BF3C1 for ; Mon, 28 Sep 2020 11:38:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 0252786FB7 for ; Mon, 28 Sep 2020 11:38:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1aUARdhubaH for ; Mon, 28 Sep 2020 11:38:05 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by hemlock.osuosl.org (Postfix) with ESMTPS id F203486FFA for ; Mon, 28 Sep 2020 11:38:04 +0000 (UTC) Received: by mail-wr1-f67.google.com with SMTP id k10so934271wru.6 for ; Mon, 28 Sep 2020 04:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=/DSfl3PhmxyqK4cCLrMlHEsrYZk0SosXscE+a3oAY9s=; b=BKUXY08CAONse8WpQ7sUrmd1q/uBCMq1YsJ7kY2YHySsvfSynLm2E6t5oCMCNvBn2T V4kwJbsEvli/SsBH76PZ7yPrZZ+nOkqXa5wFpaDpSt3EVO95vRFKVDEcRupq1zSENVb0 L6inXyTM8LbbJyYQgch0NOpYZ23Yfo2agilZtogNs3qd4r9kLZqk7pOsAVu9gJtAQOP0 ec6FQQWIk+srdEQdJH3nEMM6XyGzZaHgBRDDrzcGVoiWMllGCbeEIwrOiMj/ceNymZ1A oJpP1+GJ2hKsSURadWl+NIetcMzZMmtoSLAgskc/RKuJlRNzarujyV7A2TAUGtFdZQLg aszw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=/DSfl3PhmxyqK4cCLrMlHEsrYZk0SosXscE+a3oAY9s=; b=M7gAL49lCMb5zetnUKKLcHCDCqWtXO9OYgk1Eto5MMBeJRBlT4n1LVP9TE3ypqf4FO eOAV4ijQpLa/zf4I7OUNjfAM4cZjSFRDEjJ25bMQEPNiCRgbbLDbS/V0+7k6KwH2BOP4 tE526a/Oq64w7sBTdytve/G6YGGyMTp270du6DGqoww5lb8dlG6FybpM6dXMkrNQ5s0u zhF5w+SYflDCy5HZaQizGGUGetn9WGGMWOBh8R6ZhHxHzHnMA8TUtovewS3ACf9rWp/P wKpwf/FSecr+yusa7IthLF+WYOG93BHdnnIoC/uPkIEWTPtyyWrsX2guIKSMiIut/Ehy Ebmw== X-Gm-Message-State: AOAM531T3luofDn6P6AOJ52fYFIMe1uXEy0cOQnregCxiGM/y6XufTEb IYi0YnaFZyc0mXw9I9KlGQQ= X-Google-Smtp-Source: ABdhPJzqVbAgm8Mpq/f7Lw5cB88wTQXRr/O+Mg6pfxX0WJsJ3kspBzf3nQPqzm47Ga4SBXFb3SkYLA== X-Received: by 2002:adf:ec92:: with SMTP id z18mr1317347wrn.53.1601293077673; Mon, 28 Sep 2020 04:37:57 -0700 (PDT) Received: from [192.168.1.211] ([95.144.134.217]) by smtp.gmail.com with ESMTPSA id r14sm1028721wrn.56.2020.09.28.04.37.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Sep 2020 04:37:56 -0700 (PDT) From: Dan Scally Subject: Re: [RFC PATCH] Add bridge driver to connect sensors to CIO2 device via software nodes on ACPI platforms To: Sakari Ailus References: <20200916213618.8003-1-djrscally@gmail.com> <20200917103343.GW26842@paasikivi.fi.intel.com> Message-ID: <060b458e-66ee-ab22-5c4c-c8e04affff7b@gmail.com> Date: Mon, 28 Sep 2020 12:37:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200917103343.GW26842@paasikivi.fi.intel.com> Content-Language: en-US X-BeenThere: driverdev-devel@linuxdriverproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Driver Project Developer List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devel@driverdev.osuosl.org, robh@kernel.org, andriy.shevchenko@linux.intel.com, jorhand@linux.microsoft.com, linux-media@vger.kernel.org, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, kieran.bingham@ideasonboard.com, kitakar@gmail.com, bingbu.cao@intel.com, mchehab@kernel.org, davem@davemloft.net, tian.shu.qiu@intel.com, yong.zhi@intel.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" On 17/09/2020 11:33, Sakari Ailus wrote: >> + sensor_props[3] = PROPERTY_ENTRY_U32_ARRAY_LEN("data-lanes", >> + data_lanes, >> + (int)ssdb->lanes); >> + sensor_props[4] = remote_endpoints[(bridge.n_sensors * 2) + ENDPOINT_SENSOR]; >> + sensor_props[5] = PROPERTY_ENTRY_NULL; >> + >> + cio2_props[0] = PROPERTY_ENTRY_U32_ARRAY_LEN("data-lanes", >> + data_lanes, >> + (int)ssdb->lanes); >> + cio2_props[1] = remote_endpoints[(bridge.n_sensors * 2) + ENDPOINT_CIO2]; >> + cio2_props[2] = PROPERTY_ENTRY_NULL; > I suppose the CSI-2 link frequency is generally encoded in drivers in this > case. A lot of drivers already check for those, could you add the > frequencies here as well (as they are known)? This one caused me some consternation; I mentioned in a previous email that I was overwriting the v4l2_subdev's fwnode directly because I couldn't reprobe() the devices after changing their fwnode. Turns out that's probably not ok, because as you point out there are some drivers that check for properties in firmware as part of their .probe() call, so they _have_ to be there for those to work (including ov5670, which is the canonical ipu3 driver in the kernel docs). imx258 and ov13858 are also affected, and I'm aware of at least one other driver in development that would be affected. The problem preventing the reprobe working is that i2c_device_match() relies on a device's fwnode having acpi_device_fwnode_ops to perform ACPI matching, so after giving the device our software nodes the matching just fails. I thrashed out a way to make the reprobe work, but I don't really like the solution so I wanted to talk about it. The long story short is; clone the driver but add an i2c_device_id matching the existing i2c_client's name, then use i2c_add_driver() to install it to the bus before calling device_reprobe(). This does work; it makes the devices reprobe cleanly at the end of cio2-bridge's init, but it feels a little bit hacky. Any thoughts? Or if it makes it easier to discuss, I can just post the v2 containing all the changes that people suggested after the v1, and showing how this reprobe would work. _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel