Re: [PATCH v2 1/9] pinctrl: mvebu: pinctrl driver core

2012-09-09 Thread Jason Cooper
On Sun, Sep 02, 2012 at 10:27:29AM +0200, Sebastian Hesselbarth wrote: > there is a v3 of the patch under internal review right now. Sebastian, What is the status of v3? I'd like to get it (and gpio, which depends on this work) in for v3.7, but it's getting close... thx, Jason. -- To unsubscri

Re: [PATCH v2 1/9] pinctrl: mvebu: pinctrl driver core

2012-09-03 Thread Jason Cooper
On Sun, Sep 02, 2012 at 10:27:29AM +0200, Sebastian Hesselbarth wrote: > Maybe Jason can also comment on what branch he wants to have it based > on, as we all agreed to get it through the Marvell tree. Please base against: git://git.infradead.org/users/jcooper/linux.git boards-for-v3.7-v2 thx,

Re: [PATCH v2 1/9] pinctrl: mvebu: pinctrl driver core

2012-09-03 Thread Linus Walleij
On Sun, Sep 2, 2012 at 10:27 AM, Sebastian Hesselbarth wrote: > there is a v3 of the patch under internal review right now. OK I'll review as you send it out. Will look through the v2 patches to see if I missed some comment. > I know Stephen will not like it, but I decided not to have the list

Re: [PATCH v2 1/9] pinctrl: mvebu: pinctrl driver core

2012-09-02 Thread Sebastian Hesselbarth
On 09/02/2012 09:30 AM, Linus Walleij wrote: On Mon, Aug 27, 2012 at 6:33 AM, Stephen Warren wrote: The pinctrl subsystem does expect a list of functions, and for each function, a list of the groups where it can be selected. I admit that when I think about this, it's slightly backward, since HW

Re: [PATCH v2 1/9] pinctrl: mvebu: pinctrl driver core

2012-09-02 Thread Linus Walleij
On Mon, Aug 27, 2012 at 6:33 AM, Stephen Warren wrote: > On 08/25/2012 08:53 AM, Sebastian Hesselbarth wrote: >> >> now I do understand but in the current driver we pass pingroups associated >> with the available functions, i.e. "mpp2" with "uart1", "uart2", >> "sdio0", aso. >> IMHO for the above

Re: [PATCH v2 1/9] pinctrl: mvebu: pinctrl driver core

2012-08-26 Thread Stephen Warren
On 08/25/2012 08:53 AM, Sebastian Hesselbarth wrote: > On 08/24/2012 05:34 AM, Stephen Warren wrote: >> On 08/23/2012 05:01 PM, Sebastian Hesselbarth wrote: >>> So possible, valid combinations for uart1 would be: >>> (a) mpp_uart1; >>> (b) mpp_uart1, mpp2, mpp3; >>> (c) mpp_uart1, mpp21, mpp22; >>>

Re: [PATCH v2 1/9] pinctrl: mvebu: pinctrl driver core

2012-08-25 Thread Sebastian Hesselbarth
On 08/24/2012 05:34 AM, Stephen Warren wrote: On 08/23/2012 05:01 PM, Sebastian Hesselbarth wrote: So possible, valid combinations for uart1 would be: (a) mpp_uart1; (b) mpp_uart1, mpp2, mpp3; (c) mpp_uart1, mpp21, mpp22; (d) mpp_uart1, mpp2, mpp22; (e) mpp_uart1, mpp21, mpp3; [...] In the exa

Re: [PATCH v2 1/9] pinctrl: mvebu: pinctrl driver core

2012-08-23 Thread Stephen Warren
On 08/23/2012 05:01 PM, Sebastian Hesselbarth wrote: > On 08/23/2012 11:26 PM, Stephen Warren wrote: >> As you may have guessed, I strongly prefer the hard-coded static table >> based approach, or at least separating the definition of known >> pins/groups/functions from the configuration nodes that

Re: [PATCH v2 1/9] pinctrl: mvebu: pinctrl driver core

2012-08-23 Thread Sebastian Hesselbarth
On 08/23/2012 11:26 PM, Stephen Warren wrote: As you may have guessed, I strongly prefer the hard-coded static table based approach, or at least separating the definition of known pins/groups/functions from the configuration nodes that define which particular mux settings to actually use. Puting

Re: [PATCH v2 1/9] pinctrl: mvebu: pinctrl driver core

2012-08-23 Thread Stephen Warren
On 08/23/2012 02:31 PM, Sebastian Hesselbarth wrote: > On 08/23/2012 07:54 PM, Stephen Warren wrote: >>> dt_parse() and dt_parse_function() build up structs that get used >>> later on >>> in mvebu_pinmux_ops that require indexed functions. I can join them with >>> dt_node_to_map() but that would re

Re: [PATCH v2 1/9] pinctrl: mvebu: pinctrl driver core

2012-08-23 Thread Sebastian Hesselbarth
On 08/23/2012 07:54 PM, Stephen Warren wrote: dt_parse() and dt_parse_function() build up structs that get used later on in mvebu_pinmux_ops that require indexed functions. I can join them with dt_node_to_map() but that would require incremental kzalloc for the corresponding array. Or I could (fu

Re: [PATCH v2 1/9] pinctrl: mvebu: pinctrl driver core

2012-08-23 Thread Stephen Warren
On 08/23/2012 03:45 AM, Sebastian Hesselbarth wrote: > On 8/22/12, Stephen Warren wrote: >> On 08/22/2012 02:22 AM, Sebastian Hesselbarth wrote: >>> +++ b/drivers/pinctrl/pinctrl-mvebu.c >> >>> +static int mvebu_pinctrl_dt_node_to_map(struct pinctrl_dev *pctldev, >> >>> + of_property_for_each_st

Re: [PATCH v2 1/9] pinctrl: mvebu: pinctrl driver core

2012-08-23 Thread Sebastian Hesselbarth
On 8/22/12, Stephen Warren wrote: > On 08/22/2012 02:22 AM, Sebastian Hesselbarth wrote: >> +++ b/drivers/pinctrl/pinctrl-mvebu.c > >> +static int mvebu_pinctrl_dt_node_to_map(struct pinctrl_dev *pctldev, > >> +of_property_for_each_string(np, "marvell,pins", prop, group) { >> +stru

Re: [PATCH v2 1/9] pinctrl: mvebu: pinctrl driver core

2012-08-22 Thread Stephen Warren
On 08/22/2012 02:22 AM, Sebastian Hesselbarth wrote: > This patch adds a pinctrl driver core for Marvell SoCs plus DT > binding documentation. This core driver will be used by SoC family > specific drivers, i.e. Armada XP, Armada 370, Dove, Kirkwood, aso. > +++ b/Documentation/devicetree/bindings/

[PATCH v2 1/9] pinctrl: mvebu: pinctrl driver core

2012-08-22 Thread Sebastian Hesselbarth
This patch adds a pinctrl driver core for Marvell SoCs plus DT binding documentation. This core driver will be used by SoC family specific drivers, i.e. Armada XP, Armada 370, Dove, Kirkwood, aso. Signed-off-by: Sebastian Hesselbarth Signed-off-by: Thomas Petazzoni --- v2: - restructured Kconfig