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

[Steffen Trumtrar <s.trumtrar@pengutronix.de>]

Hi!

On Mon, Oct 27, 2014 at 01:54:20PM +0200, Pantelis Antoniou wrote:
> Hi Stefen,
> 
> > On Oct 25, 2014, at 17:42 , Steffen Trumtrar <s.trumtrar@pengutronix.de> wrote:
> > 
> > Hi Pantelis!
> > 
> > On Fri, Oct 24, 2014 at 12:20:53PM +0300, Pantelis Antoniou wrote:
> >> Hi Stefan, Allan,
> >> 
> >> Sorry, haven’t had a chance to review all this yet; will do so in the weekend.
> >> Just wanted to pop in and comment on a few things.
> >> 
> >>> On Oct 24, 2014, at 10:00 AM, Steffen Trumtrar <s.trumtrar@pengutronix.de> wrote:
> >>> 
> >>> Hi!
> >>> 
> >>> On Thu, Oct 23, 2014 at 06:51:06PM -0500, atull@opensource.altera.com wrote:
> >>>> From: Alan Tull <atull@opensource.altera.com>
> >>> 
> >>> (...)
> >>> 
> >>>> diff --git a/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
> >>>> new file mode 100644
> >>>> index 0000000..bc24a2e
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
> >>>> @@ -0,0 +1,53 @@
> >>>> +Altera FPGA/HPS Bridge Driver
> >>>> +
> >>>> +This driver manages a bridge between a FPGA and a host processor system (HPS).
> >>>> +User space can enable or disable the bridge by writing a "1" or a "0",
> >>>> +respectively, to its enable file under bridge's entry in
> >>>> +/sys/class/fpga-bridge.  Typically, one disables the bridges before
> >>>> +reprogramming the FPGA.  Once the FPGA is reprogrammed, the bridges are
> >>>> +reenabled.
> >>>> +
> >>> 
> >>> NAK.
> >>> 
> >>> This is all linux specific and doesn't belong here.
> >>> 
> >> 
> >> We know. The DT spec hasn’t been updated for a while, and this is going to be
> >> part of what we want to do with the restarting of the ePAPR spec process.
> >> 
> > 
> > As we don't have a new spec yet, I go with the current state of the art.
> > And I don't see how "file under ... /sys/class/fpga-bridge" fits the
> > current spec.
> > 
> >> So absolutes like “DT is a hardware description only" might be too strong statements, that
> >> do not work in practice anymore.
> >> 
> >> There’s no such thing as pure hardware devices lately - there is always a configuration
> >> component; some of it OS specific, some of it not.
> >> 
> > 
> > If it really is necessary, I'm not against it, don't get me wrong.
> > But in the grand scheme I wouldn't say that this fits my experience.
> > There are some devices that need configuration and often when it is
> > done in the DT, it is just a shortcut or not thought through.
> > And can be also introspected dynamically. With some discussion on the
> > list these bindings often change.
> > 
> 
> Already answered and given a possible way this might work; admittedly this
> specific example is not a good fit for what I was trying to say, but whatever.
> Let’s get the ball rolling.
> 

I would be okay with chosen-node. Not for this driver; but in general.

> > Regarding OS specifics: already there, e.g. console setup in the chosen node.
> > And other things I saw are ethernet aliases just for u-boot. Not a problem
> > of the spec, just a problem of u-boot and unneccessary "configuration".
> > Just to fix a bad bootloader. barebox can handle this without any
> > such stuff. Maybe we should integrate the DT "overlays" barebox uses into
> > the in-kernel DTs as well...but does it really help/interest someone who
> > decides to use u-boot where barebox stores its environment? I guess not.
> > 
> 
> Although I’m not against having DT overlays in the bootloader, I only see them
> as a method that helps a platform developer express things easier. I am completely
> against having the kernel tied to any particular bootloader.
> 
> We’ve all been through the hell where a kernel only boots if the bootloader has 
> setup the platform “correctly”. This “correctly” has a very loose definition and
> 99/100 times is extremely badly documented or not at all.
> 
> IMHO the bootloader should (as part of the normal boot sequence) only setup the
> absolutely bare minimum and then pass control to the kernel as soon as possible.
> 
> The full featured bootloader environment should only be presented when the user
> requests so.
> 

Totally agree. The kernel shouldn't be tied to any bootloader if at all possible
(the SoCFPGA is an especially bad example here again, as the pinmuxing can only
happen in the bootloader).
But should the DT include stuff than, that is only interesting for linux?

> >> We have to be engaged in the process and figure out how to update the spec for what is
> >> now the state of the art in the industry.
> >> 
> > 
> > Again, not against that if it is necessary. For example your overlay stuff might
> > be a good update to the spec. Would be better if it is official instead of a "hack".
> > I want that for SoCFPGA.
> > 
> > But having looked at one or two vendor kernels+DTs, the state of the art in the
> > industry is: using DT wrong. (And doing HW wrong, which makes some updates to the
> > ePAPR necessary ;-))
> > 
> 
> Vendor H/W, vendor DT and a crack pipe. Or as I call it Monday.
> 

;-)

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 |