From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
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
Date: Fri, 24 Oct 2014 07:08:18 -0500 [thread overview]
Message-ID: <544A4132.8000404@amd.com> (raw)
In-Reply-To: <20141010134534.GC6004@leverpostej>
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
next prev parent reply other threads:[~2014-10-24 12:08 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-28 20:53 [RFC 0/4] Add PCI/MSI(x) support for AMD Seattle Platform suravee.suthikulpanit
2014-09-28 20:53 ` [RFC 1/4] arm64: amd-seattle: Adding device tree for AMD Seattle platform suravee.suthikulpanit
2014-10-10 13:45 ` Mark Rutland
2014-10-24 12:08 ` Suravee Suthikulpanit [this message]
2014-09-28 20:53 ` [RFC 2/4] PCI: generic: Add support for ARM64 and MSI(x) suravee.suthikulpanit
2014-09-29 14:36 ` Arnd Bergmann
2014-09-30 12:03 ` Lorenzo Pieralisi
2014-09-30 12:31 ` Arnd Bergmann
2014-09-30 16:12 ` Lorenzo Pieralisi
2014-09-30 16:42 ` Liviu Dudau
2014-09-30 17:35 ` Lorenzo Pieralisi
2014-09-30 17:48 ` Liviu Dudau
2014-09-30 18:54 ` Arnd Bergmann
2014-09-30 20:01 ` Arnd Bergmann
2014-10-01 8:46 ` Liviu Dudau
2014-10-01 9:38 ` Arnd Bergmann
2014-10-07 12:06 ` Lorenzo Pieralisi
2014-10-07 13:52 ` Arnd Bergmann
2014-10-07 14:47 ` Lorenzo Pieralisi
2014-10-07 21:39 ` Arnd Bergmann
2014-10-08 10:19 ` Lorenzo Pieralisi
2014-10-08 14:47 ` Arnd Bergmann
2014-10-09 9:04 ` Lorenzo Pieralisi
2014-10-09 10:51 ` Arnd Bergmann
2014-10-10 13:58 ` Lorenzo Pieralisi
2014-10-10 18:31 ` Arnd Bergmann
2014-10-13 9:36 ` Lorenzo Pieralisi
2014-10-22 15:59 ` Lorenzo Pieralisi
2014-10-22 16:49 ` Bjorn Helgaas
2014-10-22 20:52 ` Arnd Bergmann
2014-10-23 9:13 ` Liviu Dudau
2014-10-23 11:27 ` Lorenzo Pieralisi
2014-10-23 16:52 ` Jason Gunthorpe
2014-10-27 16:10 ` Lorenzo Pieralisi
2014-10-23 13:33 ` Arnd Bergmann
2014-10-24 10:04 ` Liviu Dudau
2014-11-05 23:40 ` Bjorn Helgaas
2014-11-06 0:06 ` Arnd Bergmann
2014-12-29 19:32 ` Suravee Suthikulpanit
2015-01-02 11:55 ` Lorenzo Pieralisi
2015-01-02 18:18 ` Suravee Suthikulanit
2015-01-02 21:09 ` Arnd Bergmann
2015-01-05 14:48 ` Lorenzo Pieralisi
2014-11-05 23:39 ` Bjorn Helgaas
2014-11-06 0:05 ` Arnd Bergmann
2014-11-06 9:52 ` Lorenzo Pieralisi
2014-09-29 19:19 ` Sunil Kovvuri
2014-09-28 20:53 ` [RFC 3/4] arm64: Do not call enable PCI resources when specify PCI_PROBE_ONLY suravee.suthikulpanit
2014-09-29 14:38 ` Arnd Bergmann
2014-09-29 18:17 ` Bjorn Helgaas
2015-06-23 22:34 ` Benjamin Herrenschmidt
2015-06-23 23:05 ` Russell King - ARM Linux
2015-06-23 22:32 ` Benjamin Herrenschmidt
2014-09-28 20:53 ` [RFC 4/4] irqchip: gicv2m: Add supports for ARM GICv2m MSI(-X) suravee.suthikulpanit
2014-09-28 21:35 ` Suravee Suthikulpanit
2014-09-29 14:23 ` Thomas Gleixner
2014-09-29 14:42 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=544A4132.8000404@amd.com \
--to=suravee.suthikulpanit@amd.com \
--cc=Catalin.Marinas@arm.com \
--cc=Joel.Schopp@amd.com \
--cc=Liviu.Dudau@arm.com \
--cc=Marc.Zyngier@arm.com \
--cc=Thomas.Lendacky@amd.com \
--cc=Will.Deacon@arm.com \
--cc=bhelgaas@google.com \
--cc=devicetree@vger.kernel.org \
--cc=jason@lakedaemon.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).