On Mon, Nov 25, 2013 at 9:01 PM, Kevin Bracey <kevin@xxxxxxxxx> wrote: > I've been working on extending the shmobile PFC driver to provide > "gpio-mode" and implement PIN_CONFIG_OUTPUT as described by > Documentation/pinctrl.txt, primarily to handle sleep states, but I have > begun to wonder about the initial state problem, as discussed here. > > As far as I can see, we can't currently specify "fallback" states for pins, > which is one of Tomasz' key requirements. That depends on what you mean with "fallback states" so let's hash this out. > We can specify "hog" states, and we can specify "default for a driver", but > not "default before/in absence of a driver" or "sleep in absence of a > driver". Having a hog precludes any finer driver control, AFAICT. So the way it currently works is that hogs are usually used when there is no corresponding driver that can take care of the pins. If there are four SPI pins and no driver for that SPI block, a way to e.g. ground them is to do so using pinctrl hogs. Whenever a driver and a struct device * for this SPI block appears, it is wise to transfer control of these over to the device core, which will take any "default" state before doing probe() on the device driver, and then give you the option to use the nice pinctrl_pm* accessors to let the device core switch between "default" "idle" and "sleep" states if these are defined. > Some of our existing pre-pinconf board files have a "unused pins" table > which is used to claim and pull GPIOs. I've converted that to "hog" pinconf, > but that only works because the table omits all pins used by drivers. And, > unsurprisingly, that's been error-prone; if those tables originally covered > all unused pins, they don't any more. > > I'd like confidence that we can get every pin into the correct state by > having a fully-populated table containing all pins, that can be used > regardless of which drivers start. I think what we're lacking is a "weak > hog". Whatever you call that. :) > > That would also specify the state to fallback to when a group is released > (where we currently do pinmux_disable_setting). So I guess what you're after is a kind of hog that will be pushed aside and ignored if a struct device with an associated state appears that will use the same pin? It is true that we currently require the tables to be strict and not overlap like this, so ideally you should remove the hogs when you have a device driver, but you're actually describing an interesting case here: What if I have a driver for this IP block, and it was supposed to take care of a few pins, but I decide not to compile it into my kernel? Or if I have it as a module and only modprobe it later at runtime? So a suggested patch to support weak hogs would be interesting to look at. Can you provide details on how you think this would work? Yours, Linus Walleij -- 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
