lkml.org 
[lkml]   [2014]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2 2/3] ARM: dts: socfpga: fpga bridges bindings docs
    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.

    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 linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2014-10-25 22:01    [W:3.898 / U:0.448 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site