Re: [PATCH v20 06/10] fpga: add fpga bridge framework

[atull]

On Mon, 17 Oct 2016, Alan Tull wrote:

> +/**
> + * of_fpga_bridge_get - get an exclusive reference to a fpga bridge
> + *
> + * @np: node pointer of a FPGA bridge
> + * @info: fpga image specific information
> + *
> + * Return fpga_bridge struct if successful.
> + * Return -EBUSY if someone already has a reference to the bridge.
> + * Return -ENODEV if @np is not a FPGA Bridge.
> + */
> +struct fpga_bridge *of_fpga_bridge_get(struct device_node *np,
> +struct fpga_image_info *info)
> +
> +{
> + struct device *dev;
> + struct fpga_bridge *bridge;
> + int ret = -ENODEV;
> +
> + of_node_get(np);

I thought I had fixed this.  This of_node_get is unmatched,
never called in fpga_bridge_put.  And it's not necessary
since class_find_device will do kobject_get on the child
device anyway.  So I should remove this of_node_get
and the of_node_put below.

> +
> + dev = class_find_device(fpga_bridge_class, NULL, np,
> + fpga_bridge_of_node_match);
> + if (!dev)
> + goto err_dev;
> +
> + bridge = to_fpga_bridge(dev);
> + if (!bridge)
> + goto err_dev;
> +
> + bridge->info = info;
> +
> + if (!mutex_trylock(&bridge->mutex)) {
> + ret = -EBUSY;
> + goto err_dev;
> + }
> +
> + if (!try_module_get(dev->parent->driver->owner))
> + goto err_ll_mod;
> +
> + dev_dbg(&bridge->dev, "get\n");
> +
> + return bridge;
> +
> +err_ll_mod:
> + mutex_unlock(&bridge->mutex);
> +err_dev:
> + put_device(dev);
> + of_node_put(np);

Remove of_node_put.

> + return ERR_PTR(ret);
> +}
> +EXPORT_SYMBOL_GPL(of_fpga_bridge_get);
> +
> +/**
> + * fpga_bridge_put - release a reference to a bridge
> + *
> + * @bridge: FPGA bridge
> + */
> +void fpga_bridge_put(struct fpga_bridge *bridge)
> +{
> + dev_dbg(&bridge->dev, "put\n");
> +
> + bridge->info = NULL;
> + module_put(bridge->dev.parent->driver->owner);
> + mutex_unlock(&bridge->mutex);
> + put_device(&bridge->dev);
> +}
> +EXPORT_SYMBOL_GPL(fpga_bridge_put);
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v20 02/10] doc: fpga-mgr: add fpga image info to api

[atull]

On Mon, 17 Oct 2016, Moritz Fischer wrote:

> Hi Alan,
> 
> couple of nits inline and some comments on ordering the patches ;-)
> 
> On Mon, Oct 17, 2016 at 6:09 PM, Alan Tull  
> wrote:
> > This patch adds a minor change in the FPGA Mangager API
> 
> s/Mangager/Manager/

Yup!

> 
> > to hold information that is specific to an FPGA image
> > file.  This change is expected to bring little, if any,
> > pain.
> >
> > An FPGA image file will have particulars that affect how the
> > image is programmed to the FPGA.  One example is that
> > current 'flags' currently has one bit which shows whether the
> > FPGA image was built for full reconfiguration or partial
> > reconfiguration.  Another example is timeout values for
> > enabling or disabling the bridges in the FPGA.  As the
> > complexity of the FPGA design increases, the bridges in the
> > FPGA may take longer times to enable or disable.
> 
> According for the current ordering bridges are not yet defined if we
> merge patches in this order?
> Not terrible imho, but I thought I'd point it out. Would swapping the
> order make sense?

Probably, yes.

> 
> I also think [5/10] should be squashed together with this commit to
> make it an atomic change.

So far my bindings and code have gone in separately.
Bindings through Rob and code through Greg KH or Dinh.

> 
> Apart from my comments above feel free to add my Acked-by
> 
> Thanks for keeping this going,
> 
> Moritz
> 

Thanks for all the code reviews!

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v20 03/10] add bindings document for altera freeze bridge

[atull]

On Tue, 18 Oct 2016, Rob Herring wrote:

> On Mon, Oct 17, 2016 at 11:09:34AM -0500, Alan Tull wrote:
> > Add bindings document for the Altera Freeze Bridge.  A Freeze
> > Bridge is used to gate traffic to/from a region of a FPGA
> > such that that region can be reprogrammed.  The Freeze Bridge
> > exist in FPGA fabric that is not currently being reconfigured.
> > 
> > Signed-off-by: Alan Tull 
> > Signed-off-by: Matthew Gerlach 
> > ---
> > v19: Added in v19 of patchset, uses fpga image info struct
> > v20: fix one underscore to hyphen
> > ---
> >  .../bindings/fpga/altera-freeze-bridge.txt | 23 
> > ++
> >  1 file changed, 23 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/fpga/altera-freeze-bridge.txt
> 
> Acked-by: Rob Herring 
> 

Thanks!

Alan

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v20 10/10] fpga-manager: Add Socfpga Arria10 support

[atull]

On Tue, 18 Oct 2016, Moritz Fischer wrote:

> On Mon, Oct 17, 2016 at 11:09:41AM -0500, Alan Tull wrote:
> > Add low level driver to support reprogramming FPGAs for Altera
> > SoCFPGA Arria10.
> > 
> > Signed-off-by: Alan Tull 
> 
> Reviewed-by: Moritz Fischer 

> > +
> > +MODULE_AUTHOR("Alan Tull ");
> > +MODULE_DESCRIPTION("SoCFPGA Arria10 FPGA Manager");
> > +MODULE_LICENSE("GPL v2");
> > -- 
> > 2.10.1
> > 
> 
> Looking good,
> 
> Moritz
> 

Hi Moritz,

Thanks!

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v17 2/6] ARM: socfpga: add bindings document for fpga bridge drivers

[atull]

On Sat, 5 Mar 2016, Rob Herring wrote:

> On Thu, Feb 25, 2016 at 05:25:07PM -0600, Alan Tull wrote:
> > Add bindings documentation for Altera SOCFPGA bridges:
> >  * fpga2sdram
> >  * fpga2hps
> >  * hps2fpga
> >  * lwhps2fpga
> > 
> > Signed-off-by: Alan Tull 
> > Signed-off-by: Matthew Gerlach 
> > Signed-off-by: Dinh Nguyen 
> > ---
> > v2:  separate into 2 documents for the 2 drivers
> > v12: bump version to line up with simple-fpga-bus version
> >  remove Linux specific notes such as references to sysfs
> >  move non-DT specific documentation elsewhere
> >  remove bindings that would have been used to pass configuration
> >  clean up formatting
> > v13: Remove 'label' property
> >  Change property from init-val to bridge-enable
> >  Fix email address
> > v14: Add resets
> >  Change order of bridges to put lw bridge (controlling bridge) first
> > v15: No change in this patch for v15 of this patch set
> > v16: Added regs property, cleaned up unit addresses
> > v17: No change to this patch in v17 of patch set
> > ---
> >  .../bindings/fpga/altera-fpga2sdram-bridge.txt |   15 +++
> >  .../bindings/fpga/altera-hps2fpga-bridge.txt   |   47 
> > 
> >  2 files changed, 62 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
> >  create mode 100644 
> > Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
> 
> Just a few minor things.
> 
> > diff --git 
> > a/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt 
> > b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
> > new file mode 100644
> > index 000..4479a79
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
> > @@ -0,0 +1,15 @@
> > +Altera FPGA To SDRAM Bridge Driver
> > +
> > +Required properties:
> > +- compatible   : Should contain 
> > "altr,socfpga-fpga2sdram-bridge"
> > +
> > +Optional properties:
> > +- bridge-enable: 0 if driver should disable bridge at startup
> > + 1 if driver should enable bridge at startup
> > + Default is to leave bridge in current state.
> > +
> > +Example:
> > +   fpga2sdram_br {
> 
> fpga-bridge@??

The hardware is messy here as the control of this bridge is
lumped into the sdram controller.  I could give the address
of the one register that enables/disable the bridge here.

> 
> > +   compatible = "altr,socfpga-fpga2sdram-bridge";
> > +   bridge-enable = <0>;
> > +   };
> > 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 000..e6b7474
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
> > @@ -0,0 +1,47 @@
> > +Altera FPGA/HPS Bridge Driver
> > +
> > +Required properties:
> > +- regs : base address and size for AXI bridge module
> > +- compatible   : Should contain one of:
> > + "altr,socfpga-lwhps2fpga-bridge",
> > + "altr,socfpga-hps2fpga-bridge", or
> > + "altr,socfpga-fpga2hps-bridge"
> > +- reset-names  : Should contain one of:
> > + "lwhps2fpga",
> > + "hps2fpga", or
> > + "fpga2hps"
> 
> Names should be the input signal names. Do you need names with only one?

Right, I will use
of_reset_control_get_by_index(dev->of_node, 0) and eliminate
the reset-names here.

> 
> > +- resets   : Phandle and reset specifier for the reset listed in
> > + reset-names
> > +- clocks   : Clocks used by this module.
> > +
> > +Optional properties:
> > +- bridge-enable: 0 if driver should disable bridge at startup.
> > + 1 if driver should enable bridge at startup.
> > + Default is to leave bridge in its current state.
> > +
> > +Example:
> > +   hps_fpgabridge0: fpgabridge@ff40 {
> 
> No underscores.
> 
> fpga-bridge@...

OK, will add these fixes in v18.

> 
> > +   compatible = "altr,socfpga-lwhps2fpga-bridge";
> > +   reg = <0xff40 0x10>;
> > +   resets = <&rst LWHPS2FPGA_RESET>;
> > +   reset-names = "lwhps2fpga";
> > +   clocks = <&l4_main_clk>;
> > +   bridge-enable = <0>;
> > +   };
> > +
> > +   hps_fpgabridge1: fpgabridge@ff50 {
> > +   compatible = "altr,socfpga-hps2fpga-bridge";
> > +   reg = <0xff50 0x1>;
> > +   resets = <&rst HPS2FPGA_RESET>;
> > +   reset-names = "hps2fpga";
> > +   clocks = <&l4_main_clk>;
> > +   bridge-enable = <1>;
> > +   };
> > +
> > +   hps_fpgabridge2: fpgabridge@ff60 {
> > +   compatible = "altr,socfpga-fpga2hps-bridge";
> > +   reg = <0xff60 0x10>;
> > +   resets = <&rst FPGA2HPS_RESET>;
> > +   reset-names = "fpga2hps";
> > +

Re: [PATCH v17 2/6] ARM: socfpga: add bindings document for fpga bridge drivers

[atull]

On Sat, 5 Mar 2016, Rob Herring wrote:

> > +Example:
> > +   hps_fpgabridge0: fpgabridge@ff40 {
> 
> No underscores.
> 
> fpga-bridge@...

Hi Rob,

The dtc is not letting me compile if I use a hyphen in the label.
I think we have to use hyphens in the node names and underscores
in the labels.  So it will end up being:

+   fpga_bridge0: fpga-bridge@ff40 {

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v16 6/6] ARM: socfpga: fpga bridge driver support

[atull]

On Fri, 10 Jun 2016, Trent Piepho wrote:

> On Fri, 2016-02-05 at 15:30 -0600, at...@opensource.altera.com wrote:
> > Supports Altera SOCFPGA bridges:
> >  * fpga2sdram
> >  * fpga2hps
> >  * hps2fpga
> >  * lwhps2fpga
> > 
> > Allows enabling/disabling the bridges through the FPGA
> > Bridge Framework API functions.
> 
> I'm replying to v16 because it exists on gmane, while v17 appears not
> to.  lkml.org's forward feature appears to be broken so I can't reply to
> that message (no way to get message-id).  But v17 of this patch should
> be the same.  If a v18 was posted, I've not been able to find it.

Hi Trent,

Yes, we're up to v17. V18 will be soon, but v16 is good enough for
the purposes of this review.

> > +
> > +#define ALT_L3_REMAP_OFST  0x0
> > +#define ALT_L3_REMAP_MPUZERO_MSK   0x0001
> > +#define ALT_L3_REMAP_H2F_MSK   0x0008
> > +#define ALT_L3_REMAP_LWH2F_MSK 0x0010
> > +
> > +#define HPS2FPGA_BRIDGE_NAME   "hps2fpga"
> > +#define LWHPS2FPGA_BRIDGE_NAME "lwhps2fpga"
> > +#define FPGA2HPS_BRIDGE_NAME   "fpga2hps"
> > +
> > +struct altera_hps2fpga_data {
> > +   const char *name;
> > +   struct reset_control *bridge_reset;
> > +   struct regmap *l3reg;
> > +   /* The L3 REMAP register is write only, so keep a cached value. */
> > +   unsigned int l3_remap_value;
> > +   unsigned int remap_mask;
> > +   struct clk *clk;
> > +};
> > +
> > +static int alt_hps2fpga_enable_show(struct fpga_bridge *bridge)
> > +{
> > +   struct altera_hps2fpga_data *priv = bridge->priv;
> > +
> > +   return reset_control_status(priv->bridge_reset);
> > +}
> > +
> > +static int _alt_hps2fpga_enable_set(struct altera_hps2fpga_data *priv,
> > +   bool enable)
> > +{
> > +   int ret;
> > +
> > +   /* bring bridge out of reset */
> > +   if (enable)
> > +   ret = reset_control_deassert(priv->bridge_reset);
> > +   else
> > +   ret = reset_control_assert(priv->bridge_reset);
> > +   if (ret)
> > +   return ret;
> > +
> > +   /* Allow bridge to be visible to L3 masters or not */
> > +   if (priv->remap_mask) {
> > +   priv->l3_remap_value |= ALT_L3_REMAP_MPUZERO_MSK;
> 
> Doesn't seem like this belongs here.  I realize the write-only register
> is a problem.  Maybe the syscon driver should be initializing this
> value?
> 
> > +
> > +   if (enable)
> > +   priv->l3_remap_value |= priv->remap_mask;
> > +   else
> > +   priv->l3_remap_value &= ~priv->remap_mask;
> > +
> > +   ret = regmap_write(priv->l3reg, ALT_L3_REMAP_OFST,
> > +  priv->l3_remap_value);
> 
> This isn't going work if more than one bridge is used.  Each bridge has
> its own priv and thus priv->l3_remap_value.  Each bridge's priv will
> have just the bit for it's own remap set.  The 2nd bridge to be enabled
> will turn off the 1st bridge when it re-write the l3 register.
> 
> If all the bridges shared a static global to cache the reg, then this
> problem would be a replaced by a race, since nothing would be managing
> concurrent access to that global from the independent bridge devices.
> 
> How about using the already existing regmap cache ability take care of
> this?  Use regmap_update_bits() to update just the desired bit and let
> remap take care of keeping track caching the register and protecting
> access from multiple users.  It should support that and it should
> support write-only registers, with the creator of the regmap (the syscon
> driver in this case) supplying the initial value of the write-only reg.
> Which is where ALT_L3_REMAP_MPUZERO_MSK could go in.

Please correct me if I'm wrong, but I think that regmap supports
the features you are talking about, but not syscon.

One simple solution would be to take l3_remap_value out of the priv
and let it be shared by all h2f bridges.  That involves the least
amount of change.

> 
> 
> > +   }
> > +
> > +   return ret;
> > +}
> > +
> > +static int alt_hps2fpga_enable_set(struct fpga_bridge *bridge, bool enable)
> > +{
> > +   return _alt_hps2fpga_enable_set(bridge->priv, enable);
> > +}
> > +
> > +static const struct fpga_bridge_ops altera_hps2fpga_br_ops = {
> > +   .enable_set = alt_hps2fpga_enable_set,
> > +   .enable_show = alt_hps2fpga_enable_show,
> > +};
> > +
> > +static struct altera_hps2fpga_data hps2fpga_data  = {
> > +   .name = HPS2FPGA_BRIDGE_NAME,
> > +   .remap_mask = ALT_L3_REMAP_H2F_MSK,
> > +};
> 
> Each of these data structs also includes space for all the private data
> field of the drivers' state.  Seems a bit inefficient if only two of
> them are configuration data.  It also means only one device of each type
> can exists.  If one creates two bridges of the same type they'll
> (silently) share a priv data struct and randomly break.  And the config
> data structs can't be const.

Our hardware doesn't conta

Re: [PATCH v16 6/6] ARM: socfpga: fpga bridge driver support

[atull]

On Thu, 28 Jul 2016, Andrea Galbusera wrote:

> On Fri, Jun 10, 2016 at 4:18 AM, Trent Piepho  wrote:
> > On Fri, 2016-02-05 at 15:30 -0600, at...@opensource.altera.com wrote:
> >> Supports Altera SOCFPGA bridges:
> >>  * fpga2sdram
> >>  * fpga2hps
> >>  * hps2fpga
> >>  * lwhps2fpga
> >>
> >> Allows enabling/disabling the bridges through the FPGA
> >> Bridge Framework API functions.
> >
> > I'm replying to v16 because it exists on gmane, while v17 appears not
> > to.  lkml.org's forward feature appears to be broken so I can't reply to
> > that message (no way to get message-id).  But v17 of this patch should
> > be the same.  If a v18 was posted, I've not been able to find it.
> >
> >> diff --git a/drivers/fpga/altera-hps2fpga.c 
> >> b/drivers/fpga/altera-hps2fpga.c
> >> new file mode 100644
> >> index 000..c15df47
> >> --- /dev/null
> >> +++ b/drivers/fpga/altera-hps2fpga.c
> >> @@ -0,0 +1,213 @@
> >> +/*
> >> + * FPGA to/from HPS Bridge Driver for Altera SoCFPGA Devices
> >> + *
> >> + *  Copyright (C) 2013-2015 Altera Corporation, All Rights Reserved.
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify it
> >> + * under the terms and conditions of the GNU General Public License,
> >> + * version 2, as published by the Free Software Foundation.
> >> + *
> >> + * This program is distributed in the hope it will be useful, but WITHOUT
> >> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> >> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License 
> >> for
> >> + * more details.
> >> + *
> >> + * You should have received a copy of the GNU General Public License 
> >> along with
> >> + * this program.  If not, see .
> >> + */
> >> +
> >> +/*
> >> + * This driver manages bridges on a Altera SOCFPGA between the ARM host
> >> + * processor system (HPS) and the embedded FPGA.
> >> + *
> >> + * This driver supports enabling and disabling of the configured ports, 
> >> which
> >> + * allows for safe reprogramming of the FPGA, assuming that the new FPGA 
> >> image
> >> + * uses the same port configuration.  Bridges must be disabled before
> >> + * reprogramming the FPGA and re-enabled after the FPGA has been 
> >> programmed.
> >> + */
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#define ALT_L3_REMAP_OFST0x0
> >> +#define ALT_L3_REMAP_MPUZERO_MSK 0x0001
> >> +#define ALT_L3_REMAP_H2F_MSK 0x0008
> >> +#define ALT_L3_REMAP_LWH2F_MSK   0x0010
> >> +
> >> +#define HPS2FPGA_BRIDGE_NAME "hps2fpga"
> >> +#define LWHPS2FPGA_BRIDGE_NAME   "lwhps2fpga"
> >> +#define FPGA2HPS_BRIDGE_NAME "fpga2hps"
> >> +
> >> +struct altera_hps2fpga_data {
> >> + const char *name;
> >> + struct reset_control *bridge_reset;
> >> + struct regmap *l3reg;
> >> + /* The L3 REMAP register is write only, so keep a cached value. */
> >> + unsigned int l3_remap_value;
> >> + unsigned int remap_mask;
> >> + struct clk *clk;
> >> +};
> >> +
> >> +static int alt_hps2fpga_enable_show(struct fpga_bridge *bridge)
> >> +{
> >> + struct altera_hps2fpga_data *priv = bridge->priv;
> >> +
> >> + return reset_control_status(priv->bridge_reset);
> >> +}
> >> +
> >> +static int _alt_hps2fpga_enable_set(struct altera_hps2fpga_data *priv,
> >> + bool enable)
> >> +{
> >> + int ret;
> >> +
> >> + /* bring bridge out of reset */
> >> + if (enable)
> >> + ret = reset_control_deassert(priv->bridge_reset);
> >> + else
> >> + ret = reset_control_assert(priv->bridge_reset);
> >> + if (ret)
> >> + return ret;
> >> +
> >> + /* Allow bridge to be visible to L3 masters or not */
> >> + if (priv->remap_mask) {
> >> + priv->l3_remap_value |= ALT_L3_REMAP_MPUZERO_MSK;
> >
> > Doesn't seem like this belongs here.  I realize the write-only register
> > is a problem.  Maybe the syscon driver should be initializing this
> > value?
> >
> >> +
> >> + if (enable)
> >> + priv->l3_remap_value |= priv->remap_mask;
> >> + else
> >> + priv->l3_remap_value &= ~priv->remap_mask;
> >> +
> >> + ret = regmap_write(priv->l3reg, ALT_L3_REMAP_OFST,
> >> +priv->l3_remap_value);
> >
> > This isn't going work if more than one bridge is used.  Each bridge has
> > its own priv and thus priv->l3_remap_value.  Each bridge's priv will
> > have just the bit for it's own remap set.  The 2nd bridge to be enabled
> > will turn off the 1st bridge when it re-write the l3 register.
> 
> I can confirm this is exactly what happens with tag
> "rel_socfpga-4.1.22-ltsi_16.06.02_pr" of socfpga-4.1.22-ltsi branch
> from altera-o

Re: [PATCH v16 6/6] ARM: socfpga: fpga bridge driver support

[atull]

On Thu, 28 Jul 2016, Trent Piepho wrote:

> On Thu, 2016-07-28 at 10:21 -0500, atull wrote:
> > > >
> > > > This isn't going work if more than one bridge is used.  Each bridge has
> > > > its own priv and thus priv->l3_remap_value.  Each bridge's priv will
> > > > have just the bit for it's own remap set.  The 2nd bridge to be enabled
> > > > will turn off the 1st bridge when it re-write the l3 register.
> > > 
> > > I can confirm this is exactly what happens with tag
> > > "rel_socfpga-4.1.22-ltsi_16.06.02_pr" of socfpga-4.1.22-ltsi branch
> > > from altera-opensource/linux-socfpga which includes more or less the
> > > code in this patch. If you have 2 bridges (lw-hps2fpga and hps2fpga)
> > > you end up with only one of them being visible. Easily spot by logging
> > > l3_remap_value being passed to regmap_write()...
> > > 
> > 
> > Anatolij kindly provided a patch for this issue.  I'll push it
> > to my github repo when I can.
> 
> I still think a better solution would be to allow the syscon driver
> manage shared access.  The purpose of syscon is to manage access to a
> shared resource from multiple devices.  And regmap already has the
> ability to cache a write-only register and allow thread safe access to
> modify bits in said register.  The problem is just the pain of trying to
> do anything to syscon DT bindings.  Something like "write-only" in the
> syscon binding that sets a couple values in the regmap_config is all
> that's necessary.
> 
> Might as well not use syscon at all and have the bridge driver map the
> l3regs itself, since it doesn't really use syscon for anything.
> 

I agree.  Just need time to do it.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v15 3/6] ARM: socfpga: add bindings document for fpga bridge drivers

[atull]

From: Alan Tull 

Add bindings documentation for Altera SOCFPGA bridges:
 * fpga2sdram
 * fpga2hps
 * hps2fpga
 * lwhps2fpga

Signed-off-by: Alan Tull 
Signed-off-by: Matthew Gerlach 
Signed-off-by: Dinh Nguyen 
---
v2:  separate into 2 documents for the 2 drivers
v12: bump version to line up with simple-fpga-bus version
 remove Linux specific notes such as references to sysfs
 move non-DT specific documentation elsewhere
 remove bindings that would have been used to pass configuration
 clean up formatting
v13: Remove 'label' property
 Change property from init-val to bridge-enable
 Fix email address
v14: Add resets
 Change order of bridges to put lw bridge (controlling bridge) first
v15: No change in this patch for v15 of this patch set
---
 .../bindings/fpga/altera-fpga2sdram-bridge.txt |   15 +++
 .../bindings/fpga/altera-hps2fpga-bridge.txt   |   43 
 2 files changed, 58 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
 create mode 100644 
Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt

diff --git 
a/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt 
b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
new file mode 100644
index 000..81e2f06
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
@@ -0,0 +1,15 @@
+Altera FPGA To SDRAM Bridge Driver
+
+Required properties:
+- compatible   : Should contain "altr,socfpga-fpga2sdram-bridge"
+
+Optional properties:
+- bridge-enable: 0 if driver should disable bridge at startup
+ 1 if driver should enable bridge at startup
+ Default is to leave bridge in current state.
+
+Example:
+   fpga2sdram_br: fpgabridge@3 {
+   compatible = "altr,socfpga-fpga2sdram-bridge";
+   bridge-enable = <0>;
+   };
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 000..16db3b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
@@ -0,0 +1,43 @@
+Altera FPGA/HPS Bridge Driver
+
+Required properties:
+- compatible   : Should contain one of:
+ "altr,socfpga-lwhps2fpga-bridge",
+ "altr,socfpga-hps2fpga-bridge", or
+ "altr,socfpga-fpga2hps-bridge"
+- reset-names  : Should contain one of:
+ "lwhps2fpga",
+ "hps2fpga", or
+ "fpga2hps"
+- resets   : Phandle and reset specifier for the reset listed in
+ reset-names
+- clocks   : Clocks used by this module.
+
+Optional properties:
+- bridge-enable: 0 if driver should disable bridge at startup.
+ 1 if driver should enable bridge at startup.
+ Default is to leave bridge in its current state.
+
+Example:
+   hps_fpgabridge0: fpgabridge@0 {
+   compatible = "altr,socfpga-lwhps2fpga-bridge";
+   resets = <&rst LWHPS2FPGA_RESET>;
+   reset-names = "lwhps2fpga";
+   clocks = <&l4_main_clk>;
+   bridge-enable = <0>;
+   };
+
+   hps_fpgabridge1: fpgabridge@1 {
+   compatible = "altr,socfpga-hps2fpga-bridge";
+   resets = <&rst HPS2FPGA_RESET>;
+   reset-names = "hps2fpga";
+   clocks = <&l4_main_clk>;
+   bridge-enable = <1>;
+   };
+
+   hps_fpgabridge2: fpgabridge@2 {
+   compatible = "altr,socfpga-fpga2hps-bridge";
+   resets = <&rst FPGA2HPS_RESET>;
+   reset-names = "fpga2hps";
+   clocks = <&l4_main_clk>;
+   };
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v15 5/6] fpga: fpga-area and fpga-bus: device tree control for FPGA

[atull]

From: Alan Tull 

FPGA Area and FPGA Bus support programming FPGA under control of
the Device Tree.

A FPGA Bus contains the devices necessary for programming an
FPGA.

When a Device Tree Overlay containing a FPGA Area is
applied, the FPGA Area will be probed and will:
 * check to see if there is an image to program to a FPGA
 * get references to the FPGA manager and bridges if any
 * disable FPGA bridges to prevent spurious data on busses
 * reprogram the FPGA
 * enable the specified FPGA bridges
 * populate the child devices

Removing the Device Tree Overlay is also supported.

This supports fpga use where hardware blocks on a fpga will
need drivers.

Signed-off-by: Alan Tull 
---
v9:  initial version (this patch added during rest of patchset's v9)
v10: request deferral if fpga mgr or bridges not available yet
 cleanup as fpga manager core goes into the real kernel
 Don't assume bridges are disabled before programming FPGA
 Don't hang onto reference for fpga manager
 Move to staging/simple-fpga-bus
v11: No change in this patch for v11 of the patch set
v12: Moved out of staging.
 Use fpga bridges framework.
v13: If no bridges are specified, assume we don't need any.
 Clean up debug messages
 Some dev_info -> dev_dbg
 Remove unneeded #include
 Fix size of array of pointers
 Don't need to specify .owner
 Use common binding: firmware-name
v14: OK it's not a simple bus.  Call it "FPGA Area"
 Remove bindings that specify FPGA manager and FPGA bridges
 Use parent FPGA bridge and bridges that are its peers
 Use ancestor FPGA Manager
v15: Add altr,fpga-bus implementation
 Change compatible string "fpga-area" -> "altr,fpga-area"
---
 drivers/fpga/Kconfig |7 +
 drivers/fpga/Makefile|3 +
 drivers/fpga/fpga-area.c |  352 ++
 3 files changed, 362 insertions(+)
 create mode 100644 drivers/fpga/fpga-area.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index b6cfd89..6ac916b 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -31,6 +31,13 @@ config FPGA_BRIDGE
  Say Y here if you want to support bridges connected between host
 processors and FPGAs or between FPGAs.
 
+config FPGA_AREA
+   bool "Device Tree Based FPGA Reprogramming"
+   depends on FPGA_BRIDGE
+   help
+ Enable FPGA Area which supports programming FPGAs under control of
+Device Tree.
+
 endif # FPGA
 
 endmenu
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 4baef00..4f7e49f 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -11,3 +11,6 @@ obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)  += zynq-fpga.o
 
 # FPGA Bridge Drivers
 obj-$(CONFIG_FPGA_BRIDGE)  += fpga-bridge.o
+
+# High Level Interfaces
+obj-$(CONFIG_FPGA_AREA)+= fpga-area.o
diff --git a/drivers/fpga/fpga-area.c b/drivers/fpga/fpga-area.c
new file mode 100644
index 000..cec332f
--- /dev/null
+++ b/drivers/fpga/fpga-area.c
@@ -0,0 +1,352 @@
+/*
+ * FPGA Tree Area Support for Device Tree controlled FPGA reprogramming
+ *
+ *  Copyright (C) 2013-2015 Altera Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * In the case of a FPGA doing full reconfiguration, the area == the whole
+ * FPGA.  In the case of partial reconfiguration, several areas can be
+ * reconfigured separately.
+ */
+
+/**
+ * struct fpga_area
+ * @mgr:   FPGA Manager
+ * @flags: Flags for reconfiguration
+ * @firmware_name: Name of FPGA image file
+ * @bridge_list: Linked list of FPGA bridges controlled by area
+ * @br:FPGA Bridge corresponding to area
+ * @bus_np:device node of ancestor FPGA Bus
+ */
+struct fpga_area {
+   struct fpga_manager *mgr;
+   u32 flags;
+   const char *firmware_name;
+   struct list_head bridge_list;
+   struct fpga_bridge *br;
+   struct device_node *bus_np;
+};
+
+/**
+ * fpga_area_get_parent_peer_bridges - get bridges that are peers of parent
+ * @area: FPGA Area struct
+ *
+ * Intended to support case where multiple bridges need to be disabled
+ * during FPGA reprogramming.
+ *
+ * Finds the FPGA bridge that is the parent of @area in the device tree.
+ * Creates a linked list of FPGA bridges that includes the parent bridge and
+ * its peers.  Gets an exclusive reference to eac

[PATCH v15 4/6] fpga: add fpga bridge framework

[atull]

From: Alan Tull 

This framework adds API functions for enabling/
disabling FPGA bridges under kernel control.

This allows the Linux kernel to disable FPGA bridges
during FPGA reprogramming and to enable FPGA bridges
when FPGA reprogramming is done.  This framework is
be manufacturer-agnostic, allowing it to be used in
interfaces that use the FPGA Manager Framework to
reprogram FPGA's.

The functions are:
* of_fpga_bridge_get
* fpga_bridge_put
   Get/put an exclusive reference to a FPGA bridge.

* fpga_bridge_enable
* fpga_bridge_disable
   Enable/Disable traffic through a bridge.

* fpga_bridge_register
* fpga_bridge_unregister
   Register/unregister a device-specific low level FPGA
   Bridge driver.

Get an exclusive reference to a bridge and add it to a list:
* fpga_bridge_get_to_list

To enable/disable/put a set of bridges that are on a list:
* fpga_bridges_enable
* fpga_bridges_disable
* fpga_bridges_put

Signed-off-by: Alan Tull 
---
v2:  Minor cleanup
v12: Bump version to line up with simple fpga bus
 Remove sysfs
 Improve get/put functions, get the low level driver too.
 Clean up class implementation
 Add kernel doc documentation
 Rename (un)register_fpga_bridge -> fpga_bridge_(un)register
v13: Add inlined empty functions for if not CONFIG_FPGA_BRIDGE
 Clean up debugging
 Remove unneeded #include in .h
 Remove unnecessary prints
 Remove 'label' DT binding.
 Document the mutex
v14: Allow bridges with no ops
 *const* struct fpga_bridge_ops
 Add functions to git/put/enable/disable list of bridges
 Add list node to struct fpga_bridge
 Do of_node_get/put in of_fpga_bridge_get()
 Add r/o attributes: name and state
v15: No change in this patch for v15 of this patch set
---
 drivers/fpga/Kconfig |7 +
 drivers/fpga/Makefile|3 +
 drivers/fpga/fpga-bridge.c   |  388 ++
 include/linux/fpga/fpga-bridge.h |   56 ++
 4 files changed, 454 insertions(+)
 create mode 100644 drivers/fpga/fpga-bridge.c
 create mode 100644 include/linux/fpga/fpga-bridge.h

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index c9b9fdf..b6cfd89 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -24,6 +24,13 @@ config FPGA_MGR_ZYNQ_FPGA
help
  FPGA manager driver support for Xilinx Zynq FPGAs.
 
+config FPGA_BRIDGE
+   bool "FPGA Bridge Framework"
+   depends on OF
+   help
+ Say Y here if you want to support bridges connected between host
+processors and FPGAs or between FPGAs.
+
 endif # FPGA
 
 endmenu
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 8d83fc6..4baef00 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -8,3 +8,6 @@ obj-$(CONFIG_FPGA)  += fpga-mgr.o
 # FPGA Manager Drivers
 obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
 obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)   += zynq-fpga.o
+
+# FPGA Bridge Drivers
+obj-$(CONFIG_FPGA_BRIDGE)  += fpga-bridge.o
diff --git a/drivers/fpga/fpga-bridge.c b/drivers/fpga/fpga-bridge.c
new file mode 100644
index 000..5119d8e
--- /dev/null
+++ b/drivers/fpga/fpga-bridge.c
@@ -0,0 +1,388 @@
+/*
+ * FPGA Bridge Framework Driver
+ *
+ *  Copyright (C) 2013-2015 Altera Corporation, All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static DEFINE_IDA(fpga_bridge_ida);
+static struct class *fpga_bridge_class;
+
+/* Lock for adding/removing bridges to linked lists*/
+spinlock_t bridge_list_lock;
+
+static int fpga_bridge_of_node_match(struct device *dev, const void *data)
+{
+   return dev->of_node == data;
+}
+
+/**
+ * fpga_bridge_enable - Enable transactions on the bridge
+ *
+ * @bridge: FPGA bridge
+ *
+ * Return: 0 for success, error code otherwise.
+ */
+int fpga_bridge_enable(struct fpga_bridge *bridge)
+{
+   dev_dbg(&bridge->dev, "enable\n");
+
+   if (bridge->br_ops && bridge->br_ops->enable_set)
+   return bridge->br_ops->enable_set(bridge, 1);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(fpga_bridge_enable);
+
+/**
+ * fpga_bridge_disable - Disable transactions on the bridge
+ *
+ * @bridge: FPGA bridge
+ *
+ * Return: 0 for success, error code otherwise.
+ */
+int fpga_bridge_disable(struct fpga_bridge *bridge)
+{
+   dev_dbg(&bridge->dev, "disabl

[PATCH v15 1/6] fpga: add bindings document for fpga area and fpga bus

[atull]

From: Alan Tull 

New bindings document for FPGA Area for reprogramming
FPGA's under Device Tree control

Signed-off-by: Alan Tull 
---
v9:  initial version added to this patchset
v10: s/fpga/FPGA/g
 replace DT overlay example with slightly more complicated example
 move to staging/simple-fpga-bus
v11: No change in this patch for v11 of the patch set
v12: Moved out of staging.
 Changed to use FPGA bridges framework instead of resets
 for bridges.
v13: bridge@0xff2 -> bridge@ff20, etc
 Leave out directly talking about overlays
 Remove regs and clocks directly under simple-fpga-bus in example
 Use common "firmware-name" binding instead of "fpga-firmware"
v14: Use firmware-name in bindings description
 Call it FPGA Area
 Remove bindings that specify FPGA Manager and FPGA Bridges
v15: Cleanup as per Rob's comments
 Combine usage doc with bindings document
 Document as being Altera specific
 Additions and changes to add FPGA Bus
---
 .../bindings/fpga/altera-fpga-bus-fpga-area.txt|  452 
 1 file changed, 452 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/fpga/altera-fpga-bus-fpga-area.txt

diff --git 
a/Documentation/devicetree/bindings/fpga/altera-fpga-bus-fpga-area.txt 
b/Documentation/devicetree/bindings/fpga/altera-fpga-bus-fpga-area.txt
new file mode 100644
index 000..8ea38ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/altera-fpga-bus-fpga-area.txt
@@ -0,0 +1,452 @@
+Altera FPGA Area and FPGA Bus Device Tree Binding
+
+Alan Tull 2016
+
+ CONTENTS
+ - Introduction
+ - Terminology
+ - Overview
+ - Constraints
+ - FPGA Bus
+ - FPGA Area
+ - Supported Use Models
+ - Sequence
+ - Device Tree Examples
+
+
+Introduction
+
+
+FPGA Buses and FPGA Areas are introduced as a way to solve the problem of how 
to
+reprogram an Altera FPGA under an operating system and have the new hardware
+show up in the device tree.  By adding these bindings to the Device Tree, a
+system can have the information needed to do the FPGA programming to add the
+desired hardware, and also the information about the devices to be added to the
+Device Tree once the programming has succeeded.
+
+
+Terminology
+===
+
+Full Reconfiguration
+ * The entire FPGA is programmed.
+
+Partial Reconfiguration (PR)
+ * The FPGA is broken up into regions.  One of these regions is reprogrammed
+   while the rest of the FPGA is not affected.  Not all FPGA's support this.
+
+FPGA Manager & FPGA Manager Framework
+ * An FPGA Manager is a hardware block that programs an FPGA under the control
+   of a host processor.
+ * The FPGA Manager Framework provides drivers and functions to program an
+   FPGA.
+
+FPGA Bridge & FPGA Bridge Framework
+ * Provides drivers and functions to control bridges that enable/disable
+   data to the FPGA.
+ * FPGA Bridges should be disabled while the FPGA is being programmed to
+   prevent spurious data on the bus.
+ * FPGA Bridges may not be needed in implementations where the FPGA Manager
+   handles this.
+
+Freeze Blocks
+ * Freeze Blocks function as FPGA Bridges within the FPGA fabric.  In the case
+   of PR, the buses from the processor are split within the FPGA.  Each PR
+   region gets its own split of the buses, protected by an independently
+   controlled Freeze Block.  Several busses may be connected to a single
+   PR region; a Freeze Block controls the traffic of all these busses
+   together.
+
+Controlling Bridge
+ * The processor and FPGA may be connected by multiple FPGA Bridges.  In a text
+   based hierarchy, it is difficult to show this properly as a device would
+   have several parents.
+ * The bridge that handles register access to the FPGA is designated the
+   "controlling" bridge.
+ * The controlling bridge will be the target point under which the overlay is
+   inserted.
+
+
+Overview
+
+
+This binding introduces the FPGA Bus and FPGA Area.
+
+An FPGA Bus is a virtualized bus that contains the devices needed to be able to
+program an FPGA device.  It contains a child FPGA Manager and may contain child
+FPGA Bridges, if needed.  The FPGA Manager is the hardware block that handles
+programming the FPGA.  FPGA Bridges function to prevent spurious data from the
+FPGA going on the processor busses during FPGA programming.  In the case of
+partial reconfiguration, additional bridges (Freeze Blocks) for each
+reconfiguration region are required.
+
+An FPGA Area contains information about a section of an FPGA (in the case of
+partial reconfiguration or the whole FPGA (for full reconfiguration).  The FPGA
+Area contains the name of the FPGA image file to be programmed and the child
+devices that will be contained in the FPGA after programming.
+
+The intended use is that device tree overlays can be used to add hardware to an
+FPGA while an operating system is running.  In that case, the FPGA Bus and its
+associated information will exist in the live device tree, while F

[PATCH v15 0/6] altera fpga area and fpga bus

[atull]

From: Alan Tull 

For v15, I'm not using the FPGA Manager as the bus.  I'm adding a FPGA Bus;
the FPGA Manager and bridges go below it.

I've gotten enough feedback that my proposals are Altera specific that I am
going with that and changing the bindings to include an 'altr,' prefix.

I've combined the bindings document and the other Documentation/fpga/ document
and done a rewrite there.

Anybody who tried the previous patchset will not have much changes to do to get
this going.  The changes are:
 * The live tree has a 'altr,fpga-bus' which contains the FPGA Manager and
FPGA Bridges.
 * The target path in your overlays needs to be adjusted accordingly.

That said, the changes for each of these submissions is getting to be less and
less; most of these patches are unchanged for v15.

Alan Tull (6):
  fpga: add bindings document for fpga area and fpga bus
  add sysfs document for fpga bridge class
  ARM: socfpga: add bindings document for fpga bridge drivers
  fpga: add fpga bridge framework
  fpga: fpga-area and fpga-bus: device tree control for FPGA
  ARM: socfpga: fpga bridge driver support

 Documentation/ABI/testing/sysfs-class-fpga-bridge  |   11 +
 .../bindings/fpga/altera-fpga-bus-fpga-area.txt|  452 
 .../bindings/fpga/altera-fpga2sdram-bridge.txt |   15 +
 .../bindings/fpga/altera-hps2fpga-bridge.txt   |   43 ++
 drivers/fpga/Kconfig   |   21 +
 drivers/fpga/Makefile  |7 +
 drivers/fpga/altera-fpga2sdram.c   |  174 
 drivers/fpga/altera-hps2fpga.c |  213 +
 drivers/fpga/fpga-area.c   |  352 +++
 drivers/fpga/fpga-bridge.c |  388 +
 include/linux/fpga/fpga-bridge.h   |   56 +++
 11 files changed, 1732 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-fpga-bridge
 create mode 100644 
Documentation/devicetree/bindings/fpga/altera-fpga-bus-fpga-area.txt
 create mode 100644 
Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
 create mode 100644 
Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
 create mode 100644 drivers/fpga/altera-fpga2sdram.c
 create mode 100644 drivers/fpga/altera-hps2fpga.c
 create mode 100644 drivers/fpga/fpga-area.c
 create mode 100644 drivers/fpga/fpga-bridge.c
 create mode 100644 include/linux/fpga/fpga-bridge.h

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v15 6/6] ARM: socfpga: fpga bridge driver support

[atull]

From: Alan Tull 

Supports Altera SOCFPGA bridges:
 * fpga2sdram
 * fpga2hps
 * hps2fpga
 * lwhps2fpga

Allows enabling/disabling the bridges through the FPGA
Bridge Framework API functions.

The fpga2sdram driver only supports enabling and disabling
of the ports that been configured early on.  This is due to
a hardware limitation where the read, write, and command
ports on the fpga2sdram bridge can only be reconfigured
while there are no transactions to the sdram, i.e. when
running out of OCRAM before the kernel boots.

Device tree property 'init-val' configures the driver to
enable or disable the bridge during probe.  If the property
does not exist, the driver will leave the bridge in its
current state.

Signed-off-by: Alan Tull 
Signed-off-by: Matthew Gerlach 
Signed-off-by: Dinh Nguyen 
---
v2:  Use resets instead of directly writing reset registers
v12: Bump version to align with simple-fpga-bus version
 Get rid of the sysfs interface
 fpga2sdram: get configuration stored in handoff register
v13: Remove unneeded WARN_ON
 Change property from init-val to bridge-enable
 Checkpatch cleanup
 Fix email address
v14: use module_platform_driver
 remove unused struct field and some #defines
 don't really need exclamation points on error msgs
 *const* struct fpga_bridge_ops
v15: No change in this patch for v15 of this patch set
---
 drivers/fpga/Kconfig |7 ++
 drivers/fpga/Makefile|1 +
 drivers/fpga/altera-fpga2sdram.c |  174 +++
 drivers/fpga/altera-hps2fpga.c   |  213 ++
 4 files changed, 395 insertions(+)
 create mode 100644 drivers/fpga/altera-fpga2sdram.c
 create mode 100644 drivers/fpga/altera-hps2fpga.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 6ac916b..30ebe42 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -38,6 +38,13 @@ config FPGA_AREA
  Enable FPGA Area which supports programming FPGAs under control of
 Device Tree.
 
+config SOCFPGA_FPGA_BRIDGE
+   bool "Altera SoCFPGA FPGA Bridges"
+   depends on ARCH_SOCFPGA && FPGA_BRIDGE
+   help
+ Say Y to enable drivers for FPGA bridges for Altera SOCFPGA
+ devices.
+
 endif # FPGA
 
 endmenu
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 4f7e49f..3efc132 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)  += zynq-fpga.o
 
 # FPGA Bridge Drivers
 obj-$(CONFIG_FPGA_BRIDGE)  += fpga-bridge.o
+obj-$(CONFIG_SOCFPGA_FPGA_BRIDGE)  += altera-hps2fpga.o altera-fpga2sdram.o
 
 # High Level Interfaces
 obj-$(CONFIG_FPGA_AREA)+= fpga-area.o
diff --git a/drivers/fpga/altera-fpga2sdram.c b/drivers/fpga/altera-fpga2sdram.c
new file mode 100644
index 000..91f4a40
--- /dev/null
+++ b/drivers/fpga/altera-fpga2sdram.c
@@ -0,0 +1,174 @@
+/*
+ * FPGA to SDRAM Bridge Driver for Altera SoCFPGA Devices
+ *
+ *  Copyright (C) 2013-2015 Altera Corporation, All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+/*
+ * This driver manages a bridge between an FPGA and the SDRAM used by the ARM
+ * host processor system (HPS).
+ *
+ * The bridge contains 4 read ports, 4 write ports, and 6 command ports.
+ * Reconfiguring these ports requires that no SDRAM transactions occur during
+ * reconfiguration.  The code reconfiguring the ports cannot run out of SDRAM
+ * nor can the FPGA access the SDRAM during reconfiguration.  This driver does
+ * not support reconfiguring the ports.  The ports are configured by code
+ * running out of on chip ram before Linux is started and the configuration
+ * is passed in a handoff register in the system manager.
+ *
+ * This driver supports enabling and disabling of the configured ports, which
+ * allows for safe reprogramming of the FPGA, assuming that the new FPGA image
+ * uses the same port configuration.  Bridges must be disabled before
+ * reprogramming the FPGA and re-enabled after the FPGA has been programmed.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ALT_SDR_CTL_FPGAPORTRST_OFST   0x80
+#define ALT_SDR_CTL_FPGAPORTRST_PORTRSTN_MSK   0x3fff
+#define ALT_SDR_CTL_FPGAPORTRST_RD_SHIFT   0
+#define ALT_SDR_CTL_FPGAPORTRST_WR_SHIFT   4
+#define ALT_SDR_CTL_FPGAPORTRST_CTRL_SHIFT 8
+
+

[PATCH v15 2/6] add sysfs document for fpga bridge class

[atull]

From: Alan Tull 

Add documentation for new FPGA bridge class's sysfs interface.

Signed-off-by: Alan Tull 
--
v15: Document added in v15 of patch set
---
 Documentation/ABI/testing/sysfs-class-fpga-bridge |   11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-fpga-bridge

diff --git a/Documentation/ABI/testing/sysfs-class-fpga-bridge 
b/Documentation/ABI/testing/sysfs-class-fpga-bridge
new file mode 100644
index 000..312ae2c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-fpga-bridge
@@ -0,0 +1,11 @@
+What:  /sys/class/fpga_bridge//name
+Date:  January 2016
+KernelVersion: 4.5
+Contact:   Alan Tull 
+Description:   Name of low level FPGA bridge driver.
+
+What:  /sys/class/fpga_bridge//state
+Date:  January 2016
+KernelVersion: 4.5
+Contact:   Alan Tull 
+Description:   Show bridge state as "enabled" or "disabled"
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v15 2/6] add sysfs document for fpga bridge class

[atull]

On Wed, 20 Jan 2016, at...@opensource.altera.com wrote:

> From: Alan Tull 
> 
> Add documentation for new FPGA bridge class's sysfs interface.
> 
> Signed-off-by: Alan Tull 

I've received two emails that there was no patch in this email.  The
copy I received has 11 lines of changes, adding one file
Documentation/ABI/testing/sysfs-class-fpga-bridge

Alan

> --
> v15: Document added in v15 of patch set
> ---
>  Documentation/ABI/testing/sysfs-class-fpga-bridge |   11 +++
>  1 file changed, 11 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-fpga-bridge
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-fpga-bridge 
> b/Documentation/ABI/testing/sysfs-class-fpga-bridge
> new file mode 100644
> index 000..312ae2c
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-fpga-bridge
> @@ -0,0 +1,11 @@
> +What:/sys/class/fpga_bridge//name
> +Date:January 2016
> +KernelVersion:   4.5
> +Contact: Alan Tull 
> +Description: Name of low level FPGA bridge driver.
> +
> +What:/sys/class/fpga_bridge//state
> +Date:January 2016
> +KernelVersion:   4.5
> +Contact: Alan Tull 
> +Description: Show bridge state as "enabled" or "disabled"
> -- 
> 1.7.9.5
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v15 0/6] altera fpga area and fpga bus

[atull]

On Thu, 21 Jan 2016, Moritz Fischer wrote:

> Hi Alan,
> 
> On Wed, Jan 20, 2016 at 8:24 PM,   wrote:
> > From: Alan Tull 
> >
> > For v15, I'm not using the FPGA Manager as the bus.  I'm adding a FPGA Bus;
> > the FPGA Manager and bridges go below it.
> >
> > I've gotten enough feedback that my proposals are Altera specific that I am
> > going with that and changing the bindings to include an 'altr,' prefix.
> 
> I hope this wasn't a misunderstanding of one of my earlier remarks. I
> think the fpga-area & fpga bus
> parts do apply to to Xilinx FPGAs, too. I think for fpga-area and
> fpga-bus we could drop the 'altr' prefix.

Yes, I would very much like to drop the altr prefix if we have general
acceptance that this isn't all Altera specific.  I'll need to rename
altera-fpga-bus-fpga-area.txt to drop the 'altera-' prefix and clean
up a little there.

If you want to send me a Xilinx example of usage for me to include in that
document, that would be useful also.  I think you might have sent me
something a while ago, but I can't find it now.

> 
> >
> > I've combined the bindings document and the other Documentation/fpga/ 
> > document
> > and done a rewrite there.
> 
> Looks great!
> 
> I'll test it on hardware and look at the patches individually,

Thank you!

> 
> Cheers,
> 
> Moritz
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v15 1/6] fpga: add bindings document for fpga area and fpga bus

[atull]

On Thu, 21 Jan 2016, Moritz Fischer wrote:

> Hi Alan,
> 
> I tried getting a simple example to work with overlays, however so far
> I failed getting
> the child nodes to probe drivers, maybe you have an idea? The fpga
> image is loaded just fine.
> 
> in dts:
> 
>fpga_bus@0 {
>compatible = "altr,fpga-bus", "simple-bus";
>#address-cells = <1>;
>#size-cells = <1>;
>ranges;
> 
>fpga_mgr0: devcfg@f8007000 {
>compatible = "xlnx,zynq-devcfg-1.0",
> "simple-bus";
>reg = <0xf8007000 0x100>;
>interrupt-parent = <&intc>;
>interrupts = <0 8 4>;
>clocks = <&clkc 12>;
>clock-names = "ref_clk";
>syscon = <&slcr>;
> 
>#address-cells = <1>;
>#size-cells = <1>;
>ranges;
>};
>   };
> 
> overlay:
> 
> fragment@0 {
> target-path = "/amba/devcfg@f8007000";

Hi Moritz,

  target-path = "/amba/fpga_bus@0/devcfg@f8007000";

should work, I hope.  If it doesn't, turn on debugging for
fpga-area.c and maybe add more printk's in the probe function.
Hopefully you get to the fpga-area's probe function and can
see which step is bailing out.  If you get as far as 
of_platform_populate, but your axidma's probe isn't getting
called then you could add some debug to drivers/of/platform.c
to see why it's not getting populated.

Alan

> __overlay__ {
> #address-cells = <1>;
> #size-cells = <1>;
> 
> area@0 {
> compatible = "fpga-area";
> #address-cells = <1>;
> #size-cells = <1>;
> ranges;
> 
> firmware-name = "dmac.bin";
> 
> axi_dma0: axidma@4000 {
> compatible = "xlnx,axi-dma-1.00.a";
> reg = <0x4000 0x1>;
>#dma-cells = <1>;
>xlnx,include-sg = <1>;
>xlnx,include-dre = <1>;
>   status = "okay";
>   [...]
>};
> };
> };
> };
> 
> 
> I also stumbled across those while looking through the examples:
> 
> > +Example:
> > +
> > +/dts-v1/;
> > +/plugin/;
> 
> /dts-v1/ / plugin/; the above syntax is deprecated:
> 
> Warning (deprecated_plugin_syntax): Use '/dts-v1/ /plugin/'; syntax.
> /dts-v1/; /plugin/; is going to be removed in next versions
> 
> > +Device Tree Example: Partial Reconfiguration with no Bridges
> > +
> > +
> > +Live Device Tree contains:
> > +   fpgamgr@ffd03000 {
> > +   compatible = "altr,socfpga-a10-fpga-mgr", "simple-bus";
> > +   clocks = <&l4_mp_clk>;
> > +   resets = <&rst FPGAMGR_RESET>;
> > +   reset-names = "fpgamgr";
> > +   reg = <0xffd03000 0x1000
> > +  0xffcfe400 0x1000>;
> > +
> > +   #address-cells = <0x1>;
> > +   #size-cells = <0x1>;
> > +   ranges;
> > +   };
> > +
> > +DT Overlay contains:
> > +/dts-v1/;
> > +/plugin/;

Yes, thanks! I will adjust the documentation to reflect that.

Alan

> 
> see above
> 
> Cheers,
> 
> Moritz
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v15 5/6] fpga: fpga-area and fpga-bus: device tree control for FPGA

[atull]

On Thu, 21 Jan 2016, Moritz Fischer wrote:

> Hi Alan,
> 
> minor nits inline:
> 
> On Wed, Jan 20, 2016 at 8:24 PM,   wrote:
> 
> > v15: Add altr,fpga-bus implementation
> >  Change compatible string "fpga-area" -> "altr,fpga-area"
> 
> Doesn't look that way down there. Or am I reading the code wrong?

Hi Moritz,

Yes, I left that out accidentally.  But hopefully we won't have
pushback around this issue and I can leave it out permanently
and also change altr,fpga-bus to fpga-bus.

Alan

> 
> > +static const struct of_device_id fpga_area_of_match[] = {
> > +   { .compatible = "fpga-area", },
> 
> I'm fine with keeping it as fpga-area, this isn't altera specific imho
> 
> Cheers,
> 
> Moritz
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v15 5/6] fpga: fpga-area and fpga-bus: device tree control for FPGA

[atull]

On Fri, 22 Jan 2016, Moritz Fischer wrote:

> Alan,
> 
> On Wed, Jan 20, 2016 at 8:24 PM,   wrote:
> 
> > +static int fpga_area_probe(struct platform_device *pdev)
> > +{
> > +   struct device *dev = &pdev->dev;
> > +   struct device_node *np = dev->of_node;
> > +   struct fpga_area *area;
> > +   int ret;
> > +
> > +   area = devm_kzalloc(dev, sizeof(*area), GFP_KERNEL);
> > +   if (!area)
> > +   return -ENOMEM;
> > +
> > +   INIT_LIST_HEAD(&area->bridge_list);
> > +
> > +   ret = fpga_bridge_register(dev, "FPGA Area", NULL, area);
> > +   if (ret)
> > +   return ret;
> > +   area->br = dev_get_drvdata(dev);
> > +
> > +   if (of_property_read_string(np, "firmware-name",
> > +   &area->firmware_name)) {
> > +   of_platform_populate(np, of_default_bus_match_table, NULL, 
> > dev);
> > +   return 0;
> > +   }
> 
> This is the use case where the bootloader loaded the fpga, and you
> just want to populate
> the devices in the fabric, right?

Hi Moritz,

Yes

> 
> > +   if (of_property_read_bool(np, "partial-reconfig"))
> > +   area->flags |= FPGA_MGR_PARTIAL_RECONFIG;
> > +
> > +   ret = fpga_area_get_bus(area);
> > +   if (ret) {
> > +   dev_dbg(dev, "Should be child of a FPGA Bus");
> > +   goto err_unreg;
> > +   }
> 
> Looking at socfpga.dtsi, would that mean that the fpgamgr0 node would
> need to become a subnode of fpgabus@0 at the same place?
> 
> i.e. /soc/fpgamgr@ff706000 -> /soc/fpgabus@0/fpgamgr@ff706000
> 
> and the ranges property would be used to translate to the fpga memory
> mapped space?
> 
> I know we're going back and forth on this. I think Rob brought up a
> similar question:
> "Does the bus really go thru the fpgamgr and then the bridge as this
> implies? Or fpgamgr is a sideband controller?"
> 
> To which I think the answer is 'sideband' controller, yet with the new
> bindings it looks like
> the bus goes through the fpgamgr.

Yeah, let's get this right.  First, let's be clear on the reason for FPGA Bus to
exist.  There may be >1 FPGA in a system.  I want the FPGA Bus bring together
the bridges and manager that are associated with a certain FPGA.  This allows
the system designer to specify which FPGA is getting programmed with which
image/hardware.  So at minimum, we need some way of associating a FPGA Bus with
a FPGA Manager.

As far as the target path is concerned, in the case of no bridges, we could have
the overlay target the FPGA Bus instead of the FPGA Manager.  That may be more
logical.  This would just be a documentation change; I think fpga-area.c will
work OK if you specify the FPGA bus as your target (the manager still has to
be a child of the bus so the bus knows what manager to use).

Alan

> 
> Cheers,
> 
> Moritz
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v15 5/6] fpga: fpga-area and fpga-bus: device tree control for FPGA

[atull]

On Mon, 25 Jan 2016, Rob Herring wrote:

> On Fri, Jan 22, 2016 at 6:07 PM, Moritz Fischer
>  wrote:
> > On Fri, Jan 22, 2016 at 5:37 PM, atull  wrote:
> >> On Fri, 22 Jan 2016, Moritz Fischer wrote:
> >>
> >>> Alan,
> >>>
> >>> On Wed, Jan 20, 2016 at 8:24 PM,   wrote:
> >>>
> >>> > +static int fpga_area_probe(struct platform_device *pdev)
> >>> > +{
> >>> > +   struct device *dev = &pdev->dev;
> >>> > +   struct device_node *np = dev->of_node;
> >>> > +   struct fpga_area *area;
> >>> > +   int ret;
> >>> > +
> >>> > +   area = devm_kzalloc(dev, sizeof(*area), GFP_KERNEL);
> >>> > +   if (!area)
> >>> > +   return -ENOMEM;
> >>> > +
> >>> > +   INIT_LIST_HEAD(&area->bridge_list);
> >>> > +
> >>> > +   ret = fpga_bridge_register(dev, "FPGA Area", NULL, area);
> >>> > +   if (ret)
> >>> > +   return ret;
> >>> > +   area->br = dev_get_drvdata(dev);
> >>> > +
> >>> > +   if (of_property_read_string(np, "firmware-name",
> >>> > +   &area->firmware_name)) {
> >>> > +   of_platform_populate(np, of_default_bus_match_table, 
> >>> > NULL, dev);
> >>> > +   return 0;
> >>> > +   }
> >>>
> >>> This is the use case where the bootloader loaded the fpga, and you
> >>> just want to populate
> >>> the devices in the fabric, right?
> >>
> >> Hi Moritz,
> >>
> >> Yes
> 
> That is very strange logic. It should be fine to just call
> of_platform_populate unconditionally. If there are no children of np,
> then it will be a nop.

That's what it is doing.  It's coded this way to reduce indentation.  If there
is no FPGA image to load, call of_platform_populate() and return.  Otherwise do
a bunch of steps to load the FPGA image and handle the bridges, then call
of_platform_populate() and return.  If there's no children, no problem.

> 
> >>> > +   if (of_property_read_bool(np, "partial-reconfig"))
> >>> > +   area->flags |= FPGA_MGR_PARTIAL_RECONFIG;
> >>> > +
> >>> > +   ret = fpga_area_get_bus(area);
> >>> > +   if (ret) {
> >>> > +   dev_dbg(dev, "Should be child of a FPGA Bus");
> >>> > +   goto err_unreg;
> >>> > +   }
> >>>
> >>> Looking at socfpga.dtsi, would that mean that the fpgamgr0 node would
> >>> need to become a subnode of fpgabus@0 at the same place?
> >>>
> >>> i.e. /soc/fpgamgr@ff706000 -> /soc/fpgabus@0/fpgamgr@ff706000
> >>>
> >>> and the ranges property would be used to translate to the fpga memory
> >>> mapped space?
> >>>
> >>> I know we're going back and forth on this. I think Rob brought up a
> >>> similar question:
> >>> "Does the bus really go thru the fpgamgr and then the bridge as this
> >>> implies? Or fpgamgr is a sideband controller?"
> >>>
> >>> To which I think the answer is 'sideband' controller, yet with the new
> >>> bindings it looks like
> >>> the bus goes through the fpgamgr.
> >>
> >> Yeah, let's get this right.  First, let's be clear on the reason for FPGA 
> >> Bus to
> >> exist.  There may be >1 FPGA in a system.  I want the FPGA Bus bring 
> >> together
> >> the bridges and manager that are associated with a certain FPGA.  This 
> >> allows
> >> the system designer to specify which FPGA is getting programmed with which
> >> image/hardware.  So at minimum, we need some way of associating a FPGA Bus 
> >> with
> >> a FPGA Manager.
> >
> > I see your argument for the FPGA bus. I agree that we need to
> > distinguish different FPGAs,
> > and we need a way to associate an area with a manager (and potentially 
> > bridges).
> >
> >> As far as the target path is concerned, in the case of no bridges, we 
> >> could have
> >> the overlay target the FPGA Bus instead of the FPGA Manager.  That may be 
> >> more
> >> logical.  This would just be a documentation change;

Re: [PATCH v15 1/6] fpga: add bindings document for fpga area and fpga bus

[atull]

On Mon, 25 Jan 2016, Rob Herring wrote:

> On Wed, Jan 20, 2016 at 01:24:22PM -0600, at...@opensource.altera.com wrote:
> > From: Alan Tull 
> > 
> > New bindings document for FPGA Area for reprogramming
> > FPGA's under Device Tree control
> > 
> > Signed-off-by: Alan Tull 
> > ---
> > v9:  initial version added to this patchset
> > v10: s/fpga/FPGA/g
> >  replace DT overlay example with slightly more complicated example
> >  move to staging/simple-fpga-bus
> > v11: No change in this patch for v11 of the patch set
> > v12: Moved out of staging.
> >  Changed to use FPGA bridges framework instead of resets
> >  for bridges.
> > v13: bridge@0xff2 -> bridge@ff20, etc
> >  Leave out directly talking about overlays
> >  Remove regs and clocks directly under simple-fpga-bus in example
> >  Use common "firmware-name" binding instead of "fpga-firmware"
> > v14: Use firmware-name in bindings description
> >  Call it FPGA Area
> >  Remove bindings that specify FPGA Manager and FPGA Bridges
> > v15: Cleanup as per Rob's comments
> >  Combine usage doc with bindings document
> >  Document as being Altera specific
> >  Additions and changes to add FPGA Bus
> > ---
> >  .../bindings/fpga/altera-fpga-bus-fpga-area.txt|  452 
> > 
> >  1 file changed, 452 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/fpga/altera-fpga-bus-fpga-area.txt
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/fpga/altera-fpga-bus-fpga-area.txt 
> > b/Documentation/devicetree/bindings/fpga/altera-fpga-bus-fpga-area.txt
> > new file mode 100644
> > index 000..8ea38ca
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/fpga/altera-fpga-bus-fpga-area.txt
> > @@ -0,0 +1,452 @@
> > +Altera FPGA Area and FPGA Bus Device Tree Binding
> 
> Getting closer I think...

Great!

> 
> > +
> > +Alan Tull 2016
> > +
> > + CONTENTS
> > + - Introduction
> > + - Terminology
> > + - Overview
> > + - Constraints
> > + - FPGA Bus
> > + - FPGA Area
> > + - Supported Use Models
> > + - Sequence
> > + - Device Tree Examples
> > +
> > +
> > +Introduction
> > +
> > +
> > +FPGA Buses and FPGA Areas are introduced as a way to solve the problem of 
> > how to
> > +reprogram an Altera FPGA under an operating system and have the new 
> > hardware
> > +show up in the device tree.  By adding these bindings to the Device Tree, a
> > +system can have the information needed to do the FPGA programming to add 
> > the
> > +desired hardware, and also the information about the devices to be added 
> > to the
> > +Device Tree once the programming has succeeded.
> > +
> > +
> > +Terminology
> > +===
> > +
> > +Full Reconfiguration
> > + * The entire FPGA is programmed.
> > +
> > +Partial Reconfiguration (PR)
> > + * The FPGA is broken up into regions.  One of these regions is 
> > reprogrammed
> > +   while the rest of the FPGA is not affected.  Not all FPGA's support 
> > this.
> > +
> > +FPGA Manager & FPGA Manager Framework
> > + * An FPGA Manager is a hardware block that programs an FPGA under the 
> > control
> > +   of a host processor.
> > + * The FPGA Manager Framework provides drivers and functions to program an
> > +   FPGA.
> > +
> > +FPGA Bridge & FPGA Bridge Framework
> > + * Provides drivers and functions to control bridges that enable/disable
> > +   data to the FPGA.
> > + * FPGA Bridges should be disabled while the FPGA is being programmed to
> > +   prevent spurious data on the bus.
> > + * FPGA Bridges may not be needed in implementations where the FPGA Manager
> > +   handles this.
> > +
> > +Freeze Blocks
> > + * Freeze Blocks function as FPGA Bridges within the FPGA fabric.  In the 
> > case
> > +   of PR, the buses from the processor are split within the FPGA.  Each PR
> > +   region gets its own split of the buses, protected by an independently
> > +   controlled Freeze Block.  Several busses may be connected to a single
> > +   PR region; a Freeze Block controls the traffic of all these busses
> > +   together.
> > +
> > +Controlling Bridge
> > + * The processor and FPGA may be connected by multiple FPGA Bridges.  In a 
> > text
> > +   based hierarchy, it is difficult to show this properly as a device would
> > +   have several parents.
> > + * The bridge that handles register access to the FPGA is designated the
> > +   "controlling" bridge.
> > + * The controlling bridge will be the target point under which the overlay 
> > is
> > +   inserted.
> > +
> > +
> > +Overview
> > +
> > +
> > +This binding introduces the FPGA Bus and FPGA Area.
> > +
> > +An FPGA Bus is a virtualized bus that contains the devices needed to be 
> > able to
> > +program an FPGA device.  It contains a child FPGA Manager and may contain 
> > child
> > +FPGA Bridges, if needed.  The FPGA Manager is the hardware block that 
> > handles
> > +programming the FPGA.  FPGA Bridges function to prevent spurious data from 
> > the
> > +FPG

[PATCH v16 1/6] fpga: add bindings document for fpga region

[atull]

From: Alan Tull 

New bindings document for FPGA Region to support programming
FPGA's under Device Tree control

Signed-off-by: Alan Tull 
Signed-off-by: Moritz Fischer 
---
v9:  initial version added to this patchset
v10: s/fpga/FPGA/g
 replace DT overlay example with slightly more complicated example
 move to staging/simple-fpga-bus
v11: No change in this patch for v11 of the patch set
v12: Moved out of staging.
 Changed to use FPGA bridges framework instead of resets
 for bridges.
v13: bridge@0xff2 -> bridge@ff20, etc
 Leave out directly talking about overlays
 Remove regs and clocks directly under simple-fpga-bus in example
 Use common "firmware-name" binding instead of "fpga-firmware"
v14: Use firmware-name in bindings description
 Call it FPGA Area
 Remove bindings that specify FPGA Manager and FPGA Bridges
v15: Cleanup as per Rob's comments
 Combine usage doc with bindings document
 Document as being Altera specific
 Additions and changes to add FPGA Bus
v16: Reworked to document FPGA Regions
 rename altera-fpga-bus-fpga-area.txt -> fpga-region.txt
 Remove references that made it sound exclusive to Altera
 Remove altr, prefix from fpga-bus and fpga-area compatible strings
 Added Moritz' usage example with Xilinx
 Cleaned up unit addresses
---
 .../devicetree/bindings/fpga/fpga-region.txt   |  348 
 1 file changed, 348 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/fpga/fpga-region.txt

diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt 
b/Documentation/devicetree/bindings/fpga/fpga-region.txt
new file mode 100644
index 000..ccd7127
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt
@@ -0,0 +1,348 @@
+FPGA Region Device Tree Binding
+
+Alan Tull 2016
+
+ CONTENTS
+ - Introduction
+ - Terminology
+ - Overview
+ - Constraints
+ - FPGA Region
+ - Supported Use Models
+ - Sequence
+ - Device Tree Examples
+
+
+Introduction
+
+
+FPGA Regions are introduced as a way to solve the problem of how to program an
+FPGA under an operating system and have the new hardware show up in the device
+tree.  By adding these bindings to the Device Tree, a system can have the
+information needed to program the FPGA and add the desired hardware, and also
+the information about the devices to be added to the Device Tree once the
+programming has succeeded.
+
+
+Terminology
+===
+
+Full Reconfiguration
+ * The entire FPGA is programmed.
+
+Partial Reconfiguration (PR)
+Partial Reconfiguration Region (PRR)
+ * The FPGA is divided into regions.  Each of these regions can be programmed
+   while the rest of the FPGA is not affected.  Not all FPGA's support this.
+ * PRR's may vary in size and in the connections at their edge.  The image
+   that is loaded into a PRR must fit and must use a subset of the region's
+   connections.
+
+Base image
+ * An FPGA image that is designed to do full reconfiguration of the FPGA.
+ * A base image may set up a set of regions to allow for partial
+   reconfiguration.
+
+Persona
+ * An FPGA image that is designed to be loaded into a PRR.  There may be
+   any number of personas designed to fit into a PRR, but only one at at time
+   may be loaded.
+ * A persona may create more regions.
+
+FPGA Manager & FPGA Manager Framework
+ * An FPGA Manager is a hardware block that programs an FPGA under the control
+   of a host processor.
+ * The FPGA Manager Framework provides drivers and functions to program an
+   FPGA.
+
+FPGA Bridge Framework
+ * Provides drivers and functions to control bridges that enable/disable
+   data to the FPGA.
+ * FPGA Bridges should be disabled while the FPGA is being programmed to
+   prevent spurious data on the bus.
+ * FPGA Bridges may not be needed in implementations where the FPGA Manager
+   handles this.
+
+Freeze Blocks
+ * Freeze Blocks function as FPGA Bridges within the FPGA fabric.  In the case
+   of PR, the buses from the processor are split within the FPGA.  Each PR
+   region gets its own split of the buses, protected by an independently
+   controlled Freeze Block.  Several busses may be connected to a single
+   PR region; a Freeze Block controls the traffic of all these busses
+   together.
+
+
+Overview
+
+
+This binding introduces the FPGA Region.
+
+An FPGA Region references the devices needed to be able to program an FPGA
+device.  The base FPGA Region in the device tree is required to include a
+property with a phandle to an FPGA Manager.  This region may also contain a
+property that has a list of FPGA Bridge phandles, if needed.  Child FPGA 
Regions
+inherit the parent's FPGA Manager but specify their own bridges.
+
+The base FPGA Region supports full reconfiguration of the FPGA device.  If the
+FPGA image loaded contains the logic that creates a set of Partial
+Reconfiguration Regions, then the DT that programs the FPGA should also add a
+set of FPGA Regi

[PATCH v16 2/6] add sysfs document for fpga bridge class

[atull]

From: Alan Tull 

Add documentation for new FPGA bridge class's sysfs interface.

Signed-off-by: Alan Tull 
--
v15: Document added in v15 of patch set
v16: No change to this patch in v16 of patch set
---
 Documentation/ABI/testing/sysfs-class-fpga-bridge |   11 +++
 1 file changed, 11 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-fpga-bridge

diff --git a/Documentation/ABI/testing/sysfs-class-fpga-bridge 
b/Documentation/ABI/testing/sysfs-class-fpga-bridge
new file mode 100644
index 000..312ae2c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-fpga-bridge
@@ -0,0 +1,11 @@
+What:  /sys/class/fpga_bridge//name
+Date:  January 2016
+KernelVersion: 4.5
+Contact:   Alan Tull 
+Description:   Name of low level FPGA bridge driver.
+
+What:  /sys/class/fpga_bridge//state
+Date:  January 2016
+KernelVersion: 4.5
+Contact:   Alan Tull 
+Description:   Show bridge state as "enabled" or "disabled"
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v16 5/6] fpga: fpga-region: device tree control for FPGA

[atull]

From: Alan Tull 

FPGA Regions support programming FPGA under control of the Device
Tree.

Signed-off-by: Alan Tull 
---
v9:  initial version (this patch added during rest of patchset's v9)
v10: request deferral if fpga mgr or bridges not available yet
 cleanup as fpga manager core goes into the real kernel
 Don't assume bridges are disabled before programming FPGA
 Don't hang onto reference for fpga manager
 Move to staging/simple-fpga-bus
v11: No change in this patch for v11 of the patch set
v12: Moved out of staging.
 Use fpga bridges framework.
v13: If no bridges are specified, assume we don't need any.
 Clean up debug messages
 Some dev_info -> dev_dbg
 Remove unneeded #include
 Fix size of array of pointers
 Don't need to specify .owner
 Use common binding: firmware-name
v14: OK it's not a simple bus.  Call it "FPGA Area"
 Remove bindings that specify FPGA manager and FPGA bridges
 Use parent FPGA bridge and bridges that are its peers
 Use ancestor FPGA Manager
v15: Add altr,fpga-bus implementation
 Change compatible string "fpga-area" -> "altr,fpga-area"
v16: Much changes as FPGA Areas and Busses become FPGA Regions
 Add reconfig notifier, don't rely on simple-bus
---
 drivers/fpga/Kconfig   |7 +
 drivers/fpga/Makefile  |3 +
 drivers/fpga/fpga-region.c |  460 
 3 files changed, 470 insertions(+)
 create mode 100644 drivers/fpga/fpga-region.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index b6cfd89..c419d4b 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -13,6 +13,13 @@ config FPGA
 
 if FPGA
 
+config FPGA_REGION
+   bool "FPGA Region"
+   depends on OF
+   help
+FPGA Regions allow loading FPGA images under control of
+the Device Tree.
+
 config FPGA_MGR_SOCFPGA
tristate "Altera SOCFPGA FPGA Manager"
depends on ARCH_SOCFPGA
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 4baef00..8d746c3 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -11,3 +11,6 @@ obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)  += zynq-fpga.o
 
 # FPGA Bridge Drivers
 obj-$(CONFIG_FPGA_BRIDGE)  += fpga-bridge.o
+
+# High Level Interfaces
+obj-$(CONFIG_FPGA_REGION)  += fpga-region.o
diff --git a/drivers/fpga/fpga-region.c b/drivers/fpga/fpga-region.c
new file mode 100644
index 000..eb4d3a6
--- /dev/null
+++ b/drivers/fpga/fpga-region.c
@@ -0,0 +1,460 @@
+/*
+ * FPGA Region - Device Tree support for FPGA programming under Linux
+ *
+ *  Copyright (C) 2013-2016 Altera Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * struct fpga_region - FPGA Region structure
+ * @dev: FPGA Region device
+ * @mutex: enforces exclusive reference to region
+ * @bridge_list: list of FPGA bridges specified in region
+ */
+struct fpga_region {
+   struct device dev;
+   struct mutex mutex; /* for exclusive reference to region */
+   struct list_head bridge_list;
+};
+
+#define to_fpga_region(d) container_of(d, struct fpga_region, dev)
+
+static DEFINE_IDA(fpga_region_ida);
+static struct class *fpga_region_class;
+
+static const struct of_device_id fpga_region_of_match[] = {
+   { .compatible = "fpga-region", },
+   {},
+};
+MODULE_DEVICE_TABLE(of, fpga_region_of_match);
+
+static int fpga_region_of_node_match(struct device *dev, const void *data)
+{
+   return dev->of_node == data;
+}
+
+/**
+ * fpga_region_find - find FPGA region
+ * @np: device node of FPGA Region
+ * Caller will need to put_device(®ion->dev) when done.
+ * Returns FPGA Region struct or NULL
+ */
+static struct fpga_region *fpga_region_find(struct device_node *np)
+{
+   struct device *dev;
+
+   dev = class_find_device(fpga_region_class, NULL, np,
+   fpga_region_of_node_match);
+   if (!dev) {
+   pr_err("%s did not find FPGA Region in class: %s\n", __func__,
+  np->full_name);
+   return NULL;
+   }
+
+   return to_fpga_region(dev);
+}
+
+/**
+ * fpga_region_get - get an exclusive reference to a fpga region
+ * @region: FPGA Region struct
+ *
+ * Caller should call fpga_region_put() when done with region.
+ *
+ * Return fpga_region struct if successf

[PATCH v16 4/6] fpga: add fpga bridge framework

[atull]

From: Alan Tull 

This framework adds API functions for enabling/
disabling FPGA bridges under kernel control.

This allows the Linux kernel to disable FPGA bridges
during FPGA reprogramming and to enable FPGA bridges
when FPGA reprogramming is done.  This framework is
be manufacturer-agnostic, allowing it to be used in
interfaces that use the FPGA Manager Framework to
reprogram FPGA's.

The functions are:
* of_fpga_bridge_get
* fpga_bridge_put
   Get/put an exclusive reference to a FPGA bridge.

* fpga_bridge_enable
* fpga_bridge_disable
   Enable/Disable traffic through a bridge.

* fpga_bridge_register
* fpga_bridge_unregister
   Register/unregister a device-specific low level FPGA
   Bridge driver.

Get an exclusive reference to a bridge and add it to a list:
* fpga_bridge_get_to_list

To enable/disable/put a set of bridges that are on a list:
* fpga_bridges_enable
* fpga_bridges_disable
* fpga_bridges_put

Signed-off-by: Alan Tull 
---
v2:  Minor cleanup
v12: Bump version to line up with simple fpga bus
 Remove sysfs
 Improve get/put functions, get the low level driver too.
 Clean up class implementation
 Add kernel doc documentation
 Rename (un)register_fpga_bridge -> fpga_bridge_(un)register
v13: Add inlined empty functions for if not CONFIG_FPGA_BRIDGE
 Clean up debugging
 Remove unneeded #include in .h
 Remove unnecessary prints
 Remove 'label' DT binding.
 Document the mutex
v14: Allow bridges with no ops
 *const* struct fpga_bridge_ops
 Add functions to git/put/enable/disable list of bridges
 Add list node to struct fpga_bridge
 Do of_node_get/put in of_fpga_bridge_get()
 Add r/o attributes: name and state
v15: No change in this patch for v15 of this patch set
v16: Remove of_get_fpga_bus function
---
 drivers/fpga/Kconfig |7 +
 drivers/fpga/Makefile|3 +
 drivers/fpga/fpga-bridge.c   |  388 ++
 include/linux/fpga/fpga-bridge.h |   55 ++
 4 files changed, 453 insertions(+)
 create mode 100644 drivers/fpga/fpga-bridge.c
 create mode 100644 include/linux/fpga/fpga-bridge.h

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index c9b9fdf..b6cfd89 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -24,6 +24,13 @@ config FPGA_MGR_ZYNQ_FPGA
help
  FPGA manager driver support for Xilinx Zynq FPGAs.
 
+config FPGA_BRIDGE
+   bool "FPGA Bridge Framework"
+   depends on OF
+   help
+ Say Y here if you want to support bridges connected between host
+processors and FPGAs or between FPGAs.
+
 endif # FPGA
 
 endmenu
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 8d83fc6..4baef00 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -8,3 +8,6 @@ obj-$(CONFIG_FPGA)  += fpga-mgr.o
 # FPGA Manager Drivers
 obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
 obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)   += zynq-fpga.o
+
+# FPGA Bridge Drivers
+obj-$(CONFIG_FPGA_BRIDGE)  += fpga-bridge.o
diff --git a/drivers/fpga/fpga-bridge.c b/drivers/fpga/fpga-bridge.c
new file mode 100644
index 000..5119d8e
--- /dev/null
+++ b/drivers/fpga/fpga-bridge.c
@@ -0,0 +1,388 @@
+/*
+ * FPGA Bridge Framework Driver
+ *
+ *  Copyright (C) 2013-2015 Altera Corporation, All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static DEFINE_IDA(fpga_bridge_ida);
+static struct class *fpga_bridge_class;
+
+/* Lock for adding/removing bridges to linked lists*/
+spinlock_t bridge_list_lock;
+
+static int fpga_bridge_of_node_match(struct device *dev, const void *data)
+{
+   return dev->of_node == data;
+}
+
+/**
+ * fpga_bridge_enable - Enable transactions on the bridge
+ *
+ * @bridge: FPGA bridge
+ *
+ * Return: 0 for success, error code otherwise.
+ */
+int fpga_bridge_enable(struct fpga_bridge *bridge)
+{
+   dev_dbg(&bridge->dev, "enable\n");
+
+   if (bridge->br_ops && bridge->br_ops->enable_set)
+   return bridge->br_ops->enable_set(bridge, 1);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(fpga_bridge_enable);
+
+/**
+ * fpga_bridge_disable - Disable transactions on the bridge
+ *
+ * @bridge: FPGA bridge
+ *
+ * Return: 0 for success, error code otherwise.
+ */
+int fpga_bridge_disable(struct fpga_bridge *bridge)
+{

[PATCH v16 6/6] ARM: socfpga: fpga bridge driver support

[atull]

From: Alan Tull 

Supports Altera SOCFPGA bridges:
 * fpga2sdram
 * fpga2hps
 * hps2fpga
 * lwhps2fpga

Allows enabling/disabling the bridges through the FPGA
Bridge Framework API functions.

The fpga2sdram driver only supports enabling and disabling
of the ports that been configured early on.  This is due to
a hardware limitation where the read, write, and command
ports on the fpga2sdram bridge can only be reconfigured
while there are no transactions to the sdram, i.e. when
running out of OCRAM before the kernel boots.

Device tree property 'init-val' configures the driver to
enable or disable the bridge during probe.  If the property
does not exist, the driver will leave the bridge in its
current state.

Signed-off-by: Alan Tull 
Signed-off-by: Matthew Gerlach 
Signed-off-by: Dinh Nguyen 
---
v2:  Use resets instead of directly writing reset registers
v12: Bump version to align with simple-fpga-bus version
 Get rid of the sysfs interface
 fpga2sdram: get configuration stored in handoff register
v13: Remove unneeded WARN_ON
 Change property from init-val to bridge-enable
 Checkpatch cleanup
 Fix email address
v14: use module_platform_driver
 remove unused struct field and some #defines
 don't really need exclamation points on error msgs
 *const* struct fpga_bridge_ops
v15: No change in this patch for v15 of this patch set
v16: No change in this patch for v16 of this patch set
---
 drivers/fpga/Kconfig |7 ++
 drivers/fpga/Makefile|1 +
 drivers/fpga/altera-fpga2sdram.c |  174 +++
 drivers/fpga/altera-hps2fpga.c   |  213 ++
 4 files changed, 395 insertions(+)
 create mode 100644 drivers/fpga/altera-fpga2sdram.c
 create mode 100644 drivers/fpga/altera-hps2fpga.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index c419d4b..45fd823 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -38,6 +38,13 @@ config FPGA_BRIDGE
  Say Y here if you want to support bridges connected between host
 processors and FPGAs or between FPGAs.
 
+config SOCFPGA_FPGA_BRIDGE
+   bool "Altera SoCFPGA FPGA Bridges"
+   depends on ARCH_SOCFPGA && FPGA_BRIDGE
+   help
+ Say Y to enable drivers for FPGA bridges for Altera SOCFPGA
+ devices.
+
 endif # FPGA
 
 endmenu
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 8d746c3..e658436 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)  += zynq-fpga.o
 
 # FPGA Bridge Drivers
 obj-$(CONFIG_FPGA_BRIDGE)  += fpga-bridge.o
+obj-$(CONFIG_SOCFPGA_FPGA_BRIDGE)  += altera-hps2fpga.o altera-fpga2sdram.o
 
 # High Level Interfaces
 obj-$(CONFIG_FPGA_REGION)  += fpga-region.o
diff --git a/drivers/fpga/altera-fpga2sdram.c b/drivers/fpga/altera-fpga2sdram.c
new file mode 100644
index 000..91f4a40
--- /dev/null
+++ b/drivers/fpga/altera-fpga2sdram.c
@@ -0,0 +1,174 @@
+/*
+ * FPGA to SDRAM Bridge Driver for Altera SoCFPGA Devices
+ *
+ *  Copyright (C) 2013-2015 Altera Corporation, All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+/*
+ * This driver manages a bridge between an FPGA and the SDRAM used by the ARM
+ * host processor system (HPS).
+ *
+ * The bridge contains 4 read ports, 4 write ports, and 6 command ports.
+ * Reconfiguring these ports requires that no SDRAM transactions occur during
+ * reconfiguration.  The code reconfiguring the ports cannot run out of SDRAM
+ * nor can the FPGA access the SDRAM during reconfiguration.  This driver does
+ * not support reconfiguring the ports.  The ports are configured by code
+ * running out of on chip ram before Linux is started and the configuration
+ * is passed in a handoff register in the system manager.
+ *
+ * This driver supports enabling and disabling of the configured ports, which
+ * allows for safe reprogramming of the FPGA, assuming that the new FPGA image
+ * uses the same port configuration.  Bridges must be disabled before
+ * reprogramming the FPGA and re-enabled after the FPGA has been programmed.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define ALT_SDR_CTL_FPGAPORTRST_OFST   0x80
+#define ALT_SDR_CTL_FPGAPORTRST_PORTRSTN_MSK   0x3fff
+#define ALT_SDR_CTL_FPGAPORTRST_RD_SHIFT   0
+#define ALT_SDR_CTL_FPGAPOR

[PATCH v16 0/6] Device Tree support for FPGA programming

[atull]

From: Alan Tull 

v16 Refactors the FPGA Area and FPGA Bus into single thing called an
FPGA Region and eliminates using simple-bus.  I'm using the word
"region" as it's a term is used in the literature of both the major
FPGA manufacturors.

Changes for v16:
* Refactor the FPGA Area and FPGA Bus into a FPGA Region.
* Don't use simple-bus.
* FPGA Managers and FPGA Bridges are now specified by phandle using the 
  "fpga-mgr" and "fpga-bridges" properties.  fpga-bridges can specify
  more than one bridge.
* Device Tree overlays should be targeted to a FPGA Region.
* The overlays need only contain firmware-name and the child nodes.
* To model a system containing >1 partial reconfiguration region,
  an overlay could add FPGA Regions to the base FPGA Regions.
* Child FPGA Regions inherit the parent FGPA Manager, but specify
  their own set of bridges if needes as partial reconfig regions
  will likely need their own bridges.
* All this is discussed in bindings/fpga/fpga-region.txt

One other highlight:
The little engine that runs this thing is a reconfig notifier
in fpga-region.c.  This notifier that will program an FPGA if a
"firmware-name" property gets added to a fpga-region.  Then
it will call of_platform_populate().  The current behavior in Linux
when a DT overlay is applied is that the reconfig notifications
go out in heirarchical order: first notifications are for the
properties, then notifications for the child nodes.  So an overlay
that adds a 'firmware-name' property and some child nodes to a
fpga-region will cause FPGA programming and child node
populating in the right order.

One issue with the dynamic DT stuff:
I've tried returning and error from the notifier if FPGA programming
fails; the error is noted on the console, but the child nodes
get probed anyway.


Alan Tull (6):
  fpga: add bindings document for fpga region
  add sysfs document for fpga bridge class
  ARM: socfpga: add bindings document for fpga bridge drivers
  fpga: add fpga bridge framework
  fpga: fpga-region: device tree control for FPGA
  ARM: socfpga: fpga bridge driver support

 Documentation/ABI/testing/sysfs-class-fpga-bridge  |   11 +
 .../bindings/fpga/altera-fpga2sdram-bridge.txt |   15 +
 .../bindings/fpga/altera-hps2fpga-bridge.txt   |   47 ++
 .../devicetree/bindings/fpga/fpga-region.txt   |  348 +++
 drivers/fpga/Kconfig   |   21 +
 drivers/fpga/Makefile  |7 +
 drivers/fpga/altera-fpga2sdram.c   |  174 
 drivers/fpga/altera-hps2fpga.c |  213 +
 drivers/fpga/fpga-bridge.c |  388 +
 drivers/fpga/fpga-region.c |  460 
 include/linux/fpga/fpga-bridge.h   |   55 +++
 11 files changed, 1739 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-fpga-bridge
 create mode 100644 
Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
 create mode 100644 
Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
 create mode 100644 Documentation/devicetree/bindings/fpga/fpga-region.txt
 create mode 100644 drivers/fpga/altera-fpga2sdram.c
 create mode 100644 drivers/fpga/altera-hps2fpga.c
 create mode 100644 drivers/fpga/fpga-bridge.c
 create mode 100644 drivers/fpga/fpga-region.c
 create mode 100644 include/linux/fpga/fpga-bridge.h

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v16 3/6] ARM: socfpga: add bindings document for fpga bridge drivers

[atull]

From: Alan Tull 

Add bindings documentation for Altera SOCFPGA bridges:
 * fpga2sdram
 * fpga2hps
 * hps2fpga
 * lwhps2fpga

Signed-off-by: Alan Tull 
Signed-off-by: Matthew Gerlach 
Signed-off-by: Dinh Nguyen 
---
v2:  separate into 2 documents for the 2 drivers
v12: bump version to line up with simple-fpga-bus version
 remove Linux specific notes such as references to sysfs
 move non-DT specific documentation elsewhere
 remove bindings that would have been used to pass configuration
 clean up formatting
v13: Remove 'label' property
 Change property from init-val to bridge-enable
 Fix email address
v14: Add resets
 Change order of bridges to put lw bridge (controlling bridge) first
v15: No change in this patch for v15 of this patch set
v16: Added regs property, cleaned up unit addresses
---
 .../bindings/fpga/altera-fpga2sdram-bridge.txt |   15 +++
 .../bindings/fpga/altera-hps2fpga-bridge.txt   |   47 
 2 files changed, 62 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
 create mode 100644 
Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt

diff --git 
a/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt 
b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
new file mode 100644
index 000..4479a79
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
@@ -0,0 +1,15 @@
+Altera FPGA To SDRAM Bridge Driver
+
+Required properties:
+- compatible   : Should contain "altr,socfpga-fpga2sdram-bridge"
+
+Optional properties:
+- bridge-enable: 0 if driver should disable bridge at startup
+ 1 if driver should enable bridge at startup
+ Default is to leave bridge in current state.
+
+Example:
+   fpga2sdram_br {
+   compatible = "altr,socfpga-fpga2sdram-bridge";
+   bridge-enable = <0>;
+   };
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 000..e6b7474
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
@@ -0,0 +1,47 @@
+Altera FPGA/HPS Bridge Driver
+
+Required properties:
+- regs : base address and size for AXI bridge module
+- compatible   : Should contain one of:
+ "altr,socfpga-lwhps2fpga-bridge",
+ "altr,socfpga-hps2fpga-bridge", or
+ "altr,socfpga-fpga2hps-bridge"
+- reset-names  : Should contain one of:
+ "lwhps2fpga",
+ "hps2fpga", or
+ "fpga2hps"
+- resets   : Phandle and reset specifier for the reset listed in
+ reset-names
+- clocks   : Clocks used by this module.
+
+Optional properties:
+- bridge-enable: 0 if driver should disable bridge at startup.
+ 1 if driver should enable bridge at startup.
+ Default is to leave bridge in its current state.
+
+Example:
+   hps_fpgabridge0: fpgabridge@ff40 {
+   compatible = "altr,socfpga-lwhps2fpga-bridge";
+   reg = <0xff40 0x10>;
+   resets = <&rst LWHPS2FPGA_RESET>;
+   reset-names = "lwhps2fpga";
+   clocks = <&l4_main_clk>;
+   bridge-enable = <0>;
+   };
+
+   hps_fpgabridge1: fpgabridge@ff50 {
+   compatible = "altr,socfpga-hps2fpga-bridge";
+   reg = <0xff50 0x1>;
+   resets = <&rst HPS2FPGA_RESET>;
+   reset-names = "hps2fpga";
+   clocks = <&l4_main_clk>;
+   bridge-enable = <1>;
+   };
+
+   hps_fpgabridge2: fpgabridge@ff60 {
+   compatible = "altr,socfpga-fpga2hps-bridge";
+   reg = <0xff60 0x10>;
+   resets = <&rst FPGA2HPS_RESET>;
+   reset-names = "fpga2hps";
+   clocks = <&l4_main_clk>;
+   };
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v16 1/6] fpga: add bindings document for fpga region

[atull]

On Fri, 5 Feb 2016, Josh Cartwright wrote:

> Hey Alan-
> 
> First off, thanks for all of your (and others') work on this.
> 
> On Fri, Feb 05, 2016 at 03:29:58PM -0600, at...@opensource.altera.com wrote:
> > From: Alan Tull 
> > 
> > New bindings document for FPGA Region to support programming
> > FPGA's under Device Tree control
> > 
> > Signed-off-by: Alan Tull 
> > Signed-off-by: Moritz Fischer 
> [..]
> > ---
> >  .../devicetree/bindings/fpga/fpga-region.txt   |  348 
> > 
> >  1 file changed, 348 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/fpga/fpga-region.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt 
> > b/Documentation/devicetree/bindings/fpga/fpga-region.txt
> > new file mode 100644
> > index 000..ccd7127
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt
> [..]
> > +FPGA Manager & FPGA Manager Framework
> > + * An FPGA Manager is a hardware block that programs an FPGA under the 
> > control
> > +   of a host processor.
> > + * The FPGA Manager Framework provides drivers and functions to program an
> > +   FPGA.
> > +
> > +FPGA Bridge Framework
> > + * Provides drivers and functions to control bridges that enable/disable
> > +   data to the FPGA.
> > + * FPGA Bridges should be disabled while the FPGA is being programmed to
> > +   prevent spurious data on the bus.
> > + * FPGA Bridges may not be needed in implementations where the FPGA Manager
> > +   handles this.
> 
> It still seems strange for me architecturally for the FPGA Bridge to be
> a first-class top-level concept in your architecture, as they are a
> reflection of the SoC FPGA manager design.

It's not so strange if you keep in mind the intent: I want to support
both partial and full reconfiguration.  Also I want this to work not
just for Xilinx but also for Altera :) That makes it a top-level
concept.

>  That is, I would expect the
> bridges not to be associated with the FPGA Region, but with the FPGA
> manager.

Maybe for the one use case of full reconfiguation on Zynq.  More
generally, FPGA Bridges may be hardened hardware devices or they may
be soft hardware in the FPGA that allow some regions of the FGPA to be
isolated from the cpu busses while other FPGA regions are active. The
latter case is to support partial reconfiguration for devices that can
support partial reconfiguration.  The partial reconfiguration region
that is being programmed will need to be isolated from the bus during
programming while the rest of the FPGA remains active.  That requires
that the bridges for each partial reconfiguration region be specified
per region.  Supporting both full and partial reconfiguration is a
priority for me.  I'll have to review this document and see how I can
make this more clear.

> 
> Although, I will concede that you you've made it possible to not use
> FPGA Bridges (like on Zynq where they aren't necessary), so maybe it
> doesn't matter, just smells strangely.

Hmmm my patches are extra fragrent today...  

> 
> > +Freeze Blocks
> > + * Freeze Blocks function as FPGA Bridges within the FPGA fabric.  In the 
> > case
> > +   of PR, the buses from the processor are split within the FPGA.  Each PR
> > +   region gets its own split of the buses, protected by an independently
> > +   controlled Freeze Block.  Several busses may be connected to a single
> > +   PR region; a Freeze Block controls the traffic of all these busses
> > +   together.
> > +
> > +
> [..]
> > +Device Tree Examples
> > +
> > +
> > +The intention of this section is to give some simple examples, focusing on
> > +the placement of the elements detailed above, especially:
> > + * FPGA Manager
> > + * FPGA Bridges
> > + * FPGA Region
> > + * ranges
> > + * target-path or target
> > +
> > +For the purposes of this section, I'm dividing the Device Tree into two 
> > parts,
> > +each with its own requirements.  The two parts are:
> > + * The live DT prior to the overlay being added
> > + * The DT overlay
> > +
> > +The live Device Tree must contain an FPGA Region, an FPGA Manager, and any 
> > FPGA
> > +Bridges.  The FPGA Region's "fpga-mgr" property specifies the manager by 
> > phandle
> > +to handle programming the FPGA.  If the FPGA Region is the child of 
> > another FPGA
> > +Region, the parent's FPGA Manager is used.  If FPGA Bridges need to be 
> > involved,
> > +they are specified in the FPGA Region by the "fpga-bridges" property.  
> > During
> > +FPGA programming, the FPGA Region will disable the bridges that are in its
> > +"fpga-bridges" list and will re-enable them after FPGA programming has
> > +succeeded.
> > +
> > +The Device Tree Overlay will contain:
> > + * "target-path" or "target"
> > +   The insertion point where the the contents of the overlay will go into 
> > the
> > +   live tree.  target-path is a full path, while target is a phandle.
> > + * "ranges"
> > + * "firmware-name"
> > +   Specifies the name 

Re: [PATCH v16 0/6] Device Tree support for FPGA programming

[atull]

On Fri, 5 Feb 2016, at...@opensource.altera.com wrote:

> From: Alan Tull 
> 
> v16 Refactors the FPGA Area and FPGA Bus into single thing called an
> FPGA Region and eliminates using simple-bus.  I'm using the word
> "region" as it's a term is used in the literature of both the major
> FPGA manufacturors.
> 
> Changes for v16:
> * Refactor the FPGA Area and FPGA Bus into a FPGA Region.
> * Don't use simple-bus.
> * FPGA Managers and FPGA Bridges are now specified by phandle using the 
>   "fpga-mgr" and "fpga-bridges" properties.  fpga-bridges can specify
>   more than one bridge.
> * Device Tree overlays should be targeted to a FPGA Region.
> * The overlays need only contain firmware-name and the child nodes.
> * To model a system containing >1 partial reconfiguration region,
>   an overlay could add FPGA Regions to the base FPGA Regions.
> * Child FPGA Regions inherit the parent FGPA Manager, but specify
>   their own set of bridges if needes as partial reconfig regions
>   will likely need their own bridges.
> * All this is discussed in bindings/fpga/fpga-region.txt
> 
> One other highlight:
> The little engine that runs this thing is a reconfig notifier
> in fpga-region.c.  This notifier that will program an FPGA if a
> "firmware-name" property gets added to a fpga-region.  Then
> it will call of_platform_populate().  The current behavior in Linux
> when a DT overlay is applied is that the reconfig notifications
> go out in heirarchical order: first notifications are for the
> properties, then notifications for the child nodes.  So an overlay
> that adds a 'firmware-name' property and some child nodes to a
> fpga-region will cause FPGA programming and child node
> populating in the right order.

I figured out how to get rid of the reconfig notifier.

> 
> One issue with the dynamic DT stuff:
> I've tried returning and error from the notifier if FPGA programming
> fails; the error is noted on the console, but the child nodes
> get probed anyway.

I looked into it further and now I've got a solution for this issue
that I can post soon.  I can stop using the DT overlay configfs
interface and add a sysfs file for applying an overlay to an FPGA
region.  The FPGA region implementation will see the overlay before it
becomes part of the live tree.  Then it can do the FPGA programming
and see that succeed before the child nodes become part of the live
tree.  If FPGA programming fails, the overlay will be rejected before
it becomes part of the live tree.  By the time 'firmware-name' and the
child nodes show up in the live tree, they will be post-configuration
information.

Each fpga_region appears in sysfs and will add a file for loading the
overlay targeted to that region.  Such as:

echo fpga-dt-overlay.dtb.o > \
  /sys/class/fpga_region/region0/overlay_name

fpga-region.c's overlay_name attribute code will load the overlay
file, unflatten and resolve it.  Then it will check to make sure it
passes a few rules.  Such as: the overlay must contain a fragment that
is targeted to the region whose sysfs it was applied.

If the overlay passes the rules check, the FPGA region will program
the FPGA.  If that succeeds, then it calls of_overlay_create() and the
overlay is added into the live tree and the children get populated.

So fpga-region.c will ensure that the FPGA is already programmed
before the child nodes are added to the DT.

This solution also means that fpga-region.c no longer needs a reconfig
notifier.

I'll have to look at the documentation to see how that changes how I
talk about the bindings.  The documentation will have to become two
files again since part of this is Linux specific and part is DT
bindings.

Alan

> 
> 
> Alan Tull (6):
>   fpga: add bindings document for fpga region
>   add sysfs document for fpga bridge class
>   ARM: socfpga: add bindings document for fpga bridge drivers
>   fpga: add fpga bridge framework
>   fpga: fpga-region: device tree control for FPGA
>   ARM: socfpga: fpga bridge driver support
> 
>  Documentation/ABI/testing/sysfs-class-fpga-bridge  |   11 +
>  .../bindings/fpga/altera-fpga2sdram-bridge.txt |   15 +
>  .../bindings/fpga/altera-hps2fpga-bridge.txt   |   47 ++
>  .../devicetree/bindings/fpga/fpga-region.txt   |  348 +++
>  drivers/fpga/Kconfig   |   21 +
>  drivers/fpga/Makefile  |7 +
>  drivers/fpga/altera-fpga2sdram.c   |  174 
>  drivers/fpga/altera-hps2fpga.c |  213 +
>  drivers/fpga/fpga-bridge.c |  388 +
>  drivers/fpga/fpga-region.c |  460 
> 
>  include/linux/fpga/fpga-bridge.h   |   55 +++
>  11 files changed, 1739 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-fpga-bridge
>  create mode 100644 
> Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
>  create mode 100644 
> Docum

Re: [PATCH v16 0/6] Device Tree support for FPGA programming

[atull]

On Thu, 11 Feb 2016, Rob Herring wrote:

> On Thu, Feb 11, 2016 at 2:49 PM, atull  wrote:
> > On Fri, 5 Feb 2016, at...@opensource.altera.com wrote:
> >
> >> From: Alan Tull 
> >>
> >> v16 Refactors the FPGA Area and FPGA Bus into single thing called an
> >> FPGA Region and eliminates using simple-bus.  I'm using the word
> >> "region" as it's a term is used in the literature of both the major
> >> FPGA manufacturors.
> >>
> >> Changes for v16:
> >> * Refactor the FPGA Area and FPGA Bus into a FPGA Region.
> >> * Don't use simple-bus.
> >> * FPGA Managers and FPGA Bridges are now specified by phandle using the
> >>   "fpga-mgr" and "fpga-bridges" properties.  fpga-bridges can specify
> >>   more than one bridge.
> >> * Device Tree overlays should be targeted to a FPGA Region.
> >> * The overlays need only contain firmware-name and the child nodes.
> >> * To model a system containing >1 partial reconfiguration region,
> >>   an overlay could add FPGA Regions to the base FPGA Regions.
> >> * Child FPGA Regions inherit the parent FGPA Manager, but specify
> >>   their own set of bridges if needes as partial reconfig regions
> >>   will likely need their own bridges.
> >> * All this is discussed in bindings/fpga/fpga-region.txt
> >>
> >> One other highlight:
> >> The little engine that runs this thing is a reconfig notifier
> >> in fpga-region.c.  This notifier that will program an FPGA if a
> >> "firmware-name" property gets added to a fpga-region.  Then
> >> it will call of_platform_populate().  The current behavior in Linux
> >> when a DT overlay is applied is that the reconfig notifications
> >> go out in heirarchical order: first notifications are for the
> >> properties, then notifications for the child nodes.  So an overlay
> >> that adds a 'firmware-name' property and some child nodes to a
> >> fpga-region will cause FPGA programming and child node
> >> populating in the right order.
> >
> > I figured out how to get rid of the reconfig notifier.
> >
> >>
> >> One issue with the dynamic DT stuff:
> >> I've tried returning and error from the notifier if FPGA programming
> >> fails; the error is noted on the console, but the child nodes
> >> get probed anyway.
> >
> > I looked into it further and now I've got a solution for this issue
> > that I can post soon.  I can stop using the DT overlay configfs
> > interface and add a sysfs file for applying an overlay to an FPGA
> > region.  The FPGA region implementation will see the overlay before it
> > becomes part of the live tree.  Then it can do the FPGA programming
> > and see that succeed before the child nodes become part of the live
> > tree.  If FPGA programming fails, the overlay will be rejected before
> > it becomes part of the live tree.  By the time 'firmware-name' and the
> > child nodes show up in the live tree, they will be post-configuration
> > information.
> 
> Um, no. We don't need 2 interfaces for loading overlays from
> userspace. I could see this being a common problem and it needs to be
> solved. But given the configfs interface is not upstream yet, perhaps
> you should worry about that after the current series is in.
> 
> Perhaps we need a pre-add notifier and the core will only load the
> overlay if nothing handles it. Really, a solution without notifiers
> would be preferred. Maybe register handlers with the DT core for
> certain paths.
> 
> Rob
> 

Yes.  If any handler returns error, the overlay doesn't go into the
main tree.  Handler type to be registed could be:

  int pre_add_handler(struct device_node *overlay,
  struct device_node *target)

That gives us the overlay after it's been unflattened and phandles
resolved and the node that it was targeted to.  I was going to
need find_target_node() to be exported, but this avoids that.

Registration could by compatible string, of match, or path.  Path
would be too rigid in my case, I'd want to register for compatible
"fpga-region"

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v16 0/6] Device Tree support for FPGA programming

[atull]

On Thu, 11 Feb 2016, atull wrote:

> On Thu, 11 Feb 2016, Rob Herring wrote:
> 
> > On Thu, Feb 11, 2016 at 2:49 PM, atull  wrote:
> > > On Fri, 5 Feb 2016, at...@opensource.altera.com wrote:
> > >
> > >> From: Alan Tull 
> > >>
> > >> v16 Refactors the FPGA Area and FPGA Bus into single thing called an
> > >> FPGA Region and eliminates using simple-bus.  I'm using the word
> > >> "region" as it's a term is used in the literature of both the major
> > >> FPGA manufacturors.
> > >>
> > >> Changes for v16:
> > >> * Refactor the FPGA Area and FPGA Bus into a FPGA Region.
> > >> * Don't use simple-bus.
> > >> * FPGA Managers and FPGA Bridges are now specified by phandle using the
> > >>   "fpga-mgr" and "fpga-bridges" properties.  fpga-bridges can specify
> > >>   more than one bridge.
> > >> * Device Tree overlays should be targeted to a FPGA Region.
> > >> * The overlays need only contain firmware-name and the child nodes.
> > >> * To model a system containing >1 partial reconfiguration region,
> > >>   an overlay could add FPGA Regions to the base FPGA Regions.
> > >> * Child FPGA Regions inherit the parent FGPA Manager, but specify
> > >>   their own set of bridges if needes as partial reconfig regions
> > >>   will likely need their own bridges.
> > >> * All this is discussed in bindings/fpga/fpga-region.txt
> > >>
> > >> One other highlight:
> > >> The little engine that runs this thing is a reconfig notifier
> > >> in fpga-region.c.  This notifier that will program an FPGA if a
> > >> "firmware-name" property gets added to a fpga-region.  Then
> > >> it will call of_platform_populate().  The current behavior in Linux
> > >> when a DT overlay is applied is that the reconfig notifications
> > >> go out in heirarchical order: first notifications are for the
> > >> properties, then notifications for the child nodes.  So an overlay
> > >> that adds a 'firmware-name' property and some child nodes to a
> > >> fpga-region will cause FPGA programming and child node
> > >> populating in the right order.
> > >
> > > I figured out how to get rid of the reconfig notifier.
> > >
> > >>
> > >> One issue with the dynamic DT stuff:
> > >> I've tried returning and error from the notifier if FPGA programming
> > >> fails; the error is noted on the console, but the child nodes
> > >> get probed anyway.
> > >
> > > I looked into it further and now I've got a solution for this issue
> > > that I can post soon.  I can stop using the DT overlay configfs
> > > interface and add a sysfs file for applying an overlay to an FPGA
> > > region.  The FPGA region implementation will see the overlay before it
> > > becomes part of the live tree.  Then it can do the FPGA programming
> > > and see that succeed before the child nodes become part of the live
> > > tree.  If FPGA programming fails, the overlay will be rejected before
> > > it becomes part of the live tree.  By the time 'firmware-name' and the
> > > child nodes show up in the live tree, they will be post-configuration
> > > information.
> > 
> > Um, no. We don't need 2 interfaces for loading overlays from
> > userspace. I could see this being a common problem and it needs to be
> > solved. But given the configfs interface is not upstream yet, perhaps
> > you should worry about that after the current series is in.
> > 
> > Perhaps we need a pre-add notifier and the core will only load the
> > overlay if nothing handles it. Really, a solution without notifiers
> > would be preferred. Maybe register handlers with the DT core for
> > certain paths.
> > 
> > Rob
> > 
> 
> Yes.  If any handler returns error, the overlay doesn't go into the
> main tree.  Handler type to be registed could be:
> 
>   int pre_add_handler(struct device_node *overlay,
>   struct device_node *target)

And a third parameter of some flags to indicate whether the
overlay is being added or removed.

> 
> That gives us the overlay after it's been unflattened and phandles
> resolved and the node that it was targeted to.  I was going to
> need find_target_node() to be exported, but this avoids that.
> 
> Registration could by compatible string, of match, or path.  Path
> would be too rigid in my case, I'd want to register for compatible
> "fpga-region"
> 
> Alan
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html