Shawn Guo wrote at Sunday, October 23, 2011 2:51 AM:
...
> To me, pin_config() and its parameters should be invisible to client
> drivers. For amba-pl011 example, do you think any of those SoCs will
> need multiple sets of uart pin configurations to switch for different
> working modes? If that's
Shawn Guo wrote at Sunday, October 23, 2011 2:26 AM:
> On Thu, Oct 20, 2011 at 10:26:43AM -0700, Stephen Warren wrote:
> > Shawn Guo wrote at Wednesday, October 19, 2011 8:32 PM:
> > > On Wed, Oct 19, 2011 at 06:21:14PM +0200, Linus Walleij wrote:
> > ...
> > > > +int pin_config_group(struct pinctr
On Thu, Oct 20, 2011 at 04:18:49PM +0200, Linus Walleij wrote:
> On Thu, Oct 20, 2011 at 3:10 PM, Shawn Guo wrote:
>
> >> without the common definition from PIN_CONFIG_PULL to
> >> PIN_CONFIG_USER, many platforms will need to definite them repeatedly.
> >> that is what we hate.
> >>
> > I prefer
On Thu, Oct 20, 2011 at 10:26:43AM -0700, Stephen Warren wrote:
> Shawn Guo wrote at Wednesday, October 19, 2011 8:32 PM:
> > On Wed, Oct 19, 2011 at 06:21:14PM +0200, Linus Walleij wrote:
> ...
> > > +int pin_config_group(struct pinctrl_dev *pctldev, const char *pin_group,
> > > + enu
On Fri, Oct 21, 2011 at 02:57:19PM +0200, Linus Walleij wrote:
> On Fri, Oct 21, 2011 at 2:55 PM, Mark Brown
> > No, like I keep saying it's nothing to do with enabling or disabling
> > power. It's about selecting between multiple reference domains. For
> > example, choosing between the DBVDD1 a
On Fri, Oct 21, 2011 at 2:55 PM, Mark Brown
wrote:
> On Fri, Oct 21, 2011 at 02:51:46PM +0200, Linus Walleij wrote:
>> On Fri, Oct 21, 2011 at 2:30 PM, Mark Brown
>
>> > To repeat once more: this is *not* an on/off control, this is a control
>> > selecting the voltage domain a pin is referenced to
On Fri, Oct 21, 2011 at 02:51:46PM +0200, Linus Walleij wrote:
> On Fri, Oct 21, 2011 at 2:30 PM, Mark Brown
> > To repeat once more: this is *not* an on/off control, this is a control
> > selecting the voltage domain a pin is referenced to.
> Sorry, slow learner. So I'll add:
> PIN_CONFIG_ENABLE
On Fri, Oct 21, 2011 at 2:30 PM, Mark Brown
wrote:
> On Fri, Oct 21, 2011 at 02:28:25PM +0200, Linus Walleij wrote:
>> If this is a binary output pin, I suspect that
>> I suspect that what you call "off" is actually implemeted as
>> in this figure:
>
> To repeat once more: this is *not* an on/off
On Fri, Oct 21, 2011 at 02:28:25PM +0200, Linus Walleij wrote:
> On Thu, Oct 20, 2011 at 5:42 PM, Mark Brown
> > On Thu, Oct 20, 2011 at 04:43:30PM +0200, Linus Walleij wrote:
> >> In Ux500 we model our power domain switches as regulators,
> >> does such a property even belong in pin control? Is t
On Thu, Oct 20, 2011 at 5:42 PM, Mark Brown
wrote:
> On Thu, Oct 20, 2011 at 04:43:30PM +0200, Linus Walleij wrote:
>> In Ux500 we model our power domain switches as regulators,
>> does such a property even belong in pin control? Is there
>> one power domain switch per pin you mean, or a power swi
Linus Walleij wrote at Thursday, October 20, 2011 4:25 AM:
> On Thu, Oct 20, 2011 at 1:04 AM, Stephen Warren wrote:
...
> >> + * @PIN_CONFIG_BIAS_HIGH_IMPEDANCE: the pin will be set to a high
> >> impedance
> >> + * mode, also know as "third-state" (tristate) or "high-Z" or
> >> "floating".
>
Linus Walleij wrote at Thursday, October 20, 2011 7:44 AM:
> On Thu, Oct 20, 2011 at 4:45 AM, Shawn Guo wrote:
>
> > We should not require device driver to call these APIs directly. There
> > are so many pinctrl subsystem internal details left to its users.
>
> As explained I already have drive
Shawn Guo wrote at Wednesday, October 19, 2011 8:32 PM:
> On Wed, Oct 19, 2011 at 06:21:14PM +0200, Linus Walleij wrote:
...
> > +int pin_config_group(struct pinctrl_dev *pctldev, const char *pin_group,
> > +enum pin_config_param param, unsigned long data)
...
> > +enum pin_config_p
On Thu, Oct 20, 2011 at 04:43:30PM +0200, Linus Walleij wrote:
> On Thu, Oct 20, 2011 at 4:18 PM, Mark Brown
> > The other question is if it's worth bouncing through too much of an
> > abstraction layer when both ends of the API are fixed.
> If drivers doing pinctrl are used in more than one SoC
On Thu, Oct 20, 2011 at 4:18 PM, Mark Brown
wrote:
> On Thu, Oct 20, 2011 at 04:04:47PM +0200, Linus Walleij wrote:
>> I think (and of course this may be completely wrong, but it's my
>> working hypthesis) that the things that software wants to do to
>> pins are:
>
> The other question is if it's
On Thu, Oct 20, 2011 at 04:04:47PM +0200, Linus Walleij wrote:
> I think (and of course this may be completely wrong, but it's my
> working hypthesis) that the things that software wants to do to
> pins are:
The other question is if it's worth bouncing through too much of an
abstraction layer whe
On Thu, Oct 20, 2011 at 3:10 PM, Shawn Guo wrote:
>> without the common definition from PIN_CONFIG_PULL to
>> PIN_CONFIG_USER, many platforms will need to definite them repeatedly.
>> that is what we hate.
>>
> I prefer to completely leave the encoding of this 'u32 param' to pinctrl
> drivers, s
On Thu, Oct 20, 2011 at 11:17 AM, Barry Song <21cn...@gmail.com> wrote:
> [Shawn]
>> I like Stephen's idea about having 'u32 param' and let pinctrl drivers
>> to encode/decode this u32 for their pinctrl controller. It makes
>> people's life much easier.
>
> A multifunctional API is actually a bad
On Thu, Oct 20, 2011 at 4:45 AM, Shawn Guo wrote:
> There
> are so many pinctrl subsystem internal details left to its users.
The idea is indeed to provide facilities to help with setting up
default configuration
for pins like we set up default pinmux maps. It's not been coded yet though,
atlea
On Thu, Oct 20, 2011 at 4:45 AM, Shawn Guo wrote:
> We should not require device driver to call these APIs directly. There
> are so many pinctrl subsystem internal details left to its users.
As explained I already have drivers that need to do this. OK they
are out-of-tree, but they do exist.
F
On Thu, Oct 20, 2011 at 05:17:08PM +0800, Barry Song wrote:
> >> +enum pin_config_param {
> >> + PIN_CONFIG_BIAS_UNKNOWN,
> >> + PIN_CONFIG_BIAS_FLOAT,
> >> + PIN_CONFIG_BIAS_HIGH_IMPEDANCE,
> >> + PIN_CONFIG_BIAS_PULL_UP,
> >> + PIN_CONFIG_BIAS_PULL_DOWN,
> >> + PIN_CONFIG_
On Thu, Oct 20, 2011 at 1:04 AM, Stephen Warren wrote:
>> +/**
>> + * enum pin_config_param - possible pin configuration parameters
>> + * @PIN_CONFIG_BIAS_UNKNOWN: this bias mode is not known to us
>
> I'm not sure what use that would be; shouldn't we remove that, and add
> new PIN_CONFIG_BIAS_*
2011/10/20 Shawn Guo :
>> #ifdef CONFIG_DEBUG_FS
>>
>> static int pinctrl_pins_show(struct seq_file *s, void *what)
>> diff --git a/include/linux/pinctrl/pinctrl.h
>> b/include/linux/pinctrl/pinctrl.h
>> index 4f8d208..189c047 100644
>> --- a/include/linux/pinctrl/pinctrl.h
>> +++ b/include/linu
On Wed, Oct 19, 2011 at 04:04:29PM -0700, Stephen Warren wrote:
> > @@ -113,6 +204,10 @@ extern struct pinctrl_dev *pinctrl_register(struct
> > pinctrl_desc *pctldesc,
> ...
> > +extern int pin_config(struct pinctrl_dev *pctldev, int pin,
> > + enum pin_config_param param, unsigned
On Wed, Oct 19, 2011 at 06:21:14PM +0200, Linus Walleij wrote:
> From: Linus Walleij
>
> This add per-pin and per-group pin control interfaces for biasing,
> driving and other such electronic properties. The intention is
> clearly to enumerate all things you can do with pins, hoping that
> these
Linus Walleij wrote at Wednesday, October 19, 2011 10:21 AM:
> This add per-pin and per-group pin control interfaces for biasing,
> driving and other such electronic properties. The intention is
> clearly to enumerate all things you can do with pins, hoping that
> these are enumerable.
>
> Signed-
From: Linus Walleij
This add per-pin and per-group pin control interfaces for biasing,
driving and other such electronic properties. The intention is
clearly to enumerate all things you can do with pins, hoping that
these are enumerable.
Signed-off-by: Linus Walleij
---
Documentation/pinctrl.t
27 matches
Mail list logo
