From: Stephen Warren <swarren@wwwdotorg.org>
To: Ludovic Desroches <ludovic.desroches@atmel.com>,
linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: linus.walleij@linaro.org, nicolas.ferre@atmel.com
Subject: Re: [RESEND PATCH 1/2] pinctrl: change function behavior for per pin muxing controllers
Date: Mon, 15 Jun 2015 09:58:05 -0600 [thread overview]
Message-ID: <557EF60D.8020007@wwwdotorg.org> (raw)
In-Reply-To: <1433948699-19800-2-git-send-email-ludovic.desroches@atmel.com>
On 06/10/2015 09:04 AM, Ludovic Desroches wrote:
> When having a controller which allows per pin muxing, declaring with
> which groups a function can be used is a useless constraint since groups
> are something virtual.
This isn't true.
Irrespective of whether a particular piece of pinmux HW can control the
mux function for each pin individually, or only in groups, it's quite
likely that each function can only be selected onto a subset of those
pins or groups. Requiring the pinctrl driver to inform the core which
set of pins/groups particular functions can be selected onto seems quite
reasonable.
In my opinion at least, for HW that can select the mux function at the
per-pin level, the only sensible set of groups is one group per pin with
each group containing a single pin. Any other use of groups is a
SW/user-level construct, and is something unrelated to why the pinctrl
subsystem supports groups. If we want to represent those groups in
pinctrl, there should be two separate sets of groups; one to represent
the actual HW capabilities, and one to represent the SW/user-level
convenience abstractions.
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Ludovic Desroches
<ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org
Subject: Re: [RESEND PATCH 1/2] pinctrl: change function behavior for per pin muxing controllers
Date: Mon, 15 Jun 2015 09:58:05 -0600 [thread overview]
Message-ID: <557EF60D.8020007@wwwdotorg.org> (raw)
In-Reply-To: <1433948699-19800-2-git-send-email-ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
On 06/10/2015 09:04 AM, Ludovic Desroches wrote:
> When having a controller which allows per pin muxing, declaring with
> which groups a function can be used is a useless constraint since groups
> are something virtual.
This isn't true.
Irrespective of whether a particular piece of pinmux HW can control the
mux function for each pin individually, or only in groups, it's quite
likely that each function can only be selected onto a subset of those
pins or groups. Requiring the pinctrl driver to inform the core which
set of pins/groups particular functions can be selected onto seems quite
reasonable.
In my opinion at least, for HW that can select the mux function at the
per-pin level, the only sensible set of groups is one group per pin with
each group containing a single pin. Any other use of groups is a
SW/user-level construct, and is something unrelated to why the pinctrl
subsystem supports groups. If we want to represent those groups in
pinctrl, there should be two separate sets of groups; one to represent
the actual HW capabilities, and one to represent the SW/user-level
convenience abstractions.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [RESEND PATCH 1/2] pinctrl: change function behavior for per pin muxing controllers
Date: Mon, 15 Jun 2015 09:58:05 -0600 [thread overview]
Message-ID: <557EF60D.8020007@wwwdotorg.org> (raw)
In-Reply-To: <1433948699-19800-2-git-send-email-ludovic.desroches@atmel.com>
On 06/10/2015 09:04 AM, Ludovic Desroches wrote:
> When having a controller which allows per pin muxing, declaring with
> which groups a function can be used is a useless constraint since groups
> are something virtual.
This isn't true.
Irrespective of whether a particular piece of pinmux HW can control the
mux function for each pin individually, or only in groups, it's quite
likely that each function can only be selected onto a subset of those
pins or groups. Requiring the pinctrl driver to inform the core which
set of pins/groups particular functions can be selected onto seems quite
reasonable.
In my opinion at least, for HW that can select the mux function at the
per-pin level, the only sensible set of groups is one group per pin with
each group containing a single pin. Any other use of groups is a
SW/user-level construct, and is something unrelated to why the pinctrl
subsystem supports groups. If we want to represent those groups in
pinctrl, there should be two separate sets of groups; one to represent
the actual HW capabilities, and one to represent the SW/user-level
convenience abstractions.
next prev parent reply other threads:[~2015-06-15 15:57 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-10 15:04 [RESEND PATCH 0/2] get pinctrl more flexible for per pin muxing controllers Ludovic Desroches
2015-06-10 15:04 ` Ludovic Desroches
2015-06-10 15:04 ` Ludovic Desroches
2015-06-10 15:04 ` [RESEND PATCH 1/2] pinctrl: change function behavior " Ludovic Desroches
2015-06-10 15:04 ` Ludovic Desroches
2015-06-10 15:04 ` Ludovic Desroches
2015-06-15 15:58 ` Stephen Warren [this message]
2015-06-15 15:58 ` Stephen Warren
2015-06-15 15:58 ` Stephen Warren
2015-06-17 12:38 ` Ludovic Desroches
2015-06-17 12:38 ` Ludovic Desroches
2015-06-17 12:38 ` Ludovic Desroches
2015-06-17 15:55 ` Stephen Warren
2015-06-17 15:55 ` Stephen Warren
2015-06-18 12:33 ` Ludovic Desroches
2015-06-18 12:33 ` Ludovic Desroches
2015-06-18 12:33 ` Ludovic Desroches
2015-07-14 5:57 ` Sascha Hauer
2015-07-14 5:57 ` Sascha Hauer
2015-07-15 7:46 ` Ludovic Desroches
2015-07-15 7:46 ` Ludovic Desroches
2015-07-15 7:46 ` Ludovic Desroches
2015-07-15 8:29 ` Ludovic Desroches
2015-07-15 8:29 ` Ludovic Desroches
2015-07-15 8:29 ` Ludovic Desroches
2015-07-27 9:43 ` Linus Walleij
2015-07-27 9:43 ` Linus Walleij
2015-07-27 12:12 ` Ludovic Desroches
2015-07-27 12:12 ` Ludovic Desroches
2015-06-30 9:17 ` Nicolas Ferre
2015-06-30 9:17 ` Nicolas Ferre
2015-06-30 9:17 ` Nicolas Ferre
2015-07-13 12:07 ` Linus Walleij
2015-07-13 12:07 ` Linus Walleij
2015-07-13 12:07 ` Linus Walleij
2015-07-14 6:54 ` Sascha Hauer
2015-07-14 6:54 ` Sascha Hauer
2015-07-13 12:13 ` Linus Walleij
2015-07-13 12:13 ` Linus Walleij
2015-06-10 15:04 ` [RESEND PATCH 2/2] pinctrl: introduce complex pin description Ludovic Desroches
2015-06-10 15:04 ` Ludovic Desroches
2015-06-10 15:04 ` Ludovic Desroches
2015-06-15 16:01 ` Stephen Warren
2015-06-15 16:01 ` Stephen Warren
2015-06-15 16:01 ` Stephen Warren
2015-06-17 12:42 ` Ludovic Desroches
2015-06-17 12:42 ` Ludovic Desroches
2015-06-17 12:42 ` Ludovic Desroches
2015-07-14 6:13 ` Sascha Hauer
2015-07-14 6:13 ` Sascha Hauer
2015-07-15 8:45 ` Ludovic Desroches
2015-07-15 8:45 ` Ludovic Desroches
2015-07-15 8:45 ` Ludovic Desroches
2015-07-15 10:05 ` Sascha Hauer
2015-07-15 10:05 ` Sascha Hauer
2015-07-15 13:52 ` Ludovic Desroches
2015-07-15 13:52 ` Ludovic Desroches
2015-07-15 13:52 ` Ludovic Desroches
2015-06-10 15:04 ` [RESEND PROTO] pinctrl: rough draft for a future controller Ludovic Desroches
2015-06-10 15:04 ` Ludovic Desroches
2015-06-10 15:04 ` Ludovic Desroches
2015-06-10 15:04 ` [RESEND PROTO] ARM: at91/dt: proto dt Ludovic Desroches
2015-06-10 15:04 ` Ludovic Desroches
2015-06-10 15:04 ` Ludovic Desroches
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=557EF60D.8020007@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=devicetree@vger.kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ludovic.desroches@atmel.com \
--cc=nicolas.ferre@atmel.com \
/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.