From: Michal Simek <michal.simek@xilinx.com>
To: Rob Herring <robh+dt@kernel.org>, Michal Simek <monstr@monstr.eu>
Cc: "Michal Simek" <michal.simek@xilinx.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"Sören Brinkmann" <soren.brinkmann@xilinx.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"Suneel Garapati" <suneel.garapati@xilinx.com>,
"Arnd Bergmann" <arnd@arndb.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Kumar Gala" <galak@codeaurora.org>,
"Ian Campbell" <ijc+devicetree@hellion.org.uk>,
"Shubhrajyoti Datta" <shubhraj@xilinx.com>,
"Pawel Moll" <pawel.moll@arm.com>,
"Will Deacon" <will.deacon@arm.com>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Mark Rutland" <mark.rutland@arm.com>
Subject: Re: [PATCH 3/3] ARM64: zynqmp: Use 64bit size cell format
Date: Thu, 11 Feb 2016 21:15:55 +0100 [thread overview]
Message-ID: <56BCEBFB.3070209@xilinx.com> (raw)
In-Reply-To: <CAL_JsqJPXvz_9GFtNyN024+GD=iBHARCb=VdSi_36GjMWe=CnA@mail.gmail.com>
Hi Rob,
On 11.2.2016 20:49, Rob Herring wrote:
> On Thu, Feb 11, 2016 at 12:58 PM, Michal Simek <monstr@monstr.eu> wrote:
>> Hi Rob,
>>
>> On 11.2.2016 17:13, Rob Herring wrote:
>>> On Thu, Feb 11, 2016 at 6:26 AM, Michal Simek <michal.simek@xilinx.com> wrote:
>>>> Use 64bit size cell format instead of 32bit for memory
>>>> description. Change 64bit sizes also for all others IPs.
>>>
>>> Why? As is, this change is completely pointless because nothing needs
>>> a >4GB size. Do you have peripherals with >4GB size?
>>
>> The change I need to do is to support more than 4GB memory. Memory space
>> is divided to some parts. 2GB connected to hard part below 4GB. There
>> there is 1GB connected to PL part below. Then 32GB hard part above of
>> 4GB and a lot of space for PL part (~230GB).
>>
>> PCIe can also address more than 256GB.
>
> So I would expect some amount of the bus structure to be reflected in
> the DT. For example, hard and PL IP are probably in separate address
> ranges. I'd guess PL bus has additional logic to enable/disable it for
> reprogramming, so you'd need a different bus node anyway. For PCIe,
> it's probably its own bus too.
As you see right now there is separation already.
>
>> That's why I stand before decision. Change size-cell for all IPs which
>> are currently listed. Or just change it for memory node which is listed
>> in mainline.
>> I am not quite sure how PCIe description will look like and if there is
>> any other IP which will required on current buses use sizes more that
>> 4GB. That's why I have change all sizes to support more than 4GB.
>>
>> But definitely current need is to support more than 4GB memory size and
>> I have no problem to use not empty ranges property and keep there
>> #size-cells = <1>;
>
> Then why aren't you adding to the memory? (the bootloader sets the
> actual size is a valid answer)
I am not fully convinced about it. Bootloader can set it up but there
shouldn't be dependency on bootloader capability that it will do it.
Also you don't need to use fully featured bootloader for doing that.
It means that for board dtses make sense to fill memory node with
correct values. If bootloader is capable to rewrite it/fix it, then it
is fine. If not, you can use let's say default values.
Also the second part of the problem is. You have bootloader which is
aware about that you have 34GB of memory in two banks. 2GB below 4GB
limit and 32GB above. But if bootloader starts to rewrite memory node
where #size-cell = <1> with 32GB size it will probably messes it up.
That's why I see the value to setup size-cells = <2>; earlier rather
than later.
IRC someone mentioning that in past when I was pushing zynqmp DTS that
we should use #size-cells = <2>;
>> Both solution works for me. Definitely thank you for your comments.
>
> Either way, I'd change this when you actually need the change, not by itself.
ok. Fair enough. I need this for at least memory node because boards are
using the same zynqmp.dtsi files. For all other buses I have no problem
to keep just size-cells = <1>; and setup ranges to make dtc happy.
Thanks,
Michal
prev parent reply other threads:[~2016-02-11 20:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-11 12:26 [PATCH 1/3] ARM64: zynqmp: Keep gpio node alphabetically sorted Michal Simek
2016-02-11 12:26 ` [PATCH 2/3] ARM64: zynqmp: Extract clock information from EP108 Michal Simek
2016-02-11 12:26 ` [PATCH 3/3] ARM64: zynqmp: Use 64bit size cell format Michal Simek
2016-02-11 16:13 ` Rob Herring
2016-02-11 18:58 ` Michal Simek
2016-02-11 19:49 ` Rob Herring
2016-02-11 20:15 ` Michal Simek [this message]
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=56BCEBFB.3070209@xilinx.com \
--to=michal.simek@xilinx.com \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=monstr@monstr.eu \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=shubhraj@xilinx.com \
--cc=soren.brinkmann@xilinx.com \
--cc=suneel.garapati@xilinx.com \
--cc=will.deacon@arm.com \
/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).