From: fixed-term.Oleksij.Rempel@de.bosch.com (fixed-term.Oleksij.Rempel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: dts: sun7i-a20-bananapi: name the GPIO lines
Date: Mon, 25 Jul 2016 07:27:16 +0200 [thread overview]
Message-ID: <5795A334.3000701@de.bosch.com> (raw)
In-Reply-To: <CAGb2v66tf1LcBs69ECW0Xa2OeN0C0NWVyvpC8=4DsVLjAnrO3Q@mail.gmail.com>
On 22.07.2016 17:47, Chen-Yu Tsai wrote:
> On Fri, Jul 22, 2016 at 10:55 PM, Linus Walleij
> <linus.walleij@linaro.org> wrote:
>> On Thu, Jul 14, 2016 at 1:47 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>
>>> This names the GPIO lines on the Banana Pi board in accordance with
>>> the A20_Banana_Pi v1.4 Specification.
>>>
>>> This will make these line names reflect through to userspace
>>> so that they can easily be identified and used with the new
>>> character device ABI.
>>>
>>> Some care has been taken to name all lines, not just those used
>>> by the external connectors, also lines that are muxed into some
>>> other function than GPIO: these are named "[FOO]" so that users
>>> can see with lsgpio what all lines are used for.
>>>
>>> Ps: most of the text was taken from Linux Wallej patch.
>>
>> LinuS
oops... :)
>>>
>>> Cc: devicetree at vger.kernel.org
>>> Cc: Linus Walleij <linus.walleij@linaro.org>
>>> Cc: linux-arm-kernel at lists.infradead.org
>>> Cc: Chen-Yu Tsai <wens@csie.org>
>>> Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
>>
>> Nice usecase!
>>
>>> + /*
>>> + * Legend: proper name = the GPIO line is used as GPIO
>>> + * NC = not connected (not routed from the SoC)
>>> + * "[PER]" = pin is muxed for peripheral (not GPIO)
>>> + * "" = no idea, schematic doesn't say, could be
>>> + * unrouted (not connected to any external pin)
>>> + * LSEC = Low Speed External Connector
>>> + * HSEC = High Speed External Connector
>
> I don't see LSEC/HSEC used anywhere?
ok, will remove it. Probably it will be better to have it in common
place some where by the Docs?
>>> + */
>>
>> So maybe we should make this naming convention a suggested
>> standard. People seem to like it.
Why should i invent some thing new, some Docs with suggested names will
be good.
> One question about this whole thing: how extensively should we add
> the names? Only for exposed pins? Or every pin that's routed/used?
Depends on HW. Even on production system i had cases where i need to
jump in and use some random pin for debugging. So, hawing it in
devicetree can help to reduce time later.
But i would prefer to have some kind of merged names: Names provided by
SoC descriptor (real pin names or locations) and names provided by board
design.
>>> + gpio-line-names =
>>> + /* PA */
>>> + "[ERXD3]", "[ERXD2]", "[ERXD1]", "[ERXD0]", "[ETXD3]",
>>> + "[ETXD2]", "[ETXD1]", "[ETXD0]",
>>> + "[ERXCK]", "[ERXERR]", "[ERXDV]", "[EMDC]", "[EMDIO]",
>>> + "[ETXEN]", "[ETXCK]", "[ECRS]",
>>> + "[ECOL]", "[ETXERR]", "", "", "", "", "", "",
>>> + "", "", "", "", "", "", "", "",
>>> + /* PB */
>>> + "[PMU-SCK]", "[PMU-SDA]", "", "", "", "NC", "NC", "NC",
>>> + "NC", "[USB0-DRV]", "NC", "NC", "NC", "NC", "", "",
>>> + "", "", "", "", "SCL", "SDA", "", "",
>>
>> Are these bit-banged SCL and SDA for doing I2C with
>> GPIO? Otherwise you probably want to name them "[SCL]" and "[SDA]"
>
> There's an actual I2C controller backing them.
Ok, i will fix it.
>>
>>> + "TXD0", "RXD0", "IO-1", "PH3", "[USB0-IDDET]", "PH5", "", "",
>>
>> Same here. You probably want "[TXD0]" etc unless you're bit-banging
>> the serial port. "IO-1" sounds like a real GPIO though and should
>> probably be named like that without [] and "PH3" what is that really?
>> A device-muxed pin or some kind of GPIO?
>
> PH3 is actually the pin name. The vendor uses "IO-7" and "IO-8" as function
> names for PH3 and PH5, but actually names them "NC":
Not in:
https://linux-sunxi.org/images/9/9d/A20_Bananapi_Schematic.pdf
which was used for this patch.
> http://www.bananapi.org/p/product.html
>
>>
>>> + "", "", "[SD0-DET]", "", "", "", "", "",
>>> + "NC", "", "", "", "IO-4", "IO-5", "NC", "[EMAC-PWR-EN]",
>>
>> So these seem correct too.
>>
>>> + "[LED1]", "NC", "NC", "NC", "", "", "", "",
>>
>> "LED1" seems like the right name, if this is a GPIO used to drive
>> a LED.
>
> This is GPIO based.
This was not clear to me, marking GPIO pin as peripheral, at moment of
writing and testing it was a allocated by led driver. Bit for example
IO-GCLK was free to use for GPIO :).. so do [] actually make sense?
>>
>>> + "", "", "", "IO-GCLK", "NC", "NC", "NC", "NC",
>>
>> WHat is IO-GCLK? A real GPIO line used for toggling a clock?
>> Or a hardware clock signal? In the first case it it correctly named,
>> in the other case it should be "[IO-GCLK]".
>
> According to the schematics this is a PWM output.
there are two names:
SoC name: PWM1
Connector name: IO-GCLK
Which should be used. IMO it was user friendly to use connector name.
> Regards
> ChenYu
>
>>
>>> + "NC", "NC", "[SPI-CE0]", "[SPI-CLK]", "[SPI-MOSI]",
>>> + "[SPI-MISO]", "[SPI-CE1]", "NC",
>>> + "IO-6", "IO-3", "IO-2", "IO-0", "", "", "", "",
>>
>> Looks right.
>>
>> Yours,
>> Linus Walleij
WARNING: multiple messages have this Message-ID (diff)
From: fixed-term.Oleksij.Rempel <fixed-term.Oleksij.Rempel@de.bosch.com>
To: Chen-Yu Tsai <wens@csie.org>, Linus Walleij <linus.walleij@linaro.org>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Oleksij Rempel <linux@rempel-privat.de>
Subject: Re: [PATCH] arm: dts: sun7i-a20-bananapi: name the GPIO lines
Date: Mon, 25 Jul 2016 07:27:16 +0200 [thread overview]
Message-ID: <5795A334.3000701@de.bosch.com> (raw)
In-Reply-To: <CAGb2v66tf1LcBs69ECW0Xa2OeN0C0NWVyvpC8=4DsVLjAnrO3Q@mail.gmail.com>
On 22.07.2016 17:47, Chen-Yu Tsai wrote:
> On Fri, Jul 22, 2016 at 10:55 PM, Linus Walleij
> <linus.walleij@linaro.org> wrote:
>> On Thu, Jul 14, 2016 at 1:47 PM, Oleksij Rempel <linux@rempel-privat.de> wrote:
>>
>>> This names the GPIO lines on the Banana Pi board in accordance with
>>> the A20_Banana_Pi v1.4 Specification.
>>>
>>> This will make these line names reflect through to userspace
>>> so that they can easily be identified and used with the new
>>> character device ABI.
>>>
>>> Some care has been taken to name all lines, not just those used
>>> by the external connectors, also lines that are muxed into some
>>> other function than GPIO: these are named "[FOO]" so that users
>>> can see with lsgpio what all lines are used for.
>>>
>>> Ps: most of the text was taken from Linux Wallej patch.
>>
>> LinuS
oops... :)
>>>
>>> Cc: devicetree@vger.kernel.org
>>> Cc: Linus Walleij <linus.walleij@linaro.org>
>>> Cc: linux-arm-kernel@lists.infradead.org
>>> Cc: Chen-Yu Tsai <wens@csie.org>
>>> Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
>>
>> Nice usecase!
>>
>>> + /*
>>> + * Legend: proper name = the GPIO line is used as GPIO
>>> + * NC = not connected (not routed from the SoC)
>>> + * "[PER]" = pin is muxed for peripheral (not GPIO)
>>> + * "" = no idea, schematic doesn't say, could be
>>> + * unrouted (not connected to any external pin)
>>> + * LSEC = Low Speed External Connector
>>> + * HSEC = High Speed External Connector
>
> I don't see LSEC/HSEC used anywhere?
ok, will remove it. Probably it will be better to have it in common
place some where by the Docs?
>>> + */
>>
>> So maybe we should make this naming convention a suggested
>> standard. People seem to like it.
Why should i invent some thing new, some Docs with suggested names will
be good.
> One question about this whole thing: how extensively should we add
> the names? Only for exposed pins? Or every pin that's routed/used?
Depends on HW. Even on production system i had cases where i need to
jump in and use some random pin for debugging. So, hawing it in
devicetree can help to reduce time later.
But i would prefer to have some kind of merged names: Names provided by
SoC descriptor (real pin names or locations) and names provided by board
design.
>>> + gpio-line-names =
>>> + /* PA */
>>> + "[ERXD3]", "[ERXD2]", "[ERXD1]", "[ERXD0]", "[ETXD3]",
>>> + "[ETXD2]", "[ETXD1]", "[ETXD0]",
>>> + "[ERXCK]", "[ERXERR]", "[ERXDV]", "[EMDC]", "[EMDIO]",
>>> + "[ETXEN]", "[ETXCK]", "[ECRS]",
>>> + "[ECOL]", "[ETXERR]", "", "", "", "", "", "",
>>> + "", "", "", "", "", "", "", "",
>>> + /* PB */
>>> + "[PMU-SCK]", "[PMU-SDA]", "", "", "", "NC", "NC", "NC",
>>> + "NC", "[USB0-DRV]", "NC", "NC", "NC", "NC", "", "",
>>> + "", "", "", "", "SCL", "SDA", "", "",
>>
>> Are these bit-banged SCL and SDA for doing I2C with
>> GPIO? Otherwise you probably want to name them "[SCL]" and "[SDA]"
>
> There's an actual I2C controller backing them.
Ok, i will fix it.
>>
>>> + "TXD0", "RXD0", "IO-1", "PH3", "[USB0-IDDET]", "PH5", "", "",
>>
>> Same here. You probably want "[TXD0]" etc unless you're bit-banging
>> the serial port. "IO-1" sounds like a real GPIO though and should
>> probably be named like that without [] and "PH3" what is that really?
>> A device-muxed pin or some kind of GPIO?
>
> PH3 is actually the pin name. The vendor uses "IO-7" and "IO-8" as function
> names for PH3 and PH5, but actually names them "NC":
Not in:
https://linux-sunxi.org/images/9/9d/A20_Bananapi_Schematic.pdf
which was used for this patch.
> http://www.bananapi.org/p/product.html
>
>>
>>> + "", "", "[SD0-DET]", "", "", "", "", "",
>>> + "NC", "", "", "", "IO-4", "IO-5", "NC", "[EMAC-PWR-EN]",
>>
>> So these seem correct too.
>>
>>> + "[LED1]", "NC", "NC", "NC", "", "", "", "",
>>
>> "LED1" seems like the right name, if this is a GPIO used to drive
>> a LED.
>
> This is GPIO based.
This was not clear to me, marking GPIO pin as peripheral, at moment of
writing and testing it was a allocated by led driver. Bit for example
IO-GCLK was free to use for GPIO :).. so do [] actually make sense?
>>
>>> + "", "", "", "IO-GCLK", "NC", "NC", "NC", "NC",
>>
>> WHat is IO-GCLK? A real GPIO line used for toggling a clock?
>> Or a hardware clock signal? In the first case it it correctly named,
>> in the other case it should be "[IO-GCLK]".
>
> According to the schematics this is a PWM output.
there are two names:
SoC name: PWM1
Connector name: IO-GCLK
Which should be used. IMO it was user friendly to use connector name.
> Regards
> ChenYu
>
>>
>>> + "NC", "NC", "[SPI-CE0]", "[SPI-CLK]", "[SPI-MOSI]",
>>> + "[SPI-MISO]", "[SPI-CE1]", "NC",
>>> + "IO-6", "IO-3", "IO-2", "IO-0", "", "", "", "",
>>
>> Looks right.
>>
>> Yours,
>> Linus Walleij
next prev parent reply other threads:[~2016-07-25 5:27 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-14 11:47 [PATCH] arm: dts: sun7i-a20-bananapi: name the GPIO lines Oleksij Rempel
2016-07-14 11:47 ` Oleksij Rempel
2016-07-22 14:55 ` Linus Walleij
2016-07-22 14:55 ` Linus Walleij
2016-07-22 15:47 ` Chen-Yu Tsai
2016-07-22 15:47 ` Chen-Yu Tsai
2016-07-25 5:27 ` fixed-term.Oleksij.Rempel [this message]
2016-07-25 5:27 ` fixed-term.Oleksij.Rempel
2016-07-25 13:27 ` Linus Walleij
2016-07-25 13:27 ` Linus Walleij
2016-08-05 8:05 ` Oleksij Rempel
2016-08-05 8:05 ` Oleksij Rempel
2016-08-05 8:06 ` [PATCH v2] " Oleksij Rempel
2016-08-05 8:06 ` Oleksij Rempel
2016-08-08 17:51 ` Linus Walleij
2016-08-08 17:51 ` Linus Walleij
2017-04-28 5:11 ` Oleksij Rempel
2017-04-28 5:11 ` Oleksij Rempel
2017-04-28 8:45 ` Linus Walleij
2017-04-28 8:45 ` Linus Walleij
2017-04-28 9:03 ` Oleksij Rempel
2017-04-28 9:03 ` Oleksij Rempel
2017-05-03 7:09 ` [PATCH v2 resend] " Oleksij Rempel
2017-05-03 7:09 ` Oleksij Rempel
2017-05-04 14:56 ` Maxime Ripard
2017-05-04 14:56 ` Maxime Ripard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5795A334.3000701@de.bosch.com \
--to=fixed-term.oleksij.rempel@de.bosch.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.