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
WARNING: multiple messages have this Message-ID (diff)
From: Suravee.Suthikulpanit@amd.com (Suravee Suthikulpanit)
To: linux-arm-kernel@lists.infradead.org
Subject: [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 at 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 at 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 at 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 at 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: 122+ 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 ` suravee.suthikulpanit
2014-09-28 20:53 ` suravee.suthikulpanit at amd.com
2014-09-28 20:53 ` [RFC 1/4] arm64: amd-seattle: Adding device tree for AMD Seattle platform suravee.suthikulpanit
2014-09-28 20:53 ` suravee.suthikulpanit-5C7GfCeVMHo
2014-09-28 20:53 ` suravee.suthikulpanit at amd.com
2014-10-10 13:45 ` Mark Rutland
2014-10-10 13:45 ` Mark Rutland
2014-10-24 12:08 ` Suravee Suthikulpanit [this message]
2014-10-24 12:08 ` Suravee Suthikulpanit
2014-09-28 20:53 ` [RFC 2/4] PCI: generic: Add support for ARM64 and MSI(x) suravee.suthikulpanit
2014-09-28 20:53 ` suravee.suthikulpanit
2014-09-28 20:53 ` suravee.suthikulpanit at amd.com
2014-09-29 14:36 ` Arnd Bergmann
2014-09-29 14:36 ` Arnd Bergmann
2014-09-30 12:03 ` Lorenzo Pieralisi
2014-09-30 12:03 ` Lorenzo Pieralisi
2014-09-30 12:31 ` Arnd Bergmann
2014-09-30 12:31 ` Arnd Bergmann
2014-09-30 16:12 ` Lorenzo Pieralisi
2014-09-30 16:12 ` Lorenzo Pieralisi
2014-09-30 16:42 ` Liviu Dudau
2014-09-30 16:42 ` Liviu Dudau
2014-09-30 17:35 ` Lorenzo Pieralisi
2014-09-30 17:35 ` Lorenzo Pieralisi
2014-09-30 17:48 ` Liviu Dudau
2014-09-30 17:48 ` Liviu Dudau
2014-09-30 18:54 ` Arnd Bergmann
2014-09-30 18:54 ` Arnd Bergmann
2014-09-30 20:01 ` Arnd Bergmann
2014-09-30 20:01 ` Arnd Bergmann
2014-10-01 8:46 ` Liviu Dudau
2014-10-01 8:46 ` Liviu Dudau
2014-10-01 9:38 ` Arnd Bergmann
2014-10-01 9:38 ` Arnd Bergmann
2014-10-07 12:06 ` Lorenzo Pieralisi
2014-10-07 12:06 ` Lorenzo Pieralisi
2014-10-07 13:52 ` Arnd Bergmann
2014-10-07 13:52 ` Arnd Bergmann
2014-10-07 14:47 ` Lorenzo Pieralisi
2014-10-07 14:47 ` Lorenzo Pieralisi
2014-10-07 21:39 ` Arnd Bergmann
2014-10-07 21:39 ` Arnd Bergmann
2014-10-08 10:19 ` Lorenzo Pieralisi
2014-10-08 10:19 ` Lorenzo Pieralisi
2014-10-08 14:47 ` Arnd Bergmann
2014-10-08 14:47 ` Arnd Bergmann
2014-10-09 9:04 ` Lorenzo Pieralisi
2014-10-09 9:04 ` Lorenzo Pieralisi
2014-10-09 10:51 ` Arnd Bergmann
2014-10-09 10:51 ` Arnd Bergmann
2014-10-10 13:58 ` Lorenzo Pieralisi
2014-10-10 13:58 ` Lorenzo Pieralisi
2014-10-10 18:31 ` Arnd Bergmann
2014-10-10 18:31 ` Arnd Bergmann
2014-10-13 9:36 ` Lorenzo Pieralisi
2014-10-13 9:36 ` Lorenzo Pieralisi
2014-10-22 15:59 ` Lorenzo Pieralisi
2014-10-22 15:59 ` Lorenzo Pieralisi
2014-10-22 16:49 ` Bjorn Helgaas
2014-10-22 16:49 ` Bjorn Helgaas
2014-10-22 20:52 ` Arnd Bergmann
2014-10-22 20:52 ` Arnd Bergmann
2014-10-23 9:13 ` Liviu Dudau
2014-10-23 9:13 ` Liviu Dudau
2014-10-23 11:27 ` Lorenzo Pieralisi
2014-10-23 11:27 ` Lorenzo Pieralisi
2014-10-23 16:52 ` Jason Gunthorpe
2014-10-23 16:52 ` Jason Gunthorpe
2014-10-27 16:10 ` Lorenzo Pieralisi
2014-10-27 16:10 ` Lorenzo Pieralisi
2014-10-23 13:33 ` Arnd Bergmann
2014-10-23 13:33 ` Arnd Bergmann
2014-10-24 10:04 ` Liviu Dudau
2014-10-24 10:04 ` Liviu Dudau
2014-11-05 23:40 ` Bjorn Helgaas
2014-11-05 23:40 ` Bjorn Helgaas
2014-11-06 0:06 ` Arnd Bergmann
2014-11-06 0:06 ` Arnd Bergmann
2014-11-06 0:06 ` Arnd Bergmann
2014-12-29 19:32 ` Suravee Suthikulpanit
2014-12-29 19:32 ` Suravee Suthikulpanit
2015-01-02 11:55 ` Lorenzo Pieralisi
2015-01-02 11:55 ` Lorenzo Pieralisi
2015-01-02 11:55 ` Lorenzo Pieralisi
2015-01-02 18:18 ` Suravee Suthikulanit
2015-01-02 18:18 ` Suravee Suthikulanit
2015-01-02 21:09 ` Arnd Bergmann
2015-01-02 21:09 ` Arnd Bergmann
2015-01-05 14:48 ` Lorenzo Pieralisi
2015-01-05 14:48 ` Lorenzo Pieralisi
2014-11-05 23:39 ` Bjorn Helgaas
2014-11-05 23:39 ` Bjorn Helgaas
2014-11-06 0:05 ` Arnd Bergmann
2014-11-06 0:05 ` Arnd Bergmann
2014-11-06 9:52 ` Lorenzo Pieralisi
2014-11-06 9:52 ` Lorenzo Pieralisi
2014-09-29 19:19 ` Sunil Kovvuri
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-28 20:53 ` suravee.suthikulpanit
2014-09-28 20:53 ` suravee.suthikulpanit at amd.com
2014-09-29 14:38 ` Arnd Bergmann
2014-09-29 14:38 ` Arnd Bergmann
2014-09-29 18:17 ` Bjorn Helgaas
2014-09-29 18:17 ` Bjorn Helgaas
2015-06-23 22:34 ` Benjamin Herrenschmidt
2015-06-23 22:34 ` Benjamin Herrenschmidt
2015-06-23 23:05 ` Russell King - ARM Linux
2015-06-23 23:05 ` Russell King - ARM Linux
2015-06-23 22:32 ` Benjamin Herrenschmidt
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 20:53 ` suravee.suthikulpanit-5C7GfCeVMHo
2014-09-28 20:53 ` suravee.suthikulpanit at amd.com
2014-09-28 21:35 ` Suravee Suthikulpanit
2014-09-28 21:35 ` Suravee Suthikulpanit
2014-09-28 21:35 ` Suravee Suthikulpanit
2014-09-29 14:23 ` Thomas Gleixner
2014-09-29 14:23 ` Thomas Gleixner
2014-09-29 14:42 ` Arnd Bergmann
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.