[U-Boot] [PATCH 1/3] dm: gpio: Add driver for MPC85XX GPIO controller

[Mario Six]

On Sun, May 8, 2016 at 3:28 PM, Timur Tabi <timur at tabi.org> wrote:

> On Mon, May 2, 2016 at 6:43 AM, Mario Six <mario.six at gdsys.cc> wrote:
> > Regarding the address width discrepancy: The system I'm working on is a
> > P1022 Qoriq, which has 36 bit width, which implies that phys_addr_t needs
> > to be 64 bit. But the everything else (including the GPIO controller)
> uses
> > 32 bits, thus the device tree addresses are 32 bit wide. I'm not quite
> sure
> > how to handle this difference; DM support for this platform is brand-new,
> > so there are no drivers to look to for guidance.
>
> I did primary development on the P1022DS, so maybe I can help.  It's
> been a while since I've worked on it, though.
>
> First, note that there are two versions of the P1022DS DTS: one is
> 32-bit, and the other is 36-bit.  This was back when Freescale's SOCs
> were transitioning to 36-bit physical addresses.  So if you're never
> going to have more than 2GB of RAM in your system, you can use 32-bit
> physical addresses in the DTS.
>
> Can you explain the problem again?  Like I said, it's been a while,
> but I have a hard time believing that you've discovered a new problem
> on the P1022 that hasn't already been solved.
>

The problem is that in 36-bit mode the physical addresses are 64-bit, which
means that you get 64-bit integers when you read something from the device
tree
with fdtdec_get_addr. But the device tree addresses themselves seem to be
32-bit, because if I read a property like 'reg = <0xf000 0x100>', I get a
64-bit value that contains two 32-bit values, so I have to do 'addr = reg >>
32; size = reg & 0xFFFFFFFF;' to extract them (see the patch). Doing that
poses
a problem if you use the 32-bit mode, though, since then the physical
addresses
are 32-bit.

After reading your comment (and a bit of digging), I found the
fdtdec_get_addr_size_auto_noparent function, which seems to fix that problem
(by taking the parent's address-size values into account). I'll respin the
patches with that function and Simon's concerns addressed.

Thanks for the help!

Best regards,
Mario