Re: [PATCH v2 1/3] dt-bindings: add binding for i.MX8MQ IOMUXC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[Adding Shawn on Cc]

On Wed, Feb 7, 2018 at 9:11 AM, Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> 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 am also happy with the current plain register values in device tree.

Having two methods (plain register values on most of i.MX SoCs and the
new generic one for imx7ulp, imx8mq) is confusing for the end users.

I would prefer to use the plain register values in device tree for all
i.MX SoCs instead.

Thanks
--
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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux