On Sun, May 8, 2016 at 3:28 PM, Timur Tabi timur@tabi.org wrote:
On Mon, May 2, 2016 at 6:43 AM, Mario Six mario.six@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