On Wed, Feb 07, 2018 at 10:09:20AM +0100, Linus Walleij wrote: > On Tue, Feb 6, 2018 at 4:47 PM, Lucas Stach <l.stach@xxxxxxxxxxxxxx> wrote: > > > To be fully honest I'm a bit annoyed with the pinctrl framework making > > things (IMHO) unnecessarily complex, for what is basically a pretty > > easy task. > > My ambition is to make things readable, understandable and > maintainable. In generic terms, incorporating a bunch of knowledge > of the electronics that really happen into the stuff we encode in > the kernel. > > I guess it varies a bit on what goal one has. > > If the goal is "ship product with upstream kernel really fast now" > then things like pinctrl-single.c where we just hammer magic values > into registers, make sense. OMAP developers had no idea whatsoever > what their ASIC people or cell library authors were doing so they > just threw in the towel. HiSilicon also use this. Intels ambition was > to use ACPI BIOS to handle all pin control and route around the kernel > altogether, but that is not working out so well for them I think. > > All of them are approaches to avoid putting the hairy details into the > kernel, just poke some magic values into some magic registers > and be happy. > > So i.MX could have been like that, but then I guess you need to take > legacy into account and discuss with the other i.MX driver authors > about how they really wanted and want to do things. > > Their current silence wrt this mailchain is actually becoming a > problem, and the problem is that discussing with you falls upwards > to me as subsystem maintainer. Which sucks. I prefer that people > who know this hardware discuss amongst themselves how they > want things to work. > > Surely Sascha must have an opinion? It means much to me > what he wants to do. I take it you guys are colleagues? My opinion is that all that is generic about padctrl is a device driver saying "Put my pins into a suitable mode". That is what padctrl is good for and we are there for years now. I have always been happy with the plain register values in the device tree. Before device tree we had exactly these values in the board files and I never heard anyone complaining about it. There were defines for the bits in the register which you could use when you were unhappy with plain register values. It's really trivial to look in the reference manual to make up the needed register values. It's also trivial to take a register value and look into the reference manual what this value does. Every translation layer, call it generic properties, just makes things more complicated. Often enough our input is register value tables from either our customers our from spreadsheets from FSL/NXP. Every translation layer in the way just means we have to translate the already existing register values into something hoping that this correctly translates back into the register values. It's not that some board designer comes up with "I need a drive strength of 150mA" and wants to put that value into the device tree. Instead they start with the reference manual, see which values they can (must) adjust and then adjust the values until they are happy. No one wants to ask questions like "How do I have to manipulate that device tree to change that particular bit?" As said, I am happy with plain register values in the device tree and I consider everything else overengineered. FSL/NXP Reference Manuals are freely available and of high quality so everybody can understand the register values. There's nothing magic to them. That might change slightly when the Manuals are not available, but even then I think that not the device tree ABI is the right place to add that missing documentation. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | -- 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
