On 05/03/2018 11:19 AM, Tony Lindgren wrote:
* Grygorii Strashko <grygorii.strashko@xxxxxx> [180503 15:54]:
On 04/30/2018 12:31 PM, Tony Lindgren wrote:
Hi,
* Christina Quast <cquast@xxxxxxxxxxxx> [180430 11:23]:
The values are extraced from the "AM335x SitaraTM Processors Technical
Reference Manual", Section 9.3.1 CONTROL_MODULE Registers, based on the
file autogenerated by TI PinMux.
This certainly makes things easier to mux :)
Have you verified that the registers are the same across all am335x
models and different revisions?
It used to be that different SoC revisions could have different
amount of registers and also different options in some cases.
+#define AM335X_CONTROL_REVISION 0x0
+#define AM335X_CONTROL_HWINFO 0x4
+#define AM335X_CONTROL_SYSCONFIG 0x10
+#define AM335X_CONTROL_STATUS 0x40
You should only list the padconf mux registers here, no need to
list any of the controller registers.
To be honest, I do think it's right thing to do - DT by itself is
documentation and previously DT maintainers were not very happy regarding
introducing more defines instead of const.
Sounds like you mean "I don't think" above instead of "I do think"?
Care to clarify..
i don't.. sry
Adding such defines will introduce big headers in Linux common or
platform folders again which we've just got rid of.
If smth is unclear - comments can be used in DT.
Just my 5c.
The problem earlier was that we had just too many variants as
the padconf registers got changed even between SoC revisions.
Not always and not for many registers but still. The padconf
register range seems to stay the same for a SoC though.
I do see value at being able to mux the registers easier though.
--
regards,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
