[U-Boot] [PATCH v5 05/11] exynos: dts: Adjust device tree files for U-Boot

[Simon Glass]

Hi Tom,

On 5 August 2014 08:07, Tom Rini <trini at ti.com> wrote:
> On Mon, Aug 04, 2014 at 02:46:02PM -0600, Simon Glass wrote:
>> Hi Tom,
>>
>> On 4 August 2014 09:54, Tom Rini <trini at ti.com> wrote:
>> > On Mon, Aug 04, 2014 at 06:01:58AM -0600, Simon Glass wrote:
>> >> Hi Tom,
>> >>
>> >> On 30 July 2014 09:34, Simon Glass <sjg at chromium.org> wrote:
>> >> > Hi Tom,
>> >> >
>> >> > On 28 July 2014 21:27, Tom Rini <trini at ti.com> wrote:
>> >> >> On Mon, Jul 28, 2014 at 06:11:32AM -0600, Simon Glass wrote:
>> >> >>
>> >> >>> The pinctrl bindings used by Linux are an incomplete description of the
>> >> >>> hardware. It is possible in most cases to determine the register address
>> >> >>> of each, but not in all cases. By adding an additional property we can
>> >> >>> fix this, and avoid adding a table to U-Boot for every single Exynos
>> >> >>> SOC.
>> >> >>
>> >> >> So here's my fear..
>> >> >>
>> >> >> [snip]
>> >> >>> @@ -49,7 +57,7 @@
>> >> >>>       i2c at 12ca0000 {
>> >> >>>               #address-cells = <1>;
>> >> >>>               #size-cells = <0>;
>> >> >>> -             compatible = "samsung,s3c2440-i27c";
>> >> >>> +             compatible = "samsung,s3c2440-i2c";
>> >> >>>               reg = <0x12CA0000 0x100>;
>> >> >>>               interrupts = <0 60 0>;
>> >> >>>       };
>> >> >>
>> >> >> Except for the above (what's going on? pulling in a typo fix from
>> >> >> upstream?) they're legal "regular" non-U-Boot-prefixed changes.  Are
>> >> >> they going back into the master copy in Linux?
>> >> >
>> >> > Oops I missed this email. The typo is just my mistake - we don't need
>> >> > this change and the typo is in the previous patch.
>> >> >
>> >> >>
>> >> >>> diff --git a/arch/arm/dts/exynos5420-pinctrl.dtsi b/arch/arm/dts/exynos5420-pinctrl.dtsi
>> >> >>> index b3e63d1..df31f37 100644
>> >> >>> --- a/arch/arm/dts/exynos5420-pinctrl.dtsi
>> >> >>> +++ b/arch/arm/dts/exynos5420-pinctrl.dtsi
>> >> >>> @@ -13,6 +13,18 @@
>> >> >>>  */
>> >> >>>
>> >> >>>  / {
>> >> >>> +     /* Replicate the ordering of arch/arm/include/asm/arch-exynos/gpio.h */
>> >> >>> +     pinctrl at 14010000 {
>> >> >>> +     };
>> >> >>> +     pinctrl at 13400000 {
>> >> >>> +     };
>> >> >>> +     pinctrl at 13410000 {
>> >> >>> +     };
>> >> >>> +     pinctrl at 14000000 {
>> >> >>> +     };
>> >> >>> +     pinctrl at 03860000 {
>> >> >>> +     };
>> >> >>
>> >> >> So this isn't going to head back to Linux, clearly...
>> >> >>
>> >> >> Is there some way we can contain our changes under includes perhaps?
>> >> >
>> >> > I hope that this one could go away, since the order of GPIOs doesn't
>> >> > ultimately matter. At present we assume a particular order due to the
>> >> > numbering of GPIOs. But once we move to named GPIOs in the device tree
>> >> > we can drop this ordering patch.
>> >> >
>> >> > In general, yes we could create a new include file for the U-Boot
>> >> > device tree additions.
>> >>
>> >> Update: I took a look at the includes. I can create a new file, like
>> >> arch/arm/dts/exynos4210-pinctrl.dtsi which I include from
>> >> arch/arm/dts/exynos4210.dtsi. But I think I will still need to modify
>> >> arch/arm/dts/exynos4210.dtsi. The alternative is to put the changes in
>> >> something like exynos4210-u-boot.dtsi and include those in every board
>> >> file that uses that include.
>> >
>> > With arch/arm/dts/exynos4210-pinctrl.dtsi + arch/arm/dts/exynos4210.dtsi
>> > the modification to the later is just to include the former, right?  I'm
>> > OK with that.
>>
>> Almost, but we still need the #address-cells and #size-cells
>> properties in the pinctrl nodes.
>
> And these, as you said I think, are HW description things that should be
> included in the master DT file upstream, right?

Well we only need them because we are added 'reg' properties to the
subnodes. There would certainly be no harm in including them upstream.
The only bad thing I'm doing is the 'Replicate the ordering' bit. That
should just go away once the GPIO numbering doesn't matter anymore
(which requires that we use the device tree binding in GPIOs - this is
the next step!).

Regards,
Simon