Hi Stefen, > On Oct 25, 2014, at 17:42 , Steffen Trumtrar <s.trumtrar@xxxxxxxxxxxxxx> 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@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. > 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. > 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. >> 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 Regards — Pantelis -- 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
