From: Nicolas Ferre <nicolas.ferre@atmel.com>
To: Stephen Warren <swarren@wwwdotorg.org>,
Ludovic Desroches <ludovic.desroches@atmel.com>,
<linus.walleij@linaro.org>, Sascha Hauer <s.hauer@pengutronix.de>
Cc: <linux-arm-kernel@lists.infradead.org>,
<linux-gpio@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [RESEND PATCH 1/2] pinctrl: change function behavior for per pin muxing controllers
Date: Tue, 30 Jun 2015 11:17:37 +0200 [thread overview]
Message-ID: <55925EB1.1030500@atmel.com> (raw)
In-Reply-To: <5581988C.50000@wwwdotorg.org>
Le 17/06/2015 17:55, Stephen Warren a écrit :
> On 06/17/2015 06:38 AM, Ludovic Desroches wrote:
[..]
>> I have sent patches months ago trying to improve things by having
>> something more flexible. I don't think I introduce too big changes.
>> The only answers I got were from people thinking that pinctrl framework
>> conception is not good to fit all kind of controllers. I re-sent the
>> patch series to gain more expose and have no answer...
>
> I don't see anything in your description which implies pinctrl isn't
> perfectly suitable for your HW.
We are not talking about suitability, we are talking about some little
changes to the generic part, just to have more accurate information and
a little bit more flexibility with our controller.
We read the drivers that Stephen pointed out and it seems that it even
doesn't use the whole generic part of the pinconf. Moreover, we do think
that the statement "one pin" == "one group" leads to a loss of
information and ease of use.
We are not talking about the use of defines, tables, macros to reach an
usable pinctrl: let's say that we have different views.
> Note that I'm on vacation for a couple weeks soon, and I don't expect to
> follow this conversation during that time. Ultimately, LinusW owns the
> pinctrl subsystem, and you need to convince him of any changes.
Okay, so we are back at the same situation we had ended up with several
months ago:
- no agreement on 3 points:
1/ ways to use groups in generic pinctrl
2/ ways to describe a comprehensive configuration in device tree
3/ readability of a sysfs information
- no way out on the generic pinctrl little changes that Ludovic proposed
as Linus W. never gave his point of view (RFC posts on April the 2nd).
Ludovic explained at length our point of view and gave detailed
technical arguments. We don't intend to convince you, we just would like
the harmless modifications to be integrated.
As we preferred to give a chance to the generic pinconf/pinctrl for our
use by adding a little bit of flexibility, we are now in a situation
where we are nearly obliged to give up this approach and write a new
driver without the use of the generic facilities: what a pity!
We lost several months of useless work to match what we thought the
maintainer would prefer.
So Linus, do you confirm that we won't go further with this approach?
We are pretty disappointed by the way this interaction with the pinctrl
sub-system went.
Best regards,
--
Nicolas Ferre
WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
To: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
Ludovic Desroches
<ludovic.desroches-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cc: 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
Subject: Re: [RESEND PATCH 1/2] pinctrl: change function behavior for per pin muxing controllers
Date: Tue, 30 Jun 2015 11:17:37 +0200 [thread overview]
Message-ID: <55925EB1.1030500@atmel.com> (raw)
In-Reply-To: <5581988C.50000-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Le 17/06/2015 17:55, Stephen Warren a écrit :
> On 06/17/2015 06:38 AM, Ludovic Desroches wrote:
[..]
>> I have sent patches months ago trying to improve things by having
>> something more flexible. I don't think I introduce too big changes.
>> The only answers I got were from people thinking that pinctrl framework
>> conception is not good to fit all kind of controllers. I re-sent the
>> patch series to gain more expose and have no answer...
>
> I don't see anything in your description which implies pinctrl isn't
> perfectly suitable for your HW.
We are not talking about suitability, we are talking about some little
changes to the generic part, just to have more accurate information and
a little bit more flexibility with our controller.
We read the drivers that Stephen pointed out and it seems that it even
doesn't use the whole generic part of the pinconf. Moreover, we do think
that the statement "one pin" == "one group" leads to a loss of
information and ease of use.
We are not talking about the use of defines, tables, macros to reach an
usable pinctrl: let's say that we have different views.
> Note that I'm on vacation for a couple weeks soon, and I don't expect to
> follow this conversation during that time. Ultimately, LinusW owns the
> pinctrl subsystem, and you need to convince him of any changes.
Okay, so we are back at the same situation we had ended up with several
months ago:
- no agreement on 3 points:
1/ ways to use groups in generic pinctrl
2/ ways to describe a comprehensive configuration in device tree
3/ readability of a sysfs information
- no way out on the generic pinctrl little changes that Ludovic proposed
as Linus W. never gave his point of view (RFC posts on April the 2nd).
Ludovic explained at length our point of view and gave detailed
technical arguments. We don't intend to convince you, we just would like
the harmless modifications to be integrated.
As we preferred to give a chance to the generic pinconf/pinctrl for our
use by adding a little bit of flexibility, we are now in a situation
where we are nearly obliged to give up this approach and write a new
driver without the use of the generic facilities: what a pity!
We lost several months of useless work to match what we thought the
maintainer would prefer.
So Linus, do you confirm that we won't go further with this approach?
We are pretty disappointed by the way this interaction with the pinctrl
sub-system went.
Best regards,
--
Nicolas Ferre
--
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: nicolas.ferre@atmel.com (Nicolas Ferre)
To: linux-arm-kernel@lists.infradead.org
Subject: [RESEND PATCH 1/2] pinctrl: change function behavior for per pin muxing controllers
Date: Tue, 30 Jun 2015 11:17:37 +0200 [thread overview]
Message-ID: <55925EB1.1030500@atmel.com> (raw)
In-Reply-To: <5581988C.50000@wwwdotorg.org>
Le 17/06/2015 17:55, Stephen Warren a ?crit :
> On 06/17/2015 06:38 AM, Ludovic Desroches wrote:
[..]
>> I have sent patches months ago trying to improve things by having
>> something more flexible. I don't think I introduce too big changes.
>> The only answers I got were from people thinking that pinctrl framework
>> conception is not good to fit all kind of controllers. I re-sent the
>> patch series to gain more expose and have no answer...
>
> I don't see anything in your description which implies pinctrl isn't
> perfectly suitable for your HW.
We are not talking about suitability, we are talking about some little
changes to the generic part, just to have more accurate information and
a little bit more flexibility with our controller.
We read the drivers that Stephen pointed out and it seems that it even
doesn't use the whole generic part of the pinconf. Moreover, we do think
that the statement "one pin" == "one group" leads to a loss of
information and ease of use.
We are not talking about the use of defines, tables, macros to reach an
usable pinctrl: let's say that we have different views.
> Note that I'm on vacation for a couple weeks soon, and I don't expect to
> follow this conversation during that time. Ultimately, LinusW owns the
> pinctrl subsystem, and you need to convince him of any changes.
Okay, so we are back at the same situation we had ended up with several
months ago:
- no agreement on 3 points:
1/ ways to use groups in generic pinctrl
2/ ways to describe a comprehensive configuration in device tree
3/ readability of a sysfs information
- no way out on the generic pinctrl little changes that Ludovic proposed
as Linus W. never gave his point of view (RFC posts on April the 2nd).
Ludovic explained at length our point of view and gave detailed
technical arguments. We don't intend to convince you, we just would like
the harmless modifications to be integrated.
As we preferred to give a chance to the generic pinconf/pinctrl for our
use by adding a little bit of flexibility, we are now in a situation
where we are nearly obliged to give up this approach and write a new
driver without the use of the generic facilities: what a pity!
We lost several months of useless work to match what we thought the
maintainer would prefer.
So Linus, do you confirm that we won't go further with this approach?
We are pretty disappointed by the way this interaction with the pinctrl
sub-system went.
Best regards,
--
Nicolas Ferre
next prev parent reply other threads:[~2015-06-30 9:19 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
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 [this message]
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=55925EB1.1030500@atmel.com \
--to=nicolas.ferre@atmel.com \
--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=s.hauer@pengutronix.de \
--cc=swarren@wwwdotorg.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 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.