Hi Linus,
On Tue, Jan 20, 2015 at 10:45:09AM +0100, Linus Walleij wrote:
> On Fri, Jan 16, 2015 at 11:23 AM, Yingjoe Chen
> <yingjoe.chen@xxxxxxxxxxxx> wrote:
> > On Fri, 2015-01-16 at 10:53 +0100, Linus Walleij wrote:
> >> On Tue, Jan 13, 2015 at 5:16 PM, Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> wrote:
> >> > On Tue, Jan 13, 2015 at 11:05:22AM +0100, Linus Walleij wrote:
> >>
> >> >> > You often talk about ambiguities. Could you give an example what
> >> >> > ambiguities you mean?
> >> >>
> >> >> What happened was this pins = ; arguments were sometimes
> >> >> strings and sometimes integers, that becomes strange to handle
> >> >> in code, ambiguous.
> >> >
> >> > I see. I like naming it 'pinmux' because that's what it is: pins and
> >> > mux settings. A plain 'pinno' suggests that it contains only pin mubers,
> >> > without mux setting. How about 'pin-no-mux'? We also could add an
> >> > explicit "pins-are-numbered" property instead of distinguishing this
> >> > by property names.
> >>
> >> I kind of like this "pins-are-numbered" thing.
> >>
> >> The other property for the pin, whether pinmux or pin-no-mux or
> >> pin-num-and-mux etc is no such big deal, as long as it's
> >> consistent and documented with the generic bindings.
> >
> > Hi Linus,
> >
> > To make sure I understand it correct, you think something like this is
> > OK?
> >
> > pinctrl@01c20800 {
> > compatible = "mediatek,mt8135-pinctrl";
> > [...]
> > pins-are-numbered;
> >
> > i2c0_pins_a: i2c0@0 {
> > pins1 {
> > pins = <MT8135_PIN_100_SDA0__FUNC_SDA0>,
> > <MT8135_PIN_101_SCL0__FUNC_SCL0>;
> > bias-disable;
> > };
> > };
>
> As discussed with Sascha Hauer it is ambigous to use "pins" for
> a numerical value indicating both a mux setting and a pin. Sascha
> suggests using "pinmux" and adding this as a secondary generic
> binding for this type of pin controllers that use numbers and #defines
> to set up bindings.
>
> We should still move these parsing functions to the core.
I tried that for the last few days and failed.
Part of the problem is that the core lacks the data structures to put
the information in. There is
struct pinctrl_map_mux {
const char *group;
const char *function;
};
but its meaning is SoC specific. Some SoCs combine the pins found in a
dt subnode to one group (i.MX, rockchip, at91) while others make an
individual group from each single pin (Tegra, others?). Also the
function string is SoC specific. Some SoCs just define functions like
"alt1".."altn" which are valid for all groups, others define different
function names for each group.
Another thing is that the binding gives us numbers, but struct
pinctrl_map_mux expects strings, so the numbers would have to be
converted to strings. This is crude since the contents of struct
pinctrl_map_mux are converted from strings back to numbers later from
the pinctrl core with the help of the driver. So we would have to
translate the numbers from the bindings to strings just to convert them
back to numbers before passing them to the driver later.
Given that the best I can come up with is something like:
int pinctrl_parse_pinmux(struct device_node *np, int index,
unsigned int *pinno, unsigned int *funcno)
{
u32 val;
int ret;
ret = of_property_read_u32_index(np, "pinmux", index, &val);
if (ret)
return ret;
*pinno = val >> 8
*funcno = val & 0xff;
return 0;
}
Is that what you expect from a common parser?
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
