[U-Boot] [PATCH] dm: core: Add platform specific bus translation function

[Simon Glass]

Hi Stefan,

On 2 December 2015 at 10:43, Stefan Roese <sr at denx.de> wrote:
> Hi Simon,
>
> ( Last mail for tonight - a glass of quite nice red wine is
> waiting for me ... ;) )
>

That's the only sad thing about me being so many hours behind. Still I
can do the same thing with people in Asia I suppose :-)

>
> On 02.12.2015 17:53, Simon Glass wrote:
>>
>> Hi Stefan,
>>
>> On 2 December 2015 at 09:00, Stefan Roese <sr at denx.de> wrote:
>>>
>>>
>>> Hi Simon,
>>>
>>> On 02.12.2015 16:50, Simon Glass wrote:
>>>
>>> <snip>
>>>
>>>>>> I think it would be better to make it depend on whether the bit is
>>>>>> flipped, rather than whether you are in SPL or not.
>>>>>
>>>>>
>>>>>
>>>>> You simply can't detect if this "bit is flipped". You just have
>>>>> to know. This is a long lasting ugly thing on some Marvell
>>>>> patforms. Here the comment from armada-xp-gp.dts:
>>>>
>>>>
>>>>
>>>> Can you point me to the place in U-Boot where this bit is flipped?
>>>> Something, somewhere has to make the change. So something has to know.
>>>> Before it makes the change, the range works one way. Afterwards it
>>>> works another way.
>>>
>>>
>>>
>>> Sure. I've mentioned this before. Its here:
>>>
>>> arch/arm/mach-mvebu/cpu.c:
>>>
>>> int arch_cpu_init(void)
>>> {
>>>          ...
>>>
>>>          /* Linux expects the internal registers to be at 0xf1000000 */
>>>          writel(SOC_REGS_PHY_BASE, INTREG_BASE_ADDR_REG);
>>>
>>> This is the line that changes the register base address. And
>>> to change it back you need to write to the new address, as the
>>> address holding this base address is also moved. Quite ugly!
>>>
>>> So its really right at the start of U-Boot proper.
>>
>>
>> OK I see. So really we can determine which way the address 'switch'
>> it. It's just a case of making the change when we are ready, and
>> keeping a record of that.
>
>
> Yes. But how is the "common code" in dev_get_addr() supposed to know
> which version of U-Boot we are running on? This boils down to some
> callback again, or not? Or even worse the ugly #ifdef.

You would call a driver-model core function to select the ranges
property to prefer. Then driver model will remember this setting and
use it.

Regards,
Simon