On Thu, Sep 17, 2020 at 2:20 AM Drew Fustini <drew@xxxxxxxxxxxxxxx> wrote: > > On Thu, Sep 17, 2020 at 02:03:46AM -0700, Trent Piepho wrote: > > On Mon, Sep 14, 2020 at 3:44 AM Drew Fustini <drew@xxxxxxxxxxxxxxx> wrote: > > > > > > + > > > +When #pinctrl-cells = 2, then setting a pin for a device could be done with: > > > + > > > + pinctrl-single,pins = <0xdc 0x30 0x07>; > > > + > > > +Where 0x30 is the pin configuration value and 0x07 is the pin mux mode value. > > > +See the device example and static board pins example below for more information. > > > > Pin configuration and mux mode don't mean anything in pinctrl-single. > > On another machine, mux mode might not be programmed this way or even > > exist. Or the location of bits would probably be different, and this > > would seem to imply the 0x07 would get shifted to the correct location > > for where the pin mux setting was on that machine's pinctrl registers. > > > > It seems like it would be better to explain the values are ORed together. > > I descirbed it as seoerate values as I did not want to prescribe what > the pcs driver would do with those values. But, yes, it is a just an OR > operation, so I could change the language to reflect tat. If you don't say what the pinctrl-single driver does with the values, how would anyone know how to use it? > > What is the purpose of this change anyway? It seems like in the end > > it just does what it did before. The data is now split into two cells > > in the device tree, but why? > > These changes were a result of desire to seperate pinconf and pinmux. > Tony raised the idea in a thread at the end of May [1]. > > Tony wrote: > > Only slightly related, but we should really eventually move omaps to use > > #pinctrl-cells = <2> (or 3) instead of 1, and pass the pinconf seprately > > from the mux mode. We already treat them separately with the new > > AM33XX_PADCONF macro, so we'd only have to change one SoC at a time to > > use updated #pinctrl-cells. But I think pinctrl-single might need some > > changes before we can do that. I still don't see what the goal is here. Support generic pinconf? Also note that while AM33XX_PADCONF() is changed, there is an in tree board that doesn't use it, so it's broken now. I found this change when it broke my out of tree board, due to the dtsi change not being reflected in my board's pinctrl values.
