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

[Steffen Trumtrar]

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@xxxxxxxxxxxxxx> 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@xxxxxxxxxx> wrote:
> >>> 
> >>> On Mon, Oct 27, 2014 at 01:48:02PM +0200, Pantelis Antoniou wrote:
> >>>>> On Oct 24, 2014, at 02:51 , atull@xxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/