On 05/07/2014 02:02 AM, FanWu wrote: ... > I think the glitch you mentioned is indeed a problem for the vendors who > define the "pinctrl-single,function-off" which will be activated when > disabling setting.
"pinctrl-single,function-off" is one specific driver's way of configuring what happens when a mux option is disabled. The issue applies to all drivers that implement a mux option disable function. ... > I considered my previous option 1 of avoiding duplicated calling > enable_setting. If we want to avoid too much iteration in this solution, > some mark variables need to be introduced, which may make code more > complicated than the previous one. Probably the best thing is to just remove the concept of "disable a mux option". It doesn't make sense. All you can do with mux options is to select some specific mux option. Disabling a mux option isn't something that's logically possible. On some HW, perhaps you can do something similar by tri-stating the pin or something, but that should be an explicit part of the pinctrl state definition rather than an automatic side-effect. ... > Maybe another topic: > In the original code, the Pin setting will be changed to the > disabled/safe state when Pin state is switched if the old setting is not > existed in new state rather than directly switched to the new Pin > setting. Also a possible glitch? That's not a glitch, since it's not a temporary state. The mux setting starts out as configured by the old state, then switches one time to whatever the disable function sets it to. After that, it won't switch again, unless there's an explicit SW action to enable a new state. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
