linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: christian.ruppert@abilis.com (Christian Ruppert)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] pinctrl: elaborate a bit on arrangements in doc
Date: Wed, 3 Jul 2013 10:54:04 +0200	[thread overview]
Message-ID: <20130703085403.GC19130@ab42.lan> (raw)
In-Reply-To: <51CCB611.6010709@wwwdotorg.org>

On Thu, Jun 27, 2013 at 04:00:49PM -0600, Stephen Warren wrote:
> On 06/27/2013 03:54 AM, Linus Walleij wrote:
> > From: Linus Walleij <linus.walleij@linaro.org>
> [...]
> > +From a kernel point of view, however, these are different aspects of the
> > +hardware and shall be put into different subsystems.
> > +
> > +Electrical properties of the pin such as biasing and drive strength
> > +may be placed at some pin-specific register in all cases or as part
> > +of the GPIO register in case (B) especially. This doesn't mean that such
> > +properties necessarily pertain to what the Linux kernel calls "GPIO".
> 
> Is it worth explaining which Linux subsystem each of the three aspects
> are controlled by. Something like:
> 
> -----
> Registers (or fields within registers) that control electrical
> properties of the pin such as biasing and drive strength should be
> exposed through the pinctrl subsystem, as "pin configuration" settings.
> 
> Registers (or fields within registers) that control muxing of signals
> from various other HW blocks (e.g. I2C, MMC, or GPIO) onto pins should
> be exposed through the pinctrl subssytem, as mux functions.
> 
> Registers (or fields within registers) that control GPIO functionality
> such as setting a GPIO's output value, reading a GPIO's input value, or
> setting GPIO pin direction should be exposed through the GPIO subsystem.
> 
> Depending on the exact HW register design, some functions exposed by the
> GPIO subsystem may call into the pinctrl subsystem in order to
> co-ordinate register settings across HW modules. In particular, this may
> be needed for HW with separate GPIO and pin controller HW modules, where
> e.g. GPIO direction is determined by a register in the pin controller HW
> module rather than the GPIO HW module.
> -----

I agree, this is really worth mentioning in some place, maybe even a
more prominent one than here.

-- 
  Christian Ruppert              ,          <christian.ruppert@abilis.com>
                                /|
  Tel: +41/(0)22 816 19-42     //|                 3, Chemin du Pr?-Fleuri
                             _// | bilis Systems   CH-1228 Plan-les-Ouates

  reply	other threads:[~2013-07-03  8:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-27  9:54 [PATCH v2] pinctrl: elaborate a bit on arrangements in doc Linus Walleij
2013-06-27 12:18 ` Christian Ruppert
2013-06-27 22:00 ` Stephen Warren
2013-07-03  8:54   ` Christian Ruppert [this message]
2013-07-21 17:47   ` Linus Walleij

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=20130703085403.GC19130@ab42.lan \
    --to=christian.ruppert@abilis.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 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).