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=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 7DB06C4338F for ; Wed, 28 Jul 2021 11:22:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 664C260FC2 for ; Wed, 28 Jul 2021 11:22:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234576AbhG1LWH (ORCPT ); Wed, 28 Jul 2021 07:22:07 -0400 Received: from mail-yb1-f176.google.com ([209.85.219.176]:36556 "EHLO mail-yb1-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232165AbhG1LWG (ORCPT ); Wed, 28 Jul 2021 07:22:06 -0400 Received: by mail-yb1-f176.google.com with SMTP id j77so1342164ybj.3; Wed, 28 Jul 2021 04:22:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9C90hpgYkE4biTrUIzNHDYYty+iOjCgfF4PS52t6ewo=; b=F6pJPrvdCieXriMEBuqgIXnPrNl6PtcJpZiaoh3GGXKuHZowv6plgRKI2uRH93Lbfh AKiAwfdG+sAvdvz1Wpwib/UQtps7ej/ius40I1HAKzkcAhliU1gtoKLmE2vr6kJQPo7Y w+Lattr/kY729rVR0sddKt0LSBYh1cxJjYDiHws0sidf7/AfPCzRyaHnMAM5CsjPic/f 1cb/0wXiw7VsbQo7zjt2AT7NFqHvCVKAWayp7D0J+2UkB3pjQavxpWMHkCa7kL/CayA3 UC+G5v+80KNR6PwPjXbq/LecM0JUr50Vf+7kRLDxEbZMxsi+xZjgAJDuCeigCGsvAktm vRJg== X-Gm-Message-State: AOAM533zp8NXxWGhVujmsuzCr6KClIbetHx1Dh4GWuEW0mWed+WusCLR aHH59FAc6+6cqry5Ejslj7X65oa3YQ0iucKCICk= X-Google-Smtp-Source: ABdhPJyMKN9A7vWkH92nGKXoClZVP7xtHJgjDzAKw67iBSQKKzU7V2Oom+eEuE5m1MWc9u5CTXApe/NPMo7j7l4w0a4= X-Received: by 2002:a25:1e89:: with SMTP id e131mr9659175ybe.90.1627471323751; Wed, 28 Jul 2021 04:22:03 -0700 (PDT) MIME-Version: 1.0 References: <20210701002037.912625-1-drew@beagleboard.org> <20210701002037.912625-3-drew@beagleboard.org> <8c59105d32a9936f8806501ecd20e044@walle.cc> <20210726071124.GA9184@x1> <20210727052851.GA3147871@x1> In-Reply-To: From: Emil Renner Berthing Date: Wed, 28 Jul 2021 13:21:52 +0200 Message-ID: Subject: Re: [RFC PATH 2/2] gpio: starfive-jh7100: Add StarFive JH7100 GPIO driver To: Michael Walle Cc: Drew Fustini , Linus Walleij , Rob Herring , Bartosz Golaszewski , Paul Walmsley , Palmer Dabbelt , Michael Zhu , Geert Uytterhoeven , Fu Wei , linux-kernel , "open list:GPIO SUBSYSTEM" , linux-riscv , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Huan Feng Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Wed, 28 Jul 2021 at 13:19, Michael Walle wrote: > Am 2021-07-28 12:59, schrieb Emil Renner Berthing: > > On Wed, 28 Jul 2021 at 11:49, Michael Walle wrote: > >> Hi Drew, > >> Am 2021-07-27 07:28, schrieb Drew Fustini: > >> [..] > >> >> > > Drew please look at drivers/gpio/gpio-ftgpio010.c for an example > >> >> > > of GPIO_GENERIC calling bgpio_init() in probe(). > >> >> > > >> >> > Thank you for the suggestion. However, I am not sure that will work for > >> >> > this SoC. > >> >> > > >> >> > The GPIO registers are described in section 12 of JH7100 datasheet [1] > >> >> > and I don't think they fit the expectation of gpio-mmio.c because there > >> >> > is a seperate register for each GPIO line for output data value and > >> >> > output enable. > >> >> > > >> >> > There are 64 output data config registers which are 4 bytes wide. There > >> >> > are 64 output enable config registers which are 4 bytes wide too. Output > >> >> > data and output enable registers for a given GPIO pad are contiguous. > >> >> > GPIO0_DOUT_CFG is 0x50 and GPIO0_DOEN_CFG is 0x54 while GPIO1_DOUT_CFG > >> >> > is 0x58 and GPIO1_DOEN_CFG is 0x5C. The stride between GPIO pads is > >> >> > effectively 8, which yields the formula: GPIOn_DOUT_CFG is 0x50+8n. > >> >> > Similarly, GPIO0_DOEN_CFG is 0x54 and thus GPIOn_DOEN_CFG is 0x54+8n. > >> >> > > >> >> > However, GPIO input data does use just one bit for each line. GPIODIN_0 > >> >> > at 0x48 covers GPIO[31:0] and GPIODIN_1 at 0x4c covers GPIO[63:32]. > >> > >> Mh, I'm not sure I'm understanding the datasheet/registers. _DOUT_CFG > >> and _DOEN_CFG seem to specify the pad where this GPIO is mapped to. > >> Shouldn't this be some kind of pinctrl then? Apparently you can map > >> any GPIO number to any output pad, no? Or at least to all pads > >> which are described in Table 11-2. What happens if two different GPIOs > >> are mapped to the same pad? Bit 31 in these _CFG seems to be an invert > >> bit, but what does it invert? > >> > >> Similar, the input GPIOs are connected to an output pad by all the > >> GPI_*_CFG registers. > >> > >> To me it seems, that there two multiplexers for each GPIO, where > >> you can connect any GPIOn to any input pad and output pad. Sound > >> like a huge overkill. I must be missing something here. > >> > >> But what puzzles me the most, where do I set the actual GPIO output > >> value? > > > > Yeah, it's a little confusing. The DOUT registers choose between a > > number of > > signals from various peripherals to control the output value of the > > pin. Similarly > > the DOEN registers chose between a number of signals to control the > > output > > enable of the pin. However, two of those signals are special in that > > they are > > constant 0 or constant 1. This is how you control the output value and > > output > > enable from software like a regular GPIO. > > > > You're completely right though. This ought to be managed by a proper > > pinctrl > > driver, and I'm working on one here: > > https://github.com/esmil/linux/commits/beaglev-pinctrl > > Ahh, I see. So for the non-gpio function you have to set a value other > than 0 or 1, correct? > > And as an implementation detail you have to set the corresponding OE > pin if the non-gpio function will need a tristate pin (or whatever). > > So, the _DOUT_CFG will actually be shared between the pinctrl and the > gpio driver, right? (I haven't done anything with pinctrl, so this might > be a stupid question). No, not a stupid question. You've got that exactly right. /Emil