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]

Date:	Mon, 27 Oct 2014 20:03:40 +0200
From:	Pantelis Antoniou <pantelis.antoniou@...sulko.com>
To:	Steffen Trumtrar <s.trumtrar@...gutronix.de>
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

Hi Steffen,

> On Oct 27, 2014, at 20:00 , Steffen Trumtrar <s.trumtrar@...gutronix.de> wrote:
> 
> 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.
> 
> 

Ohh, I see. Sorry for the confusion.

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

Thanks. /me throws it at the pile of things to read…


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

Regards

— Pantelis

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