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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 36C37C433F5 for ; Thu, 30 Sep 2021 15:19:06 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 018E461139 for ; Thu, 30 Sep 2021 15:19:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 018E461139 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=tu9M2ZzBAmnajbmUDyd4px2kSZGB8kkEt80EuCbvLE0=; b=UpcVDUvvYxPwiE 2MVG7YaNWHql9CkWyaQMRRDig6DamHg0Rpms+1KuWjgmmkwpNHgJnTxQruc01hAdJaVXOz3qgXbqH LcN9++u4G0uzT1H0yBMoCOoJu6NCqB8iwD0CVecXKhhVAKTOV01W1/CHlhAyTAI8glaUV7pI62wSO SD/reH+HQpT6MXonm3+bDV4CliiNAb3mysLENNJ6txJmHpGOzDfZeNe2ApDWUlIc+3dbNhPqOsITJ od346udpO17vpPDurnlk8RuqqutRs0Kpp9rZSsGOVy8b3j/NHHJkF8BAqXr0wW1gT/xPF+mU/+R82 COrT9P/G44HDxMkVxeJA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mVxoR-00EvDN-M8; Thu, 30 Sep 2021 15:17:31 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mVxoN-00EvCh-VM for linux-arm-kernel@lists.infradead.org; Thu, 30 Sep 2021 15:17:29 +0000 Received: from jic23-huawei (cpc108967-cmbg20-2-0-cust86.5-4.cable.virginm.net [81.101.6.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 44F1A61139; Thu, 30 Sep 2021 15:17:24 +0000 (UTC) Date: Thu, 30 Sep 2021 16:21:19 +0100 From: Jonathan Cameron To: Olivier MOYSAN Cc: , , , , , , , , , , Arnaud POULIQUEN , Fabrice GASNIER Subject: Re: [PATCH 4/4] iio: adc: stm32-dfsdm: add scale and offset support Message-ID: <20210930162119.6b8c8455@jic23-huawei> In-Reply-To: References: <20200204101008.11411-1-olivier.moysan@st.com> <20200204101008.11411-5-olivier.moysan@st.com> <20200208161847.76c7d6e8@archlinux> <8400827e-5f3d-ad3f-99c8-986934b1a7b8@st.com> <20200214131113.70aa36b8@archlinux> <5b2e74a0-71bd-46d0-0096-b33ff17f780b@st.com> <20200214151011.20111e8c@archlinux> <78f4e4b9-ef4c-982f-7cd3-8d3052d99150@foss.st.com> <20210912182617.5635fa06@jic23-huawei> <20210919191414.09270f4e@jic23-huawei> <2ac8eafa-25fe-6640-edef-960e56733534@foss.st.com> <20210926155607.3a7fae81@jic23-huawei> X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210930_081728_084070_D2E2A62D X-CRM114-Status: GOOD ( 40.98 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Wed, 29 Sep 2021 18:44:30 +0200 Olivier MOYSAN wrote: > Hi Jonathan, > > >>>> > >>>> If 'backend' option turns out to be the most appropriated to match DFSDM > >>>> constraints, I can prepare some patches to support it. > >>>> Would you have some guidelines or requirements for the implementation of > >>>> such feature, in this case ? > >>> > >>> Closest example is that rcar-gyroadc but in this case we'd want to define > >>> something standard to support the modulators so that if we have other filters > >>> in future we can reuse them. > >>> > >>> That means implementing them as child devices of the filter - probably put > >>> the on the IIO bus, but as different device type. Take a look at how > >>> triggers are done in industrialio-trigger.c > >>> You need struct device_type sd_modulator > >>> and a suitable device struct (burred in an iio_sd_modulator struct probably). > >>> > >>> Also needed would be a bunch of standard callbacks to allow you to query things > >>> like scaling. Keep that interface simple. Until we have a lot of modulator > >>> drivers it will be hard to know exactly what is needed. Also whilst we don't > >>> have many it is easy to modify the interface. > >>> > >>> Then have your filter driver walk it's own dt children and instantiate > >>> appropriate new elements and register them on the iio_bus. They will have > >>> the filter as their parent. > >>> > >>> There are various examples of this sort of thing in tree. > >>> If you want a good one, drivers/cxl does a lot of this sort magic to manage > >>> a fairly complex graph of devices including some nice registration stuff to > >>> cause the correct device drivers to load automatically. > >>> > >>> Hmm. Thinking more on this, there is an ordering issue for driver load. > >>> Instead of making the modulator nodes children of the modulator, you may need > >>> to give them their own existence and use a phandle to reference them. > >>> That will let you defer probe in the filter driver until those > >>> modulator drivers are ready. > >>> > >>> This isn't going to be particularly simple, so you may want to have a look > >>> at how various other subsystems do similar things and mock up the dependencies > >>> to make sure you have something that doesn't end up with a loop of dependencies. > >>> In some ways the modulators are on a bus below the filter, but the filter driver > >>> needs them to be in place to do the rest. > >>> You may end up with some sort of delayed load. > >>> 1. Initial filter driver load + parsing of the modulator dt children (if done that way). > >>> 2. Filter driver goes to sleep until... > >>> 3. Modulator drivers call something on the filter driver to say they are ready. > >>> 4. Filter driver finishes loading and create the IIO device etc. > >>> You'll need some reference counting etc in there to make removal safe etc but it > >>> shouldn't be 'too bad'. > >>> > >>> Good luck! > >>> > >>> Jonathan > >>> > I'am on the way to prototype this proposal for DFSDM. > Looking at your advices, I see that the current topolgy based on > hardware consumer, already meets most of the requirements. > > - SD modulators are described in DT with their own nodes and are > referred in DFSDM nodes through their phandle. > - Dependencies at probe are managed (defer probe through > devm_iio_hw_consumer_alloc()) > - SD modulator scaling is retrieved through iio_read_channel_scale() ABI. > > So, it seems that the current implementation is not so far from this > solution. > It remains the unwanted sysfs interface for SD modulator. Or more than > that, if I missed something ? > Instead of introducing a new device type for SD modulator, could the > mode field be used to identify devices not requesting an IIO sysfs ? > (A dedicated mode may be used to skip sysfs register in device registration) > Otherwise let's go for a new type. I'd rather see them as a new device type than overload the IIO device. We want to be able to control what can 'connect' to the DFSDM afterall and device type is a convenient route to doing this. Obviously if there is infrastructure that can be factored out and used for both this and a normal IIO device we can do that to save on duplication. Thanks, Jonathan > > Regards > Olivier _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel