From mboxrd@z Thu Jan 1 00:00:00 1970 From: Shawn Guo Subject: Re: [PATCH v2 1/3] dt-bindings: add binding for i.MX8MQ IOMUXC Date: Thu, 8 Feb 2018 16:56:06 +0800 Message-ID: <20180208085605.GG31910@dragon> References: <20180201174923.7385-1-l.stach@pengutronix.de> <20180205060918.vm3q6ludepvqcuxm@rob-hp-laptop> <1517825351.3175.3.camel@pengutronix.de> <1517914394.3175.21.camel@pengutronix.de> <1517932068.3175.27.camel@pengutronix.de> <20180207111156.a7cevrz3dbk2f4fb@pengutronix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Fabio Estevam Cc: Sascha Hauer , Linus Walleij , Lucas Stach , "A . s . Dong" , NXP Linux Team , Gary Bisson , Vladimir Zapolskiy , Sascha Hauer , Mark Rutland , Rob Herring , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , patchwork-lst-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org, linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: devicetree@vger.kernel.org On Wed, Feb 07, 2018 at 09:41:22AM -0200, Fabio Estevam wrote: > [Adding Shawn on Cc] Thanks Fabio. > On Wed, Feb 7, 2018 at 9:11 AM, Sascha Hauer wrote: > > > 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. > > I agree 100% with Sascha. I would vote for not going generic pinconf either, as the controversy here starts from something, that indicates the generic stuff doesn't work for i.MX. Shawn -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html