On Thu, May 20, 2021 at 7:17 AM Drew Fustini <drew@xxxxxxxxxxxxxxx> wrote: > On Wed, May 19, 2021 at 02:27:38PM +0300, Andy Shevchenko wrote: > > On Wed, May 19, 2021 at 1:02 PM Drew Fustini <drew@xxxxxxxxxxxxxxx> wrote: > > > On Tue, May 18, 2021 at 05:01:30PM +0300, Andy Shevchenko wrote: ... > > > Vladimir Zapolskiy wrote in e73339037f6b ("pinctrl: remove unused > > > 'pinconf-config' debugfs interface"): > > > > > > Of course it might be possible to increase MAX_NAME_LEN, and then add > > > .pin_config_dbg_parse_modify callbacks to the drivers, but the whole > > > idea of such a limited debug option looks inviable. A more flexible > > > way to functionally substitute the original approach is to implicitly > > > or explicitly use pinctrl_select_state() function whenever needed. > > > > > > This makes me think it is not a good idea to bring back pinconf-config. > > > The pinmux-select debugfs file that I add added in commit 6199f6becc86 > > > ("pinctrl: pinmux: Add pinmux-select debugfs file") provides a method to > > > activate a pin function and pin group which I think provides the same > > > capability as long as the possible pin functions are described in dts. > > > > The problem is that the pinctrl_select_state() is very limited and has > > no clear meanings of the states. Only few are defined and still > > unclear. What does `sleep` or `standby` or whatever mean? It may be > > quite different to the device in question. Basically what we need is > > to say we want this device ('function') to appear on this group of > > pins ('group'). And pinctrl_select_state() can't fulfill this simple > > task :-( > > > > If we look at the ACPI case it makes that API completely out of useful > > context (it can be used due to above and some kind of layering > > violations, like PM vs. pin control). > > > > Since above is the debugfs interface we may return it for the certain > > task, i.e. printing current function / group choice(s) (if it's not > > done by other means) and allow to switch it desired function/group > > (that's what Dario tries to achieve AFAIU). > > A write to the pinmux-select debugfs file will call pinmux_select() in > drivers/pinctrl/pinmux.c which, after some validation checks, will call > pmxops->set_mux() with function selector and group selector as > arguments. For pinctrl-single, this will invoke pcs_set_mux() which > will ultimately set the mux mode bits in the register for each pin in > that function. > > IS that useful for pin controllers in ACPI systems as well? Yes, the debugfs interface is useful independently of the resource provider. What I was talking about is the boot / driver load time pin muxing and configuration as well as PM transitions. -- With Best Regards, Andy Shevchenko