From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-bn1bon0147.outbound.protection.outlook.com ([157.56.111.147]:48890 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1756415AbaJXMI1 (ORCPT ); Fri, 24 Oct 2014 08:08:27 -0400 Message-ID: <544A4132.8000404@amd.com> Date: Fri, 24 Oct 2014 07:08:18 -0500 From: Suravee Suthikulpanit MIME-Version: 1.0 To: Mark Rutland CC: Will Deacon , Liviu Dudau , Marc Zyngier , Catalin Marinas , "jason@lakedaemon.net" , "tglx@linutronix.de" , "robh+dt@kernel.org" , "bhelgaas@google.com" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linux-pci@vger.kernel.org" , "linux-doc@vger.kernel.org" , "devicetree@vger.kernel.org" , Thomas Lendacky , Joel Schopp 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 Sender: linux-pci-owner@vger.kernel.org List-ID: 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 >> >> 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