public inbox for linux-rockchip@lists.infradead.org
 help / color / mirror / Atom feed
From: "Heiko Stübner" <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
To: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Subject: Boundary between pinctrl and peripheral settings
Date: Fri, 05 Aug 2016 01:36:06 +0200	[thread overview]
Message-ID: <1719598.F3JUalFtig@phil> (raw)

Hi Linus,


on the rk3399 we found an interesting new feature and would like to get some 
input from the pinctrl expert :-) , as Doug and me currently are of 
differing opinions on where specific control elements belong.


In a nutshell on the rk3399 some things like one specific uart can use 
multiple pins to output data, but control of that seems to be split. The 
actual pin config is identical for all pins - each needs to be configured to 
function 2, pulls set etc. Then somewhere between the pin io-cells and the 
uart it seems to have some sort of switch to decide to which pin to actually 
route the data.


+-------+    +--------+  /- GPIO4_B1 (pinmux 2)
| uart2 | -- | switch | --- GPIO4_C1 (pinmux 2)
+-------+    +--------+  \- GPIO4_C4 (pinmux 2)
(switch selects one of the 3 pins to actually output data to)


So the question now is, should the pinctrl driver also flip that switch to 
the correct position itself when pin-function 2 of say gpio4_bq gets 
selected or is that routing outside of pinctrl's scope?

-----

I hope to have presented the core issue above somewhat neutrally, below are 
my personal worries about doing that in pinctrl :-) .


Apart from it feeling "bolted-on" to me, I have two main worries with that 
approach:
(1) Right now the unused pins are really unused on the same iomux, so when 
flipping the switch it essentially does

 uart-sout    unused 
  |(iomux2)    |(iomux2)
  |            |
+----------+ +----------+
| gpio4_b0 | | gpio4_c0 |
+----------+ +----------+

going to

 unused       uart-sout
  |(iomux2)    |(iomux2)
  |            |
+----------+ +----------+
| gpio4_b0 | | gpio4_c0 |
+----------+ +----------+

but nothing keeps designers from doing

 uart-sout    special1 
  |(iomux2)    |(iomux2)
  |            |
+----------+ +----------+
| gpio4_b0 | | gpio4_c0 |
+----------+ +----------+

going to

 special2     uart-sout
  |(iomux2)    |(iomux2)
  |            |
+----------+ +----------+
| gpio4_b0 | | gpio4_c0 |
+----------+ +----------+

somewhere down the road, so relying on following the selected iomux feels 
not future proof.

(2) Looking at [0] we already have a similar case, where we configure the 
pins for rgmii but still tell the gmac controller that it is supposed to do 
rgmii instead of rmii.

Here the pinmux is the same for all pins, rmii just uses less pins when 
compared to rgmii, so binding that to the pinmux isn't even possible.

And doing it one way here and another way for the switch feels very strange.


I hope this overly long mail was not to confusing and hope for some words of 
wisdom ;-)


Big thanks
Heiko


[0] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/rk3288-miqi.dts#n139

             reply	other threads:[~2016-08-04 23:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-04 23:36 Heiko Stübner [this message]
2016-08-10 13:32 ` Boundary between pinctrl and peripheral settings Linus Walleij
     [not found]   ` <CACRpkdb=ju0i9x3rtRz0OvUkrsGBSBLymnzLqWNZ=WWJ6CKryQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-08-22 17:10     ` Heiko Stuebner
2017-05-18  8:21 ` Kever Yang
     [not found]   ` <2f1d45cb-8869-94fc-98b1-952d0f12d343-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2017-05-18  8:48     ` Heiko Stübner
2017-05-18 14:39       ` David.Wu
     [not found]         ` <a865024c-98d4-4349-6a33-e29fbc3cd7a7-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2017-05-19  9:13           ` Heiko Stuebner
2017-05-22 13:58             ` David.Wu
     [not found]               ` <97536e9f-7ad9-032b-d2dd-921f97464123-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2017-05-22 16:29                 ` Heiko Stuebner
2017-05-23 13:05                   ` David.Wu
2017-07-21  6:33                   ` David.Wu
     [not found]                     ` <d0ade22d-3e3d-6bf3-3a06-e85e74360147-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2017-07-21  9:28                       ` Heiko Stuebner

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=1719598.F3JUalFtig@phil \
    --to=heiko-4mtyjxux2i+zqb+pc5nmwq@public.gmane.org \
    --cc=dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
    --cc=linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.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