On Thu, Oct 10, 2013 at 10:49 PM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote: > On 10/09/2013 08:01 AM, Linus Walleij wrote: >> On Wed, Oct 9, 2013 at 3:28 PM, Christian Ruppert >> <christian.ruppert@xxxxxxxxxx> wrote: >>> On Wed, Oct 09, 2013 at 01:58:35PM +0200, Linus Walleij wrote: >>>> On Tue, Oct 8, 2013 at 2:25 PM, Christian Ruppert >>>> <christian.ruppert@xxxxxxxxxx> wrote: > ... >>> Obviously, a driver (no matter for which OS) must be aware of >>> this hardware property so it can decide which value to write to which >>> register in order to control the pin mux. If we don't want to split (or >>> worse: duplicate) that information in the driver and device tree, I see >>> two alternatives. >>> 1. Define register offsets, masks and register values and the list of >>> pins controlled by those register/value pairs in the device tree. >> >> This is not a viable alternative of course. > > Cough. pinctrl-single. Cough. Indeed I have had second thoughts about pinctrl-single both during its inception and later. Especially yesteray when it sort of popped up that "yeah one register per pin ... then we have this one extra register on the side to flush the pin settings out to the IO-ring". (Haven't caught up with that discussion though.) It really needs to be kept in its very constrained cage. For pinctrl-single there are quite a few strings attached, like the pin can only be controlled by a single register, not two of them. The indata to the device tree should be in some nonsensical machine-readable form, not a human-readable manual, such that the work of writing a "proper" driver would involve reverse-engineering that manual. But it is definately in a grey area. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
