Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)

[Alan Tull]

On Wed, 2012-11-07 at 09:06 +0100, Pantelis Antoniou wrote:
 Hi Grant,
 
 On Nov 6, 2012, at 9:45 PM, Grant Likely wrote:
 
  On Tue, Nov 6, 2012 at 7:34 PM, Pantelis Antoniou
  pa...@antoniou-consulting.com wrote:
  On Nov 6, 2012, at 12:14 PM, Grant Likely wrote:
  On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou
  pa...@antoniou-consulting.com wrote:
  For hot-plugging, you need it. Whether kernel code can deal with
  large parts of the DT going away... How about we use the dead
  properties method and move/tag the removed modes as such, and not
  really remove them.
  
  Nodes already use krefs, and I'm thinking about making them kobjects
  so that they appear in sysfs and we'll have some tools to figure out
  when reference counts don't get decremented properly.
  
  
  From the little I've looked in the of code, and the drivers, it's going
  to be pretty bad. I don't think all users take references properly, and
  we have a big global lock for accessing the DT.
  
  I'm a lot more optimistic on this front... I wrote a patch today to
  make the change and took some measurements:
  
  On the versatile express qemu model I measured the free memory with
  /proc/device-tree, with /sys/device-tree, and with both. Here's what I
  found:
  
  /proc/device-tree only: 114776kB free
  /sys/device-tree only: 114792kB free
  both enabled: 114716kB free
  
  The back of a napkin calculation indicates that on this platform
  /proc/devicetree costs 76kB and /sys/device-tree costs 60kb. I'm happy
  to see that using /sys instead of /proc appears to be slightly cheaper
  which makes it easier to justify the change. The diffstat makes me
  even happier:
  
  arch/arm/plat-omap/Kconfig|1 -
  arch/powerpc/platforms/pseries/dlpar.c|   23 ---
  arch/powerpc/platforms/pseries/reconfig.c |   40 --
  drivers/of/Kconfig|8 
  drivers/of/base.c |  116
  
  drivers/of/fdt.c  |5 ++-
  fs/proc/Makefile  |1 -
  fs/proc/proc_devtree.c|   13 +-
  fs/proc/root.c|4 +-
  include/linux/of.h|   35 
  include/linux/proc_fs.h   |   16 
  include/linux/string.h|   11 +
  12 files changed, 107 insertions(+), 166 deletions(-)
  
 
 Interesting. Not so bad then.
 
  There are still a few odds and ends that need to be tidied up, but
  I'll get it out for review shortly. I've not touched the sparc code
  yet, and I need to take another look over the existing OF_DYNAMIC
  code. I think that CONFIG_OF_DYNAMIC will probably go away and the add
  node/property functions will get used by fdt.c and pdt.c for initial
  construction of the device tree.
 
 CONFIG_OF_DYNAMIC never made sense to me. Glad to see the config option
 gone. I'm not totally up to date with the -next dt stuff, but if we're
 there can we rename all the prom_ functions to something saner?
 
I'd be glad to see the dynamic stuff be integrated better than it
currently is.  Currently unflatten_dt_node assumes that the flattened
tree will stay around and not be freed.  So using it to unflatten dynamic
nodes after boot is problematic if the nodes may be later removed.

  
  Adding and removing nodes at runtime as part of the normal operation of
  the system (and not as something that happens once in a blue moon under
  controlled conditions) will uncover lots of bugs.
  
  I'm hoping so! Its time to clean that mess up. :-) Fortunately adding
  nodes is not where we're going to have problems. The problems will be
  on node removal. Addition-only at least means we can have something
  useful before hunting down and squashing all the bugs.
 
 I'll admit that removing nodes is going to be quite rare at least for
 me use cases. I did come across a couple of people that do hot-plugging
 (using something completely different) that could use it for sure.


We have been looking at an approach that would allow adding/deleting
whole nodes under userspace direction.  Such as a variation of the real-time
video processing system example where the FPGA has some IP blocks that are
dsp filters.  The user could rearrange them from
some userspace GUI without having to reboot.  For that to work, device nodes 
that
are removed really have to be freed or there's a memory leak.


  
  So let's think about locking too
  
  Yes, the locking does need to be sorted out.
  
 
 Perhaps come up with a dt-stress test tool/boot time validator?
 
  g.
 
 Regards
 
 -- Pantelis
 
 P.S. Lots of teeth grinding in the ELCE about the lack of a DT preprocessor.
 The pinctrl arguments have been mentioned more than once.
 
 
 ___
 devicetree-discuss mailing list
 devicetree-disc...@lists.ozlabs.org
 

[PATCH 2/3] gpio: dwapb: add support for GPIO interrupts

[Alan Tull]

From: Jamie Iles ja...@jamieiles.com

The controller supports interrupts on bank A (up to 8 interrupt
sources).  Use the generic IRQ chip to implement interrupt support for
this bank.

Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Linus Walleij linus.wall...@stericsson.com
Acked-by: Rob Herring rob.herr...@calxeda.com
Signed-off-by: Jamie Iles ja...@jamieiles.com
---
 drivers/gpio/Kconfig  |2 +-
 drivers/gpio/gpio-dwapb.c |  181 +
 2 files changed, 182 insertions(+), 1 deletion(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index c5e7868..4cc26ed 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -125,7 +125,7 @@ config GPIO_DWAPB
bool Synopsys DesignWare APB GPIO driver
select GPIO_GENERIC
select GENERIC_IRQ_CHIP
-   depends on OF_GPIO
+   depends on OF_GPIO  IRQ_DOMAIN
help
  Say Y or M here to build support for the Synopsys DesignWare APB
  GPIO block.  This requires device tree support.
diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index 3a28697..64c7183 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -10,12 +10,22 @@
 #include linux/init.h
 #include linux/io.h
 #include linux/ioport.h
+#include linux/irq.h
+#include linux/irqdomain.h
 #include linux/module.h
 #include linux/basic_mmio_gpio.h
 #include linux/of.h
 #include linux/of_address.h
+#include linux/of_irq.h
 #include linux/platform_device.h
 
+#define INT_EN_REG_OFFS0x30
+#define INT_MASK_REG_OFFS  0x34
+#define INT_TYPE_REG_OFFS  0x38
+#define INT_POLARITY_REG_OFFS  0x3c
+#define INT_STATUS_REG_OFFS0x40
+#define EOI_REG_OFFS   0x4c
+
 struct dwapb_gpio;
 
 struct dwapb_gpio_bank {
@@ -31,6 +41,8 @@ struct dwapb_gpio {
void __iomem*regs;
struct dwapb_gpio_bank  *banks;
unsigned intnr_banks;
+   struct irq_chip_generic *irq_gc;
+   unsigned long   toggle_edge;
 };
 
 static unsigned int dwapb_gpio_nr_banks(struct device_node *of_node)
@@ -44,6 +56,168 @@ static unsigned int dwapb_gpio_nr_banks(struct device_node 
*of_node)
return nr_banks;
 }
 
+static int dwapb_gpio_to_irq(struct gpio_chip *gc, unsigned offset)
+{
+   struct bgpio_chip *bgc = to_bgpio_chip(gc);
+   struct dwapb_gpio_bank *bank = container_of(bgc, struct
+   dwapb_gpio_bank, bgc);
+   struct dwapb_gpio *gpio = bank-gpio;
+
+   return irq_domain_to_irq(gpio-irq_gc-domain, offset);
+}
+
+static void dwapb_toggle_trigger(struct dwapb_gpio *gpio, unsigned int offs)
+{
+   u32 v = readl(gpio-regs + INT_TYPE_REG_OFFS);
+
+   if (gpio_get_value(gpio-banks[0].bgc.gc.base + offs))
+   v = ~BIT(offs);
+   else
+   v |= BIT(offs);
+
+   writel(v, gpio-regs + INT_TYPE_REG_OFFS);
+}
+
+static void dwapb_irq_handler(u32 irq, struct irq_desc *desc)
+{
+   struct dwapb_gpio *gpio = irq_get_handler_data(irq);
+   u32 irq_status = readl(gpio-regs + INT_STATUS_REG_OFFS);
+
+   while (irq_status) {
+   int irqoffset = fls(irq_status) - 1;
+   int irq = irq_domain_to_irq(gpio-irq_gc-domain, irqoffset);
+
+   generic_handle_irq(irq);
+   irq_status = ~(1  irqoffset);
+
+   if (gpio-toggle_edge  BIT(irqoffset))
+   dwapb_toggle_trigger(gpio, irqoffset);
+   }
+}
+
+static void dwapb_irq_enable(struct irq_data *d)
+{
+   struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+   struct dwapb_gpio *gpio = gc-private;
+
+   u32 val = readl(gpio-regs + INT_EN_REG_OFFS);
+   val |= 1  d-hwirq;
+   writel(val, gpio-regs + INT_EN_REG_OFFS);
+}
+
+static void dwapb_irq_disable(struct irq_data *d)
+{
+   struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+   struct dwapb_gpio *gpio = gc-private;
+
+   u32 val = readl(gpio-regs + INT_EN_REG_OFFS);
+   val = ~(1  d-hwirq);
+   writel(val, gpio-regs + INT_EN_REG_OFFS);
+}
+
+static int dwapb_irq_set_type(struct irq_data *d, u32 type)
+{
+   struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+   struct dwapb_gpio *gpio = gc-private;
+   int bit = d-hwirq;
+   unsigned long level, polarity;
+
+   if (type  ~(IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING |
+IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW))
+   return -EINVAL;
+
+   level = readl(gpio-regs + INT_TYPE_REG_OFFS);
+   polarity = readl(gpio-regs + INT_POLARITY_REG_OFFS);
+
+   gpio-toggle_edge = ~BIT(bit);
+   if (type  IRQ_TYPE_EDGE_BOTH) {
+   gpio-toggle_edge |= BIT(bit);
+   level |= (1  bit);
+   dwapb_toggle_trigger(gpio, bit);
+   } else if (type  IRQ_TYPE_EDGE_RISING) {
+   level |= (1  bit);
+   polarity |= (1  bit);
+   

[PATCH 3/3] use linear irq domain in gpio-dwapb

[Alan Tull]

From: Alan Tull at...@altera.com

 * Changes to get gpio-dwapb (originally v3.2-rc7) driver building and
   working on current kernel.
 * Use linear irq domain.
 * Fix setting irq edge type for 'rising' and 'both'.
 * Support as a loadable module.
 * Use bgpio_chip's spinlock during register access.

Signed-off-by: Alan Tull at...@altera.com
---
 drivers/gpio/Kconfig  |2 +-
 drivers/gpio/gpio-dwapb.c |  235 ++---
 2 files changed, 160 insertions(+), 77 deletions(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 4cc26ed..5fc674a 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -122,7 +122,7 @@ config GPIO_GENERIC_PLATFORM
  Say yes here to support basic platform_device memory-mapped GPIO 
controllers.
 
 config GPIO_DWAPB
-   bool Synopsys DesignWare APB GPIO driver
+   tristate Synopsys DesignWare APB GPIO driver
select GPIO_GENERIC
select GENERIC_IRQ_CHIP
depends on OF_GPIO  IRQ_DOMAIN
diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
index 64c7183..cca97e3 100644
--- a/drivers/gpio/gpio-dwapb.c
+++ b/drivers/gpio/gpio-dwapb.c
@@ -18,6 +18,7 @@
 #include linux/of_address.h
 #include linux/of_irq.h
 #include linux/platform_device.h
+#include linux/spinlock.h
 
 #define INT_EN_REG_OFFS0x30
 #define INT_MASK_REG_OFFS  0x34
@@ -30,7 +31,6 @@ struct dwapb_gpio;
 
 struct dwapb_gpio_bank {
struct bgpio_chip   bgc;
-   unsigned intbank_idx;
boolis_registered;
struct dwapb_gpio   *gpio;
 };
@@ -41,8 +41,9 @@ struct dwapb_gpio {
void __iomem*regs;
struct dwapb_gpio_bank  *banks;
unsigned intnr_banks;
-   struct irq_chip_generic *irq_gc;
unsigned long   toggle_edge;
+   struct irq_domain   *domain;
+   int hwirq;
 };
 
 static unsigned int dwapb_gpio_nr_banks(struct device_node *of_node)
@@ -63,29 +64,30 @@ static int dwapb_gpio_to_irq(struct gpio_chip *gc, unsigned 
offset)
dwapb_gpio_bank, bgc);
struct dwapb_gpio *gpio = bank-gpio;
 
-   return irq_domain_to_irq(gpio-irq_gc-domain, offset);
+   return irq_create_mapping(gpio-domain, offset);
 }
 
 static void dwapb_toggle_trigger(struct dwapb_gpio *gpio, unsigned int offs)
 {
-   u32 v = readl(gpio-regs + INT_TYPE_REG_OFFS);
+   u32 v = readl(gpio-regs + INT_POLARITY_REG_OFFS);
 
if (gpio_get_value(gpio-banks[0].bgc.gc.base + offs))
v = ~BIT(offs);
else
v |= BIT(offs);
 
-   writel(v, gpio-regs + INT_TYPE_REG_OFFS);
+   writel(v, gpio-regs + INT_POLARITY_REG_OFFS);
 }
 
 static void dwapb_irq_handler(u32 irq, struct irq_desc *desc)
 {
struct dwapb_gpio *gpio = irq_get_handler_data(irq);
+   struct irq_chip *chip = irq_desc_get_chip(desc);
u32 irq_status = readl(gpio-regs + INT_STATUS_REG_OFFS);
 
while (irq_status) {
int irqoffset = fls(irq_status) - 1;
-   int irq = irq_domain_to_irq(gpio-irq_gc-domain, irqoffset);
+   int irq = irq_linear_revmap(gpio-domain, irqoffset);
 
generic_handle_irq(irq);
irq_status = ~(1  irqoffset);
@@ -93,44 +95,56 @@ static void dwapb_irq_handler(u32 irq, struct irq_desc 
*desc)
if (gpio-toggle_edge  BIT(irqoffset))
dwapb_toggle_trigger(gpio, irqoffset);
}
+
+   if (chip-irq_eoi)
+   chip-irq_eoi(irq_desc_get_irq_data(desc));
 }
 
 static void dwapb_irq_enable(struct irq_data *d)
 {
-   struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
-   struct dwapb_gpio *gpio = gc-private;
+   struct dwapb_gpio *gpio = irq_data_get_irq_chip_data(d);
+   struct bgpio_chip *bgc = gpio-banks[0].bgc;
+   unsigned long flags;
+   u32 val;
 
-   u32 val = readl(gpio-regs + INT_EN_REG_OFFS);
+   spin_lock_irqsave(bgc-lock, flags);
+   val = readl(gpio-regs + INT_EN_REG_OFFS);
val |= 1  d-hwirq;
writel(val, gpio-regs + INT_EN_REG_OFFS);
+   spin_unlock_irqrestore(bgc-lock, flags);
 }
 
 static void dwapb_irq_disable(struct irq_data *d)
 {
-   struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
-   struct dwapb_gpio *gpio = gc-private;
+   struct dwapb_gpio *gpio = irq_data_get_irq_chip_data(d);
+   struct bgpio_chip *bgc = gpio-banks[0].bgc;
+   unsigned long flags;
+   u32 val;
 
-   u32 val = readl(gpio-regs + INT_EN_REG_OFFS);
+   spin_lock_irqsave(bgc-lock, flags);
+   val = readl(gpio-regs + INT_EN_REG_OFFS);
val = ~(1  d-hwirq);
writel(val, gpio-regs + INT_EN_REG_OFFS);
+   spin_unlock_irqrestore(bgc-lock, flags);
 }
 
 static int dwapb_irq_set_type(struct irq_data *d, u32 type)
 {
-   struct

[PATCH 1/3] gpio: add a driver for the Synopsys DesignWare APB GPIO block

[Alan Tull]

From: Jamie Iles ja...@jamieiles.com

The Synopsys DesignWare block is used in some ARM devices (picoxcell)
and can be configured to provide multiple banks of GPIO pins.

v5: - handle sparse bank population correctly
v3: - depend on rather than select IRQ_DOMAIN
- split IRQ support into a separate patch
v2: - use Rob Herring's irqdomain in generic irq chip patches
- use reg property to indicate bank index
- support irqs on both edges based on LinusW's u300 driver

Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Linus Walleij linus.wall...@stericsson.com
Acked-by: Rob Herring rob.herr...@calxeda.com
Signed-off-by: Jamie Iles ja...@jamieiles.com
---
 .../devicetree/bindings/gpio/snps-dwapb-gpio.txt   |   57 +++
 drivers/gpio/Kconfig   |9 +
 drivers/gpio/Makefile  |1 +
 drivers/gpio/gpio-dwapb.c  |  172 
 4 files changed, 239 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
 create mode 100644 drivers/gpio/gpio-dwapb.c

diff --git a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt 
b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
new file mode 100644
index 000..73adf37
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
@@ -0,0 +1,57 @@
+* Synopsys DesignWare APB GPIO controller
+
+Required properties:
+- compatible : Should be snps,dw-apb-gpio
+- reg : Address and length of the register set for the device
+
+The GPIO controller has a configurable number of banks, each of which are
+represented as child nodes with the following properties:
+
+Required properties:
+- compatible : snps,dw-apb-gpio-bank
+- gpio-controller : Marks the device node as a gpio controller.
+- #gpio-cells : Should be two.  The first cell is the pin number and
+  the second cell is used to specify optional parameters (currently
+  unused).
+- reg : The integer bank index of the bank, a single cell.
+- nr-gpio : The number of pins in the bank, a single cell.
+
+Optional properties:
+- interrupt-controller : The first bank may be configured to be an interrupt
+controller.
+- #interrupt-cells : Specifies the number of cells needed to encode an
+interrupt.  Shall be set to 2.  The first cell defines the interrupt number,
+the second encodes the triger flags encoded as described in
+Documentation/devicetree/bindings/interrupts.txt
+- interrupt-parent : The parent interrupt controller.
+- interrupts : The interrupts to the parent controller raised when GPIOs
+generate the interrupts.
+
+Example:
+
+gpio: gpio@2 {
+   compatible = snps,dw-apb-gpio;
+   reg = 0x2 0x1000;
+   #address-cells = 1;
+   #size-cells = 0;
+
+   banka: gpio-controller@0 {
+   compatible = snps,dw-apb-gpio-bank;
+   gpio-controller;
+   #gpio-cells = 2;
+   nr-gpio = 8;
+   reg = 0;
+   interrupt-controller;
+   #interrupt-cells = 2;
+   interrupt-parent = vic1;
+   interrupts = 0 1 2 3 4 5 6 7;
+   };
+
+   bankb: gpio-controller@1 {
+   compatible = snps,dw-apb-gpio-bank;
+   gpio-controller;
+   #gpio-cells = 2;
+   nr-gpio = 8;
+   reg = 1;
+   };
+};
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b6ed304..c5e7868 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -121,6 +121,15 @@ config GPIO_GENERIC_PLATFORM
help
  Say yes here to support basic platform_device memory-mapped GPIO 
controllers.
 
+config GPIO_DWAPB
+   bool Synopsys DesignWare APB GPIO driver
+   select GPIO_GENERIC
+   select GENERIC_IRQ_CHIP
+   depends on OF_GPIO
+   help
+ Say Y or M here to build support for the Synopsys DesignWare APB
+ GPIO block.  This requires device tree support.
+
 config GPIO_IT8761E
tristate IT8761E GPIO support
depends on X86  # unconditional access to IO space.
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 98e23eb..8de041a 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_GPIO_CS5535) += gpio-cs5535.o
 obj-$(CONFIG_GPIO_DA9052)  += gpio-da9052.o
 obj-$(CONFIG_GPIO_DA9055)  += gpio-da9055.o
 obj-$(CONFIG_ARCH_DAVINCI) += gpio-davinci.o
+obj-$(CONFIG_GPIO_DWAPB)   += gpio-dwapb.o
 obj-$(CONFIG_GPIO_EM)  += gpio-em.o
 obj-$(CONFIG_GPIO_EP93XX)  += gpio-ep93xx.o
 obj-$(CONFIG_GPIO_F7188X)  += gpio-f7188x.o
diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
new file mode 100644
index 000..3a28697
--- /dev/null
+++ b/drivers/gpio/gpio-dwapb.c
@@ -0,0 +1,172 @@
+/*
+ * Copyright (c) 2011 Jamie Iles
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General 

[PATCH 0/3] gpio-dwapb plus irq domain

[Alan Tull]

From: Alan Tull at...@altera.com

Resending Jamie's gpio-dwapb driver patches.  Adding a patch to get 
them building with current irq domain stuff.

Alan Tull


Alan Tull (1):
  use linear irq domain in gpio-dwapb

Jamie Iles (2):
  gpio: add a driver for the Synopsys DesignWare APB GPIO block
  gpio: dwapb: add support for GPIO interrupts

 .../devicetree/bindings/gpio/snps-dwapb-gpio.txt   |   57 +++
 drivers/gpio/Kconfig   |9 +
 drivers/gpio/Makefile  |1 +
 drivers/gpio/gpio-dwapb.c  |  436 
 4 files changed, 503 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
 create mode 100644 drivers/gpio/gpio-dwapb.c

-- 
1.7.9.5


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/1] gpio: add a driver for the Synopsys DesignWare APB GPIO block

[Alan Tull]

From: Jamie Iles ja...@jamieiles.com

The Synopsys DesignWare block is used in some ARM devices (picoxcell)
and can be configured to provide multiple banks of GPIO pins.

Signed-off-by: Alan Tull at...@altera.com

v6: - (atull) squash the set of patches
- use linear irq domain
- build fixes. Original driver was reviewed on v3.2.
- Fix setting irq edge type for 'rising' and 'both'.
- Support as a loadable module.
- Use bgpio_chip's spinlock during register access.
- Clean up register names to match spec
- s/bank/port/ because register names use the word 'port'
- s/nr-gpio/nr-gpios/
- don't get/put the of_node
- remove signoffs/acked-by's because of changes
- other cleanup
v5: - handle sparse bank population correctly
v3: - depend on rather than select IRQ_DOMAIN
- split IRQ support into a separate patch
v2: - use Rob Herring's irqdomain in generic irq chip patches
- use reg property to indicate bank index
- support irqs on both edges based on LinusW's u300 driver
---
 .../devicetree/bindings/gpio/snps-dwapb-gpio.txt   |   57 +++
 drivers/gpio/Kconfig   |9 +
 drivers/gpio/Makefile  |1 +
 drivers/gpio/gpio-dwapb.c  |  458 
 4 files changed, 525 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
 create mode 100644 drivers/gpio/gpio-dwapb.c

diff --git a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt 
b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
new file mode 100644
index 000..f7e2076
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
@@ -0,0 +1,57 @@
+* Synopsys DesignWare APB GPIO controller
+
+Required properties:
+- compatible : Should be snps,dw-apb-gpio
+- reg : Address and length of the register set for the device
+
+The GPIO controller has a configurable number of banks, each of which are
+represented as child nodes with the following properties:
+
+Required properties:
+- compatible : snps,dw-apb-gpio-bank
+- gpio-controller : Marks the device node as a gpio controller.
+- #gpio-cells : Should be two.  The first cell is the pin number and
+  the second cell is used to specify optional parameters (currently
+  unused).
+- reg : The integer bank index of the bank, a single cell.
+- nr-gpios : The number of pins in the bank, a single cell.
+
+Optional properties:
+- interrupt-controller : The first bank may be configured to be an interrupt
+controller.
+- #interrupt-cells : Specifies the number of cells needed to encode an
+interrupt.  Shall be set to 2.  The first cell defines the interrupt number,
+the second encodes the triger flags encoded as described in
+Documentation/devicetree/bindings/interrupts.txt
+- interrupt-parent : The parent interrupt controller.
+- interrupts : The interrupts to the parent controller raised when GPIOs
+generate the interrupts.
+
+Example:
+
+gpio: gpio@2 {
+   compatible = snps,dw-apb-gpio;
+   reg = 0x2 0x1000;
+   #address-cells = 1;
+   #size-cells = 0;
+
+   banka: gpio-controller@0 {
+   compatible = snps,dw-apb-gpio-bank;
+   gpio-controller;
+   #gpio-cells = 2;
+   nr-gpio = 8;
+   reg = 0;
+   interrupt-controller;
+   #interrupt-cells = 2;
+   interrupt-parent = vic1;
+   interrupts = 0 1 2 3 4 5 6 7;
+   };
+
+   bankb: gpio-controller@1 {
+   compatible = snps,dw-apb-gpio-bank;
+   gpio-controller;
+   #gpio-cells = 2;
+   nr-gpio = 8;
+   reg = 1;
+   };
+};
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b6ed304..14ec4e4 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -121,6 +121,15 @@ config GPIO_GENERIC_PLATFORM
help
  Say yes here to support basic platform_device memory-mapped GPIO 
controllers.
 
+config GPIO_DWAPB
+   tristate Synopsys DesignWare APB GPIO driver
+   select GPIO_GENERIC
+   select GENERIC_IRQ_CHIP
+   depends on OF_GPIO  IRQ_DOMAIN
+   help
+ Say Y or M here to build support for the Synopsys DesignWare APB
+ GPIO block.
+
 config GPIO_IT8761E
tristate IT8761E GPIO support
depends on X86  # unconditional access to IO space.
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 98e23eb..8de041a 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_GPIO_CS5535) += gpio-cs5535.o
 obj-$(CONFIG_GPIO_DA9052)  += gpio-da9052.o
 obj-$(CONFIG_GPIO_DA9055)  += gpio-da9055.o
 obj-$(CONFIG_ARCH_DAVINCI) += gpio-davinci.o
+obj-$(CONFIG_GPIO_DWAPB)   += gpio-dwapb.o
 obj-$(CONFIG_GPIO_EM)  += gpio-em.o
 obj-$(CONFIG_GPIO_EP93XX

[PATCH 0/1] gpio: add a driver for the Synopsys DesignWare APB GPIO

[Alan Tull]

From: Alan Tull at...@altera.com

Version 6 - Implementing Sebastian's suggestions.

To make reviewing more to-the-point, I squashed all three commits
into one.  I hope that expedites things rather than getting in the
way, we will see.

I am currently leaving nr-gpios as a required property because I saw a
mailing list comment that that register to read the IP configuration is
not available on earlier versions of the IP.

s/bank/port/ because the register names use the word 'port'

s/nr-gpio/nr-gpios/

I removed previous acked-by's and sign-off-by's as I felt that
it would be weird and sneaky to make lots of changes and keep
them, although it feels like a step backwards.

I didn't want to mess with the interrupt enable/mask stuff so I
left those as separate.

Alan Tull


Jamie Iles (1):
  gpio: add a driver for the Synopsys DesignWare APB GPIO block

 .../devicetree/bindings/gpio/snps-dwapb-gpio.txt   |   57 +++
 drivers/gpio/Kconfig   |9 +
 drivers/gpio/Makefile  |1 +
 drivers/gpio/gpio-dwapb.c  |  458 
 4 files changed, 525 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
 create mode 100644 drivers/gpio/gpio-dwapb.c

-- 
1.7.9.5


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v2 0/1] FPGA subsystem core

[Alan Tull]

On Wed, 2013-10-02 at 17:35 +0200, Michal Simek wrote:

 
 Through firmware interface:
 cat /sys/class/fpga_manager/fpga0/name
 echo -n fpga.bin  /sys/class/fpga_manager/fpga0/firmware
 
 Through sysfs bin file:
 cat /sys/class/fpga_manager/fpga0/fpga_config_state
 echo -n write_init  /sys/class/fpga_manager/fpga0/fpga_config_state
 cat /lib/firmware/fpga.bin  /sys/class/fpga_manager/fpga0/fpga_config_data
 echo -n write_complete  /sys/class/fpga_manager/fpga0/fpga_config_state
 

Hi Michal,

I have v2 working for me with Altera socfpga and had some feedback.

Add me and Dinh as maintainers.

This driver now has two interfaces for programming the image.
I don't think things in the kernel usually have multiple interfaces.

Does the fpga community in general find that the firmware class is
suitable for all our use cases?  I think it only supports the most simple
use cases.

My original fpga framework that you started with supported writing the
fpga device through the devnode, i.e.
cat fpga.bin  /dev/fpga0
I think we should get back to that basic char driver interface like that.
It seems like if you have a char driver, you would open and write to the
devnode instead of adding an attribute under /sys.

The 'flags' implementation is a nice way to do some locking.  But it doesn't
replace the status op to get fpga manager status which vanished in v2.
So please add that back.  Its interface was that catting the 'status'
attribute got a status description from the low level driver such as
'power up phase' or 'reset phase'.  Too useful to just get rid of.

Alan



 Subsystem supports working with phandles for cases where you want to load
 bitstreams for particular device through defined device.
 For example:
 mngr@0 {
   compatible = whatever;
   fpga-mgr = ps7_dev_cfg_0;
   ...
 } ;
 
 With these lines you can get easily load bitstream to the device.
 
 struct fpga_manager *mgr;
 mgr = of_find_fpga_mgr_by_phandle(pdev-dev.of_node, fpga-mgr);
 if (mgr)
   mgr-fpga_firmware_write(mgr, filename);
 
 NOTE: I have added there of_find_fpga_mgr_by_node()
 and of_find_fpga_mgr_by_phandle() but maybe they should be added
 separately to drivers/of/of_fpga.c.
 
 Alessandro: I haven't looked at your FMC cases but maybe this
 could be also worth for your cases.
 
 TODO:
 - Probably make sense to create doc in Documentation folder too.
 - When interface is fine also send zynq devcfg driver
 - Properly test reading (we have problem with zynq devcfg driver now)
 - Not sure if firmware interface also provide option to create
   files from kernel space.
 
 Thanks for your comments,
 Michal
 
 Changes in v2:
 - Remove ! from all error message not to be shouty
 - Fix error codes
 - Add sysfs-class-fpga description
 - Use read/write helper functions with bit protection
 - s/fpga_mgr_status_show/fpga_mgr_status_read/g
 - Do not all end driver status just show core status
 - Extract firmware support to specific sysfs firmware file
 - Add support for sysfs bin attributes (fpga_config_state, fpga_config_data)
 - Allocate space for name dynamically
 - Introduce new flags bits (INIT_DONE, READ, WRITE)
 
 Michal Simek (1):
   fpga: Introduce new fpga subsystem
 
  Documentation/ABI/testing/sysfs-class-fpga |  33 ++
  MAINTAINERS|   7 +
  drivers/Kconfig|   2 +
  drivers/Makefile   |   1 +
  drivers/fpga/Kconfig   |  18 +
  drivers/fpga/Makefile  |   5 +
  drivers/fpga/fpga-mgr.c| 753 
 +
  include/linux/fpga.h   | 110 +
  8 files changed, 929 insertions(+)
  create mode 100644 Documentation/ABI/testing/sysfs-class-fpga
  create mode 100644 drivers/fpga/Kconfig
  create mode 100644 drivers/fpga/Makefile
  create mode 100644 drivers/fpga/fpga-mgr.c
  create mode 100644 include/linux/fpga.h
 
 --
 1.8.2.3
 




--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v2 0/1] FPGA subsystem core

[Alan Tull]

On Fri, 2013-10-04 at 19:44 +0200, Michal Simek wrote:
 On 10/04/2013 06:46 PM, H. Peter Anvin wrote:
  On 10/04/2013 07:28 AM, Michal Simek wrote:
  On 10/04/2013 04:21 PM, H. Peter Anvin wrote:
  Yes; I never got too corner Greg ;)
 
  Greg Kroah-Hartman gre...@linuxfoundation.org wrote:
  On Fri, Oct 04, 2013 at 03:57:57PM +0200, Michal Simek wrote:
  But anyway what was resolution from that meeting?
 
  It never happened, we got distracted by lunch :)
 
  Then why not to have it here?
 
  
  The essential question is if the firmware interface really is
  appropriate for FPGAs.  It definitely has a feel of a square peg in a
  round hole, especially when you consider the myriad ways FPGAs can be
  configured (some persistent, some not, some which takes effect now,
  some which come later, some which involve bytecode interpreters...)
  and considering reconfiguration and partial reconfiguration.
 
 If you look at it in general I believe that there is wide range
 of applications which just contain one bitstream per fpga and the bitstream 
 is replaced
 by newer version in upgrade. For them firmware interface should be pretty 
 useful.
 Just setup firmware name with bitstream and it will be automatically loaded in
 startup phase.
 
 Then there is another set of applications especially in connection to partial 
 reconfiguration
 where this can be done statically by pregenerated partial bitstreams
 or automatically generated on target cpu. For doing everything on the target
 firmware interface is not the best because everything can be handled by user 
 application
 and it is easier just to push this bitstream to do device and not to save it
 to the fs.
 
 I think the question here is if this subsystem could have several interfaces.
 For example Alan is asking for adding char support.
 Does it even make sense to have more interfaces with the same backend driver?

Just for clarification, I'm asking for just one way to write the fpga
image data, not two or three.

I like being able to directly write the fpga image buffer from
userspace; that will support the superset of use cases.  v2 accepts the
binary image data from a sysfs attribute (cat image.bin
 /sys/class/fpga_manager/fpga0/fpga_config_data).  My original fpga
manager framework allowed writing the image data to the device node (cat
image.bin  /dev/fpga0) rather than sysfs. My point is that it that if
you are writing data, that goes to the file ops, not to sysfs
attributes.  sysfs is for text communication (Documentation/sysfs.txt:
Attributes should be ASCII text files...)

 When this is answered then we can talk which one make sense to have.
 In v2 is sysfs and firmware one. Adding char is also easy to do.

Please, not three ways to do the same thing.  If you change from having
the fpga_config_data attribute to having a file_operations' write, that
would be what I think is more standard for char drivers in the kernel,
if I'm not mistaken.


 
 Thanks,
 Michal
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v2 0/1] FPGA subsystem core

[Alan Tull]

On Fri, 2013-10-04 at 17:27 +0200, Michal Simek wrote:
 Hi,
 
 On 10/03/2013 11:46 PM, Alan Tull wrote:
  On Wed, 2013-10-02 at 17:35 +0200, Michal Simek wrote:
  
 
  Through firmware interface:
  cat /sys/class/fpga_manager/fpga0/name
  echo -n fpga.bin  /sys/class/fpga_manager/fpga0/firmware
 
  Through sysfs bin file:
  cat /sys/class/fpga_manager/fpga0/fpga_config_state
  echo -n write_init  /sys/class/fpga_manager/fpga0/fpga_config_state
  cat /lib/firmware/fpga.bin  /sys/class/fpga_manager/fpga0/fpga_config_data
  echo -n write_complete  /sys/class/fpga_manager/fpga0/fpga_config_state
 
  
  Hi Michal,
  
  I have v2 working for me with Altera socfpga and had some feedback.
  
  Add me and Dinh as maintainers.
 
 why not just one? What about you?

That's fine.  Just add Alan Tull at...@altera.com So we can expect
that in v3, right?

  
  This driver now has two interfaces for programming the image.
  I don't think things in the kernel usually have multiple interfaces.
 
 The question here is if this is a problem. i2c create char devices
 and also provide sysfs access too. It is done through notification.

i2c_master_send() is called as the fops write or from an i2c client, but
not by writing data to some attribute under sysfs.  So there aren't two
direct paths from userspace to the i2c core.  I am advocating against
multiple ways for userspace to request/send fpga images for programming.

 
  Does the fpga community in general find that the firmware class is
  suitable for all our use cases?  I think it only supports the most simple
  use cases.
 
 Let's continue with this on that second thread and we will see what happen.

Yes, let's continue this particular discussion on the other thread.

 
 
  My original fpga framework that you started with supported writing the
  fpga device through the devnode, i.e.
  cat fpga.bin  /dev/fpga0
  I think we should get back to that basic char driver interface like that.
  It seems like if you have a char driver, you would open and write to the
  devnode instead of adding an attribute under /sys.
 
 It is the same as above. As you know we can simple add support for char
 device with the current set of functions without changing logic in the driver.
 
  
  The 'flags' implementation is a nice way to do some locking.  But it doesn't
  replace the status op to get fpga manager status which vanished in v2.
  So please add that back.  Its interface was that catting the 'status'
  attribute got a status description from the low level driver such as
  'power up phase' or 'reset phase'.  Too useful to just get rid of.
 
 No problem to add it back but it means that core will loose control
 about values which can be returned back to the user. It is probably better
 to create set of return values.
 
 Thanks,
 Michal
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v2] fpga: Introduce new fpga subsystem

[Alan Tull]

On Fri, 2013-10-04 at 18:28 +0200, Michal Simek wrote:
 On 10/02/2013 07:46 PM, Jason Gunthorpe wrote:
  On Wed, Oct 02, 2013 at 05:35:58PM +0200, Michal Simek wrote:
  
  +What: /sys/class/fpga_manager/fpgadev-id/fpga_config_state
  +Date: October 2013
  +KernelVersion:3.12
  +Contact:  Michal Simek michal.si...@xilinx.com
  +Description:
  +  By reading this file you will get current fpga manager state.
  +  Flag bits are present in include/linux/fpga.h (FPGA_MGR_XX).
  +  By writing to this file you can change fpga manager state.
  +  Valid options are: write_init, write_complete, read_init,
  +  read_complete.
  
  This shouldn't be asymmetric - read/write should be in the same
  format.
  
  I strongly encourage you to use text strings to indicate the state of
  the configuration FSM, and I *really* think you should rework things
  to have an explicit configuration FSM rather than trying to bodge one
  together with a bunch of bit flags.
 
 Any favourite names for states?
 Or ready, write_init, write_complete is enough for now?

Currently the only state I want to attempt to *set* from sysfs would be
reset. 

For Altera fpga, the states I want to *report* are:

static const char *const altera_fpga_state_str[] = {
[ALT_FPGAMGR_STAT_POWER_UP] = power up phase,
[ALT_FPGAMGR_STAT_RESET] = reset phase,
[ALT_FPGAMGR_STAT_CFG] = configuration phase,
[ALT_FPGAMGR_STAT_INIT] = initialization phase,
[ALT_FPGAMGR_STAT_USER_MODE] = user mode,
[ALT_FPGAMGR_STAT_UNKNOWN] = undetermined,
[ALT_FPGAMGR_STAT_POWER_OFF] = powered off,
};

Setting write_init and write_complete explicitly is fine, but not needed
for me.  I'm fine with the driver knowing that if I request to write
data, it knows that it needs to write_init and write_complete.  Either
way works for me here.


 
 Alan: This should be unified way for user to get proper states from the
 driver. It means from my point of view will be better to have set of states
 which this function can return instead of calling origin status function
 where we can't control states for all these drivers.

I agree with both you and Jason on this :)  I agree that it should be
strings, and also that it probably should come from the framework
instead of directly from the low level driver.  The framework should
query the low level driver for state.  Not all vendors' fpgas support
exactly the same set of states, so we can hash out a superset that we
can agree on that fits all our needs (mine are above). 

I think this is separate from your 'flags' implementation.  I like that
implementation for locking, but I want something that actually goes to
the low level driver to find out what state the fpga manager has to
report.

 
  Plus error handling is missing, failures need to be reported back.
 
 Will fix this.
 
  Noticed several typos:
 
 Ah yeah cp. :-(
 
  
  +
  +  if (mgr-mops-read_init) {
  +  ret = mgr-mops-read_init(mgr);
  +  if (ret) {
  +  dev_dbg(mgr-dev, Failed to write_init\n);
  
  read_init
  
  +  if (mgr-mops-write) {
 ^^
  read
  
  +  ret = mgr-mops-read(mgr, buf, count);
  +  if (ret) {
  +  dev_dbg(mgr-dev, Failed to write\n);
   ^
  read
  
  +
  +  if (mgr-mops-write_complete) {
  ^^
  read
  +  ret = mgr-mops-read_complete(mgr);
  +  if (ret) {
  +  dev_dbg(mgr-dev, Failed to write_complete\n);

  read
  
  +static inline int fpga_mgr_write(struct fpga_manager *mgr, const u8 *buf,
  +   ssize_t count)
  +{
  +  int bit, ret;
  +
  +  dev_dbg(mgr-dev, %s %lx\n, __func__, mgr-flags);
  +
  +  /* FPGE init has to be done to be able to continue */
 ^^
  FPGA
  
  +static struct device_attribute fpga_mgr_attrs[] = {
  +  __ATTR(name, S_IRUGO, fpga_mgr_name_show, NULL),
  +  __ATTR(firmware, S_IWUSR, NULL, fpga_mgr_attr_write),
  +  __ATTR(fpga_config_state, S_IRUSR | S_IWUSR,
  + fpga_mgr_status_read, fpga_mgr_status_write),
  +  __ATTR_NULL
  +};
  
  AFAIK it is preferred to use DEVICE_ATTR_RO(), ATTRIBUTE_GROUPS()
  and struct class.dev_groups
  
  eg see this note in linux/device.h
  
  struct class {
  struct device_attribute *dev_attrs; /* use dev_groups 
  instead */
  const struct attribute_group**dev_groups;
  }
  
 
 This will be fixed in v3. I have already changed this.
 
  +  struct fpga_manager *mgr;
  +  int ret;
  +
  +  if (!mops) {
  +  dev_dbg(pdev-dev, Register failed: NO fpga_manager_ops\n);
  +  return -EINVAL;
  +  }
  +
  +  if (!name || !strlen(name)) {
  +  dev_dbg(pdev-dev, Register failed: 

Re: [RFC PATCH] fpga: Introduce new fpga subsystem

[Alan Tull]

On Wed, 2013-09-18 at 14:32 -0600, Jason Gunthorpe wrote:
 On Wed, Sep 18, 2013 at 03:15:17PM -0400, Jason Cooper wrote:
 
  + Jason Gunthorpe
 
 Thanks, looks interesting, we could possibly use this interface if it 
 met our needs..
  
  On Wed, Sep 18, 2013 at 05:56:39PM +0200, Michal Simek wrote:
   This new subsystem should unify all fpga drivers which
   do the same things. Load configuration data to fpga
   or another programmable logic through common interface.
   It doesn't matter if it is MMIO device, gpio bitbanging,
   etc. connection. The point is to have the same
   inteface for these drivers.
 
 So, we have many years of in-field experience with this and this API
 doesn't really match what we do.
 
 Here are the steps we perform, from userspace:
  - Ask kernel to place FPGA into reset and prepare for programming
* Kernel can return an error (eg FPGA failed to erase, etc)
* this is the PROG_N low - DONE high, PROG_N high - INIT_N high
  sequencing on Xilinx chips
  - Ask kernel to load a bitstream.
* Userspace locats the bitstream file to load, and the mmaps it.
* Userspace passes the entire file in a single write() call to the
  kernel which streams it over the configuration bus
* The kernel can report an erro rhere (eg Xilinx can report CRC
error)
  - Ask the kernel to verify that configuration is complete. 
* On Xilinx this wait for done to go high
  - Ask the kernel to release the configuration bus (tristate
all drivers) (or sometimes we have to drive the bus low,
it depends on the bitfile, user space knows what to do)
 
 It is very important that userspace know exactly which step fails
 because the resolution is different. We use this in a manufacturing
 setting, so failures are expected and need quick root cause
 determination.
 
 You could probably address that need by very clearly defining a
 variety of errno values for the various cases. However, it would be a
 disaster if every driver did something a little different :|
 
 Using request_firmware exclusively is not useful for us. We
 format the bitfile with a header that contains our internal tracking
 information. Sometimes we need to bitswap the bitfile. Our userspace
 handles all of this and can pass a bitfile in memory to write().
 
 request_firmware would be horrible to use :)
 
 Our API uses a binary sysfs attribute to stream the FPGA data, you
 might want to consider that.
 
 Regards,
 Jason

The firmware approach is interesting.  It might be less flexible
compared with my original code (see link to git below) that this is
based on.  The original code created a devnode like /dev/fpga0 and a raw
bitstream could be loaded by doing 'cat bitstream  /dev/fpga0'.  Or
some other userspace app could write the /dev/fpga0 to handle any
headers that needed to be added to the bitstream.

This code also creates a set of files under /sys for each separate fpga.
I.e. checking status by looking at /sys/class/fpga/fpag0/status.  It
would be pretty small changes to control reseting the fpga by adding a
'reset' file there also (added first to the framework, and an interface
into the low level fpga manager driver).

I am trying this out with my low level fpga manager driver.  I'm very
curious about your approach and I am wondering whether the firmware
approach will work for us or not.

Will this framework handle more than one fpga at a time?

Is there some way a per-device userspace helper can be added that can
handle adding the headers?  Such that different fpga types get different
helpers?

My fpga framework code is in git at:
http://rocketboards.org/gitweb/?p=linux-socfpga.git;a=commit;h=7b7c04ef3f8589349211bdfe884e42d6b7554b27

and

http://rocketboards.org/gitweb/?p=linux-socfpga.git;a=commit;h=57ee6197d65015620cd6aad435a695ce00a48a8c

Best Regards,
Alan

 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: /sys rules Re: [RFC PATCH] fpga: Introduce new fpga subsystem

[Alan Tull]

On Thu, 2013-09-19 at 07:18 -0700, Greg KH wrote:
 On Thu, Sep 19, 2013 at 04:10:46PM +0200, Michal Simek wrote:
  On 09/19/2013 04:06 PM, Greg KH wrote:
   On Thu, Sep 19, 2013 at 02:52:37PM +0200, Pavel Machek wrote:
   On Thu 2013-09-19 13:22:00, Michal Simek wrote:
   On 09/19/2013 01:17 PM, Pavel Machek wrote:
  
   Status is just there and for my zynq devcfg driver I do export some 
   status
   bits.
  
   root@petalinux:~# cat /sys/class/fpga/fpga0/status
   partial_bitstream_status: 0
   prog_done_status: 1
   dbg_lock_status: 0
   seu_lock_status: 0
   aes_en_lock_status: 0
   aes_status: 0
   seu_status: 0
   spniden_status: 1
   spiden_status: 1
   niden_status: 1
   dbgen_status: 1
   dap_en_status: 7
  
   This is single file? If so, it needs to be changed. Greg is rather
   clear about that.
  
   Don't you have a link to these rules? I have seen any paragraph from 
   Greg
   about it but I forget where was it.
  
   one value per file and there must be documentation in
   Documentation/ for each file are the rules, iirc.
  
   There's Documentation/sysfs-rules.txt, but it does not seem too
   relevant.
   
   Documentation/filesystems/sysfs.txt says it.  It probably should be
   added to sysfs-rules.txt as well, but the odds that anyone ever reads
   the documentation is so low I doubt it's even worth it.
   
   Also, all sysfs files have to be documented in Documentation/ABI/ which
   this patch does not do :(
   
   And yes, multiple values in a single sysfs file is not allowed at all.
   
  
  ok. I will read that. This is output from my fpga end driver - nothing
  what I have sent for review.
  Can you please look at origin patch and tell me what you think about it?
 
 When I return from LinuxCon/Plumbers and catch up on my pending patch
 queue, I will.  It seems that others have already provided good code
 review, so I suggest sending out a new version with their changes
 integrated and not wait for me.

Michal,

I am currently porting my altera fpga driver to work with your changes.
Please go ahead and post your xilinx fpga driver patch, that would help
accelerate my testing and give us a chance to give more feedback quickly
and arrive a satisfactory solution that will work for more of the key
players here.

Thanks,
ALan

 
 thanks,
 
 greg k-h
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] fpga: Introduce new fpga subsystem

[Alan Tull]

  +/**
  + * fpga_mgr_attr_read - Read data from fpga
  + * @dev: Pointer to the device structure
  + * @attr: Pointer to the device attribute structure
  + * @buf: Pointer to the buffer location
  + *
  + * Function reads fpga bitstream and copy them to output buffer
  + *
  + * Returns the number of bytes copied to @buf, a negative error number 
  otherwise
  + */
  +static ssize_t fpga_mgr_attr_read(struct device *dev,
  + struct device_attribute *attr, char *buf)
  +{
  +  struct fpga_manager *mgr = dev_get_drvdata(dev);
  +  ssize_t count;
  +  int ret;
  +
  +  if (mgr  mgr-fpga_read)
  +  ret = mgr-fpga_read(mgr, buf, count);
  +
  +  return ret == 0 ? count : -EPERM;
  
  EPERM isn't the only error return from fpga_read.
 
 Yeah I know. Will revisit all return codes.

Build warning:
/home/atull/repos/linux-socfpga/drivers/fpga/fpga-mgr.c:145:26: warning:
‘ret’ may be used uninitialized in this function [-Wmaybe-uninitialized]


 
  
  
  +/**
  + * fpga_mgr_attr_write - Write data to fpga
  + * @dev: Pointer to the device structure
  + * @attr: Pointer to the device attribute structure
  + * @buf: Pointer to the buffer location with bistream firmware filename
  + * @count: Number of characters in @buf
  + *
  + * @buf contains firmware filename which is loading through firmware
  + * interface and passed to the fpga driver.
  + *
  + * Returns string lenght added to @buf, a negative error number otherwise
  + */
  +static ssize_t fpga_mgr_attr_write(struct device *dev,
  + struct device_attribute *attr,
  + const char *buf, size_t count)
  +{
  +  struct fpga_manager *mgr = dev_get_drvdata(dev);
  +  int ret;
  +
  +  if (mgr  mgr-fpga_write)
  +  ret = mgr-fpga_write(mgr, buf);
  +
  +  return ret == 0 ? strlen(buf) : -EPERM;
  +}
  
  Same -EPERM issue as read
 
 yap

Build warning:
/home/atull/repos/linux-socfpga/drivers/fpga/fpga-mgr.c:236:2: warning:
‘ret’ may be used uninitialized in this function [-Wmaybe-uninitialized]

Best Regards,
Alan



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v7] gpio: add a driver for the Synopsys DesignWare APB GPIO block

[Alan Tull]

From: Jamie Iles ja...@jamieiles.com

The Synopsys DesignWare block is used in some ARM devices (picoxcell)
and can be configured to provide multiple banks of GPIO pins.

Signed-off-by: Alan Tull at...@altera.com

v7: - use irq_generic_chip
- support one irq per gpio line or one irq for many
- s/bank/port/ and other cleanup
v6: - (atull) squash the set of patches
- use linear irq domain
- build fixes. Original driver was reviewed on v3.2.
- Fix setting irq edge type for 'rising' and 'both'.
- Support as a loadable module.
- Use bgpio_chip's spinlock during register access.
- Clean up register names to match spec
- s/bank/port/ because register names use the word 'port'
- s/nr-gpio/nr-gpios/
- don't get/put the of_node
- remove signoffs/acked-by's because of changes
- other cleanup
v5: - handle sparse bank population correctly
v3: - depend on rather than select IRQ_DOMAIN
- split IRQ support into a separate patch
v2: - use Rob Herring's irqdomain in generic irq chip patches
- use reg property to indicate bank index
- support irqs on both edges based on LinusW's u300 driver
---
 .../devicetree/bindings/gpio/snps-dwapb-gpio.txt   |   57 +++
 arch/arm/boot/dts/socfpga.dtsi |6 +-
 drivers/gpio/Kconfig   |9 +
 drivers/gpio/Makefile  |1 +
 drivers/gpio/gpio-dwapb.c  |  426 
 5 files changed, 496 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
 create mode 100644 drivers/gpio/gpio-dwapb.c

diff --git a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt 
b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
new file mode 100644
index 000..131129b
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
@@ -0,0 +1,57 @@
+* Synopsys DesignWare APB GPIO controller
+
+Required properties:
+- compatible : Should be snps,dw-apb-gpio
+- reg : Address and length of the register set for the device
+
+The GPIO controller has a configurable number of ports, each of which are
+represented as child nodes with the following properties:
+
+Required properties:
+- compatible : snps,dw-apb-gpio-port
+- gpio-controller : Marks the device node as a gpio controller.
+- #gpio-cells : Should be two.  The first cell is the pin number and
+  the second cell is used to specify optional parameters (currently
+  unused).
+- reg : The integer port index of the port, a single cell.
+
+Optional properties:
+- interrupt-controller : The first port may be configured to be an interrupt
+controller.
+- #interrupt-cells : Specifies the number of cells needed to encode an
+interrupt.  Shall be set to 2.  The first cell defines the interrupt number,
+the second encodes the triger flags encoded as described in
+Documentation/devicetree/bindings/interrupts.txt
+- interrupt-parent : The parent interrupt controller.
+- interrupts : The interrupts to the parent controller raised when GPIOs
+generate the interrupts.
+- snps,nr-gpios : The number of pins in the port, a single cell.
+
+Example:
+
+gpio: gpio@2 {
+   compatible = snps,dw-apb-gpio;
+   reg = 0x2 0x1000;
+   #address-cells = 1;
+   #size-cells = 0;
+
+   porta: gpio-controller@0 {
+   compatible = snps,dw-apb-gpio-port;
+   gpio-controller;
+   #gpio-cells = 2;
+   nr-gpio = 8;
+   reg = 0;
+   interrupt-controller;
+   #interrupt-cells = 2;
+   interrupt-parent = vic1;
+   interrupts = 0 1 2 3 4 5 6 7;
+   };
+
+   portb: gpio-controller@1 {
+   compatible = snps,dw-apb-gpio-port;
+   gpio-controller;
+   #gpio-cells = 2;
+   nr-gpio = 8;
+   reg = 1;
+   };
+};
diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
index 1c32140..1914350 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -470,7 +470,7 @@
compatible = snps,dw-apb-gpio-port;
gpio-controller;
#gpio-cells = 2;
-   nr-gpios = 29;
+   snps,nr-gpios = 29;
reg = 0;
interrupt-controller;
interrupts = 0 164 4;
@@ -489,7 +489,7 @@
compatible = snps,dw-apb-gpio-port;
gpio-controller;
#gpio-cells = 2;
-   nr-gpios = 29;
+   snps,nr-gpios = 29;
reg = 0

[PATCH v8] add a driver for the Synopsys DesignWare APB GPIO block

[Alan Tull]

From: Alan Tull at...@altera.com

Minor cleanup from v7 as noted below.

Hi Jamie,

I changed the interrupt implementation of your driver to work with the
current kernel (wouldn't build othewise).  Could you please test and
let me know if this will work for you?

Alan

Jamie Iles (1):
  gpio: add a driver for the Synopsys DesignWare APB GPIO block

 .../devicetree/bindings/gpio/snps-dwapb-gpio.txt   |   57 +++
 drivers/gpio/Kconfig   |9 +
 drivers/gpio/Makefile  |1 +
 drivers/gpio/gpio-dwapb.c  |  426 
 4 files changed, 493 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
 create mode 100644 drivers/gpio/gpio-dwapb.c

-- 
1.7.9.5


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v8] gpio: add a driver for the Synopsys DesignWare APB GPIO block

[Alan Tull]

From: Jamie Iles ja...@jamieiles.com

The Synopsys DesignWare block is used in some ARM devices (picoxcell)
and can be configured to provide multiple banks of GPIO pins.

Signed-off-by: Alan Tull at...@altera.com
Reviewed-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com

v8: - remove socfpga.dtsi changes
- minor cleanup in devicetree documentation
v7: - use irq_generic_chip
- support one irq per gpio line or one irq for many
- s/bank/port/ and other cleanup
v6: - (atull) squash the set of patches
- use linear irq domain
- build fixes. Original driver was reviewed on v3.2.
- Fix setting irq edge type for 'rising' and 'both'.
- Support as a loadable module.
- Use bgpio_chip's spinlock during register access.
- Clean up register names to match spec
- s/bank/port/ because register names use the word 'port'
- s/nr-gpio/nr-gpios/
- don't get/put the of_node
- remove signoffs/acked-by's because of changes
- other cleanup
v5: - handle sparse bank population correctly
v3: - depend on rather than select IRQ_DOMAIN
- split IRQ support into a separate patch
v2: - use Rob Herring's irqdomain in generic irq chip patches
- use reg property to indicate bank index
- support irqs on both edges based on LinusW's u300 driver
---
 .../devicetree/bindings/gpio/snps-dwapb-gpio.txt   |   57 +++
 drivers/gpio/Kconfig   |9 +
 drivers/gpio/Makefile  |1 +
 drivers/gpio/gpio-dwapb.c  |  426 
 4 files changed, 493 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
 create mode 100644 drivers/gpio/gpio-dwapb.c

diff --git a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt 
b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
new file mode 100644
index 000..e7f144f
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
@@ -0,0 +1,57 @@
+* Synopsys DesignWare APB GPIO controller
+
+Required properties:
+- compatible : Should be snps,dw-apb-gpio
+- reg : Address and length of the register set for the device
+
+The GPIO controller has a configurable number of ports, each of which are
+represented as child nodes with the following properties:
+
+Required properties:
+- compatible : snps,dw-apb-gpio-port
+- gpio-controller : Marks the device node as a gpio controller.
+- #gpio-cells : Should be two.  The first cell is the pin number and
+  the second cell is used to specify optional parameters (currently
+  unused).
+- reg : The integer port index of the port, a single cell.
+
+Optional properties:
+- interrupt-controller : The first port may be configured to be an interrupt
+controller.
+- #interrupt-cells : Specifies the number of cells needed to encode an
+interrupt.  Shall be set to 2.  The first cell defines the interrupt number,
+the second encodes the triger flags encoded as described in
+Documentation/devicetree/bindings/interrupts.txt
+- interrupt-parent : The parent interrupt controller.
+- interrupts : The interrupts to the parent controller raised when GPIOs
+generate the interrupts.
+- snps,nr-gpios : The number of pins in the port, a single cell.
+
+Example:
+
+gpio: gpio@2 {
+   compatible = snps,dw-apb-gpio;
+   reg = 0x2 0x1000;
+   #address-cells = 1;
+   #size-cells = 0;
+
+   porta: gpio-controller@0 {
+   compatible = snps,dw-apb-gpio-port;
+   gpio-controller;
+   #gpio-cells = 2;
+   snps,nr-gpio = 8;
+   reg = 0;
+   interrupt-controller;
+   #interrupt-cells = 2;
+   interrupt-parent = vic1;
+   interrupts = 0 1 2 3 4 5 6 7;
+   };
+
+   portb: gpio-controller@1 {
+   compatible = snps,dw-apb-gpio-port;
+   gpio-controller;
+   #gpio-cells = 2;
+   snps,nr-gpio = 8;
+   reg = 1;
+   };
+};
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b6ed304..14ec4e4 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -121,6 +121,15 @@ config GPIO_GENERIC_PLATFORM
help
  Say yes here to support basic platform_device memory-mapped GPIO 
controllers.
 
+config GPIO_DWAPB
+   tristate Synopsys DesignWare APB GPIO driver
+   select GPIO_GENERIC
+   select GENERIC_IRQ_CHIP
+   depends on OF_GPIO  IRQ_DOMAIN
+   help
+ Say Y or M here to build support for the Synopsys DesignWare APB
+ GPIO block.
+
 config GPIO_IT8761E
tristate IT8761E GPIO support
depends on X86  # unconditional access to IO space.
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 98e23eb..8de041a 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -22,6 +22,7 @@ obj

[PATCH] gpio: gpio-dwapb size-cells should be two

[Alan Tull]

From: Alan Tull at...@altera.com

Fix size-cells to show use of OF_GPIO_ACTIVE_LOW flag.

Signed-off-by: Alan Tull at...@altera.com
---
 .../devicetree/bindings/gpio/snps-dwapb-gpio.txt   |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt 
b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
index 0934950..91cc90c 100644
--- a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
@@ -12,7 +12,10 @@ represented as child nodes with the following properties:
 Required properties:
 - compatible : snps,dw-apb-gpio-port
 - gpio-controller : Marks the device node as a gpio controller.
-- #gpio-cells : Should be 1.  It is the pin number.
+- #gpio-cells : Should be two.  The first cell is the pin number and
+  the second cell is used to specify the gpio polarity:
+  0 = active high
+  1 = active low
 - reg : The integer port index of the port, a single cell.
 
 Optional properties:
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v12] gpio: add a driver for the Synopsys DesignWare APB GPIO block

[Alan Tull]

From: Jamie Iles ja...@jamieiles.com

The Synopsys DesignWare block is used in some ARM devices (picoxcell)
and can be configured to provide multiple banks of GPIO pins.

Signed-off-by: Jamie Iles ja...@jamieiles.com
Signed-off-by: Alan Tull at...@altera.com
Reviewed-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com

v12: - Add irq_startup/shutdown
 - do irq_create_mapping() in probe, irq_find_mapping() in to_irq()
 - Adjust mappings to show support for 1 gpio per port.
 - gpio-cells = 1
v11: - Use NULL when checking existence of 'interrupts' property
 - Bindings descriptions cleanup
v10: - in documentation nr-gpio - nr-gpios
v9:  - cleanup in dt bindings doc
 - use of_get_child_count()
v8:  - remove socfpga.dtsi changes
 - minor cleanup in devicetree documentation
v7:  - use irq_generic_chip
 - support one irq per gpio line or one irq for many
 - s/bank/port/ and other cleanup
v6:  - (atull) squash the set of patches
 - use linear irq domain
 - build fixes. Original driver was reviewed on v3.2.
 - Fix setting irq edge type for 'rising' and 'both'.
 - Support as a loadable module.
 - Use bgpio_chip's spinlock during register access.
 - Clean up register names to match spec
 - s/bank/port/ because register names use the word 'port'
 - s/nr-gpio/nr-gpios/
 - don't get/put the of_node
 - remove signoffs/acked-by's because of changes
 - other cleanup
v5:  - handle sparse bank population correctly
v3:  - depend on rather than select IRQ_DOMAIN
 - split IRQ support into a separate patch
v2:  - use Rob Herring's irqdomain in generic irq chip patches
 - use reg property to indicate bank index
 - support irqs on both edges based on LinusW's u300 driver
---
 .../devicetree/bindings/gpio/snps-dwapb-gpio.txt   |   57 +++
 drivers/gpio/Kconfig   |9 +
 drivers/gpio/Makefile  |1 +
 drivers/gpio/gpio-dwapb.c  |  438 
 4 files changed, 505 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
 create mode 100644 drivers/gpio/gpio-dwapb.c

diff --git a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt 
b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
new file mode 100644
index 000..0934950
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
@@ -0,0 +1,57 @@
+* Synopsys DesignWare APB GPIO controller
+
+Required properties:
+- compatible : Should contain snps,dw-apb-gpio
+- reg : Address and length of the register set for the device.
+- #address-cells : should be 1 (for addressing port subnodes).
+- #size-cells : should be 0 (port subnodes).
+
+The GPIO controller has a configurable number of ports, each of which are
+represented as child nodes with the following properties:
+
+Required properties:
+- compatible : snps,dw-apb-gpio-port
+- gpio-controller : Marks the device node as a gpio controller.
+- #gpio-cells : Should be 1.  It is the pin number.
+- reg : The integer port index of the port, a single cell.
+
+Optional properties:
+- interrupt-controller : The first port may be configured to be an interrupt
+controller.
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt.  Shall be set to 2.  The first cell defines the interrupt number,
+  the second encodes the triger flags encoded as described in
+  Documentation/devicetree/bindings/interrupts.txt
+- interrupt-parent : The parent interrupt controller.
+- interrupts : The interrupt to the parent controller raised when GPIOs
+  generate the interrupts.
+- snps,nr-gpios : The number of pins in the port, a single cell.
+
+Example:
+
+gpio: gpio@2 {
+   compatible = snps,dw-apb-gpio;
+   reg = 0x2 0x1000;
+   #address-cells = 1;
+   #size-cells = 0;
+
+   porta: gpio-controller@0 {
+   compatible = snps,dw-apb-gpio-port;
+   gpio-controller;
+   #gpio-cells = 1;
+   snps,nr-gpios = 8;
+   reg = 0;
+   interrupt-controller;
+   #interrupt-cells = 2;
+   interrupt-parent = vic1;
+   interrupts = 0;
+   };
+
+   portb: gpio-controller@1 {
+   compatible = snps,dw-apb-gpio-port;
+   gpio-controller;
+   #gpio-cells = 1;
+   snps,nr-gpios = 8;
+   reg = 1;
+   };
+};
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 903f24d..9979017 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -128,6 +128,15 @@ config GPIO_GENERIC_PLATFORM
help
  Say yes here to support basic platform_device memory-mapped GPIO 
controllers.
 
+config GPIO_DWAPB
+   tristate Synopsys DesignWare APB GPIO driver
+   select GPIO_GENERIC
+   select GENERIC_IRQ_CHIP
+   depends on OF_GPIO  IRQ_DOMAIN
+   help
+ Say Y

[PATCH] fix build error in gpio-dwapb patch

[Alan Tull]

From: Alan Tull at...@altera.com

fix build error with this message:
kernel/irq/Kconfig:41:error: recursive dependency detected!
kernel/irq/Kconfig:41:  symbol GENERIC_IRQ_CHIP is selected by GPIO_DWAPB
drivers/gpio/Kconfig:131:   symbol GPIO_DWAPB depends on IRQ_DOMAIN
kernel/irq/Kconfig:46:  symbol IRQ_DOMAIN is selected by GENERIC_IRQ_CHIP

Signed-off-by: Alan Tull at...@altera.com
---
 drivers/gpio/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 9979017..0e524d7 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -132,7 +132,7 @@ config GPIO_DWAPB
tristate Synopsys DesignWare APB GPIO driver
select GPIO_GENERIC
select GENERIC_IRQ_CHIP
-   depends on OF_GPIO  IRQ_DOMAIN
+   depends on OF_GPIO
help
  Say Y or M here to build support for the Synopsys DesignWare APB
  GPIO block.
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v2 0/1] FPGA subsystem core

[Alan Tull]

On Tue, 2013-10-08 at 15:00 +0200, Michal Simek wrote:
 On 10/07/2013 05:07 PM, H. Peter Anvin wrote:
  Special soft IP presenting a PCI device to the host.
 
 ok. It means that you should need just different backend for this device
 which is able to communicate over PCI.
 
 I still can't see why this case should be problematic for this fpga
 manager.
 As Jason pointed if this is just about JTAG emulation and your
 data is in different format then you have to create your backend
 which will support this configuration.
 I will want to look at gpio jtag emulation to be able to program
 different board. We have this support for u-boot and doing in Linux
 should be also possible.
 
 I think the question is if we can live with 2/3 user interfaces.
 I tend to keep firmware one because it is covering a lot of common
 use cases and it can be easily to use.
 And then I don't have any preference if sysfs or char device

The sysfs and char device interface are equal, except I don't think it
is right to write binary data to a sysfs attribute.

The difference between these 3 options is that firmware will work for
some fixed use cases, but either the sysfs or char interface will work
for all the use cases.

Alan


 is better.
 
 Thanks,
 Michal
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v2 0/1] FPGA subsystem core

[Alan Tull]

On Fri, 2013-10-04 at 16:33 -0700, Greg Kroah-Hartman wrote:
 On Fri, Oct 04, 2013 at 11:12:13AM -0700, H. Peter Anvin wrote:
  On 10/04/2013 10:44 AM, Michal Simek wrote:
   
   If you look at it in general I believe that there is wide range of 
   applications which just contain one bitstream per fpga and the 
   bitstream is replaced by newer version in upgrade. For them 
   firmware interface should be pretty useful. Just setup firmware 
   name with bitstream and it will be automatically loaded in startup 
   phase.
   
   Then there is another set of applications especially in connection 
   to partial reconfiguration where this can be done statically by 
   pregenerated partial bitstreams or automatically generated on 
   target cpu. For doing everything on the target firmware interface 
   is not the best because everything can be handled by user 
   application and it is easier just to push this bitstream to do 
   device and not to save it to the fs.
   
   I think the question here is if this subsystem could have several 
   interfaces. For example Alan is asking for adding char support. 
   Does it even make sense to have more interfaces with the same 
   backend driver? When this is answered then we can talk which one 
   make sense to have. In v2 is sysfs and firmware one. Adding char
   is also easy to do.
   
  
  Greg, what do you think?
  
  I agree that the firmware interface makes sense when the use of the
  FPGA is an implementation detail in a fixed hardware configuration,
  but that is a fairly restricted use case all things considered.
 
 Ideally I thought this would be just like firmware, you dump the file
 to the FPGA, it validates it and away you go with a new image running in
 the chip.
 
 But, it sounds like this is much more complicated, so much so that
 configfs might be the correct interface for it, as you can do lots of
 things there, and it is very flexible (some say too flexible...)
 
 A char device, with a zillion different custom ioctls is also a way to
 do it, but one that I really want to avoid as that gets messy really
 quickly.

Hi Greg,

We are discussing a char device that has very few interfaces:
 - a way of writing the image to fpga
 - a way of getting fpga manager status
 - a way of setting fpga manager state

This all looks like standard char driver interface to me.  Writing the
image could be writing to the devnode (cat image.bin  /dev/fpga0). The
status stuff would be sysfs attributes.  All normal stuff any char
driver in the kernel would do.  Why not just go with that?

 
 thanks,
 
 greg k-h
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] fpga: Introduce new fpga subsystem

[Alan Tull]

On Thu, 2013-09-19 at 13:02 +0200, Michal Simek wrote:
 On 09/19/2013 12:08 PM, Pavel Machek wrote:
  Hi!
  
  The firmware approach is interesting.  It might be less flexible
  compared with my original code (see link to git below) that this is
  
  On the other hand... that's the interface world wants, right? To most
  users, fpga bitstream is just a firmware.
 
 It is one nice way how to get data from one place to another and
 it is easy to handle. Using different methods is also possible.
 
  Is there some way a per-device userspace helper can be added that can
  handle adding the headers?  Such that different fpga types get different
  helpers?
  
  https://www.kernel.org/doc/Documentation/firmware_class/README
  
   4), userspace:
   - hotplug: cat appropriate_firmware_image  \
 
  /sys/class/firmware/xxx/data
  
  I assume udev's firmware.sh could be modified to add headers.
  
  But... if same bitstream is expected to work across multiple FPGAs (is
  it?) maybe kernel should hide that difference and provide headers
  itself.
 
 There could be a configuration where you want to load one bitstream
 to more fpgas with the same type. I can imagine this system and use cases.
 
 Thanks,
 Michal
 
 
Hi Michael,

I have ported the altera fpga manager driver to work with your version
of the fpga manager framework.  It works fine if I use the
firmware_class.c's built-in support to load the firmware, but not with a
userspace helper.

I see my helper script get called, but I don't see 'loading' and 'data'
show up under /sys.  I have CONFIG_FW_LOADER_USER_HELPER=y enabled and
have done enough printf debugging to see that there was no failure in
creating the attributes as far as firmware_class.c is concerned.

More details:
I'm taking cues from Documentation/firmware_class here.
This is with the 3.11 kernel.
I have CONFIG_FW_LOADER_USER_HELPER=y enabled.
I have this udev rule:
SUBSYSTEM==firmware, ACTION==add, RUN+=/lib/udev/hotplug-script
My hotplug-script is linux/Documentation/firmware_class/hotplug-script

What I am seeing when I request 'image.rbf' is that my hotplug-script
gets run with this DEVPATH set:
DEVPATH == /devices/soc.0/ff706000.fpgamgr/fpga/fpga0/image.rbf

I added debug to my hotplug-script and it could not find 'loading' or
'data' appearing under /sys anywhere when it got called.  According to
the firmware_class/README, these should appear under
/sys/class/firmware.  However according to the
firmware_class/hotplug-script, they should be under /sys/$DEVPATH.

When I look at firmware_class.c, that code wants these attributes
to show up under the firmware class.  Again, with printf debugging,
I don't see firmware_class.c being unhappy until it decides it has
timed out (which happens quickly).

I was wondering what behavior you were seeing with userspace helpers.

Alan



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] fpga: Introduce new fpga subsystem

[Alan Tull]

 I have ported the altera fpga manager driver to work with your version
 of the fpga manager framework.  It works fine if I use the
 firmware_class.c's built-in support to load the firmware, but not with a
 userspace helper.
 


Hi Michal,

I cleaned up my udev rules and now I see the userspace helper working.
Just adding one udev rule that points to the standard hotplug-script was
sufficient to see the userspace script working nicely.  

All in all, the firmware interface seems pretty easy to use and it gives
us the flexibility to either use the kernel to load the firmware or to
use scripts, so it should work with a variety of use cases.

Since we are arriving at a solution that is suitable for the both of us,
I expect you will be able to add Dinh and myself as maintainers here,
right?  I have no problem with there only being one repo to store
patches for this subsystem.

Alan






--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] fpga: Introduce new fpga subsystem

[Alan Tull]

On Tue, 2013-09-24 at 17:58 +0200, Michal Simek wrote:
 Hi,
 
 On 09/24/2013 05:55 PM, Alan Tull wrote:
  
  I have ported the altera fpga manager driver to work with your version
  of the fpga manager framework.  It works fine if I use the
  firmware_class.c's built-in support to load the firmware, but not with a
  userspace helper.
 
  
  
  Hi Michal,
  
  I cleaned up my udev rules and now I see the userspace helper working.
  Just adding one udev rule that points to the standard hotplug-script was
  sufficient to see the userspace script working nicely.  
  
  All in all, the firmware interface seems pretty easy to use and it gives
  us the flexibility to either use the kernel to load the firmware or to
  use scripts, so it should work with a variety of use cases.
  
  Since we are arriving at a solution that is suitable for the both of us,
  I expect you will be able to add Dinh and myself as maintainers here,
  right?  I have no problem with there only being one repo to store
  patches for this subsystem.
 
 Does it mean that you are able to see loading file there?
 
 Can you share your script?
 
 Thanks,
 Michal
 

Hi Michal,

Yes, I could see /sys/class/fpga/fpga0/image.rbf/loading and 'data' and
a few others (If I was requesting to load 'image.rbf').  It's a nice
interface.

I just used the linux/Documentation/firmware_class/hotplug-script
without modifications.

To enable it:

 * cp linux/Documentation/firmware_class/hotplug-script /lib/udev/

 * chmod 755 /lib/udev/hotplug-script

 * Add this udev rule:
   SUBSYSTEM==firmware, ACTION==add, RUN+=/lib/udev/hotplug-script

 * Check that there aren't other 'firmware' udev rules to get in the
way.

 * Add your firmware files to /usr/lib/hotplug/firmware/ or change that
   path in hotplug-script to point to where your firmware files.

The default hotplug-script doesn't do anything special (that the kernel
couldn't do by itself).  What's great is that it could call another
script that adds headers or does whatever other special un-gzipping or
other massaging that the firmware image needs before it gets loaded.

Regards,
Alan


 
 


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] fpga: Introduce new fpga subsystem

[Alan Tull]

  
   * Add this udev rule:
 SUBSYSTEM==firmware, ACTION==add, RUN+=/lib/udev/hotplug-script
  
   * Check that there aren't other 'firmware' udev rules to get in the
  way.
 
 Hm, don't do that, all modern distros will not do firmware loading
 through udev anymore, so please don't try to add it back in.  The kernel
 handles the loading of the firmware directly, with no need to call any
 usermodehelper program at all.
 
   * Add your firmware files to /usr/lib/hotplug/firmware/ or change that
 path in hotplug-script to point to where your firmware files.
  
  The default hotplug-script doesn't do anything special (that the kernel
  couldn't do by itself).  What's great is that it could call another
  script that adds headers or does whatever other special un-gzipping or
  other massaging that the firmware image needs before it gets loaded.
 
 Only if you need to do something special like this could it justify
 not using the in-kernel firmware loader.  Also note that I think future
 versions of udev will have the udev firmware loader removed entirely, so
 watch out for that.
 

Hi Greg,

Thanks for the heads-up on the direction the firmware class is taking.
Well, that's kind of disappointing.  I was just getting excited about
how flexible the firmware class currently is.  In the simpler fpga use
cases, using the in-kernel loader to load static raw images would be
great.  But we are really excited about exploiting the possibilities
that fpga's give in terms of reconfiguration and partial reconfiguration
on the fly, so we will be needing to do 'special' things (unpacking
images, stripping headers, lots of stuff that userspace would better for
and that we wouldn't want to put into the kernel).  I hope that we can
arrive at a framework with a unified interface that suites this.

Alan

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] fpga: Introduce new fpga subsystem

[Alan Tull]

  
  For the Zynq based product I am working on, we encourage the end user to
  create their own bitstreams to customize their application. So we need
  an easy way for the user to load a bitstream. cat foo.bin  /dev/xdevcfg
  works well for us.
 
 You probably don't care if this will be
 cat foo.bin  /sys/fpga/fpga0/whatever
 (for zynq case you can also run)
 cat foo.bit  /sys/fpga/fpga0/whatever
 
 FYI: Current driver in xilinx repo supports bit format too.
 

Michal,

So your low level driver has a back door to avoid having to use the
firmware class?  I thought the point of this exercise was to have a
framework with a unified interface.

My original framework supported the interface you mention here.

If we are going to have a framework, we should spec in in such a way
that vendors won't be required to add back doors to their drivers in
order to support the use cases they are interested in.

If the firmware interface isn't going to work all the fpga use cases,
then why upstream this patch?  In that case we should go back to the
original implementation and have a unified interface that supports
cat'ing the bitstreams to /sys instead.

My current opinion about the firmware class is that we can use it (and
it is best to use existing interfaces), but it is not really suited for
all the fpga use cases.

The other thing the original fpga framework had was a transport layer.
The intent was to eventually support the same driver (such as a bitbang
driver) no matter what type of gpio lines it was attached to.  It wasn't
really necessary for the fpga manager that is bolted onto a soc, but it
will be needed if you have an fpga that gets programmed from another
fpga that is connected to a soc.  Otherwise you have to write separate
drivers depending on how the fpga is connected.

Alan

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv5 1/3] dts: socfpga: Add bindings for Altera SoC SDRAM controller

[Alan Tull]

On Mon, May 19, 2014 at 2:37 PM, Thor Thayer tthayer.li...@gmail.com wrote:

  diff --git 
  a/Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt 
  b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt
  new file mode 100644
  index 000..8f8746b
  --- /dev/null
  +++ b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt
  @@ -0,0 +1,11 @@
  +Altera SOCFPGA SDRAM Controller
  +
  +Required properties:
  +- compatible : altr,sdr-ctl;
  +- reg : Should contain 1 register ranges(address and length)
  +
  +Example:
  + sdrctl@ffc25000 {
  + compatible = altr,sdr-ctl;
  + reg = 0xffc25000 0x1000;
  + };
  diff --git a/arch/arm/boot/dts/socfpga.dtsi 
  b/arch/arm/boot/dts/socfpga.dtsi
  index df43702..6ce912e 100644
  --- a/arch/arm/boot/dts/socfpga.dtsi
  +++ b/arch/arm/boot/dts/socfpga.dtsi
  @@ -676,6 +676,11 @@
clocks = l4_sp_clk;
};
 
  + sdrctl@ffc25000 {
  + compatible = altr,sdr-ctl, syscon;
 ^^
 
  Get rid of that, too, please.

 Hi Steffan,

 I believe I need to keep the syscon. The same register (ctrlcfg)
 that has the ECC enable bitfield also includes the DRAM configuration
 bitfields that other drivers will want to access (specifically the
 FPGA bridge needs this information). Since this register will be
 shared between drivers,  syscon seems like the best solution.


 Hm, from looking at the documentation of the ctrlcfg I can't really
 understand which bits you would need for the FPGA brigde and why.

Hi Steffen,

Offset 0x80 in the sdr-ctl is the fpgaportrst register.  14 bits
wide, defaults to 0.  When appropriate bits set to 1 in that reg, it
allows an FPGA port to come out of reset (enables that port).  Has no
other effect on SDRAM configuration.

 That all sounds like stuff you would want to set for the specific
 RAM you are dealing with on a specific board.
 What bridge are you talking about? The SDRAM bridge?

Yes, the port allows the FPGA a direct path to the SDRAM.  This one
register the only register in the sdr that the bridge driver needs.


 I can see the problem with the ECC enable, though.

 Regards,
 Steffen


 Hi Steffen,

 I'll get more details from the guy working on the FPGA bridge when he
 gets back in the office. When I started working on EDAC, that register
 had been allocated by the FPGA bridge driver so we decided to use the
 syscon to allow sharing of the register.

 My understanding was that the FPGA bridge as an SDRAM master would
 allow FPGA devices to access the SDRAM.  As part of that process, they
 may want to read the SDRAM configuration.

The FPGA bridge driver doesn't look at the SDRAM configuration.  It
just wants access to this one register so it can enable or disable the
FPGA path to SDRAM.  The only function of this bridge driver is to
enable/disable the bridge.

~Alan


 I'll need to get more details from the driver developer because the
 FPGA driver is in flux while the appropriate driver architecture is
 being discussed.

 Thor


  sdrctl@ffc25000 {
  compatible = altr,sdr-ctl;
  reg = 0xffc25000 0x1000;
  ranges;
 
  edac@ffc2502c {
  compatible = altr,sdram-edac;
  reg = 0xffc2502c 0x50;
  interrupts = 0 39 4;
  };
  };
 
  Then we can later add:
 
  sdr-ports: ports@ffc2507c {
  #reset-cells = 1;
  compatible = altr,sdr-ports;
  reg = 0xffc2507c 0x10;
  clocks = ddr_dqs_clk;
  ...
  };

 --
 Pengutronix e.K.   | |
 Industrial Linux Solutions | http://www.pengutronix.de/  |
 Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
 Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/7 v2] gpio: dwapb: use a second irq chip

[Alan Tull]

On Thu, May 22, 2014 at 4:42 AM, Sebastian Andrzej Siewior
bige...@linutronix.de wrote:
 On 05/16/2014 05:01 PM, Linus Walleij wrote:
 OK this patch is ACKed by Alan so I would like to apply it but:

 Content-Type: text/plain; charset=utf-8
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable

 This is not good. Quoted-printable makes the raw patch look like
 that:

 - int err, irq;
 + int err, irq, i;
 =20
   irq =3D irq_of_parse_and_map(node, 0);

 Notice spurious =20 and =3D encoding.

 Please resend in ISO8859-1 and take this opportunity to add

 doesn't git am handle this on its own?

Neither 'git am' nor 'patch -p1' can apply this patch.  When I was
testing it, I assumed those '=3D' were  a product of my webmail, so I
manually edited the patch to get it to apply.

Alan


 Alan's ACK.

 I will try to add his ack and tell git resent the patch.

 Yours,
 Linus Walleij

 Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv5 1/3] dts: socfpga: Add bindings for Altera SoC SDRAM controller

[Alan Tull]

On Tue, May 27, 2014 at 2:11 AM, Steffen Trumtrar
s.trumt...@pengutronix.de wrote:
 On Wed, May 21, 2014 at 10:38:34AM -0500, Thor Thayer wrote:
 On Tue, May 20, 2014 at 9:44 AM, Steffen Trumtrar
 s.trumt...@pengutronix.de wrote:
  Hi!
 
  On Tue, May 20, 2014 at 09:31:06AM -0500, Alan Tull wrote:
  On Mon, May 19, 2014 at 2:37 PM, Thor Thayer tthayer.li...@gmail.com 
  wrote:
 
diff --git 
a/Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt 
b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt
new file mode 100644
index 000..8f8746b
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt
@@ -0,0 +1,11 @@
+Altera SOCFPGA SDRAM Controller
+
+Required properties:
+- compatible : altr,sdr-ctl;
+- reg : Should contain 1 register ranges(address and length)
+
+Example:
+ sdrctl@ffc25000 {
+ compatible = altr,sdr-ctl;
+ reg = 0xffc25000 0x1000;
+ };
diff --git a/arch/arm/boot/dts/socfpga.dtsi 
b/arch/arm/boot/dts/socfpga.dtsi
index df43702..6ce912e 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -676,6 +676,11 @@
  clocks = l4_sp_clk;
  };
   
+ sdrctl@ffc25000 {
+ compatible = altr,sdr-ctl, syscon;
   ^^
   
Get rid of that, too, please.
  
   Hi Steffan,
  
   I believe I need to keep the syscon. The same register (ctrlcfg)
   that has the ECC enable bitfield also includes the DRAM configuration
   bitfields that other drivers will want to access (specifically the
   FPGA bridge needs this information). Since this register will be
   shared between drivers,  syscon seems like the best solution.
  
  
   Hm, from looking at the documentation of the ctrlcfg I can't really
   understand which bits you would need for the FPGA brigde and why.
 
  Hi Steffen,
 
  Offset 0x80 in the sdr-ctl is the fpgaportrst register.  14 bits
  wide, defaults to 0.  When appropriate bits set to 1 in that reg, it
  allows an FPGA port to come out of reset (enables that port).  Has no
  other effect on SDRAM configuration.
 
   That all sounds like stuff you would want to set for the specific
   RAM you are dealing with on a specific board.
   What bridge are you talking about? The SDRAM bridge?
 
  Yes, the port allows the FPGA a direct path to the SDRAM.  This one
  register the only register in the sdr that the bridge driver needs.
 
 
  So, what I suggested down ...
 
  
   I can see the problem with the ECC enable, though.
  
   Regards,
   Steffen
  
  
sdrctl@ffc25000 {
compatible = altr,sdr-ctl;
reg = 0xffc25000 0x1000;
ranges;
   
edac@ffc2502c {
compatible = altr,sdram-edac;
reg = 0xffc2502c 0x50;
interrupts = 0 39 4;
};
};
   
Then we can later add:
   
sdr-ports: ports@ffc2507c {
#reset-cells = 1;
compatible = altr,sdr-ports;
reg = 0xffc2507c 0x10;
clocks = ddr_dqs_clk;
...
};
 
 
  ... here should work. No?! Just a simple driver that registers with the
  reset-framework. I would add 0x7c to that driver and than that driver could
  configure the port and let it out of reset.
 
  I have done the same thing for the other 3 bridges, but am not finished 
  yet.
  Especially the GPV-stuff needs to at least be able to be added later if 
  not now.
 

 Hi Thor!

 I'm not clear on how the EDAC driver will interact with the registers
 allocated to the SDRAM controller. If the group of registers from
 0xffc25000 to 0xffc26000 is exclusively allocated to the SDRAM
 controller, how does the EDAC driver cleanly access that single
 register inside this range?


 The compatible in the example is wrong. I didn't mean to map the whole 
 address space
 to some driver.
 I think for the configuration register syscon is the right approach. It is a
 bag of bits that don't necessitate an own driver, so syscon is perfect.

 So, let me change my proposal to

 sdr-ctl: sdram@ffc25000 {
 compatible = altr,sdr-ctl, syscon;
 reg = 0xffc25000 0x1;
 };

 edac: edac@ffc2502c {
 compatible = altr,sdram-edac;
 reg = 0xffc2502c 0x50;
 interrupts = 0 39 4;
 config = sdr-ctl;
 ...
 };

 sdr-ports: ports@ffc2507c

Re: [PATCHv5 1/3] dts: socfpga: Add bindings for Altera SoC SDRAM controller

[Alan Tull]

On Tue, May 27, 2014 at 2:42 PM, Steffen Trumtrar
s.trumt...@pengutronix.de wrote:
 On Tue, May 27, 2014 at 02:12:17PM -0500, Alan Tull wrote:
 On Tue, May 27, 2014 at 2:11 AM, Steffen Trumtrar
 s.trumt...@pengutronix.de wrote:
  On Wed, May 21, 2014 at 10:38:34AM -0500, Thor Thayer wrote:
  On Tue, May 20, 2014 at 9:44 AM, Steffen Trumtrar
  s.trumt...@pengutronix.de wrote:
   Hi!
  
   On Tue, May 20, 2014 at 09:31:06AM -0500, Alan Tull wrote:
   On Mon, May 19, 2014 at 2:37 PM, Thor Thayer tthayer.li...@gmail.com 
   wrote:
  
 diff --git 
 a/Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt
  
 b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt
 new file mode 100644
 index 000..8f8746b
 --- /dev/null
 +++ 
 b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt
 @@ -0,0 +1,11 @@
 +Altera SOCFPGA SDRAM Controller
 +
 +Required properties:
 +- compatible : altr,sdr-ctl;
 +- reg : Should contain 1 register ranges(address and length)
 +
 +Example:
 + sdrctl@ffc25000 {
 + compatible = altr,sdr-ctl;
 + reg = 0xffc25000 0x1000;
 + };
 diff --git a/arch/arm/boot/dts/socfpga.dtsi 
 b/arch/arm/boot/dts/socfpga.dtsi
 index df43702..6ce912e 100644
 --- a/arch/arm/boot/dts/socfpga.dtsi
 +++ b/arch/arm/boot/dts/socfpga.dtsi
 @@ -676,6 +676,11 @@
   clocks = l4_sp_clk;
   };

 + sdrctl@ffc25000 {
 + compatible = altr,sdr-ctl, syscon;
^^

 Get rid of that, too, please.
   
Hi Steffan,
   
I believe I need to keep the syscon. The same register (ctrlcfg)
that has the ECC enable bitfield also includes the DRAM 
configuration
bitfields that other drivers will want to access (specifically the
FPGA bridge needs this information). Since this register will be
shared between drivers,  syscon seems like the best solution.
   
   
Hm, from looking at the documentation of the ctrlcfg I can't really
understand which bits you would need for the FPGA brigde and why.
  
   Hi Steffen,
  
   Offset 0x80 in the sdr-ctl is the fpgaportrst register.  14 bits
   wide, defaults to 0.  When appropriate bits set to 1 in that reg, it
   allows an FPGA port to come out of reset (enables that port).  Has no
   other effect on SDRAM configuration.
  
That all sounds like stuff you would want to set for the specific
RAM you are dealing with on a specific board.
What bridge are you talking about? The SDRAM bridge?
  
   Yes, the port allows the FPGA a direct path to the SDRAM.  This one
   register the only register in the sdr that the bridge driver needs.
  
  
   So, what I suggested down ...
  
   
I can see the problem with the ECC enable, though.
   
Regards,
Steffen
   
   
 sdrctl@ffc25000 {
 compatible = altr,sdr-ctl;
 reg = 0xffc25000 0x1000;
 ranges;

 edac@ffc2502c {
 compatible = altr,sdram-edac;
 reg = 0xffc2502c 0x50;
 interrupts = 0 39 4;
 };
 };

 Then we can later add:

 sdr-ports: ports@ffc2507c {
 #reset-cells = 1;
 compatible = altr,sdr-ports;
 reg = 0xffc2507c 0x10;
 clocks = ddr_dqs_clk;
 ...
 };
  
  
   ... here should work. No?! Just a simple driver that registers with the
   reset-framework. I would add 0x7c to that driver and than that driver 
   could
   configure the port and let it out of reset.
  
   I have done the same thing for the other 3 bridges, but am not finished 
   yet.
   Especially the GPV-stuff needs to at least be able to be added later if 
   not now.
  
 
  Hi Thor!
 
  I'm not clear on how the EDAC driver will interact with the registers
  allocated to the SDRAM controller. If the group of registers from
  0xffc25000 to 0xffc26000 is exclusively allocated to the SDRAM
  controller, how does the EDAC driver cleanly access that single
  register inside this range?
 
 
  The compatible in the example is wrong. I didn't mean to map the whole 
  address space
  to some driver.
  I think for the configuration register syscon is the right approach. It is 
  a
  bag of bits that don't necessitate an own driver, so syscon is perfect.
 
  So, let me change my proposal to
 
  sdr-ctl: sdram@ffc25000 {
  compatible = altr,sdr-ctl, syscon;
  reg

Re: [PATCHv5 1/3] dts: socfpga: Add bindings for Altera SoC SDRAM controller

[Alan Tull]

On Wed, May 28, 2014 at 2:01 AM, Steffen Trumtrar
s.trumt...@pengutronix.de wrote:
 On Tue, May 27, 2014 at 03:57:47PM -0500, Alan Tull wrote:
 On Tue, May 27, 2014 at 2:42 PM, Steffen Trumtrar
 s.trumt...@pengutronix.de wrote:
  On Tue, May 27, 2014 at 02:12:17PM -0500, Alan Tull wrote:
  On Tue, May 27, 2014 at 2:11 AM, Steffen Trumtrar
  s.trumt...@pengutronix.de wrote:
   On Wed, May 21, 2014 at 10:38:34AM -0500, Thor Thayer wrote:
   On Tue, May 20, 2014 at 9:44 AM, Steffen Trumtrar
   s.trumt...@pengutronix.de wrote:
Hi!
   
On Tue, May 20, 2014 at 09:31:06AM -0500, Alan Tull wrote:
On Mon, May 19, 2014 at 2:37 PM, Thor Thayer 
tthayer.li...@gmail.com wrote:
   
  diff --git 
  a/Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt
   
  b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt
  new file mode 100644
  index 000..8f8746b
  --- /dev/null
  +++ 
  b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram.txt
  @@ -0,0 +1,11 @@
  +Altera SOCFPGA SDRAM Controller
  +
  +Required properties:
  +- compatible : altr,sdr-ctl;
  +- reg : Should contain 1 register ranges(address and length)
  +
  +Example:
  + sdrctl@ffc25000 {
  + compatible = altr,sdr-ctl;
  + reg = 0xffc25000 0x1000;
  + };
  diff --git a/arch/arm/boot/dts/socfpga.dtsi 
  b/arch/arm/boot/dts/socfpga.dtsi
  index df43702..6ce912e 100644
  --- a/arch/arm/boot/dts/socfpga.dtsi
  +++ b/arch/arm/boot/dts/socfpga.dtsi
  @@ -676,6 +676,11 @@
clocks = l4_sp_clk;
};
 
  + sdrctl@ffc25000 {
  + compatible = altr,sdr-ctl, syscon;
 ^^
 
  Get rid of that, too, please.

 Hi Steffan,

 I believe I need to keep the syscon. The same register 
 (ctrlcfg)
 that has the ECC enable bitfield also includes the DRAM 
 configuration
 bitfields that other drivers will want to access (specifically 
 the
 FPGA bridge needs this information). Since this register will be
 shared between drivers,  syscon seems like the best solution.


 Hm, from looking at the documentation of the ctrlcfg I can't 
 really
 understand which bits you would need for the FPGA brigde and why.
   
Hi Steffen,
   
Offset 0x80 in the sdr-ctl is the fpgaportrst register.  14 bits
wide, defaults to 0.  When appropriate bits set to 1 in that reg, it
allows an FPGA port to come out of reset (enables that port).  Has 
no
other effect on SDRAM configuration.
   
 That all sounds like stuff you would want to set for the specific
 RAM you are dealing with on a specific board.
 What bridge are you talking about? The SDRAM bridge?
   
Yes, the port allows the FPGA a direct path to the SDRAM.  This one
register the only register in the sdr that the bridge driver needs.
   
   
So, what I suggested down ...
   

 I can see the problem with the ECC enable, though.

 Regards,
 Steffen


  sdrctl@ffc25000 {
  compatible = altr,sdr-ctl;
  reg = 0xffc25000 0x1000;
  ranges;
 
  edac@ffc2502c {
  compatible = 
  altr,sdram-edac;
  reg = 0xffc2502c 0x50;
  interrupts = 0 39 4;
  };
  };
 
  Then we can later add:
 
  sdr-ports: ports@ffc2507c {
  #reset-cells = 1;
  compatible = altr,sdr-ports;
  reg = 0xffc2507c 0x10;
  clocks = ddr_dqs_clk;
  ...
  };
   
   
... here should work. No?! Just a simple driver that registers with 
the
reset-framework. I would add 0x7c to that driver and than that 
driver could
configure the port and let it out of reset.
   
I have done the same thing for the other 3 bridges, but am not 
finished yet.
Especially the GPV-stuff needs to at least be able to be added later 
if not now.
   
  
   Hi Thor!
  
   I'm not clear on how the EDAC driver will interact with the registers
   allocated to the SDRAM controller. If the group of registers from
   0xffc25000 to 0xffc26000 is exclusively allocated to the SDRAM
   controller, how does the EDAC driver cleanly access that single
   register inside this range?
  
  
   The compatible in the example is wrong. I didn't mean to map the whole 
   address space
   to some driver

Re: [PATCH 6/7 v2] gpio: dwapb: use a second irq chip

[Alan Tull]

On Fri, May 9, 2014 at 6:46 AM, Linus Walleij linus.wall...@linaro.org wrote:
 On Wed, Apr 30, 2014 at 1:13 PM, Sebastian Andrzej Siewior
 bige...@linutronix.de wrote:

 Right new have one irq chip running always in level mode. It would nicer
 to have two irq chips where one is handling level type interrupts and
 the other one is doing edge interrupts. So we can have at runtime two users
 where one is using edge and the other level.

 Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
 ---
 I am very sorry for the delay. I assumed that I've already fixed the
 patch sent it out. Just realized that it was not the case.

 v1…v2:
 - using the lopp again but breaking the assignment of type and
   handler out of the loop as suggested by delicious quinoa.

 Can I have an ACK from Jamie || Alan on this patch so I can apply
 it?

 Yours,
 Linus Walleij

Yes

Acked-by: Alan Tull delicious.qui...@gmail.com

Alan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v9] gpio: add a driver for Synopsys DesignWare APB GPIO

[Alan Tull]

From: Alan Tull at...@altera.com

Hi Linus,

If you don't have any further comments, can you take this patch?

Alan

Jamie Iles (1):
  gpio: add a driver for the Synopsys DesignWare APB GPIO block

 .../devicetree/bindings/gpio/snps-dwapb-gpio.txt   |   59 +++
 drivers/gpio/Kconfig   |9 +
 drivers/gpio/Makefile  |1 +
 drivers/gpio/gpio-dwapb.c  |  415 
 4 files changed, 484 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
 create mode 100644 drivers/gpio/gpio-dwapb.c

-- 
1.7.9.5


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v9] gpio: add a driver for the Synopsys DesignWare APB GPIO block

[Alan Tull]

From: Jamie Iles ja...@jamieiles.com

The Synopsys DesignWare block is used in some ARM devices (picoxcell)
and can be configured to provide multiple banks of GPIO pins.

Signed-off-by: Jamie Iles ja...@jamieiles.com
Signed-off-by: Alan Tull at...@altera.com
Reviewed-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com

v9: - cleanup in dt bindings doc
- use of_get_child_count()
v8: - remove socfpga.dtsi changes
- minor cleanup in devicetree documentation
v7: - use irq_generic_chip
- support one irq per gpio line or one irq for many
- s/bank/port/ and other cleanup
v6: - (atull) squash the set of patches
- use linear irq domain
- build fixes. Original driver was reviewed on v3.2.
- Fix setting irq edge type for 'rising' and 'both'.
- Support as a loadable module.
- Use bgpio_chip's spinlock during register access.
- Clean up register names to match spec
- s/bank/port/ because register names use the word 'port'
- s/nr-gpio/nr-gpios/
- don't get/put the of_node
- remove signoffs/acked-by's because of changes
- other cleanup
v5: - handle sparse bank population correctly
v3: - depend on rather than select IRQ_DOMAIN
- split IRQ support into a separate patch
v2: - use Rob Herring's irqdomain in generic irq chip patches
- use reg property to indicate bank index
- support irqs on both edges based on LinusW's u300 driver
---
 .../devicetree/bindings/gpio/snps-dwapb-gpio.txt   |   59 +++
 drivers/gpio/Kconfig   |9 +
 drivers/gpio/Makefile  |1 +
 drivers/gpio/gpio-dwapb.c  |  415 
 4 files changed, 484 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
 create mode 100644 drivers/gpio/gpio-dwapb.c

diff --git a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt 
b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
new file mode 100644
index 000..2d5eca6
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
@@ -0,0 +1,59 @@
+* Synopsys DesignWare APB GPIO controller
+
+Required properties:
+- compatible : Should contain snps,dw-apb-gpio
+- reg : Address and length of the register set for the device
+
+The GPIO controller has a configurable number of ports, each of which are
+represented as child nodes with the following properties:
+
+Required properties:
+- compatible : snps,dw-apb-gpio-port
+- gpio-controller : Marks the device node as a gpio controller.
+- #gpio-cells : Should be two.  The first cell is the pin number and
+  the second cell is used to specify optional parameters (currently
+  unused).
+- reg : The integer port index of the port, a single cell.
+- #address-cells : should be 1.
+- #size-cells : should be 0.
+
+Optional properties:
+- interrupt-controller : The first port may be configured to be an interrupt
+controller.
+- #interrupt-cells : Specifies the number of cells needed to encode an
+interrupt.  Shall be set to 2.  The first cell defines the interrupt number,
+the second encodes the triger flags encoded as described in
+Documentation/devicetree/bindings/interrupts.txt
+- interrupt-parent : The parent interrupt controller.
+- interrupts : The interrupts to the parent controller raised when GPIOs
+generate the interrupts.
+- snps,nr-gpios : The number of pins in the port, a single cell.
+
+Example:
+
+gpio: gpio@2 {
+   compatible = snps,dw-apb-gpio;
+   reg = 0x2 0x1000;
+   #address-cells = 1;
+   #size-cells = 0;
+
+   porta: gpio-controller@0 {
+   compatible = snps,dw-apb-gpio-port;
+   gpio-controller;
+   #gpio-cells = 2;
+   snps,nr-gpio = 8;
+   reg = 0;
+   interrupt-controller;
+   #interrupt-cells = 2;
+   interrupt-parent = vic1;
+   interrupts = 0, 1, 2, 3, 4, 5, 6, 7;
+   };
+
+   portb: gpio-controller@1 {
+   compatible = snps,dw-apb-gpio-port;
+   gpio-controller;
+   #gpio-cells = 2;
+   snps,nr-gpio = 8;
+   reg = 1;
+   };
+};
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 0f0..17760dd 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -121,6 +121,15 @@ config GPIO_GENERIC_PLATFORM
help
  Say yes here to support basic platform_device memory-mapped GPIO 
controllers.
 
+config GPIO_DWAPB
+   tristate Synopsys DesignWare APB GPIO driver
+   select GPIO_GENERIC
+   select GENERIC_IRQ_CHIP
+   depends on OF_GPIO  IRQ_DOMAIN
+   help
+ Say Y or M here to build support for the Synopsys DesignWare APB
+ GPIO block.
+
 config GPIO_IT8761E
tristate IT8761E GPIO support
depends on X86  # unconditional access to IO

Re: [PATCH 1/7] ARM: dts: socfpga: add gpio pieces

[Alan Tull]

On Mon, May 5, 2014 at 5:02 PM, Olof Johansson o...@lixom.net wrote:
 Hi,

 I saw this patch as it came in through Dinh's pull request, see below:


 On Sat, Mar 22, 2014 at 9:16 AM, Sebastian Andrzej Siewior
 bige...@linutronix.de wrote:
 The cycloneV has three gpio controllers, the first two with 29 gpios, the 
 last
 one with 27. This patch adds the three controller with the gpio driver which 
 is
 now sitting the gpio tree.

 Cc: devicet...@vger.kernel.org
 Acked-by: Alan Tull at...@altera.com
 Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
 ---
 v1…v2:
 - #gpio-cells = 2
 - third gpio block has now only 27 gpios

  arch/arm/boot/dts/socfpga.dtsi | 64 
 ++
  1 file changed, 64 insertions(+)

 diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
 index 537f1a5..2a84e67 100644
 --- a/arch/arm/boot/dts/socfpga.dtsi
 +++ b/arch/arm/boot/dts/socfpga.dtsi
 @@ -463,6 +463,70 @@
 status = disabled;
 };

 +   gpio@ff708000 {
 +   #address-cells = 1;
 +   #size-cells = 0;
 +   compatible = snps,dw-apb-gpio;
 +   reg = 0xff708000 0x1000;
 +   clocks = per_base_clk;
 +   status = disabled;
 +
 +   gpio0: gpio-controller@0 {
 +   compatible = snps,dw-apb-gpio-port;
 +   gpio-controller;
 +   #gpio-cells = 2;
 +   snps,nr-gpios = 29;
 +   reg = 0;
 +   interrupt-controller;
 +   #interrupt-cells = 2;
 +   interrupts = 0 164 4;
 +   };
 +   };

 This is an odd setup. We usually would have it all in one node, since
 the @ff708000 is the GPIO controller, instead of adding a subnode with
 the actual GPIO info.

 So I would have expected something more like:


 gpio0: gpio-controller@ff708000 {
#address-cells = 1;
#size-cells = 0;
compatible = snps,dw-apb-gpio;
reg = 0xff708000 0x1000;
interrupts = 0 164 4;
   clocks = per_base_clk;
status = disabled;
gpio-controller;
#gpio-cells = 2;
snps,nr-gpios = 29;
interrupt-controller;
#interrupt-cells = 2;
};


 ... or is there some underlying reason for having the two-layer
 approach that isn't obvious from this device tree?


 -Olof

The synopsys gpio ip can have 1, 2, or 3 gpio ports of varying widths
per IP block.  The simpler bindings assume one gpio port per IP block.

Alan Tull
aka
delicious quinoa
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCHv7 2/3] devicetree: Addition of the Altera SDRAM EDAC.

[Alan Tull]

On Wed, Jul 9, 2014 at 3:07 PM, Thor Thayer tthayer.li...@gmail.com wrote:

 On Thu, Jun 26, 2014 at 4:45 AM, Mark Rutland mark.rutl...@arm.com wrote:
  On Wed, Jun 25, 2014 at 10:15:26PM +0100, ttha...@altera.com wrote:
  From: Thor Thayer ttha...@altera.com
 
  Add the Altera SDRAM EDAC bindings and device tree changes to the Altera 
  SoC project.
 
  Signed-off-by: Thor Thayer ttha...@altera.com
  ---
  v2: Changes to SoC EDAC source code.
 
  v3: Fix typo in device tree documentation.
 
  v4,v5: No changes - bump version for consistency.
 
  v6: Assign ECC registers in SDRAM controller to EDAC
 
  v7: Fix SDRAM EDAC base address.
  ---
   .../bindings/arm/altera/socfpga-sdram-edac.txt |   15 +++
   arch/arm/boot/dts/socfpga.dtsi |6 ++
   2 files changed, 21 insertions(+)
   create mode 100644 
  Documentation/devicetree/bindings/arm/altera/socfpga-sdram-edac.txt
 
  diff --git 
  a/Documentation/devicetree/bindings/arm/altera/socfpga-sdram-edac.txt 
  b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram-edac.txt
  new file mode 100644
  index 000..d68e033
  --- /dev/null
  +++ b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram-edac.txt
  @@ -0,0 +1,15 @@
  +Altera SOCFPGA SDRAM Error Detection  Correction [EDAC]
  +
  +Required properties:
  +- compatible : should contain altr,sdram-edac;
  +- reg : should contain the ECC register range in sdram
  +controller (address and length).
  +- interrupts : Should contain the SDRAM ECC IRQ in the
  + appropriate format for the IRQ controller.
  +
  +Example:
  + sdramedac@ffc2502c {
  + compatible = altr,sdram-edac;
  + reg = 0xffc2502c 0x28;
  + interrupts = 0 39 4;
  + };
  diff --git a/arch/arm/boot/dts/socfpga.dtsi 
  b/arch/arm/boot/dts/socfpga.dtsi
  index 310292e..da0785d 100644
  --- a/arch/arm/boot/dts/socfpga.dtsi
  +++ b/arch/arm/boot/dts/socfpga.dtsi
  @@ -687,6 +687,12 @@
reg = 0xffc25000 0x4;
};
 
  + sdramedac@ffc2502c {
  + compatible = altr,sdram-edac;
  + reg = 0xffc2502c 0x28;
  + interrupts = 0 39 4;
  + };
 
  I'm not sure I understand this. The ECC register existing within the
  SDRAM controller, which we have a binding for. Why do we need a separate
  binding for a subset of registers within an IP block?
 
  Why can we not have a single binding for the entire SDRAM controlelr and
  decompse that within Linux as it makes sense for the appropriate
  subsystyems?
 
  Leaking Linux design into bindings is a bad idea; it makes it harder to
  change things.
 
  Mark.

 Hi Mark,

 How would we decompose this within Linux. MFD? Is there an example
 that I can look at?

 We originally used syscon for the entire sdram controller register
 block but we got dinged on it.

I think it is good feedback that we don't want the devicetree to break
up this register range (unless someone wants to argue that).

The problem we need to solve here is that the sdram controller
register range has registers that are needed for at least 3 different
functions/drivers: edac, fpga bridges, and loe power mode (putting ddr
in self-refresh).  We would not want to do that in one driver.
Originally we had the whole sdram controller as 'syscon' and that was
frowned upon.  I think someone suggested a MFD.  We can do that and
will do that if that will move things forward.  But that would just be
a mfd that ioremaps the range and provides read/write functions for
other drivers to use (which starts looking very similar to syscon
except that it adds more code to the kernel to do what syscon does).
It seems like that's what syscon was for (looking at
Documentation/devicetree/bindings/mfd/syscon.txt).

So can we have a consensus here on syscon or a very minimal mfd or
some other clear way of moving forward?

Alan


 Thanks for your help.

 Thor
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] dts: socfpga: Add bindings for Altera SoC SDRAM controller

[Alan Tull]

On Tue, Apr 8, 2014 at 1:52 PM, Rob Herring robherri...@gmail.com wrote:
 On Tue, Apr 8, 2014 at 11:02 AM, delicious quinoa
 delicious.qui...@gmail.com wrote:
 On Tue, Apr 8, 2014 at 9:33 AM, Steffen Trumtrar
 s.trumt...@pengutronix.de wrote:
 On Tue, Apr 08, 2014 at 09:29:50AM -0500, Thor Thayer wrote:
 On Tue, 2014-04-08 at 15:38 +0200, Steffen Trumtrar wrote:
  Hi!
 
  On Mon, Apr 07, 2014 at 04:54:07PM -0500, ttha...@altera.com wrote:
   From: Thor Thayer ttha...@altera.com
  
   Addition of the Altera SDRAM controller bindings and device
   tree changes to the Altera SoC project.
  
 [snip]
   +
   +Required properties:
   +- compatible : altr,sdr-ctl, syscon;
   +Note that syscon is invoked for this device to 
   support the FPGA
   + bridge driver, EDAC driver and other devices that share the
   + registers.
   +- reg : Should contain 1 register ranges(address and length)
 
  I haven't really thought this through, but why would the FPGA bridge 
  driver
  access the sdram controller? For releasing the resets in fpgaportrst ? 
  Or is
  there more?

 Hi Steffan. No, not for resets. We need to enable the FPGA to SDRAM
 path. Our SDRAM controller allows FPGA master access to the SDRAM.


 Yes. But what you have to do to enable the path is let the FPGA port you use
 out of reset. And that is it as far as I can see. The rest happens in the
 bitstream. Or is there more to enable the path?
 The FPGA2SDRAM bridge is the one I didn't use as of yet, so if I miss 
 something
 please elaborate.

 Hi Steffen,

 The sdram controller is used by two drivers.  That's why we want to
 specify syscon here.  The other driver is the FPGA bridge driver.
 Its functionality is very separate from what this driver is doing (we
 are not enabling the bridge in this driver; we are enabling the
 monitoring and resetting the interrupt bit of the EDAC).  We wanted to
 specify syscon her so that we don't have to have to change it for
 the other driver.

 But are there actually overlapping registers which are accessed by
 both drivers and need the protection of regmap?

No overlapping registers here.  Just various registers that are used
by: edac driver, fpga bridge, low power modes.  So no special
protection needed.


 Perhaps MFD is more appropriate than syscon?

 Rob

A syscon will do fine here.  If we did a MFD, all it would be doing
would be providing register access for this range of registers to a
few drivers, so syscon does that without any trouble.

Alan Tull
aka
delicious quinoa
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v10] gpio: add a driver for the Synopsys DesignWare APB GPIO block

[Alan Tull]

From: Jamie Iles ja...@jamieiles.com

The Synopsys DesignWare block is used in some ARM devices (picoxcell)
and can be configured to provide multiple banks of GPIO pins.

Signed-off-by: Jamie Iles ja...@jamieiles.com
Signed-off-by: Alan Tull at...@altera.com
Reviewed-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com

v10:- in documentation nr-gpio - nr-gpios
v9: - cleanup in dt bindings doc
- use of_get_child_count()
v8: - remove socfpga.dtsi changes
- minor cleanup in devicetree documentation
v7: - use irq_generic_chip
- support one irq per gpio line or one irq for many
- s/bank/port/ and other cleanup
v6: - (atull) squash the set of patches
- use linear irq domain
- build fixes. Original driver was reviewed on v3.2.
- Fix setting irq edge type for 'rising' and 'both'.
- Support as a loadable module.
- Use bgpio_chip's spinlock during register access.
- Clean up register names to match spec
- s/bank/port/ because register names use the word 'port'
- s/nr-gpio/nr-gpios/
- don't get/put the of_node
- remove signoffs/acked-by's because of changes
- other cleanup
v5: - handle sparse bank population correctly
v3: - depend on rather than select IRQ_DOMAIN
- split IRQ support into a separate patch
v2: - use Rob Herring's irqdomain in generic irq chip patches
- use reg property to indicate bank index
- support irqs on both edges based on LinusW's u300 driver
---
 .../devicetree/bindings/gpio/snps-dwapb-gpio.txt   |   59 +++
 drivers/gpio/Kconfig   |9 +
 drivers/gpio/Makefile  |1 +
 drivers/gpio/gpio-dwapb.c  |  415 
 4 files changed, 484 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
 create mode 100644 drivers/gpio/gpio-dwapb.c

diff --git a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt 
b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
new file mode 100644
index 000..cb01f9f
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
@@ -0,0 +1,59 @@
+* Synopsys DesignWare APB GPIO controller
+
+Required properties:
+- compatible : Should contain snps,dw-apb-gpio
+- reg : Address and length of the register set for the device
+
+The GPIO controller has a configurable number of ports, each of which are
+represented as child nodes with the following properties:
+
+Required properties:
+- compatible : snps,dw-apb-gpio-port
+- gpio-controller : Marks the device node as a gpio controller.
+- #gpio-cells : Should be two.  The first cell is the pin number and
+  the second cell is used to specify optional parameters (currently
+  unused).
+- reg : The integer port index of the port, a single cell.
+- #address-cells : should be 1.
+- #size-cells : should be 0.
+
+Optional properties:
+- interrupt-controller : The first port may be configured to be an interrupt
+controller.
+- #interrupt-cells : Specifies the number of cells needed to encode an
+interrupt.  Shall be set to 2.  The first cell defines the interrupt number,
+the second encodes the triger flags encoded as described in
+Documentation/devicetree/bindings/interrupts.txt
+- interrupt-parent : The parent interrupt controller.
+- interrupts : The interrupts to the parent controller raised when GPIOs
+generate the interrupts.
+- snps,nr-gpios : The number of pins in the port, a single cell.
+
+Example:
+
+gpio: gpio@2 {
+   compatible = snps,dw-apb-gpio;
+   reg = 0x2 0x1000;
+   #address-cells = 1;
+   #size-cells = 0;
+
+   porta: gpio-controller@0 {
+   compatible = snps,dw-apb-gpio-port;
+   gpio-controller;
+   #gpio-cells = 2;
+   snps,nr-gpios = 8;
+   reg = 0;
+   interrupt-controller;
+   #interrupt-cells = 2;
+   interrupt-parent = vic1;
+   interrupts = 0, 1, 2, 3, 4, 5, 6, 7;
+   };
+
+   portb: gpio-controller@1 {
+   compatible = snps,dw-apb-gpio-port;
+   gpio-controller;
+   #gpio-cells = 2;
+   snps,nr-gpios = 8;
+   reg = 1;
+   };
+};
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 0f0..17760dd 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -121,6 +121,15 @@ config GPIO_GENERIC_PLATFORM
help
  Say yes here to support basic platform_device memory-mapped GPIO 
controllers.
 
+config GPIO_DWAPB
+   tristate Synopsys DesignWare APB GPIO driver
+   select GPIO_GENERIC
+   select GENERIC_IRQ_CHIP
+   depends on OF_GPIO  IRQ_DOMAIN
+   help
+ Say Y or M here to build support for the Synopsys DesignWare APB
+ GPIO block.
+
 config GPIO_IT8761E
tristate IT8761E GPIO support

[PATCH v11] gpio: add a driver for the Synopsys DesignWare APB GPIO block

[Alan Tull]

From: Jamie Iles ja...@jamieiles.com

The Synopsys DesignWare block is used in some ARM devices (picoxcell)
and can be configured to provide multiple banks of GPIO pins.

Signed-off-by: Jamie Iles ja...@jamieiles.com
Signed-off-by: Alan Tull at...@altera.com
Reviewed-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com

v11: - Use NULL when checking existence of 'interrupts' property
 - Bindings descriptions cleanup
v10: - in documentation nr-gpio - nr-gpios
v9:  - cleanup in dt bindings doc
 - use of_get_child_count()
v8:  - remove socfpga.dtsi changes
 - minor cleanup in devicetree documentation
v7:  - use irq_generic_chip
 - support one irq per gpio line or one irq for many
 - s/bank/port/ and other cleanup
v6:  - (atull) squash the set of patches
 - use linear irq domain
 - build fixes. Original driver was reviewed on v3.2.
 - Fix setting irq edge type for 'rising' and 'both'.
 - Support as a loadable module.
 - Use bgpio_chip's spinlock during register access.
 - Clean up register names to match spec
 - s/bank/port/ because register names use the word 'port'
 - s/nr-gpio/nr-gpios/
 - don't get/put the of_node
 - remove signoffs/acked-by's because of changes
 - other cleanup
v5:  - handle sparse bank population correctly
v3:  - depend on rather than select IRQ_DOMAIN
 - split IRQ support into a separate patch
v2:  - use Rob Herring's irqdomain in generic irq chip patches
 - use reg property to indicate bank index
 - support irqs on both edges based on LinusW's u300 driver
---
 .../devicetree/bindings/gpio/snps-dwapb-gpio.txt   |   58 +++
 drivers/gpio/Kconfig   |9 +
 drivers/gpio/Makefile  |1 +
 drivers/gpio/gpio-dwapb.c  |  415 
 4 files changed, 483 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
 create mode 100644 drivers/gpio/gpio-dwapb.c

diff --git a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt 
b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
new file mode 100644
index 000..38c2224
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
@@ -0,0 +1,58 @@
+* Synopsys DesignWare APB GPIO controller
+
+Required properties:
+- compatible : Should contain snps,dw-apb-gpio
+- reg : Address and length of the register set for the device.
+- #address-cells : should be 1 (for addressing port subnodes).
+- #size-cells : should be 0 (port subnodes).
+
+The GPIO controller has a configurable number of ports, each of which are
+represented as child nodes with the following properties:
+
+Required properties:
+- compatible : snps,dw-apb-gpio-port
+- gpio-controller : Marks the device node as a gpio controller.
+- #gpio-cells : Should be 1.  It is the pin number.
+- reg : The integer port index of the port, a single cell.
+
+Optional properties:
+- interrupt-controller : The first port may be configured to be an interrupt
+controller.
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt.  Shall be set to 2.  The first cell defines the interrupt number,
+  the second encodes the triger flags encoded as described in
+  Documentation/devicetree/bindings/interrupts.txt
+- interrupt-parent : The parent interrupt controller.
+- interrupts : The interrupts to the parent controller raised when GPIOs
+  generate the interrupts.  The number of interrupts depends on the hardware
+  configuration of the DesignWare IP block.
+- snps,nr-gpios : The number of pins in the port, a single cell.
+
+Example:
+
+gpio: gpio@2 {
+   compatible = snps,dw-apb-gpio;
+   reg = 0x2 0x1000;
+   #address-cells = 1;
+   #size-cells = 0;
+
+   porta: gpio-controller@0 {
+   compatible = snps,dw-apb-gpio-port;
+   gpio-controller;
+   #gpio-cells = 2;
+   snps,nr-gpios = 8;
+   reg = 0;
+   interrupt-controller;
+   #interrupt-cells = 2;
+   interrupt-parent = vic1;
+   interrupts = 0, 1, 2, 3, 4, 5, 6, 7;
+   };
+
+   portb: gpio-controller@1 {
+   compatible = snps,dw-apb-gpio-port;
+   gpio-controller;
+   #gpio-cells = 2;
+   snps,nr-gpios = 8;
+   reg = 1;
+   };
+};
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 6973387..b72cd85 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -128,6 +128,15 @@ config GPIO_GENERIC_PLATFORM
help
  Say yes here to support basic platform_device memory-mapped GPIO 
controllers.
 
+config GPIO_DWAPB
+   tristate Synopsys DesignWare APB GPIO driver
+   select GPIO_GENERIC
+   select GENERIC_IRQ_CHIP
+   depends on OF_GPIO  IRQ_DOMAIN
+   help
+ Say Y or M here to build support for the Synopsys DesignWare APB

Re: [PATCH v2 1/2] pmbus: add regulator support

[Alan Tull]

On Sat, Aug 23, 2014 at 9:54 AM, Mark Brown broo...@kernel.org wrote:
 On Sat, Aug 23, 2014 at 07:00:44AM -0700, Guenter Roeck wrote:
 On 08/22/2014 05:31 PM, atull wrote:

 of_get_regulator_init_data() will only have an error if it cannot alloc
 the regulator_init_data struct.  That's why I did -ENOMEM.  If there
 is no platform data and nothing about the regulator in the device tree, we
 should end up with a zeroed out regulator_init_data.

 Yes, but if OF is not defined it will return NULL as well. Unless I am
 missing something, that means that the code will now fail if there is
 no platform init data and OF is not configured.

 Indeed, and that's the more interesting case than running out of memory.

Thanks for catching this.  I'll remove the unnecessary check for NULL
and the brackets here.

Alan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/2] pmbus: ltc2978: add regulator gating

[Alan Tull]

On Sat, Aug 23, 2014 at 10:10 AM, Guenter Roeck li...@roeck-us.net wrote:
 On 08/22/2014 02:45 PM, Mark Brown wrote:

 On Fri, Aug 22, 2014 at 04:11:34PM -0500, at...@opensource.altera.com
 wrote:

 From: Alan Tull at...@opensource.altera.com

 Add regulator with support for enabling or disabling all
 supplies.


 Reviwed-by: Mark Brown broo...@linaro.org

 though it still looks like you should be able to create generic
 functions for the operations.

 Sorry I didn't have time to review the code myself. I'll have
 to check the datasheet about turning regulators on and off.
 Using page 0xff for the lm2978 looks wrong, as the chip supports
 up to 8 channels which should be controlled separately
 (I would assume) instead of turning them all on and off in
 one go. Maybe I am missing something, but my assumption would
 have been to have a separate regulator for each channel, and
 that each channel would have its own regulator which would be
 turned on and off separately. So I don't really understand the
 change between v1 and v2 of the core patch, which dropped the
 per-channel regulators. Someone will have to explain to me
 why that makes sense, especially since it means that I won't
 be able to use the regulator expansion in my system (which
 would require per-channel regulators, and which does not always
 have all channels enabled on a given chip).

The LTC2978 spec says that the OPERATION command register responds to
the global page command (PAGE=0xFF).  I originally took it to mean
that it *only* responds to 0xFF.  Now I get that yes I could turn
on/off each of 8 channels separately.

I will make the change have one regulator for each supply.  It would
be useful to still have a global regulator for turning them all on/off
together if that is not completely odious.


 In respect to generic functions, that really depends on the scope
 of the regulators. As written, where all regulators are turned on
 in a single operation, per-chip functions are needed. I thought
 we would only need per-chip configuration values, but that only
 applies if regulators are turned on one by one, not all in one go.

For all the parts supported by ltc2978.c, a banked write of 0x80 to
the OPERATION register turns a regulator on, writing 0x00 turns it
off.  I'm not sure how universal that is for other PMBUS parts.  I
will look at the PMBUS specs when I get back to the office Tuesday.

I'll look into it and see if I can push almost all of this code into
pmbus_core.c and just have per-chip config values in
pmbus_driver_info.   If many PMBUS parts have the same scheme (0x80 or
0x00 written to OPERATION register as a banked write) then  a flag bit
that is turned on in pmbus_driver_info could enable this scheme for
this chip.  If it is a different register or different on/off values,
then I'll need to add those to pmbus_driver_info.

 Either case, a wrapper for ltc2978_write_pmbus_operation needs to
 be added to pmbus_core.c as pmbus_write_byte_data and exported
 (as a separate patch). For paged reads, the existing
 pmbus_read_byte_data should be used. In general, avoid direct
 accesses to paged registers and use API functions instead
 if possible.

OK.  Will add pmbus_write_byte_data as a separate patch and use the
existing pmbus_read_byte_data.

Thanks for the review!

Alan


 Thanks,
 Guenter

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/2] TTY Driver for Newhaven LCD module

[Alan Tull]

Supports a 2 line by 16 character LCD module over I2C.

Alan Tull (2):
  newhaven lcd: device tree bindings documentation
  add newhaven lcd tty driver on i2c

 .../devicetree/bindings/tty/newhaven_lcd.txt   |   21 +
 drivers/tty/Kconfig|5 +
 drivers/tty/Makefile   |1 +
 drivers/tty/newhaven_lcd.c |  733 
 include/linux/platform_data/newhaven_lcd.h |   25 +
 5 files changed, 785 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/tty/newhaven_lcd.txt
 create mode 100644 drivers/tty/newhaven_lcd.c
 create mode 100644 include/linux/platform_data/newhaven_lcd.h

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] add newhaven lcd tty driver on i2c

[Alan Tull]

Supports the Newhaven NHD‐0216K3Z‐NSW‐BBW 2x16 LCD module as i2c slave.
Devices will show up as /dev/ttyLCD0, etc.

 * Backspace is supported to the beginning of the current line.
* i.e. printf '\b'  /dev/ttyLCD0

 * ESC [ 2 J
* erase whole display and reset cursor to home.
* i.e. printf '\e[2J'  /dev/ttyLCD0

 * ESC [ 2 K
* erase current line and set cursor to beginning of line.
* i.e. printf '\e[2K'  /dev/ttyLCD0

 * CR and LF are supported.

 * Vertical scroll when cursor is on bottom line and receive end of line.

Default brightness can be set from the device tree/plat data.

Brightness can be set from a sysfs file, for example:
 * echo 6  /sys/devices/soc.0/ffc04000.i2c/i2c-0/0-0028/brightness

Signed-off-by: Alan Tull at...@opensource.altera.com
---
 drivers/tty/Kconfig|5 +
 drivers/tty/Makefile   |1 +
 drivers/tty/newhaven_lcd.c |  733 
 include/linux/platform_data/newhaven_lcd.h |   25 +
 4 files changed, 764 insertions(+)
 create mode 100644 drivers/tty/newhaven_lcd.c
 create mode 100644 include/linux/platform_data/newhaven_lcd.h

diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index b24aa01..c392405 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -419,4 +419,9 @@ config DA_CONSOLE
help
  This enables a console on a Dash channel.
 
+config NEWHAVEN_LCD
+   tristate NEWHAVEN LCD
+   help
+ Add support for a TTY device on a Newhaven I2C LCD device.
+
 endif # TTY
diff --git a/drivers/tty/Makefile b/drivers/tty/Makefile
index 58ad1c0..f6a3d56 100644
--- a/drivers/tty/Makefile
+++ b/drivers/tty/Makefile
@@ -29,5 +29,6 @@ obj-$(CONFIG_SYNCLINK)+= synclink.o
 obj-$(CONFIG_PPC_EPAPR_HV_BYTECHAN) += ehv_bytechan.o
 obj-$(CONFIG_GOLDFISH_TTY) += goldfish.o
 obj-$(CONFIG_DA_TTY)   += metag_da.o
+obj-$(CONFIG_NEWHAVEN_LCD) += newhaven_lcd.o
 
 obj-y += ipwireless/
diff --git a/drivers/tty/newhaven_lcd.c b/drivers/tty/newhaven_lcd.c
new file mode 100644
index 000..d79ee47
--- /dev/null
+++ b/drivers/tty/newhaven_lcd.c
@@ -0,0 +1,733 @@
+/*
+ * TTY on a LCD connected to I2C
+ * Supports Newhaven NHD-0216K3Z-NSW-BBW Serial LCD Module
+ *
+ * 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 http://www.gnu.org/licenses/.
+ */
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/idr.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/platform_data/newhaven_lcd.h
+#include linux/slab.h
+#include linux/tty.h
+
+#define DRV_NAME lcd-comm
+#define DEV_NAME ttyLCD
+#define MAX_NEWHAVEN_LCD_COUNT 256
+
+#define LCD_COMMAND 0xfe
+#define LCD_DISPLAY_ON  0x41
+#define LCD_DISPLAY_OFF 0x42
+#define LCD_SET_CURSOR  0x45
+#define LCD_BACKSPACE   0x4e
+#define LCD_CLEAR_SCREEN0x51
+#define LCD_BRIGHTNESS  0x53
+#define LCD_CUSTOM_CHAR 0x54
+#define LCD_BYTES_PER_FONT  8
+#define LCD_BYTES_PER_FONT_CMD  (LCD_BYTES_PER_FONT + 3)
+
+#define LCD_BRIGHTNESS_MIN 1
+#define LCD_BRIGHTNESS_MAX 8
+
+#define ASCII_BS0x08
+#define ASCII_LF0x0a
+#define ASCII_CR0x0d
+#define ASCII_ESC   0x1b
+#define ASCII_SPACE 0x20
+#define ASCII_BACKSLASH 0x5c
+#define ASCII_TILDE 0x7e
+
+/* Valid displayable character in LCD panel's font table */
+#define valid_font(x) (0x20 = (x)  (x) = 0x7f)
+
+/*
+ * The display module displays a right arrow instead of tilde for
+ * ascii 0x7e. Also, it displays a Japanese character instead of a
+ * backslash character for ascii 0x5c. Work around these by loading
+ * custom characters into the display module's cg ram.
+ */
+struct custom_font {
+   char font[LCD_BYTES_PER_FONT];
+   char ascii;
+};
+
+#define CUSTOM_BACKSLASH0x00
+#define CUSTOM_TILDE0x01
+
+struct custom_font custom_fonts[] = {
+   [CUSTOM_BACKSLASH] = {
+   { 0x00, 0x10, 0x08, 0x04, 0x02, 0x01, 0x00, 0x00, },
+   ASCII_BACKSLASH,
+   },
+   [CUSTOM_TILDE] = {
+   { 0x00, 0x00, 0x00, 0x08, 0x15, 0x02, 0x00, 0x00, },
+   ASCII_TILDE,
+   },
+};
+
+struct lcd {
+   struct device *dev;
+   struct i2c_client *client

[PATCH 1/2] newhaven lcd: device tree bindings documentation

[Alan Tull]

Add documention for the newhaven lcd device tree bindings.

Signed-off-by: Alan Tull at...@opensource.altera.com
---
 .../devicetree/bindings/tty/newhaven_lcd.txt   |   21 
 1 file changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/tty/newhaven_lcd.txt

diff --git a/Documentation/devicetree/bindings/tty/newhaven_lcd.txt 
b/Documentation/devicetree/bindings/tty/newhaven_lcd.txt
new file mode 100644
index 000..14b48fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty/newhaven_lcd.txt
@@ -0,0 +1,21 @@
+* TTY on a Newhaven NHD‐0216K3Z‐NSW‐BBW LCD connected to I2C
+
+Required properties:
+- compatible: Should be newhaven,nhd-0216k3z-nsw-bbw
+- reg: i2c address
+- height: should be 2 lines
+- width: should be 16 characters
+- brightness: backlight brightness. Range is 1 to 8, where
+  1=OFF and 8=maximum brightness.
+
+Example:
+
+i2c0 {
+   lcd: lcd@28 {
+   compatible = newhaven,nhd-0216k3z-nsw-bbw;
+   reg = 0x28;
+   height = 2;
+   width = 16;
+   brightness = 8;
+   };
+
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv6 1/2] ARM: socfpga: support suspend to ram

[Alan Tull]

Add code that requests that the sdr controller go into
self-refresh mode.  This code is run from ocram.

Suspend-to-RAM and EDAC support are mutually exclusive on
SOCFPGA.  If the EDAC is enabled, it will prevent the
platform from going into suspend.

Example of how to request to suspend to ram:
 $ echo enabled  \
/sys/devices/soc/ffc02000.serial0/tty/ttyS0/power/wakeup

 $ echo -n mem  /sys/power/state

Signed-off-by: Alan Tull at...@opensource.altera.com
Cc: Pavel Machek pa...@denx.de
Cc: Arnd Bergmann a...@arndb.de
Cc: Dinh Nguyen dingu...@opensource.altera.com
Cc: Steffen Trumtrar s.trumt...@pengutronix.de
---
v2: use Generic on-chip SRAM driver to allocate ocram
rm fncpy_align since generic allocator handles alignment
check __arm_ioremap_exec return code
check for NULL pointers
add a comment regarding sdram controller configuration
v3: fix renamed #define
propagate socfpga_setup_ocram_self_refresh error code
v4: Kconfig: don't need to select GENERIC_ALLOCATER
add CONFIG_SOCFPGA_SUSPEND
make s2r and EDAC support mutually exclusive
socfpga.c: add sdr_ctl_base_addr
return error if ocram not available in device tree
update copyright years
v5: remove compile time dependency
edac driver will prevent suspend
don't configure scu standby mode; done in enable_scu().
fix comments about required sdram controller configuration
v6: needed a static declaration
---
 arch/arm/mach-socfpga/Kconfig|   10 ++-
 arch/arm/mach-socfpga/Makefile   |1 +
 arch/arm/mach-socfpga/core.h |6 +-
 arch/arm/mach-socfpga/pm.c   |  149 ++
 arch/arm/mach-socfpga/self-refresh.S |  136 +++
 arch/arm/mach-socfpga/socfpga.c  |6 +-
 drivers/edac/altera_edac.c   |   20 +
 7 files changed, 325 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/mach-socfpga/pm.c
 create mode 100644 arch/arm/mach-socfpga/self-refresh.S

diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index b5f8d75..b26a684 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -1,4 +1,4 @@
-config ARCH_SOCFPGA
+menuconfig ARCH_SOCFPGA
bool Altera SOCFPGA family if ARCH_MULTI_V7
select ARM_AMBA
select ARM_GIC
@@ -8,3 +8,11 @@ config ARCH_SOCFPGA
select HAVE_ARM_SCU
select HAVE_ARM_TWD if SMP
select MFD_SYSCON
+
+if ARCH_SOCFPGA
+config SOCFPGA_SUSPEND
+   bool Suspend to RAM on SOCFPGA
+   help
+ Select this if you want to enable Suspend-to-RAM on SOCFPGA
+ platforms.
+endif
diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index 6dd7a93..b8f9e23 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -4,3 +4,4 @@
 
 obj-y  := socfpga.o
 obj-$(CONFIG_SMP)  += headsmp.o platsmp.o
+obj-$(CONFIG_SOCFPGA_SUSPEND)  += pm.o self-refresh.o
diff --git a/arch/arm/mach-socfpga/core.h b/arch/arm/mach-socfpga/core.h
index 7637b7f..35472f2 100644
--- a/arch/arm/mach-socfpga/core.h
+++ b/arch/arm/mach-socfpga/core.h
@@ -1,6 +1,6 @@
 /*
  * Copyright 2012 Pavel Machek pa...@denx.de
- * Copyright (C) 2012 Altera Corporation
+ * Copyright (C) 2012-2015 Altera Corporation
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -40,6 +40,10 @@ extern void socfpga_sysmgr_init(void);
 
 extern void __iomem *sys_manager_base_addr;
 extern void __iomem *rst_manager_base_addr;
+extern void __iomem *sdr_ctl_base_addr;
+
+u32 socfpga_sdram_self_refresh(u32 sdr_base);
+extern unsigned int socfpga_sdram_self_refresh_sz;
 
 extern struct smp_operations socfpga_smp_ops;
 extern char secondary_trampoline, secondary_trampoline_end;
diff --git a/arch/arm/mach-socfpga/pm.c b/arch/arm/mach-socfpga/pm.c
new file mode 100644
index 000..1ed89fc
--- /dev/null
+++ b/arch/arm/mach-socfpga/pm.c
@@ -0,0 +1,149 @@
+/*
+ *  arch/arm/mach-socfpga/pm.c
+ *
+ * Copyright (C) 2014-2015 Altera Corporation. All rights reserved.
+ *
+ * with code from pm-imx6.c
+ * Copyright 2011-2014 Freescale Semiconductor, Inc.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * 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 http://www.gnu.org/licenses/.
+ */
+
+#include linux/bitops.h
+#include linux/genalloc.h
+#include linux/init.h
+#include linux/io.h

[PATCHv6 0/2] socfpga: support suspend to ram*

[Alan Tull]

Support suspend to ram on socfpga.
  * allocate space in ocram using sram driver.
  * Add a function in ocram to place DDR in self-refresh
and suspend.
  * Prevent suspend if EDAC is enabled.
  * Add a device tree binding document for the Altera
SOCFPGA SDRAM controller that is used to put DDR in
self-refresh mode.

Alan Tull (2):
  ARM: socfpga: support suspend to ram
  ARM: socfpga: dts: add sdram controller dt binding doc

 .../arm/altera/socfpga-sdram-controller.txt|   12 ++
 arch/arm/mach-socfpga/Kconfig  |   10 +-
 arch/arm/mach-socfpga/Makefile |1 +
 arch/arm/mach-socfpga/core.h   |6 +-
 arch/arm/mach-socfpga/pm.c |  149 
 arch/arm/mach-socfpga/self-refresh.S   |  136 ++
 arch/arm/mach-socfpga/socfpga.c|6 +-
 drivers/edac/altera_edac.c |   20 +++
 8 files changed, 337 insertions(+), 3 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/altera/socfpga-sdram-controller.txt
 create mode 100644 arch/arm/mach-socfpga/pm.c
 create mode 100644 arch/arm/mach-socfpga/self-refresh.S

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv6 2/2] ARM: socfpga: dts: add sdram controller dt binding doc

[Alan Tull]

Add binding doc for Altera SOCFPGA SDRAM controller.

Signed-off-by: Alan Tull at...@opensource.altera.com
---
v4: Add bindings doc
v5: No change for v5
v6: No change for v6
---
 .../arm/altera/socfpga-sdram-controller.txt|   12 
 1 file changed, 12 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/altera/socfpga-sdram-controller.txt

diff --git 
a/Documentation/devicetree/bindings/arm/altera/socfpga-sdram-controller.txt 
b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram-controller.txt
new file mode 100644
index 000..77ca635
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram-controller.txt
@@ -0,0 +1,12 @@
+Altera SOCFPGA SDRAM Controller
+
+Required properties:
+- compatible : Should contain altr,sdr-ctl and syscon.
+  syscon is required by the Altera SOCFPGA SDRAM EDAC.
+- reg : Should contain 1 register range (address and length)
+
+Example:
+   sdr: sdr@ffc25000 {
+   compatible = altr,sdr-ctl, syscon;
+   reg = 0xffc25000 0x1000;
+   };
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv5 0/2] socfpga: support suspend to ram

[Alan Tull]

Support suspend to ram on socfpga.
  * allocate space in ocram using sram driver.
  * Add a function in ocram to place DDR in self-refresh
and suspend.
  * Prevent suspend if EDAC is enabled.
  * Add a device tree binding document for the Altera
SOCFPGA SDRAM controller that is used to put DDR in
self-refresh mode.

Alan Tull (2):
  ARM: socfpga: support suspend to ram
  ARM: socfpga: dts: add sdram controller dt binding doc

 .../arm/altera/socfpga-sdram-controller.txt|   12 ++
 arch/arm/mach-socfpga/Kconfig  |   10 +-
 arch/arm/mach-socfpga/Makefile |1 +
 arch/arm/mach-socfpga/core.h   |6 +-
 arch/arm/mach-socfpga/pm.c |  149 
 arch/arm/mach-socfpga/self-refresh.S   |  136 ++
 arch/arm/mach-socfpga/socfpga.c|6 +-
 drivers/edac/altera_edac.c |   20 +++
 8 files changed, 337 insertions(+), 3 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/altera/socfpga-sdram-controller.txt
 create mode 100644 arch/arm/mach-socfpga/pm.c
 create mode 100644 arch/arm/mach-socfpga/self-refresh.S

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv5 2/2] ARM: socfpga: dts: add sdram controller dt binding doc

[Alan Tull]

Add binding doc for Altera SOCFPGA SDRAM controller.

Signed-off-by: Alan Tull at...@opensource.altera.com
---
v4: Add bindings doc
v5: No change for v5
---
 .../arm/altera/socfpga-sdram-controller.txt|   12 
 1 file changed, 12 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/altera/socfpga-sdram-controller.txt

diff --git 
a/Documentation/devicetree/bindings/arm/altera/socfpga-sdram-controller.txt 
b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram-controller.txt
new file mode 100644
index 000..77ca635
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram-controller.txt
@@ -0,0 +1,12 @@
+Altera SOCFPGA SDRAM Controller
+
+Required properties:
+- compatible : Should contain altr,sdr-ctl and syscon.
+  syscon is required by the Altera SOCFPGA SDRAM EDAC.
+- reg : Should contain 1 register range (address and length)
+
+Example:
+   sdr: sdr@ffc25000 {
+   compatible = altr,sdr-ctl, syscon;
+   reg = 0xffc25000 0x1000;
+   };
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv5 1/2] ARM: socfpga: support suspend to ram

[Alan Tull]

Add code that requests that the sdr controller go into
self-refresh mode.  This code is run from ocram.

Suspend-to-RAM and EDAC support are mutually exclusive on
SOCFPGA.  If the EDAC is enabled, it will prevent the
platform from going into suspend.

Example of how to request to suspend to ram:
 $ echo enabled  \
/sys/devices/soc/ffc02000.serial0/tty/ttyS0/power/wakeup

 $ echo -n mem  /sys/power/state

Signed-off-by: Alan Tull at...@opensource.altera.com
Cc: Pavel Machek pa...@denx.de
Cc: Arnd Bergmann a...@arndb.de
Cc: Dinh Nguyen dingu...@opensource.altera.com
Cc: Steffen Trumtrar s.trumt...@pengutronix.de
---
v2: use Generic on-chip SRAM driver to allocate ocram
rm fncpy_align since generic allocator handles alignment
check __arm_ioremap_exec return code
check for NULL pointers
add a comment regarding sdram controller configuration
v3: fix renamed #define
propagate socfpga_setup_ocram_self_refresh error code
v4: Kconfig: don't need to select GENERIC_ALLOCATER
add CONFIG_SOCFPGA_SUSPEND
make s2r and EDAC support mutually exclusive
socfpga.c: add sdr_ctl_base_addr
return error if ocram not available in device tree
update copyright years
v5: remove compile time dependency
edac driver will prevent suspend
don't configure scu standby mode; done in enable_scu().
fix comments about required sdram controller configuration
---
 arch/arm/mach-socfpga/Kconfig|   10 ++-
 arch/arm/mach-socfpga/Makefile   |1 +
 arch/arm/mach-socfpga/core.h |6 +-
 arch/arm/mach-socfpga/pm.c   |  149 ++
 arch/arm/mach-socfpga/self-refresh.S |  136 +++
 arch/arm/mach-socfpga/socfpga.c  |6 +-
 drivers/edac/altera_edac.c   |   20 +
 7 files changed, 325 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/mach-socfpga/pm.c
 create mode 100644 arch/arm/mach-socfpga/self-refresh.S

diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index b5f8d75..b26a684 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -1,4 +1,4 @@
-config ARCH_SOCFPGA
+menuconfig ARCH_SOCFPGA
bool Altera SOCFPGA family if ARCH_MULTI_V7
select ARM_AMBA
select ARM_GIC
@@ -8,3 +8,11 @@ config ARCH_SOCFPGA
select HAVE_ARM_SCU
select HAVE_ARM_TWD if SMP
select MFD_SYSCON
+
+if ARCH_SOCFPGA
+config SOCFPGA_SUSPEND
+   bool Suspend to RAM on SOCFPGA
+   help
+ Select this if you want to enable Suspend-to-RAM on SOCFPGA
+ platforms.
+endif
diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index 6dd7a93..b8f9e23 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -4,3 +4,4 @@
 
 obj-y  := socfpga.o
 obj-$(CONFIG_SMP)  += headsmp.o platsmp.o
+obj-$(CONFIG_SOCFPGA_SUSPEND)  += pm.o self-refresh.o
diff --git a/arch/arm/mach-socfpga/core.h b/arch/arm/mach-socfpga/core.h
index 7637b7f..35472f2 100644
--- a/arch/arm/mach-socfpga/core.h
+++ b/arch/arm/mach-socfpga/core.h
@@ -1,6 +1,6 @@
 /*
  * Copyright 2012 Pavel Machek pa...@denx.de
- * Copyright (C) 2012 Altera Corporation
+ * Copyright (C) 2012-2015 Altera Corporation
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -40,6 +40,10 @@ extern void socfpga_sysmgr_init(void);
 
 extern void __iomem *sys_manager_base_addr;
 extern void __iomem *rst_manager_base_addr;
+extern void __iomem *sdr_ctl_base_addr;
+
+u32 socfpga_sdram_self_refresh(u32 sdr_base);
+extern unsigned int socfpga_sdram_self_refresh_sz;
 
 extern struct smp_operations socfpga_smp_ops;
 extern char secondary_trampoline, secondary_trampoline_end;
diff --git a/arch/arm/mach-socfpga/pm.c b/arch/arm/mach-socfpga/pm.c
new file mode 100644
index 000..1ed89fc
--- /dev/null
+++ b/arch/arm/mach-socfpga/pm.c
@@ -0,0 +1,149 @@
+/*
+ *  arch/arm/mach-socfpga/pm.c
+ *
+ * Copyright (C) 2014-2015 Altera Corporation. All rights reserved.
+ *
+ * with code from pm-imx6.c
+ * Copyright 2011-2014 Freescale Semiconductor, Inc.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * 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 http://www.gnu.org/licenses/.
+ */
+
+#include linux/bitops.h
+#include linux/genalloc.h
+#include linux/init.h
+#include linux/io.h
+#include linux/of_platform.h
+#include

[PATCH v4 2/2] ARM: socfpga: dts: add sdram controller dt binding doc

[Alan Tull]

Add binding doc for Altera SOCFPGA SDRAM controller.

Signed-off-by: Alan Tull at...@opensource.altera.com
---
v4: Add bindings doc
---
 .../arm/altera/socfpga-sdram-controller.txt|   12 
 1 file changed, 12 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/altera/socfpga-sdram-controller.txt

diff --git 
a/Documentation/devicetree/bindings/arm/altera/socfpga-sdram-controller.txt 
b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram-controller.txt
new file mode 100644
index 000..77ca635
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram-controller.txt
@@ -0,0 +1,12 @@
+Altera SOCFPGA SDRAM Controller
+
+Required properties:
+- compatible : Should contain altr,sdr-ctl and syscon.
+  syscon is required by the Altera SOCFPGA SDRAM EDAC.
+- reg : Should contain 1 register range (address and length)
+
+Example:
+   sdr: sdr@ffc25000 {
+   compatible = altr,sdr-ctl, syscon;
+   reg = 0xffc25000 0x1000;
+   };
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 1/2] ARM: socfpga: support suspend to ram

[Alan Tull]

Add code that requests that the sdr controller go into
self-refresh mode.  This code is run from ocram.

This patch assumes that u-boot has already configured sdr:
  sdr.ctrlcfg.lowpwreq.selfrfshmask = 3
  sdr.ctrlcfg.lowpwrtiming.clkdisablecycles = 8
  sdr.ctrlcfg.dramtiming4.selfrfshexit = 512

Suspend-to-RAM and EDAC support are mutually exclusive on SOCFPGA
platforms.  CONFIG_SOCFPGA_SUSPEND enables suspend-to-RAM and
prevents selecting CONFIG_EDAC_ALTERA_MC.

How to suspend to ram:
 $ echo enabled  \
/sys/devices/soc/ffc02000.serial0/tty/ttyS0/power/wakeup

 $ echo -n mem  /sys/power/state

Signed-off-by: Alan Tull at...@opensource.altera.com
Cc: Pavel Machek pa...@denx.de
Cc: Arnd Bergmann a...@arndb.de
Cc: Dinh Nguyen dingu...@opensource.altera.com
Cc: Steffen Trumtrar s.trumt...@pengutronix.de
---
v2: use Generic on-chip SRAM driver to allocate ocram
rm fncpy_align since generic allocator handles alignment
check __arm_ioremap_exec return code
check for NULL pointers
add a comment regarding sdram controller configuration
v3: fix renamed #define
propagate socfpga_setup_ocram_self_refresh error code
v4: Kconfig: don't need to select GENERIC_ALLOCATER
add CONFIG_SOCFPGA_SUSPEND
make s2r and EDAC support mutually exclusive
socfpga.c: add sdr_ctl_base_addr
return error if ocram not available in device tree
update copyright years
---
 arch/arm/mach-socfpga/Kconfig|   10 ++-
 arch/arm/mach-socfpga/Makefile   |1 +
 arch/arm/mach-socfpga/core.h |6 +-
 arch/arm/mach-socfpga/pm.c   |  150 
 arch/arm/mach-socfpga/self-refresh.S |  157 ++
 arch/arm/mach-socfpga/socfpga.c  |6 +-
 drivers/edac/Kconfig |2 +-
 7 files changed, 328 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/mach-socfpga/pm.c
 create mode 100644 arch/arm/mach-socfpga/self-refresh.S

diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index b5f8d75..b26a684 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -1,4 +1,4 @@
-config ARCH_SOCFPGA
+menuconfig ARCH_SOCFPGA
bool Altera SOCFPGA family if ARCH_MULTI_V7
select ARM_AMBA
select ARM_GIC
@@ -8,3 +8,11 @@ config ARCH_SOCFPGA
select HAVE_ARM_SCU
select HAVE_ARM_TWD if SMP
select MFD_SYSCON
+
+if ARCH_SOCFPGA
+config SOCFPGA_SUSPEND
+   bool Suspend to RAM on SOCFPGA
+   help
+ Select this if you want to enable Suspend-to-RAM on SOCFPGA
+ platforms.
+endif
diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index 6dd7a93..b8f9e23 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -4,3 +4,4 @@
 
 obj-y  := socfpga.o
 obj-$(CONFIG_SMP)  += headsmp.o platsmp.o
+obj-$(CONFIG_SOCFPGA_SUSPEND)  += pm.o self-refresh.o
diff --git a/arch/arm/mach-socfpga/core.h b/arch/arm/mach-socfpga/core.h
index a0f3b1c..498b271 100644
--- a/arch/arm/mach-socfpga/core.h
+++ b/arch/arm/mach-socfpga/core.h
@@ -1,6 +1,6 @@
 /*
  * Copyright 2012 Pavel Machek pa...@denx.de
- * Copyright (C) 2012 Altera Corporation
+ * Copyright (C) 2012-2015 Altera Corporation
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -39,6 +39,10 @@ extern void socfpga_sysmgr_init(void);
 
 extern void __iomem *sys_manager_base_addr;
 extern void __iomem *rst_manager_base_addr;
+extern void __iomem *sdr_ctl_base_addr;
+
+u32 socfpga_sdram_self_refresh(u32 sdr_base, u32 scu_base);
+extern unsigned int socfpga_sdram_self_refresh_sz;
 
 extern struct smp_operations socfpga_smp_ops;
 extern char secondary_trampoline, secondary_trampoline_end;
diff --git a/arch/arm/mach-socfpga/pm.c b/arch/arm/mach-socfpga/pm.c
new file mode 100644
index 000..166ac32
--- /dev/null
+++ b/arch/arm/mach-socfpga/pm.c
@@ -0,0 +1,150 @@
+/*
+ *  arch/arm/mach-socfpga/pm.c
+ *
+ * Copyright (C) 2014-2015 Altera Corporation. All rights reserved.
+ *
+ * with code from pm-imx6.c
+ * Copyright 2011-2014 Freescale Semiconductor, Inc.
+ * Copyright 2011 Linaro Ltd.
+ *
+ * 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 http://www.gnu.org/licenses/.
+ */
+
+#include linux/bitops.h
+#include linux/genalloc.h
+#include linux/init.h
+#include linux/io.h
+#include linux

[PATCH v4 0/2] socfpga: support suspend to ram

[Alan Tull]

Support suspend to ram on socfpga.
  * allocate space in ocram using sram driver.
  * Add a function in ocram to place DDR in self-refresh
and suspend.
  * SDRAM ECC is mutually exclusive with using ocram for
suspend, so disable SDRAM ECC if socfpga suspend is
enabled.
  * Add a device tree binding document for the Altera
SOCFPGA SDRAM controller that is used to put DDR in
self-refresh mode.

Alan Tull (2):
  ARM: socfpga: support suspend to ram
  ARM: socfpga: dts: add sdram controller dt binding doc

 .../arm/altera/socfpga-sdram-controller.txt|   12 ++
 arch/arm/mach-socfpga/Kconfig  |   10 +-
 arch/arm/mach-socfpga/Makefile |1 +
 arch/arm/mach-socfpga/core.h   |6 +-
 arch/arm/mach-socfpga/pm.c |  150 +++
 arch/arm/mach-socfpga/self-refresh.S   |  157 
 arch/arm/mach-socfpga/socfpga.c|6 +-
 drivers/edac/Kconfig   |2 +-
 8 files changed, 340 insertions(+), 4 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/altera/socfpga-sdram-controller.txt
 create mode 100644 arch/arm/mach-socfpga/pm.c
 create mode 100644 arch/arm/mach-socfpga/self-refresh.S

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] leds/class: Check snprintf return value

[Alan Tull]

On Mon, Mar 30, 2015 at 4:08 AM, Ricardo Ribalda Delgado
ricardo.riba...@gmail.com wrote:
 If the final name does not fit the string there is a potential
 endless-loop.

 Reported-by: Geert Uytterhoeven ge...@linux-m68k.org
 Signed-off-by: Ricardo Ribalda Delgado ricardo.riba...@gmail.com
 ---
  drivers/leds/led-class.c | 10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)

 diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
 index 294d6d6..2ffe8b1 100644
 --- a/drivers/leds/led-class.c
 +++ b/drivers/leds/led-class.c
 @@ -223,12 +223,17 @@ static int led_classdev_next_name(const char 
 *init_name, char *name,
   size_t len)
  {
 int i = 0;
 +   int ret = 0;

 strlcpy(name, init_name, len);

 -   while (class_find_device(leds_class, NULL, name, match_name))
 +   while (class_find_device(leds_class, NULL, name, match_name) 
 +  (ret  len))
 snprintf(name, len, %s_%d, init_name, ++i);

class_find_device will get a reference for a device.  That reference must be
dropped using put_device().  See the definition for class_find_device in
drivers/base/class.c and other usage examples in the kernel.  So this
function call will only work the first time.

Alan Tull


 +   if (ret = len)
 +   return -ENOMEM;
 +
 return i;
  }

 @@ -243,6 +248,9 @@ int led_classdev_register(struct device *parent, struct 
 led_classdev *led_cdev)
 int ret;

 ret = led_classdev_next_name(led_cdev-name, name, sizeof(name));
 +   if (ret  0)
 +   return ret;
 +
 led_cdev-dev = device_create_with_groups(leds_class, parent, 0,
 led_cdev, led_cdev-groups, %s, name);
 if (IS_ERR(led_cdev-dev))
 --
 2.1.4

 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v14 0/7] fpga area and fpga bridge framework

[Alan Tull]

On Mon, Dec 14, 2015 at 11:16 AM, Moritz Fischer
<moritz.fisc...@ettus.com> wrote:
> Hi Alan,
>
> On Thu, Dec 10, 2015 at 3:37 PM,  <at...@opensource.altera.com> wrote:
>> From: Alan Tull <at...@opensource.altera.com>
>>
>> For v14 I'm dropping the concept of "simple-fpga-bus" for "fpga-area"
>> with reworked bindings.
>
> I had an offline discussion with Josh Cartwright about his concerns.
> He brought up a good
> point on w.r.t to the way FPGA Area (Bus) deals with things.
>
> Currently we only support complete status = "okay" vs "disabled" kind
> of overlays.
>
> If now you have say a UART in the FPGA that you don't want to go away
> and come back on reload,
> we don't have a good way of expressing this.

Maybe i don't understand what you are saying; could you write out a
sequence you want to be able to do?

If you want suspend/resume functionality that would reload the FPGA
after a suspend powers off the FPGA, that would be simple to add to
the FPGA area code and it wasn't a hack at all.

> Is there a good way to
> express non-mmio FPGA devices?

Is this a separate question/issue from the above?  Are you talking
about acceleration?

>
> I've been toying around with hacking up struct device to include a
> FPGA 'domain', and then, similar
> to power domains allow devices to register suspend() / resume() style
> callbacks (could call them pre_reload() or something like that ...)
>
> I haven't gotten around to think it through. At this point it's just
> an idea and I don't have real code to show.
>
> I realize the issue with that is we'd have to make changes to struct device.

That's interesting.  Usually a FPGA image has many devices in it, so
so way of making that dependency clear would be needed.  If any of the
devices involved are powered up, that FPGA image would need to be
loaded.

Currently I'm trying to get some bindings approved for doing device
tree control of loading the FPGA and probing the devices.  My idea is
that these bindings could be useful for some use cases where we are
loading hardware onto the FPGA that needs to show up in the device
tree. Some of Rob's feedback is that my proposal may be
Altera-specific. If the bindings that I am proposing are useful for at
least some uses with Xilinx parts, that would be valuable feedback at
this point.  If they are Altera-specific, then I may need to add
"altr," to some of the compatible strings like "altr,fpga-bus" and
"altr,fpga-area".  My original intent was to implement something that
you could use also, so I hope that's not the future here.

So my question for you is: is this stuff useful for you?

Alan Tull

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

[PATCH] of: add pre-operation notifications

[Alan Tull]

Add pre-apply and pre-remove notifications.

For pre-apply notifications that result from creating an overlay,
include a device node to the overlay fragment in of_reconfig_data.

If a pre-apply notifier return error, reject the changeset.

Signed-off-by: Alan Tull <at...@opensource.altera.com>
---
 drivers/of/base.c|   20 +
 drivers/of/dynamic.c |   79 +-
 drivers/of/overlay.c |   46 +
 include/linux/of.h   |7 +
 4 files changed, 138 insertions(+), 14 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 017dd94..6d170e0 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1719,6 +1719,12 @@ int of_add_property(struct device_node *np, struct 
property *prop)
 
mutex_lock(_mutex);
 
+   rc = of_property_notify(OF_RECONFIG_PRE_ADD_PROPERTY, np, prop, NULL);
+   if (rc) {
+   mutex_unlock(_mutex);
+   return rc;
+   }
+
raw_spin_lock_irqsave(_lock, flags);
rc = __of_add_property(np, prop);
raw_spin_unlock_irqrestore(_lock, flags);
@@ -1778,6 +1784,13 @@ int of_remove_property(struct device_node *np, struct 
property *prop)
 
mutex_lock(_mutex);
 
+   rc = of_property_notify(OF_RECONFIG_PRE_REMOVE_PROPERTY, np, prop,
+   NULL);
+   if (rc) {
+   mutex_unlock(_mutex);
+   return rc;
+   }
+
raw_spin_lock_irqsave(_lock, flags);
rc = __of_remove_property(np, prop);
raw_spin_unlock_irqrestore(_lock, flags);
@@ -1854,6 +1867,13 @@ int of_update_property(struct device_node *np, struct 
property *newprop)
 
mutex_lock(_mutex);
 
+   rc = of_property_notify(OF_RECONFIG_PRE_UPDATE_PROPERTY, np, newprop,
+   oldprop);
+   if (rc) {
+   mutex_unlock(_mutex);
+   return rc;
+   }
+
raw_spin_lock_irqsave(_lock, flags);
rc = __of_update_property(np, newprop, );
raw_spin_unlock_irqrestore(_lock, flags);
diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index f0bf021..1ac9f49 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -85,6 +85,12 @@ const char *action_names[] = {
[OF_RECONFIG_ADD_PROPERTY] = "ADD_PROPERTY",
[OF_RECONFIG_REMOVE_PROPERTY] = "REMOVE_PROPERTY",
[OF_RECONFIG_UPDATE_PROPERTY] = "UPDATE_PROPERTY",
+
+   [OF_RECONFIG_PRE_ATTACH_NODE] = "PRE_ATTACH_NODE",
+   [OF_RECONFIG_PRE_DETACH_NODE] = "PRE_DETACH_NODE",
+   [OF_RECONFIG_PRE_ADD_PROPERTY] = "PRE_ADD_PROPERTY",
+   [OF_RECONFIG_PRE_REMOVE_PROPERTY] = "PRE_REMOVE_PROPERTY",
+   [OF_RECONFIG_PRE_UPDATE_PROPERTY] = "PRE_UPDATE_PROPERTY",
 };
 #endif
 
@@ -97,12 +103,17 @@ int of_reconfig_notify(unsigned long action, struct 
of_reconfig_data *p)
switch (action) {
case OF_RECONFIG_ATTACH_NODE:
case OF_RECONFIG_DETACH_NODE:
+   case OF_RECONFIG_PRE_ATTACH_NODE:
+   case OF_RECONFIG_PRE_DETACH_NODE:
pr_debug("of/notify %-15s %s\n", action_names[action],
pr->dn->full_name);
break;
case OF_RECONFIG_ADD_PROPERTY:
case OF_RECONFIG_REMOVE_PROPERTY:
case OF_RECONFIG_UPDATE_PROPERTY:
+   case OF_RECONFIG_PRE_ADD_PROPERTY:
+   case OF_RECONFIG_PRE_REMOVE_PROPERTY:
+   case OF_RECONFIG_PRE_UPDATE_PROPERTY:
pr_debug("of/notify %-15s %s:%s\n", action_names[action],
pr->dn->full_name, pr->prop->name);
break;
@@ -141,6 +152,13 @@ int of_reconfig_get_state_change(unsigned long action, 
struct of_reconfig_data *
prop = pr->prop;
old_prop = pr->old_prop;
break;
+   /* no state change during pre-apply notifications */
+   case OF_RECONFIG_PRE_ATTACH_NODE:
+   case OF_RECONFIG_PRE_DETACH_NODE:
+   case OF_RECONFIG_PRE_ADD_PROPERTY:
+   case OF_RECONFIG_PRE_REMOVE_PROPERTY:
+   case OF_RECONFIG_PRE_UPDATE_PROPERTY:
+   return OF_RECONFIG_NO_CHANGE;
default:
return OF_RECONFIG_NO_CHANGE;
}
@@ -502,10 +520,31 @@ static void __of_changeset_entry_invert(struct 
of_changeset_entry *ce,
}
 }
 
-static void __of_changeset_entry_notify(struct of_changeset_entry *ce, bool 
revert)
+static unsigned long __of_changeset_entry_pre_action(unsigned long action)
+{
+   switch (action) {
+   case OF_RECONFIG_ATTACH_NODE:
+   return OF_RECONFIG_PRE_ATTACH_NODE;
+   case OF_RECONFIG_DETACH_NODE:
+   return OF_RECONFIG_PRE_DETACH_NODE;
+   case OF_RECONFIG_ADD_PROPERTY:
+   return OF_RECONFIG_PRE_ADD_PROPERTY;
+   case OF_RECONFIG_REMOVE_PROPERTY:
+   return

[PATCH] of/overlay: add of overlay notifications

[Alan Tull]

This patch add of overlay notifications.

When DT overlays are being added, some drivers/subsystems
need to see device tree overlays before the changes go into
the live tree.

This is distinct from reconfig notifiers that are
post-apply or post-remove and which issue very granular
notifications without providing access to the context
of a whole overlay.

The following 4 notificatons are issued:
  OF_OVERLAY_PRE_APPLY
  OF_OVERLAY_POST_APPLY
  OF_OVERLAY_PRE_REMOVE
  OF_OVERLAY_POST_REMOVE

In the case of pre-apply notification, if the notifier
returns error, the overlay will be rejected.

This patch exports two functions for registering/unregistering
notifications:
  of_overlay_notifier_register(struct notifier_block *nb)
  of_overlay_notifier_unregister(struct notifier_block *nb)

The notification data includes pointers to the overlay
target and the overlay:

struct of_overlay_notify_data {
   struct device_node *overlay;
   struct device_node *target;
};

Signed-off-by: Alan Tull <at...@opensource.altera.com>
---
v2: add missing 'static inline' in of.h
---
 drivers/of/overlay.c |   47 ++-
 include/linux/of.h   |   25 +
 2 files changed, 71 insertions(+), 1 deletion(-)

diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 8225081..a26f0ed 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -56,6 +56,41 @@ struct of_overlay {
 static int of_overlay_apply_one(struct of_overlay *ov,
struct device_node *target, const struct device_node *overlay);
 
+static BLOCKING_NOTIFIER_HEAD(of_overlay_chain);
+
+int of_overlay_notifier_register(struct notifier_block *nb)
+{
+   return blocking_notifier_chain_register(_overlay_chain, nb);
+}
+EXPORT_SYMBOL_GPL(of_overlay_notifier_register);
+
+int of_overlay_notifier_unregister(struct notifier_block *nb)
+{
+   return blocking_notifier_chain_unregister(_overlay_chain, nb);
+}
+EXPORT_SYMBOL_GPL(of_overlay_notifier_unregister);
+
+static int of_overlay_notify(struct of_overlay *ov,
+enum of_overlay_notify_action action)
+{
+   struct of_overlay_notify_data nd;
+   int i, ret;
+
+   for (i = 0; i < ov->count; i++) {
+   struct of_overlay_info *ovinfo = >ovinfo_tab[i];
+
+   nd.target = ovinfo->target;
+   nd.overlay = ovinfo->overlay;
+
+   ret = blocking_notifier_call_chain(_overlay_chain,
+  action, );
+   if (ret)
+   return notifier_to_errno(ret);
+   }
+
+   return 0;
+}
+
 static int of_overlay_apply_single_property(struct of_overlay *ov,
struct device_node *target, struct property *prop)
 {
@@ -370,6 +405,13 @@ int of_overlay_create(struct device_node *tree)
goto err_free_idr;
}
 
+   err = of_overlay_notify(ov, OF_OVERLAY_PRE_APPLY);
+   if (err < 0) {
+   pr_err("%s: Pre-apply notifier failed (err=%d)\n",
+  __func__, err);
+   goto err_free_idr;
+   }
+
/* apply the overlay */
err = of_overlay_apply(ov);
if (err) {
@@ -389,6 +431,8 @@ int of_overlay_create(struct device_node *tree)
/* add to the tail of the overlay list */
list_add_tail(>node, _list);
 
+   of_overlay_notify(ov, OF_OVERLAY_POST_APPLY);
+
mutex_unlock(_mutex);
 
return id;
@@ -509,9 +553,10 @@ int of_overlay_destroy(int id)
goto out;
}
 
-
+   of_overlay_notify(ov, OF_OVERLAY_PRE_REMOVE);
list_del(>node);
__of_changeset_revert(>cset);
+   of_overlay_notify(ov, OF_OVERLAY_POST_REMOVE);
of_free_overlay_info(ov);
idr_remove(_idr, id);
of_changeset_destroy(>cset);
diff --git a/include/linux/of.h b/include/linux/of.h
index dc6e396..b79e1c5 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -1083,6 +1083,21 @@ int of_overlay_create(struct device_node *tree);
 int of_overlay_destroy(int id);
 int of_overlay_destroy_all(void);
 
+enum of_overlay_notify_action {
+   OF_OVERLAY_PRE_APPLY,
+   OF_OVERLAY_POST_APPLY,
+   OF_OVERLAY_PRE_REMOVE,
+   OF_OVERLAY_POST_REMOVE,
+};
+
+struct of_overlay_notify_data {
+   struct device_node *overlay;
+   struct device_node *target;
+};
+
+int of_overlay_notifier_register(struct notifier_block *nb);
+int of_overlay_notifier_unregister(struct notifier_block *nb);
+
 #else
 
 static inline int of_overlay_create(struct device_node *tree)
@@ -1100,6 +1115,16 @@ static inline int of_overlay_destroy_all(void)
return -ENOTSUPP;
 }
 
+static inline int of_overlay_notifier_register(struct notifier_block *nb)
+{
+   return 0;
+}
+
+static inline int of_overlay_notifier_unregister(struct notifier_block *nb)
+{
+   return 0;
+}
+
 #endif
 
 #endif /* _LINUX_OF_H */
-- 
1.7.9.5

[PATCH v17 0/6] Device Tree support for FPGA Programming

[Alan Tull]

v17 has a rewrite of devicetree/bindings/fpga/fpga-region.txt for clarity
and uses the overlay notifications that I've introduced and are being
discussed.

I'm mostly submitting to see if the bindings are looking acceptable-ish.

The bridge has been stable a long time.  I hope that can go in also.

Alan Tull (6):
  fpga: add bindings document for fpga region
  ARM: socfpga: add bindings document for fpga bridge drivers
  add sysfs document for fpga bridge class
  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   |  491 +
 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 |  555 
 include/linux/fpga/fpga-bridge.h   |   55 ++
 include/linux/fpga/fpga-mgr.h  |2 +
 12 files changed, 1979 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

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

[Alan Tull]

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

Signed-off-by: Alan Tull <at...@opensource.altera.com>
Signed-off-by: Moritz Fischer <moritz.fisc...@ettus.com>
---
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
v17: Lots of rewrites to try to make things clearer
 Clarify that overlay can be rejected if FPGA isn't programmed
 Add external-fpga-config binding already used in u-boot
 Change partial-reconfig binding to partial-fpga-config to align
   with existing u-boot binding format *-fpga-config
 Add a document from Xilinx' website
---
 .../devicetree/bindings/fpga/fpga-region.txt   |  491 
 1 file changed, 491 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..141274f
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt
@@ -0,0 +1,491 @@
+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.
+
+This device tree binding document hits some of the high points of FPGA usage 
and
+attempts to include terminology used by both major FPGA manufacturers.  This
+document isn't a replacement for any manufacturers white papers and
+specifications for FPGA usage.
+
+
+Terminology
+===
+
+Full Reconfiguration
+ * The entire FPGA is programmed.
+
+Partial Reconfiguration (PR)
+ * A section of the FPGA is reprogrammed while the rest of the FPGA is not
+   affected. Not all FPGA's support this.
+
+Partial Reconfiguration Region (PRR)
+ * Also called a "reconfigurable partition"
+ * A PRR is a specific section of a FPGA reserved for reconfiguration.
+ * A base (or static) FPGA image may create a set of PRR's that later may
+   be independently reprogrammed many times.
+ * The size and specific location of each PRR is fixed.
+ * The connections at the edge of each PRR are fixed.  The image that is loaded
+   into a PRR must fit and must use a subset of the region's connections.
+ * The busses within the FPGA are split such that each region gets its own
+   branch that may be gated independently.
+
+Persona
+ * Also called a "partial bit stream"
+ * 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
+ * An FPGA Manager is a hardware block that programs an FPGA under the control
+   of a host processor.
+
+
+   --
+|  Host CPU|   |   FPGA |
+|  |   ||
+|  |   |   ---  |
+|  | H |   |   |==>| FB0 |<==>| PRR0 |  |
+|  | W |   |   |   ---  |
+|  |   |   |   ||
+|  | B |<=>|<==|   ---  |
+|  | R |   |   |==>| FB1 |<==>| PRR

[PATCH] of/overlay: add of overlay notifications

[Alan Tull]

This patch add of overlay notifications.

When DT overlays are being added, some drivers/subsystems
need to see device tree overlays before the changes go into
the live tree.

This is distinct from reconfig notifiers that are
post-apply or post-remove and which issue very granular
notifications without providing access to the context
of a whole overlay.

The following 4 notificatons are issued:
  OF_OVERLAY_PRE_APPLY
  OF_OVERLAY_POST_APPLY
  OF_OVERLAY_PRE_REMOVE
  OF_OVERLAY_POST_REMOVE

In the case of pre-apply notification, if the notifier
returns error, the overlay will be rejected.

This patch exports two functions for registering/unregistering
notifications:
  of_overlay_notifier_register(struct notifier_block *nb)
  of_overlay_notifier_unregister(struct notifier_block *nb)

The notification data includes pointers to the overlay
target and the overlay:

struct of_overlay_notify_data {
   struct device_node *overlay;
   struct device_node *target;
};

Signed-off-by: Alan Tull <at...@opensource.altera.com>
---
 drivers/of/overlay.c |   47 ++-
 include/linux/of.h   |   25 +
 2 files changed, 71 insertions(+), 1 deletion(-)

diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 8225081..a26f0ed 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -56,6 +56,41 @@ struct of_overlay {
 static int of_overlay_apply_one(struct of_overlay *ov,
struct device_node *target, const struct device_node *overlay);
 
+static BLOCKING_NOTIFIER_HEAD(of_overlay_chain);
+
+int of_overlay_notifier_register(struct notifier_block *nb)
+{
+   return blocking_notifier_chain_register(_overlay_chain, nb);
+}
+EXPORT_SYMBOL_GPL(of_overlay_notifier_register);
+
+int of_overlay_notifier_unregister(struct notifier_block *nb)
+{
+   return blocking_notifier_chain_unregister(_overlay_chain, nb);
+}
+EXPORT_SYMBOL_GPL(of_overlay_notifier_unregister);
+
+static int of_overlay_notify(struct of_overlay *ov,
+enum of_overlay_notify_action action)
+{
+   struct of_overlay_notify_data nd;
+   int i, ret;
+
+   for (i = 0; i < ov->count; i++) {
+   struct of_overlay_info *ovinfo = >ovinfo_tab[i];
+
+   nd.target = ovinfo->target;
+   nd.overlay = ovinfo->overlay;
+
+   ret = blocking_notifier_call_chain(_overlay_chain,
+  action, );
+   if (ret)
+   return notifier_to_errno(ret);
+   }
+
+   return 0;
+}
+
 static int of_overlay_apply_single_property(struct of_overlay *ov,
struct device_node *target, struct property *prop)
 {
@@ -370,6 +405,13 @@ int of_overlay_create(struct device_node *tree)
goto err_free_idr;
}
 
+   err = of_overlay_notify(ov, OF_OVERLAY_PRE_APPLY);
+   if (err < 0) {
+   pr_err("%s: Pre-apply notifier failed (err=%d)\n",
+  __func__, err);
+   goto err_free_idr;
+   }
+
/* apply the overlay */
err = of_overlay_apply(ov);
if (err) {
@@ -389,6 +431,8 @@ int of_overlay_create(struct device_node *tree)
/* add to the tail of the overlay list */
list_add_tail(>node, _list);
 
+   of_overlay_notify(ov, OF_OVERLAY_POST_APPLY);
+
mutex_unlock(_mutex);
 
return id;
@@ -509,9 +553,10 @@ int of_overlay_destroy(int id)
goto out;
}
 
-
+   of_overlay_notify(ov, OF_OVERLAY_PRE_REMOVE);
list_del(>node);
__of_changeset_revert(>cset);
+   of_overlay_notify(ov, OF_OVERLAY_POST_REMOVE);
of_free_overlay_info(ov);
idr_remove(_idr, id);
of_changeset_destroy(>cset);
diff --git a/include/linux/of.h b/include/linux/of.h
index dc6e396..e70a686 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -1083,6 +1083,21 @@ int of_overlay_create(struct device_node *tree);
 int of_overlay_destroy(int id);
 int of_overlay_destroy_all(void);
 
+enum of_overlay_notify_action {
+   OF_OVERLAY_PRE_APPLY,
+   OF_OVERLAY_POST_APPLY,
+   OF_OVERLAY_PRE_REMOVE,
+   OF_OVERLAY_POST_REMOVE,
+};
+
+struct of_overlay_notify_data {
+   struct device_node *overlay;
+   struct device_node *target;
+};
+
+int of_overlay_notifier_register(struct notifier_block *nb);
+int of_overlay_notifier_unregister(struct notifier_block *nb);
+
 #else
 
 static inline int of_overlay_create(struct device_node *tree)
@@ -1100,6 +1115,16 @@ static inline int of_overlay_destroy_all(void)
return -ENOTSUPP;
 }
 
+int of_overlay_notifier_register(struct notifier_block *nb)
+{
+   return 0;
+}
+
+int of_overlay_notifier_unregister(struct notifier_block *nb)
+{
+   return 0;
+}
+
 #endif
 
 #endif /* _LINUX_OF_H */
-- 
1.7.9.5

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

[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 <at...@opensource.altera.com>
---
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
v17: No change to this patch in v17 of patch set
---
 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 <http://www.gnu.org/licenses/>.
+ */
+#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(>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:

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

[Alan Tull]

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

Signed-off-by: Alan Tull <at...@opensource.altera.com>
---
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
v17: Use new overlay notifier instead of reconfig notifier
 Add external_fpga_config property used in u-boot
 Change partial-reconfig binding to partial-fpga-config to be
   similar to *-fpga-config bindings used in u-boot
---
 drivers/fpga/Kconfig  |7 +
 drivers/fpga/Makefile |3 +
 drivers/fpga/fpga-region.c|  555 +
 include/linux/fpga/fpga-mgr.h |2 +
 4 files changed, 567 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..62b1799
--- /dev/null
+++ b/drivers/fpga/fpga-region.c
@@ -0,0 +1,555 @@
+/*
+ * 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 <http://www.gnu.org/licenses/>.
+ */
+
+#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(>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

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

[Alan Tull]

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

Signed-off-by: Alan Tull <at...@opensource.altera.com>
Signed-off-by: Matthew Gerlach <mgerl...@altera.com>
Signed-off-by: Dinh Nguyen <dingu...@opensource.altera.com>
---
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

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 = < LWHPS2FPGA_RESET>;
+   reset-names = "lwhps2fpga";
+   clocks = <_main_clk>;
+   bridge-enable = <0>;
+   };
+
+   hps_fpgabridge1: fpgabridge@ff50 {
+   compatible = "altr,socfpga-hps2fpga-bridge";
+   reg = <0xff50 0x1>;
+   resets = < HPS2FPGA_RESET>;
+   reset-names = "hps2fpga";
+   clocks = <_main_clk>;
+   bridge-enable = <1>;
+   };
+
+   hps_fpgabridge2: fpgabridge@ff60 {
+   compatible = "altr,socfpga-fpga2hps-bridge";
+   reg = <0xff60 0x10>;
+   resets = < FPGA2HPS_RESET>;
+   reset-names = "fpga2hps";
+   clocks = <_main_clk>;
+   };
-- 
1.7.9.5

[PATCH v17 3/6] add sysfs document for fpga bridge class

[Alan Tull]

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

Signed-off-by: Alan Tull <at...@opensource.altera.com>
--
v15: Document added in v15 of patch set
v16: No change to this patch in v16 of patch set
v17: No change to this patch in v17 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 <at...@opensource.altera.com>
+Description:   Name of low level FPGA bridge driver.
+
+What:  /sys/class/fpga_bridge//state
+Date:  January 2016
+KernelVersion: 4.5
+Contact:   Alan Tull <at...@opensource.altera.com>
+Description:   Show bridge state as "enabled" or "disabled"
-- 
1.7.9.5

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

[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 <at...@opensource.altera.com>
Signed-off-by: Matthew Gerlach <mgerl...@altera.com>
Signed-off-by: Dinh Nguyen <dingu...@opensource.altera.com>
---
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
v17: No change to this patch for v17 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 <http://www.gnu.org/licenses/>.
+ */
+
+/*
+ * 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_CT

[PATCH] of overlay callbacks

[Alan Tull]

Adding functionality for registering callbacks with the
of overlay code.  

When DT overlays are being added, some drivers/subsystems
will want to know about the changes before they go into the
live tree.  Similarly there is a need for post-remove
callbacks.

Each handler is registered with a of_device_id.  When
an overlay target matches a handler's id, the handler
gets called.

The following 4 cases are handled: pre-apply, post-apply,
pre-remove, and post-remove.

This is useful for me as I can apply an FPGA overlay that
contains the file name that I want to program the FPGA with
and the child device information.  My FPGA code gets the
pre-apply callback and attempts to program the FPGA.  If
the programming failed, the callback can return an error
and prevent the overlay from being applied.

I've tested this with code that uses pre-apply and post-remove
handlers.  Tested on next-20160216 and Pantelis' current
bbb-overlays branch.

Alan Tull (1):
  of/overlay: of overlay callbacks

 drivers/of/overlay.c |   90 +-
 include/linux/of.h   |   31 +
 2 files changed, 120 insertions(+), 1 deletion(-)

-- 
1.7.9.5

[PATCH] of/overlay: of overlay callbacks

[Alan Tull]

Add overlay callback functionality.

When DT overlays are being added, some drivers/subsystems
will want to know about the changes before they go into the
live tree.  Similarly there is a need for post-remove
callbacks.

Each handler is registered with a of_device_id.  When
an overlay target matches a handler's id, the handler
gets called.

The following 4 cases are handled: pre-apply, post-apply,
pre-remove, and post-remove.

Signed-off-by: Alan Tull <at...@opensource.altera.com>
---
 drivers/of/overlay.c |   90 +-
 include/linux/of.h   |   31 +
 2 files changed, 120 insertions(+), 1 deletion(-)

diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 8225081..ee88e4e 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -20,9 +20,13 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "of_private.h"
 
+static DEFINE_SPINLOCK(of_overlay_handler_lock);
+static LIST_HEAD(of_overlay_handler_list);
+
 /**
  * struct of_overlay_info - Holds a single overlay info
  * @target:target of the overlay operation
@@ -56,6 +60,80 @@ struct of_overlay {
 static int of_overlay_apply_one(struct of_overlay *ov,
struct device_node *target, const struct device_node *overlay);
 
+/*
+ * Send overlay callbacks to handlers that match.  This call is blocking.  In
+ * the case OF_OVERLAY_PRE_APPLY, return error for the first handler that 
fails.
+ * Otherwise, notify all the matching handlers and return success.
+ */
+static int send_overlay_callbacks(struct of_overlay *ov, int type)
+{
+   int i, ret;
+
+   spin_lock(_overlay_handler_lock);
+
+   for (i = 0; i < ov->count; i++) {
+   struct of_overlay_info *ovinfo = >ovinfo_tab[i];
+   struct of_overlay_handler *handler;
+   int (*callback)(struct of_overlay_msg *msg);
+   struct of_overlay_msg msg_data;
+
+   msg_data.target = ovinfo->target;
+   msg_data.overlay = ovinfo->overlay;
+
+   list_for_each_entry(handler, _overlay_handler_list, node) {
+   msg_data.priv = handler->priv;
+   switch (type) {
+   case OF_OVERLAY_PRE_APPLY:
+   callback = handler->pre_apply_callback;
+   break;
+   case OF_OVERLAY_POST_APPLY:
+   callback = handler->post_apply_callback;
+   break;
+   case OF_OVERLAY_PRE_REMOVE:
+   callback = handler->pre_remove_callback;
+   break;
+   case OF_OVERLAY_POST_REMOVE:
+   callback = handler->post_remove_callback;
+   break;
+   default:
+   continue;
+   };
+   if (!callback)
+   continue;
+   if (of_match_node(handler->of_match, ovinfo->target)) {
+   ret = callback(_data);
+   if ((ret < 0) && (type == 
OF_OVERLAY_PRE_APPLY)) {
+   spin_unlock(_overlay_handler_lock);
+   return ret;
+   }
+   continue;
+   }
+   }
+   }
+
+   spin_unlock(_overlay_handler_lock);
+
+   return 0;
+}
+
+int of_overlay_handler_register(struct of_overlay_handler *handler)
+{
+   spin_lock(_overlay_handler_lock);
+   list_add_tail(>node, _overlay_handler_list);
+   spin_unlock(_overlay_handler_lock);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(of_overlay_handler_register);
+
+void of_overlay_handler_unregister(struct of_overlay_handler *handler)
+{
+   spin_lock(_overlay_handler_lock);
+   list_del(>node);
+   spin_unlock(_overlay_handler_lock);
+}
+EXPORT_SYMBOL_GPL(of_overlay_handler_unregister);
+
 static int of_overlay_apply_single_property(struct of_overlay *ov,
struct device_node *target, struct property *prop)
 {
@@ -370,6 +448,13 @@ int of_overlay_create(struct device_node *tree)
goto err_free_idr;
}
 
+   err = send_overlay_callbacks(ov, OF_OVERLAY_PRE_APPLY);
+   if (err < 0) {
+   pr_err("%s: Pre apply handler failed (err=%d)\n",
+  __func__, err);
+   goto err_free_idr;
+   }
+
/* apply the overlay */
err = of_overlay_apply(ov);
if (err) {
@@ -389,6 +474,8 @@ int of_overlay_create(struct device_node *tree)
/* add to the tail of the overlay list */
list_add_tail(>node, _list);
 
+   send_overlay_callbacks(ov, OF_OVERLAY_POST_

[PATCH 0/1] of overlay callbacks

[Alan Tull]

[Resend as patch/cover letter got separated yesterday]

Adding functionality for registering callbacks with the
of overlay code.  

This will be useful for drivers responding to overlays
and will allow their implementations to not use reconfig
notifiers.  Also the reconfig notifiers are too late as
they go out after the overlay has been added to the live
tree.

My use of the overlay callback is to control FPGA
programming from a DT overlay.  The overlay would contain
the FPGA image file name and the child device information.
My FPGA code gets the pre-apply callback and attempts to
program the FPGA.  If the programming failed, the callback
can return an error and prevent the overlay from being
applied.  If FPGA programming succeeds, the overlay will
continue and be added to the live tree.  The child devices
in the overlay will get populated and probed.

I've tested this with code that uses pre-apply and post-remove
handlers.  Tested on next-20160216 and Pantelis' current
bbb-overlays branch.


Alan Tull (1):
  of/overlay: of overlay callbacks

 drivers/of/overlay.c |   90 +-
 include/linux/of.h   |   31 +
 2 files changed, 120 insertions(+), 1 deletion(-)

-- 
1.7.9.5

[PATCH 1/1] of/overlay: of overlay callbacks

[Alan Tull]

Add overlay callback functionality.

When DT overlays are being added, some drivers/subsystems
will want to know about the changes before they go into the
live tree.  Similarly there is a need for post-remove
callbacks.

Each handler is registered with a of_device_id.  When
an overlay target matches a handler's id, the handler
gets called.

The following 4 cases are handled: pre-apply, post-apply,
pre-remove, and post-remove.

Signed-off-by: Alan Tull <at...@opensource.altera.com>
---
 drivers/of/overlay.c |   90 +-
 include/linux/of.h   |   31 +
 2 files changed, 120 insertions(+), 1 deletion(-)

diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 8225081..ee88e4e 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -20,9 +20,13 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "of_private.h"
 
+static DEFINE_SPINLOCK(of_overlay_handler_lock);
+static LIST_HEAD(of_overlay_handler_list);
+
 /**
  * struct of_overlay_info - Holds a single overlay info
  * @target:target of the overlay operation
@@ -56,6 +60,80 @@ struct of_overlay {
 static int of_overlay_apply_one(struct of_overlay *ov,
struct device_node *target, const struct device_node *overlay);
 
+/*
+ * Send overlay callbacks to handlers that match.  This call is blocking.  In
+ * the case OF_OVERLAY_PRE_APPLY, return error for the first handler that 
fails.
+ * Otherwise, notify all the matching handlers and return success.
+ */
+static int send_overlay_callbacks(struct of_overlay *ov, int type)
+{
+   int i, ret;
+
+   spin_lock(_overlay_handler_lock);
+
+   for (i = 0; i < ov->count; i++) {
+   struct of_overlay_info *ovinfo = >ovinfo_tab[i];
+   struct of_overlay_handler *handler;
+   int (*callback)(struct of_overlay_msg *msg);
+   struct of_overlay_msg msg_data;
+
+   msg_data.target = ovinfo->target;
+   msg_data.overlay = ovinfo->overlay;
+
+   list_for_each_entry(handler, _overlay_handler_list, node) {
+   msg_data.priv = handler->priv;
+   switch (type) {
+   case OF_OVERLAY_PRE_APPLY:
+   callback = handler->pre_apply_callback;
+   break;
+   case OF_OVERLAY_POST_APPLY:
+   callback = handler->post_apply_callback;
+   break;
+   case OF_OVERLAY_PRE_REMOVE:
+   callback = handler->pre_remove_callback;
+   break;
+   case OF_OVERLAY_POST_REMOVE:
+   callback = handler->post_remove_callback;
+   break;
+   default:
+   continue;
+   };
+   if (!callback)
+   continue;
+   if (of_match_node(handler->of_match, ovinfo->target)) {
+   ret = callback(_data);
+   if ((ret < 0) && (type == 
OF_OVERLAY_PRE_APPLY)) {
+   spin_unlock(_overlay_handler_lock);
+   return ret;
+   }
+   continue;
+   }
+   }
+   }
+
+   spin_unlock(_overlay_handler_lock);
+
+   return 0;
+}
+
+int of_overlay_handler_register(struct of_overlay_handler *handler)
+{
+   spin_lock(_overlay_handler_lock);
+   list_add_tail(>node, _overlay_handler_list);
+   spin_unlock(_overlay_handler_lock);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(of_overlay_handler_register);
+
+void of_overlay_handler_unregister(struct of_overlay_handler *handler)
+{
+   spin_lock(_overlay_handler_lock);
+   list_del(>node);
+   spin_unlock(_overlay_handler_lock);
+}
+EXPORT_SYMBOL_GPL(of_overlay_handler_unregister);
+
 static int of_overlay_apply_single_property(struct of_overlay *ov,
struct device_node *target, struct property *prop)
 {
@@ -370,6 +448,13 @@ int of_overlay_create(struct device_node *tree)
goto err_free_idr;
}
 
+   err = send_overlay_callbacks(ov, OF_OVERLAY_PRE_APPLY);
+   if (err < 0) {
+   pr_err("%s: Pre apply handler failed (err=%d)\n",
+  __func__, err);
+   goto err_free_idr;
+   }
+
/* apply the overlay */
err = of_overlay_apply(ov);
if (err) {
@@ -389,6 +474,8 @@ int of_overlay_create(struct device_node *tree)
/* add to the tail of the overlay list */
list_add_tail(>node, _list);
 
+   send_overlay_callbacks(ov, OF_OVERLAY_POST_

Re: [PATCH v5 1/3] gpio: designware: convert device node to fwnode

[Alan Tull]

On Fri, Mar 4, 2016 at 1:44 AM, qiujiang  wrote:
> This patch converts device node to fwnode in
> dwapb_port_property for designware gpio driver,
> so as to provide a unified data structure for DT
> and ACPI bindings.
>
> Acked-by: Andy Shevchenko 
> Signed-off-by: qiujiang 
> ---
>  drivers/gpio/gpio-dwapb.c| 43 
> +++-
>  drivers/mfd/intel_quark_i2c_gpio.c   |  2 +-
>  include/linux/platform_data/gpio-dwapb.h |  2 +-
>  3 files changed, 22 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpio/gpio-dwapb.c b/drivers/gpio/gpio-dwapb.c
> index 597de1e..49f6e5d 100644
> --- a/drivers/gpio/gpio-dwapb.c
> +++ b/drivers/gpio/gpio-dwapb.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -290,14 +291,14 @@ static void dwapb_configure_irqs(struct dwapb_gpio 
> *gpio,
>  struct dwapb_port_property *pp)
>  {
> struct gpio_chip *gc = >gc;
> -   struct device_node *node = pp->node;
> +   struct fwnode_handle  *fwnode = pp->fwnode;
> struct irq_chip_generic *irq_gc = NULL;
> unsigned int hwirq, ngpio = gc->ngpio;
> struct irq_chip_type *ct;
> int err, i;
>
> -   gpio->domain = irq_domain_add_linear(node, ngpio,
> -_generic_chip_ops, gpio);
> +   gpio->domain = irq_domain_create_linear(fwnode, ngpio,
> +_generic_chip_ops, gpio);
> if (!gpio->domain)
> return;
>
> @@ -415,7 +416,8 @@ static int dwapb_gpio_add_port(struct dwapb_gpio *gpio,
> }
>
>  #ifdef CONFIG_OF_GPIO
> -   port->gc.of_node = pp->node;
> +   port->gc.of_node = is_of_node(pp->fwnode) ?
> +   to_of_node(pp->fwnode) : NULL;
>  #endif
> port->gc.ngpio = pp->ngpio;
> port->gc.base = pp->gpio_base;
> @@ -449,17 +451,13 @@ static void dwapb_gpio_unregister(struct dwapb_gpio 
> *gpio)
>  static struct dwapb_platform_data *
>  dwapb_gpio_get_pdata_of(struct device *dev)
>  {
> -   struct device_node *node, *port_np;
> +   struct fwnode_handle *fwnode;
> struct dwapb_platform_data *pdata;
> struct dwapb_port_property *pp;
> int nports;
> int i;
>
> -   node = dev->of_node;
> -   if (!IS_ENABLED(CONFIG_OF_GPIO) || !node)
> -   return ERR_PTR(-ENODEV);
> -
> -   nports = of_get_child_count(node);
> +   nports = device_get_child_node_count(dev);
> if (nports == 0)
> return ERR_PTR(-ENODEV);
>
> @@ -474,21 +472,19 @@ dwapb_gpio_get_pdata_of(struct device *dev)
> pdata->nports = nports;
>
> i = 0;
> -   for_each_child_of_node(node, port_np) {
> +   device_for_each_child_node(dev, fwnode)  {
> pp = >properties[i++];
> -   pp->node = port_np;
> +   pp->fwnode = fwnode;
>
> -   if (of_property_read_u32(port_np, "reg", >idx) ||
> +   if (fwnode_property_read_u32(fwnode, "reg", >idx) ||
> pp->idx >= DWAPB_MAX_PORTS) {
> -   dev_err(dev, "missing/invalid port index for %s\n",
> -   port_np->full_name);
> +   dev_err(dev, "missing/invalid port index\n");
> return ERR_PTR(-EINVAL);
> }
>
> -   if (of_property_read_u32(port_np, "snps,nr-gpios",
> +   if (fwnode_property_read_u32(fwnode, "snps,nr-gpios",
>  >ngpio)) {
> -   dev_info(dev, "failed to get number of gpios for 
> %s\n",
> -port_np->full_name);
> +   dev_info(dev, "failed to get number of gpios\n");
> pp->ngpio = 32;
> }
>
> @@ -496,18 +492,19 @@ dwapb_gpio_get_pdata_of(struct device *dev)
>  * Only port A can provide interrupts in all configurations of
>  * the IP.
>  */
> -   if (pp->idx == 0 &&
> -   of_property_read_bool(port_np, "interrupt-controller")) {
> -   pp->irq = irq_of_parse_and_map(port_np, 0);
> +   if (dev->of_node && pp->idx == 0 &&
> +   of_property_read_bool(to_of_node(fwnode),
> +   "interrupt-controller")) {

Hi Qiujiang,

Is there a reason to use "of_property_read_bool" here instead of
"device_property_read_bool" or similar?

Alan

> +   pp->irq = irq_of_parse_and_map(to_of_node(fwnode), 0);
> if (!pp->irq) {
> dev_warn(dev, "no irq for bank %s\n",
> -port_np->full_name);
> +

Re: [PATCH v5 0/3] "gpio: designware: add gpio-signaled acpi event support for power button"

[Alan Tull]

On Tue, Mar 8, 2016 at 8:26 PM, Linus Walleij  wrote:
> On Fri, Mar 4, 2016 at 2:44 PM, qiujiang  wrote:
>
>> This patchset adds gpio-signaled acpi events support for power button on 
>> hisilicon
>> D02 board.
>>
>> The three patches respectively:
>> - convert device node to fwnode
>> - add acpi binding
>> - add gpio-signaled acpi event support
>>
>>This patchset is based on
>>https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
>>branch "devel"
>>
>> Changes v4 -> v5:
>>- split into three patchs
>>- add Andy's ACKs
>>
>> Changes v3 -> v4:
>>- re-organize this two patchs by Andy's suggestion
>>
>> Changes v2 -> v3:
>>- fixed the build error reported by Kbuild test robot
>>
>> Changes v1 -> v2:
>>- rebase to branch "devel" of Linus Walleij's repository
>>- split in two patch as suggested by Andy S
>>- add Mika's ACKs
>>
>> qiujiang (3):
>>   gpio: designware: convert device node to fwnode
>>   gpio: designware: add acpi binding
>>   gpio: designware: add gpio-signaled acpi event support
>
> I noticed that the original driver authors Jamie and Alan have not been
> properly CC:ed on this patch. Jamie, Alan: can you look at this and
> ACK it if you like what you see?
>
> Yours,
> Linus Walleij

Hi Linus,

I briefly tested the patches on a ARM CycloneV board and didn't see
any issues.  I looked over the patches (not super familiar with ACPI)
and just had one question (on another thread).

Thanks,
Alan

Re: [PATCH v6 1/2] gpio: dwapb: convert device node to fwnode

[Alan Tull]

On Fri, Mar 25, 2016 at 9:31 PM, qiujiang  wrote:

> -   if (pp->idx == 0 &&
> -   of_property_read_bool(port_np, "interrupt-controller")) {
> -   pp->irq = irq_of_parse_and_map(port_np, 0);
> +   if (dev->of_node && pp->idx == 0 &&
> +   fwnode_property_read_bool(fwnode,
> + "interrupt-controller")) {
> +   pp->irq = irq_of_parse_and_map(to_of_node(fwnode), 0);
> if (!pp->irq) {
> dev_warn(dev, "no irq for bank %s\n",
> -port_np->full_name);
> +to_of_node(fwnode)->full_name);
> }
> }
>
> pp->irq_shared  = false;
> pp->gpio_base   = -1;
> -   pp->name= port_np->full_name;
> +   if (dev->of_node)
> +   pp->name = to_of_node(fwnode)->full_name;

Hi Jiang,

I tested lightly on a CycloneV and it worked fine (with device tree).

One suggestion for both patches: you could remove name from struct
dwapb_port_property and get rid of pp->name and nobody would miss it.
All it is used for is some dev_err's so the device info gets printed
anyway.  For example (if I leave the irq out of the DT)

gpio-dwapb ff708000.gpio: no irq for bank /soc/gpio@ff708000/gpio-controller@0

is redundant.  The only additional info here from the name is the port
index.  That could be added to the messages without having to get the
name through the two property/of methods.

Alan

Re: [PATCH v5 1/3] gpio: designware: convert device node to fwnode

[Alan Tull]

On Wed, Mar 23, 2016 at 6:41 AM, Jiang Qiu <qiuji...@huawei.com> wrote:
> 在 2016/3/11 4:27, Andy Shevchenko 写道:
>> On Thu, Mar 10, 2016 at 9:09 PM, Alan Tull <delicious.qui...@gmail.com> 
>> wrote:
>>> On Fri, Mar 4, 2016 at 1:44 AM, qiujiang <qiuji...@huawei.com> wrote:
>>>> This patch converts device node to fwnode in
>>>> dwapb_port_property for designware gpio driver,
>>>> so as to provide a unified data structure for DT
>>>> and ACPI bindings.
>>>>
>>>> Acked-by: Andy Shevchenko <andy.shevche...@gmail.com>
>>>> Signed-off-by: qiujiang <qiuji...@huawei.com>
>>>> @@ -496,18 +492,19 @@ dwapb_gpio_get_pdata_of(struct device *dev)
>>>>  * Only port A can provide interrupts in all 
>>>> configurations of
>>>>  * the IP.
>>>>  */
>>>> -   if (pp->idx == 0 &&
>>>> -   of_property_read_bool(port_np, 
>>>> "interrupt-controller")) {
>>>> -   pp->irq = irq_of_parse_and_map(port_np, 0);
>>>> +   if (dev->of_node && pp->idx == 0 &&
>>>> +   of_property_read_bool(to_of_node(fwnode),
>>>> +   "interrupt-controller")) {
>>> Hi Qiujiang,
>>>
>>> Is there a reason to use "of_property_read_bool" here instead of
>>> "device_property_read_bool" or similar?
>> Yeah, this patch looks unfinished.
>>
>> This should be
>>  if (pp->idx == 0 &&  fwnode_property_read_bool(fwnode,
>> "interrupt-controller")) {
> Hi, Alan, Andy, Mika,
>
> Many thanks for help me review this patchset.
>
> I tried to use a unified interface to parse the interrupts resource in DT and 
> ACPI,
> but it looks difficult because of the hierarchy device node structure as 
> follow:
>
> pc_gpio1: gpio@802f {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "snps,dw-apb-gpio";
> reg = <0x0 0x802f 0x0 0x1>;
>
> porta: gpio-controller@0 {
> compatible = "snps,dw-apb-gpio-port";
> gpio-controller;
> #gpio-cells = <2>;
> snps,nr-gpios = <32>;
> reg = <0>;
> interrupt-controller;
> #interrupt-cells = <2>;
> interrupts = <0 313 4>;
> };
> };
>
> According to the designware gpio databook, each GPIO controller includes 4 
> ports
> (porta,b,c,d), only porta can be a interrupt controller. So, I moved the 
> interrupts
> resource to the parent node from porta in ACPI.
>
> Device(GPI0) {
> Name(_HID, "HISI0181")
> Name(_ADR, 0) // _ADR: Address
> Name(_UID, 0)
>
> Name (_CRS, ResourceTemplate ()  {
> Memory32Fixed (ReadWrite, 0x802e, 0x1)
> Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive,,,)  
> {344} //moved here
> })
>
> Device(PRTa) {
> Name (_DSD, Package () {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package () {"reg",0},
> Package () {"snps,nr-gpios",32},
> }
> })
> }
> }
>
> That is to say, if GPI0 should be a interrupt controller, the child node PRTa 
> must be
> present first, then add the interrupt resource to the parent node GPI0 scope.
>
> Dose this proposal sounds ok? if yes, we can do that for DT. If not, there 
> can only
> keep two branches to parse the IRQ resource, and the code looks strange.

Hi Jiang,

Are you suggesting a change for the DT to make it similar to the ACPI
case?  DT changes create unexpected breakages when people upgrade
their kernel even if the change is minor.  How bad will the code look
if you implement it as the two separate code paths as you suggest?

Alan

>
> That would be great if I can get some help from you.
>
> Best Regards
> Jiang
>>> Alan
>>>
>>>> +   pp->irq = irq_of_parse_and_map(to_of_node(fwnode), 
>>>> 0);
>> But here should be common method called which takes fwnode on input.
>>
>>>> if (!pp->irq) {
>>>> dev_warn(dev, "no irq for bank %s\n",
>>>> -port_np->full_name);
>>>> +to_of_node(fwnode)->full_name);
>>>> }
>>>> }
>>>>
>>>> pp->irq_shared  = false;
>>>> pp->gpio_base   = -1;
>>>> -   pp->name= port_np->full_name;
>>>> +   pp->name= to_of_node(fwnode)->full_name;
>> Also those two should be device property source agnostic. That's what
>> I tried to tell earlier.
>>
>
>

[PATCH v3] of/overlay: add of overlay notifications

[Alan Tull]

This patch add of overlay notifications.

When DT overlays are being added, some drivers/subsystems
need to see device tree overlays before the changes go into
the live tree.

This is distinct from reconfig notifiers that are
post-apply or post-remove and which issue very granular
notifications without providing access to the context
of a whole overlay.

The following 4 notificatons are issued:
  OF_OVERLAY_PRE_APPLY
  OF_OVERLAY_POST_APPLY
  OF_OVERLAY_PRE_REMOVE
  OF_OVERLAY_POST_REMOVE

In the case of pre-apply notification, if the notifier
returns error, the overlay will be rejected.

This patch exports two functions for registering/unregistering
notifications:
  of_overlay_notifier_register(struct notifier_block *nb)
  of_overlay_notifier_unregister(struct notifier_block *nb)

The of_mutex is held during these notifications. The
notification data includes pointers to the overlay target
and the overlay:

struct of_overlay_notify_data {
   struct device_node *overlay;
   struct device_node *target;
};

Signed-off-by: Alan Tull <at...@opensource.altera.com>
---
v2: add missing 'static inline' in of.h
v3: fix build for !OF_OVERLAY in of.h
add a note in the header that the of_mutex is held
---
 drivers/of/overlay.c |   47 ++-
 include/linux/of.h   |   25 +
 2 files changed, 71 insertions(+), 1 deletion(-)

diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index 8225081..a26f0ed 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -56,6 +56,41 @@ struct of_overlay {
 static int of_overlay_apply_one(struct of_overlay *ov,
struct device_node *target, const struct device_node *overlay);
 
+static BLOCKING_NOTIFIER_HEAD(of_overlay_chain);
+
+int of_overlay_notifier_register(struct notifier_block *nb)
+{
+   return blocking_notifier_chain_register(_overlay_chain, nb);
+}
+EXPORT_SYMBOL_GPL(of_overlay_notifier_register);
+
+int of_overlay_notifier_unregister(struct notifier_block *nb)
+{
+   return blocking_notifier_chain_unregister(_overlay_chain, nb);
+}
+EXPORT_SYMBOL_GPL(of_overlay_notifier_unregister);
+
+static int of_overlay_notify(struct of_overlay *ov,
+enum of_overlay_notify_action action)
+{
+   struct of_overlay_notify_data nd;
+   int i, ret;
+
+   for (i = 0; i < ov->count; i++) {
+   struct of_overlay_info *ovinfo = >ovinfo_tab[i];
+
+   nd.target = ovinfo->target;
+   nd.overlay = ovinfo->overlay;
+
+   ret = blocking_notifier_call_chain(_overlay_chain,
+  action, );
+   if (ret)
+   return notifier_to_errno(ret);
+   }
+
+   return 0;
+}
+
 static int of_overlay_apply_single_property(struct of_overlay *ov,
struct device_node *target, struct property *prop)
 {
@@ -370,6 +405,13 @@ int of_overlay_create(struct device_node *tree)
goto err_free_idr;
}
 
+   err = of_overlay_notify(ov, OF_OVERLAY_PRE_APPLY);
+   if (err < 0) {
+   pr_err("%s: Pre-apply notifier failed (err=%d)\n",
+  __func__, err);
+   goto err_free_idr;
+   }
+
/* apply the overlay */
err = of_overlay_apply(ov);
if (err) {
@@ -389,6 +431,8 @@ int of_overlay_create(struct device_node *tree)
/* add to the tail of the overlay list */
list_add_tail(>node, _list);
 
+   of_overlay_notify(ov, OF_OVERLAY_POST_APPLY);
+
mutex_unlock(_mutex);
 
return id;
@@ -509,9 +553,10 @@ int of_overlay_destroy(int id)
goto out;
}
 
-
+   of_overlay_notify(ov, OF_OVERLAY_PRE_REMOVE);
list_del(>node);
__of_changeset_revert(>cset);
+   of_overlay_notify(ov, OF_OVERLAY_POST_REMOVE);
of_free_overlay_info(ov);
idr_remove(_idr, id);
of_changeset_destroy(>cset);
diff --git a/include/linux/of.h b/include/linux/of.h
index dc6e396..33832a9 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -1076,6 +1076,18 @@ static inline bool 
of_device_is_system_power_controller(const struct device_node
  * Overlay support
  */
 
+enum of_overlay_notify_action {
+   OF_OVERLAY_PRE_APPLY,
+   OF_OVERLAY_POST_APPLY,
+   OF_OVERLAY_PRE_REMOVE,
+   OF_OVERLAY_POST_REMOVE,
+};
+
+struct of_overlay_notify_data {
+   struct device_node *overlay;
+   struct device_node *target;
+};
+
 #ifdef CONFIG_OF_OVERLAY
 
 /* ID based overlays; the API for external users */
@@ -1083,6 +1095,9 @@ int of_overlay_create(struct device_node *tree);
 int of_overlay_destroy(int id);
 int of_overlay_destroy_all(void);
 
+int of_overlay_notifier_register(struct notifier_block *nb);
+int of_overlay_notifier_unregister(struct notifier_block *nb);
+
 #else
 
 static inline int of_overlay_create(struct device_no

Re: [PATCH v9 0/3] gpio: dwapb: add gpio-signaled acpi event support for power button

[Alan Tull]

On Wed, Apr 20, 2016 at 8:06 AM, Andy Shevchenko
<andy.shevche...@gmail.com> wrote:
> On Wed, Apr 20, 2016 at 10:13 AM, Jiang Qiu <qiuji...@huawei.com> wrote:
>> This patchset adds gpio-signaled acpi events support for power button on 
>> hisilicon
>> D02 board.
>>
>> The three patches respectively:
>> - remove name from dwapb_port_property
>> - convert device node to fwnode
>> - add gpio-signaled acpi event support
>>
>>This patchset is based on
>>https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
>>branch "devel"
>>
>> Changes v8 -> v9:
>>- fixed a low-level compile warning
>
> Please, don't send updates to often. You see, now I noticed one more
> thing you have to address.
> Usually the time between fixup series is something like 24h. Thus,
> waiting for v10 at least tomorrow or even next week.
>
> Linus, for my point of view next version should be fine and final. The
> current code is in a good shape already.

Reviewed, tested v9, looks good.

Alan Tull


>
>>
>> Changes v7 -> v8:
>>- fixed few minors
>>
>> Changes v6 -> v7:
>>- add patch1 by Alan's suggestion
>>
>> Changes v5 -> v6:
>>- merge patch 2~3 to one patch
>>- small fixed from Alan's suggestion
>>- fixed subject title reference commit history
>>
>> Changes v4 -> v5:
>>- split into three patchs
>>- add Andy's ACKs
>>
>> Changes v3 -> v4:
>>- re-organize this two patchs by Andy's suggestion
>>
>> Changes v2 -> v3:
>>- fixed the build error reported by Kbuild test robot
>>
>> Changes v1 -> v2:
>>- rebase to branch "devel" of Linus Walleij's repository
>>- split in two patch as suggested by Andy S
>>- add Mika's ACKs
>>
>> Jiang Qiu (3):
>>   gpio: dwapb: remove name from dwapb_port_property
>>   gpio: dwapb: convert device node to fwnode
>>   gpio: dwapb: add gpio-signaled acpi event support
>>
>>  drivers/gpio/gpio-dwapb.c| 78 
>> +++-
>>  drivers/mfd/intel_quark_i2c_gpio.c   |  3 +-
>>  include/linux/platform_data/gpio-dwapb.h |  3 +-
>>  3 files changed, 48 insertions(+), 36 deletions(-)
>>
>> --
>> 1.9.1
>>
>
>
>
> --
> With Best Regards,
> Andy Shevchenko

Re: [PATCH v18 4/6] fpga: add fpga bridge framework

[Alan Tull]

On Thu, Jul 14, 2016 at 3:54 PM, Paul Gortmaker
<paul.gortma...@windriver.com> wrote:
> On Tue, Jul 12, 2016 at 3:36 PM, Alan Tull <at...@opensource.altera.com> 
> wrote:
>> 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 <at...@opensource.altera.com>
>> ---
>> 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
>> v17: No change to this patch in v17 of patch set
>> v18: No change to this patch in v18 of patch set
>> ---
>>  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 d614102..46e20af 100644
>> --- a/drivers/fpga/Kconfig
>> +++ b/drivers/fpga/Kconfig
>> @@ -25,6 +25,13 @@ config FPGA_MGR_ZYNQ_FPGA
>> help
>>   FPGA manager driver support for Xilinx Zynq FPGAs.
>>
>> +config FPGA_BRIDGE
>> +   bool "FPGA Bridge Framework"
>
> Same here. A bool Kconfig but module.h etc. used in the driver.
>
> Either make the code modular with a tristate if there is a valid
> use case for that, or get rid of the modular references.

Yes, of course.  Thanks!

Alan Tull

>
> Thanks,
> Paul.
> --

[PATCH 2/2] fpga-manager: Add Socfpga Arria10 support

[Alan Tull]

Add low level driver to support reprogramming FPGAs for Altera
SoCFPGA Arria10.

Signed-off-by: Alan Tull <at...@opensource.altera.com>
---
 drivers/fpga/Kconfig   |   6 +
 drivers/fpga/Makefile  |   1 +
 drivers/fpga/socfpga-a10.c | 573 +
 3 files changed, 580 insertions(+)
 create mode 100644 drivers/fpga/socfpga-a10.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index b346166..1a18623 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -26,6 +26,12 @@ config FPGA_MGR_SOCFPGA
help
  FPGA manager driver support for Altera SOCFPGA.
 
+config FPGA_MGR_SOCFPGA_A10
+   tristate "Altera SoCFPGA Arria10"
+   depends on ARCH_SOCFPGA
+   help
+ FPGA manager driver support for Altera Arria10 SoCFPGA.
+
 config FPGA_MGR_ZYNQ_FPGA
tristate "Xilinx Zynq FPGA"
depends on HAS_DMA
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index e658436..0375cbd 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_FPGA)  += fpga-mgr.o
 
 # FPGA Manager Drivers
 obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
+obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10) += socfpga-a10.o
 obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)   += zynq-fpga.o
 
 # FPGA Bridge Drivers
diff --git a/drivers/fpga/socfpga-a10.c b/drivers/fpga/socfpga-a10.c
new file mode 100644
index 000..63e0c5b
--- /dev/null
+++ b/drivers/fpga/socfpga-a10.c
@@ -0,0 +1,573 @@
+/*
+ * FPGA Manager Driver for Altera Arria10 SoCFPGA
+ *
+ * Copyright (C) 2015-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 <http://www.gnu.org/licenses/>.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define A10_FPGAMGR_DCLKCNT_OFST   0x08
+#define A10_FPGAMGR_DCLKSTAT_OFST  0x0c
+#define A10_FPGAMGR_IMGCFG_CTL_00_OFST 0x70
+#define A10_FPGAMGR_IMGCFG_CTL_01_OFST 0x74
+#define A10_FPGAMGR_IMGCFG_CTL_02_OFST 0x78
+#define A10_FPGAMGR_IMGCFG_STAT_OFST   0x80
+
+#define A10_FPGAMGR_DCLKSTAT_DCLKDONE  BIT(0)
+
+#define A10_FPGAMGR_IMGCFG_CTL_00_S2F_NENABLE_NCONFIG  BIT(0)
+#define A10_FPGAMGR_IMGCFG_CTL_00_S2F_NENABLE_NSTATUS  BIT(1)
+#define A10_FPGAMGR_IMGCFG_CTL_00_S2F_NENABLE_CONDONE  BIT(2)
+#define A10_FPGAMGR_IMGCFG_CTL_00_S2F_NCONFIG  BIT(8)
+#define A10_FPGAMGR_IMGCFG_CTL_00_S2F_NSTATUS_OE   BIT(16)
+#define A10_FPGAMGR_IMGCFG_CTL_00_S2F_CONDONE_OE   BIT(24)
+
+#define A10_FPGAMGR_IMGCFG_CTL_01_S2F_NENABLE_CONFIG   BIT(0)
+#define A10_FPGAMGR_IMGCFG_CTL_01_S2F_PR_REQUEST   BIT(16)
+#define A10_FPGAMGR_IMGCFG_CTL_01_S2F_NCE  BIT(24)
+
+#define A10_FPGAMGR_IMGCFG_CTL_02_EN_CFG_CTRL  BIT(0)
+#define A10_FPGAMGR_IMGCFG_CTL_02_CDRATIO_MASK (BIT(16) | BIT(17))
+#define A10_FPGAMGR_IMGCFG_CTL_02_CDRATIO_SHIFT16
+#define A10_FPGAMGR_IMGCFG_CTL_02_CFGWIDTH BIT(24)
+#define A10_FPGAMGR_IMGCFG_CTL_02_CFGWIDTH_SHIFT   24
+
+#define A10_FPGAMGR_IMGCFG_STAT_F2S_CRC_ERROR  BIT(0)
+#define A10_FPGAMGR_IMGCFG_STAT_F2S_EARLY_USERMODE BIT(1)
+#define A10_FPGAMGR_IMGCFG_STAT_F2S_USERMODE   BIT(2)
+#define A10_FPGAMGR_IMGCFG_STAT_F2S_NSTATUS_PINBIT(4)
+#define A10_FPGAMGR_IMGCFG_STAT_F2S_CONDONE_PINBIT(6)
+#define A10_FPGAMGR_IMGCFG_STAT_F2S_PR_READY   BIT(9)
+#define A10_FPGAMGR_IMGCFG_STAT_F2S_PR_DONEBIT(10)
+#define A10_FPGAMGR_IMGCFG_STAT_F2S_PR_ERROR   BIT(11)
+#define A10_FPGAMGR_IMGCFG_STAT_F2S_NCONFIG_PINBIT(12)
+#define A10_FPGAMGR_IMGCFG_STAT_F2S_MSEL_MASK  (BIT(16) | BIT(17) | BIT(18))
+#define A10_FPGAMGR_IMGCFG_STAT_F2S_MSEL_SHIFT 16
+
+/* FPGA CD Ratio Value */
+#define CDRATIO_x1 0x0
+#define CDRATIO_x2 0x1
+#define CDRATIO_x4 0x2
+#define CDRATIO_x8 0x3
+
+/* Configuration width 

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

[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 <at...@opensource.altera.com>
Signed-off-by: Matthew Gerlach <mgerl...@altera.com>
Signed-off-by: Dinh Nguyen <dingu...@opensource.altera.com>
---
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
v17: No change to this patch for v17 of this patch set
v18: Eliminate need to specify reset names since only one reset
---
 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 ec81e21..b346166 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -39,6 +39,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 <http://www.gnu.org/licenses/>.
+ */
+
+/*
+ * 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 
+

[PATCH v18 0/6] Device Tree support for FPGA Programming

[Alan Tull]

v18 has very minimal changes to address comments about the device
tree bindings and device tree examples in the bindings document.

The diffstat from v17 is:
  4 files changed, 11 insertions(+), 18 deletions(-)
If there are more changes, it would be easier to
send these upstream and just start adding small
patches to fix whatever else.

Alan Tull (6):
  fpga: add bindings document for fpga region
  ARM: socfpga: add bindings document for fpga bridge drivers
  add sysfs document for fpga bridge class
  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 |  16 +
 .../bindings/fpga/altera-hps2fpga-bridge.txt   |  39 ++
 .../devicetree/bindings/fpga/fpga-region.txt   | 491 ++
 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 | 555 +
 include/linux/fpga/fpga-bridge.h   |  55 ++
 include/linux/fpga/fpga-mgr.h  |   2 +
 12 files changed, 1972 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

-- 
2.9.1

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

[Alan Tull]

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

Signed-off-by: Alan Tull <at...@opensource.altera.com>
Signed-off-by: Matthew Gerlach <mgerl...@altera.com>
Signed-off-by: Dinh Nguyen <dingu...@opensource.altera.com>
---
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
v18: Changed to not need reset-names property
 node names as fpga-bridge@...
 labels as fpga_bridge
 Add address of fpgaportrst to give and address for f2s bridge
---
 .../bindings/fpga/altera-fpga2sdram-bridge.txt | 16 +
 .../bindings/fpga/altera-hps2fpga-bridge.txt   | 39 ++
 2 files changed, 55 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..817a8d4
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/altera-fpga2sdram-bridge.txt
@@ -0,0 +1,16 @@
+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:
+   fpga_bridge3: fpga-bridge@ffc25080 {
+   compatible = "altr,socfpga-fpga2sdram-bridge";
+   reg = <0xffc25080 0x4>;
+   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..6406f93
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
@@ -0,0 +1,39 @@
+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"
+- resets   : Phandle and reset specifier for this bridge's reset
+- 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:
+   fpga_bridge0: fpga-bridge@ff40 {
+   compatible = "altr,socfpga-lwhps2fpga-bridge";
+   reg = <0xff40 0x10>;
+   resets = < LWHPS2FPGA_RESET>;
+   clocks = <_main_clk>;
+   bridge-enable = <0>;
+   };
+
+   fpga_bridge1: fpga-bridge@ff50 {
+   compatible = "altr,socfpga-hps2fpga-bridge";
+   reg = <0xff50 0x1>;
+   resets = < HPS2FPGA_RESET>;
+   clocks = <_main_clk>;
+   bridge-enable = <1>;
+   };
+
+   fpga_bridge2: fpga-bridge@ff60 {
+   compatible = "altr,socfpga-fpga2hps-bridge";
+   reg = <0xff60 0x10>;
+   resets = < FPGA2HPS_RESET>;
+   clocks = <_main_clk>;
+   };
-- 
2.9.1

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

[Alan Tull]

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

Signed-off-by: Alan Tull <at...@opensource.altera.com>
Signed-off-by: Moritz Fischer <moritz.fisc...@ettus.com>
---
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
v17: Lots of rewrites to try to make things clearer
 Clarify that overlay can be rejected if FPGA isn't programmed
 Add external-fpga-config binding already used in u-boot
 Change partial-reconfig binding to partial-fpga-config to align
   with existing u-boot binding format *-fpga-config
 Add a document from Xilinx' website
v18: Fix node names underscores to be hyphens
 Fix copy/pasted duplicate nodes in diagram
---
 .../devicetree/bindings/fpga/fpga-region.txt   | 491 +
 1 file changed, 491 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..cfac8c2
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt
@@ -0,0 +1,491 @@
+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.
+
+This device tree binding document hits some of the high points of FPGA usage 
and
+attempts to include terminology used by both major FPGA manufacturers.  This
+document isn't a replacement for any manufacturers white papers and
+specifications for FPGA usage.
+
+
+Terminology
+===
+
+Full Reconfiguration
+ * The entire FPGA is programmed.
+
+Partial Reconfiguration (PR)
+ * A section of the FPGA is reprogrammed while the rest of the FPGA is not
+   affected. Not all FPGA's support this.
+
+Partial Reconfiguration Region (PRR)
+ * Also called a "reconfigurable partition"
+ * A PRR is a specific section of a FPGA reserved for reconfiguration.
+ * A base (or static) FPGA image may create a set of PRR's that later may
+   be independently reprogrammed many times.
+ * The size and specific location of each PRR is fixed.
+ * The connections at the edge of each PRR are fixed.  The image that is loaded
+   into a PRR must fit and must use a subset of the region's connections.
+ * The busses within the FPGA are split such that each region gets its own
+   branch that may be gated independently.
+
+Persona
+ * Also called a "partial bit stream"
+ * 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
+ * An FPGA Manager is a hardware block that programs an FPGA under the control
+   of a host processor.
+
+
+   --
+|  Host CPU|   |   FPGA |
+|  |   ||
+|  |   |   ---  |
+|  | H |   |   |==>| FB0 |<==>| PRR0 |  |
+|  | W |   |   |   ---  |
+|  |   |   |   ||
+|  | B |<=>|<==|   ---  |
+ 

[PATCH 0/2] FPGA Manager support for Arria10

[Alan Tull]

New patch submission for FPGA Manager support for the Altera
SoCFPGA Arria10 plus device tree bindings.

Alan Tull (2):
  ARM: socfpga: add bindings doc for arria10 fpga manager
  fpga-manager: Add Socfpga Arria10 support

 .../bindings/fpga/altera-socfpga-a10-fpga-mgr.txt  |  19 +
 drivers/fpga/Kconfig   |   6 +
 drivers/fpga/Makefile  |   1 +
 drivers/fpga/socfpga-a10.c | 573 +
 4 files changed, 599 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/fpga/altera-socfpga-a10-fpga-mgr.txt
 create mode 100644 drivers/fpga/socfpga-a10.c

-- 
2.9.1

[PATCH 1/2] ARM: socfpga: add bindings doc for arria10 fpga manager

[Alan Tull]

Add a device tree bindings document for the SoCFPGA Arria10
FPGA Manager driver.

Signed-off-by: Alan Tull <at...@opensource.altera.com>
---
 .../bindings/fpga/altera-socfpga-a10-fpga-mgr.txt | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/fpga/altera-socfpga-a10-fpga-mgr.txt

diff --git 
a/Documentation/devicetree/bindings/fpga/altera-socfpga-a10-fpga-mgr.txt 
b/Documentation/devicetree/bindings/fpga/altera-socfpga-a10-fpga-mgr.txt
new file mode 100644
index 000..2fd8e7a
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/altera-socfpga-a10-fpga-mgr.txt
@@ -0,0 +1,19 @@
+Altera SOCFPGA Arria10 FPGA Manager
+
+Required properties:
+- compatible : should contain "altr,socfpga-a10-fpga-mgr"
+- reg: base address and size for memory mapped io.
+   - The first index is for FPGA manager register access.
+   - The second index is for writing FPGA configuration data.
+- resets : Phandle and reset specifier for the device's reset.
+- clocks : Clocks used by the device.
+
+Example:
+
+   fpga_mgr: fpga-mgr@ffd03000 {
+   compatible = "altr,socfpga-a10-fpga-mgr";
+   reg = <0xffd03000 0x100
+  0xffcfe400 0x20>;
+   clocks = <_mp_clk>;
+   resets = < FPGAMGR_RESET>;
+   };
-- 
2.9.1

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

[Alan Tull]

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

Signed-off-by: Alan Tull <at...@opensource.altera.com>
---
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
v17: Use new overlay notifier instead of reconfig notifier
 Add external_fpga_config property used in u-boot
 Change partial-reconfig binding to partial-fpga-config to be
   similar to *-fpga-config bindings used in u-boot
v18: No change to this patch in v18 of patch set
---
 drivers/fpga/Kconfig  |   7 +
 drivers/fpga/Makefile |   3 +
 drivers/fpga/fpga-region.c| 555 ++
 include/linux/fpga/fpga-mgr.h |   2 +
 4 files changed, 567 insertions(+)
 create mode 100644 drivers/fpga/fpga-region.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 46e20af..ec81e21 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..62b1799
--- /dev/null
+++ b/drivers/fpga/fpga-region.c
@@ -0,0 +1,555 @@
+/*
+ * 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 <http://www.gnu.org/licenses/>.
+ */
+
+#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(>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 (!

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

[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 <at...@opensource.altera.com>
---
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
v17: No change to this patch in v17 of patch set
v18: No change to this patch in v18 of patch set
---
 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 d614102..46e20af 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -25,6 +25,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 <http://www.gnu.org/licenses/>.
+ */
+#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(>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 transa

[PATCH v18 3/6] add sysfs document for fpga bridge class

[Alan Tull]

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

Signed-off-by: Alan Tull <at...@opensource.altera.com>
--
v15: Document added in v15 of patch set
v16: No change to this patch in v16 of patch set
v17: No change to this patch in v17 of patch set
v18: No change to this patch in v18 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 <at...@opensource.altera.com>
+Description:   Name of low level FPGA bridge driver.
+
+What:  /sys/class/fpga_bridge//state
+Date:  January 2016
+KernelVersion: 4.5
+Contact:   Alan Tull <at...@opensource.altera.com>
+Description:   Show bridge state as "enabled" or "disabled"
-- 
2.9.1

Re: [PATCH v2 1/3] fpga: Add flag to indicate bitstream needs decrypting

[Alan Tull]

On Tue, Feb 21, 2017 at 7:55 AM, Michal Simek <michal.si...@xilinx.com> wrote:
> On 20.2.2017 21:55, m...@kernel.org wrote:
>> From: Moritz Fischer <m...@kernel.org>
>>
>> Add a flag that is passed to the write_init() callback, indicating
>> that the bitstream is encrypted.
>>
>> The low-level driver will deal with the flag, or return an error,
>> if encrypted bitstreams are not supported.
>>
>> Signed-off-by: Moritz Fischer <m...@kernel.org>
>> Cc: Alan Tull <at...@kernel.org>
>> Cc: Michal Simek <michal.si...@xilinx.com>
>> Cc: Sören Brinkmann <soren.brinkm...@xilinx.com>
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux-f...@vger.kernel.org
>> ---
>>
>> Changes from v1:
>> - Renamed flag from FPGA_MGR_DECRYPT_BITSTREAM->FPGA_MGR_ENCRYPTED_BITSTREAM
>>
>> ---
>>  include/linux/fpga/fpga-mgr.h | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/include/linux/fpga/fpga-mgr.h b/include/linux/fpga/fpga-mgr.h
>> index 57beb5d..e2ef94f 100644
>> --- a/include/linux/fpga/fpga-mgr.h
>> +++ b/include/linux/fpga/fpga-mgr.h
>> @@ -70,6 +70,7 @@ enum fpga_mgr_states {
>>   */
>>  #define FPGA_MGR_PARTIAL_RECONFIGBIT(0)
>>  #define FPGA_MGR_EXTERNAL_CONFIG BIT(1)
>> +#define FPGA_MGR_ENCRYPTED_BITSTREAM BIT(2)
>>
>>  /**
>>   * struct fpga_image_info - information specific to a FPGA image
>>
>
> Acked-by: Michal Simek <michal.si...@xilinx.com>

Acked-by: Alan Tull <at...@kernel.org>

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

Re: [RFC 7/8] fpga-region: add sysfs interface

[Alan Tull]

On Tue, Feb 21, 2017 at 11:38 PM, Moritz Fischer
 wrote:

Hi Moritz,

> Hi all,
>
> On Tue, Feb 21, 2017 at 9:12 PM, Jason Gunthorpe
>  wrote:
>> On Tue, Feb 21, 2017 at 07:49:19PM -0800, Moritz Fischer wrote:
>>
>>> fdt does this out of the box, too. So far I've seen nothing fdt
>>> couldn't do (or doesn't do let's rather say).
>>
>> tlv/fdt/http headers are all essentially exactly the same
>> thing. Key/value pairs with various encoding schemes.
>>
>> I don't think we don't need a tree of data, so fdt is overkill.
>>
>> tlv is not substantially easier to parse correctly than the
>> structured plain text headers.. It is just in binary so it can
>> represent binary-ish things better.
>
> TLV Seems easy enough. To give an update, I played with fdt a bit to see
> how far I get in half an hour. I got bool / int / strings to work
> quite fast (~30mins).

Thanks for doing this fast piece of exploratory coding.  It does
confirm that for Linux, using fdt is pretty straightforward here.
However...

> Please disregard the horrible hackyness of this ...
>
> For simplicity I stuck the header on top of my bitfile with:
>
> 
> /dts-v1/;
>
> /{
> description = "Test";
> compressed = <0>;
> encrypted = <1>;
> };

I understand that this is a simplified example, but it looks a lot
like KVP which then gets compiled by dtc.

If we do KVP or TLV we get skip using dtc, which would be nice for non-dt
OS's using the same images.

Also, the license of libfdt allows the use by proprietary
os's, but that's not true for dtc.

Alan

> 
>
> $ dtc -o header.dtb header.dts
>
> $ cat header.dtb mybitfile.bin > /lib/firmware/bitfile_header.bin
>
> + static int __fpga_mgr_blob_to_image_info(const void *blob,
> +  struct fpga_image_info *info)
> + {
> + int root_offset;
> + const char *desc;
> + const uint32_t *_compressed, *_encrypted;
> + int compressed, encrypted;
> +
> + if (fdt_check_header(blob)) {
> + pr_err("Invalid device tree blob header\n");
> + return -EINVAL;
> + }
> +
> + root_offset = fdt_path_offset(blob, "/");
> + if (root_offset < 0) {
> + pr_err("Invalid root offset\n");
> + return -EINVAL;
> + }
> +
> + desc = fdt_getprop(blob, root_offset, "description", NULL);
> +
> + _compressed = fdt_getprop(blob, root_offset, "compressed", NULL);
> + if (_compressed)
> + compressed = fdt32_to_cpu(*_compressed);
> +
> + _encrypted = fdt_getprop(blob, root_offset, "encrypted", NULL);
> + if (_encrypted)
> + encrypted = fdt32_to_cpu(*_encrypted);
> +
> + if (desc)
> + pr_info("%s: description=%s\n", __func__, desc);
> +
> + if (_encrypted && _compressed)
> + pr_info("%s: compressed? %s encrypted? %s\n", __func__,
> + compressed ? "Yes" : "No", encrypted ? "Yes" : 
> "No");
> +
> + return 0;
> + }
>
> Which gave me:
>
> 
>
> [   19.325182] fpga_manager fpga0: writing bitfile_header.bin to
> Xilinx Zynq FPGA Manager
> [   20.091222] __fpga_mgr_blob_to_image_info: description=Test
> [   20.096730] __fpga_mgr_blob_to_image_info: compressed? No encrypted? Yes
>
> 
>
> So I'm fairly convinced I can make this work, TVLs seem like it could work, 
> too.
>
>> So far the only thing we know we need is a 'bool' for encrypted and a
>> stringish guid thing for partial reconfiguration.
>
> Yeah, shouldn't be hard to implement either way.
>
> Cheers,
>
> Moritz

Re: [RFC 7/8] fpga-region: add sysfs interface

[Alan Tull]

On Sat, Feb 18, 2017 at 2:45 PM, Moritz Fischer
<moritz.fisc...@ettus.com> wrote:
> On Sat, Feb 18, 2017 at 02:10:43PM -0600, Alan Tull wrote:
>> On Sat, Feb 18, 2017 at 6:45 AM, Nadathur, Sundar
>> <sundar.nadat...@intel.com> wrote:
>>
>> > Hi all,
>> >Interesting discussion. The discussion so far has brought out many 
>> > concerns such as OS independence. There is an existing format, well-known 
>> > to developers, with widespread support, and which is quite extensible: 
>> > Type-Length-Value triples.
>> >
>> > To elaborate, a TLV-based format has many advantages:
>> > * It is highly extensible in many ways
>> >-- You can express structures and arrays using TLVs. Our needs right 
>> > now may seem limited but requirements grow over time.

Device tree can express arrays.

>> >-- The space of Type values can be decomposed into standard pre-defined 
>> > values that are in upstreamed code, and possibly experimental or 
>> > feature-specific values.
>> >-- Forward compatibility: We can write parsers that can skip unexpected 
>> > type values, thus allowing old parsers to work with new additions. With 
>> > some tweaks, old parsers can also reject unexpected values in some ranges 
>> > while accepting them in other ranges.
>> > * It is OS-independent.
>> > * It can be easily parsed, in kernel or user space.
>
> Are there other users of the format? I have to admit I didn't look very
> long, but couldn't find any libs / existing code at a first glance.

Is there a standard you are looking at?  Have you seen any use of TLV's
in the Linux kernel you could point to?

>
>> > * It can be validated, in terms of Type values, acceptable lengths, etc.
>> >
>> > It  is not directly human-readable but that can be easily addressed with a 
>> > tool that parses TLVs.
>> >
>> > Compared to some other proposals:
>> > * Compared to DTs, TLVs are OS-independent.
>
> That's just alternative facts here. Just because Linux uses fdt for
> devicetree blobs it is *not* OS dependent. There are several (see
> last email) non-Linux users of fdt / libfdt.
>
> Thanks,
>
> Moritz

It is worth repeating that libdtc is GPL/BSD with the intent of
allowing proprietary code to use libdtc.  So license shouldn't be a barrier.

Using device tree in the header would give us a way of doing enumeration at
least for Linux, not sure if that kind of info can be used in Windows
in some way.

Alan

Re: [RFC 4/8] doc: fpga-mgr: separate getting/locking FPGA manager

[Alan Tull]

On Fri, Feb 17, 2017 at 11:14 AM, Li, Yi <yi1...@linux.intel.com> wrote:
> hi Alan
>
>
> On 2/15/2017 10:14 AM, Alan Tull wrote:
>>
>> Document that getting a reference to a FPGA Manager has been
>> separated from locking the FPGA Mangager for use.
>>
>> fpga_mgr_lock/unlock functions get/release mutex.
>>
>> of_fpga_mgr_get, fpga_mgr_get, and fpga_mgr_put no longer lock
>> the FPGA manager mutex.
>>
>> This makes it more straigtforward to save a reference to
>> a FPGA manager and only attempting to lock it when programming
>> the FPGA.
>
>
> New to the FPGA world, but I like the idea of shorter lock. Separating the
> lock from fpga_mgr_get will give underline FPGA device drivers more
> flexibility to acquire the mgr pointer.
> One newbie question, since the underline FPGA device driver does the
> fpga_mgr_register during probe, each manager instance belongs to that FPGA
> device only. What's the use to keep tracking the usage reference with
> fpga_mgr_put/get function, or is it enough to increase/decrease dev
> reference count in fpga_mgr_register/unregister function?

Hi Yi,

That's a good though but the code that creates the fpga mgr device might not be
the code that needs to hold a reference to it.  The device tree
implementation is an
example of this.  The fpga mgr devices are created completely
separately from the
fpga regions.

Alan

>
> Thanks,
> Yi
>
>>
>> Signed-off-by: Alan Tull <at...@kernel.org>
>> ---
>>   Documentation/fpga/fpga-mgr.txt | 19 ++-
>>   1 file changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/fpga/fpga-mgr.txt
>> b/Documentation/fpga/fpga-mgr.txt
>> index 78f197f..06d5d5b 100644
>> --- a/Documentation/fpga/fpga-mgr.txt
>> +++ b/Documentation/fpga/fpga-mgr.txt
>> @@ -53,13 +53,26 @@ To get/put a reference to a FPGA manager:
>> struct fpga_manager *of_fpga_mgr_get(struct device_node *node);
>> struct fpga_manager *fpga_mgr_get(struct device *dev);
>>   -Given a DT node or device, get an exclusive reference to a FPGA
>> manager.
>> +Given a DT node or device, get an reference to a FPGA manager.  Pointer
>> +can be saved until you are ready to program the FPGA.
>> void fpga_mgr_put(struct fpga_manager *mgr);
>> Release the reference.
>> +To get exclusive control of a FPGA manager:
>> +---
>> +
>> +   int fpga_mgr_lock(struct fpga_magager *mgr);
>> +
>> +Call fpga_mgr_lock and verify that it returns 0 before attempting to
>> +program the FPGA.
>> +
>> +   void fpga_mgr_unlock(struct fpga_magager *mgr);
>> +
>> +Call fpga_mgr_unlock when done programming the FPGA.
>> +
>>   To register or unregister the low level FPGA-specific driver:
>>   -
>>   @@ -95,11 +108,13 @@ int ret;
>> /* Get exclusive control of FPGA manager */
>>   struct fpga_manager *mgr = of_fpga_mgr_get(mgr_node);
>> +ret = fpga_mgr_lock(mgr);
>> /* Load the buffer to the FPGA */
>>   ret = fpga_mgr_buf_load(mgr, , buf, count);
>> /* Release the FPGA manager */
>> +fpga_mgr_unlock(mgr);
>>   fpga_mgr_put(mgr);
>> @@ -124,11 +139,13 @@ int ret;
>> /* Get exclusive control of FPGA manager */
>>   struct fpga_manager *mgr = of_fpga_mgr_get(mgr_node);
>> +ret = fpga_mgr_lock(mgr);
>> /* Get the firmware image (path) and load it to the FPGA */
>>   ret = fpga_mgr_firmware_load(mgr, , path);
>> /* Release the FPGA manager */
>> +fpga_mgr_unlock(mgr);
>>   fpga_mgr_put(mgr);
>>
>
>

Re: [RFC 4/8] doc: fpga-mgr: separate getting/locking FPGA manager

[Alan Tull]

On Fri, Feb 17, 2017 at 11:52 AM, Moritz Fischer <m...@kernel.org> wrote:
> Alan,
>
> small nits inline

Hi Moritz,

Thanks for the review!

Alan

>
> On Wed, Feb 15, 2017 at 8:14 AM, Alan Tull <at...@kernel.org> wrote:
>> Document that getting a reference to a FPGA Manager has been
>> separated from locking the FPGA Mangager for use.
>>
>> fpga_mgr_lock/unlock functions get/release mutex.
>>
>> of_fpga_mgr_get, fpga_mgr_get, and fpga_mgr_put no longer lock
>> the FPGA manager mutex.
>>
>> This makes it more straigtforward to save a reference to
>> a FPGA manager and only attempting to lock it when programming
>> the FPGA.
>>
>> Signed-off-by: Alan Tull <at...@kernel.org>
> Acked-by: Moritz Fischer <m...@kernel.org>
>
>> ---
>>  Documentation/fpga/fpga-mgr.txt | 19 ++-
>>  1 file changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/fpga/fpga-mgr.txt 
>> b/Documentation/fpga/fpga-mgr.txt
>> index 78f197f..06d5d5b 100644
>> --- a/Documentation/fpga/fpga-mgr.txt
>> +++ b/Documentation/fpga/fpga-mgr.txt
>> @@ -53,13 +53,26 @@ To get/put a reference to a FPGA manager:
>> struct fpga_manager *of_fpga_mgr_get(struct device_node *node);
>> struct fpga_manager *fpga_mgr_get(struct device *dev);
>>
>> -Given a DT node or device, get an exclusive reference to a FPGA manager.
>> +Given a DT node or device, get an reference to a FPGA manager.  Pointer
>
> Nits: get *a* reference, 'A' pointer or 'The' pointer.
>
>> +can be saved until you are ready to program the FPGA.
>>
>> void fpga_mgr_put(struct fpga_manager *mgr);
>>
>>  Release the reference.
>>
>>
>> +To get exclusive control of a FPGA manager:
>> +---
>> +
>> +   int fpga_mgr_lock(struct fpga_magager *mgr);
>> +
>> +Call fpga_mgr_lock and verify that it returns 0 before attempting to
>> +program the FPGA.
>> +
>> +   void fpga_mgr_unlock(struct fpga_magager *mgr);
>> +
>> +Call fpga_mgr_unlock when done programming the FPGA.
>> +
>>  To register or unregister the low level FPGA-specific driver:
>>  -
>>
>> @@ -95,11 +108,13 @@ int ret;
>>
>>  /* Get exclusive control of FPGA manager */
>>  struct fpga_manager *mgr = of_fpga_mgr_get(mgr_node);
>> +ret = fpga_mgr_lock(mgr);
>>
>>  /* Load the buffer to the FPGA */
>>  ret = fpga_mgr_buf_load(mgr, , buf, count);
>>
>>  /* Release the FPGA manager */
>> +fpga_mgr_unlock(mgr);
>>  fpga_mgr_put(mgr);
>>
>>
>> @@ -124,11 +139,13 @@ int ret;
>>
>>  /* Get exclusive control of FPGA manager */
>>  struct fpga_manager *mgr = of_fpga_mgr_get(mgr_node);
>> +ret = fpga_mgr_lock(mgr);
>>
>>  /* Get the firmware image (path) and load it to the FPGA */
>>  ret = fpga_mgr_firmware_load(mgr, , path);
>>
>>  /* Release the FPGA manager */
>> +fpga_mgr_unlock(mgr);
>>  fpga_mgr_put(mgr);
>>
>>
>> --
>> 2.7.4
>>
>
> Cheers,
>
> Moritz

Re: [RFC 7/8] fpga-region: add sysfs interface

[Alan Tull]

On Sun, Feb 19, 2017 at 9:00 AM, Alan Tull <delicious.qui...@gmail.com> wrote:
> On Sat, Feb 18, 2017 at 2:45 PM, Moritz Fischer
> <moritz.fisc...@ettus.com> wrote:
>> On Sat, Feb 18, 2017 at 02:10:43PM -0600, Alan Tull wrote:
>>> On Sat, Feb 18, 2017 at 6:45 AM, Nadathur, Sundar
>>> <sundar.nadat...@intel.com> wrote:
>>>
>>> > Hi all,
>>> >Interesting discussion. The discussion so far has brought out many 
>>> > concerns such as OS independence. There is an existing format, well-known 
>>> > to developers, with widespread support, and which is quite extensible: 
>>> > Type-Length-Value triples.
>>> >
>>> > To elaborate, a TLV-based format has many advantages:
>>> > * It is highly extensible in many ways
>>> >-- You can express structures and arrays using TLVs. Our needs right 
>>> > now may seem limited but requirements grow over time.
>
> Device tree can express arrays.
>
>>> >-- The space of Type values can be decomposed into standard 
>>> > pre-defined values that are in upstreamed code, and possibly experimental 
>>> > or feature-specific values.
>>> >-- Forward compatibility: We can write parsers that can skip 
>>> > unexpected type values, thus allowing old parsers to work with new 
>>> > additions. With some tweaks, old parsers can also reject unexpected 
>>> > values in some ranges while accepting them in other ranges.
>>> > * It is OS-independent.
>>> > * It can be easily parsed, in kernel or user space.
>>
>> Are there other users of the format? I have to admit I didn't look very
>> long, but couldn't find any libs / existing code at a first glance.
>
> Is there a standard you are looking at?  Have you seen any use of TLV's
> in the Linux kernel you could point to?
>
>>
>>> > * It can be validated, in terms of Type values, acceptable lengths, etc.
>>> >
>>> > It  is not directly human-readable but that can be easily addressed with 
>>> > a tool that parses TLVs.
>>> >
>>> > Compared to some other proposals:
>>> > * Compared to DTs, TLVs are OS-independent.
>>
>> That's just alternative facts here. Just because Linux uses fdt for
>> devicetree blobs it is *not* OS dependent. There are several (see
>> last email) non-Linux users of fdt / libfdt.
>>
>> Thanks,
>>
>> Moritz
>
> It is worth repeating that libdtc is GPL/BSD with the intent of
> allowing proprietary code to use libdtc.  So license shouldn't be a barrier.
>
> Using device tree in the header would give us a way of doing enumeration at
> least for Linux, not sure if that kind of info can be used in Windows
> in some way.

Actually, enumeration is the only advantage I see with DT.

Currently I like key/value pairs because they are easily implemented
and expandable without being rigid in any way.

If we use key/value pairs, we could pass in child device info
in one of the keys.  It could be either a device tree overlay or an
ACPI overlay.  Or could just be left out.  So platforms that
aren't already using DT wouldn't have to.  Platforms that
are have a smooth road to enumeration.

Alan

>
> Alan

Re: [RFC 7/8] fpga-region: add sysfs interface

[Alan Tull]

On Sat, Feb 18, 2017 at 6:45 AM, Nadathur, Sundar
 wrote:

> Hi all,
>Interesting discussion. The discussion so far has brought out many 
> concerns such as OS independence. There is an existing format, well-known to 
> developers, with widespread support, and which is quite extensible: 
> Type-Length-Value triples.
>
> To elaborate, a TLV-based format has many advantages:
> * It is highly extensible in many ways
>-- You can express structures and arrays using TLVs. Our needs right now 
> may seem limited but requirements grow over time.
>-- The space of Type values can be decomposed into standard pre-defined 
> values that are in upstreamed code, and possibly experimental or 
> feature-specific values.
>-- Forward compatibility: We can write parsers that can skip unexpected 
> type values, thus allowing old parsers to work with new additions. With some 
> tweaks, old parsers can also reject unexpected values in some ranges while 
> accepting them in other ranges.
> * It is OS-independent.
> * It can be easily parsed, in kernel or user space.
> * It can be validated, in terms of Type values, acceptable lengths, etc.
>
> It  is not directly human-readable but that can be easily addressed with a 
> tool that parses TLVs.
>
> Compared to some other proposals:
> * Compared to DTs, TLVs are OS-independent.
> * Compared to strings as key-value pairs, TLVs can express structures/arrays, 
> can be validated, etc.
>
> So, I suggest we use TLVs to express metadata in image files.
>
> Thank you very much,
> Sundar Nadathur

Hi Sundar,

IIUC, each field is position dependent.  One of the strengths of key
value pairs is
that any key can be added in any order and ones that aren't applicable for
a particular architecture or use case can be left out.  If the header
is position
dependent, it becomes less flexible.  Once a field is added, we are
stuck with it
forever unless we drop it in some incremented version of the header format.

Alan

Re: [PATCH v2 1/3] fpga: Add flag to indicate bitstream needs decrypting

[Alan Tull]

On Tue, Feb 21, 2017 at 10:35 AM, Alan Tull <delicious.qui...@gmail.com>

Hi Greg,

Would it be helpful for us to resend patches for you to take with you
on cc?  Or is it enough that they are on lkml?

Thanks,
Alan Tull

wrote:
> On Tue, Feb 21, 2017 at 7:55 AM, Michal Simek <michal.si...@xilinx.com> wrote:
>> On 20.2.2017 21:55, m...@kernel.org wrote:
>>> From: Moritz Fischer <m...@kernel.org>
>>>
>>> Add a flag that is passed to the write_init() callback, indicating
>>> that the bitstream is encrypted.
>>>
>>> The low-level driver will deal with the flag, or return an error,
>>> if encrypted bitstreams are not supported.
>>>
>>> Signed-off-by: Moritz Fischer <m...@kernel.org>
>>> Cc: Alan Tull <at...@kernel.org>
>>> Cc: Michal Simek <michal.si...@xilinx.com>
>>> Cc: Sören Brinkmann <soren.brinkm...@xilinx.com>
>>> Cc: linux-kernel@vger.kernel.org
>>> Cc: linux-f...@vger.kernel.org
>>> ---
>>>
>>> Changes from v1:
>>> - Renamed flag from FPGA_MGR_DECRYPT_BITSTREAM->FPGA_MGR_ENCRYPTED_BITSTREAM
>>>
>>> ---
>>>  include/linux/fpga/fpga-mgr.h | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/include/linux/fpga/fpga-mgr.h b/include/linux/fpga/fpga-mgr.h
>>> index 57beb5d..e2ef94f 100644
>>> --- a/include/linux/fpga/fpga-mgr.h
>>> +++ b/include/linux/fpga/fpga-mgr.h
>>> @@ -70,6 +70,7 @@ enum fpga_mgr_states {
>>>   */
>>>  #define FPGA_MGR_PARTIAL_RECONFIGBIT(0)
>>>  #define FPGA_MGR_EXTERNAL_CONFIG BIT(1)
>>> +#define FPGA_MGR_ENCRYPTED_BITSTREAM BIT(2)
>>>
>>>  /**
>>>   * struct fpga_image_info - information specific to a FPGA image
>>>
>>
>> Acked-by: Michal Simek <michal.si...@xilinx.com>
>
> Acked-by: Alan Tull <at...@kernel.org>
>
>>
>> Thanks,
>> Michal
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 7/8] fpga-region: add sysfs interface

[Alan Tull]

On Mon, Feb 20, 2017 at 5:49 PM, Moritz Fischer
<moritz.fisc...@ettus.com> wrote:
> Hi Alan,
>
> On Sun, Feb 19, 2017 at 3:16 PM, Alan Tull <delicious.qui...@gmail.com> wrote:
>> On Sun, Feb 19, 2017 at 9:00 AM, Alan Tull <delicious.qui...@gmail.com> 
>> wrote:
>>> On Sat, Feb 18, 2017 at 2:45 PM, Moritz Fischer
>>> <moritz.fisc...@ettus.com> wrote:
>>>> On Sat, Feb 18, 2017 at 02:10:43PM -0600, Alan Tull wrote:
>>>>> On Sat, Feb 18, 2017 at 6:45 AM, Nadathur, Sundar
>>>>> <sundar.nadat...@intel.com> wrote:
>>>>>
>>>>> > Hi all,
>>>>> >Interesting discussion. The discussion so far has brought out many 
>>>>> > concerns such as OS independence. There is an existing format, 
>>>>> > well-known to developers, with widespread support, and which is quite 
>>>>> > extensible: Type-Length-Value triples.
>>>>> >
>>>>> > To elaborate, a TLV-based format has many advantages:
>>>>> > * It is highly extensible in many ways
>>>>> >-- You can express structures and arrays using TLVs. Our needs right 
>>>>> > now may seem limited but requirements grow over time.
>>>
>>> Device tree can express arrays.
>>>
>>>>> >-- The space of Type values can be decomposed into standard 
>>>>> > pre-defined values that are in upstreamed code, and possibly 
>>>>> > experimental or feature-specific values.
>>>>> >-- Forward compatibility: We can write parsers that can skip 
>>>>> > unexpected type values, thus allowing old parsers to work with new 
>>>>> > additions. With some tweaks, old parsers can also reject unexpected 
>>>>> > values in some ranges while accepting them in other ranges.
>>>>> > * It is OS-independent.
>>>>> > * It can be easily parsed, in kernel or user space.
>>>>
>>>> Are there other users of the format? I have to admit I didn't look very
>>>> long, but couldn't find any libs / existing code at a first glance.
>>>
>>> Is there a standard you are looking at?  Have you seen any use of TLV's
>>> in the Linux kernel you could point to?
>>>
>>>>
>>>>> > * It can be validated, in terms of Type values, acceptable lengths, etc.
>>>>> >
>>>>> > It  is not directly human-readable but that can be easily addressed 
>>>>> > with a tool that parses TLVs.
>>>>> >
>>>>> > Compared to some other proposals:
>>>>> > * Compared to DTs, TLVs are OS-independent.
>>>>
>>>> That's just alternative facts here. Just because Linux uses fdt for
>>>> devicetree blobs it is *not* OS dependent. There are several (see
>>>> last email) non-Linux users of fdt / libfdt.
>>>>
>>>> Thanks,
>>>>
>>>> Moritz
>>>
>>> It is worth repeating that libdtc is GPL/BSD with the intent of
>>> allowing proprietary code to use libdtc.  So license shouldn't be a barrier.
>>>
>>> Using device tree in the header would give us a way of doing enumeration at
>>> least for Linux, not sure if that kind of info can be used in Windows
>>> in some way.
>>
>> Actually, enumeration is the only advantage I see with DT.
>
> Which seems to some point a separate issue to passing in image
> specific info such as
> encrypted or not, compressed or not or build info metadata.
>
> So I think in general we can still separate this out into:
> - Image specific values
> - Reconfiguration specific values
>
>> Currently I like key/value pairs because they are easily implemented
>> and expandable without being rigid in any way.
>>
>> If we use key/value pairs, we could pass in child device info
>> in one of the keys.  It could be either a device tree overlay or an
>> ACPI overlay.  Or could just be left out.  So platforms that
>> aren't already using DT wouldn't have to.  Platforms that
>> are have a smooth road to enumeration.
>
> I'm not sure if you can bundle up enumeration info *with* the image
> since you might e.g.
> load the same image (i.e. same header) into different FPGAs and the
> required update to
> the kernel state, i.e. live tree or ACPI would depend entirely on
> which FPGA you loaded
> the image into w.r.t busses it's connected to etc.
>
> I do think this info cannot be image specific, but needs to be passed
> in via something
> external such as a dt overlay.

Yes, I think you are right about that.

Thanks!
Alan

>
> Cheers,
>
> Moritz

Re: [PATCH v2 1/3] fpga: Add flag to indicate bitstream needs decrypting

[Alan Tull]

On Tue, Feb 21, 2017 at 12:36 PM, Michal Simek <michal.si...@xilinx.com> wrote:
> On 21.2.2017 19:26, Alan Tull wrote:
>> On Tue, Feb 21, 2017 at 10:35 AM, Alan Tull <delicious.qui...@gmail.com>
>>
>> Hi Greg,
>>
>> Would it be helpful for us to resend patches for you to take with you
>> on cc?  Or is it enough that they are on lkml?
>
> Can I know the reason for this? I know that there were some discussion
> in past. But just add them to your linux-fpga.git repo and send pull
> request to Greg and proper time when he expects that.
>

Greg said it was easier for him to take them from email.

Alan

> Thanks,
> Michal
>

Re: [PATCH v2 3/3] fpga: region: Add fpga-region property 'encrypted-fpga-config'

[Alan Tull]

On Tue, Feb 21, 2017 at 7:55 AM, Michal Simek <michal.si...@xilinx.com> wrote:
> On 20.2.2017 21:55, m...@kernel.org wrote:
>> From: Moritz Fischer <m...@kernel.org>
>>
>> Add fpga-region property to allow passing the fact that the bitstream is
>> encrypted to the fpga-region and ultimately to the low-level driver.
>>
>> Signed-off-by: Moritz Fischer <m...@kernel.org>
>> Cc: Alan Tull <at...@kernel.org>
>> Cc: Michal Simek <michal.si...@xilinx.com>
>> Cc: Sören Brinkmann <soren.brinkm...@xilinx.com>
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux-f...@vger.kernel.org
>> ---
>>  Documentation/devicetree/bindings/fpga/fpga-region.txt | 1 +
>>  drivers/fpga/fpga-region.c | 8 ++--
>>  2 files changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt 
>> b/Documentation/devicetree/bindings/fpga/fpga-region.txt
>> index 3b32ba1..81bf3ad 100644
>> --- a/Documentation/devicetree/bindings/fpga/fpga-region.txt
>> +++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt
>> @@ -186,6 +186,7 @@ Optional properties:
>>   otherwise full reconfiguration is done.
>>  - external-fpga-config : boolean, set if the FPGA has already been 
>> configured
>>   prior to OS boot up.
>> +- encrypted-fpga-config : boolean, set if the bitstream is encrypted
>>  - region-unfreeze-timeout-us : The maximum time in microseconds to wait for
>>   bridges to successfully become enabled after the region has been
>>   programmed.
>> diff --git a/drivers/fpga/fpga-region.c b/drivers/fpga/fpga-region.c
>> index 3222fdb..2fe2a52 100644
>> --- a/drivers/fpga/fpga-region.c
>> +++ b/drivers/fpga/fpga-region.c
>> @@ -337,8 +337,9 @@ static int child_regions_with_firmware(struct 
>> device_node *overlay)
>>   * The overlay must add either firmware-name or external-fpga-config 
>> property
>>   * to the FPGA Region.
>>   *
>> - *   firmware-name: program the FPGA
>> - *   external-fpga-config : FPGA is already programmed
>> + *   firmware-name : program the FPGA
>> + *   external-fpga-config  : FPGA is already programmed
>> + *   encrypted-fpga-config : FPGA bitstream is encrypted
>>   *
>>   * The overlay can add other FPGA regions, but child FPGA regions cannot 
>> have a
>>   * firmware-name property since those regions don't exist yet.
>> @@ -373,6 +374,9 @@ static int fpga_region_notify_pre_apply(struct 
>> fpga_region *region,
>>   if (of_property_read_bool(nd->overlay, "external-fpga-config"))
>>   info->flags |= FPGA_MGR_EXTERNAL_CONFIG;
>>
>> + if (of_property_read_bool(nd->overlay, "encrypted-fpga-config"))
>> + info->flags |= FPGA_MGR_ENCRYPTED_BITSTREAM;
>> +
>>   of_property_read_string(nd->overlay, "firmware-name", _name);
>>
>>   of_property_read_u32(nd->overlay, "region-unfreeze-timeout-us",
>>
>
> Acked-by: Michal Simek <michal.si...@xilinx.com>

Acked-by: Alan Tull <at...@kernel.org>

>
> Thanks,
> Michal
>

Re: [PATCH v2 2/3] fpga: zynq: Add support for encrypted bitstreams

[Alan Tull]

On Tue, Feb 21, 2017 at 7:55 AM, Michal Simek <michal.si...@xilinx.com> wrote:
> On 20.2.2017 21:55, m...@kernel.org wrote:
>> From: Moritz Fischer <m...@kernel.org>
>>
>> Add support for encrypted bitstreams. For this to work the system
>> must be booted in secure mode.
>>
>> In order for on-the-fly decryption to work, the PCAP clock rate
>> needs to be lowered via the PCAP_RATE_EN bit.
>>
>> Signed-off-by: Moritz Fischer <m...@kernel.org>
>> Cc: Alan Tull <at...@kernel.org>
>> Cc: Michal Simek <michal.si...@xilinx.com>
>> Cc: Sören Brinkmann <soren.brinkm...@xilinx.com>
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux-f...@vger.kernel.org
>> ---
>>
>> Changes from v1:
>> - Renamed flag from FPGA_MGR_DECRYPT_BITSTREAM->FPGA_MGR_ENCRYPTED_BITSTREAM
>>
>> ---
>>  drivers/fpga/zynq-fpga.c | 28 +---
>>  1 file changed, 25 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/fpga/zynq-fpga.c b/drivers/fpga/zynq-fpga.c
>> index 34cb981..70b15b3 100644
>> --- a/drivers/fpga/zynq-fpga.c
>> +++ b/drivers/fpga/zynq-fpga.c
>> @@ -72,6 +72,10 @@
>>  #define CTRL_PCAP_PR_MASKBIT(27)
>>  /* Enable PCAP */
>>  #define CTRL_PCAP_MODE_MASK  BIT(26)
>> +/* Lower rate to allow decrypt on the fly */
>> +#define CTRL_PCAP_RATE_EN_MASK   BIT(25)
>> +/* System booted in secure mode */
>> +#define CTRL_SEC_EN_MASK BIT(7)
>>
>>  /* Miscellaneous Control Register bit definitions */
>>  /* Internal PCAP loopback */
>> @@ -266,6 +270,17 @@ static int zynq_fpga_ops_write_init(struct fpga_manager 
>> *mgr,
>>   if (err)
>>   return err;
>>
>> + /* check if bitstream is encrypted & and system's still secure */
>> + if (info->flags & FPGA_MGR_ENCRYPTED_BITSTREAM) {
>> + ctrl = zynq_fpga_read(priv, CTRL_OFFSET);
>> + if (!(ctrl & CTRL_SEC_EN_MASK)) {
>> + dev_err(>dev,
>> + "System not secure, can't use crypted 
>> bitstreams\n");
>> + err = -EINVAL;
>> + goto out_err;
>> + }
>> + }
>> +
>>   /* don't globally reset PL if we're doing partial reconfig */
>>   if (!(info->flags & FPGA_MGR_PARTIAL_RECONFIG)) {
>>   if (!zynq_fpga_has_sync(buf, count)) {
>> @@ -337,12 +352,19 @@ static int zynq_fpga_ops_write_init(struct 
>> fpga_manager *mgr,
>>
>>   /* set configuration register with following options:
>>* - enable PCAP interface
>> -  * - set throughput for maximum speed
>> +  * - set throughput for maximum speed (if bistream not crypted)
>>* - set CPU in user mode
>>*/
>>   ctrl = zynq_fpga_read(priv, CTRL_OFFSET);
>> - zynq_fpga_write(priv, CTRL_OFFSET,
>> - (CTRL_PCAP_PR_MASK | CTRL_PCAP_MODE_MASK | ctrl));
>> + if (info->flags & FPGA_MGR_ENCRYPTED_BITSTREAM)
>> + zynq_fpga_write(priv, CTRL_OFFSET,
>> +     (CTRL_PCAP_PR_MASK | CTRL_PCAP_MODE_MASK
>> +  | CTRL_PCAP_RATE_EN_MASK | ctrl));
>> + else
>> + zynq_fpga_write(priv, CTRL_OFFSET,
>> + (CTRL_PCAP_PR_MASK | CTRL_PCAP_MODE_MASK
>> +  | ctrl));
>> +
>>
>>   /* We expect that the command queue is empty right now. */
>>   status = zynq_fpga_read(priv, STATUS_OFFSET);
>>
>
> Acked-by: Michal Simek <michal.si...@xilinx.com>

Acked-by: Alan Tull <at...@kernel.org>

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

Re: [RFC 7/8] fpga-region: add sysfs interface

[Alan Tull]

On Wed, Feb 22, 2017 at 10:44 AM, Moritz Fischer
<moritz.fisc...@ettus.com> wrote:
> On Wed, Feb 22, 2017 at 8:33 AM, Alan Tull <delicious.qui...@gmail.com> wrote:
>> On Tue, Feb 21, 2017 at 11:38 PM, Moritz Fischer
>> <moritz.fisc...@ettus.com> wrote:
>>
>> Hi Moritz,
>>
>>> Hi all,
>>>
>>> On Tue, Feb 21, 2017 at 9:12 PM, Jason Gunthorpe
>>> <jguntho...@obsidianresearch.com> wrote:
>>>> On Tue, Feb 21, 2017 at 07:49:19PM -0800, Moritz Fischer wrote:
>>>>
>>>>> fdt does this out of the box, too. So far I've seen nothing fdt
>>>>> couldn't do (or doesn't do let's rather say).
>>>>
>>>> tlv/fdt/http headers are all essentially exactly the same
>>>> thing. Key/value pairs with various encoding schemes.
>>>>
>>>> I don't think we don't need a tree of data, so fdt is overkill.
>>>>
>>>> tlv is not substantially easier to parse correctly than the
>>>> structured plain text headers.. It is just in binary so it can
>>>> represent binary-ish things better.
>>>
>>> TLV Seems easy enough. To give an update, I played with fdt a bit to see
>>> how far I get in half an hour. I got bool / int / strings to work
>>> quite fast (~30mins).
>>
>> Thanks for doing this fast piece of exploratory coding.  It does
>> confirm that for Linux, using fdt is pretty straightforward here.
>> However...
>>
>>> Please disregard the horrible hackyness of this ...
>>>
>>> For simplicity I stuck the header on top of my bitfile with:
>>>
>>> 
>>> /dts-v1/;
>>>
>>> /{
>>> description = "Test";
>>> compressed = <0>;
>>> encrypted = <1>;
>>> };
>>
>> I understand that this is a simplified example, but it looks a lot
>> like KVP which then gets compiled by dtc.
>>
>> If we do KVP or TLV we get skip using dtc, which would be nice for non-dt
>> OS's using the same images.
>
> I used dtc for pure lazyness. Writing a blob to a file using libfdt is
> about as much
> code as parsing it.

Thanks for that clarification.  I haven't used libfdt myself.  That
takes care of the license issue I brought up below.

I have heard that MS is averse to using DT, but I'm not clear
about why other than that it isn't native to Windows already.

Alan

> Even with KVP or TLV you have some code that needs
> to encode / pack your header into a file.
>
> libfdt has an example that creates an empty tree. Write that to a file, done.
>
> 1: Create empty tree
> https://github.com/dgibson/dtc/blob/master/libfdt/fdt_empty_tree.c
>
> 2: fopen / fwrite, done
>
>> Also, the license of libfdt allows the use by proprietary
>> os's, but that's not true for dtc.
>
> Why would that be an issue, you don't need to link anything to run
> dtc. That being
> said as I pointed out above you don not have to actually use dtc if the values
> are known ahead of time (like in our case). What you'd get from using dtc is 
> to
> encode arbitrary values (for the types supported).
>
> Cheers,
>
> Moritz