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

[Stefan Roese]

Hi Simon,

On 02.12.2015 18:45, Simon Glass wrote:
> 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 :-)

Right. I'm not sure about the wine quality in Asia though... ;)
 
>>
>> 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.

Yes. This can be done. I've taken the time to implement such a
version. And attached a small patch in a hackish version, just as
an RFC. As you will see, I've added the "ranges-spl" property to
some of the DT nodes. And added the DM core functions to enable to
usage of a different, non-standard "ranges" property name.

All this is not really "clean" and will definitely break non-DM
usage of fdt_support.c. Not sure where to go from here. I would
still prefer my first patch version, even though I know that
you don't like to add this hook / callback into the DM core code.

Let me know what you think.

Thanks,
Stefan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-dm-Add-option-to-configure-a-different-non-standard-.patch
Type: text/x-diff
Size: 5494 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20151203/39791bc1/attachment.patch>