public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/9] ARM: dts: exynos: Add macros for GPIO configuration
Date: Wed, 31 Aug 2016 14:58:41 +0200	[thread overview]
Message-ID: <6113443.1q3Xq4YM82@wuerfel> (raw)
In-Reply-To: <07ddb8f8-a9e1-6105-ace9-edb5c8cc2f57@samsung.com>

On Wednesday, August 31, 2016 2:53:02 PM CEST Krzysztof Kozlowski wrote:
> On 08/31/2016 02:42 PM, Arnd Bergmann wrote:
> > On Wednesday, August 31, 2016 2:13:25 PM CEST Krzysztof Kozlowski wrote:
> >>
> >> +#define PIN_PULL_NONE          0
> >> +#define PIN_PULL_DOWN          1
> >> +#define PIN_PULL_UP            3
> >> +
> >> +#define PIN_DRV_LV1            0
> >> +#define PIN_DRV_LV2            2
> >> +#define PIN_DRV_LV3            1
> >> +#define PIN_DRV_LV4            3
> >> +
> >> +#define PIN_FUNC_INPUT         0
> >> +#define PIN_FUNC_OUTPUT                1
> >> +#define PIN_FUNC_SPC_2         2
> >> +#define PIN_FUNC_SPC_3         3
> >> +#define PIN_FUNC_SPC_4         4
> >> +#define PIN_FUNC_SPC_5         5
> >> +#define PIN_FUNC_SPC_F         0xf
> > 
> > Any reason for having a copy in each of those files instead of one
> > that is shared across all of them?
> 
> The drive strengths differ between some of them. There are three groups
> of drive strengths:
> 1. Exynos3250, Exynos4 (all) and Exynos5250,
> 2. Exynos5260,
> 3. Exynos5410, 542x and 5800.

I see. That sounds like an even stronger reason to not duplicate
the definitions, as this is very confusing.

> Rest (functions and pull up/down) is the same so sharing the defines is
> possible but not that obvious. Solution would be for example adding a
> SoC-family prefix for PIN_DRV_LVx. Not that good...
> 
> I could put it into three DTSI:
>  - exynos3-pinctrl.dtsi (new file)
>  - exynos5260-pinctrl.dtsi (like it is now)
>  - exynos54xx-pinctrl.dtsi (new file)
> 
> which would reduce the duplication. Other ideas?

I think having the soc-family prefix is better, as it avoids
defining the same symbol to a different value. Better make this
as explicit as possible.

I think overall, a better solution would have been to define the
constants globally (shared with non-exynos) to start with,
and have the driver translate generic numbers into vendor
specific ones. Obviously it's too late for that now.

	Arnd

  reply	other threads:[~2016-08-31 12:58 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-31 12:13 [PATCH 0/9] ARM: dts: exynos: Use macros for GPIO to make it more readable Krzysztof Kozlowski
2016-08-31 12:13 ` [PATCH 1/9] ARM: dts: exynos: Add macros for GPIO configuration Krzysztof Kozlowski
2016-08-31 12:42   ` Arnd Bergmann
2016-08-31 12:53     ` Krzysztof Kozlowski
2016-08-31 12:58       ` Arnd Bergmann [this message]
2016-08-31 13:07         ` Krzysztof Kozlowski
2016-08-31 13:33           ` Arnd Bergmann
2016-08-31 12:13 ` [PATCH 2/9] ARM: dts: exynos: Use macros for GPIO configuration on exynos3250 Krzysztof Kozlowski
2016-08-31 12:13 ` [PATCH 3/9] ARM: dts: exynos: Use macros for GPIO configuration on exynos4210 Krzysztof Kozlowski
2016-08-31 12:13 ` [PATCH 4/9] ARM: dts: exynos: Use macros for GPIO configuration on exynos4415 Krzysztof Kozlowski
2016-08-31 12:13 ` [PATCH 5/9] ARM: dts: exynos: Use macros for GPIO configuration on exynos4x12 Krzysztof Kozlowski
2016-08-31 12:13 ` [PATCH 6/9] ARM: dts: exynos: Use macros for GPIO configuration on exynos5250 Krzysztof Kozlowski
2016-08-31 12:13 ` [PATCH 7/9] ARM: dts: exynos: Use macros for GPIO configuration on exynos5260 Krzysztof Kozlowski
2016-08-31 12:13 ` [PATCH 8/9] ARM: dts: exynos: Use macros for GPIO configuration on exynos5410 Krzysztof Kozlowski
2016-08-31 12:13 ` [PATCH 9/9] ARM: dts: exynos: Use macros for GPIO configuration on exynos542x/exynos5800 Krzysztof Kozlowski
2016-08-31 12:40 ` [PATCH 0/9] ARM: dts: exynos: Use macros for GPIO to make it more readable Javier Martinez Canillas

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=6113443.1q3Xq4YM82@wuerfel \
    --to=arnd@arndb.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox