linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Simek <michal.simek@xilinx.com>
To: Josh Cartwright <josh.cartwright@ni.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>,
	John Linn <linnj@xilinx.com>,
	Nick Bowler <nbowler@elliptictech.com>
Subject: RE: [PATCH v4 1/5] zynq: use GIC device tree bindings
Date: Sat, 27 Oct 2012 15:20:59 +0000	[thread overview]
Message-ID: <60e4cbf9-52b4-4c02-8537-ecd3a7dbbf06@CO1EHSMHS020.ehs.local> (raw)
In-Reply-To: <20121027144253.GC5190@beefymiracle.amer.corp.natinst.com>



> -----Original Message-----
> From: Josh Cartwright [mailto:josh.cartwright@ni.com]
> Sent: Saturday, October 27, 2012 4:43 PM
> 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 Sat, Oct 27, 2012 at 02:06:45PM +0000, Michal Simek wrote:
> [...]
> > I am not big fan to use dtsi solution because dts can be simple
> > generated directly From Xilinx design tool based on your hw design.
> > That's why I can't see any benefit To have dtsi file.
> 
> Can I ask you to reconsider? 

I am open to all solution which will help others. I am not definitely saying NO   for this features
I just haven't found a reason to support it.  

> We, for example, don't make any use of the Xilinx
> dev tools to generate our device trees.

Ok. How does your working flow looks like?
I mean you don't get any information from hardware guys how does your hw design look like?

>  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. 

In my workflow we generate DTS directly from design tool which I expect your hw
guys use because it is probably needed to generate boot.bin/fsbl/etc. 
Then there is one more additional step to setup device-tree bsp to generate DTS
which directly fits to your HW design. 
If you have the same boards with different programmable logic I understand
that you would like to share that PS part and then just add it that IPs in PL.

 
> Is it going to be expected that users building kernels for their zynq targets have
> access to the Xilinx EDK?

Definitely not. You can do it just once and of course you can write it by hand
and then just reusing. 

>From my point of view. You have to use design tools at least once to get bitstream
and boot.bin with fsbl. Please correct me if I am wrong.
In this step you can use device-tree BSP to generate DTS ( I doesn't need to be perfect with 
all attached devices on i2c,spi, phys, etc but it reflects your hardware).
You will get it in some seconds and your dts has correct irq numbers/ip description, compatible strings,
addresses, position in the system - if you use bus bridges, etc) and you can just directly use it
and kernel will boot. If you need to do changes in dts by hand, you can of course do it. 

> > > Would you like for me to pull this into v5, or spin up a separate patch series?
> >
> > Definitely not. I have checked patches but haven't got it work on the zc702.
> > Not sure if you have run it on real hw or just on the qemu as you have
> > mentioned In 5/5.
> 
> You're likely running into the issue Nick has identified in the thread for patch 5
> where the chosen virtual address for the uart doesn't seem to work:
> http://www.spinics.net/lists/arm-kernel/msg203141.html
> 
> We haven't yet identified the root cause; any insight you can provide here
> would be beneficial.
> 
> Otherwise, I'm considering reworking patch 5 to move the uart mapping to a
> known working location.

I just need to get some time to catch you.

thanks,
Michal



  reply	other threads:[~2012-10-27 15:21 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 [this message]
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
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=60e4cbf9-52b4-4c02-8537-ecd3a7dbbf06@CO1EHSMHS020.ehs.local \
    --to=michal.simek@xilinx.com \
    --cc=arm@kernel.org \
    --cc=arnd@arndb.de \
    --cc=josh.cartwright@ni.com \
    --cc=linnj@xilinx.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --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).