Re: Pulls and drive strengths in the pinctrl world
On 15:42 Thu 23 May , Stephen Warren wrote: On 05/19/2013 03:17 AM, Jean-Christophe PLAGNIOL-VILLARD wrote: ... how a pin can not have mux? Well, if that's the way HW is designed, that's just the way it is. There are certainly pins on Tegra which don't have a mux in HW, but have some configuration options such as drive strength that can be configured. on Samsung it's not the case I mean on at91 we have fixed mux and configurable mux On Tegra IIRC it's the same Best Regards, J. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
On 05/18/2013 10:30 AM, Jean-Christophe PLAGNIOL-VILLARD wrote: On 16:57 Sat 18 May , Tomasz Figa wrote: ... Personally I'd prefer a solution with separate property for each parameter, because it's much more flexible and allows shorter lines, making device tree sources more readable. we already discuss this on the ML the one property perline will endup with 100s of node if not 1000s so we all do agree we do not want this in the DT If you introduce s second level of nodes into the DT like the Tegra bindings do, that's really not an issue. For Tegra, each pinctrl state is a node. Within this, there are a bunch of child nodes, each of which applies to n pins, and sets up an arbitrary set of parameters; some nodes can set up mux functions, some can set up e.g. pull-up, etc. The same pin can be affected by multiple of these nodes. This all allows you to group together common settings and avoid duplication and having too many nodes. Then, client drivers' pincrl-0 properties just reference a single top-level state node, not each of the 10/100/... child nodes. Take a look at something like nodes state_i2xmux_* in arch/arm/boot/dts/tegra20-seaboard.dts. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
On 05/19/2013 03:17 AM, Jean-Christophe PLAGNIOL-VILLARD wrote: ... how a pin can not have mux? Well, if that's the way HW is designed, that's just the way it is. There are certainly pins on Tegra which don't have a mux in HW, but have some configuration options such as drive strength that can be configured. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
On Friday 17 of May 2013 14:26:25 Jean-Christophe PLAGNIOL-VILLARD wrote:
On 18:22 Wed 15 May , Stephen Warren wrote:
On 05/15/2013 06:13 PM, Tomasz Figa wrote:
On Wednesday 15 of May 2013 16:55:37 Doug Anderson wrote:
Tomasz / Linus,
On Wed, May 15, 2013 at 3:06 PM, Tomasz Figa
tomasz.f...@gmail.com
wrote:
Yes. I don't like the current way too much either, duplication
being
one of the reasons.
Do you have any other ideas? It sounds like Linus didn't like my
suggestion and makes some good points...
I don't have anything interesting at the moment. It's a bit late now
here (2 AM), so I'm going to get some sleep first.
Also after reading Stephen's reply, I'm wondering if hogging
wouldn't
solve the problem indeed. (It might have to be fixed on
pinctrl-samsung
first, as last time I tried to use it, it caused some errors from
pinctrl core, but haven't time to track them down, as it wasn't
anything important at that time).
One issue I noticed with the DT fragments earlier in this thread. It
looks like hogs in the Samsung pinctrl bingings end up looking like:
pinctrl {
pina {
samsung,pins = PIN_A PIN_B PIN_C;
samsung,pin-function = 0xf;
samsung,pin-pud = 0;
...
I have a huge issue here that we had on at91 too
we are going to have a huge numbet of node
and on at91 we handle the pin the same way as samsung
and ST have also a similiar IP
so I'll prefer to reuse the AT91 DT bindings
as said by Linus I just push a cleanup of the magic by using Macro
which make it really readable now
some extract of the sama5 pinctrl
mmc0 {
pinctrl_mmc0_clk_cmd_dat0: mmc0_clk_cmd_dat0 {
atmel,pins =
AT91_PIOD 9 AT91_PERIPH_A
AT91_PINCTRL_NONE /* PD9 periph A MCI0_CK
*/ AT91_PIOD 0 AT91_PERIPH_A AT91_PINCTRL_PULL_UP /* PD0 periph A
MCI0_CDA with pullup */ AT91_PIOD 1 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP;/* PD1 periph A MCI0_DA0 with pullup */ };
pinctrl_mmc0_dat1_3: mmc0_dat1_3 {
atmel,pins =
AT91_PIOD 2 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP/* PD2 periph A
MCI0_DA1 with pullup */ AT91_PIOD 3 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP /* PD3 periph A MCI0_DA2 with pullup */ AT91_PIOD
4 AT91_PERIPH_A AT91_PINCTRL_PULL_UP;/* PD4 periph A MCI0_DA3
with
pullup */ };
pinctrl_mmc0_dat4_7: mmc0_dat4_7 {
atmel,pins =
AT91_PIOD 5 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP/* PD5 periph A
MCI0_DA4 with pullup, conflicts with TIOA0, PWMH2 */ AT91_PIOD 6
AT91_PERIPH_A AT91_PINCTRL_PULL_UP/* PD6 periph A MCI0_DA5 with
pullup, conflicts with TIOB0, PWML2 */ AT91_PIOD 7 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP /* PD7 periph A MCI0_DA6 with pullup, conlicts
with TCLK0, PWMH3 */ AT91_PIOD 8 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP;/* PD8 periph A MCI0_DA7 with pullup,
conflicts
with PWML3 */ };
};
of sam9g45
i2c_gpio2 {
pinctrl_i2c_gpio2: i2c_gpio2-0 {
atmel,pins =
AT91_PIOB 4 AT91_PERIPH_GPIO
AT91_PINCTRL_MULTI_DRIVE/* PB4 gpio
multidrive I2C2 data */ AT91_PIOB 5 AT91_PERIPH_GPIO
AT91_PINCTRL_MULTI_DRIVE;/* PB5 gpio multidrive I2C2 clock */ };
};
so we could share the c code too
OK. After thinking about it a bit more recently, I think your solution
might be fine.
However there is one thing I'm worried about. As far as I remember, when
setting a function (mux selector), pinctrl core calls pin_request() to
request all pins of the group for the device which requested the
configuration.
Now if we use hogs to set up default configuration of pins, all of them
would get requested for the pin controller and then further pin control
configuration done by device drivers would fail. This is why I wanted to
allow setting pinmux and pinconf separately, without one requiring
another.
Best regards,
Tomasz
Best Regards,
J,
};
pinp {
samsung,pins = PIN_P PIN_Q;
samsung,pin-function = 0xe;
samsung,pin-pud = 1;
...
};
pinx {
samsung,pins = PIN_X PIN_Y PIN_Z;
samsung,pin-function = 0xd;
samsung,pin-pud = 2;
...
};
pinctrl-names = default;
pinctrl-0 = pina pinp pinx;
};
That pinctrl-0 property could get rather large (hard to
write/maintain,
unwieldy) if it needs to set up lots of different configurations.
That's why I made the equivalent Tegra bindings be:
pinctrl {
pins_default {
pina {
samsung,pins = PIN_A PIN_B PIN_C;
samsung,pin-function = 0xf;
samsung,pin-pud = 0;
Re: Pulls and drive strengths in the pinctrl world
On 11:28 Tue 21 May , Tomasz Figa wrote:
On Friday 17 of May 2013 14:26:25 Jean-Christophe PLAGNIOL-VILLARD wrote:
On 18:22 Wed 15 May , Stephen Warren wrote:
On 05/15/2013 06:13 PM, Tomasz Figa wrote:
On Wednesday 15 of May 2013 16:55:37 Doug Anderson wrote:
Tomasz / Linus,
On Wed, May 15, 2013 at 3:06 PM, Tomasz Figa
tomasz.f...@gmail.com
wrote:
Yes. I don't like the current way too much either, duplication
being
one of the reasons.
Do you have any other ideas? It sounds like Linus didn't like my
suggestion and makes some good points...
I don't have anything interesting at the moment. It's a bit late now
here (2 AM), so I'm going to get some sleep first.
Also after reading Stephen's reply, I'm wondering if hogging
wouldn't
solve the problem indeed. (It might have to be fixed on
pinctrl-samsung
first, as last time I tried to use it, it caused some errors from
pinctrl core, but haven't time to track them down, as it wasn't
anything important at that time).
One issue I noticed with the DT fragments earlier in this thread. It
looks like hogs in the Samsung pinctrl bingings end up looking like:
pinctrl {
pina {
samsung,pins = PIN_A PIN_B PIN_C;
samsung,pin-function = 0xf;
samsung,pin-pud = 0;
...
I have a huge issue here that we had on at91 too
we are going to have a huge numbet of node
and on at91 we handle the pin the same way as samsung
and ST have also a similiar IP
so I'll prefer to reuse the AT91 DT bindings
as said by Linus I just push a cleanup of the magic by using Macro
which make it really readable now
some extract of the sama5 pinctrl
mmc0 {
pinctrl_mmc0_clk_cmd_dat0: mmc0_clk_cmd_dat0 {
atmel,pins =
AT91_PIOD 9 AT91_PERIPH_A
AT91_PINCTRL_NONE /* PD9 periph A MCI0_CK
*/ AT91_PIOD 0 AT91_PERIPH_A AT91_PINCTRL_PULL_UP /* PD0 periph A
MCI0_CDA with pullup */ AT91_PIOD 1 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP; /* PD1 periph A MCI0_DA0 with pullup */ };
pinctrl_mmc0_dat1_3: mmc0_dat1_3 {
atmel,pins =
AT91_PIOD 2 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP /* PD2 periph A
MCI0_DA1 with pullup */ AT91_PIOD 3 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP/* PD3 periph A MCI0_DA2 with pullup */
AT91_PIOD
4 AT91_PERIPH_A AT91_PINCTRL_PULL_UP; /* PD4 periph A MCI0_DA3
with
pullup */ };
pinctrl_mmc0_dat4_7: mmc0_dat4_7 {
atmel,pins =
AT91_PIOD 5 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP /* PD5 periph A
MCI0_DA4 with pullup, conflicts with TIOA0, PWMH2 */ AT91_PIOD 6
AT91_PERIPH_A AT91_PINCTRL_PULL_UP /* PD6 periph A MCI0_DA5 with
pullup, conflicts with TIOB0, PWML2 */ AT91_PIOD 7 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP/* PD7 periph A MCI0_DA6 with pullup, conlicts
with TCLK0, PWMH3 */ AT91_PIOD 8 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP; /* PD8 periph A MCI0_DA7 with pullup,
conflicts
with PWML3 */ };
};
of sam9g45
i2c_gpio2 {
pinctrl_i2c_gpio2: i2c_gpio2-0 {
atmel,pins =
AT91_PIOB 4 AT91_PERIPH_GPIO
AT91_PINCTRL_MULTI_DRIVE /* PB4 gpio
multidrive I2C2 data */ AT91_PIOB 5 AT91_PERIPH_GPIO
AT91_PINCTRL_MULTI_DRIVE; /* PB5 gpio multidrive I2C2 clock */ };
};
so we could share the c code too
OK. After thinking about it a bit more recently, I think your solution
might be fine.
However there is one thing I'm worried about. As far as I remember, when
setting a function (mux selector), pinctrl core calls pin_request() to
request all pins of the group for the device which requested the
configuration.
Now if we use hogs to set up default configuration of pins, all of them
would get requested for the pin controller and then further pin control
configuration done by device drivers would fail. This is why I wanted to
allow setting pinmux and pinconf separately, without one requiring
another.
I undertatnd you use default config for power management optimisation, is it
not?
so you need to set different state in the device instead of using hogs.
default, sleep, etc..
I get an other issue too I have the same pin requested more than one time by
multiple driver.
As thoses pins are used for external memory interface, but they have the same
config. The current pinctrl implementation does not allow share pin.
Best Regards,
J.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
PULL_UP (1 0): indicate this pin need a pull up.
MULTIDRIVE (1 1): indicate this pin need to be configured as
multidrive. DEGLITCH(1 2): indicate this pin need
deglitch.
PULL_DOWN (1 3): indicate this pin need a pull down.
DIS_SCHMIT (1 4): indicate this pin need to disable schmit
trigger. DEBOUNCE(1 16): indicate this pin need debounce.
DEBOUNCE_VAL(0x3fff 17): debounce val.
today I was planning to update the binding to allow to this
instead of writing this
dbgu {
pinctrl_dbgu: dbgu-0 {
atmel,pins =
AT91_PIOB 30 AT91_PERIPH_A AT91_PINCTRL_NONE
AT91_PIOB 31 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP;
};
};
we will write this
dbgu {
pinctrl_dbgu: dbgu-0 {
atmel,pins =
AT91_PIOB 30 AT91_PERIPH_A,
AT91_PIOB 31 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP;
};
};
so a pin can have 3 or more parameter
so as a generic binding only the 3 first will be namdatory (bank
pinnp
muxid) the rest will driver specific
for power down I plan to define an other node
dbgu {
pinctrl_dbgu_sleep: dbgu_sleep-0 {
atmel,pins =
AT91_PIOB 30 AT91_PERIPH_GPIO,
AT91_PIOB 31 AT91_PERIPH_A
AT91_PINCTRL_PULL_DOWN;
};
};
I'm afraid this won't work for Samsung SoCs. In our case normal and
power down settings are completely unrelated, i.e. stored in separate
registers and one doesn't affect another (a system controller
automatically switches between normal and power down settings when
entering or leaving low power modes, like SoC-level suspend).
and?
Pin configuration node on Exynos SoCs will need 7 values for each pin in
samsung,pins property, just like in following example:
mmc0 {
mmc0_bus1: mmc0-bus1 {
pins = GPA0 4 SFN3 PULL_UP DRV4 PDN_IN PDN_PULL_UP;
};
/* ... */
};
Now if I just want to enable pull-up for a single pin, I will have to add
following node:
foo {
pins = GPK1 2 NONE PULL_UP NONE NONE NONE;
};
no you will not
foo {
pins = GPK1 2 NONE PULL_UP;
};
how a pin can not have mux?
while with current bindings I can simply omit properties that I don't care
about (or are going to be set up correctly by other means - e.g.
gpio_direction_input() or request_irq(), ending with following node:
foo {
samsung,pins = gpk1-2;
samsung,pin-pud = 3;
};
except here you will 100s of NODE which we do NOT want in the dtb
This is all I need to configure for simple things like open-drain
interrupt lines.
Another thing is that we're using one driver for many SoCs, which have
different variants of the controller. So for example some of them don't
have driver strength configuration (S3C24xx, S3C64xx), other don't have
power down mode configuration (S3C24xx) and even some of the banks on some
SoCs don't support particular type of configuration (alive banks of SoCs
same on at91 some IP have less feature
and some SoC have the IP/die but not the same pins package
the key point is to share the pin DT handling between at91, ST and Samsung
ofcourse all the IP will have more or less parameter per pin but the basic is
the same for DT and C code
= S3C64xx don't have power down mode configuration, because they are
always on).
on at91 I've x banks of registers to handle each gpio bank
on ST with have same situation but the controller work the same way at
the end
so we need to factorise code
Personally I'd prefer a solution with separate property for each
parameter, because it's much more flexible and allows shorter lines,
making device tree sources more readable.
we already discuss this on the ML the one property perline will endup
with 100s of node if not 1000s so we all do agree we do not want this
in the DT
Could you point me to this discussion, please? I'd really like to take a
look.
you have to search this on the dt ML, it was about the clk bindings IIRC and
agree on this at Prague durring kernel Summit
Best Regards,
J.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
On Sunday 19 of May 2013 11:17:36 Jean-Christophe PLAGNIOL-VILLARD wrote:
PULL_UP (1 0): indicate this pin need a pull up.
MULTIDRIVE (1 1): indicate this pin need to be
configured as
multidrive. DEGLITCH(1 2): indicate this pin need
deglitch.
PULL_DOWN (1 3): indicate this pin need a pull down.
DIS_SCHMIT (1 4): indicate this pin need to disable
schmit
trigger. DEBOUNCE(1 16): indicate this pin need
debounce.
DEBOUNCE_VAL(0x3fff 17): debounce val.
today I was planning to update the binding to allow to this
instead of writing this
dbgu {
pinctrl_dbgu: dbgu-0 {
atmel,pins =
AT91_PIOB 30 AT91_PERIPH_A
AT91_PINCTRL_NONE
AT91_PIOB 31 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP;
};
};
we will write this
dbgu {
pinctrl_dbgu: dbgu-0 {
atmel,pins =
AT91_PIOB 30 AT91_PERIPH_A,
AT91_PIOB 31 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP;
};
};
so a pin can have 3 or more parameter
so as a generic binding only the 3 first will be namdatory (bank
pinnp
muxid) the rest will driver specific
for power down I plan to define an other node
dbgu {
pinctrl_dbgu_sleep: dbgu_sleep-0 {
atmel,pins =
AT91_PIOB 30 AT91_PERIPH_GPIO,
AT91_PIOB 31 AT91_PERIPH_A
AT91_PINCTRL_PULL_DOWN;
};
};
I'm afraid this won't work for Samsung SoCs. In our case normal
and
power down settings are completely unrelated, i.e. stored in
separate
registers and one doesn't affect another (a system controller
automatically switches between normal and power down settings when
entering or leaving low power modes, like SoC-level suspend).
and?
Pin configuration node on Exynos SoCs will need 7 values for each pin
in samsung,pins property, just like in following example:
mmc0 {
mmc0_bus1: mmc0-bus1 {
pins = GPA0 4 SFN3 PULL_UP DRV4 PDN_IN PDN_PULL_UP;
};
/* ... */
};
Now if I just want to enable pull-up for a single pin, I will have to
add following node:
foo {
pins = GPK1 2 NONE PULL_UP NONE NONE NONE;
};
no you will not
foo {
pins = GPK1 2 NONE PULL_UP;
};
OK, this will work in case of one pin, but if you need two it starts to
become problematic. Let's look at an example:
We have two pins for which we don't need to specify power down mode
settings (e.g. they are in alive banks):
foo {
pins = GPK1 2 NONE PULL_UP,
GPK1 3 NONE PULL_UP;
};
After compilation you will get just a series of u32 values, like
foo {
pins = 1 2 255 3 1 3 255 3;
};
How are you going to distinguish such setup with:
foo {
pins = GPK1 2 NONE PULL_UP NONE NONE NONE,
GPK1 3 NONE PULL_UP NONE NONE NONE;
};
which translates to
foo {
pins = 1 2 255 3 255 255 255 1 3 255 3 255 255 255;
};
I mean, you don't know where one entry ends and another starts, if you
allow to left out some values.
how a pin can not have mux?
I don't always want to change the mux. Sometimes I just want to change one
of the other parameters. For example, I don't want to switch the pin to
interrupt mode on driver probe (it is a separate pin mux value), but
rather after the trigger type gets configured, which is done by
request_irq() based on trigger flags.
while with current bindings I can simply omit properties that I don't
care about (or are going to be set up correctly by other means - e.g.
gpio_direction_input() or request_irq(), ending with following node:
foo {
samsung,pins = gpk1-2;
samsung,pin-pud = 3;
};
except here you will 100s of NODE which we do NOT want in the dtb
Is this really an issue?
We are already using this method to describe really complex boards (not
necessarily in mainline) and we don't have any problems.
This is all I need to configure for simple things like open-drain
interrupt lines.
Another thing is that we're using one driver for many SoCs, which have
different variants of the controller. So for example some of them
don't
have driver strength configuration (S3C24xx, S3C64xx), other don't
have
power down mode configuration (S3C24xx) and even some of the banks on
some SoCs don't support particular type of configuration (alive banks
of SoCs
same on at91 some IP have less feature
Re: Pulls and drive strengths in the pinctrl world
On 11:46 Sun 19 May , Tomasz Figa wrote:
On Sunday 19 of May 2013 11:17:36 Jean-Christophe PLAGNIOL-VILLARD wrote:
PULL_UP (1 0): indicate this pin need a pull up.
MULTIDRIVE (1 1): indicate this pin need to be
configured as
multidrive. DEGLITCH(1 2): indicate this pin need
deglitch.
PULL_DOWN (1 3): indicate this pin need a pull down.
DIS_SCHMIT (1 4): indicate this pin need to disable
schmit
trigger. DEBOUNCE(1 16): indicate this pin need
debounce.
DEBOUNCE_VAL(0x3fff 17): debounce val.
today I was planning to update the binding to allow to this
instead of writing this
dbgu {
pinctrl_dbgu: dbgu-0 {
atmel,pins =
AT91_PIOB 30 AT91_PERIPH_A
AT91_PINCTRL_NONE
AT91_PIOB 31 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP;
};
};
we will write this
dbgu {
pinctrl_dbgu: dbgu-0 {
atmel,pins =
AT91_PIOB 30 AT91_PERIPH_A,
AT91_PIOB 31 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP;
};
};
so a pin can have 3 or more parameter
so as a generic binding only the 3 first will be namdatory (bank
pinnp
muxid) the rest will driver specific
for power down I plan to define an other node
dbgu {
pinctrl_dbgu_sleep: dbgu_sleep-0 {
atmel,pins =
AT91_PIOB 30 AT91_PERIPH_GPIO,
AT91_PIOB 31 AT91_PERIPH_A
AT91_PINCTRL_PULL_DOWN;
};
};
I'm afraid this won't work for Samsung SoCs. In our case normal
and
power down settings are completely unrelated, i.e. stored in
separate
registers and one doesn't affect another (a system controller
automatically switches between normal and power down settings when
entering or leaving low power modes, like SoC-level suspend).
and?
Pin configuration node on Exynos SoCs will need 7 values for each pin
in samsung,pins property, just like in following example:
mmc0 {
mmc0_bus1: mmc0-bus1 {
pins = GPA0 4 SFN3 PULL_UP DRV4 PDN_IN PDN_PULL_UP;
};
/* ... */
};
Now if I just want to enable pull-up for a single pin, I will have to
add following node:
foo {
pins = GPK1 2 NONE PULL_UP NONE NONE NONE;
};
no you will not
foo {
pins = GPK1 2 NONE PULL_UP;
};
OK, this will work in case of one pin, but if you need two it starts to
become problematic. Let's look at an example:
We have two pins for which we don't need to specify power down mode
settings (e.g. they are in alive banks):
foo {
pins = GPK1 2 NONE PULL_UP,
GPK1 3 NONE PULL_UP;
};
as done for cs-gpios
After compilation you will get just a series of u32 values, like
foo {
pins = 1 2 255 3 1 3 255 3;
};
How are you going to distinguish such setup with:
foo {
pins = GPK1 2 NONE PULL_UP NONE NONE NONE,
GPK1 3 NONE PULL_UP NONE NONE NONE;
};
which translates to
foo {
pins = 1 2 255 3 255 255 255 1 3 255 3 255 255 255;
};
I mean, you don't know where one entry ends and another starts, if you
allow to left out some values.
on gpios we can do so, I want to have the same feature here
how a pin can not have mux?
I don't always want to change the mux. Sometimes I just want to change one
of the other parameters. For example, I don't want to switch the pin to
interrupt mode on driver probe (it is a separate pin mux value), but
rather after the trigger type gets configured, which is done by
request_irq() based on trigger flags.
so request the same
while with current bindings I can simply omit properties that I don't
care about (or are going to be set up correctly by other means - e.g.
gpio_direction_input() or request_irq(), ending with following node:
foo {
samsung,pins = gpk1-2;
samsung,pin-pud = 3;
};
except here you will 100s of NODE which we do NOT want in the dtb
Is this really an issue?
just one example
slow down the boot
We are already using this method to describe really complex boards (not
necessarily in mainline) and we don't have any problems.
This is all I need to configure for simple things like open-drain
interrupt lines.
Another thing is that we're using one driver for many SoCs, which have
different variants of the controller. So for example some of
Re: Pulls and drive strengths in the pinctrl world
On 14:17 Fri 17 May , Tomasz Figa wrote:
Hi Jean-Christophe,
On Friday 17 of May 2013 14:26:25 Jean-Christophe PLAGNIOL-VILLARD wrote:
On 18:22 Wed 15 May , Stephen Warren wrote:
On 05/15/2013 06:13 PM, Tomasz Figa wrote:
On Wednesday 15 of May 2013 16:55:37 Doug Anderson wrote:
Tomasz / Linus,
On Wed, May 15, 2013 at 3:06 PM, Tomasz Figa
tomasz.f...@gmail.com
wrote:
Yes. I don't like the current way too much either, duplication
being
one of the reasons.
Do you have any other ideas? It sounds like Linus didn't like my
suggestion and makes some good points...
I don't have anything interesting at the moment. It's a bit late now
here (2 AM), so I'm going to get some sleep first.
Also after reading Stephen's reply, I'm wondering if hogging
wouldn't
solve the problem indeed. (It might have to be fixed on
pinctrl-samsung
first, as last time I tried to use it, it caused some errors from
pinctrl core, but haven't time to track them down, as it wasn't
anything important at that time).
One issue I noticed with the DT fragments earlier in this thread. It
looks like hogs in the Samsung pinctrl bingings end up looking like:
pinctrl {
pina {
samsung,pins = PIN_A PIN_B PIN_C;
samsung,pin-function = 0xf;
samsung,pin-pud = 0;
...
I have a huge issue here that we had on at91 too
we are going to have a huge numbet of node
and on at91 we handle the pin the same way as samsung
and ST have also a similiar IP
so I'll prefer to reuse the AT91 DT bindings
as said by Linus I just push a cleanup of the magic by using Macro
which make it really readable now
some extract of the sama5 pinctrl
mmc0 {
pinctrl_mmc0_clk_cmd_dat0: mmc0_clk_cmd_dat0 {
atmel,pins =
AT91_PIOD 9 AT91_PERIPH_A
AT91_PINCTRL_NONE /* PD9 periph A MCI0_CK
*/ AT91_PIOD 0 AT91_PERIPH_A AT91_PINCTRL_PULL_UP /* PD0 periph A
MCI0_CDA with pullup */ AT91_PIOD 1 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP; /* PD1 periph A MCI0_DA0 with pullup */ };
pinctrl_mmc0_dat1_3: mmc0_dat1_3 {
atmel,pins =
AT91_PIOD 2 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP /* PD2 periph A
MCI0_DA1 with pullup */ AT91_PIOD 3 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP/* PD3 periph A MCI0_DA2 with pullup */
AT91_PIOD
4 AT91_PERIPH_A AT91_PINCTRL_PULL_UP; /* PD4 periph A MCI0_DA3
with
pullup */ };
pinctrl_mmc0_dat4_7: mmc0_dat4_7 {
atmel,pins =
AT91_PIOD 5 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP /* PD5 periph A
MCI0_DA4 with pullup, conflicts with TIOA0, PWMH2 */ AT91_PIOD 6
AT91_PERIPH_A AT91_PINCTRL_PULL_UP /* PD6 periph A MCI0_DA5 with
pullup, conflicts with TIOB0, PWML2 */ AT91_PIOD 7 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP/* PD7 periph A MCI0_DA6 with pullup, conlicts
with TCLK0, PWMH3 */ AT91_PIOD 8 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP; /* PD8 periph A MCI0_DA7 with pullup,
conflicts
with PWML3 */ };
};
of sam9g45
i2c_gpio2 {
pinctrl_i2c_gpio2: i2c_gpio2-0 {
atmel,pins =
AT91_PIOB 4 AT91_PERIPH_GPIO
AT91_PINCTRL_MULTI_DRIVE /* PB4 gpio
multidrive I2C2 data */ AT91_PIOB 5 AT91_PERIPH_GPIO
AT91_PINCTRL_MULTI_DRIVE; /* PB5 gpio multidrive I2C2 clock */ };
};
so we could share the c code too
I'd have a question with regard to AT91 bindings.
Using Samsung bindings we don't need to specify all configuration options
for a pin, only those that are relevant for the platform. Do your bindings
allow this?
on at91 we have this too we just put NONE, and I'm planning to allow to drop
the last option too (not yet implement)
Apparently AT91 has less configurable things and those available are
usually always configured together so it's not a problem. But on our SoCs
we have a bit more of them:
- function (input, output, special functions)
- pull-down/-up
- driver strength
- power down mode function (input, output low, output high, retention)
- power down mode pull-down/-up
- one could argue that default output value could be set this way as well,
by adding samsung,pin-value property.
on Atmel you have
first a pin need to be muxed as a gpio or a function name periph
depending on the SoC we can have up to 4 function mode + gpio
then each pin have feature that are independent of the mux function
Bits used for CONFIG: (4th parameter)
PULL_UP (1 0): indicate this pin need a pull up.
MULTIDRIVE (1 1): indicate this pin need to be configured as multidrive.
DEGLITCH(1 2): indicate this pin need deglitch.
PULL_DOWN (1 3): indicate this pin need a pull down.
DIS_SCHMIT (1
Re: Pulls and drive strengths in the pinctrl world
On Saturday 18 of May 2013 10:18:47 Jean-Christophe PLAGNIOL-VILLARD
wrote:
On 14:17 Fri 17 May , Tomasz Figa wrote:
Hi Jean-Christophe,
On Friday 17 of May 2013 14:26:25 Jean-Christophe PLAGNIOL-VILLARD
wrote:
On 18:22 Wed 15 May , Stephen Warren wrote:
On 05/15/2013 06:13 PM, Tomasz Figa wrote:
On Wednesday 15 of May 2013 16:55:37 Doug Anderson wrote:
Tomasz / Linus,
On Wed, May 15, 2013 at 3:06 PM, Tomasz Figa
tomasz.f...@gmail.com
wrote:
Yes. I don't like the current way too much either, duplication
being
one of the reasons.
Do you have any other ideas? It sounds like Linus didn't like
my
suggestion and makes some good points...
I don't have anything interesting at the moment. It's a bit late
now
here (2 AM), so I'm going to get some sleep first.
Also after reading Stephen's reply, I'm wondering if hogging
wouldn't
solve the problem indeed. (It might have to be fixed on
pinctrl-samsung
first, as last time I tried to use it, it caused some errors
from
pinctrl core, but haven't time to track them down, as it wasn't
anything important at that time).
One issue I noticed with the DT fragments earlier in this thread.
It
looks like hogs in the Samsung pinctrl bingings end up looking
like:
pinctrl {
pina {
samsung,pins = PIN_A PIN_B PIN_C;
samsung,pin-function = 0xf;
samsung,pin-pud = 0;
...
I have a huge issue here that we had on at91 too
we are going to have a huge numbet of node
and on at91 we handle the pin the same way as samsung
and ST have also a similiar IP
so I'll prefer to reuse the AT91 DT bindings
as said by Linus I just push a cleanup of the magic by using Macro
which make it really readable now
some extract of the sama5 pinctrl
mmc0 {
pinctrl_mmc0_clk_cmd_dat0: mmc0_clk_cmd_dat0 {
atmel,pins =
AT91_PIOD 9 AT91_PERIPH_A
AT91_PINCTRL_NONE /* PD9 periph A MCI0_CK
*/ AT91_PIOD 0 AT91_PERIPH_A AT91_PINCTRL_PULL_UP /* PD0 periph A
MCI0_CDA with pullup */ AT91_PIOD 1 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP;/* PD1 periph A MCI0_DA0 with pullup */ };
pinctrl_mmc0_dat1_3: mmc0_dat1_3 {
atmel,pins =
AT91_PIOD 2 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP/* PD2 periph A
MCI0_DA1 with pullup */ AT91_PIOD 3 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP /* PD3 periph A MCI0_DA2 with pullup */
AT91_PIOD
4 AT91_PERIPH_A AT91_PINCTRL_PULL_UP;/* PD4 periph A MCI0_DA3
with
pullup */ };
pinctrl_mmc0_dat4_7: mmc0_dat4_7 {
atmel,pins =
AT91_PIOD 5 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP/* PD5 periph A
MCI0_DA4 with pullup, conflicts with TIOA0, PWMH2 */ AT91_PIOD 6
AT91_PERIPH_A AT91_PINCTRL_PULL_UP/* PD6 periph A MCI0_DA5
with
pullup, conflicts with TIOB0, PWML2 */ AT91_PIOD 7 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP /* PD7 periph A MCI0_DA6 with pullup,
conlicts
with TCLK0, PWMH3 */ AT91_PIOD 8 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP;/* PD8 periph A MCI0_DA7 with pullup,
conflicts
with PWML3 */ };
};
of sam9g45
i2c_gpio2 {
pinctrl_i2c_gpio2: i2c_gpio2-0 {
atmel,pins =
AT91_PIOB 4 AT91_PERIPH_GPIO
AT91_PINCTRL_MULTI_DRIVE/* PB4 gpio
multidrive I2C2 data */ AT91_PIOB 5 AT91_PERIPH_GPIO
AT91_PINCTRL_MULTI_DRIVE;/* PB5 gpio multidrive I2C2 clock
*/ };
};
so we could share the c code too
I'd have a question with regard to AT91 bindings.
Using Samsung bindings we don't need to specify all configuration
options for a pin, only those that are relevant for the platform. Do
your bindings allow this?
on at91 we have this too we just put NONE, and I'm planning to allow to
drop the last option too (not yet implement)
Apparently AT91 has less configurable things and those available are
usually always configured together so it's not a problem. But on our
SoCs we have a bit more of them:
- function (input, output, special functions)
- pull-down/-up
- driver strength
- power down mode function (input, output low, output high, retention)
- power down mode pull-down/-up
- one could argue that default output value could be set this way as
well, by adding samsung,pin-value property.
on Atmel you have
first a pin need to be muxed as a gpio or a function name periph
depending on the SoC we can have up to 4
Re: Pulls and drive strengths in the pinctrl world
On 16:57 Sat 18 May , Tomasz Figa wrote:
On Saturday 18 of May 2013 10:18:47 Jean-Christophe PLAGNIOL-VILLARD
wrote:
On 14:17 Fri 17 May , Tomasz Figa wrote:
Hi Jean-Christophe,
On Friday 17 of May 2013 14:26:25 Jean-Christophe PLAGNIOL-VILLARD
wrote:
On 18:22 Wed 15 May , Stephen Warren wrote:
On 05/15/2013 06:13 PM, Tomasz Figa wrote:
On Wednesday 15 of May 2013 16:55:37 Doug Anderson wrote:
Tomasz / Linus,
On Wed, May 15, 2013 at 3:06 PM, Tomasz Figa
tomasz.f...@gmail.com
wrote:
Yes. I don't like the current way too much either, duplication
being
one of the reasons.
Do you have any other ideas? It sounds like Linus didn't like
my
suggestion and makes some good points...
I don't have anything interesting at the moment. It's a bit late
now
here (2 AM), so I'm going to get some sleep first.
Also after reading Stephen's reply, I'm wondering if hogging
wouldn't
solve the problem indeed. (It might have to be fixed on
pinctrl-samsung
first, as last time I tried to use it, it caused some errors
from
pinctrl core, but haven't time to track them down, as it wasn't
anything important at that time).
One issue I noticed with the DT fragments earlier in this thread.
It
looks like hogs in the Samsung pinctrl bingings end up looking
like:
pinctrl {
pina {
samsung,pins = PIN_A PIN_B PIN_C;
samsung,pin-function = 0xf;
samsung,pin-pud = 0;
...
I have a huge issue here that we had on at91 too
we are going to have a huge numbet of node
and on at91 we handle the pin the same way as samsung
and ST have also a similiar IP
so I'll prefer to reuse the AT91 DT bindings
as said by Linus I just push a cleanup of the magic by using Macro
which make it really readable now
some extract of the sama5 pinctrl
mmc0 {
pinctrl_mmc0_clk_cmd_dat0: mmc0_clk_cmd_dat0 {
atmel,pins =
AT91_PIOD 9 AT91_PERIPH_A
AT91_PINCTRL_NONE /* PD9 periph A MCI0_CK
*/ AT91_PIOD 0 AT91_PERIPH_A AT91_PINCTRL_PULL_UP /* PD0 periph A
MCI0_CDA with pullup */ AT91_PIOD 1 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP; /* PD1 periph A MCI0_DA0 with pullup */ };
pinctrl_mmc0_dat1_3: mmc0_dat1_3 {
atmel,pins =
AT91_PIOD 2 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP /* PD2 periph A
MCI0_DA1 with pullup */ AT91_PIOD 3 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP/* PD3 periph A MCI0_DA2 with pullup */
AT91_PIOD
4 AT91_PERIPH_A AT91_PINCTRL_PULL_UP; /* PD4 periph A MCI0_DA3
with
pullup */ };
pinctrl_mmc0_dat4_7: mmc0_dat4_7 {
atmel,pins =
AT91_PIOD 5 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP /* PD5 periph A
MCI0_DA4 with pullup, conflicts with TIOA0, PWMH2 */ AT91_PIOD 6
AT91_PERIPH_A AT91_PINCTRL_PULL_UP /* PD6 periph A MCI0_DA5
with
pullup, conflicts with TIOB0, PWML2 */ AT91_PIOD 7 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP/* PD7 periph A MCI0_DA6 with pullup,
conlicts
with TCLK0, PWMH3 */ AT91_PIOD 8 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP; /* PD8 periph A MCI0_DA7 with pullup,
conflicts
with PWML3 */ };
};
of sam9g45
i2c_gpio2 {
pinctrl_i2c_gpio2: i2c_gpio2-0 {
atmel,pins =
AT91_PIOB 4 AT91_PERIPH_GPIO
AT91_PINCTRL_MULTI_DRIVE /* PB4 gpio
multidrive I2C2 data */ AT91_PIOB 5 AT91_PERIPH_GPIO
AT91_PINCTRL_MULTI_DRIVE; /* PB5 gpio multidrive I2C2 clock
*/ };
};
so we could share the c code too
I'd have a question with regard to AT91 bindings.
Using Samsung bindings we don't need to specify all configuration
options for a pin, only those that are relevant for the platform. Do
your bindings allow this?
on at91 we have this too we just put NONE, and I'm planning to allow to
drop the last option too (not yet implement)
Apparently AT91 has less configurable things and those available are
usually always configured together so it's not a problem. But on our
SoCs we have a bit more of them:
- function (input, output, special functions)
- pull-down/-up
- driver strength
- power down
Re: Pulls and drive strengths in the pinctrl world
On Saturday 18 of May 2013 18:30:01 Jean-Christophe PLAGNIOL-VILLARD
wrote:
On 16:57 Sat 18 May , Tomasz Figa wrote:
On Saturday 18 of May 2013 10:18:47 Jean-Christophe PLAGNIOL-VILLARD
wrote:
On 14:17 Fri 17 May , Tomasz Figa wrote:
Hi Jean-Christophe,
On Friday 17 of May 2013 14:26:25 Jean-Christophe PLAGNIOL-VILLARD
wrote:
On 18:22 Wed 15 May , Stephen Warren wrote:
On 05/15/2013 06:13 PM, Tomasz Figa wrote:
On Wednesday 15 of May 2013 16:55:37 Doug Anderson wrote:
Tomasz / Linus,
On Wed, May 15, 2013 at 3:06 PM, Tomasz Figa
tomasz.f...@gmail.com
wrote:
Yes. I don't like the current way too much either,
duplication
being
one of the reasons.
Do you have any other ideas? It sounds like Linus didn't
like
my
suggestion and makes some good points...
I don't have anything interesting at the moment. It's a bit
late
now
here (2 AM), so I'm going to get some sleep first.
Also after reading Stephen's reply, I'm wondering if hogging
wouldn't
solve the problem indeed. (It might have to be fixed on
pinctrl-samsung
first, as last time I tried to use it, it caused some errors
from
pinctrl core, but haven't time to track them down, as it
wasn't
anything important at that time).
One issue I noticed with the DT fragments earlier in this
thread.
It
looks like hogs in the Samsung pinctrl bingings end up looking
like:
pinctrl {
pina {
samsung,pins = PIN_A PIN_B PIN_C;
samsung,pin-function = 0xf;
samsung,pin-pud = 0;
...
I have a huge issue here that we had on at91 too
we are going to have a huge numbet of node
and on at91 we handle the pin the same way as samsung
and ST have also a similiar IP
so I'll prefer to reuse the AT91 DT bindings
as said by Linus I just push a cleanup of the magic by using
Macro
which make it really readable now
some extract of the sama5 pinctrl
mmc0 {
pinctrl_mmc0_clk_cmd_dat0: mmc0_clk_cmd_dat0 {
atmel,pins =
AT91_PIOD 9 AT91_PERIPH_A
AT91_PINCTRL_NONE /* PD9 periph A MCI0_CK
*/ AT91_PIOD 0 AT91_PERIPH_A AT91_PINCTRL_PULL_UP /* PD0
periph
A
MCI0_CDA with pullup */ AT91_PIOD 1 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP;/* PD1 periph A MCI0_DA0 with
pullup */
};
pinctrl_mmc0_dat1_3: mmc0_dat1_3 {
atmel,pins =
AT91_PIOD 2 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP/* PD2 periph A
MCI0_DA1 with pullup */ AT91_PIOD 3 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP /* PD3 periph A MCI0_DA2 with pullup */
AT91_PIOD
4 AT91_PERIPH_A AT91_PINCTRL_PULL_UP;/* PD4 periph A
MCI0_DA3
with
pullup */ };
pinctrl_mmc0_dat4_7: mmc0_dat4_7 {
atmel,pins =
AT91_PIOD 5 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP/* PD5 periph A
MCI0_DA4 with pullup, conflicts with TIOA0, PWMH2 */ AT91_PIOD 6
AT91_PERIPH_A AT91_PINCTRL_PULL_UP/* PD6 periph A MCI0_DA5
with
pullup, conflicts with TIOB0, PWML2 */ AT91_PIOD 7 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP /* PD7 periph A MCI0_DA6 with pullup,
conlicts
with TCLK0, PWMH3 */ AT91_PIOD 8 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP;/* PD8 periph A MCI0_DA7 with
pullup,
conflicts
with PWML3 */ };
};
of sam9g45
i2c_gpio2 {
pinctrl_i2c_gpio2: i2c_gpio2-0 {
atmel,pins =
AT91_PIOB 4 AT91_PERIPH_GPIO
AT91_PINCTRL_MULTI_DRIVE/* PB4 gpio
multidrive I2C2 data */ AT91_PIOB 5 AT91_PERIPH_GPIO
AT91_PINCTRL_MULTI_DRIVE;/* PB5 gpio multidrive I2C2 clock
*/ };
};
so we could share the c code too
I'd have a question with regard to AT91 bindings.
Using Samsung bindings we don't need to specify all configuration
options for a pin, only those that are relevant for the platform.
Do
your bindings allow this?
on at91 we have this too we just put NONE, and I'm planning to allow
to
drop the last option too (not yet implement)
Apparently AT91 has
Re: Pulls and drive strengths in the pinctrl world
On Thu, May 16, 2013 at 2:03 AM, Doug Anderson diand...@google.com wrote:
I prefer to put all the static pinctrl configuration in the pinctrl hog,
and only the dynamic stuff in the individual device nodes.
I know LinusW won't like this suggestion much though:-)
(It's not that bad actually...)
Ah right! I forgot about hogs in this case. That's also reasonable
as a solution and is similar to what we've got in the tree for
powerdown configuration of pins (I'll try to post this patch soon too,
WIP at https://gerrit.chromium.org/gerrit/#/c/51292/ and
https://gerrit.chromium.org/gerrit/#/c/51372/.
I don't like these Gerrit patches really, it's better to move
this to the pinctrl core using hogs.
If you look in drivers/pinctr/core.c you can find this:
pinctrl_register()
{
(...)
if (!IS_ERR(pctldev-p)) {
pctldev-hog_default =
pinctrl_lookup_state(pctldev-p, PINCTRL_STATE_DEFAULT);
if (IS_ERR(pctldev-hog_default)) {
dev_dbg(dev, failed to lookup the default state\n);
} else {
if (pinctrl_select_state(pctldev-p,
pctldev-hog_default))
dev_err(dev,
failed to select default state\n);
}
pctldev-hog_sleep =
pinctrl_lookup_state(pctldev-p,
PINCTRL_STATE_SLEEP);
if (IS_ERR(pctldev-hog_sleep))
dev_dbg(dev, failed to lookup the sleep state\n);
}
Just add another state, pctldev-hog_shutdown to this, and
add an operation pinctrl_force_poweroff() in the same spirit as
pinctrl_force_sleep() that we already have.
Add a new state to include/linux/pinctrl/pinctrl-state.h:
#define PINCTRL_STATE_POWEROFF poweroff
And define you pin table to hog these pins with the mentioned
default and poweroff states.
Result: pinctrl core keeps track of your offstate too.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
Hi Linus,
On Friday 17 of May 2013 10:38:53 Linus Walleij wrote:
On Thu, May 16, 2013 at 2:03 AM, Doug Anderson diand...@google.com
wrote:
I prefer to put all the static pinctrl configuration in the pinctrl
hog, and only the dynamic stuff in the individual device nodes.
I know LinusW won't like this suggestion much though:-)
(It's not that bad actually...)
Ah right! I forgot about hogs in this case. That's also reasonable
as a solution and is similar to what we've got in the tree for
powerdown configuration of pins (I'll try to post this patch soon too,
WIP at https://gerrit.chromium.org/gerrit/#/c/51292/ and
https://gerrit.chromium.org/gerrit/#/c/51372/.
I don't like these Gerrit patches really, it's better to move
this to the pinctrl core using hogs.
If you look in drivers/pinctr/core.c you can find this:
pinctrl_register()
{
(...)
if (!IS_ERR(pctldev-p)) {
pctldev-hog_default =
pinctrl_lookup_state(pctldev-p,
PINCTRL_STATE_DEFAULT); if (IS_ERR(pctldev-hog_default)) {
dev_dbg(dev, failed to lookup the default
state\n); } else {
if (pinctrl_select_state(pctldev-p,
pctldev-hog_default))
dev_err(dev,
failed to select default
state\n); }
pctldev-hog_sleep =
pinctrl_lookup_state(pctldev-p,
PINCTRL_STATE_SLEEP); if (IS_ERR(pctldev-hog_sleep))
dev_dbg(dev, failed to lookup the sleep
state\n); }
Just add another state, pctldev-hog_shutdown to this, and
add an operation pinctrl_force_poweroff() in the same spirit as
pinctrl_force_sleep() that we already have.
Add a new state to include/linux/pinctrl/pinctrl-state.h:
#define PINCTRL_STATE_POWEROFF poweroff
And define you pin table to hog these pins with the mentioned
default and poweroff states.
Result: pinctrl core keeps track of your offstate too.
Power down mode settings on our pin controller are completely unrelated to
normal mode settings. You can set them once in appropriate registers and
pins are switched to them automatically when the SoC enters sleep mode.
So IMHO in our case power mode settings are just additional pin
configuration options, next to pull-up/-down and driver strength.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
On Fri, May 17, 2013 at 11:09 AM, Tomasz Figa tomasz.f...@gmail.com wrote: Just add another state, pctldev-hog_shutdown to this, and add an operation pinctrl_force_poweroff() in the same spirit as pinctrl_force_sleep() that we already have. Add a new state to include/linux/pinctrl/pinctrl-state.h: #define PINCTRL_STATE_POWEROFF poweroff And define you pin table to hog these pins with the mentioned default and poweroff states. Result: pinctrl core keeps track of your offstate too. Power down mode settings on our pin controller are completely unrelated to normal mode settings. You can set them once in appropriate registers and pins are switched to them automatically when the SoC enters sleep mode. Aha so it's actually automatic sleep modes, not power down (as in, disconnect the power and then push the on button to get it back up). Please remember to document it per above in the code and the device tree, so everybody understands what it is. So IMHO in our case power mode settings are just additional pin configuration options, next to pull-up/-down and driver strength. I see. Yes that is different. You might want to have a debugfs file in your driver for inspecting them though, that sounds like it could be helpful. I'd recommend augmenting your .pin_config_dbg_show() callback in the struct pinconf_ops to display this for each pin, in addition to the current configuration. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
Hi Linus, On Friday 17 of May 2013 13:59:54 Linus Walleij wrote: On Fri, May 17, 2013 at 11:09 AM, Tomasz Figa tomasz.f...@gmail.com wrote: Just add another state, pctldev-hog_shutdown to this, and add an operation pinctrl_force_poweroff() in the same spirit as pinctrl_force_sleep() that we already have. Add a new state to include/linux/pinctrl/pinctrl-state.h: #define PINCTRL_STATE_POWEROFF poweroff And define you pin table to hog these pins with the mentioned default and poweroff states. Result: pinctrl core keeps track of your offstate too. Power down mode settings on our pin controller are completely unrelated to normal mode settings. You can set them once in appropriate registers and pins are switched to them automatically when the SoC enters sleep mode. Aha so it's actually automatic sleep modes, not power down (as in, disconnect the power and then push the on button to get it back up). Please remember to document it per above in the code and the device tree, so everybody understands what it is. Sure. So IMHO in our case power mode settings are just additional pin configuration options, next to pull-up/-down and driver strength. I see. Yes that is different. You might want to have a debugfs file in your driver for inspecting them though, that sounds like it could be helpful. I'd recommend augmenting your .pin_config_dbg_show() callback in the struct pinconf_ops to display this for each pin, in addition to the current configuration. Seems reasonable. Best regards, -- Tomasz Figa Linux Kernel Developer Samsung RD Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
On 18:22 Wed 15 May , Stephen Warren wrote:
On 05/15/2013 06:13 PM, Tomasz Figa wrote:
On Wednesday 15 of May 2013 16:55:37 Doug Anderson wrote:
Tomasz / Linus,
On Wed, May 15, 2013 at 3:06 PM, Tomasz Figa tomasz.f...@gmail.com
wrote:
Yes. I don't like the current way too much either, duplication being
one of the reasons.
Do you have any other ideas? It sounds like Linus didn't like my
suggestion and makes some good points...
I don't have anything interesting at the moment. It's a bit late now here
(2 AM), so I'm going to get some sleep first.
Also after reading Stephen's reply, I'm wondering if hogging wouldn't
solve the problem indeed. (It might have to be fixed on pinctrl-samsung
first, as last time I tried to use it, it caused some errors from pinctrl
core, but haven't time to track them down, as it wasn't anything important
at that time).
One issue I noticed with the DT fragments earlier in this thread. It
looks like hogs in the Samsung pinctrl bingings end up looking like:
pinctrl {
pina {
samsung,pins = PIN_A PIN_B PIN_C;
samsung,pin-function = 0xf;
samsung,pin-pud = 0;
...
I have a huge issue here that we had on at91 too
we are going to have a huge numbet of node
and on at91 we handle the pin the same way as samsung
and ST have also a similiar IP
so I'll prefer to reuse the AT91 DT bindings
as said by Linus I just push a cleanup of the magic by using Macro
which make it really readable now
some extract of the sama5 pinctrl
mmc0 {
pinctrl_mmc0_clk_cmd_dat0: mmc0_clk_cmd_dat0 {
atmel,pins =
AT91_PIOD 9 AT91_PERIPH_A AT91_PINCTRL_NONE
/* PD9 periph A MCI0_CK */
AT91_PIOD 0 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
/* PD0 periph A MCI0_CDA with pullup */
AT91_PIOD 1 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP; /* PD1 periph A MCI0_DA0 with pullup */
};
pinctrl_mmc0_dat1_3: mmc0_dat1_3 {
atmel,pins =
AT91_PIOD 2 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
/* PD2 periph A MCI0_DA1 with pullup */
AT91_PIOD 3 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
/* PD3 periph A MCI0_DA2 with pullup */
AT91_PIOD 4 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP; /* PD4 periph A MCI0_DA3 with pullup */
};
pinctrl_mmc0_dat4_7: mmc0_dat4_7 {
atmel,pins =
AT91_PIOD 5 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
/* PD5 periph A MCI0_DA4 with pullup, conflicts with TIOA0, PWMH2 */
AT91_PIOD 6 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
/* PD6 periph A MCI0_DA5 with pullup, conflicts with TIOB0, PWML2 */
AT91_PIOD 7 AT91_PERIPH_A AT91_PINCTRL_PULL_UP
/* PD7 periph A MCI0_DA6 with pullup, conlicts with TCLK0, PWMH3 */
AT91_PIOD 8 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP; /* PD8 periph A MCI0_DA7 with pullup, conflicts
with PWML3 */
};
};
of sam9g45
i2c_gpio2 {
pinctrl_i2c_gpio2: i2c_gpio2-0 {
atmel,pins =
AT91_PIOB 4 AT91_PERIPH_GPIO
AT91_PINCTRL_MULTI_DRIVE /* PB4 gpio multidrive I2C2 data */
AT91_PIOB 5 AT91_PERIPH_GPIO
AT91_PINCTRL_MULTI_DRIVE;/* PB5 gpio multidrive I2C2 clock */
};
};
so we could share the c code too
Best Regards,
J,
};
pinp {
samsung,pins = PIN_P PIN_Q;
samsung,pin-function = 0xe;
samsung,pin-pud = 1;
...
};
pinx {
samsung,pins = PIN_X PIN_Y PIN_Z;
samsung,pin-function = 0xd;
samsung,pin-pud = 2;
...
};
pinctrl-names = default;
pinctrl-0 = pina pinp pinx;
};
That pinctrl-0 property could get rather large (hard to write/maintain,
unwieldy) if it needs to set up lots of different configurations. That's
why I made the equivalent Tegra bindings be:
pinctrl {
pins_default {
pina {
samsung,pins = PIN_A PIN_B PIN_C;
samsung,pin-function = 0xf;
samsung,pin-pud = 0;
...
};
pinp {
samsung,pins = PIN_P PIN_Q;
samsung,pin-function = 0xe;
samsung,pin-pud = 1;
...
};
pinx {
samsung,pins = PIN_X PIN_Y PIN_Z;
samsung,pin-function = 0xd;
samsung,pin-pud = 2;
...
};
};
pinctrl-names = default;
pinctrl-0 = pins_default;
};
The extra level within the pinctrl configuration node (pins_default
here) makes the pinctrl-0 property a lot easier to write, and the
Re: Pulls and drive strengths in the pinctrl world
Tomasz, On Fri, May 17, 2013 at 5:38 AM, Tomasz Figa t.f...@samsung.com wrote: You might want to have a debugfs file in your driver for inspecting them though, that sounds like it could be helpful. I'd recommend augmenting your .pin_config_dbg_show() callback in the struct pinconf_ops to display this for each pin, in addition to the current configuration. Seems reasonable. If you do this I'd love to be CCed. I have a super-ugly userspace tool that shows this info and have been contemplating moving it into debugfs and cleaning it up there. See https://gerrit.chromium.org/gerrit/#/c/51380/ A small snippet of the output looks like: GPIO x3[4]@0x11400c60: con=0x0 dat=0 pulldwn(1) drv=1(0) GPIO x3[5]@0x11400c60: con=0xf dat=1 nopull(0) drv=1(0) GPIO x3[6]@0x11400c60: con=0x0 dat=1 pulldwn(1) drv=1(0) GPIO x3[7]@0x11400c60: con=0x0 dat=0 pulldwn(1) drv=1(0) GPIO e0[0]@0x1340: con=0x0 dat=0 pulldwn(1) drv=1(0) pdn= low(0), pdn= nopull(0) GPIO e0[1]@0x1340: con=0x0 dat=0 pulldwn(1) drv=1(0) pdn= in(2), pdn=pulldwn(1) GPIO e0[2]@0x1340: con=0x0 dat=0 pulldwn(1) drv=1(0) pdn= in(2), pdn=pulldwn(1) -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
Hi Jean-Christophe,
On Friday 17 of May 2013 14:26:25 Jean-Christophe PLAGNIOL-VILLARD wrote:
On 18:22 Wed 15 May , Stephen Warren wrote:
On 05/15/2013 06:13 PM, Tomasz Figa wrote:
On Wednesday 15 of May 2013 16:55:37 Doug Anderson wrote:
Tomasz / Linus,
On Wed, May 15, 2013 at 3:06 PM, Tomasz Figa
tomasz.f...@gmail.com
wrote:
Yes. I don't like the current way too much either, duplication
being
one of the reasons.
Do you have any other ideas? It sounds like Linus didn't like my
suggestion and makes some good points...
I don't have anything interesting at the moment. It's a bit late now
here (2 AM), so I'm going to get some sleep first.
Also after reading Stephen's reply, I'm wondering if hogging
wouldn't
solve the problem indeed. (It might have to be fixed on
pinctrl-samsung
first, as last time I tried to use it, it caused some errors from
pinctrl core, but haven't time to track them down, as it wasn't
anything important at that time).
One issue I noticed with the DT fragments earlier in this thread. It
looks like hogs in the Samsung pinctrl bingings end up looking like:
pinctrl {
pina {
samsung,pins = PIN_A PIN_B PIN_C;
samsung,pin-function = 0xf;
samsung,pin-pud = 0;
...
I have a huge issue here that we had on at91 too
we are going to have a huge numbet of node
and on at91 we handle the pin the same way as samsung
and ST have also a similiar IP
so I'll prefer to reuse the AT91 DT bindings
as said by Linus I just push a cleanup of the magic by using Macro
which make it really readable now
some extract of the sama5 pinctrl
mmc0 {
pinctrl_mmc0_clk_cmd_dat0: mmc0_clk_cmd_dat0 {
atmel,pins =
AT91_PIOD 9 AT91_PERIPH_A
AT91_PINCTRL_NONE /* PD9 periph A MCI0_CK
*/ AT91_PIOD 0 AT91_PERIPH_A AT91_PINCTRL_PULL_UP /* PD0 periph A
MCI0_CDA with pullup */ AT91_PIOD 1 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP;/* PD1 periph A MCI0_DA0 with pullup */ };
pinctrl_mmc0_dat1_3: mmc0_dat1_3 {
atmel,pins =
AT91_PIOD 2 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP/* PD2 periph A
MCI0_DA1 with pullup */ AT91_PIOD 3 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP /* PD3 periph A MCI0_DA2 with pullup */ AT91_PIOD
4 AT91_PERIPH_A AT91_PINCTRL_PULL_UP;/* PD4 periph A MCI0_DA3
with
pullup */ };
pinctrl_mmc0_dat4_7: mmc0_dat4_7 {
atmel,pins =
AT91_PIOD 5 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP/* PD5 periph A
MCI0_DA4 with pullup, conflicts with TIOA0, PWMH2 */ AT91_PIOD 6
AT91_PERIPH_A AT91_PINCTRL_PULL_UP/* PD6 periph A MCI0_DA5 with
pullup, conflicts with TIOB0, PWML2 */ AT91_PIOD 7 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP /* PD7 periph A MCI0_DA6 with pullup, conlicts
with TCLK0, PWMH3 */ AT91_PIOD 8 AT91_PERIPH_A
AT91_PINCTRL_PULL_UP;/* PD8 periph A MCI0_DA7 with pullup,
conflicts
with PWML3 */ };
};
of sam9g45
i2c_gpio2 {
pinctrl_i2c_gpio2: i2c_gpio2-0 {
atmel,pins =
AT91_PIOB 4 AT91_PERIPH_GPIO
AT91_PINCTRL_MULTI_DRIVE/* PB4 gpio
multidrive I2C2 data */ AT91_PIOB 5 AT91_PERIPH_GPIO
AT91_PINCTRL_MULTI_DRIVE;/* PB5 gpio multidrive I2C2 clock */ };
};
so we could share the c code too
I'd have a question with regard to AT91 bindings.
Using Samsung bindings we don't need to specify all configuration options
for a pin, only those that are relevant for the platform. Do your bindings
allow this?
Apparently AT91 has less configurable things and those available are
usually always configured together so it's not a problem. But on our SoCs
we have a bit more of them:
- function (input, output, special functions)
- pull-down/-up
- driver strength
- power down mode function (input, output low, output high, retention)
- power down mode pull-down/-up
- one could argue that default output value could be set this way as well,
by adding samsung,pin-value property.
Best regards,
Tomasz
Best Regards,
J,
};
pinp {
samsung,pins = PIN_P PIN_Q;
samsung,pin-function = 0xe;
samsung,pin-pud = 1;
...
};
pinx {
samsung,pins = PIN_X PIN_Y PIN_Z;
samsung,pin-function = 0xd;
samsung,pin-pud = 2;
...
};
pinctrl-names = default;
pinctrl-0 = pina pinp pinx;
};
That pinctrl-0 property could get rather large (hard to
write/maintain,
unwieldy) if it needs to set up lots of different configurations.
That's why I made the equivalent Tegra bindings be:
pinctrl {
pins_default {
pina {
samsung,pins = PIN_A PIN_B
Re: Pulls and drive strengths in the pinctrl world
Tomasz / Stephen,
On Wed, May 15, 2013 at 5:55 PM, Doug Anderson diand...@google.com wrote:
Also after reading Stephen's reply, I'm wondering if hogging wouldn't
solve the problem indeed. (It might have to be fixed on pinctrl-samsung
first, as last time I tried to use it, it caused some errors from pinctrl
core, but haven't time to track them down, as it wasn't anything important
at that time).
I will give it a shot tomorrow morning and see how it looks. I'll
also evaluate Stephen's suggestions then once I've see how it looks
with the current bindings...
I wrote this out and it had some nice properties (it was a little more
concise), but had the downside that there's no reference from the GPIO
usage back to the pinmux. I'd rather have the reference there in the
hopes that it will help others get things right when they make changes
to the dts file (they'll notice the reference and know that they need
to change that too).
...so I think the summary is: I'm OK with keeping what we have. It
may be a little awkward in some ways but it's definitely worth it to
get all of the benefits of the pinmux / GPIO separation. :)
For the curious of what my prototype looked like (feel free to
ignore--I'm not planning on keeping this and I didn't actually try
testing it), I've included it below. This is just the bit from
cros5250-common (the common file shared among several similar
boards), so I'd need something similar in exynos5250-snow).
pinctrl@1140 {
/* Default states for hogs follow */
nopull_inputs_cros5250_a: nopull-inputs-cros5250-a {
samsung,pins =
gpx1-2, /* trackpad */
gpx1-3, /* gpio-keys - power */
gpx3-2; /* max77686 */
samsung,pin-function = 0;
samsung,pin-pud = 0;
samsung,pin-drv = 0;
};
pulldown_inputs_cros5250-a: pulldown-inputs-cros5250_a {
samsung,pins = gpx3-7; /* hdmi */
samsung,pin-function = 0;
samsung,pin-pud = 1;
samsung,pin-drv = 0;
};
simple_outputs_cros5250-a: simple-outputs-cros5250_a {
samsung,pins =
gpx0-1, /* wifi-en */
gpx0-2, /* wifi-rst */
gpx1-7; /* max98095-en */
samsung,pin-function = 1;
samsung,pin-pud = 0;
samsung,pin-drv = 0;
}
pinctrl-names = default;
pinctrl-0 = nopull_inputs_cros5250_a
pulldown_inputs_cros5250_a
simple_outputs_cros5250_a;
};
pinctrl@1340 {
simple_outputs_cros5250-b: simple-outputs-cros5250_b {
samsung,pins = gpe1-0 /* hsic reset */;
samsung,pin-function = 1;
samsung,pin-pud = 0;
samsung,pin-drv = 0;
};
pinctrl-names = default;
pinctrl-0 = simple_outputs_cros5250_b;
};
-Doug
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Pulls and drive strengths in the pinctrl world
Linus,
I'm currently working towards adapting exynos5250-snow (the ARM
Chromebook) to work well in the new world of pinctrl. We've got a
backport of exynos5250 pinctrl in our kernel-3.8 tree and are now
fixing all of the bugs that have popped up. Patches will be sent
upstream (where applicable) shortly.
...but I'm running into an issue when trying to specify pullups /
pulldowns and drive strengths on lines that are just GPIOs or just
interrupts. This is important not just for power usage but also for
proper functioning (the default internal pulldown was overpowering the
weak external pullup in one case). In the old GPIO specifier you
could do specify pulls, but the new simpler one doesn't allow it.
I've managed to make things work and you can see my progress at
https://gerrit.chromium.org/gerrit/#/c/51232/, but it feels a bit
awkward. Is there a better way? If so, then I'm all ears! :)
If not, then I guess that what I have will have to do for now. ...but
I really wish that:
* The GPIO specifier could specify initial drive strength and pull
values for pins.
* The interrupt specifier could specify pull values for pins (drive
strength shouldn't be needed since these are inputs).
Some examples from the gerrit CL referenced above...
Here's how I need to do things when I'm using just an interrupt:
pinctrl@1140 {
cyapa_irq: cyapa-irq {
samsung,pins = gpx1-2;
samsung,pin-function = 0xf;
samsung,pin-pud = 0;
samsung,pin-drv = 0;
};
};
trackpad {
reg = 0x67;
compatible = cypress,cyapa;
interrupts = 2 0;
interrupt-parent = gpx1;
pinctrl-names = default;
pinctrl-0 = cyapa_irq;
wakeup-source;
};
I really wish I could add a 3rd number to the interrupt specifier for
pud and skip the pinctrl bit:
trackpad {
reg = 0x67;
compatible = cypress,cyapa;
interrupts = 2 0 0;
interrupt-parent = gpx1;
wakeup-source;
};
An example with the GPIO specifier instead of the interrupt one:
pinctrl@1140 {
ptn3460_gpios: ptn3460-gpios {
samsung,pins = gpy2-5, gpx1-5;
samsung,pin-function = 1;
samsung,pin-pud = 0;
samsung,pin-drv = 0;
};
};
ptn3460-bridge@20 {
compatible = nxp,ptn3460;
reg = 0x20;
powerdown-gpio = gpy2 5 0;
reset-gpio = gpx1 5 0;
edid-emulation = 5;
pinctrl-names = default;
pinctrl-0 = ptn3460_gpios;
};
I don't want to specify function/direction (code can handle that), but do wish
I could specify the pulls and strength. Perhaps:
ptn3460-bridge@20 {
compatible = nxp,ptn3460;
reg = 0x20;
powerdown-gpio = gpy2 5 0 0 0;
reset-gpio = gpx1 5 0 0 0;
edid-emulation = 5;
};
-Doug
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
Hi Doug,
There is no better way at the moment, but...
On Wednesday 15 of May 2013 09:44:22 Doug Anderson wrote:
Linus,
I'm currently working towards adapting exynos5250-snow (the ARM
Chromebook) to work well in the new world of pinctrl. We've got a
backport of exynos5250 pinctrl in our kernel-3.8 tree and are now
fixing all of the bugs that have popped up. Patches will be sent
upstream (where applicable) shortly.
...but I'm running into an issue when trying to specify pullups /
pulldowns and drive strengths on lines that are just GPIOs or just
interrupts. This is important not just for power usage but also for
proper functioning (the default internal pulldown was overpowering the
weak external pullup in one case). In the old GPIO specifier you
could do specify pulls, but the new simpler one doesn't allow it.
I've managed to make things work and you can see my progress at
https://gerrit.chromium.org/gerrit/#/c/51232/, but it feels a bit
awkward. Is there a better way? If so, then I'm all ears! :)
If not, then I guess that what I have will have to do for now. ...but
I really wish that:
* The GPIO specifier could specify initial drive strength and pull
values for pins.
* The interrupt specifier could specify pull values for pins (drive
strength shouldn't be needed since these are inputs).
Some examples from the gerrit CL referenced above...
Here's how I need to do things when I'm using just an interrupt:
pinctrl@1140 {
cyapa_irq: cyapa-irq {
samsung,pins = gpx1-2;
samsung,pin-function = 0xf;
You can omit samsung,pin-function here.
samsung,pin-pud = 0;
samsung,pin-drv = 0;
For inputs I guess you can omit samsung,pin-drv as well.
};
};
trackpad {
reg = 0x67;
compatible = cypress,cyapa;
interrupts = 2 0;
interrupt-parent = gpx1;
pinctrl-names = default;
pinctrl-0 = cyapa_irq;
wakeup-source;
};
I really wish I could add a 3rd number to the interrupt specifier for
pud and skip the pinctrl bit:
trackpad {
reg = 0x67;
compatible = cypress,cyapa;
interrupts = 2 0 0;
Hmm, looks pretty good to me.
interrupt-parent = gpx1;
wakeup-source;
};
An example with the GPIO specifier instead of the interrupt one:
pinctrl@1140 {
ptn3460_gpios: ptn3460-gpios {
samsung,pins = gpy2-5, gpx1-5;
samsung,pin-function = 1;
samsung,pin-pud = 0;
samsung,pin-drv = 0;
};
};
ptn3460-bridge@20 {
compatible = nxp,ptn3460;
reg = 0x20;
powerdown-gpio = gpy2 5 0;
reset-gpio = gpx1 5 0;
edid-emulation = 5;
pinctrl-names = default;
pinctrl-0 = ptn3460_gpios;
};
I don't want to specify function/direction (code can handle that), but
do wish I could specify the pulls and strength. Perhaps:
ptn3460-bridge@20 {
compatible = nxp,ptn3460;
reg = 0x20;
powerdown-gpio = gpy2 5 0 0 0;
reset-gpio = gpx1 5 0 0 0;
This looks fine to me as well.
Implementation of both shouldn't be too complicated, so it might be worth
giving a try. Keep in mind that old bindings must be supported as well
(based on #interrupt-cells and #gpio-cells values, I guess).
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
On Wed, May 15, 2013 at 10:26 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
I don't want to specify function/direction (code can handle that), but
do wish I could specify the pulls and strength. Perhaps:
ptn3460-bridge@20 {
compatible = nxp,ptn3460;
reg = 0x20;
powerdown-gpio = gpy2 5 0 0 0;
reset-gpio = gpx1 5 0 0 0;
This looks fine to me as well.
Implementation of both shouldn't be too complicated, so it might be worth
giving a try. Keep in mind that old bindings must be supported as well
(based on #interrupt-cells and #gpio-cells values, I guess).
Given the late discovery of this pretty major drawback, I don't think
we should worry too much about backwards compatibility in this case
and instead just move everyone over asap to whatever the new binding
is (when we agree on something).
Also, it looks like the gpio bindings were never updated with the
pinctrl changes. Tsk, tsk, tsk. Bad.
We have the option of either adding new fields for pulls and strength,
but we can also split the existing flags field similar to how we did
with the old binding, and take 8 bits each for pulls and strength, or
somesuch. That'll be less of a change w.r.t. existing device trees and
bindings.
-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
On Wed, May 15, 2013 at 6:44 PM, Doug Anderson diand...@google.com wrote:
Pls include Stephen Warren on mailings regarding DT mappings,
he's very good at this stuff.
I'm running into an issue when trying to specify pullups /
pulldowns and drive strengths on lines that are just GPIOs or just
interrupts. This is important not just for power usage but also for
proper functioning (the default internal pulldown was overpowering the
weak external pullup in one case). In the old GPIO specifier you
could do specify pulls, but the new simpler one doesn't allow it.
Background:
The idea with the subsystems is that the GPIO subsystem will
handle any aspect of GPIOs which are not necessarily
synonymous to pins.
So the two subsystems are orthogonal and the decisions in
each subsystem may result on combined electrical effects.
If there are cross-dependencies, GPIO ranges are used to
cross-map the GPIOs to pins.
I've managed to make things work and you can see my progress at
https://gerrit.chromium.org/gerrit/#/c/51232/, but it feels a bit
awkward. Is there a better way? If so, then I'm all ears! :
This seems good. default states are used to set up pins.
But please use the preprocessor to provide symbolic names for
the configurations. See for example these two patches from
J-C:
http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg32164.html
I really wish that:
* The GPIO specifier could specify initial drive strength and pull
values for pins.
* The interrupt specifier could specify pull values for pins (drive
strength shouldn't be needed since these are inputs).
The subsystem does not differentiate between different configs,
what you say is that you want GPIO and interrupt specifiers
to pass arbitrary configs.
Here's how I need to do things when I'm using just an interrupt:
pinctrl@1140 {
cyapa_irq: cyapa-irq {
samsung,pins = gpx1-2;
samsung,pin-function = 0xf;
samsung,pin-pud = 0;
samsung,pin-drv = 0;
};
};
trackpad {
reg = 0x67;
compatible = cypress,cyapa;
interrupts = 2 0;
interrupt-parent = gpx1;
pinctrl-names = default;
pinctrl-0 = cyapa_irq;
wakeup-source;
};
I really wish I could add a 3rd number to the interrupt specifier for
pud and skip the pinctrl bit:
trackpad {
reg = 0x67;
compatible = cypress,cyapa;
interrupts = 2 0 0;
interrupt-parent = gpx1;
wakeup-source;
};
I don't think the idea with device tree is to write as compact trees
as possible, but as expressive and exact yet abstract trees as
possible for OS independence.
Instead of referring to a node containing the config relevant for
another piece of hardware and associating this with the ampersand
notation (as is done with regulators, clocks, dma channels ...)
you here want to break that pattern totally and just hardcode
a numeric argument into the specifier. (Well could be a #define
using includes, but...)
That is not the pattern used so far I've seen to indicate dependent
resources. Dependent resources are passed using the ampersand.
While a number may suffice to describe all config for your hardware,
other pinctrl hardware needs more than one single numeric
argument. And device trees should be similar to each other.
If you're not doing that using the ampersand, the same could
potentially be done for a regulator powering a GPIO pin
and you get a fourth argument, and a fifth argument supplying
the color of the LED at the other end and ... I guess this is
why ampersands are being used.
Other than that I think you should ask a DT expert and I'm
no such.
An example with the GPIO specifier instead of the interrupt one:
pinctrl@1140 {
ptn3460_gpios: ptn3460-gpios {
samsung,pins = gpy2-5, gpx1-5;
samsung,pin-function = 1;
samsung,pin-pud = 0;
samsung,pin-drv = 0;
};
};
ptn3460-bridge@20 {
compatible = nxp,ptn3460;
reg = 0x20;
powerdown-gpio = gpy2 5 0;
reset-gpio = gpx1 5 0;
edid-emulation = 5;
pinctrl-names = default;
pinctrl-0 = ptn3460_gpios;
};
I don't want to specify function/direction (code can handle that), but do wish
I could specify the pulls and strength. Perhaps:
ptn3460-bridge@20 {
compatible = nxp,ptn3460;
reg = 0x20;
powerdown-gpio = gpy2 5 0 0 0;
reset-gpio = gpx1 5 0 0 0;
edid-emulation = 5;
};
Dito.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
Tomasz,
Thanks for your comments. I'm glad I'm not totally off-track. I'll
respond to most things in reply to Linus' email, but a few here:
On Wed, May 15, 2013 at 10:26 AM, Tomasz Figa tomasz.f...@gmail.com wrote:
pinctrl@1140 {
cyapa_irq: cyapa-irq {
samsung,pins = gpx1-2;
samsung,pin-function = 0xf;
You can omit samsung,pin-function here.
One potential reason for leaving them is the hopes that it might cause
a little less line glitching, especially in the case of outputs.
There is some delay between the pinmux being configured at the start
of device probe and the device actually claiming the GPIO. Things
might be worse in the case of deferred probe (?). Can you think of
any reason to remove (other than yet more lines of device tree to deal
with)?
samsung,pin-pud = 0;
samsung,pin-drv = 0;
For inputs I guess you can omit samsung,pin-drv as well.
I will probably leave them even for inputs. They shouldn't matter but
I like the idea of initting things to a known state...
-Doug
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
Linus,
Thank you for your comments. See below...
Stephen: sorry for missing you earlier! :(
On Wed, May 15, 2013 at 11:29 AM, Linus Walleij
linus.wall...@linaro.org wrote:
But please use the preprocessor to provide symbolic names for
the configurations. See for example these two patches from
J-C:
http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg32164.html
Ah, that does look nice! This probably needs to be addressed in a
separate patch to cleanup all of the samsung pinctrl devicetrees.
I don't think the idea with device tree is to write as compact trees
as possible, but as expressive and exact yet abstract trees as
possible for OS independence.
The compactness was one benefit, but also it was about trying to avoid
excessive duplication of information. I found it awkward that I
needed to list that my interrupt was gpx1-2 in two different ways.
I would find it just as good if I could express things like this (for
interrupts):
pinctrl@1140 {
cyapa_irq: cyapa-irq {
samsung,pins = gpx1-2;
samsung,pin-function = 0xf;
samsung,pin-pud = 0;
samsung,pin-drv = 0;
interrupt-controller;
#interrupt-cells = 1;
};
};
trackpad {
reg = 0x67;
compatible = cypress,cyapa;
interrupt-parent = cyapa_irq;
interrupts = 0;
wakeup-source;
};
In this case I'm not saying that my interrupt parent is gpx1-2 in
two separate places that could diverge.
I could come up with a similar example for GPIOs.
-Doug
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
On Wednesday 15 of May 2013 14:19:18 Doug Anderson wrote:
Tomasz,
Thanks for your comments. I'm glad I'm not totally off-track. I'll
respond to most things in reply to Linus' email, but a few here:
On Wed, May 15, 2013 at 10:26 AM, Tomasz Figa tomasz.f...@gmail.com
wrote:
pinctrl@1140 {
cyapa_irq: cyapa-irq {
samsung,pins = gpx1-2;
samsung,pin-function = 0xf;
You can omit samsung,pin-function here.
One potential reason for leaving them is the hopes that it might cause
a little less line glitching, especially in the case of outputs.
There is some delay between the pinmux being configured at the start
of device probe and the device actually claiming the GPIO. Things
might be worse in the case of deferred probe (?). Can you think of
any reason to remove (other than yet more lines of device tree to deal
with)?
Well, actually in case of interrupts the function should not be configured
manually, because it is likely to cause a false interrupt to be caught,
before appropriate interrupt trigger type is configured. The correct way
is to leave setting pin function to EINT to the pin control driver once
the trigger gets configured (the pin control driver configures pin
function from set_irq_type callback).
samsung,pin-pud = 0;
samsung,pin-drv = 0;
For inputs I guess you can omit samsung,pin-drv as well.
I will probably leave them even for inputs. They shouldn't matter but
I like the idea of initting things to a known state...
Well, the binding you proposed for interrupts doesn't initialize it. This
is why I pointed that it can be omitted using current way as well.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
On Wednesday 15 of May 2013 14:31:20 Doug Anderson wrote:
Linus,
Thank you for your comments. See below...
Stephen: sorry for missing you earlier! :(
On Wed, May 15, 2013 at 11:29 AM, Linus Walleij
linus.wall...@linaro.org wrote:
But please use the preprocessor to provide symbolic names for
the configurations. See for example these two patches from
J-C:
http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg321
64.html
Ah, that does look nice! This probably needs to be addressed in a
separate patch to cleanup all of the samsung pinctrl devicetrees.
I don't think the idea with device tree is to write as compact trees
as possible, but as expressive and exact yet abstract trees as
possible for OS independence.
The compactness was one benefit, but also it was about trying to avoid
excessive duplication of information. I found it awkward that I
needed to list that my interrupt was gpx1-2 in two different ways.
I would find it just as good if I could express things like this (for
interrupts):
pinctrl@1140 {
cyapa_irq: cyapa-irq {
samsung,pins = gpx1-2;
samsung,pin-function = 0xf;
samsung,pin-pud = 0;
samsung,pin-drv = 0;
interrupt-controller;
#interrupt-cells = 1;
};
};
trackpad {
reg = 0x67;
compatible = cypress,cyapa;
interrupt-parent = cyapa_irq;
interrupts = 0;
wakeup-source;
};
In this case I'm not saying that my interrupt parent is gpx1-2 in
two separate places that could diverge.
This will be hard, since the phandle in interrupt-parent is represented by
an IRQ domain in kernel code. One-interrupt IRQ domains seem a bit awkward
to me.
Since we are already going to modify the binding, let's think a bit more
about this problem and try to figure out a solution that doesn't add any
disadvantages (at least any significant) to avoid such situation in future
again.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
On Wednesday 15 of May 2013 23:41:54 Tomasz Figa wrote:
On Wednesday 15 of May 2013 14:31:20 Doug Anderson wrote:
Linus,
Thank you for your comments. See below...
Stephen: sorry for missing you earlier! :(
On Wed, May 15, 2013 at 11:29 AM, Linus Walleij
linus.wall...@linaro.org wrote:
But please use the preprocessor to provide symbolic names for
the configurations. See for example these two patches from
J-C:
http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg3
21
64.html
Ah, that does look nice! This probably needs to be addressed in a
separate patch to cleanup all of the samsung pinctrl devicetrees.
I don't think the idea with device tree is to write as compact trees
as possible, but as expressive and exact yet abstract trees as
possible for OS independence.
The compactness was one benefit, but also it was about trying to avoid
excessive duplication of information. I found it awkward that I
needed to list that my interrupt was gpx1-2 in two different ways.
I would find it just as good if I could express things like this (for
interrupts):
pinctrl@1140 {
cyapa_irq: cyapa-irq {
samsung,pins = gpx1-2;
samsung,pin-function = 0xf;
samsung,pin-pud = 0;
samsung,pin-drv = 0;
interrupt-controller;
#interrupt-cells = 1;
};
};
trackpad {
reg = 0x67;
compatible = cypress,cyapa;
interrupt-parent = cyapa_irq;
interrupts = 0;
wakeup-source;
};
In this case I'm not saying that my interrupt parent is gpx1-2 in
two separate places that could diverge.
This will be hard, since the phandle in interrupt-parent is represented
by an IRQ domain in kernel code. One-interrupt IRQ domains seem a bit
awkward to me.
Ahh, not even saying that a single interrupt signal is not really an
interrupt controller, which would make device tree diverge from real
hardware description.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
Tomasz, On Wed, May 15, 2013 at 2:36 PM, Tomasz Figa tomasz.f...@gmail.com wrote: One potential reason for leaving them is the hopes that it might cause a little less line glitching, especially in the case of outputs. There is some delay between the pinmux being configured at the start of device probe and the device actually claiming the GPIO. Things might be worse in the case of deferred probe (?). Can you think of any reason to remove (other than yet more lines of device tree to deal with)? Well, actually in case of interrupts the function should not be configured manually, because it is likely to cause a false interrupt to be caught, before appropriate interrupt trigger type is configured. The correct way is to leave setting pin function to EINT to the pin control driver once the trigger gets configured (the pin control driver configures pin function from set_irq_type callback). Ah, OK. I'll set to input for these. I will probably leave them even for inputs. They shouldn't matter but I like the idea of initting things to a known state... Well, the binding you proposed for interrupts doesn't initialize it. This is why I pointed that it can be omitted using current way as well. Agreed. ...though you could say that the actual code in that case would just be setting the drive strength to 0 (for consistency). ;) -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
Tomasz, On Wed, May 15, 2013 at 2:41 PM, Tomasz Figa tomasz.f...@gmail.com wrote: This will be hard, since the phandle in interrupt-parent is represented by an IRQ domain in kernel code. One-interrupt IRQ domains seem a bit awkward to me. Since we are already going to modify the binding, let's think a bit more about this problem and try to figure out a solution that doesn't add any disadvantages (at least any significant) to avoid such situation in future again. I'm definitely not super familiar with the implementation at that level of detail, so don't take my proposed syntax as something I've thought all the way through. ...but hopefully you understand what I'm getting at in terms of eliminating duplication? Thanks! :) -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
On Wednesday 15 of May 2013 15:01:23 Doug Anderson wrote: Tomasz, On Wed, May 15, 2013 at 2:41 PM, Tomasz Figa tomasz.f...@gmail.com wrote: This will be hard, since the phandle in interrupt-parent is represented by an IRQ domain in kernel code. One-interrupt IRQ domains seem a bit awkward to me. Since we are already going to modify the binding, let's think a bit more about this problem and try to figure out a solution that doesn't add any disadvantages (at least any significant) to avoid such situation in future again. I'm definitely not super familiar with the implementation at that level of detail, so don't take my proposed syntax as something I've thought all the way through. ...but hopefully you understand what I'm getting at in terms of eliminating duplication? Yes. I don't like the current way too much either, duplication being one of the reasons. Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
On 05/15/2013 12:29 PM, Linus Walleij wrote:
On Wed, May 15, 2013 at 6:44 PM, Doug Anderson diand...@google.com wrote:
...
Here's how I need to do things when I'm using just an interrupt:
pinctrl@1140 {
cyapa_irq: cyapa-irq {
samsung,pins = gpx1-2;
samsung,pin-function = 0xf;
samsung,pin-pud = 0;
samsung,pin-drv = 0;
};
};
trackpad {
reg = 0x67;
compatible = cypress,cyapa;
interrupts = 2 0;
interrupt-parent = gpx1;
pinctrl-names = default;
pinctrl-0 = cyapa_irq;
wakeup-source;
};
I don't really see much disadvantage here; the interrupt bindings
specify things related to interrupts and the pinctrl bindings specify
thing related to pin configuration.
If you want to condense the DT, I'd suggest using a the pinctrl hogging
feature, i.e. don't put pinctrl-* properties in the trackpad node, but
rather define a system-wide default pinctrl state in the pin
controller node itself. That configuration will be applied as soon as
the pin controller driver is registered. That'd be the same as the
above, with the following added:
pinctrl@1140 {
pinctrl-names = default;
pinctrl-0 = cyapa_irq;
};
except that the pinctrl-0 property would probably end up configuring a
whole bunch of basic pinctrl state rather than just that one interrupt pin.
I prefer to put all the static pinctrl configuration in the pinctrl hog,
and only the dynamic stuff in the individual device nodes.
I know LinusW won't like this suggestion much though:-)
I really wish I could add a 3rd number to the interrupt specifier for
pud and skip the pinctrl bit:
trackpad {
reg = 0x67;
compatible = cypress,cyapa;
interrupts = 2 0 0;
interrupt-parent = gpx1;
wakeup-source;
};
I don't like that myself, since it makes the interrupt binding (and I
assume you'd want to go back to the similar misuse in the GPIO binding)
also configure pinctrl-related stuff.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
Tomasz / Linus, On Wed, May 15, 2013 at 3:06 PM, Tomasz Figa tomasz.f...@gmail.com wrote: Yes. I don't like the current way too much either, duplication being one of the reasons. Do you have any other ideas? It sounds like Linus didn't like my suggestion and makes some good points... I don't have any other great ideas other than having an argument about whether the concept of pulls should be added to the GPIO subsystem (and backed by pinmux). Then we could make an argument that default pull state belonged in the GPIO specifier. OK, maybe we should just pretend that I didn't bring that up. ;) ...but I'm definitely interested in other ideas to eliminate the duplication. Until then I'm planning on submitting what I have locally. I'll probably send some version of it upstream fairly soon. I will probably submit without trying to get all the preprocessor symbols names done and will understand if Linus NAKs because of that. I don't have time to take that on at the moment but can always come back and rework that patch later. ;) -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
Stephen,
On Wed, May 15, 2013 at 4:51 PM, Stephen Warren swar...@wwwdotorg.org wrote:
I don't really see much disadvantage here; the interrupt bindings
specify things related to interrupts and the pinctrl bindings specify
thing related to pin configuration.
OK. If this is the best way then I can accept that and maybe we
should just drop this thread. What do people think? It means less
work for me in the short term since I've already got it implemented
that way and then I don't need to submit any patches to try to change
things! ;)
If you want to condense the DT, I'd suggest using a the pinctrl hogging
feature, i.e. don't put pinctrl-* properties in the trackpad node, but
rather define a system-wide default pinctrl state in the pin
controller node itself. That configuration will be applied as soon as
the pin controller driver is registered. That'd be the same as the
above, with the following added:
pinctrl@1140 {
pinctrl-names = default;
pinctrl-0 = cyapa_irq;
};
except that the pinctrl-0 property would probably end up configuring a
whole bunch of basic pinctrl state rather than just that one interrupt pin.
I prefer to put all the static pinctrl configuration in the pinctrl hog,
and only the dynamic stuff in the individual device nodes.
I know LinusW won't like this suggestion much though:-)
Ah right! I forgot about hogs in this case. That's also reasonable
as a solution and is similar to what we've got in the tree for
powerdown configuration of pins (I'll try to post this patch soon too,
WIP at https://gerrit.chromium.org/gerrit/#/c/51292/ and
https://gerrit.chromium.org/gerrit/#/c/51372/.
It sounds like there's a bit of disagreement about the best way so
I'll probably keep the way I have. ...but I'll keep hogs in my back
pocket.
I don't like that myself, since it makes the interrupt binding (and I
assume you'd want to go back to the similar misuse in the GPIO binding)
also configure pinctrl-related stuff.
Fair enough. :)
-Doug
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
On Wednesday 15 of May 2013 16:55:37 Doug Anderson wrote: Tomasz / Linus, On Wed, May 15, 2013 at 3:06 PM, Tomasz Figa tomasz.f...@gmail.com wrote: Yes. I don't like the current way too much either, duplication being one of the reasons. Do you have any other ideas? It sounds like Linus didn't like my suggestion and makes some good points... I don't have anything interesting at the moment. It's a bit late now here (2 AM), so I'm going to get some sleep first. Also after reading Stephen's reply, I'm wondering if hogging wouldn't solve the problem indeed. (It might have to be fixed on pinctrl-samsung first, as last time I tried to use it, it caused some errors from pinctrl core, but haven't time to track them down, as it wasn't anything important at that time). Best regards, Tomasz -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
On Wednesday 15 of May 2013 17:03:44 Doug Anderson wrote:
Stephen,
On Wed, May 15, 2013 at 4:51 PM, Stephen Warren swar...@wwwdotorg.org
wrote:
I don't really see much disadvantage here; the interrupt bindings
specify things related to interrupts and the pinctrl bindings specify
thing related to pin configuration.
OK. If this is the best way then I can accept that and maybe we
should just drop this thread. What do people think? It means less
work for me in the short term since I've already got it implemented
that way and then I don't need to submit any patches to try to change
things! ;)
If you want to condense the DT, I'd suggest using a the pinctrl
hogging
feature, i.e. don't put pinctrl-* properties in the trackpad node, but
rather define a system-wide default pinctrl state in the pin
controller node itself. That configuration will be applied as soon as
the pin controller driver is registered. That'd be the same as the
above, with the following added:
pinctrl@1140 {
pinctrl-names = default;
pinctrl-0 = cyapa_irq;
};
except that the pinctrl-0 property would probably end up configuring a
whole bunch of basic pinctrl state rather than just that one interrupt
pin.
I prefer to put all the static pinctrl configuration in the pinctrl
hog, and only the dynamic stuff in the individual device nodes.
I know LinusW won't like this suggestion much though:-)
Ah right! I forgot about hogs in this case. That's also reasonable
as a solution and is similar to what we've got in the tree for
powerdown configuration of pins (I'll try to post this patch soon too,
WIP at https://gerrit.chromium.org/gerrit/#/c/51292/ and
https://gerrit.chromium.org/gerrit/#/c/51372/.
Hmm, last thing before I fell asleep: We already have support for power
down configuration in pinctrl-samsung. See samsung,pin-conpdn and
samsung,pin-pudpdn.
Also I already have patches for suspend/resume support of pinctrl-samsung
and pinctrl-exynos, as well as configuration of wake-up sources. I'm going
to post them soon.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
On 05/15/2013 06:13 PM, Tomasz Figa wrote:
On Wednesday 15 of May 2013 16:55:37 Doug Anderson wrote:
Tomasz / Linus,
On Wed, May 15, 2013 at 3:06 PM, Tomasz Figa tomasz.f...@gmail.com
wrote:
Yes. I don't like the current way too much either, duplication being
one of the reasons.
Do you have any other ideas? It sounds like Linus didn't like my
suggestion and makes some good points...
I don't have anything interesting at the moment. It's a bit late now here
(2 AM), so I'm going to get some sleep first.
Also after reading Stephen's reply, I'm wondering if hogging wouldn't
solve the problem indeed. (It might have to be fixed on pinctrl-samsung
first, as last time I tried to use it, it caused some errors from pinctrl
core, but haven't time to track them down, as it wasn't anything important
at that time).
One issue I noticed with the DT fragments earlier in this thread. It
looks like hogs in the Samsung pinctrl bingings end up looking like:
pinctrl {
pina {
samsung,pins = PIN_A PIN_B PIN_C;
samsung,pin-function = 0xf;
samsung,pin-pud = 0;
...
};
pinp {
samsung,pins = PIN_P PIN_Q;
samsung,pin-function = 0xe;
samsung,pin-pud = 1;
...
};
pinx {
samsung,pins = PIN_X PIN_Y PIN_Z;
samsung,pin-function = 0xd;
samsung,pin-pud = 2;
...
};
pinctrl-names = default;
pinctrl-0 = pina pinp pinx;
};
That pinctrl-0 property could get rather large (hard to write/maintain,
unwieldy) if it needs to set up lots of different configurations. That's
why I made the equivalent Tegra bindings be:
pinctrl {
pins_default {
pina {
samsung,pins = PIN_A PIN_B PIN_C;
samsung,pin-function = 0xf;
samsung,pin-pud = 0;
...
};
pinp {
samsung,pins = PIN_P PIN_Q;
samsung,pin-function = 0xe;
samsung,pin-pud = 1;
...
};
pinx {
samsung,pins = PIN_X PIN_Y PIN_Z;
samsung,pin-function = 0xd;
samsung,pin-pud = 2;
...
};
};
pinctrl-names = default;
pinctrl-0 = pins_default;
};
The extra level within the pinctrl configuration node (pins_default
here) makes the pinctrl-0 property a lot easier to write, and the
advantage happens at every use-site that needs to configure different
subsets of the relevant pins in different ways.
If you're changing all the bindings anyway, introducing this extra level
might be something to think about.
I did try to explain my philosophy here when we all got together to
design the pinctrl bindings, but I obviously didn't explain it well
enough, or people didn't like it anyway.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
Tomasz, On Wed, May 15, 2013 at 5:13 PM, Tomasz Figa tomasz.f...@gmail.com wrote: I don't have anything interesting at the moment. It's a bit late now here (2 AM), so I'm going to get some sleep first. Sorry for keeping you up. Sleep is good! Also after reading Stephen's reply, I'm wondering if hogging wouldn't solve the problem indeed. (It might have to be fixed on pinctrl-samsung first, as last time I tried to use it, it caused some errors from pinctrl core, but haven't time to track them down, as it wasn't anything important at that time). I will give it a shot tomorrow morning and see how it looks. I'll also evaluate Stephen's suggestions then once I've see how it looks with the current bindings... -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Pulls and drive strengths in the pinctrl world
Tomasz, On Wed, May 15, 2013 at 5:19 PM, Tomasz Figa tomasz.f...@gmail.com wrote: Hmm, last thing before I fell asleep: We already have support for power down configuration in pinctrl-samsung. See samsung,pin-conpdn and samsung,pin-pudpdn. Dang it! OK, we'll work on using those. Also I already have patches for suspend/resume support of pinctrl-samsung and pinctrl-exynos, as well as configuration of wake-up sources. I'm going to post them soon. Huh, I wonder if they look just like the one we've been working on: * https://gerrit.chromium.org/gerrit/#/c/51336/ * https://gerrit.chromium.org/gerrit/#/c/51342/ Those are about ready for upstream, too. I was going to send them this morning when I found out that we were missing a bunch of pinctrl patches and had to rework then. :( Anyway, we can compare our solutions and figure out which is better. ;) I'm happy with anything that works! -Doug -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
