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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 84EC2CA9ED1 for ; Fri, 1 Nov 2019 13:46:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5B95021897 for ; Fri, 1 Nov 2019 13:46:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1572615982; bh=lswMlSOEv3IVKL2o6g/0/MZB83V2bKNcQKcLhOteMKY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=Lz2QQVcUscKqiBupBc9vwZunrAZm6OXXsGAt1GrwnpS42vLnygH+UaT2LI3xeIDSy A00/GVarcH5jxivy0+jOJV2wgMaalWDQeTSKBOrpJ0o1rG+DydagCMoOhpLT3H5qH7 1fAHImCF7+mD//hRHrsP+iRCG0mmQSfhOror+0YI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727451AbfKANqV (ORCPT ); Fri, 1 Nov 2019 09:46:21 -0400 Received: from mail.kernel.org ([198.145.29.99]:35358 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727296AbfKANqV (ORCPT ); Fri, 1 Nov 2019 09:46:21 -0400 Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C43E6217D9; Fri, 1 Nov 2019 13:46:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1572615979; bh=lswMlSOEv3IVKL2o6g/0/MZB83V2bKNcQKcLhOteMKY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=2VkCgmkJqOKWH5d+9KDukIcRTAHgjVukLo7+WnDE3TtykYaRb7rHNveONlNIa8z7C Wvf1s2hGqg8xK0DzjTHvWERd5B6QiJWEpQb02QETpjyRKih31rBLTX7nsrqGZryAfR nhqGnY7r7catGAEwdtg/1KASZ0QhIN/rBtzM7asA= Received: by mail-qt1-f182.google.com with SMTP id g50so13011584qtb.4; Fri, 01 Nov 2019 06:46:19 -0700 (PDT) X-Gm-Message-State: APjAAAWegAhA0MSmZ56hns4n8acGINgkS5bridDXXvlZhRaj0c6Ie/jc HWSteslGUTa/Kp8rUhF6fL4v6jMTPkJM0eM0PA== X-Google-Smtp-Source: APXvYqzSxs3/lKPGNsJo7QmVk87af0sBuK78lFCb7LPwSTyRxmDlUk2yWUVGBizpA0SlPdiVCwhtvME32ugnV3l7tjA= X-Received: by 2002:ac8:458c:: with SMTP id l12mr84256qtn.300.1572615978901; Fri, 01 Nov 2019 06:46:18 -0700 (PDT) MIME-Version: 1.0 References: <20191030120440.3699-1-peter.ujfalusi@ti.com> <5bca4eb6-6379-394f-c95e-5bbbba5308f1@ti.com> <20191030141736.GN4568@sirena.org.uk> <1258a5bf-a829-d47a-902f-bf2c3db07513@ti.com> In-Reply-To: <1258a5bf-a829-d47a-902f-bf2c3db07513@ti.com> From: Rob Herring Date: Fri, 1 Nov 2019 08:46:06 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC v2 0/2] gpio: Support for shared GPIO lines on boards To: Peter Ujfalusi Cc: Mark Brown , Linus Walleij , Bartosz Golaszewski , "open list:GPIO SUBSYSTEM" , "linux-kernel@vger.kernel.org" , Marek Szyprowski , Tero Kristo , Maxime Ripard , Philipp Zabel , devicetree@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Thu, Oct 31, 2019 at 3:00 AM Peter Ujfalusi wrot= e: > > > > On 30/10/2019 20.49, Rob Herring wrote: > > On Wed, Oct 30, 2019 at 9:30 AM Peter Ujfalusi = wrote: > >> > >> > >> > >> On 30/10/2019 16.17, Mark Brown wrote: > >>> On Wed, Oct 30, 2019 at 03:32:09PM +0200, Peter Ujfalusi wrote: > >>>> On 30/10/2019 15.12, Rob Herring wrote: > >>> > >>>>> Why can't we just add a shared flag like we have for interrupts? > >>>>> Effectively, we have that for resets too, it's just hardcoded in th= e > >>>>> the drivers. > >>> > >>>> This would be kind of the same thing what the > >>>> GPIOD_FLAGS_BIT_NONEXCLUSIVE does, which was a quick workaround for > >>>> fixed-regulators afaik. > >>> > >>> The theory with that was that any usage of this would need the > >>> higher level code using the GPIO to cooperate so they didn't step > >>> on each other's toes so the GPIO code should just punt to it. > >> > >> But from the client driver point of view a GPIO is still GPIO and if t= he > >> components are unrelated then it is hard to patch things together from > >> the top. > > > > You can't escape a driver being aware. If a driver depends on that > > GPIO to actually be set to states the driver says, then it can't be > > guaranteed to work. For example, maybe the driver assumes the device > > is in reset state after toggling reset and doesn't work if not in > > reset state. The driver has to be aware no matter what you do in DT. > > That's true for some device, but it is also true that some can not > tolerate being reset without them knowing it. You mean a reset when the driver is not loaded would not work? How could that ever work? I don't think you can have any reset control in the drivers in that case. > If all users of the shared GPIO have full control over it then they can > just toggle it whatever way they want. How would a regulator, codec, > amplifier would negotiate on what to do with the shared GPIO? > > Another not uncommon setup is when the two components needs different lev= el: > C1: ENABLE is high active > C2: RESET is high active > > To enable C1, the GPIO should be high. To enable C2 the GPIO must be low. > In the board one of the branch of the shared GPIO needs (and have) a > logic inverter. > > If they both control the same GPIO then they must have requested it with > different GPIO_ACTIVE_ since the drivers are written according to chip > spec, so C1 sets the GPIO to 1, C2 sets it to 0, the inversion for one > of them must happen in gpio core, right? No, drivers are written to set the state to active/inactive. The DT GPIO_ACTIVE_ flags can depend on an inverter being present (BTW, there was a recent attempt to do an inverter binding). > It should be possible to add pass-through mode for gpio-shared so that > all requests would propagate to the root GPIO if that's what needed for > some setups. > > That way the gpio-shared would nicely handle the GPIO inversions, would > be able to handle cases to avoid unwanted reset/enable of components or > allow components to be ninja-reset. What does ninja-reset mean? > I think it would be possible to add gpiod_is_shared(struct gpio_desc > *desc) so users can check if the GPIO is shared - it would only return > true if the gpio-shared is not in pass-through mode so they can know > that the state they see on their gpio desc is not necessary matching > with reality. > Probably another gpiod_shared_get_root_value() to fetch the root's state? > > I intentionally not returning that in the driver as clients might skip a > gpio_set_value() seeing that the GPIO line is already in a state they > would want it, but that would not register their needs for the level. > > - P=C3=A9ter > > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki