From: John Linn <John.Linn@xilinx.com>
To: Josh Cartwright <josh.cartwright@ni.com>,
Michal Simek <michals@xilinx.com>
Cc: "arm@kernel.org" <arm@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Nick Bowler <nbowler@elliptictech.com>
Subject: RE: [PATCH v4 1/5] zynq: use GIC device tree bindings
Date: Thu, 8 Nov 2012 00:38:34 +0000 [thread overview]
Message-ID: <0b8fc3e2-e9b7-467f-a681-2fba45b68425@CH1EHSMHS015.ehs.local> (raw)
In-Reply-To: <20121107141759.GA1718@beefymiracle.amer.corp.natinst.com>
> -----Original Message-----
> From: Josh Cartwright [mailto:josh.cartwright@ni.com]
> Sent: Wednesday, November 07, 2012 6:18 AM
> To: Michal Simek
> Cc: arm@kernel.org; Arnd Bergmann; linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> John Linn; Nick Bowler
> Subject: Re: [PATCH v4 1/5] zynq: use GIC device tree bindings
>
> On Wed, Nov 07, 2012 at 01:05:57PM +0100, Michal Simek wrote:
> > 2012/11/5 Josh Cartwright <josh.cartwright@ni.com>:
> [..]
> > > Our usecase may admittedly be a bit weird, because what logic is in the
> > > PL is ultimately determined (and even implemented) by the end user and
> > > is loaded at runtime. There is a lot of machinery to make that happen,
> > > but the point is that I don't have sufficient knowledge upfront to
> > > generate appropriate bindings for what's in the PL.
> >
> > ok. It means that you need to use just the part of DTS without PL logic at all.
> > Does it mean that PL will be connected with any DTS fragment?
>
> Yes. For the time being, this is true. We have our own mechanisms for
> enumerating IP at runtime.
>
> > > > > Having a dtsi allows for easy extension of the zynq-7000
> > > > > platform for our boards, without having to carry duplicate data.
> > > >
> > > > ok. I think that make sense if you send the next your series as
> > > > RFC to see how exactly you would like to use it.
> > >
> > > It seems like you caught a glimpse of this in my COMMON_CLK
> > > patchset. :)
> >
> > Yes. Just need to get some time to analyze it.
> >
> [..]
> > > I wouldn't be as opposed to device tree generation if the device tree
> > > generator was in tree.
> >
> > Which tree do you exactly mean? Linux kernel or just any git tree?
>
> No, I mean in the upstream Linux kernel tree. I don't think this is
> likely to happen. My point here is that the generator necessarily has a
> dependency on how the bindings are written. If those bindings change
> (or new bindings are added), the generator must be updated to generate
> device trees according to the new bindings.
>
> I fail to see how these changes are handled with your generator.
>
> > Let me give you more information about the generator. It uses TCL in SDK
> > where it provides all structure from the system. It means device-tree generator
> > will read all information from design tool and based on that will generate
> > DTS file. It also means if user will setup specific irq lines in design, special
> > paramters setting in registers then all these values will be added to DTS.
> >
> > > Device tree bindings change, how would/could an out-of-tree
> > > generator possibly handle changes in bindings?
> >
> > What do you mean by that? Any example?
>
> Yes, I have a real life example. In 3.2 (?), GIC bindings were added to
> the kernel. It was necessary for us to update our board descriptions to
> reflect the new #interrupt-cells = <3>; and figure out the appropriate
> interrupt numbers (which differed from how they were specified before).
>
> How would your generator have known whether or not I was targetting a
> kernel with the GIC bindings, and appropriately generate the GIC node,
> and generate interruptspecs for all children with #interrupt-cells = <3>?
>
Hi Josh,
Yes we see this problem coming too.
> Or, maybe another example: say clk bindings are added to the upstream
> kernel, and I would like to use a kernel that contains them on my board.
> Say this has all happened before Xilinx has even released a new version
> of their SDK. How could I use your dts generator to output proper clk
> nodes in my dts?
>
> It seems the only way that Xilinx can possibly handle this is to tightly
> couple the version of the kernel and their generator.
>
> With increasing support for Zynq in the mainline kernel tree, it may
> become more palatable for some existing users to switch to using the
> upstream kernel instead of the Xilinx tree for their boards, and
> coupling between the generator and target kernel version will be broken.
>
> [..]
> > > It is odd to me that the use of a generator would be required to create
> > > what is completely static data. What I'm referring to here is the
> > > collection of peripherals on the zynq-7000 that are not in the PL. For
> > > me, this requirement adds an unnecessary dependency on the Xilinx EDK
> > > that I would like to avoid.
> >
> > I am not saying that you need to use it. If you want to write your DTS
> > by hand, you still can but I expect that the most of zynq users will
> > use generator and generate it because it is just easier than to
> > describe it by hand and they can be sure that all parameters are
> > correctly generated.
>
> Again, you can only make this assurance _for a specific version of the
> kernel_. If a user is not using the version of the kernel that came
> with the SDK (and, maybe instead using a vanilla upstream kernel), all
> bets are off.
>
> > If you are using any non-standard solution where you will load pl
> > logic at runtime then you can use just generated DTS for hardblock or
> > write it by hand.
>
> I choose 'write it by hand'. I want what I write by hand to also be
> useful to others by including the zynq-7000.dtsi in the upstream kernel.
Yes agreed.
>
> [..]
> > If you want to use solution with several dtsi files and compose it as
> > you describe then it is completely fine but forcing others to use this
> > structure and write dts by hand will be big pain for a lot of users.
>
> Using a composed model in the upstream kernel doesn't force anything
> upon the existing users of your generator. They can still use whatever
> gets spit out of your generator (assuming it generates nodes with
> appropriate bindings). Unless I'm missing something here.
>
> > Also in design tools you can setup if you use qspi,nor,nand flash
> > memory interface.
> > memory interface, baudrates, dma, ports to PL logic, connections, etc.
> > and from my point of view is very complicated to describe it by
> >
> > There are a lot of combination which you can have on one reference
> > board. You can't enable all hard IPs at one time and use all of them
> > that's why you shouldn't list all of them in the kernel.
>
> I disagree with this. In my opinion, all of the "hard IPs" should be
> described in the zynq-7000.dtsi, and those nodes which aren't available
> explicitly disabled in the board-specific file.
It looks like most everyone is doing this in their device trees.
>
> > From my point of view make sense to have one DTS file in the kernel
> > and one defconfig for the most popular zynq board where will be
> > exactly written that this DTS is connected to this reference hw
> > design. If you want to get more reference design go to this page and
> > download it. Adding all DTSes for zynq boards to the kernel is
> > overkill. If you want to use your hw design you can use this
> > generator and generate it or write it by hand.
>
> All I'm asking for is for there to be a common zynq-7000.dtsi that
> describes all of the static PS logic ("hard IPs") in the upstream kernel
> source that I can include in my own (hand maintained) board
> descriptions. It would be nice if there was an example of its use, like
> with a zc702 board file also upstream, but it is not really important to
> me.
>
Yes I understand and see the benefits too.
> I do not want a dependency on the EDK.
>
Understood and it makes sense what you're saying.
> My request does not sound unreasonable to me and is what other platforms
> are doing.
>
Agreed. We'll wrestle with this some more within Xilinx.
Thanks,
John
> Josh
next prev parent reply other threads:[~2012-11-08 0:38 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-24 20:02 [PATCH v4 0/5] zynq subarch cleanups Josh Cartwright
2012-10-24 20:03 ` [PATCH v4 1/5] zynq: use GIC device tree bindings Josh Cartwright
2012-10-27 13:39 ` Michal Simek
2012-10-27 14:00 ` Josh Cartwright
2012-10-27 14:06 ` Michal Simek
2012-10-27 14:42 ` Josh Cartwright
2012-10-27 15:20 ` Michal Simek
2012-11-05 18:35 ` Josh Cartwright
2012-11-07 12:05 ` Michal Simek
2012-11-07 14:17 ` Josh Cartwright
2012-11-08 0:38 ` John Linn [this message]
2012-10-24 20:03 ` [PATCH v4 2/5] zynq: use pl310 " Josh Cartwright
2012-10-27 13:40 ` Michal Simek
2012-10-24 20:04 ` [PATCH v4 3/5] zynq: remove use of CLKDEV_LOOKUP Josh Cartwright
2012-10-27 16:47 ` Michal Simek
2012-10-24 20:04 ` [PATCH v4 4/5] ARM: annotate VMALLOC_END definition with _AC Josh Cartwright
2012-10-27 13:59 ` Michal Simek
2012-10-30 22:22 ` Arnd Bergmann
2012-10-31 8:43 ` Michal Simek
2012-10-31 11:36 ` Josh Cartwright
2012-10-24 20:04 ` [PATCH v4 5/5] zynq: move static peripheral mappings Josh Cartwright
2012-10-25 20:17 ` Nick Bowler
2012-10-25 21:29 ` Josh Cartwright
2012-10-25 22:41 ` Nick Bowler
2012-10-25 22:47 ` [PATCH] ARM: zynq: Allow UART1 to be used as DEBUG_LL console Nick Bowler
2012-10-29 16:56 ` Josh Cartwright
2012-10-29 18:13 ` Nick Bowler
2012-10-26 1:03 ` [PATCH v4 5/5] zynq: move static peripheral mappings Josh Cartwright
2012-10-27 16:52 ` Michal Simek
2012-10-28 23:26 [PATCH v4 0/5] zynq subarch cleanups Josh Cartwright
2012-10-18 0:46 ` [PATCH v4 1/5] zynq: use GIC device tree bindings Josh Cartwright
2012-10-29 7:59 ` Michal Simek
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=0b8fc3e2-e9b7-467f-a681-2fba45b68425@CH1EHSMHS015.ehs.local \
--to=john.linn@xilinx.com \
--cc=arm@kernel.org \
--cc=arnd@arndb.de \
--cc=josh.cartwright@ni.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michals@xilinx.com \
--cc=nbowler@elliptictech.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).