linux-kernel - Re: [PATCH v2 2/3] ARM: dts: socfpga: fpga bridges bindings docs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20141027180049.GY10262@pengutronix.de>
Date:	Mon, 27 Oct 2014 19:00:49 +0100
From:	Steffen Trumtrar <s.trumtrar@...gutronix.de>
To:	Pantelis Antoniou <pantelis.antoniou@...sulko.com>
Cc:	Mark Brown <broonie@...nel.org>, atull@...nsource.altera.com,
	jgunthorpe@...idianresearch.com, hpa@...or.com,
	Michal Simek <monstr@...str.eu>, michal.simek@...inx.com,
	rdunlap@...radead.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	devicetree@...r.kernel.org, robh+dt@...nel.org,
	Grant Likely <grant.likely@...aro.org>, iws@...o.caltech.edu,
	linux-doc@...r.kernel.org, Pavel Machek <pavel@...x.de>,
	philip@...ister.org, rubini@...dd.com, jason@...edaemon.net,
	kyle.teske@...com, nico@...aro.org, Felipe Balbi <balbi@...com>,
	m.chehab@...sung.com, davidb@...eaurora.org,
	Rob Landley <rob@...dley.net>, davem@...emloft.net,
	cesarb@...arb.net, sameo@...ux.intel.com,
	akpm@...ux-foundation.org,
	Linus Walleij <linus.walleij@...aro.org>,
	mgerlach@...nsource.altera.com,
	Alan Tull <delicious.quinoa@...il.com>,
	dinguyen@...nsource.altera.com, yvanderv@...nsource.altera.com
Subject: Re: [PATCH v2 2/3] ARM: dts: socfpga: fpga bridges bindings docs

On Mon, Oct 27, 2014 at 05:45:03PM +0200, Pantelis Antoniou wrote:
> Hi Stefan,
> 
> > On Oct 27, 2014, at 17:32 , Steffen Trumtrar <s.trumtrar@...gutronix.de> wrote:
> > 
> > On Mon, Oct 27, 2014 at 05:05:29PM +0200, Pantelis Antoniou wrote:
> >> Hi Mark,
> >> 
> >>> On Oct 27, 2014, at 17:01 , Mark Brown <broonie@...nel.org> wrote:
> >>> 
> >>> On Mon, Oct 27, 2014 at 01:48:02PM +0200, Pantelis Antoniou wrote:
> >>>>> On Oct 24, 2014, at 02:51 , atull@...nsource.altera.com wrote:
> >>> 
> >>>>> + - init-val         : 0 if driver should disable bridge at startup
> >>>>> +                      1 if driver should enable bridge at startup
> >>>>> +                      driver leaves bridge in current state if property not
> >>>>> +		      specified.
> >>> 
> >>>> Isn’t init-val a boolean property? It’s not named very well.
> >>> 
> >>> It's not boolean, it's tristate - turn on, turn off or don't touch.
> >>> 
> >> 
> >> I see. Even then ‘init-val’ is cryptic. I’d prefer two booleans,
> >> enable-at-startup; disable-at-startup.
> >> 
> >>>> Along with the label, is kinda hard to defend as configuration in DT.
> >>> 
> >>> Yeah...  presumably this decision would fall out of the users?
> >> 
> >> Well, it’s the user that should make the decision, but the driver should
> >> pick it up. This works but it’s not very nice.
> >> 
> > 
> > Hm, convince me why this AXI bus is so special, that I even need an
> > "init-val" property? Other buses don't have that.
> > Why don't I add a property "init-val" to my SPI buses, so I can enable
> > it in the DT and still have it in reset, just because....
> > 
> > The bridges on the SoCFPGA are buses, from the HPS to the FPGA. If I have
> > written firmware to the FPGA and I have subnodes on that bus, I have to
> > get it out of reset and probe everything. Normal procedure, no ?!
> > 
> 
> Well, it’s not my speciality, but my understanding is that FPGAs take (considerable)
> time to be programmed. If someone has already configured the ‘bus’ it is considered
> a win to not reload the bitstream. I.e. if you boot with the bootloader having loaded
> the bitstream already, you don’t want to do it again.
> 
> I’m afraid there’s no such analogue with standard hardware busses like SPI, where
> the bus setup time is instantaneous.

Ah, okay. I see why you got confused.
The bridges are not in any way responsible for loading the FPGA nor will
resetting them reset the bitstream.

The FPGA Manager, a different IP core, is responsible for that. And AFAIK
it has a status bit, that tells you if the FPGA is programmed or not.
Loading the bitstream is in the order of milliseconds.

So from the bridges point of view, when you probe it, you can ask the
FPGA manager if is done, otherwise -EPROBE_DEFER and than go on and
probe the subdevices.


If you are bored, take a look at
http://www.altera.com/literature/hb/cyclone-v/cv_54004.pdf
page 7-2. There you can see the hardware setup.

Regards,
Steffen


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/