Message-ID: <544A4132.8000404@amd.com>
Date: Fri, 24 Oct 2014 07:08:18 -0500
From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Mark Rutland <mark.rutland@arm.com>
CC: Will Deacon <Will.Deacon@arm.com>, Liviu Dudau <Liviu.Dudau@arm.com>,
        Marc Zyngier <Marc.Zyngier@arm.com>,
        Catalin Marinas <Catalin.Marinas@arm.com>,
        "jason@lakedaemon.net" <jason@lakedaemon.net>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "robh+dt@kernel.org" <robh+dt@kernel.org>,
        "bhelgaas@google.com" <bhelgaas@google.com>,
        "linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        Thomas Lendacky <Thomas.Lendacky@amd.com>,
        Joel Schopp <Joel.Schopp@amd.com>
Subject: Re: [RFC 1/4] arm64: amd-seattle: Adding device tree for AMD Seattle
 platform
References: <1411937610-22125-1-git-send-email-suravee.suthikulpanit@amd.com>
 <1411937610-22125-2-git-send-email-suravee.suthikulpanit@amd.com>
 <20141010134534.GC6004@leverpostej>
In-Reply-To: <20141010134534.GC6004@leverpostej>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org

On 10/10/2014 8:45 AM, Mark Rutland wrote:
> Hi Suravee,
>
> On Sun, Sep 28, 2014 at 09:53:27PM +0100, suravee.suthikulpanit@amd.com wrote:
>> From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
>>
>> Initial revision of device tree for AMD Seattle platform
>
> To check: how is it possible to make use of a DTB generated from this
> dts? Can a user update the DTB used by the Seattle firmware?

In the current FW, there is a mechanism that users can modify and 
provide UEFI with the updated device tree to override the one that comes 
with Seattle firmware.

[...];
>> +
>> +       timer@1,1060000 {
>> +               compatible = "arm,standalone_a5_twd";
>> +               reg = <0 0x1060000 0 0x40>;
>> +               interrupts =
>> +                       <0 378 4>,
>> +                       <0 379 4>;
>> +       };
>
> This binding does not exist in mainline.

I am removing this.

>
>> +
>> +       ccp: ccp@1,00100000 {
>> +               compatible = "amd,ccp-seattle-v1a";
>> +               reg = <0 0x00100000 0 0x10000>;
>> +               interrupts = <0 3 4>;
>> +               dma-coherent;
>> +       };
>
> Nor does this.

The binding for this one is here 
(http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/crypto/amd-ccp.txt).


 > [....]
>
>> +               linux,pci-probe-only;
>
> Why is this necessary?

This was defined in the PCI Generic Host Controller binding here 
(http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/pci/host-generic-pci.txt).

>
>> +       };
>> +
>> +       aliases {
>> +               serial0 = &v2m_serial0;
>> +       };
>> +
>> +       /* Note: This entry is modified by UEFI */
>
> In what way is this modified?

1. UEFI would basically take out certain CPUs and modify the cpu-map 
accordingly.
2. Change method to psci-0.2 when support is in place.
3. Update release address.

Actually, the "cpus" entry should/will be fully auto generated by UEFI 
in the future BIOS. I think I'll be taking this out completely for now.

> [...]
>
>> +
>> +       /* Note: This entry is modified by UEFI */
>> +       memory@8000000000 {
>> +               device_type = "memory";
>> +               reg = <0x00000080 0x00000000 0x1 0x00000000>; /* 4GB */
>> +       };
>
> Why does UEFI modify this? When booted via UEFI we use the UEFI memory
> map.

True. But for non-EFI boot (as fallback), we still need this. UEFI will 
update the amount of detected memory.

Actually, same here as the "cpus", this entry should/will go away 
completely from the static DT, and UEFI will auto-generate this in the 
future firmware.

Thanks,

Suravee
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/