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@xxxxxxxxxxxxxx> wrote: > > > > Hi! > > > > On Thu, Oct 23, 2014 at 06:51:06PM -0500, atull@xxxxxxxxxxxxxxxxxxxxx wrote: > >> From: Alan Tull <atull@xxxxxxxxxxxxxxxxxxxxx> > > > > (...) > > > >> 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. 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. > 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 ;-)) 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 devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
