linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: Jorik Jonker <jorik@kippendief.biz>
Cc: wens@csie.org, mark.rutland@arm.com, robh+dt@kernel.org,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 4/8] dts: sun8i-h3: move uart1 pinmux/peripheral assocation to DSTI
Date: Mon, 12 Sep 2016 11:47:45 +0200	[thread overview]
Message-ID: <20160912094745.GH9449@lukather> (raw)
In-Reply-To: <20160908095108.GA14915@carbon.kippendief.biz>

[-- Attachment #1: Type: text/plain, Size: 1865 bytes --]

On Thu, Sep 08, 2016 at 11:51:09AM +0200, Jorik Jonker wrote:
> >>- put rts/cts in seperate pinmux sets for uart1 (2,3: see below)
> >>- associate rx/tx for uart1-3 in H3 DTSI (this is the only option)
> >
> >I'm still a bit skeptical about this. This wouldn't be in any way
> >consistant. I prefer to have something consistant and a bit duplicated
> >over something without any duplication but that confuses everyone
> >about what should be placed where.
> >
> >>- associate UART1 rts/cts as pinctrl-1 in sun8i-h3-bananapi-m2-plus
> >> (to prevent breakage for existing users)
> >
> >You can also set it in pinctrl-0.
> 
> OK, sounds reasonable, but also a bit contradictive. One the one hand you
> prefer consistency (so, let uart2-3 follow uart1 and include rts/cts in
> them)

Hmm, I never said that, quite the opposite actually. Any board might
use either just RX/TX, or RX/TX and RTS/CTS. I don't see why we should
enable RTS/CTS on any board by default.

> , on the other hand the common case over the rare (so split off
> rts/cts). What should I do with uarts2-3 and should I do that to
> uart1 too?

You do the exact same thing in both cases.

My point was that you could just do:

pinctrl-0 = <&uart0_pins_a>, <&uart0_rts_cts_pins_a>;
pinctrl-names = "default";

instead of

pinctrl-0 = <&uart0_pins_a>;
pinctrl-1 = <&uart0_rts_cts_pins_a>;
pinctrl-names = "default", "default";

Since they are the exact same pin state.

> Moreover, Chen-Yu prefers to drop _a and @0 when they are redundant, which
> does not appear to be the convention, looking at existing sun*dsti. What's
> your opinion on this?

AFAIK, he wanted to remove them when they're not relevant (ie, only
one pin state possible).

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2016-09-12  9:48 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-07  7:58 [PATCH v4 0/8] dts: sun8i-h3: complete UART I2C definitions for H3 jorik
2016-09-07  7:58 ` [PATCH v4 1/8] dts: sun8i-h3: drop _a and address suffix from uart0 pinmux jorik
2016-09-08  6:17   ` Maxime Ripard
2016-09-07  7:58 ` [PATCH v4 2/8] dts: sun8i-h3: clarify uart1 pinmux definition name jorik
2016-09-08  6:18   ` Maxime Ripard
2016-09-07  7:58 ` [PATCH v4 3/8] dts: sun8i-h3: move uart0 pinmux/peripheral assocation to DSTI jorik
2016-09-08  6:22   ` Maxime Ripard
2016-09-07  7:58 ` [PATCH v4 4/8] dts: sun8i-h3: move uart1 " jorik
2016-09-07  8:54   ` Chen-Yu Tsai
2016-09-08  6:23   ` Maxime Ripard
2016-09-08  8:02     ` Jorik Jonker
2016-09-08  9:01       ` Maxime Ripard
2016-09-08  9:51         ` Jorik Jonker
2016-09-12  9:47           ` Maxime Ripard [this message]
2016-09-07  7:58 ` [PATCH v4 5/8] dts: sun8i-h3: add pinmux definitions for UART2-3 jorik
2016-09-07  7:58 ` [PATCH v4 6/8] dts: sun8i-h3: associate pinmux/peripherals " jorik
2016-09-07  7:59 ` [PATCH v4 7/8] dts: sun8i-h3: add pinmux definitions for I2C0-2 jorik
2016-09-07  7:59 ` [PATCH v4 8/8] dts: sun8i-h3: add I2C0-2 peripherals to H3 SOC jorik

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=20160912094745.GH9449@lukather \
    --to=maxime.ripard@free-electrons.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jorik@kippendief.biz \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=wens@csie.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;
as well as URLs for NNTP newsgroup(s).