[RFC,3/3] ARM: e3xx: Add header file for pinctrl constants

This new header file defines pincontrol constants for USRP E3xx to
use from E3xx's DTS file for pincontrol properties option.

Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
---
 include/dt-bindings/pinctrl/pinctrl-e3xx.h | 142 +++++++++++++++++++++++++++++
 1 file changed, 142 insertions(+)
 create mode 100644 include/dt-bindings/pinctrl/pinctrl-e3xx.h

On Thursday 05 November 2015 15:41:23 Moritz Fischer wrote:
> +/* Pin names for the E31x usecase */
> +#define E31X_TX_BANDSEL_2      "DB_1"
> +#define E31X_RX1B_BANDSEL_0    "DB_3"
> +#define E31X_RX1B_BANDSEL_1    "DB_5"
> +#define E31X_VCTXRX2_V2                "DB_7"
> +#define E31X_TX_ENABLE1A       "DB_9"
> +#define E31X_TX_ENABLE2A       "DB_11"
> +#define E31X_TX_BANDSEL_0      "DB_12"

Why not put the strings directly into the .dts files and change the
lookup table in the driver accordingly:

+static const struct pinctrl_pin_desc e3xx_pins[] = {
+       /* pin0 doesn't exist */
+       PINCTRL_PIN(1, "TX_BANDSEL_2"),
+       PINCTRL_PIN(3, "RX1B_BANDSEL_0"),
+       PINCTRL_PIN(5, "RX1B_BANDSEL_1"),
+       PINCTRL_PIN(7, "VCTXRX2_V2"),

That would save you the hassle of the three-way dependency between the
dts file, the driver and the header when you want to change something
going through three different maintainer trees.

	arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Arnd,

On Fri, Nov 6, 2015 at 12:54 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 05 November 2015 15:41:23 Moritz Fischer wrote:
>> +/* Pin names for the E31x usecase */
>> +#define E31X_TX_BANDSEL_2      "DB_1"
>> +#define E31X_RX1B_BANDSEL_0    "DB_3"
>> +#define E31X_RX1B_BANDSEL_1    "DB_5"
>> +#define E31X_VCTXRX2_V2                "DB_7"
>> +#define E31X_TX_ENABLE1A       "DB_9"
>> +#define E31X_TX_ENABLE2A       "DB_11"
>> +#define E31X_TX_BANDSEL_0      "DB_12"
>
> Why not put the strings directly into the .dts files and change the
> lookup table in the driver accordingly:
>
> +static const struct pinctrl_pin_desc e3xx_pins[] = {
> +       /* pin0 doesn't exist */
> +       PINCTRL_PIN(1, "TX_BANDSEL_2"),
> +       PINCTRL_PIN(3, "RX1B_BANDSEL_0"),
> +       PINCTRL_PIN(5, "RX1B_BANDSEL_1"),
> +       PINCTRL_PIN(7, "VCTXRX2_V2"),

That's actually the way I initially had it, however the pin names
literally changed
in the schematic depending on which daughter-board you stick into the slot.
So my plan was to add the #defines for the second daughter-board in a
follow up patch
once the pin assignment is final. This would allow me to have something like:

pins = E31X_TX_BANDSEL_2;
output-low;

in one .dts, while having something like

pins = E33X_TX_BANDSEL_2
output low;

in the second dts

The other option would have been to stick a e31x_pins and a e33x_pins
into the driver,
and set them according to a compatible string or "ettus,daughterboard"
property on probe.

Does that make sense, or do you think there's a cleaner / better way
to achieve this sort of behavior?

Thanks for your feedback!

Cheers,
Moritz
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Friday 06 November 2015 08:01:25 Moritz Fischer wrote:
> Hi Arnd,
> 
> On Fri, Nov 6, 2015 at 12:54 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday 05 November 2015 15:41:23 Moritz Fischer wrote:
> >> +/* Pin names for the E31x usecase */
> >> +#define E31X_TX_BANDSEL_2      "DB_1"
> >> +#define E31X_RX1B_BANDSEL_0    "DB_3"
> >> +#define E31X_RX1B_BANDSEL_1    "DB_5"
> >> +#define E31X_VCTXRX2_V2                "DB_7"
> >> +#define E31X_TX_ENABLE1A       "DB_9"
> >> +#define E31X_TX_ENABLE2A       "DB_11"
> >> +#define E31X_TX_BANDSEL_0      "DB_12"
> >
> > Why not put the strings directly into the .dts files and change the
> > lookup table in the driver accordingly:
> >
> > +static const struct pinctrl_pin_desc e3xx_pins[] = {
> > +       /* pin0 doesn't exist */
> > +       PINCTRL_PIN(1, "TX_BANDSEL_2"),
> > +       PINCTRL_PIN(3, "RX1B_BANDSEL_0"),
> > +       PINCTRL_PIN(5, "RX1B_BANDSEL_1"),
> > +       PINCTRL_PIN(7, "VCTXRX2_V2"),
> 
> That's actually the way I initially had it, however the pin names
> literally changed
> in the schematic depending on which daughter-board you stick into the slot.
> So my plan was to add the #defines for the second daughter-board in a
> follow up patch
> once the pin assignment is final. This would allow me to have something like:
> 
> pins = E31X_TX_BANDSEL_2;
> output-low;
> 
> in one .dts, while having something like
> 
> pins = E33X_TX_BANDSEL_2
> output low;
> 
> in the second dts

That doesn't seem helpful though, because the assignment of the
pins is not hidden from the source file that should be documenting
it: if someone wants to know how the pins are muxed, they now have
to cross-reference the dts file with the header. If you just put the
pin number directly into the dts, it becomes completely clear
what the setting is.

> The other option would have been to stick a e31x_pins and a e33x_pins
> into the driver,
> and set them according to a compatible string or "ettus,daughterboard"
> property on probe.
> 
> Does that make sense, or do you think there's a cleaner / better way
> to achieve this sort of behavior?

The driver should not be board specific.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Fri, Nov 6, 2015 at 8:42 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 06 November 2015 08:01:25 Moritz Fischer wrote:
>> Hi Arnd,
>>
>> On Fri, Nov 6, 2015 at 12:54 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Thursday 05 November 2015 15:41:23 Moritz Fischer wrote:
>> >> +/* Pin names for the E31x usecase */
>> >> +#define E31X_TX_BANDSEL_2      "DB_1"
>> >> +#define E31X_RX1B_BANDSEL_0    "DB_3"
>> >> +#define E31X_RX1B_BANDSEL_1    "DB_5"
>> >> +#define E31X_VCTXRX2_V2                "DB_7"
>> >> +#define E31X_TX_ENABLE1A       "DB_9"
>> >> +#define E31X_TX_ENABLE2A       "DB_11"
>> >> +#define E31X_TX_BANDSEL_0      "DB_12"
>> >
>> > Why not put the strings directly into the .dts files and change the
>> > lookup table in the driver accordingly:
>> >
>> > +static const struct pinctrl_pin_desc e3xx_pins[] = {
>> > +       /* pin0 doesn't exist */
>> > +       PINCTRL_PIN(1, "TX_BANDSEL_2"),
>> > +       PINCTRL_PIN(3, "RX1B_BANDSEL_0"),
>> > +       PINCTRL_PIN(5, "RX1B_BANDSEL_1"),
>> > +       PINCTRL_PIN(7, "VCTXRX2_V2"),
>>
>> That's actually the way I initially had it, however the pin names
>> literally changed
>> in the schematic depending on which daughter-board you stick into the slot.
>> So my plan was to add the #defines for the second daughter-board in a
>> follow up patch
>> once the pin assignment is final. This would allow me to have something like:
>>
>> pins = E31X_TX_BANDSEL_2;
>> output-low;
>>
>> in one .dts, while having something like
>>
>> pins = E33X_TX_BANDSEL_2
>> output low;
>>
>> in the second dts
>
> That doesn't seem helpful though, because the assignment of the
> pins is not hidden from the source file that should be documenting
> it: if someone wants to know how the pins are muxed, they now have
> to cross-reference the dts file with the header. If you just put the
> pin number directly into the dts, it becomes completely clear
> what the setting is.

Just to clarify, you're suggesting using "DB_0" etc in the dts file?
At that point
the name becomes kinda useless. I found the PINCTRL_PIN_ANON macro,
but haven't found any use throughout the tree, is using it discouraged?

>> The other option would have been to stick a e31x_pins and a e33x_pins
>> into the driver,
>> and set them according to a compatible string or "ettus,daughterboard"
>> property on probe.
>>
>> Does that make sense, or do you think there's a cleaner / better way
>> to achieve this sort of behavior?
>
> The driver should not be board specific.

Agreed, thank you!

Cheers,

Moritz
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Friday 06 November 2015 09:55:28 Moritz Fischer wrote:
> On Fri, Nov 6, 2015 at 8:42 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday 06 November 2015 08:01:25 Moritz Fischer wrote:
> >> pins = E31X_TX_BANDSEL_2;
> >> output-low;
> >>
> >> in one .dts, while having something like
> >>
> >> pins = E33X_TX_BANDSEL_2
> >> output low;
> >>
> >> in the second dts
> >
> > That doesn't seem helpful though, because the assignment of the
> > pins is not hidden from the source file that should be documenting
> > it: if someone wants to know how the pins are muxed, they now have
> > to cross-reference the dts file with the header. If you just put the
> > pin number directly into the dts, it becomes completely clear
> > what the setting is.
> 
> Just to clarify, you're suggesting using "DB_0" etc in the dts file?
> At that point
> the name becomes kinda useless. I found the PINCTRL_PIN_ANON macro,
> but haven't found any use throughout the tree, is using it discouraged?

I don't know if that is the best approach, but it's better than using
macros here. You should only add a header file with macros if you
absolutely have to define a common namespace between the driver and the
dts files, but you don't do that here: the header file is only used
in one place.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html