[PATCH 1/2] ARM: dts: am335x: Replace numeric pinmux address with macro defines

[Grygorii Strashko]

On 05/03/2018 11:19 AM, Tony Lindgren wrote:
> * Grygorii Strashko <grygorii.strashko at ti.com> [180503 15:54]:
>>
>>
>> On 04/30/2018 12:31 PM, Tony Lindgren wrote:
>>> Hi,
>>>
>>> * Christina Quast <cquast at baylibre.com> [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