[U-Boot] [PATCH 4/9] misc: add Tegra BPMP driver

[Stephen Warren]

On 08/01/2016 09:41 AM, Stephen Warren wrote:
> On 07/31/2016 07:02 PM, Simon Glass wrote:
>> On 27 July 2016 at 15:24, Stephen Warren <swarren at wwwdotorg.org> wrote:
>>> From: Stephen Warren <swarren at nvidia.com>
>>>
>>> The Tegra BPMP (Boot and Power Management Processor) is a separate
>>> auxiliary CPU embedded into Tegra to perform power management work, and
>>> controls related features such as clocks, resets, power domains, PMIC
>>> I2C
>>> bus, etc. This driver provides the core low-level communication path by
>>> which feature-specific drivers (such as clock) can make requests to the
>>> BPMP. This driver is similar to an MFD driver in the Linux kernel. It is
>>> unconditionally selected by CONFIG_TEGRA186 since virtually any Tegra186
>>> build of U-Boot will need the feature.

>>> diff --git a/arch/arm/include/asm/arch-tegra/bpmp_abi.h

>>> +static ulong tegra186_bpmp_get_shmem(struct udevice *dev, int index)
>>> +{
>>> +       int ret;
>>> +       struct fdtdec_phandle_args args;
>>> +       struct udevice fakedev;
>>> +       fdt_addr_t reg;
>>> +
>>> +       ret = fdtdec_parse_phandle_with_args(gd->fdt_blob,
>>> dev->of_offset,
>>> +                                             "shmem", NULL, 0,
>>> index, &args);
>>> +       if (ret < 0) {
>>> +               error("fdtdec_parse_phandle_with_args() failed:
>>> %d\n", ret);
>>> +               return ret;
>>> +       }
>>> +
>>> +       fakedev.of_offset = args.node;
>>> +       reg = dev_get_addr_index(&fakedev, 0);
>>
>> This is nasty. If you don't set fakedev.parent, how does this work?
>
> Hmmm. Good question; I thought dev_get_addr_index() only used the
> device's own of_offset, but it does look like it uses the parent device
> too. I'll have to look into this.

How sad. It works because dev->parent happens to be 0, and address 0 is 
part of the mapped MMIO space so is mapped in the MMU, and then 
dev->parent->of_offset happens to be 0, so dev_get_addr_index() ends up 
querying #address-calls/#size-cells from the root node, and those happen 
to match the values for the node we're actually interested in:-(

I guess the simplest approach is to use 
fdtdec_get_addr_size_auto_parent() or similar as you say, but also  call 
fdt_translate_address() afterwards.