Re: [PATCH v2 07/22] fpga: intel: pcie: parse feature list and create platform device for features.

[Moritz Fischer]

Hi Xiao / Wu,

general question, can't you make the /* */ comments
for the structs kernel-doc ([1]) markup instead (see below)?


On Mon, Jun 26, 2017 at 09:52:03AM +0800, Wu Hao wrote:
> From: Xiao Guangrong <guangrong.x...@linux.intel.com>
> 
> Device Feature List structure creates a link list of feature headers
> within the MMIO space to provide an extensible way of adding features.
> 
> The Intel FPGA PCIe driver walks through the feature headers to enumerate
> feature devices, FPGA Management Engine (FME) and FPGA Port for Accelerated
> Function Unit (AFU), and their private sub features. For feature devices,
> it creates the platform devices and linked the private sub features into
> their platform data.
> 
> Signed-off-by: Tim Whisonant <tim.whison...@intel.com>
> Signed-off-by: Enno Luebbers <enno.luebb...@intel.com>
> Signed-off-by: Shiva Rao <shiva@intel.com>
> Signed-off-by: Christopher Rauer <christopher.ra...@intel.com>
> Signed-off-by: Kang Luwei <luwei.k...@intel.com>
> Signed-off-by: Zhang Yi <yi.z.zh...@intel.com>
> Signed-off-by: Xiao Guangrong <guangrong.x...@linux.intel.com>
> Signed-off-by: Wu Hao <hao...@intel.com>
> ---
> v2: moved the code to drivers/fpga folder as suggested by Alan Tull.
> switched to GPLv2 license.
> fixed comments from Moritz Fischer.
> fixed kbuild warning, typos and clean up the code.
> ---
>  drivers/fpga/Makefile|   2 +-
>  drivers/fpga/intel-feature-dev.c | 130 ++
>  drivers/fpga/intel-feature-dev.h | 341 
>  drivers/fpga/intel-pcie.c| 841 
> ++-
>  4 files changed, 1311 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/fpga/intel-feature-dev.c
>  create mode 100644 drivers/fpga/intel-feature-dev.h
> 
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index 5613133..ad24b3d 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -31,4 +31,4 @@ obj-$(CONFIG_OF_FPGA_REGION)+= 
> of-fpga-region.o
>  # Intel FPGA Support
>  obj-$(CONFIG_INTEL_FPGA_PCI) += intel-fpga-pci.o
>  
> -intel-fpga-pci-objs := intel-pcie.o
> +intel-fpga-pci-objs := intel-pcie.o intel-feature-dev.o
> diff --git a/drivers/fpga/intel-feature-dev.c 
> b/drivers/fpga/intel-feature-dev.c
> new file mode 100644
> index 000..68f9cba
> --- /dev/null
> +++ b/drivers/fpga/intel-feature-dev.c
> @@ -0,0 +1,130 @@
> +/*
> + * Intel FPGA Feature Device Driver
> + *
> + * Copyright (C) 2017 Intel Corporation, Inc.
> + *
> + * Authors:
> + *   Kang Luwei <luwei.k...@intel.com>
> + *   Zhang Yi <yi.z.zh...@intel.com>
> + *   Wu Hao <hao...@intel.com>
> + *   Xiao Guangrong <guangrong.x...@linux.intel.com>
> + *
> + * This work is licensed under the terms of the GNU GPL version 2. See
> + * the COPYING file in the top-level directory.
> + */
> +
> +#include "intel-feature-dev.h"
> +
> +void feature_platform_data_add(struct feature_platform_data *pdata,
> +int index, const char *name,
> +int resource_index, void __iomem *ioaddr)
> +{
> + WARN_ON(index >= pdata->num);
> +
> + pdata->features[index].name = name;
> + pdata->features[index].resource_index = resource_index;
> + pdata->features[index].ioaddr = ioaddr;
> +}
> +
> +struct feature_platform_data *
> +feature_platform_data_alloc_and_init(struct platform_device *dev, int num)
> +{
> + struct feature_platform_data *pdata;
> +
> + pdata = kzalloc(feature_platform_data_size(num), GFP_KERNEL);
> + if (pdata) {
> + pdata->dev = dev;
> + pdata->num = num;
> + mutex_init(>lock);
> + }
> +
> + return pdata;
> +}
> +
> +int fme_feature_num(void)
> +{
> + return FME_FEATURE_ID_MAX;
> +}
> +
> +int port_feature_num(void)
> +{
> + return PORT_FEATURE_ID_MAX;
> +}
> +
> +int fpga_port_id(struct platform_device *pdev)
> +{
> + struct feature_port_header *port_hdr;
> + struct feature_port_capability capability;
> +
> + port_hdr = get_feature_ioaddr_by_index(>dev,
> +PORT_FEATURE_ID_HEADER);
> + WARN_ON(!port_hdr);
> +
> + capability.csr = readq(_hdr->capability);
> + return capability.port_number;
> +}
> +EXPORT_SYMBOL_GPL(fpga_port_id);
> +
> +/*
> + * Enable Port by clear the port soft reset bit, which is set by default.
> + * The User AFU is unable to respond to any MMIO access while in reset.
> + * _

Re: [PATCH v2 07/22] fpga: intel: pcie: parse feature list and create platform device for features.

[Moritz Fischer]

Hi Xiao / Wu,

general question, can't you make the /* */ comments
for the structs kernel-doc ([1]) markup instead (see below)?


On Mon, Jun 26, 2017 at 09:52:03AM +0800, Wu Hao wrote:
> From: Xiao Guangrong 
> 
> Device Feature List structure creates a link list of feature headers
> within the MMIO space to provide an extensible way of adding features.
> 
> The Intel FPGA PCIe driver walks through the feature headers to enumerate
> feature devices, FPGA Management Engine (FME) and FPGA Port for Accelerated
> Function Unit (AFU), and their private sub features. For feature devices,
> it creates the platform devices and linked the private sub features into
> their platform data.
> 
> Signed-off-by: Tim Whisonant 
> Signed-off-by: Enno Luebbers 
> Signed-off-by: Shiva Rao 
> Signed-off-by: Christopher Rauer 
> Signed-off-by: Kang Luwei 
> Signed-off-by: Zhang Yi 
> Signed-off-by: Xiao Guangrong 
> Signed-off-by: Wu Hao 
> ---
> v2: moved the code to drivers/fpga folder as suggested by Alan Tull.
> switched to GPLv2 license.
> fixed comments from Moritz Fischer.
> fixed kbuild warning, typos and clean up the code.
> ---
>  drivers/fpga/Makefile|   2 +-
>  drivers/fpga/intel-feature-dev.c | 130 ++
>  drivers/fpga/intel-feature-dev.h | 341 
>  drivers/fpga/intel-pcie.c| 841 
> ++-
>  4 files changed, 1311 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/fpga/intel-feature-dev.c
>  create mode 100644 drivers/fpga/intel-feature-dev.h
> 
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index 5613133..ad24b3d 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -31,4 +31,4 @@ obj-$(CONFIG_OF_FPGA_REGION)+= 
> of-fpga-region.o
>  # Intel FPGA Support
>  obj-$(CONFIG_INTEL_FPGA_PCI) += intel-fpga-pci.o
>  
> -intel-fpga-pci-objs := intel-pcie.o
> +intel-fpga-pci-objs := intel-pcie.o intel-feature-dev.o
> diff --git a/drivers/fpga/intel-feature-dev.c 
> b/drivers/fpga/intel-feature-dev.c
> new file mode 100644
> index 000..68f9cba
> --- /dev/null
> +++ b/drivers/fpga/intel-feature-dev.c
> @@ -0,0 +1,130 @@
> +/*
> + * Intel FPGA Feature Device Driver
> + *
> + * Copyright (C) 2017 Intel Corporation, Inc.
> + *
> + * Authors:
> + *   Kang Luwei 
> + *   Zhang Yi 
> + *   Wu Hao 
> + *   Xiao Guangrong 
> + *
> + * This work is licensed under the terms of the GNU GPL version 2. See
> + * the COPYING file in the top-level directory.
> + */
> +
> +#include "intel-feature-dev.h"
> +
> +void feature_platform_data_add(struct feature_platform_data *pdata,
> +int index, const char *name,
> +int resource_index, void __iomem *ioaddr)
> +{
> + WARN_ON(index >= pdata->num);
> +
> + pdata->features[index].name = name;
> + pdata->features[index].resource_index = resource_index;
> + pdata->features[index].ioaddr = ioaddr;
> +}
> +
> +struct feature_platform_data *
> +feature_platform_data_alloc_and_init(struct platform_device *dev, int num)
> +{
> + struct feature_platform_data *pdata;
> +
> + pdata = kzalloc(feature_platform_data_size(num), GFP_KERNEL);
> + if (pdata) {
> + pdata->dev = dev;
> + pdata->num = num;
> + mutex_init(>lock);
> + }
> +
> + return pdata;
> +}
> +
> +int fme_feature_num(void)
> +{
> + return FME_FEATURE_ID_MAX;
> +}
> +
> +int port_feature_num(void)
> +{
> + return PORT_FEATURE_ID_MAX;
> +}
> +
> +int fpga_port_id(struct platform_device *pdev)
> +{
> + struct feature_port_header *port_hdr;
> + struct feature_port_capability capability;
> +
> + port_hdr = get_feature_ioaddr_by_index(>dev,
> +PORT_FEATURE_ID_HEADER);
> + WARN_ON(!port_hdr);
> +
> + capability.csr = readq(_hdr->capability);
> + return capability.port_number;
> +}
> +EXPORT_SYMBOL_GPL(fpga_port_id);
> +
> +/*
> + * Enable Port by clear the port soft reset bit, which is set by default.
> + * The User AFU is unable to respond to any MMIO access while in reset.
> + * __fpga_port_enable function should only be used after __fpga_port_disable
> + * function.
> + */
> +void __fpga_port_enable(struct platform_device *pdev)
> +{
> + struct feature_platform_data *pdata = dev_get_platdata(>dev);
> + struct feature_port_header *port_hdr;
> + struct feature_port_control control;
> +
> + WARN_ON(!pdata->disable_count);
> +
> + if (--pdata-&

Re: [PATCH v3 2/2] fpga: lattice machxo2: Add Lattice MachXO2 support

[Moritz Fischer]

On Thu, Jun 15, 2017 at 4:13 AM, Paolo Pisati  wrote:
> This patch adds support to the FPGA manager for programming
> MachXO2 device’s internal flash memory, via slave SPI.
>
> Signed-off-by: Paolo Pisati 
> ---
>  drivers/fpga/Kconfig   |   7 ++
>  drivers/fpga/Makefile  |   1 +
>  drivers/fpga/machxo2-spi.c | 277 
> +
>  3 files changed, 285 insertions(+)
>  create mode 100644 drivers/fpga/machxo2-spi.c
>
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index c81cb7d..cce135b 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -26,6 +26,13 @@ config FPGA_MGR_ICE40_SPI
> help
>   FPGA manager driver support for Lattice iCE40 FPGAs over SPI.
>
> +config FPGA_MGR_MACHXO2_SPI
> +   tristate "Lattice MachXO2 SPI"
> +   depends on SPI
> +   help
> +FPGA manager driver support for Lattice MachXO2 configuration
> +over slave SPI interface.
> +
>  config FPGA_MGR_SOCFPGA
> tristate "Altera SOCFPGA FPGA Manager"
> depends on ARCH_SOCFPGA || COMPILE_TEST
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index c6f5d74..cdab1fe 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_ICE40_SPI)   += ice40-spi.o
> +obj-$(CONFIG_FPGA_MGR_MACHXO2_SPI) += machxo2-spi.o
>  obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
>  obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10) += socfpga-a10.o
>  obj-$(CONFIG_FPGA_MGR_TS73XX)  += ts73xx-fpga.o
> diff --git a/drivers/fpga/machxo2-spi.c b/drivers/fpga/machxo2-spi.c
> new file mode 100644
> index 000..ea8793c
> --- /dev/null
> +++ b/drivers/fpga/machxo2-spi.c
> @@ -0,0 +1,277 @@
> +/**
> + * Lattice MachXO2 Slave SPI Driver
> + *
> + * Copyright (C) 2017 Paolo Pisati 
> + *
> + * 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.
> + *
> + * Manage Lattice FPGA firmware that is loaded over SPI using
> + * the slave serial configuration interface.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* MachXO2 Programming Guide - sysCONFIG Programming Commands */
> +
> +#define ISC_DISABLE0x0026
> +#define ISC_ENABLE 0x08c6
> +#define ISC_ERASE  0x040e
> +#define ISC_NOOP   0x
> +#define ISC_PROGRAMDONE0x005e
> +#define LSC_CHECKBUSY  0x00f0
> +#define LSC_INITADDRESS0x0046
> +#define LSC_PROGINCRNV 0x0170
> +#define LSC_REFRESH0x0079
> +
> +#define BUSYFLAG   BIT(7)
> +
> +/*
> + * Max CCLK in Slave SPI mode according to 'MachXO2 Family Data
> + * Sheet' sysCONFIG Port Timing Specifications (3-36)
> + */
> +#define MACHXO2_MAX_SPEED  6600
> +
> +#define MACHXO2_LOW_DELAY  5   /* us */
> +#define MACHXO2_HIGH_DELAY 200 /* us */
> +#define MACHXO2_REFRESH4800/* us */
> +
> +#define MACHXO2_OP_SIZEsizeof(u32)
> +#define MACHXO2_PAGE_SIZE  16
> +#define MACHXO2_BUF_SIZE   (MACHXO2_OP_SIZE + MACHXO2_PAGE_SIZE)
> +
> +static int wait_until_not_busy(struct spi_device *spi)
> +{
> +   struct spi_message msg;
> +   struct spi_transfer rx, tx;
> +   u32 checkbusy = LSC_CHECKBUSY;
> +   u8 busy;
> +   int ret;
> +
> +   do {
> +   memset(, 0, sizeof(rx));
> +   memset(, 0, sizeof(tx));
> +   tx.tx_buf = 
> +   tx.len = MACHXO2_OP_SIZE;
> +   rx.rx_buf = 
> +   rx.len = sizeof(busy);
> +   spi_message_init();
> +   spi_message_add_tail(, );
> +   spi_message_add_tail(, );
> +   ret = spi_sync(spi, );
> +   if (ret)
> +   return ret;
> +   } while (busy & BUSYFLAG);
> +
> +   return 0;
> +}
> +
> +static enum fpga_mgr_states machxo2_spi_state(struct fpga_manager *mgr)
> +{
> +   return FPGA_MGR_STATE_UNKNOWN;
> +}
> +
> +static int machxo2_write_init(struct fpga_manager *mgr,
> + struct fpga_image_info *info,
> + const char *buf, size_t count)
> +{
> +   struct spi_device *spi = mgr->priv;
> +   struct spi_message msg;
> +   struct spi_transfer tx[5];
> +   u32 disable = ISC_DISABLE;
> +   u32 bypass = ISC_NOOP;
> +   u32 enable = ISC_ENABLE;
> +   u32 erase = ISC_ERASE;
> +   u32 initaddr = LSC_INITADDRESS;
> +   int ret;
> +
> +   if ((info->flags & FPGA_MGR_PARTIAL_RECONFIG)) {
> +   dev_err(>dev,
> +   

Re: [PATCH v3 2/2] fpga: lattice machxo2: Add Lattice MachXO2 support

[Moritz Fischer]

On Thu, Jun 15, 2017 at 4:13 AM, Paolo Pisati  wrote:
> This patch adds support to the FPGA manager for programming
> MachXO2 device’s internal flash memory, via slave SPI.
>
> Signed-off-by: Paolo Pisati 
> ---
>  drivers/fpga/Kconfig   |   7 ++
>  drivers/fpga/Makefile  |   1 +
>  drivers/fpga/machxo2-spi.c | 277 
> +
>  3 files changed, 285 insertions(+)
>  create mode 100644 drivers/fpga/machxo2-spi.c
>
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index c81cb7d..cce135b 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -26,6 +26,13 @@ config FPGA_MGR_ICE40_SPI
> help
>   FPGA manager driver support for Lattice iCE40 FPGAs over SPI.
>
> +config FPGA_MGR_MACHXO2_SPI
> +   tristate "Lattice MachXO2 SPI"
> +   depends on SPI
> +   help
> +FPGA manager driver support for Lattice MachXO2 configuration
> +over slave SPI interface.
> +
>  config FPGA_MGR_SOCFPGA
> tristate "Altera SOCFPGA FPGA Manager"
> depends on ARCH_SOCFPGA || COMPILE_TEST
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index c6f5d74..cdab1fe 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_ICE40_SPI)   += ice40-spi.o
> +obj-$(CONFIG_FPGA_MGR_MACHXO2_SPI) += machxo2-spi.o
>  obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
>  obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10) += socfpga-a10.o
>  obj-$(CONFIG_FPGA_MGR_TS73XX)  += ts73xx-fpga.o
> diff --git a/drivers/fpga/machxo2-spi.c b/drivers/fpga/machxo2-spi.c
> new file mode 100644
> index 000..ea8793c
> --- /dev/null
> +++ b/drivers/fpga/machxo2-spi.c
> @@ -0,0 +1,277 @@
> +/**
> + * Lattice MachXO2 Slave SPI Driver
> + *
> + * Copyright (C) 2017 Paolo Pisati 
> + *
> + * 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.
> + *
> + * Manage Lattice FPGA firmware that is loaded over SPI using
> + * the slave serial configuration interface.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* MachXO2 Programming Guide - sysCONFIG Programming Commands */
> +
> +#define ISC_DISABLE0x0026
> +#define ISC_ENABLE 0x08c6
> +#define ISC_ERASE  0x040e
> +#define ISC_NOOP   0x
> +#define ISC_PROGRAMDONE0x005e
> +#define LSC_CHECKBUSY  0x00f0
> +#define LSC_INITADDRESS0x0046
> +#define LSC_PROGINCRNV 0x0170
> +#define LSC_REFRESH0x0079
> +
> +#define BUSYFLAG   BIT(7)
> +
> +/*
> + * Max CCLK in Slave SPI mode according to 'MachXO2 Family Data
> + * Sheet' sysCONFIG Port Timing Specifications (3-36)
> + */
> +#define MACHXO2_MAX_SPEED  6600
> +
> +#define MACHXO2_LOW_DELAY  5   /* us */
> +#define MACHXO2_HIGH_DELAY 200 /* us */
> +#define MACHXO2_REFRESH4800/* us */
> +
> +#define MACHXO2_OP_SIZEsizeof(u32)
> +#define MACHXO2_PAGE_SIZE  16
> +#define MACHXO2_BUF_SIZE   (MACHXO2_OP_SIZE + MACHXO2_PAGE_SIZE)
> +
> +static int wait_until_not_busy(struct spi_device *spi)
> +{
> +   struct spi_message msg;
> +   struct spi_transfer rx, tx;
> +   u32 checkbusy = LSC_CHECKBUSY;
> +   u8 busy;
> +   int ret;
> +
> +   do {
> +   memset(, 0, sizeof(rx));
> +   memset(, 0, sizeof(tx));
> +   tx.tx_buf = 
> +   tx.len = MACHXO2_OP_SIZE;
> +   rx.rx_buf = 
> +   rx.len = sizeof(busy);
> +   spi_message_init();
> +   spi_message_add_tail(, );
> +   spi_message_add_tail(, );
> +   ret = spi_sync(spi, );
> +   if (ret)
> +   return ret;
> +   } while (busy & BUSYFLAG);
> +
> +   return 0;
> +}
> +
> +static enum fpga_mgr_states machxo2_spi_state(struct fpga_manager *mgr)
> +{
> +   return FPGA_MGR_STATE_UNKNOWN;
> +}
> +
> +static int machxo2_write_init(struct fpga_manager *mgr,
> + struct fpga_image_info *info,
> + const char *buf, size_t count)
> +{
> +   struct spi_device *spi = mgr->priv;
> +   struct spi_message msg;
> +   struct spi_transfer tx[5];
> +   u32 disable = ISC_DISABLE;
> +   u32 bypass = ISC_NOOP;
> +   u32 enable = ISC_ENABLE;
> +   u32 erase = ISC_ERASE;
> +   u32 initaddr = LSC_INITADDRESS;
> +   int ret;
> +
> +   if ((info->flags & FPGA_MGR_PARTIAL_RECONFIG)) {
> +   dev_err(>dev,
> +   "Partial reconfiguration is not supported\n");
> +   

Re: [PATCH] Make FPGA a menuconfig to ease disabling it all

[Moritz Fischer]

On Wed, May 24, 2017 at 8:35 AM, Alan Tull <at...@kernel.org> wrote:
> On Fri, Apr 14, 2017 at 5:39 PM, Vincent Legoll
> <vincent.leg...@gmail.com> wrote:
>
> Hi Vincent,
>
> Thanks!
>
> Alan
>
>> No need to get into the submenu to disable all FPGA-related config entries
>>
>> Signed-off-by: Vincent Legoll <vincent.leg...@gmail.com>
Acked-by: Moritz Fischer <m...@kernel.org>
>
> Signed-off-by: Alan Tull <at...@kernel.org>
>
>> ---
>>  drivers/fpga/Kconfig | 6 +-
>>  1 file changed, 1 insertion(+), 5 deletions(-)
>>
>> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
>> index ce861a2..2cb9b81 100644
>> --- a/drivers/fpga/Kconfig
>> +++ b/drivers/fpga/Kconfig
>> @@ -2,9 +2,7 @@
>>  # FPGA framework configuration
>>  #
>>
>> -menu "FPGA Configuration Support"
>> -
>> -config FPGA
>> +menuconfig FPGA
>> tristate "FPGA Configuration Framework"
>> help
>>   Say Y here if you want support for configuring FPGAs from the
>> @@ -64,5 +62,3 @@ config ALTERA_FREEZE_BRIDGE
>>   region is being reprogrammed.
>>
>>  endif # FPGA
>> -
>> -endmenu
>> --
>> 2.9.3
>>

Re: [PATCH] Make FPGA a menuconfig to ease disabling it all

[Moritz Fischer]

On Wed, May 24, 2017 at 8:35 AM, Alan Tull  wrote:
> On Fri, Apr 14, 2017 at 5:39 PM, Vincent Legoll
>  wrote:
>
> Hi Vincent,
>
> Thanks!
>
> Alan
>
>> No need to get into the submenu to disable all FPGA-related config entries
>>
>> Signed-off-by: Vincent Legoll 
Acked-by: Moritz Fischer 
>
> Signed-off-by: Alan Tull 
>
>> ---
>>  drivers/fpga/Kconfig | 6 +-
>>  1 file changed, 1 insertion(+), 5 deletions(-)
>>
>> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
>> index ce861a2..2cb9b81 100644
>> --- a/drivers/fpga/Kconfig
>> +++ b/drivers/fpga/Kconfig
>> @@ -2,9 +2,7 @@
>>  # FPGA framework configuration
>>  #
>>
>> -menu "FPGA Configuration Support"
>> -
>> -config FPGA
>> +menuconfig FPGA
>> tristate "FPGA Configuration Framework"
>> help
>>   Say Y here if you want support for configuring FPGAs from the
>> @@ -64,5 +62,3 @@ config ALTERA_FREEZE_BRIDGE
>>   region is being reprogrammed.
>>
>>  endif # FPGA
>> -
>> -endmenu
>> --
>> 2.9.3
>>

Re: [RFC/PATCH 1/2] dt-binding: mfd: Add Maxim/Dallas DS1374 MFD device binding

[Moritz Fischer]

On Fri, May 12, 2017 at 07:00:29PM -0500, Rob Herring wrote:
> On Tue, May 09, 2017 at 11:20:20AM -0700, Moritz Fischer wrote:
> > This adds a binding for the Maxim/Dallas DS1374 MFD.
> > 
> > Signed-off-by: Moritz Fischer <m...@kernel.org>
> > ---
> > 
> > Hi all,
> > 
> > I'm not entirely sure aobut the binding, does anyone
> > have a better suggestion for the remap-wdt-reset property?
> > 
> > Thanks,
> > 
> > Moritz
> > 
> > ---
> >  Documentation/devicetree/bindings/mfd/ds1374.txt   | 63 
> > ++
> >  .../devicetree/bindings/trivial-devices.txt|  1 -
> >  drivers/rtc/Kconfig|  2 +
> >  3 files changed, 65 insertions(+), 1 deletion(-)
> >  create mode 100644 Documentation/devicetree/bindings/mfd/ds1374.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/mfd/ds1374.txt 
> > b/Documentation/devicetree/bindings/mfd/ds1374.txt
> > new file mode 100644
> > index 000..b22396f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mfd/ds1374.txt
> > @@ -0,0 +1,63 @@
> > +* Device tree bindings for Maxim/Dallas DS1374 Multi Function Device (MFD)
> > +
> > +The Maxim/Dallas DS1374 is a multi function device that combines rtc,
> > +watchdog or alarm, as well as trickle charger.
> > +
> > +The DS1374 is connected via I2C.
> > +
> > +Required properties:
> > +- compatible: "dallas,ds1374"
> > +- reg: I2C slave address
> > +- dallas,ds1374-mode: Should be one of the following values:
> 
> Just "dallas,mode" is sufficient.

Will fix.
> 
> > +   <0> for RTC
> > +   <1> for RTC + Alarm (Interrupt)
> > +   <2> for RTC + Watchdog
> > +
> > +Required child:
> > +A single available child device of type matching the "dallas,ds1374-mode"
> > +property.
> > +
> > +Optional properties (watchdog):
> > +- dallas,ds1374-remap-wdt-reset: Boolean describing whether the INT pin
> > +on the device is used as interrupt for
> > +the alarm
> 
> Isn't presence of the interrupt property or not enough? It would be 
> kind of useless to have no interrupt and also not do anything on 
> timeout.

So you're saying:

If interrupt not present AND mode = <0> ignore interrupt

If interrupt present AND mode = <1> (maybe define here would be nicer),
make it an interrupt.

If interrupt not present AND mode = <2> then this implies that reset
output is mapped to RST pin.

If Interrupt present AND mode = <2> then this implies that the reset
output is (re)mapped to INT pin?

> 
> > +
> > +See ../watchdog/* for generic watchdog bindings.
> > +
> > +Optional properties (real time clock):
> > +- interrupt: phandle to interrupt cell for the rtc's alarm feature
> > +
> > +See ../rtc/* for generic rtc bindings.
> > +
> > +Optional properties (trickle-charger):
> > +- dallas,trickle-resistor-ohms : Selected resistor for trickle charger
> > +   Values usable for ds1374 are 250, 2000, 4000
> > +   Should be given if trickle charger should be enabled
> > +- dallas,trickle-diode-disable : Do not use internal trickle charger diode
> > +   Should be given if internal trickle charger diode should be disabled
> > +
> > +Example for rtc with alarm mode and interrupt:
> > +
> > +i2c@12ca {
> > +   rtc@68 {
> > +   compatible = "ds1374";
> > +   reg = <0x68>;
> > +   interrupts = < 62>;
> > +   dallas,ds1374-mode = <2>
> > +
> > +   dallas,trickle-resistor-ohms = <250>;
> > +   dallas,trickle-diode-disable;
> > +   };
> > +};
> > +
> > +Example for rtc with watchdog and reset on timeout, with reset remapped
> > +to the INT pin:
> > +
> > +i2c@12ca {
> > +   rtc@68 {
> > +   compatible = "ds1374";
> > +   reg = <0x68>;
> > +   dallas,ds1374-mode = <2>
> > +   dallas,ds1374-remap-wdt-reset;
> > +   };
> > +};
> > diff --git a/Documentation/devicetree/bindings/trivial-devices.txt 
> > b/Documentation/devicetree/bindings/trivial-devices.txt
> > index 3e0a34c..f7a50e5 100644
> > --- a/Documentation/devicetree/bindings/trivial-devices.txt
> > +++ b/Documentation/devicetree/bindings/trivial-devices.txt
> > @@ -29,7 +29,6 @@ cirrus,cs42l51Cirrus Logic CS42L51 audio c

Re: [RFC/PATCH 1/2] dt-binding: mfd: Add Maxim/Dallas DS1374 MFD device binding

[Moritz Fischer]

On Fri, May 12, 2017 at 07:00:29PM -0500, Rob Herring wrote:
> On Tue, May 09, 2017 at 11:20:20AM -0700, Moritz Fischer wrote:
> > This adds a binding for the Maxim/Dallas DS1374 MFD.
> > 
> > Signed-off-by: Moritz Fischer 
> > ---
> > 
> > Hi all,
> > 
> > I'm not entirely sure aobut the binding, does anyone
> > have a better suggestion for the remap-wdt-reset property?
> > 
> > Thanks,
> > 
> > Moritz
> > 
> > ---
> >  Documentation/devicetree/bindings/mfd/ds1374.txt   | 63 
> > ++
> >  .../devicetree/bindings/trivial-devices.txt|  1 -
> >  drivers/rtc/Kconfig|  2 +
> >  3 files changed, 65 insertions(+), 1 deletion(-)
> >  create mode 100644 Documentation/devicetree/bindings/mfd/ds1374.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/mfd/ds1374.txt 
> > b/Documentation/devicetree/bindings/mfd/ds1374.txt
> > new file mode 100644
> > index 000..b22396f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mfd/ds1374.txt
> > @@ -0,0 +1,63 @@
> > +* Device tree bindings for Maxim/Dallas DS1374 Multi Function Device (MFD)
> > +
> > +The Maxim/Dallas DS1374 is a multi function device that combines rtc,
> > +watchdog or alarm, as well as trickle charger.
> > +
> > +The DS1374 is connected via I2C.
> > +
> > +Required properties:
> > +- compatible: "dallas,ds1374"
> > +- reg: I2C slave address
> > +- dallas,ds1374-mode: Should be one of the following values:
> 
> Just "dallas,mode" is sufficient.

Will fix.
> 
> > +   <0> for RTC
> > +   <1> for RTC + Alarm (Interrupt)
> > +   <2> for RTC + Watchdog
> > +
> > +Required child:
> > +A single available child device of type matching the "dallas,ds1374-mode"
> > +property.
> > +
> > +Optional properties (watchdog):
> > +- dallas,ds1374-remap-wdt-reset: Boolean describing whether the INT pin
> > +on the device is used as interrupt for
> > +the alarm
> 
> Isn't presence of the interrupt property or not enough? It would be 
> kind of useless to have no interrupt and also not do anything on 
> timeout.

So you're saying:

If interrupt not present AND mode = <0> ignore interrupt

If interrupt present AND mode = <1> (maybe define here would be nicer),
make it an interrupt.

If interrupt not present AND mode = <2> then this implies that reset
output is mapped to RST pin.

If Interrupt present AND mode = <2> then this implies that the reset
output is (re)mapped to INT pin?

> 
> > +
> > +See ../watchdog/* for generic watchdog bindings.
> > +
> > +Optional properties (real time clock):
> > +- interrupt: phandle to interrupt cell for the rtc's alarm feature
> > +
> > +See ../rtc/* for generic rtc bindings.
> > +
> > +Optional properties (trickle-charger):
> > +- dallas,trickle-resistor-ohms : Selected resistor for trickle charger
> > +   Values usable for ds1374 are 250, 2000, 4000
> > +   Should be given if trickle charger should be enabled
> > +- dallas,trickle-diode-disable : Do not use internal trickle charger diode
> > +   Should be given if internal trickle charger diode should be disabled
> > +
> > +Example for rtc with alarm mode and interrupt:
> > +
> > +i2c@12ca {
> > +   rtc@68 {
> > +   compatible = "ds1374";
> > +   reg = <0x68>;
> > +   interrupts = < 62>;
> > +   dallas,ds1374-mode = <2>
> > +
> > +   dallas,trickle-resistor-ohms = <250>;
> > +   dallas,trickle-diode-disable;
> > +   };
> > +};
> > +
> > +Example for rtc with watchdog and reset on timeout, with reset remapped
> > +to the INT pin:
> > +
> > +i2c@12ca {
> > +   rtc@68 {
> > +   compatible = "ds1374";
> > +   reg = <0x68>;
> > +   dallas,ds1374-mode = <2>
> > +   dallas,ds1374-remap-wdt-reset;
> > +   };
> > +};
> > diff --git a/Documentation/devicetree/bindings/trivial-devices.txt 
> > b/Documentation/devicetree/bindings/trivial-devices.txt
> > index 3e0a34c..f7a50e5 100644
> > --- a/Documentation/devicetree/bindings/trivial-devices.txt
> > +++ b/Documentation/devicetree/bindings/trivial-devices.txt
> > @@ -29,7 +29,6 @@ cirrus,cs42l51Cirrus Logic CS42L51 audio codec
> >  dalla

Re: [RFC/PATCH 2/2] mfd: ds1374: Add Dallas/Maxim DS1374 Multi Function Device

[Moritz Fischer]

On Tue, May 09, 2017 at 11:20:21AM -0700, Moritz Fischer wrote:
> From: Moritz Fischer <moritz.fisc...@ettus.com>
> 
> Add support for the Maxim/Dallas DS1374 RTC/WDT with trickle charger.
> The device can either be configured as simple RTC, as simple RTC with
> Alarm (IRQ) as well as simple RTC with watchdog timer.
> 
> Break up the old monolithic driver in drivers/rtc/rtc-ds1374.c into:
> - rtc part in drivers/rtc/rtc-ds1374.c
> - watchdog part under drivers/watchdog/ds1374-wdt.c
> - mfd part drivers/mfd/ds1374.c
> 
> The MFD part takes care of trickle charging and mode selection,
> since the usage modes of a) RTC + Alarm or b) RTC + WDT
> are mutually exclusive.
> 
> Signed-off-by: Moritz Fischer <m...@kernel.org>
> ---
> 
> Hi all,
> 
> attached changeset is huge, I do realize that. I couldn't find a good
> way of splitting it and maintaining bisectability.
> 
> Not sure if the way the rtc/wdt drivers access the parent is recommended,
> or whether one should rather pass down just the 'mode' and regmap in platform
> data.
> 
> Thanks for your time reviewing,
> 
> Moritz
> 
> 
> ---
>  drivers/mfd/Kconfig   |  10 +
>  drivers/mfd/Makefile  |   1 +
>  drivers/mfd/ds1374.c  | 267 ++
>  drivers/rtc/rtc-ds1374.c  | 640 
> ++
>  drivers/watchdog/Kconfig  |  10 +
>  drivers/watchdog/Makefile |   1 +
>  drivers/watchdog/ds1374-wdt.c | 214 ++
>  include/linux/mfd/ds1374.h|  59 
>  8 files changed, 714 insertions(+), 488 deletions(-)
>  create mode 100644 drivers/mfd/ds1374.c
>  create mode 100644 drivers/watchdog/ds1374-wdt.c
>  create mode 100644 include/linux/mfd/ds1374.h
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 3eb5c93..2dfef3c 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -203,6 +203,16 @@ config MFD_CROS_EC_SPI
> response time cannot be guaranteed, we support ignoring
> 'pre-amble' bytes before the response actually starts.
>  
> +config MFD_DS1374
> + tristate "Dallas/Maxim DS1374 RTC/WDT/ALARM (I2C)"
> + select MFD_CORE
> + depends on I2C
> + depends on REGMAP_I2C
> +
> +  ---help---
> +   This driver supports the Dallas Maxim DS1374 multi function chip.
> +   The chip combines an RTC, trickle charger, Watchdog or Alarm.
> +
>  config MFD_ASIC3
>   bool "Compaq ASIC3"
>   depends on GPIOLIB && ARM
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index c16bf1e..b5cfcf4 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -15,6 +15,7 @@ cros_ec_core-$(CONFIG_ACPI) += cros_ec_acpi_gpe.o
>  obj-$(CONFIG_MFD_CROS_EC)+= cros_ec_core.o
>  obj-$(CONFIG_MFD_CROS_EC_I2C)+= cros_ec_i2c.o
>  obj-$(CONFIG_MFD_CROS_EC_SPI)+= cros_ec_spi.o
> +obj-$(CONFIG_MFD_DS1374) += ds1374.o
>  obj-$(CONFIG_MFD_EXYNOS_LPASS)   += exynos-lpass.o
>  
>  rtsx_pci-objs:= rtsx_pcr.o rts5209.o rts5229.o 
> rtl8411.o rts5227.o rts5249.o
> diff --git a/drivers/mfd/ds1374.c b/drivers/mfd/ds1374.c
> new file mode 100644
> index 000..be82b38
> --- /dev/null
> +++ b/drivers/mfd/ds1374.c
> @@ -0,0 +1,267 @@
> +/*
> + * Copyright (c) 2017, National Instruments Corp.
> + *
> + * Dallas/Maxim DS1374 Multi Function Device Driver
> + *
> + * The trickle charger code was taken more ore less 1:1 from
> + * drivers/rtc/rtc-1390.c
> + *
> + * 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
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * This program is distributed in the hope that 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DS1374_TRICKLE_CHARGER_ENABLE0xa0
> +#define DS1374_TRICKLE_CHARGER_ENABLE_MASK 0xe0
> +
> +#define DS1374_TRICKLE_CHARGER_250_OHM   0x01
> +#define DS1374_TRICKLE_CHARGER_2K_OHM0x02
> +#define DS1374_TRICKLE_CHARGER_4K_OHM0x03
> +#define DS1374_TRICKLE_CHARGER_ROUT_MASK 0x03
> +
> +#define DS1374_TRICKLE_CHARGER_NO_DIODE  0x04
> +#define DS1374_TRICKLE_CHARGER_DIODE 0x08
> +#define DS1374_TRICKLE_CHARGER_DIODE_MASK 0xc
> +
> +static const struct regmap_ran

Re: [RFC/PATCH 2/2] mfd: ds1374: Add Dallas/Maxim DS1374 Multi Function Device

[Moritz Fischer]

On Tue, May 09, 2017 at 11:20:21AM -0700, Moritz Fischer wrote:
> From: Moritz Fischer 
> 
> Add support for the Maxim/Dallas DS1374 RTC/WDT with trickle charger.
> The device can either be configured as simple RTC, as simple RTC with
> Alarm (IRQ) as well as simple RTC with watchdog timer.
> 
> Break up the old monolithic driver in drivers/rtc/rtc-ds1374.c into:
> - rtc part in drivers/rtc/rtc-ds1374.c
> - watchdog part under drivers/watchdog/ds1374-wdt.c
> - mfd part drivers/mfd/ds1374.c
> 
> The MFD part takes care of trickle charging and mode selection,
> since the usage modes of a) RTC + Alarm or b) RTC + WDT
> are mutually exclusive.
> 
> Signed-off-by: Moritz Fischer 
> ---
> 
> Hi all,
> 
> attached changeset is huge, I do realize that. I couldn't find a good
> way of splitting it and maintaining bisectability.
> 
> Not sure if the way the rtc/wdt drivers access the parent is recommended,
> or whether one should rather pass down just the 'mode' and regmap in platform
> data.
> 
> Thanks for your time reviewing,
> 
> Moritz
> 
> 
> ---
>  drivers/mfd/Kconfig   |  10 +
>  drivers/mfd/Makefile  |   1 +
>  drivers/mfd/ds1374.c  | 267 ++
>  drivers/rtc/rtc-ds1374.c  | 640 
> ++
>  drivers/watchdog/Kconfig  |  10 +
>  drivers/watchdog/Makefile |   1 +
>  drivers/watchdog/ds1374-wdt.c | 214 ++
>  include/linux/mfd/ds1374.h|  59 
>  8 files changed, 714 insertions(+), 488 deletions(-)
>  create mode 100644 drivers/mfd/ds1374.c
>  create mode 100644 drivers/watchdog/ds1374-wdt.c
>  create mode 100644 include/linux/mfd/ds1374.h
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 3eb5c93..2dfef3c 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -203,6 +203,16 @@ config MFD_CROS_EC_SPI
> response time cannot be guaranteed, we support ignoring
> 'pre-amble' bytes before the response actually starts.
>  
> +config MFD_DS1374
> + tristate "Dallas/Maxim DS1374 RTC/WDT/ALARM (I2C)"
> + select MFD_CORE
> + depends on I2C
> + depends on REGMAP_I2C
> +
> +  ---help---
> +   This driver supports the Dallas Maxim DS1374 multi function chip.
> +   The chip combines an RTC, trickle charger, Watchdog or Alarm.
> +
>  config MFD_ASIC3
>   bool "Compaq ASIC3"
>   depends on GPIOLIB && ARM
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index c16bf1e..b5cfcf4 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -15,6 +15,7 @@ cros_ec_core-$(CONFIG_ACPI) += cros_ec_acpi_gpe.o
>  obj-$(CONFIG_MFD_CROS_EC)+= cros_ec_core.o
>  obj-$(CONFIG_MFD_CROS_EC_I2C)+= cros_ec_i2c.o
>  obj-$(CONFIG_MFD_CROS_EC_SPI)+= cros_ec_spi.o
> +obj-$(CONFIG_MFD_DS1374) += ds1374.o
>  obj-$(CONFIG_MFD_EXYNOS_LPASS)   += exynos-lpass.o
>  
>  rtsx_pci-objs:= rtsx_pcr.o rts5209.o rts5229.o 
> rtl8411.o rts5227.o rts5249.o
> diff --git a/drivers/mfd/ds1374.c b/drivers/mfd/ds1374.c
> new file mode 100644
> index 000..be82b38
> --- /dev/null
> +++ b/drivers/mfd/ds1374.c
> @@ -0,0 +1,267 @@
> +/*
> + * Copyright (c) 2017, National Instruments Corp.
> + *
> + * Dallas/Maxim DS1374 Multi Function Device Driver
> + *
> + * The trickle charger code was taken more ore less 1:1 from
> + * drivers/rtc/rtc-1390.c
> + *
> + * 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
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * This program is distributed in the hope that 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DS1374_TRICKLE_CHARGER_ENABLE0xa0
> +#define DS1374_TRICKLE_CHARGER_ENABLE_MASK 0xe0
> +
> +#define DS1374_TRICKLE_CHARGER_250_OHM   0x01
> +#define DS1374_TRICKLE_CHARGER_2K_OHM0x02
> +#define DS1374_TRICKLE_CHARGER_4K_OHM0x03
> +#define DS1374_TRICKLE_CHARGER_ROUT_MASK 0x03
> +
> +#define DS1374_TRICKLE_CHARGER_NO_DIODE  0x04
> +#define DS1374_TRICKLE_CHARGER_DIODE 0x08
> +#define DS1374_TRICKLE_CHARGER_DIODE_MASK 0xc
> +
> +static const struct regmap_range volatile_ranges[] = {
> + regmap_reg_range

[RFC/PATCH 2/2] mfd: ds1374: Add Dallas/Maxim DS1374 Multi Function Device

[Moritz Fischer]

From: Moritz Fischer <moritz.fisc...@ettus.com>

Add support for the Maxim/Dallas DS1374 RTC/WDT with trickle charger.
The device can either be configured as simple RTC, as simple RTC with
Alarm (IRQ) as well as simple RTC with watchdog timer.

Break up the old monolithic driver in drivers/rtc/rtc-ds1374.c into:
- rtc part in drivers/rtc/rtc-ds1374.c
- watchdog part under drivers/watchdog/ds1374-wdt.c
- mfd part drivers/mfd/ds1374.c

The MFD part takes care of trickle charging and mode selection,
since the usage modes of a) RTC + Alarm or b) RTC + WDT
are mutually exclusive.

Signed-off-by: Moritz Fischer <m...@kernel.org>
---

Hi all,

attached changeset is huge, I do realize that. I couldn't find a good
way of splitting it and maintaining bisectability.

Not sure if the way the rtc/wdt drivers access the parent is recommended,
or whether one should rather pass down just the 'mode' and regmap in platform
data.

Thanks for your time reviewing,

Moritz


---
 drivers/mfd/Kconfig   |  10 +
 drivers/mfd/Makefile  |   1 +
 drivers/mfd/ds1374.c  | 267 ++
 drivers/rtc/rtc-ds1374.c  | 640 ++
 drivers/watchdog/Kconfig  |  10 +
 drivers/watchdog/Makefile |   1 +
 drivers/watchdog/ds1374-wdt.c | 214 ++
 include/linux/mfd/ds1374.h|  59 
 8 files changed, 714 insertions(+), 488 deletions(-)
 create mode 100644 drivers/mfd/ds1374.c
 create mode 100644 drivers/watchdog/ds1374-wdt.c
 create mode 100644 include/linux/mfd/ds1374.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 3eb5c93..2dfef3c 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -203,6 +203,16 @@ config MFD_CROS_EC_SPI
  response time cannot be guaranteed, we support ignoring
  'pre-amble' bytes before the response actually starts.
 
+config MFD_DS1374
+   tristate "Dallas/Maxim DS1374 RTC/WDT/ALARM (I2C)"
+   select MFD_CORE
+   depends on I2C
+   depends on REGMAP_I2C
+
+---help---
+ This driver supports the Dallas Maxim DS1374 multi function chip.
+ The chip combines an RTC, trickle charger, Watchdog or Alarm.
+
 config MFD_ASIC3
bool "Compaq ASIC3"
depends on GPIOLIB && ARM
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index c16bf1e..b5cfcf4 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -15,6 +15,7 @@ cros_ec_core-$(CONFIG_ACPI)   += cros_ec_acpi_gpe.o
 obj-$(CONFIG_MFD_CROS_EC)  += cros_ec_core.o
 obj-$(CONFIG_MFD_CROS_EC_I2C)  += cros_ec_i2c.o
 obj-$(CONFIG_MFD_CROS_EC_SPI)  += cros_ec_spi.o
+obj-$(CONFIG_MFD_DS1374)   += ds1374.o
 obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o
 
 rtsx_pci-objs  := rtsx_pcr.o rts5209.o rts5229.o rtl8411.o 
rts5227.o rts5249.o
diff --git a/drivers/mfd/ds1374.c b/drivers/mfd/ds1374.c
new file mode 100644
index 000..be82b38
--- /dev/null
+++ b/drivers/mfd/ds1374.c
@@ -0,0 +1,267 @@
+/*
+ * Copyright (c) 2017, National Instruments Corp.
+ *
+ * Dallas/Maxim DS1374 Multi Function Device Driver
+ *
+ * The trickle charger code was taken more ore less 1:1 from
+ * drivers/rtc/rtc-1390.c
+ *
+ * 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
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DS1374_TRICKLE_CHARGER_ENABLE  0xa0
+#define DS1374_TRICKLE_CHARGER_ENABLE_MASK 0xe0
+
+#define DS1374_TRICKLE_CHARGER_250_OHM 0x01
+#define DS1374_TRICKLE_CHARGER_2K_OHM  0x02
+#define DS1374_TRICKLE_CHARGER_4K_OHM  0x03
+#define DS1374_TRICKLE_CHARGER_ROUT_MASK 0x03
+
+#define DS1374_TRICKLE_CHARGER_NO_DIODE0x04
+#define DS1374_TRICKLE_CHARGER_DIODE   0x08
+#define DS1374_TRICKLE_CHARGER_DIODE_MASK 0xc
+
+static const struct regmap_range volatile_ranges[] = {
+   regmap_reg_range(DS1374_REG_TOD0, DS1374_REG_WDALM2),
+   regmap_reg_range(DS1374_REG_SR, DS1374_REG_SR),
+};
+
+static const struct regmap_access_table ds1374_volatile_table = {
+   .yes_ranges = volatile_ranges,
+   .n_yes_ranges = ARRAY_SIZE(volatile_ranges),
+};
+
+static struct regmap_config ds1374_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+   .max_register = DS1374_REG_TCR,
+   .volatile_table = _volatile_table,
+   .cache_type = REGCACHE_RBTREE,
+};
+
+static struct mfd_cell ds1374_wdt_cell = {
+   .name = "ds1374-wdt",
+};
+
+static struct mfd_cell ds1374_rtc_cell = {
+   .name = "ds1374-rtc&qu

[RFC/PATCH 2/2] mfd: ds1374: Add Dallas/Maxim DS1374 Multi Function Device

[Moritz Fischer]

From: Moritz Fischer 

Add support for the Maxim/Dallas DS1374 RTC/WDT with trickle charger.
The device can either be configured as simple RTC, as simple RTC with
Alarm (IRQ) as well as simple RTC with watchdog timer.

Break up the old monolithic driver in drivers/rtc/rtc-ds1374.c into:
- rtc part in drivers/rtc/rtc-ds1374.c
- watchdog part under drivers/watchdog/ds1374-wdt.c
- mfd part drivers/mfd/ds1374.c

The MFD part takes care of trickle charging and mode selection,
since the usage modes of a) RTC + Alarm or b) RTC + WDT
are mutually exclusive.

Signed-off-by: Moritz Fischer 
---

Hi all,

attached changeset is huge, I do realize that. I couldn't find a good
way of splitting it and maintaining bisectability.

Not sure if the way the rtc/wdt drivers access the parent is recommended,
or whether one should rather pass down just the 'mode' and regmap in platform
data.

Thanks for your time reviewing,

Moritz


---
 drivers/mfd/Kconfig   |  10 +
 drivers/mfd/Makefile  |   1 +
 drivers/mfd/ds1374.c  | 267 ++
 drivers/rtc/rtc-ds1374.c  | 640 ++
 drivers/watchdog/Kconfig  |  10 +
 drivers/watchdog/Makefile |   1 +
 drivers/watchdog/ds1374-wdt.c | 214 ++
 include/linux/mfd/ds1374.h|  59 
 8 files changed, 714 insertions(+), 488 deletions(-)
 create mode 100644 drivers/mfd/ds1374.c
 create mode 100644 drivers/watchdog/ds1374-wdt.c
 create mode 100644 include/linux/mfd/ds1374.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 3eb5c93..2dfef3c 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -203,6 +203,16 @@ config MFD_CROS_EC_SPI
  response time cannot be guaranteed, we support ignoring
  'pre-amble' bytes before the response actually starts.
 
+config MFD_DS1374
+   tristate "Dallas/Maxim DS1374 RTC/WDT/ALARM (I2C)"
+   select MFD_CORE
+   depends on I2C
+   depends on REGMAP_I2C
+
+---help---
+ This driver supports the Dallas Maxim DS1374 multi function chip.
+ The chip combines an RTC, trickle charger, Watchdog or Alarm.
+
 config MFD_ASIC3
bool "Compaq ASIC3"
depends on GPIOLIB && ARM
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index c16bf1e..b5cfcf4 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -15,6 +15,7 @@ cros_ec_core-$(CONFIG_ACPI)   += cros_ec_acpi_gpe.o
 obj-$(CONFIG_MFD_CROS_EC)  += cros_ec_core.o
 obj-$(CONFIG_MFD_CROS_EC_I2C)  += cros_ec_i2c.o
 obj-$(CONFIG_MFD_CROS_EC_SPI)  += cros_ec_spi.o
+obj-$(CONFIG_MFD_DS1374)   += ds1374.o
 obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o
 
 rtsx_pci-objs  := rtsx_pcr.o rts5209.o rts5229.o rtl8411.o 
rts5227.o rts5249.o
diff --git a/drivers/mfd/ds1374.c b/drivers/mfd/ds1374.c
new file mode 100644
index 000..be82b38
--- /dev/null
+++ b/drivers/mfd/ds1374.c
@@ -0,0 +1,267 @@
+/*
+ * Copyright (c) 2017, National Instruments Corp.
+ *
+ * Dallas/Maxim DS1374 Multi Function Device Driver
+ *
+ * The trickle charger code was taken more ore less 1:1 from
+ * drivers/rtc/rtc-1390.c
+ *
+ * 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
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DS1374_TRICKLE_CHARGER_ENABLE  0xa0
+#define DS1374_TRICKLE_CHARGER_ENABLE_MASK 0xe0
+
+#define DS1374_TRICKLE_CHARGER_250_OHM 0x01
+#define DS1374_TRICKLE_CHARGER_2K_OHM  0x02
+#define DS1374_TRICKLE_CHARGER_4K_OHM  0x03
+#define DS1374_TRICKLE_CHARGER_ROUT_MASK 0x03
+
+#define DS1374_TRICKLE_CHARGER_NO_DIODE0x04
+#define DS1374_TRICKLE_CHARGER_DIODE   0x08
+#define DS1374_TRICKLE_CHARGER_DIODE_MASK 0xc
+
+static const struct regmap_range volatile_ranges[] = {
+   regmap_reg_range(DS1374_REG_TOD0, DS1374_REG_WDALM2),
+   regmap_reg_range(DS1374_REG_SR, DS1374_REG_SR),
+};
+
+static const struct regmap_access_table ds1374_volatile_table = {
+   .yes_ranges = volatile_ranges,
+   .n_yes_ranges = ARRAY_SIZE(volatile_ranges),
+};
+
+static struct regmap_config ds1374_regmap_config = {
+   .reg_bits = 8,
+   .val_bits = 8,
+   .max_register = DS1374_REG_TCR,
+   .volatile_table = _volatile_table,
+   .cache_type = REGCACHE_RBTREE,
+};
+
+static struct mfd_cell ds1374_wdt_cell = {
+   .name = "ds1374-wdt",
+};
+
+static struct mfd_cell ds1374_rtc_cell = {
+   .name = "ds1374-rtc",
+};
+
+static int ds1374_add_device(struct ds1374 *chip,
+ 

[RFC/PATCH 1/2] dt-binding: mfd: Add Maxim/Dallas DS1374 MFD device binding

[Moritz Fischer]

This adds a binding for the Maxim/Dallas DS1374 MFD.

Signed-off-by: Moritz Fischer <m...@kernel.org>
---

Hi all,

I'm not entirely sure aobut the binding, does anyone
have a better suggestion for the remap-wdt-reset property?

Thanks,

Moritz

---
 Documentation/devicetree/bindings/mfd/ds1374.txt   | 63 ++
 .../devicetree/bindings/trivial-devices.txt|  1 -
 drivers/rtc/Kconfig|  2 +
 3 files changed, 65 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/ds1374.txt

diff --git a/Documentation/devicetree/bindings/mfd/ds1374.txt 
b/Documentation/devicetree/bindings/mfd/ds1374.txt
new file mode 100644
index 000..b22396f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ds1374.txt
@@ -0,0 +1,63 @@
+* Device tree bindings for Maxim/Dallas DS1374 Multi Function Device (MFD)
+
+The Maxim/Dallas DS1374 is a multi function device that combines rtc,
+watchdog or alarm, as well as trickle charger.
+
+The DS1374 is connected via I2C.
+
+Required properties:
+- compatible: "dallas,ds1374"
+- reg: I2C slave address
+- dallas,ds1374-mode: Should be one of the following values:
+   <0> for RTC
+   <1> for RTC + Alarm (Interrupt)
+   <2> for RTC + Watchdog
+
+Required child:
+A single available child device of type matching the "dallas,ds1374-mode"
+property.
+
+Optional properties (watchdog):
+- dallas,ds1374-remap-wdt-reset: Boolean describing whether the INT pin
+on the device is used as interrupt for
+the alarm
+
+See ../watchdog/* for generic watchdog bindings.
+
+Optional properties (real time clock):
+- interrupt: phandle to interrupt cell for the rtc's alarm feature
+
+See ../rtc/* for generic rtc bindings.
+
+Optional properties (trickle-charger):
+- dallas,trickle-resistor-ohms : Selected resistor for trickle charger
+   Values usable for ds1374 are 250, 2000, 4000
+   Should be given if trickle charger should be enabled
+- dallas,trickle-diode-disable : Do not use internal trickle charger diode
+   Should be given if internal trickle charger diode should be disabled
+
+Example for rtc with alarm mode and interrupt:
+
+i2c@12ca {
+   rtc@68 {
+   compatible = "ds1374";
+   reg = <0x68>;
+   interrupts = < 62>;
+   dallas,ds1374-mode = <2>
+
+   dallas,trickle-resistor-ohms = <250>;
+   dallas,trickle-diode-disable;
+   };
+};
+
+Example for rtc with watchdog and reset on timeout, with reset remapped
+to the INT pin:
+
+i2c@12ca {
+   rtc@68 {
+   compatible = "ds1374";
+   reg = <0x68>;
+   dallas,ds1374-mode = <2>
+   dallas,ds1374-remap-wdt-reset;
+   };
+};
diff --git a/Documentation/devicetree/bindings/trivial-devices.txt 
b/Documentation/devicetree/bindings/trivial-devices.txt
index 3e0a34c..f7a50e5 100644
--- a/Documentation/devicetree/bindings/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/trivial-devices.txt
@@ -29,7 +29,6 @@ cirrus,cs42l51Cirrus Logic CS42L51 audio codec
 dallas,ds1307  64 x 8, Serial, I2C Real-Time Clock
 dallas,ds1338  I2C RTC with 56-Byte NV RAM
 dallas,ds1340  I2C RTC with Trickle Charger
-dallas,ds1374  I2C, 32-Bit Binary Counter Watchdog RTC with Trickle 
Charger and Reset Input/Output
 dallas,ds1631  High-Precision Digital Thermometer
 dallas,ds1682  Total-Elapsed-Time Recorder with Alarm
 dallas,ds1775  Tiny Digital Thermometer and Thermostat
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 8d3b957..e6763fe 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -250,6 +250,8 @@ config RTC_DRV_DS1307_CENTURY
 
 config RTC_DRV_DS1374
tristate "Dallas/Maxim DS1374"
+   depends on MFD_DS1374
+   depends on REGMAP_I2C
help
  If you say yes here you get support for Dallas Semiconductor
  DS1374 real-time clock chips. If an interrupt is associated
-- 
2.7.4

[RFC/PATCH 1/2] dt-binding: mfd: Add Maxim/Dallas DS1374 MFD device binding

[Moritz Fischer]

This adds a binding for the Maxim/Dallas DS1374 MFD.

Signed-off-by: Moritz Fischer 
---

Hi all,

I'm not entirely sure aobut the binding, does anyone
have a better suggestion for the remap-wdt-reset property?

Thanks,

Moritz

---
 Documentation/devicetree/bindings/mfd/ds1374.txt   | 63 ++
 .../devicetree/bindings/trivial-devices.txt|  1 -
 drivers/rtc/Kconfig|  2 +
 3 files changed, 65 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/ds1374.txt

diff --git a/Documentation/devicetree/bindings/mfd/ds1374.txt 
b/Documentation/devicetree/bindings/mfd/ds1374.txt
new file mode 100644
index 000..b22396f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ds1374.txt
@@ -0,0 +1,63 @@
+* Device tree bindings for Maxim/Dallas DS1374 Multi Function Device (MFD)
+
+The Maxim/Dallas DS1374 is a multi function device that combines rtc,
+watchdog or alarm, as well as trickle charger.
+
+The DS1374 is connected via I2C.
+
+Required properties:
+- compatible: "dallas,ds1374"
+- reg: I2C slave address
+- dallas,ds1374-mode: Should be one of the following values:
+   <0> for RTC
+   <1> for RTC + Alarm (Interrupt)
+   <2> for RTC + Watchdog
+
+Required child:
+A single available child device of type matching the "dallas,ds1374-mode"
+property.
+
+Optional properties (watchdog):
+- dallas,ds1374-remap-wdt-reset: Boolean describing whether the INT pin
+on the device is used as interrupt for
+the alarm
+
+See ../watchdog/* for generic watchdog bindings.
+
+Optional properties (real time clock):
+- interrupt: phandle to interrupt cell for the rtc's alarm feature
+
+See ../rtc/* for generic rtc bindings.
+
+Optional properties (trickle-charger):
+- dallas,trickle-resistor-ohms : Selected resistor for trickle charger
+   Values usable for ds1374 are 250, 2000, 4000
+   Should be given if trickle charger should be enabled
+- dallas,trickle-diode-disable : Do not use internal trickle charger diode
+   Should be given if internal trickle charger diode should be disabled
+
+Example for rtc with alarm mode and interrupt:
+
+i2c@12ca {
+   rtc@68 {
+   compatible = "ds1374";
+   reg = <0x68>;
+   interrupts = < 62>;
+   dallas,ds1374-mode = <2>
+
+   dallas,trickle-resistor-ohms = <250>;
+   dallas,trickle-diode-disable;
+   };
+};
+
+Example for rtc with watchdog and reset on timeout, with reset remapped
+to the INT pin:
+
+i2c@12ca {
+   rtc@68 {
+   compatible = "ds1374";
+   reg = <0x68>;
+   dallas,ds1374-mode = <2>
+   dallas,ds1374-remap-wdt-reset;
+   };
+};
diff --git a/Documentation/devicetree/bindings/trivial-devices.txt 
b/Documentation/devicetree/bindings/trivial-devices.txt
index 3e0a34c..f7a50e5 100644
--- a/Documentation/devicetree/bindings/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/trivial-devices.txt
@@ -29,7 +29,6 @@ cirrus,cs42l51Cirrus Logic CS42L51 audio codec
 dallas,ds1307  64 x 8, Serial, I2C Real-Time Clock
 dallas,ds1338  I2C RTC with 56-Byte NV RAM
 dallas,ds1340  I2C RTC with Trickle Charger
-dallas,ds1374  I2C, 32-Bit Binary Counter Watchdog RTC with Trickle 
Charger and Reset Input/Output
 dallas,ds1631  High-Precision Digital Thermometer
 dallas,ds1682  Total-Elapsed-Time Recorder with Alarm
 dallas,ds1775  Tiny Digital Thermometer and Thermostat
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 8d3b957..e6763fe 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -250,6 +250,8 @@ config RTC_DRV_DS1307_CENTURY
 
 config RTC_DRV_DS1374
tristate "Dallas/Maxim DS1374"
+   depends on MFD_DS1374
+   depends on REGMAP_I2C
help
  If you say yes here you get support for Dallas Semiconductor
  DS1374 real-time clock chips. If an interrupt is associated
-- 
2.7.4

Re: [PATCH] mfd: cros-ec: Add cros_ec_readmem() helpers for I2C/SPI based ECs

[Moritz Fischer]

On Tue, May 09, 2017 at 01:56:14PM +0800, kbuild test robot wrote:
> Hi Moritz,
> 
> [auto build test WARNING on ljones-mfd/for-mfd-next]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Moritz-Fischer/mfd-cros-ec-Add-cros_ec_readmem-helpers-for-I2C-SPI-based-ECs/20170509-040606
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git 
> for-mfd-next
> config: tile-allmodconfig
> compiler: tilegx-linux-gcc (GCC) 4.6.2
> reproduce:
> wget 
> https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> make.cross ARCH=tile  allmodconfig
> make.cross ARCH=tile 

I just locally ran that and it wouldn't print a warning. False positive?

> 
> All warnings (new ones prefixed by >>):
> 
> 
> vim +279 drivers/mfd/cros_ec.c
> 
>263return 0;
>264}
>265EXPORT_SYMBOL(cros_ec_resume);
>266
>267#endif
>268
>269int cros_ec_readmem(struct cros_ec_device *ec, unsigned int 
> offset,
>270   unsigned int bytes, void *dest)
>271{
>272int ret;
>273struct ec_params_read_memmap *params;
>274struct cros_ec_command *msg;
>275
>276if (offset >= EC_MEMMAP_SIZE - bytes)
>277return -EINVAL;
>278
>  > 279msg = kzalloc(sizeof(*msg) + max(sizeof(*params), 
> bytes), GFP_KERNEL);

What am I not seeing here?
>280if (!msg)
>281return -ENOMEM;
>282
>283msg->version = 0;
>284msg->command = EC_CMD_READ_MEMMAP;
>285msg->insize = bytes;
>286msg->outsize = sizeof(*params);
>287
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Thanks,

Moritz


signature.asc
Description: PGP signature

Re: [PATCH] mfd: cros-ec: Add cros_ec_readmem() helpers for I2C/SPI based ECs

[Moritz Fischer]

On Tue, May 09, 2017 at 01:56:14PM +0800, kbuild test robot wrote:
> Hi Moritz,
> 
> [auto build test WARNING on ljones-mfd/for-mfd-next]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Moritz-Fischer/mfd-cros-ec-Add-cros_ec_readmem-helpers-for-I2C-SPI-based-ECs/20170509-040606
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git 
> for-mfd-next
> config: tile-allmodconfig
> compiler: tilegx-linux-gcc (GCC) 4.6.2
> reproduce:
> wget 
> https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> make.cross ARCH=tile  allmodconfig
> make.cross ARCH=tile 

I just locally ran that and it wouldn't print a warning. False positive?

> 
> All warnings (new ones prefixed by >>):
> 
> 
> vim +279 drivers/mfd/cros_ec.c
> 
>263return 0;
>264}
>265EXPORT_SYMBOL(cros_ec_resume);
>266
>267#endif
>268
>269int cros_ec_readmem(struct cros_ec_device *ec, unsigned int 
> offset,
>270   unsigned int bytes, void *dest)
>271{
>272int ret;
>273struct ec_params_read_memmap *params;
>274struct cros_ec_command *msg;
>275
>276if (offset >= EC_MEMMAP_SIZE - bytes)
>277return -EINVAL;
>278
>  > 279msg = kzalloc(sizeof(*msg) + max(sizeof(*params), 
> bytes), GFP_KERNEL);

What am I not seeing here?
>280if (!msg)
>281return -ENOMEM;
>282
>283msg->version = 0;
>284msg->command = EC_CMD_READ_MEMMAP;
>285msg->insize = bytes;
>286msg->outsize = sizeof(*params);
>287
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation

Thanks,

Moritz


signature.asc
Description: PGP signature

Re: [PATCH v2 02/16] fpga: bridge: support getting bridge from device

[Moritz Fischer]

Hi Alan,

On Mon, May 8, 2017 at 2:20 PM, Alan Tull <at...@kernel.org> wrote:
> On Mon, May 8, 2017 at 4:11 PM, Moritz Fischer <m...@kernel.org> wrote:
>> Hi Alan,
>>
>> On Mon, May 8, 2017 at 2:02 PM, Alan Tull <at...@kernel.org> wrote:
>>> On Mon, May 8, 2017 at 3:52 PM, Moritz Fischer <m...@kernel.org> wrote:
>>>> On Mon, May 8, 2017 at 1:44 PM, Alan Tull <at...@kernel.org> wrote:
>>>>> On Mon, May 8, 2017 at 3:44 AM, Wu, Hao <hao...@intel.com> wrote:
>>>>>>> On Wed, May 3, 2017 at 3:07 PM, Alan Tull <at...@kernel.org> wrote:
>>>>>>> > On Wed, May 3, 2017 at 6:58 AM, Wu Hao <hao...@intel.com> wrote:
>>>>>>> >> On Thu, Apr 20, 2017 at 09:09:47AM -0500, Alan Tull wrote:
>>>>>>> >>> Add two functions for getting the FPGA bridge from the device
>>>>>>> >>> rather than device tree node.  This is to enable writing code
>>>>>>> >>> that will support using FPGA bridges without device tree.
>>>>>>> >>> Rename one old function to make it clear that it is device
>>>>>>> >>> tree-ish.  This leaves us with 3 functions for getting a bridge:
>>>>>>> >>>
>>>>>>> >>> * fpga_bridge_get
>>>>>>> >>>   Get the bridge given the device.
>>>>>>> >>>
>>>>>>> >>> * fpga_bridges_get_to_list
>>>>>>> >>>   Given the device, get the bridge and add it to a list.
>>>>>>> >>>
>>>>>>> >>> * of_fpga_bridges_get_to_list
>>>>>>> >>>   Renamed from priviously existing fpga_bridges_get_to_list.
>>>>>>> >>>   Given the device node, get the bridge and add it to a list.
>>>>>>> >>>
>>>>>>> >>
>>>>>>> >> Hi Alan
>>>>>>> >>
>>>>>>> >> Thanks a lot for providing this patch set for non device tree 
>>>>>>> >> support. :)
>>>>>>> >> Actually I am reworking the Intel FPGA device drivers based on this 
>>>>>>> >> patch
>>>>>>> >> set, and I find some problems with the existing APIs including fpga 
>>>>>>> >> bridge
>>>>>>> >> and manager. My idea is to create all fpga bridges/regions/manager 
>>>>>>> >> under
>>>>>>> >> the same platform device (FME), it allows FME driver to establish the
>>>>>>> >> relationship for the bridges/regions/managers it creates in an easy 
>>>>>>> >> way.
>>>>>>> >> But I found current fpga class API doesn't support this very well.
>>>>>>> >> e.g fpga_bridge_get/get_to_list only accept parent device as the 
>>>>>>> >> input
>>>>>>> >> parameter, but it doesn't work if we have multiple bridges (and
>>>>>>> >> regions/manager) under the same platform device. fpga_mgr has similar
>>>>>>> >> issue, but fpga_region APIs work better, as they accept fpga_region 
>>>>>>> >> as
>>>>>>> >> parameter not the shared parent device.
>>>>>>> >
>>>>>>> > That's good feedback.  I can post a couple patches that apply on top
>>>>>>> > of that patchset to add the APIs you need.
>>>>>>> >
>>>>>>> > Probably what I'll do is add
>>>>>>> >
>>>>>>> > struct fpga_manager *fpga_mgr_get(struct fpga_manager *mgr);
>>>>>>> >
>>>>>>> > And rename fpga_bridge_get() to fpga_bridge_dev_get() and add the
>>>>>>> following:
>>>>>>> >
>>>>>>> > struct fpga_bridge *fpga_bridge_get(struct fpga_bridge *br,
>>>>>>> > struct fpga_image_info *info);
>>>>>>> >
>>>>>>> > int of_fpga_bridge_get_to_list(struct fpga_bridge *br,
>>>>>>> >struct fpga_image_info *info,
>>>>>>> >struct list_head *bridge_list);
>>>>>>> >
>>&

Re: [PATCH v2 02/16] fpga: bridge: support getting bridge from device

[Moritz Fischer]

Hi Alan,

On Mon, May 8, 2017 at 2:20 PM, Alan Tull  wrote:
> On Mon, May 8, 2017 at 4:11 PM, Moritz Fischer  wrote:
>> Hi Alan,
>>
>> On Mon, May 8, 2017 at 2:02 PM, Alan Tull  wrote:
>>> On Mon, May 8, 2017 at 3:52 PM, Moritz Fischer  wrote:
>>>> On Mon, May 8, 2017 at 1:44 PM, Alan Tull  wrote:
>>>>> On Mon, May 8, 2017 at 3:44 AM, Wu, Hao  wrote:
>>>>>>> On Wed, May 3, 2017 at 3:07 PM, Alan Tull  wrote:
>>>>>>> > On Wed, May 3, 2017 at 6:58 AM, Wu Hao  wrote:
>>>>>>> >> On Thu, Apr 20, 2017 at 09:09:47AM -0500, Alan Tull wrote:
>>>>>>> >>> Add two functions for getting the FPGA bridge from the device
>>>>>>> >>> rather than device tree node.  This is to enable writing code
>>>>>>> >>> that will support using FPGA bridges without device tree.
>>>>>>> >>> Rename one old function to make it clear that it is device
>>>>>>> >>> tree-ish.  This leaves us with 3 functions for getting a bridge:
>>>>>>> >>>
>>>>>>> >>> * fpga_bridge_get
>>>>>>> >>>   Get the bridge given the device.
>>>>>>> >>>
>>>>>>> >>> * fpga_bridges_get_to_list
>>>>>>> >>>   Given the device, get the bridge and add it to a list.
>>>>>>> >>>
>>>>>>> >>> * of_fpga_bridges_get_to_list
>>>>>>> >>>   Renamed from priviously existing fpga_bridges_get_to_list.
>>>>>>> >>>   Given the device node, get the bridge and add it to a list.
>>>>>>> >>>
>>>>>>> >>
>>>>>>> >> Hi Alan
>>>>>>> >>
>>>>>>> >> Thanks a lot for providing this patch set for non device tree 
>>>>>>> >> support. :)
>>>>>>> >> Actually I am reworking the Intel FPGA device drivers based on this 
>>>>>>> >> patch
>>>>>>> >> set, and I find some problems with the existing APIs including fpga 
>>>>>>> >> bridge
>>>>>>> >> and manager. My idea is to create all fpga bridges/regions/manager 
>>>>>>> >> under
>>>>>>> >> the same platform device (FME), it allows FME driver to establish the
>>>>>>> >> relationship for the bridges/regions/managers it creates in an easy 
>>>>>>> >> way.
>>>>>>> >> But I found current fpga class API doesn't support this very well.
>>>>>>> >> e.g fpga_bridge_get/get_to_list only accept parent device as the 
>>>>>>> >> input
>>>>>>> >> parameter, but it doesn't work if we have multiple bridges (and
>>>>>>> >> regions/manager) under the same platform device. fpga_mgr has similar
>>>>>>> >> issue, but fpga_region APIs work better, as they accept fpga_region 
>>>>>>> >> as
>>>>>>> >> parameter not the shared parent device.
>>>>>>> >
>>>>>>> > That's good feedback.  I can post a couple patches that apply on top
>>>>>>> > of that patchset to add the APIs you need.
>>>>>>> >
>>>>>>> > Probably what I'll do is add
>>>>>>> >
>>>>>>> > struct fpga_manager *fpga_mgr_get(struct fpga_manager *mgr);
>>>>>>> >
>>>>>>> > And rename fpga_bridge_get() to fpga_bridge_dev_get() and add the
>>>>>>> following:
>>>>>>> >
>>>>>>> > struct fpga_bridge *fpga_bridge_get(struct fpga_bridge *br,
>>>>>>> > struct fpga_image_info *info);
>>>>>>> >
>>>>>>> > int of_fpga_bridge_get_to_list(struct fpga_bridge *br,
>>>>>>> >struct fpga_image_info *info,
>>>>>>> >struct list_head *bridge_list);
>>>>>>> >
>>>>>>> > Working on it now.
>>>>>>> >
>>>>>>> >>
>>>>>>> >> Do you think if having multiple fpga-*

Re: [PATCH v2 02/16] fpga: bridge: support getting bridge from device

[Moritz Fischer]

Hi Alan,

On Mon, May 8, 2017 at 2:02 PM, Alan Tull <at...@kernel.org> wrote:
> On Mon, May 8, 2017 at 3:52 PM, Moritz Fischer <m...@kernel.org> wrote:
>> On Mon, May 8, 2017 at 1:44 PM, Alan Tull <at...@kernel.org> wrote:
>>> On Mon, May 8, 2017 at 3:44 AM, Wu, Hao <hao...@intel.com> wrote:
>>>>> On Wed, May 3, 2017 at 3:07 PM, Alan Tull <at...@kernel.org> wrote:
>>>>> > On Wed, May 3, 2017 at 6:58 AM, Wu Hao <hao...@intel.com> wrote:
>>>>> >> On Thu, Apr 20, 2017 at 09:09:47AM -0500, Alan Tull wrote:
>>>>> >>> Add two functions for getting the FPGA bridge from the device
>>>>> >>> rather than device tree node.  This is to enable writing code
>>>>> >>> that will support using FPGA bridges without device tree.
>>>>> >>> Rename one old function to make it clear that it is device
>>>>> >>> tree-ish.  This leaves us with 3 functions for getting a bridge:
>>>>> >>>
>>>>> >>> * fpga_bridge_get
>>>>> >>>   Get the bridge given the device.
>>>>> >>>
>>>>> >>> * fpga_bridges_get_to_list
>>>>> >>>   Given the device, get the bridge and add it to a list.
>>>>> >>>
>>>>> >>> * of_fpga_bridges_get_to_list
>>>>> >>>   Renamed from priviously existing fpga_bridges_get_to_list.
>>>>> >>>   Given the device node, get the bridge and add it to a list.
>>>>> >>>
>>>>> >>
>>>>> >> Hi Alan
>>>>> >>
>>>>> >> Thanks a lot for providing this patch set for non device tree support. 
>>>>> >> :)
>>>>> >> Actually I am reworking the Intel FPGA device drivers based on this 
>>>>> >> patch
>>>>> >> set, and I find some problems with the existing APIs including fpga 
>>>>> >> bridge
>>>>> >> and manager. My idea is to create all fpga bridges/regions/manager 
>>>>> >> under
>>>>> >> the same platform device (FME), it allows FME driver to establish the
>>>>> >> relationship for the bridges/regions/managers it creates in an easy 
>>>>> >> way.
>>>>> >> But I found current fpga class API doesn't support this very well.
>>>>> >> e.g fpga_bridge_get/get_to_list only accept parent device as the input
>>>>> >> parameter, but it doesn't work if we have multiple bridges (and
>>>>> >> regions/manager) under the same platform device. fpga_mgr has similar
>>>>> >> issue, but fpga_region APIs work better, as they accept fpga_region as
>>>>> >> parameter not the shared parent device.
>>>>> >
>>>>> > That's good feedback.  I can post a couple patches that apply on top
>>>>> > of that patchset to add the APIs you need.
>>>>> >
>>>>> > Probably what I'll do is add
>>>>> >
>>>>> > struct fpga_manager *fpga_mgr_get(struct fpga_manager *mgr);
>>>>> >
>>>>> > And rename fpga_bridge_get() to fpga_bridge_dev_get() and add the
>>>>> following:
>>>>> >
>>>>> > struct fpga_bridge *fpga_bridge_get(struct fpga_bridge *br,
>>>>> > struct fpga_image_info *info);
>>>>> >
>>>>> > int of_fpga_bridge_get_to_list(struct fpga_bridge *br,
>>>>> >struct fpga_image_info *info,
>>>>> >struct list_head *bridge_list);
>>>>> >
>>>>> > Working on it now.
>>>>> >
>>>>> >>
>>>>> >> Do you think if having multiple fpga-* under one parent device is in 
>>>>> >> the
>>>>> >> right direction?
>>>>> >
>>>>> > That should be fine as long as it's coded with an eye on making things
>>>>> > reusable and seeing beyond the current project.  Just thinking of the
>>>>> > future and of what can be of general usefulness for others.  And there
>>>>> > will be others interested in reusing this.
>>>>> >
>>>>> > Alan
>>>>>
>>>&

Re: [PATCH v2 02/16] fpga: bridge: support getting bridge from device

[Moritz Fischer]

Hi Alan,

On Mon, May 8, 2017 at 2:02 PM, Alan Tull  wrote:
> On Mon, May 8, 2017 at 3:52 PM, Moritz Fischer  wrote:
>> On Mon, May 8, 2017 at 1:44 PM, Alan Tull  wrote:
>>> On Mon, May 8, 2017 at 3:44 AM, Wu, Hao  wrote:
>>>>> On Wed, May 3, 2017 at 3:07 PM, Alan Tull  wrote:
>>>>> > On Wed, May 3, 2017 at 6:58 AM, Wu Hao  wrote:
>>>>> >> On Thu, Apr 20, 2017 at 09:09:47AM -0500, Alan Tull wrote:
>>>>> >>> Add two functions for getting the FPGA bridge from the device
>>>>> >>> rather than device tree node.  This is to enable writing code
>>>>> >>> that will support using FPGA bridges without device tree.
>>>>> >>> Rename one old function to make it clear that it is device
>>>>> >>> tree-ish.  This leaves us with 3 functions for getting a bridge:
>>>>> >>>
>>>>> >>> * fpga_bridge_get
>>>>> >>>   Get the bridge given the device.
>>>>> >>>
>>>>> >>> * fpga_bridges_get_to_list
>>>>> >>>   Given the device, get the bridge and add it to a list.
>>>>> >>>
>>>>> >>> * of_fpga_bridges_get_to_list
>>>>> >>>   Renamed from priviously existing fpga_bridges_get_to_list.
>>>>> >>>   Given the device node, get the bridge and add it to a list.
>>>>> >>>
>>>>> >>
>>>>> >> Hi Alan
>>>>> >>
>>>>> >> Thanks a lot for providing this patch set for non device tree support. 
>>>>> >> :)
>>>>> >> Actually I am reworking the Intel FPGA device drivers based on this 
>>>>> >> patch
>>>>> >> set, and I find some problems with the existing APIs including fpga 
>>>>> >> bridge
>>>>> >> and manager. My idea is to create all fpga bridges/regions/manager 
>>>>> >> under
>>>>> >> the same platform device (FME), it allows FME driver to establish the
>>>>> >> relationship for the bridges/regions/managers it creates in an easy 
>>>>> >> way.
>>>>> >> But I found current fpga class API doesn't support this very well.
>>>>> >> e.g fpga_bridge_get/get_to_list only accept parent device as the input
>>>>> >> parameter, but it doesn't work if we have multiple bridges (and
>>>>> >> regions/manager) under the same platform device. fpga_mgr has similar
>>>>> >> issue, but fpga_region APIs work better, as they accept fpga_region as
>>>>> >> parameter not the shared parent device.
>>>>> >
>>>>> > That's good feedback.  I can post a couple patches that apply on top
>>>>> > of that patchset to add the APIs you need.
>>>>> >
>>>>> > Probably what I'll do is add
>>>>> >
>>>>> > struct fpga_manager *fpga_mgr_get(struct fpga_manager *mgr);
>>>>> >
>>>>> > And rename fpga_bridge_get() to fpga_bridge_dev_get() and add the
>>>>> following:
>>>>> >
>>>>> > struct fpga_bridge *fpga_bridge_get(struct fpga_bridge *br,
>>>>> > struct fpga_image_info *info);
>>>>> >
>>>>> > int of_fpga_bridge_get_to_list(struct fpga_bridge *br,
>>>>> >struct fpga_image_info *info,
>>>>> >struct list_head *bridge_list);
>>>>> >
>>>>> > Working on it now.
>>>>> >
>>>>> >>
>>>>> >> Do you think if having multiple fpga-* under one parent device is in 
>>>>> >> the
>>>>> >> right direction?
>>>>> >
>>>>> > That should be fine as long as it's coded with an eye on making things
>>>>> > reusable and seeing beyond the current project.  Just thinking of the
>>>>> > future and of what can be of general usefulness for others.  And there
>>>>> > will be others interested in reusing this.
>>>>> >
>>>>> > Alan
>>>>>
>>>>> Actually,  I don't think you will need the additional APIs we were
>>>>> just discussing after all.  What you have 

Re: [PATCH v2 02/16] fpga: bridge: support getting bridge from device

[Moritz Fischer]

On Mon, May 8, 2017 at 1:44 PM, Alan Tull  wrote:
> On Mon, May 8, 2017 at 3:44 AM, Wu, Hao  wrote:
>>> On Wed, May 3, 2017 at 3:07 PM, Alan Tull  wrote:
>>> > On Wed, May 3, 2017 at 6:58 AM, Wu Hao  wrote:
>>> >> On Thu, Apr 20, 2017 at 09:09:47AM -0500, Alan Tull wrote:
>>> >>> Add two functions for getting the FPGA bridge from the device
>>> >>> rather than device tree node.  This is to enable writing code
>>> >>> that will support using FPGA bridges without device tree.
>>> >>> Rename one old function to make it clear that it is device
>>> >>> tree-ish.  This leaves us with 3 functions for getting a bridge:
>>> >>>
>>> >>> * fpga_bridge_get
>>> >>>   Get the bridge given the device.
>>> >>>
>>> >>> * fpga_bridges_get_to_list
>>> >>>   Given the device, get the bridge and add it to a list.
>>> >>>
>>> >>> * of_fpga_bridges_get_to_list
>>> >>>   Renamed from priviously existing fpga_bridges_get_to_list.
>>> >>>   Given the device node, get the bridge and add it to a list.
>>> >>>
>>> >>
>>> >> Hi Alan
>>> >>
>>> >> Thanks a lot for providing this patch set for non device tree support. :)
>>> >> Actually I am reworking the Intel FPGA device drivers based on this patch
>>> >> set, and I find some problems with the existing APIs including fpga 
>>> >> bridge
>>> >> and manager. My idea is to create all fpga bridges/regions/manager under
>>> >> the same platform device (FME), it allows FME driver to establish the
>>> >> relationship for the bridges/regions/managers it creates in an easy way.
>>> >> But I found current fpga class API doesn't support this very well.
>>> >> e.g fpga_bridge_get/get_to_list only accept parent device as the input
>>> >> parameter, but it doesn't work if we have multiple bridges (and
>>> >> regions/manager) under the same platform device. fpga_mgr has similar
>>> >> issue, but fpga_region APIs work better, as they accept fpga_region as
>>> >> parameter not the shared parent device.
>>> >
>>> > That's good feedback.  I can post a couple patches that apply on top
>>> > of that patchset to add the APIs you need.
>>> >
>>> > Probably what I'll do is add
>>> >
>>> > struct fpga_manager *fpga_mgr_get(struct fpga_manager *mgr);
>>> >
>>> > And rename fpga_bridge_get() to fpga_bridge_dev_get() and add the
>>> following:
>>> >
>>> > struct fpga_bridge *fpga_bridge_get(struct fpga_bridge *br,
>>> > struct fpga_image_info *info);
>>> >
>>> > int of_fpga_bridge_get_to_list(struct fpga_bridge *br,
>>> >struct fpga_image_info *info,
>>> >struct list_head *bridge_list);
>>> >
>>> > Working on it now.
>>> >
>>> >>
>>> >> Do you think if having multiple fpga-* under one parent device is in the
>>> >> right direction?
>>> >
>>> > That should be fine as long as it's coded with an eye on making things
>>> > reusable and seeing beyond the current project.  Just thinking of the
>>> > future and of what can be of general usefulness for others.  And there
>>> > will be others interested in reusing this.
>>> >
>>> > Alan
>>>
>>> Actually,  I don't think you will need the additional APIs we were
>>> just discussing after all.  What you have is a multifunction device
>>> (single piece of hardware, multi functions such as in drivers/mfd).
>>> It will have child devices for the mgr, bridges, and regions.  When
>>> registering the mgr and bridges you will need to allocate child
>>> devices and use them to create the mgr and bridges.
>>>
>>> Alan
>>
>> Hi Alan
>>
>> I tried to create child devices as the parent device for the mgr and
>> bridges in fme platform driver module. If only creates the device without
>> driver, it doesn't work as try_module_get(dev->parent->driver->owner)
>> always failed in mgr_get and bridge_get functions.
>
> I tried it and it wasn't hard.
>
> Each mgr or bridge driver should be a separate file which registers
> its driver using 'module_platform_driver".  That way the drivers are
> registered with the kernel in a normal fashion.  The thing we want
> here is to not bypass the kernel driver model.
>
> You'll need to keep the platform_device pointers in private data somewhere.
>
> For each child platform device, do a platform_device_alloc and
> platform_device_add.
>
> Then to get the manager, you can do
>
> mgr = fpga_mgr_get(>mgr_pdev->dev);
>
> If this is in your probe function, you can use -EPROBE_DEFER if
> platform_device_alloc or fpga_mgr_get fail.  Then you could destroy
> whatever you've created and return -EPROBE_DEFER to wait for the
> drivers you need to be registered and ready for devices to be added.
>
>>
>> If it creates platform devices as child devices, and introduce new platform
>> device drivers for bridge and mgr, then it will be difficult to establish the
>> relationship for region/mgr/bridges (e.g when should region->mgr be
>> configured and cleared, as mgr is created/destroyed when mgr parent
>> 

Re: [PATCH v2 02/16] fpga: bridge: support getting bridge from device

[Moritz Fischer]

On Mon, May 8, 2017 at 1:44 PM, Alan Tull  wrote:
> On Mon, May 8, 2017 at 3:44 AM, Wu, Hao  wrote:
>>> On Wed, May 3, 2017 at 3:07 PM, Alan Tull  wrote:
>>> > On Wed, May 3, 2017 at 6:58 AM, Wu Hao  wrote:
>>> >> On Thu, Apr 20, 2017 at 09:09:47AM -0500, Alan Tull wrote:
>>> >>> Add two functions for getting the FPGA bridge from the device
>>> >>> rather than device tree node.  This is to enable writing code
>>> >>> that will support using FPGA bridges without device tree.
>>> >>> Rename one old function to make it clear that it is device
>>> >>> tree-ish.  This leaves us with 3 functions for getting a bridge:
>>> >>>
>>> >>> * fpga_bridge_get
>>> >>>   Get the bridge given the device.
>>> >>>
>>> >>> * fpga_bridges_get_to_list
>>> >>>   Given the device, get the bridge and add it to a list.
>>> >>>
>>> >>> * of_fpga_bridges_get_to_list
>>> >>>   Renamed from priviously existing fpga_bridges_get_to_list.
>>> >>>   Given the device node, get the bridge and add it to a list.
>>> >>>
>>> >>
>>> >> Hi Alan
>>> >>
>>> >> Thanks a lot for providing this patch set for non device tree support. :)
>>> >> Actually I am reworking the Intel FPGA device drivers based on this patch
>>> >> set, and I find some problems with the existing APIs including fpga 
>>> >> bridge
>>> >> and manager. My idea is to create all fpga bridges/regions/manager under
>>> >> the same platform device (FME), it allows FME driver to establish the
>>> >> relationship for the bridges/regions/managers it creates in an easy way.
>>> >> But I found current fpga class API doesn't support this very well.
>>> >> e.g fpga_bridge_get/get_to_list only accept parent device as the input
>>> >> parameter, but it doesn't work if we have multiple bridges (and
>>> >> regions/manager) under the same platform device. fpga_mgr has similar
>>> >> issue, but fpga_region APIs work better, as they accept fpga_region as
>>> >> parameter not the shared parent device.
>>> >
>>> > That's good feedback.  I can post a couple patches that apply on top
>>> > of that patchset to add the APIs you need.
>>> >
>>> > Probably what I'll do is add
>>> >
>>> > struct fpga_manager *fpga_mgr_get(struct fpga_manager *mgr);
>>> >
>>> > And rename fpga_bridge_get() to fpga_bridge_dev_get() and add the
>>> following:
>>> >
>>> > struct fpga_bridge *fpga_bridge_get(struct fpga_bridge *br,
>>> > struct fpga_image_info *info);
>>> >
>>> > int of_fpga_bridge_get_to_list(struct fpga_bridge *br,
>>> >struct fpga_image_info *info,
>>> >struct list_head *bridge_list);
>>> >
>>> > Working on it now.
>>> >
>>> >>
>>> >> Do you think if having multiple fpga-* under one parent device is in the
>>> >> right direction?
>>> >
>>> > That should be fine as long as it's coded with an eye on making things
>>> > reusable and seeing beyond the current project.  Just thinking of the
>>> > future and of what can be of general usefulness for others.  And there
>>> > will be others interested in reusing this.
>>> >
>>> > Alan
>>>
>>> Actually,  I don't think you will need the additional APIs we were
>>> just discussing after all.  What you have is a multifunction device
>>> (single piece of hardware, multi functions such as in drivers/mfd).
>>> It will have child devices for the mgr, bridges, and regions.  When
>>> registering the mgr and bridges you will need to allocate child
>>> devices and use them to create the mgr and bridges.
>>>
>>> Alan
>>
>> Hi Alan
>>
>> I tried to create child devices as the parent device for the mgr and
>> bridges in fme platform driver module. If only creates the device without
>> driver, it doesn't work as try_module_get(dev->parent->driver->owner)
>> always failed in mgr_get and bridge_get functions.
>
> I tried it and it wasn't hard.
>
> Each mgr or bridge driver should be a separate file which registers
> its driver using 'module_platform_driver".  That way the drivers are
> registered with the kernel in a normal fashion.  The thing we want
> here is to not bypass the kernel driver model.
>
> You'll need to keep the platform_device pointers in private data somewhere.
>
> For each child platform device, do a platform_device_alloc and
> platform_device_add.
>
> Then to get the manager, you can do
>
> mgr = fpga_mgr_get(>mgr_pdev->dev);
>
> If this is in your probe function, you can use -EPROBE_DEFER if
> platform_device_alloc or fpga_mgr_get fail.  Then you could destroy
> whatever you've created and return -EPROBE_DEFER to wait for the
> drivers you need to be registered and ready for devices to be added.
>
>>
>> If it creates platform devices as child devices, and introduce new platform
>> device drivers for bridge and mgr, then it will be difficult to establish the
>> relationship for region/mgr/bridges (e.g when should region->mgr be
>> configured and cleared, as mgr is created/destroyed when mgr parent
>> device platform driver module is loaded/unload), and it maybe not really

[PATCH] mfd: cros-ec: Add cros_ec_readmem() helpers for I2C/SPI based ECs

[Moritz Fischer]

Add cros_ec_readmem() based helpers for I2C/SPI based ECs.
Unlike the LPC based ECs the I2C/SPI based ones cannot just directly
read the mapped region.

Signed-off-by: Moritz Fischer <m...@kernel.org>
---

Hi Lee,

I'm currently reworking my patchset for the cros-ec hwmon,
and as part of the feedback there Guenter had pointed out that I should use
the cmd_readmem() callbacks. Since they don't exist for the I2C / SPI ECs
I'll send this patch ahead, while working on my hwmon patchset.

Thanks,

Moritz
---
 drivers/mfd/cros_ec.c | 39 +++
 drivers/mfd/cros_ec.h | 29 +
 drivers/mfd/cros_ec_i2c.c |  3 +++
 drivers/mfd/cros_ec_spi.c |  2 ++
 4 files changed, 73 insertions(+)
 create mode 100644 drivers/mfd/cros_ec.h

diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index d4a407e..2121cd5 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -2,6 +2,7 @@
  * ChromeOS EC multi-function device
  *
  * Copyright (C) 2012 Google, Inc
+ * Copyright (C) 2017 National Instruments Corp
  *
  * This software is licensed under the terms of the GNU General Public
  * License version 2, as published by the Free Software Foundation, and
@@ -265,5 +266,43 @@ EXPORT_SYMBOL(cros_ec_resume);
 
 #endif
 
+int cros_ec_readmem(struct cros_ec_device *ec, unsigned int offset,
+  unsigned int bytes, void *dest)
+{
+   int ret;
+   struct ec_params_read_memmap *params;
+   struct cros_ec_command *msg;
+
+   if (offset >= EC_MEMMAP_SIZE - bytes)
+   return -EINVAL;
+
+   msg = kzalloc(sizeof(*msg) + max(sizeof(*params), bytes), GFP_KERNEL);
+   if (!msg)
+   return -ENOMEM;
+
+   msg->version = 0;
+   msg->command = EC_CMD_READ_MEMMAP;
+   msg->insize = bytes;
+   msg->outsize = sizeof(*params);
+
+   params = (struct ec_params_read_memmap *)msg->data;
+   params->offset = offset;
+   params->size = bytes;
+
+   ret = cros_ec_cmd_xfer_status(ec, msg);
+   if (ret < 0) {
+   dev_warn(ec->dev, "cannot read mapped reg: %d/%d\n",
+ret, msg->result);
+   goto out_free;
+   }
+
+   memcpy(dest, msg->data, bytes);
+
+out_free:
+   kfree(msg);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(cros_ec_readmem);
+
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("ChromeOS EC core driver");
diff --git a/drivers/mfd/cros_ec.h b/drivers/mfd/cros_ec.h
new file mode 100644
index 000..09e83e6
--- /dev/null
+++ b/drivers/mfd/cros_ec.h
@@ -0,0 +1,29 @@
+/*
+ * Copyright (C) 2017 National Instruments Corp
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that 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.
+ */
+
+#ifndef MFD_CROS_EC_H
+#define MFD_CROS_EC_H
+
+/**
+ * cros_ec_readmem - Read mapped memory in the ChromeOS EC
+ *
+ * @ec: Device to read from
+ * @offset: Offset to read within the mapped region
+ * @bytes: number of bytes to read
+ * @data: Return data
+ * @return: 0 if Ok, -ve on error
+ */
+int cros_ec_readmem(struct cros_ec_device *ec, unsigned int offset,
+   unsigned int bytes, void *dest);
+
+#endif /* MFD_CROS_EC_H */
diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
index 9f70de1..012f949 100644
--- a/drivers/mfd/cros_ec_i2c.c
+++ b/drivers/mfd/cros_ec_i2c.c
@@ -23,6 +23,8 @@
 #include 
 #include 
 
+#include "cros_ec.h"
+
 /**
  * Request format for protocol v3
  * byte 0  0xda (EC_COMMAND_PROTOCOL_3)
@@ -302,6 +304,7 @@ static int cros_ec_i2c_probe(struct i2c_client *client,
ec_dev->irq = client->irq;
ec_dev->cmd_xfer = cros_ec_cmd_xfer_i2c;
ec_dev->pkt_xfer = cros_ec_pkt_xfer_i2c;
+   ec_dev->cmd_readmem = cros_ec_readmem;
ec_dev->phys_name = client->adapter->name;
ec_dev->din_size = sizeof(struct ec_host_response_i2c) +
   sizeof(struct ec_response_get_protocol_info);
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index c971407..8f90bd6 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 
+#include "cros_ec.h"
 
 /* The header byte, which follows the preamble */
 #define EC_MSG_HEADER  0xec
@@ -661,6 +662,7 @@ static int cros_ec_spi_probe(struct spi_device *spi)
ec_dev->irq = spi->irq;
ec_dev->cmd_xfer = cros_ec_cmd_xfer_spi;
ec_dev->pkt_xfer = cros_ec_pkt_xfer

[PATCH] mfd: cros-ec: Add cros_ec_readmem() helpers for I2C/SPI based ECs

[Moritz Fischer]

Add cros_ec_readmem() based helpers for I2C/SPI based ECs.
Unlike the LPC based ECs the I2C/SPI based ones cannot just directly
read the mapped region.

Signed-off-by: Moritz Fischer 
---

Hi Lee,

I'm currently reworking my patchset for the cros-ec hwmon,
and as part of the feedback there Guenter had pointed out that I should use
the cmd_readmem() callbacks. Since they don't exist for the I2C / SPI ECs
I'll send this patch ahead, while working on my hwmon patchset.

Thanks,

Moritz
---
 drivers/mfd/cros_ec.c | 39 +++
 drivers/mfd/cros_ec.h | 29 +
 drivers/mfd/cros_ec_i2c.c |  3 +++
 drivers/mfd/cros_ec_spi.c |  2 ++
 4 files changed, 73 insertions(+)
 create mode 100644 drivers/mfd/cros_ec.h

diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index d4a407e..2121cd5 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -2,6 +2,7 @@
  * ChromeOS EC multi-function device
  *
  * Copyright (C) 2012 Google, Inc
+ * Copyright (C) 2017 National Instruments Corp
  *
  * This software is licensed under the terms of the GNU General Public
  * License version 2, as published by the Free Software Foundation, and
@@ -265,5 +266,43 @@ EXPORT_SYMBOL(cros_ec_resume);
 
 #endif
 
+int cros_ec_readmem(struct cros_ec_device *ec, unsigned int offset,
+  unsigned int bytes, void *dest)
+{
+   int ret;
+   struct ec_params_read_memmap *params;
+   struct cros_ec_command *msg;
+
+   if (offset >= EC_MEMMAP_SIZE - bytes)
+   return -EINVAL;
+
+   msg = kzalloc(sizeof(*msg) + max(sizeof(*params), bytes), GFP_KERNEL);
+   if (!msg)
+   return -ENOMEM;
+
+   msg->version = 0;
+   msg->command = EC_CMD_READ_MEMMAP;
+   msg->insize = bytes;
+   msg->outsize = sizeof(*params);
+
+   params = (struct ec_params_read_memmap *)msg->data;
+   params->offset = offset;
+   params->size = bytes;
+
+   ret = cros_ec_cmd_xfer_status(ec, msg);
+   if (ret < 0) {
+   dev_warn(ec->dev, "cannot read mapped reg: %d/%d\n",
+ret, msg->result);
+   goto out_free;
+   }
+
+   memcpy(dest, msg->data, bytes);
+
+out_free:
+   kfree(msg);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(cros_ec_readmem);
+
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("ChromeOS EC core driver");
diff --git a/drivers/mfd/cros_ec.h b/drivers/mfd/cros_ec.h
new file mode 100644
index 000..09e83e6
--- /dev/null
+++ b/drivers/mfd/cros_ec.h
@@ -0,0 +1,29 @@
+/*
+ * Copyright (C) 2017 National Instruments Corp
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that 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.
+ */
+
+#ifndef MFD_CROS_EC_H
+#define MFD_CROS_EC_H
+
+/**
+ * cros_ec_readmem - Read mapped memory in the ChromeOS EC
+ *
+ * @ec: Device to read from
+ * @offset: Offset to read within the mapped region
+ * @bytes: number of bytes to read
+ * @data: Return data
+ * @return: 0 if Ok, -ve on error
+ */
+int cros_ec_readmem(struct cros_ec_device *ec, unsigned int offset,
+   unsigned int bytes, void *dest);
+
+#endif /* MFD_CROS_EC_H */
diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
index 9f70de1..012f949 100644
--- a/drivers/mfd/cros_ec_i2c.c
+++ b/drivers/mfd/cros_ec_i2c.c
@@ -23,6 +23,8 @@
 #include 
 #include 
 
+#include "cros_ec.h"
+
 /**
  * Request format for protocol v3
  * byte 0  0xda (EC_COMMAND_PROTOCOL_3)
@@ -302,6 +304,7 @@ static int cros_ec_i2c_probe(struct i2c_client *client,
ec_dev->irq = client->irq;
ec_dev->cmd_xfer = cros_ec_cmd_xfer_i2c;
ec_dev->pkt_xfer = cros_ec_pkt_xfer_i2c;
+   ec_dev->cmd_readmem = cros_ec_readmem;
ec_dev->phys_name = client->adapter->name;
ec_dev->din_size = sizeof(struct ec_host_response_i2c) +
   sizeof(struct ec_response_get_protocol_info);
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index c971407..8f90bd6 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 
+#include "cros_ec.h"
 
 /* The header byte, which follows the preamble */
 #define EC_MSG_HEADER  0xec
@@ -661,6 +662,7 @@ static int cros_ec_spi_probe(struct spi_device *spi)
ec_dev->irq = spi->irq;
ec_dev->cmd_xfer = cros_ec_cmd_xfer_spi;
ec_dev->pkt_xfer = cros_ec_pkt_xfer_spi;
+   ec_dev->cmd_r

Re: [PATCH v2 08/16] fpga: region: check for child regions before allocing image info

[Moritz Fischer]

On Thu, Apr 20, 2017 at 7:09 AM, Alan Tull <at...@kernel.org> wrote:
> During a device tree overlay pre-apply notification, the check
> for child FPGA regions can happen slightly earlier.  This saves
> us from allocating the FPGA image info that just gets thrown
> away.
>
> This is a baby step in refactoring the FPGA region code to
> separate out common FPGA region code from FPGA region
> Device Tree overlay support.
>
> Signed-off-by: Alan Tull <at...@kernel.org>
Acked-by: Moritz Fischer <m...@kernel.org>
> ---
> v2: split out from another patch
> ---
>  drivers/fpga/fpga-region.c | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/fpga/fpga-region.c b/drivers/fpga/fpga-region.c
> index 7ff5426..c2730a8 100644
> --- a/drivers/fpga/fpga-region.c
> +++ b/drivers/fpga/fpga-region.c
> @@ -355,15 +355,19 @@ static int fpga_region_notify_pre_apply(struct 
> fpga_region *region,
> const char *firmware_name;
> int ret;
>
> -   info = fpga_image_info_alloc(>dev);
> -   if (!info)
> -   return -ENOMEM;
> -
> -   /* Reject overlay if child FPGA Regions have firmware-name property */
> +   /*
> +* Reject overlay if child FPGA Regions added in the overlay have
> +* firmware-name property (would mean that an FPGA region that has
> +* not been added to the live tree yet is doing FPGA programming).
> +*/
> ret = child_regions_with_firmware(nd->overlay);
> if (ret)
> return ret;
>
> +   info = fpga_image_info_alloc(dev);
> +   if (!info)
> +   return -ENOMEM;
> +
> /* Read FPGA region properties from the overlay */
> if (of_property_read_bool(nd->overlay, "partial-fpga-config"))
> info->flags |= FPGA_MGR_PARTIAL_RECONFIG;
> --
> 2.7.4
>

Re: [PATCH v2 08/16] fpga: region: check for child regions before allocing image info

[Moritz Fischer]

On Thu, Apr 20, 2017 at 7:09 AM, Alan Tull  wrote:
> During a device tree overlay pre-apply notification, the check
> for child FPGA regions can happen slightly earlier.  This saves
> us from allocating the FPGA image info that just gets thrown
> away.
>
> This is a baby step in refactoring the FPGA region code to
> separate out common FPGA region code from FPGA region
> Device Tree overlay support.
>
> Signed-off-by: Alan Tull 
Acked-by: Moritz Fischer 
> ---
> v2: split out from another patch
> ---
>  drivers/fpga/fpga-region.c | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/fpga/fpga-region.c b/drivers/fpga/fpga-region.c
> index 7ff5426..c2730a8 100644
> --- a/drivers/fpga/fpga-region.c
> +++ b/drivers/fpga/fpga-region.c
> @@ -355,15 +355,19 @@ static int fpga_region_notify_pre_apply(struct 
> fpga_region *region,
> const char *firmware_name;
> int ret;
>
> -   info = fpga_image_info_alloc(>dev);
> -   if (!info)
> -   return -ENOMEM;
> -
> -   /* Reject overlay if child FPGA Regions have firmware-name property */
> +   /*
> +* Reject overlay if child FPGA Regions added in the overlay have
> +* firmware-name property (would mean that an FPGA region that has
> +* not been added to the live tree yet is doing FPGA programming).
> +*/
> ret = child_regions_with_firmware(nd->overlay);
> if (ret)
> return ret;
>
> +   info = fpga_image_info_alloc(dev);
> +   if (!info)
> +   return -ENOMEM;
> +
> /* Read FPGA region properties from the overlay */
> if (of_property_read_bool(nd->overlay, "partial-fpga-config"))
> info->flags |= FPGA_MGR_PARTIAL_RECONFIG;
> --
> 2.7.4
>

Re: [PATCH v2 06/16] fpga: region: remove unneeded of_node_get and put

[Moritz Fischer]

On Thu, Apr 20, 2017 at 7:09 AM, Alan Tull <at...@kernel.org> wrote:
> Remove of_node_get/put in fpga_region_get/put.  Not
> needed and will get in the way when I separate out
> the common FPGA region code from Device Tree support
> code.
>
> Signed-off-by: Alan Tull <at...@kernel.org>

Acked-by: Moritz Fischer <m...@kernel.org>
> ---
> v2: split out from another patch
> ---
>  drivers/fpga/fpga-region.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/drivers/fpga/fpga-region.c b/drivers/fpga/fpga-region.c
> index eaea9d4..6784357 100644
> --- a/drivers/fpga/fpga-region.c
> +++ b/drivers/fpga/fpga-region.c
> @@ -94,9 +94,7 @@ static struct fpga_region *fpga_region_get(struct 
> fpga_region *region)
> }
>
> get_device(dev);
> -   of_node_get(dev->of_node);
> if (!try_module_get(dev->parent->driver->owner)) {
> -   of_node_put(dev->of_node);
> put_device(dev);
> mutex_unlock(>mutex);
> return ERR_PTR(-ENODEV);
> @@ -119,7 +117,6 @@ static void fpga_region_put(struct fpga_region *region)
> dev_dbg(dev, "put\n");
>
> module_put(dev->parent->driver->owner);
> -   of_node_put(dev->of_node);
> put_device(dev);
> mutex_unlock(>mutex);
>  }
> --
> 2.7.4
>

Re: [PATCH v2 06/16] fpga: region: remove unneeded of_node_get and put

[Moritz Fischer]

On Thu, Apr 20, 2017 at 7:09 AM, Alan Tull  wrote:
> Remove of_node_get/put in fpga_region_get/put.  Not
> needed and will get in the way when I separate out
> the common FPGA region code from Device Tree support
> code.
>
> Signed-off-by: Alan Tull 

Acked-by: Moritz Fischer 
> ---
> v2: split out from another patch
> ---
>  drivers/fpga/fpga-region.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/drivers/fpga/fpga-region.c b/drivers/fpga/fpga-region.c
> index eaea9d4..6784357 100644
> --- a/drivers/fpga/fpga-region.c
> +++ b/drivers/fpga/fpga-region.c
> @@ -94,9 +94,7 @@ static struct fpga_region *fpga_region_get(struct 
> fpga_region *region)
> }
>
> get_device(dev);
> -   of_node_get(dev->of_node);
> if (!try_module_get(dev->parent->driver->owner)) {
> -   of_node_put(dev->of_node);
> put_device(dev);
> mutex_unlock(>mutex);
> return ERR_PTR(-ENODEV);
> @@ -119,7 +117,6 @@ static void fpga_region_put(struct fpga_region *region)
> dev_dbg(dev, "put\n");
>
> module_put(dev->parent->driver->owner);
> -   of_node_put(dev->of_node);
> put_device(dev);
> mutex_unlock(>mutex);
>  }
> --
> 2.7.4
>

Re: [PATCH v2 15/16] fpga: region: add fpga_region_class_find

[Moritz Fischer]

On Thu, Apr 20, 2017 at 7:10 AM, Alan Tull <at...@kernel.org> wrote:
> Add a function for searching the fpga-region class.  This
> will be useful when device tree code is no longer in the
> same file that declares the fpga-region class.  Another
> step in separating common FPGA region code from device
> tree support.
>
> Signed-off-by: Alan Tull <at...@kernel.org>
Acked-by: Moritz Fischer <m...@kernel.org>
> ---
> v2: split out from another patch
> ---
>  drivers/fpga/fpga-region.c   | 23 +++
>  include/linux/fpga/fpga-region.h |  4 
>  2 files changed, 19 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/fpga/fpga-region.c b/drivers/fpga/fpga-region.c
> index e2a3fe6..7ffb8c1 100644
> --- a/drivers/fpga/fpga-region.c
> +++ b/drivers/fpga/fpga-region.c
> @@ -30,6 +30,20 @@
>  static DEFINE_IDA(fpga_region_ida);
>  static struct class *fpga_region_class;
>
> +struct fpga_region *fpga_region_class_find(
> +   struct device *start, const void *data,
> +   int (*match)(struct device *, const void *))
> +{
> +   struct device *dev;
> +
> +   dev = class_find_device(fpga_region_class, start, data, match);
> +   if (!dev)
> +   return NULL;
> +
> +   return to_fpga_region(dev);
> +}
> +EXPORT_SYMBOL_GPL(fpga_region_class_find);
> +
>  static const struct of_device_id fpga_region_of_match[] = {
> { .compatible = "fpga-region", },
> {},
> @@ -51,14 +65,7 @@ static int fpga_region_of_node_match(struct device *dev, 
> const void *data)
>   */
>  static struct fpga_region *of_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)
> -   return NULL;
> -
> -   return to_fpga_region(dev);
> +   return fpga_region_class_find(NULL, np, fpga_region_of_node_match);
>  }
>
>  /**
> diff --git a/include/linux/fpga/fpga-region.h 
> b/include/linux/fpga/fpga-region.h
> index 35e7e09..4966bb2 100644
> --- a/include/linux/fpga/fpga-region.h
> +++ b/include/linux/fpga/fpga-region.h
> @@ -28,6 +28,10 @@ struct fpga_region {
>
>  #define to_fpga_region(d) container_of(d, struct fpga_region, dev)
>
> +struct fpga_region *fpga_region_class_find(
> +   struct device *start, const void *data,
> +   int (*match)(struct device *, const void *));
> +
>  int fpga_region_program_fpga(struct fpga_region *region,
>  struct fpga_image_info *image_info);
>
> --
> 2.7.4
>

Re: [PATCH v2 15/16] fpga: region: add fpga_region_class_find

[Moritz Fischer]

On Thu, Apr 20, 2017 at 7:10 AM, Alan Tull  wrote:
> Add a function for searching the fpga-region class.  This
> will be useful when device tree code is no longer in the
> same file that declares the fpga-region class.  Another
> step in separating common FPGA region code from device
> tree support.
>
> Signed-off-by: Alan Tull 
Acked-by: Moritz Fischer 
> ---
> v2: split out from another patch
> ---
>  drivers/fpga/fpga-region.c   | 23 +++
>  include/linux/fpga/fpga-region.h |  4 
>  2 files changed, 19 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/fpga/fpga-region.c b/drivers/fpga/fpga-region.c
> index e2a3fe6..7ffb8c1 100644
> --- a/drivers/fpga/fpga-region.c
> +++ b/drivers/fpga/fpga-region.c
> @@ -30,6 +30,20 @@
>  static DEFINE_IDA(fpga_region_ida);
>  static struct class *fpga_region_class;
>
> +struct fpga_region *fpga_region_class_find(
> +   struct device *start, const void *data,
> +   int (*match)(struct device *, const void *))
> +{
> +   struct device *dev;
> +
> +   dev = class_find_device(fpga_region_class, start, data, match);
> +   if (!dev)
> +   return NULL;
> +
> +   return to_fpga_region(dev);
> +}
> +EXPORT_SYMBOL_GPL(fpga_region_class_find);
> +
>  static const struct of_device_id fpga_region_of_match[] = {
> { .compatible = "fpga-region", },
> {},
> @@ -51,14 +65,7 @@ static int fpga_region_of_node_match(struct device *dev, 
> const void *data)
>   */
>  static struct fpga_region *of_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)
> -   return NULL;
> -
> -   return to_fpga_region(dev);
> +   return fpga_region_class_find(NULL, np, fpga_region_of_node_match);
>  }
>
>  /**
> diff --git a/include/linux/fpga/fpga-region.h 
> b/include/linux/fpga/fpga-region.h
> index 35e7e09..4966bb2 100644
> --- a/include/linux/fpga/fpga-region.h
> +++ b/include/linux/fpga/fpga-region.h
> @@ -28,6 +28,10 @@ struct fpga_region {
>
>  #define to_fpga_region(d) container_of(d, struct fpga_region, dev)
>
> +struct fpga_region *fpga_region_class_find(
> +   struct device *start, const void *data,
> +   int (*match)(struct device *, const void *));
> +
>  int fpga_region_program_fpga(struct fpga_region *region,
>  struct fpga_image_info *image_info);
>
> --
> 2.7.4
>

Re: [PATCH v2 2/2] fpga: lattice machxo2: Add Lattice MachXO2 support

[Moritz Fischer]

Hi Paolo,

couple of nits inline, looks pretty good already.

On Mon, May 01, 2017 at 03:15:12PM +0200, Paolo Pisati wrote:
> This patch adds support to the FPGA manager for programming
> MachXO2 device’s internal flash memory, via slave SPI.
> 
> Signed-off-by: Paolo Pisati 
> ---
>  drivers/fpga/Kconfig   |   7 ++
>  drivers/fpga/Makefile  |   1 +
>  drivers/fpga/machxo2-spi.c | 214 
> +
>  3 files changed, 222 insertions(+)
>  create mode 100644 drivers/fpga/machxo2-spi.c
> 
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index c81cb7d..cce135b 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -26,6 +26,13 @@ config FPGA_MGR_ICE40_SPI
>   help
> FPGA manager driver support for Lattice iCE40 FPGAs over SPI.
>  
> +config FPGA_MGR_MACHXO2_SPI
> + tristate "Lattice MachXO2 SPI"
> + depends on SPI
> + help
> +  FPGA manager driver support for Lattice MachXO2 configuration
> +  over slave SPI interface.
> +
>  config FPGA_MGR_SOCFPGA
>   tristate "Altera SOCFPGA FPGA Manager"
>   depends on ARCH_SOCFPGA || COMPILE_TEST
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index c6f5d74..cdab1fe 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_ICE40_SPI) += ice40-spi.o
> +obj-$(CONFIG_FPGA_MGR_MACHXO2_SPI)   += machxo2-spi.o
>  obj-$(CONFIG_FPGA_MGR_SOCFPGA)   += socfpga.o
>  obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10)   += socfpga-a10.o
>  obj-$(CONFIG_FPGA_MGR_TS73XX)+= ts73xx-fpga.o
> diff --git a/drivers/fpga/machxo2-spi.c b/drivers/fpga/machxo2-spi.c
> new file mode 100644
> index 000..264ef63
> --- /dev/null
> +++ b/drivers/fpga/machxo2-spi.c
> @@ -0,0 +1,214 @@
> +/**
> + * Lattice MachXO2 Slave SPI Driver
> + *
> + * Copyright (C) 2017 Paolo Pisati 
> + *
> + * 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.
> + *
> + * Manage Lattice FPGA firmware that is loaded over SPI using
> + * the slave serial configuration interface.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* MachXO2 Programming Guide - sysCONFIG Programming Commands */
> +
> +#define ISC_ENABLE   0x08c6
> +#define ISC_ERASE0x040e
> +#define ISC_PROGRAMDONE  0x005e
> +#define LSC_CHECKBUSY0x00f0
> +#define LSC_INITADDRESS  0x0046
> +#define LSC_PROGINCRNV   0x0170
> +#define LSC_REFRESH  0x0079
> +
> +#define BUSYFLAG 0x80

Maybe BIT() macro?
> +
> +/*
> + * Max CCLK in Slave SPI mode according to 'MachXO2 Family Data
> + * Sheet' sysCONFIG Port Timing Specifications (3-36)
> + */
> +#define MACHXO2_MAX_SPEED6600
> +
> +#define MACHXO2_LOW_DELAY5   /* us */
> +#define MACHXO2_HIGH_DELAY   200 /* us */
> +
> +#define MACHXO2_OP_SIZE  sizeof(u32)
> +#define MACHXO2_PAGE_SIZE16
> +#define MACHXO2_BUF_SIZE (MACHXO2_OP_SIZE + MACHXO2_PAGE_SIZE)
> +
> +static int wait_until_not_busy(struct spi_device *spi)
> +{
> + u8 rx;
> + u32 checkbusy = LSC_CHECKBUSY;
> + int ret;
> +
> + do {
> + ret = spi_write_then_read(spi, , MACHXO2_OP_SIZE,
> +   , sizeof(rx));
> + if (ret)
> + return ret;
> + } while (rx & BUSYFLAG);
> +
> + return 0;
> +}
> +
> +static enum fpga_mgr_states machxo2_spi_state(struct fpga_manager *mgr)
> +{
> + return FPGA_MGR_STATE_UNKNOWN;
> +}
> +
> +static int machxo2_write_init(struct fpga_manager *mgr,
> +   struct fpga_image_info *info,
> +   const char *buf, size_t count)
> +{
> + struct spi_device *spi = mgr->priv;
> + u32 enable = ISC_ENABLE;
> + u32 erase = ISC_ERASE;
> + u32 initaddr = LSC_INITADDRESS;
> + int ret;
> +
> + if ((info->flags & FPGA_MGR_PARTIAL_RECONFIG)) {
> + dev_err(>dev,
> + "Partial reconfiguration is not supported\n");
> + return -ENOTSUPP;
> + }
> +
> + ret = spi_write(spi, , MACHXO2_OP_SIZE);
> + if (ret)
> + goto fail;
> +
> + udelay(MACHXO2_LOW_DELAY);

Does this have to be a delay, or can this be a sleep?
Can you maybe make the whole thing a chain of transactions
making use of spi_message_init() and trans.delay_usecs?

> + ret = spi_write(spi, , MACHXO2_OP_SIZE);
> + if (ret)
> + goto fail;
> +
> + ret = wait_until_not_busy(spi);
> + if (ret)
> + goto fail;
> +
> + ret = spi_write(spi, , MACHXO2_OP_SIZE);
> 

Re: [PATCH v2 2/2] fpga: lattice machxo2: Add Lattice MachXO2 support

[Moritz Fischer]

Hi Paolo,

couple of nits inline, looks pretty good already.

On Mon, May 01, 2017 at 03:15:12PM +0200, Paolo Pisati wrote:
> This patch adds support to the FPGA manager for programming
> MachXO2 device’s internal flash memory, via slave SPI.
> 
> Signed-off-by: Paolo Pisati 
> ---
>  drivers/fpga/Kconfig   |   7 ++
>  drivers/fpga/Makefile  |   1 +
>  drivers/fpga/machxo2-spi.c | 214 
> +
>  3 files changed, 222 insertions(+)
>  create mode 100644 drivers/fpga/machxo2-spi.c
> 
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index c81cb7d..cce135b 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -26,6 +26,13 @@ config FPGA_MGR_ICE40_SPI
>   help
> FPGA manager driver support for Lattice iCE40 FPGAs over SPI.
>  
> +config FPGA_MGR_MACHXO2_SPI
> + tristate "Lattice MachXO2 SPI"
> + depends on SPI
> + help
> +  FPGA manager driver support for Lattice MachXO2 configuration
> +  over slave SPI interface.
> +
>  config FPGA_MGR_SOCFPGA
>   tristate "Altera SOCFPGA FPGA Manager"
>   depends on ARCH_SOCFPGA || COMPILE_TEST
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index c6f5d74..cdab1fe 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_ICE40_SPI) += ice40-spi.o
> +obj-$(CONFIG_FPGA_MGR_MACHXO2_SPI)   += machxo2-spi.o
>  obj-$(CONFIG_FPGA_MGR_SOCFPGA)   += socfpga.o
>  obj-$(CONFIG_FPGA_MGR_SOCFPGA_A10)   += socfpga-a10.o
>  obj-$(CONFIG_FPGA_MGR_TS73XX)+= ts73xx-fpga.o
> diff --git a/drivers/fpga/machxo2-spi.c b/drivers/fpga/machxo2-spi.c
> new file mode 100644
> index 000..264ef63
> --- /dev/null
> +++ b/drivers/fpga/machxo2-spi.c
> @@ -0,0 +1,214 @@
> +/**
> + * Lattice MachXO2 Slave SPI Driver
> + *
> + * Copyright (C) 2017 Paolo Pisati 
> + *
> + * 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.
> + *
> + * Manage Lattice FPGA firmware that is loaded over SPI using
> + * the slave serial configuration interface.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* MachXO2 Programming Guide - sysCONFIG Programming Commands */
> +
> +#define ISC_ENABLE   0x08c6
> +#define ISC_ERASE0x040e
> +#define ISC_PROGRAMDONE  0x005e
> +#define LSC_CHECKBUSY0x00f0
> +#define LSC_INITADDRESS  0x0046
> +#define LSC_PROGINCRNV   0x0170
> +#define LSC_REFRESH  0x0079
> +
> +#define BUSYFLAG 0x80

Maybe BIT() macro?
> +
> +/*
> + * Max CCLK in Slave SPI mode according to 'MachXO2 Family Data
> + * Sheet' sysCONFIG Port Timing Specifications (3-36)
> + */
> +#define MACHXO2_MAX_SPEED6600
> +
> +#define MACHXO2_LOW_DELAY5   /* us */
> +#define MACHXO2_HIGH_DELAY   200 /* us */
> +
> +#define MACHXO2_OP_SIZE  sizeof(u32)
> +#define MACHXO2_PAGE_SIZE16
> +#define MACHXO2_BUF_SIZE (MACHXO2_OP_SIZE + MACHXO2_PAGE_SIZE)
> +
> +static int wait_until_not_busy(struct spi_device *spi)
> +{
> + u8 rx;
> + u32 checkbusy = LSC_CHECKBUSY;
> + int ret;
> +
> + do {
> + ret = spi_write_then_read(spi, , MACHXO2_OP_SIZE,
> +   , sizeof(rx));
> + if (ret)
> + return ret;
> + } while (rx & BUSYFLAG);
> +
> + return 0;
> +}
> +
> +static enum fpga_mgr_states machxo2_spi_state(struct fpga_manager *mgr)
> +{
> + return FPGA_MGR_STATE_UNKNOWN;
> +}
> +
> +static int machxo2_write_init(struct fpga_manager *mgr,
> +   struct fpga_image_info *info,
> +   const char *buf, size_t count)
> +{
> + struct spi_device *spi = mgr->priv;
> + u32 enable = ISC_ENABLE;
> + u32 erase = ISC_ERASE;
> + u32 initaddr = LSC_INITADDRESS;
> + int ret;
> +
> + if ((info->flags & FPGA_MGR_PARTIAL_RECONFIG)) {
> + dev_err(>dev,
> + "Partial reconfiguration is not supported\n");
> + return -ENOTSUPP;
> + }
> +
> + ret = spi_write(spi, , MACHXO2_OP_SIZE);
> + if (ret)
> + goto fail;
> +
> + udelay(MACHXO2_LOW_DELAY);

Does this have to be a delay, or can this be a sleep?
Can you maybe make the whole thing a chain of transactions
making use of spi_message_init() and trans.delay_usecs?

> + ret = spi_write(spi, , MACHXO2_OP_SIZE);
> + if (ret)
> + goto fail;
> +
> + ret = wait_until_not_busy(spi);
> + if (ret)
> + goto fail;
> +
> + ret = spi_write(spi, , MACHXO2_OP_SIZE);
> + if (ret)
> + goto 

Re: [PATCH 0/2] DS1374 Watchdog fixes

[Moritz Fischer]

On Tue, Apr 25, 2017 at 01:22:10PM -0700, Guenter Roeck wrote:
> On Tue, Apr 25, 2017 at 12:58:36PM -0700, Moritz Fischer wrote:
> > On Tue, Apr 25, 2017 at 09:58:24AM -0700, Guenter Roeck wrote:
> > 
> > > Ah, I missed the "n" in various #ifndef statements.
> > >
> > > I can't really comment on how to solve that; I simply don't know.
> > > Also, even with a dt property, it still would be necessary to have
> > > a non-DT means to configure one or the other. Making whatever solution
> > > backward compatible also seems tricky; I don't have a solution for that
> > > problem either.
> > 
> > How does one do these things in a non-dt context? Platform data? I'd let
> 
> Platform data is out of favor. You'd probably want to use device properties
> (see drivers/base/property.c). Question though is if this is considered
> configuration, hardware description, or both. Presumably the watchdog
> only makes sense if the reset signal is wired, and the alarm only makes
> sense if the interrupt is wired, but what if both are wired ?

To make things worse you can even remap the reset output to the INT pin
(which my platform does).

I'll look at device properties. Thanks for the pointer.

> 
> > the MFD select the 'mode'. Maybe being backwards compatible isn't
> > possible in any case. Is there a rule somewhere that we guarantee you'll
> > never have to change your CONFIG_FOO options?
> > 
> 
> That would be nice, but no, there is no such rule. You can probably argue
> that no published kernel configuration enables the watchdog flag,
> so there is nothing to be concerned about.

Alright, cool. Thanks

Moritz

PS: Haven't forgotten about the cros-ec-hwmon patch that I sent out ...


signature.asc
Description: PGP signature

Re: [PATCH 0/2] DS1374 Watchdog fixes

[Moritz Fischer]

On Tue, Apr 25, 2017 at 01:22:10PM -0700, Guenter Roeck wrote:
> On Tue, Apr 25, 2017 at 12:58:36PM -0700, Moritz Fischer wrote:
> > On Tue, Apr 25, 2017 at 09:58:24AM -0700, Guenter Roeck wrote:
> > 
> > > Ah, I missed the "n" in various #ifndef statements.
> > >
> > > I can't really comment on how to solve that; I simply don't know.
> > > Also, even with a dt property, it still would be necessary to have
> > > a non-DT means to configure one or the other. Making whatever solution
> > > backward compatible also seems tricky; I don't have a solution for that
> > > problem either.
> > 
> > How does one do these things in a non-dt context? Platform data? I'd let
> 
> Platform data is out of favor. You'd probably want to use device properties
> (see drivers/base/property.c). Question though is if this is considered
> configuration, hardware description, or both. Presumably the watchdog
> only makes sense if the reset signal is wired, and the alarm only makes
> sense if the interrupt is wired, but what if both are wired ?

To make things worse you can even remap the reset output to the INT pin
(which my platform does).

I'll look at device properties. Thanks for the pointer.

> 
> > the MFD select the 'mode'. Maybe being backwards compatible isn't
> > possible in any case. Is there a rule somewhere that we guarantee you'll
> > never have to change your CONFIG_FOO options?
> > 
> 
> That would be nice, but no, there is no such rule. You can probably argue
> that no published kernel configuration enables the watchdog flag,
> so there is nothing to be concerned about.

Alright, cool. Thanks

Moritz

PS: Haven't forgotten about the cros-ec-hwmon patch that I sent out ...


signature.asc
Description: PGP signature

Re: [PATCH 0/2] DS1374 Watchdog fixes

[Moritz Fischer]

On Tue, Apr 25, 2017 at 09:58:24AM -0700, Guenter Roeck wrote:

> Ah, I missed the "n" in various #ifndef statements.
>
> I can't really comment on how to solve that; I simply don't know.
> Also, even with a dt property, it still would be necessary to have
> a non-DT means to configure one or the other. Making whatever solution
> backward compatible also seems tricky; I don't have a solution for that
> problem either.

How does one do these things in a non-dt context? Platform data? I'd let
the MFD select the 'mode'. Maybe being backwards compatible isn't
possible in any case. Is there a rule somewhere that we guarantee you'll
never have to change your CONFIG_FOO options?

>
> > > > The idea was to fix what's broken currently (this patchset) and then 
> > > > refactor.
> > > > But if you prefer I can do all in one go instead.
> > > >
> > >
> > > It just seemed a waste to me to change/fix a function which is going to
> > > be removed in a subsequent patch (I seem to recall that there was a fix
> > > to the ioctl function).
> > >
> >
> > I'd say that it depends on whether you want to backport the fixes to the
> > stable kernels. Backporting the full rework is probably riskier.

I suck at communicating these days. But yeah. That was basically my
concern when I split it up into 'Fixes' and 'Rework'.

Mostly since the rework might take a couple of rounds of review, while the
fix can unbrick stuff (might still need review of course)

Cheers,

Moritz

Re: [PATCH 0/2] DS1374 Watchdog fixes

[Moritz Fischer]

On Tue, Apr 25, 2017 at 09:58:24AM -0700, Guenter Roeck wrote:

> Ah, I missed the "n" in various #ifndef statements.
>
> I can't really comment on how to solve that; I simply don't know.
> Also, even with a dt property, it still would be necessary to have
> a non-DT means to configure one or the other. Making whatever solution
> backward compatible also seems tricky; I don't have a solution for that
> problem either.

How does one do these things in a non-dt context? Platform data? I'd let
the MFD select the 'mode'. Maybe being backwards compatible isn't
possible in any case. Is there a rule somewhere that we guarantee you'll
never have to change your CONFIG_FOO options?

>
> > > > The idea was to fix what's broken currently (this patchset) and then 
> > > > refactor.
> > > > But if you prefer I can do all in one go instead.
> > > >
> > >
> > > It just seemed a waste to me to change/fix a function which is going to
> > > be removed in a subsequent patch (I seem to recall that there was a fix
> > > to the ioctl function).
> > >
> >
> > I'd say that it depends on whether you want to backport the fixes to the
> > stable kernels. Backporting the full rework is probably riskier.

I suck at communicating these days. But yeah. That was basically my
concern when I split it up into 'Fixes' and 'Rework'.

Mostly since the rework might take a couple of rounds of review, while the
fix can unbrick stuff (might still need review of course)

Cheers,

Moritz

[PATCH] spi: cadence: Allow for GPIO pins to be used as chipselects

[Moritz Fischer]

This adds support for using GPIOs for chipselects as described by the
default dt-bindings.

Signed-off-by: Moritz Fischer <m...@kernel.org>
---

Hi Mark,

I've tested this on my Zynq-7000 based system with
GPIO and non-gpio based chipselects mixed.

Thanks for your time,

Moritz

---
 drivers/spi/spi-cadence.c | 65 +++
 1 file changed, 65 insertions(+)

diff --git a/drivers/spi/spi-cadence.c b/drivers/spi/spi-cadence.c
index 1c57ce6..f0b5c7b 100644
--- a/drivers/spi/spi-cadence.c
+++ b/drivers/spi/spi-cadence.c
@@ -13,6 +13,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -127,6 +128,10 @@ struct cdns_spi {
u32 is_decoded_cs;
 };
 
+struct cdns_spi_device_data {
+   bool gpio_requested;
+};
+
 /* Macros for the SPI controller read/write */
 static inline u32 cdns_spi_read(struct cdns_spi *xspi, u32 offset)
 {
@@ -456,6 +461,64 @@ static int cdns_unprepare_transfer_hardware(struct 
spi_master *master)
return 0;
 }
 
+static int cdns_spi_setup(struct spi_device *spi)
+{
+
+   int ret = -EINVAL;
+   struct cdns_spi_device_data *cdns_spi_data = spi_get_ctldata(spi);
+
+   /* this is a pin managed by the controller, leave it alone */
+   if (spi->cs_gpio == -ENOENT)
+   return 0;
+
+   /* this seems to be the first time we're here */
+   if (!cdns_spi_data) {
+   cdns_spi_data = kzalloc(sizeof(*cdns_spi_data), GFP_KERNEL);
+   if (!cdns_spi_data)
+   return -ENOMEM;
+   cdns_spi_data->gpio_requested = false;
+   spi_set_ctldata(spi, cdns_spi_data);
+   }
+
+   /* if we haven't done so, grab the gpio */
+   if (!cdns_spi_data->gpio_requested && gpio_is_valid(spi->cs_gpio)) {
+   ret = gpio_request_one(spi->cs_gpio,
+  (spi->mode & SPI_CS_HIGH) ?
+  GPIOF_OUT_INIT_LOW : GPIOF_OUT_INIT_HIGH,
+  dev_name(>dev));
+   if (ret)
+   dev_err(>dev, "can't request chipselect gpio %d\n",
+   spi->cs_gpio);
+   else
+   cdns_spi_data->gpio_requested = true;
+   } else {
+   if (gpio_is_valid(spi->cs_gpio)) {
+   int mode = ((spi->mode & SPI_CS_HIGH) ?
+   GPIOF_OUT_INIT_LOW : GPIOF_OUT_INIT_HIGH);
+
+   ret = gpio_direction_output(spi->cs_gpio, mode);
+   if (ret)
+   dev_err(>dev, "chipselect gpio %d setup 
failed (%d)\n",
+   spi->cs_gpio, ret);
+   }
+   }
+
+   return ret;
+}
+
+static void cdns_spi_cleanup(struct spi_device *spi)
+{
+   struct cdns_spi_device_data *cdns_spi_data = spi_get_ctldata(spi);
+
+   if (cdns_spi_data) {
+   if (cdns_spi_data->gpio_requested)
+   gpio_free(spi->cs_gpio);
+   kfree(cdns_spi_data);
+   spi_set_ctldata(spi, NULL);
+   }
+
+}
+
 /**
  * cdns_spi_probe - Probe method for the SPI driver
  * @pdev:  Pointer to the platform_device structure
@@ -555,6 +618,8 @@ static int cdns_spi_probe(struct platform_device *pdev)
master->transfer_one = cdns_transfer_one;
master->unprepare_transfer_hardware = cdns_unprepare_transfer_hardware;
master->set_cs = cdns_spi_chipselect;
+   master->setup = cdns_spi_setup;
+   master->cleanup = cdns_spi_cleanup;
master->auto_runtime_pm = true;
master->mode_bits = SPI_CPOL | SPI_CPHA;
 
-- 
2.7.4

[PATCH] spi: cadence: Allow for GPIO pins to be used as chipselects

[Moritz Fischer]

This adds support for using GPIOs for chipselects as described by the
default dt-bindings.

Signed-off-by: Moritz Fischer 
---

Hi Mark,

I've tested this on my Zynq-7000 based system with
GPIO and non-gpio based chipselects mixed.

Thanks for your time,

Moritz

---
 drivers/spi/spi-cadence.c | 65 +++
 1 file changed, 65 insertions(+)

diff --git a/drivers/spi/spi-cadence.c b/drivers/spi/spi-cadence.c
index 1c57ce6..f0b5c7b 100644
--- a/drivers/spi/spi-cadence.c
+++ b/drivers/spi/spi-cadence.c
@@ -13,6 +13,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -127,6 +128,10 @@ struct cdns_spi {
u32 is_decoded_cs;
 };
 
+struct cdns_spi_device_data {
+   bool gpio_requested;
+};
+
 /* Macros for the SPI controller read/write */
 static inline u32 cdns_spi_read(struct cdns_spi *xspi, u32 offset)
 {
@@ -456,6 +461,64 @@ static int cdns_unprepare_transfer_hardware(struct 
spi_master *master)
return 0;
 }
 
+static int cdns_spi_setup(struct spi_device *spi)
+{
+
+   int ret = -EINVAL;
+   struct cdns_spi_device_data *cdns_spi_data = spi_get_ctldata(spi);
+
+   /* this is a pin managed by the controller, leave it alone */
+   if (spi->cs_gpio == -ENOENT)
+   return 0;
+
+   /* this seems to be the first time we're here */
+   if (!cdns_spi_data) {
+   cdns_spi_data = kzalloc(sizeof(*cdns_spi_data), GFP_KERNEL);
+   if (!cdns_spi_data)
+   return -ENOMEM;
+   cdns_spi_data->gpio_requested = false;
+   spi_set_ctldata(spi, cdns_spi_data);
+   }
+
+   /* if we haven't done so, grab the gpio */
+   if (!cdns_spi_data->gpio_requested && gpio_is_valid(spi->cs_gpio)) {
+   ret = gpio_request_one(spi->cs_gpio,
+  (spi->mode & SPI_CS_HIGH) ?
+  GPIOF_OUT_INIT_LOW : GPIOF_OUT_INIT_HIGH,
+  dev_name(>dev));
+   if (ret)
+   dev_err(>dev, "can't request chipselect gpio %d\n",
+   spi->cs_gpio);
+   else
+   cdns_spi_data->gpio_requested = true;
+   } else {
+   if (gpio_is_valid(spi->cs_gpio)) {
+   int mode = ((spi->mode & SPI_CS_HIGH) ?
+   GPIOF_OUT_INIT_LOW : GPIOF_OUT_INIT_HIGH);
+
+   ret = gpio_direction_output(spi->cs_gpio, mode);
+   if (ret)
+   dev_err(>dev, "chipselect gpio %d setup 
failed (%d)\n",
+   spi->cs_gpio, ret);
+   }
+   }
+
+   return ret;
+}
+
+static void cdns_spi_cleanup(struct spi_device *spi)
+{
+   struct cdns_spi_device_data *cdns_spi_data = spi_get_ctldata(spi);
+
+   if (cdns_spi_data) {
+   if (cdns_spi_data->gpio_requested)
+   gpio_free(spi->cs_gpio);
+   kfree(cdns_spi_data);
+   spi_set_ctldata(spi, NULL);
+   }
+
+}
+
 /**
  * cdns_spi_probe - Probe method for the SPI driver
  * @pdev:  Pointer to the platform_device structure
@@ -555,6 +618,8 @@ static int cdns_spi_probe(struct platform_device *pdev)
master->transfer_one = cdns_transfer_one;
master->unprepare_transfer_hardware = cdns_unprepare_transfer_hardware;
master->set_cs = cdns_spi_chipselect;
+   master->setup = cdns_spi_setup;
+   master->cleanup = cdns_spi_cleanup;
master->auto_runtime_pm = true;
master->mode_bits = SPI_CPOL | SPI_CPHA;
 
-- 
2.7.4

Re: [PATCH 0/2] DS1374 Watchdog fixes

[Moritz Fischer]

Hi Guenter,

On Mon, Apr 24, 2017 at 10:03 PM, Guenter Roeck <li...@roeck-us.net> wrote:
> On 04/24/2017 03:05 PM, Moritz Fischer wrote:

>> I'm very unhappy with the CONFIG_DRV_RTC_DS1374_WDT way of enabling
>> the watchdog behavior and currently I'm investigating how to make
>> that work via DT.
>>
>> Watchdog maintainers, do you have an idea on how to do that in a
>> non breaking fashion?
>>
>
> Depends on what you mean with "non breaking". Just using the normal mfd
> mechanisms, ie define an mfd cell for each client driver, should work.
> Do you see any problems with that ? Either case, that doesn't seem
> to be a watchdog driver problem, or am I missing something ?

Well so currently watchdog behavior is selected (out of the two options alarm,
or watchdog) by enabling the configuration option mentioned above.
If I change this over to use a dt-based approach like dallas,ds1374-mode = <2>;
to select the behavior in the mfd for example, won't that break people that
relied on the old behavior? If everyone involved is ok with that, I'm happy
to just add it to the binding.

> I don't really see the point of doing that if you plan to move the watchdog
> part of the driver into the watchdog directory. We for sure won't accept a
> watchdog driver that does not use the watchdog infrastructure.

The idea was to fix what's broken currently (this patchset) and then refactor.
But if you prefer I can do all in one go instead.

>
> Regarding
> +   /* WHY? */
> +   ds1374->wdd.timeout = t;
>
> Assuming you mean why the driver has to set the timeout value - not every
> watchdog hardware supports timeouts in multiples of 1 second. The driver
> is expected to set the value to the real timeout, not to the timeout asked
> for by the infrastructure.

Yeah that branch is work in progress and needs cleanup. Leftover from testing,
before I had understood why. Branch needs cleanup. It also doesn't really use
regmap_update_bits etc.

Thanks for the explanation,

Moritz

Re: [PATCH 0/2] DS1374 Watchdog fixes

[Moritz Fischer]

Hi Guenter,

On Mon, Apr 24, 2017 at 10:03 PM, Guenter Roeck  wrote:
> On 04/24/2017 03:05 PM, Moritz Fischer wrote:

>> I'm very unhappy with the CONFIG_DRV_RTC_DS1374_WDT way of enabling
>> the watchdog behavior and currently I'm investigating how to make
>> that work via DT.
>>
>> Watchdog maintainers, do you have an idea on how to do that in a
>> non breaking fashion?
>>
>
> Depends on what you mean with "non breaking". Just using the normal mfd
> mechanisms, ie define an mfd cell for each client driver, should work.
> Do you see any problems with that ? Either case, that doesn't seem
> to be a watchdog driver problem, or am I missing something ?

Well so currently watchdog behavior is selected (out of the two options alarm,
or watchdog) by enabling the configuration option mentioned above.
If I change this over to use a dt-based approach like dallas,ds1374-mode = <2>;
to select the behavior in the mfd for example, won't that break people that
relied on the old behavior? If everyone involved is ok with that, I'm happy
to just add it to the binding.

> I don't really see the point of doing that if you plan to move the watchdog
> part of the driver into the watchdog directory. We for sure won't accept a
> watchdog driver that does not use the watchdog infrastructure.

The idea was to fix what's broken currently (this patchset) and then refactor.
But if you prefer I can do all in one go instead.

>
> Regarding
> +   /* WHY? */
> +   ds1374->wdd.timeout = t;
>
> Assuming you mean why the driver has to set the timeout value - not every
> watchdog hardware supports timeouts in multiples of 1 second. The driver
> is expected to set the value to the real timeout, not to the timeout asked
> for by the infrastructure.

Yeah that branch is work in progress and needs cleanup. Leftover from testing,
before I had understood why. Branch needs cleanup. It also doesn't really use
regmap_update_bits etc.

Thanks for the explanation,

Moritz

[PATCH 1/2] rtc: ds1374: wdt: Fix issue with timeout scaling from secs to wdt ticks

[Moritz Fischer]

Fix commit 920f91e50c5b ("drivers/rtc/rtc-ds1374.c: add watchdog support")

The issue is that the internal counter that triggers the watchdog reset
is actually running at 4096 Hz instead of 1Hz, therefore the value
given by userland (in sec) needs to be multiplied by 4096 to get the
correct behavior.

Signed-off-by: Moritz Fischer <m...@kernel.org>
---
 drivers/rtc/rtc-ds1374.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-ds1374.c b/drivers/rtc/rtc-ds1374.c
index 4cd115e..2a8b5b3 100644
--- a/drivers/rtc/rtc-ds1374.c
+++ b/drivers/rtc/rtc-ds1374.c
@@ -525,6 +525,10 @@ static long ds1374_wdt_ioctl(struct file *file, unsigned 
int cmd,
if (get_user(new_margin, (int __user *)arg))
return -EFAULT;
 
+   /* the hardware's tick rate is 4096 Hz, so
+* the counter value needs to be scaled accordingly
+*/
+   new_margin <<= 12;
if (new_margin < 1 || new_margin > 16777216)
return -EINVAL;
 
@@ -533,7 +537,8 @@ static long ds1374_wdt_ioctl(struct file *file, unsigned 
int cmd,
ds1374_wdt_ping();
/* fallthrough */
case WDIOC_GETTIMEOUT:
-   return put_user(wdt_margin, (int __user *)arg);
+   /* when returning ... inverse is true */
+   return put_user((wdt_margin >> 12), (int __user *)arg);
case WDIOC_SETOPTIONS:
if (copy_from_user(, (int __user *)arg, sizeof(int)))
return -EFAULT;
-- 
2.7.4

[PATCH 1/2] rtc: ds1374: wdt: Fix issue with timeout scaling from secs to wdt ticks

[Moritz Fischer]

Fix commit 920f91e50c5b ("drivers/rtc/rtc-ds1374.c: add watchdog support")

The issue is that the internal counter that triggers the watchdog reset
is actually running at 4096 Hz instead of 1Hz, therefore the value
given by userland (in sec) needs to be multiplied by 4096 to get the
correct behavior.

Signed-off-by: Moritz Fischer 
---
 drivers/rtc/rtc-ds1374.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-ds1374.c b/drivers/rtc/rtc-ds1374.c
index 4cd115e..2a8b5b3 100644
--- a/drivers/rtc/rtc-ds1374.c
+++ b/drivers/rtc/rtc-ds1374.c
@@ -525,6 +525,10 @@ static long ds1374_wdt_ioctl(struct file *file, unsigned 
int cmd,
if (get_user(new_margin, (int __user *)arg))
return -EFAULT;
 
+   /* the hardware's tick rate is 4096 Hz, so
+* the counter value needs to be scaled accordingly
+*/
+   new_margin <<= 12;
if (new_margin < 1 || new_margin > 16777216)
return -EINVAL;
 
@@ -533,7 +537,8 @@ static long ds1374_wdt_ioctl(struct file *file, unsigned 
int cmd,
ds1374_wdt_ping();
/* fallthrough */
case WDIOC_GETTIMEOUT:
-   return put_user(wdt_margin, (int __user *)arg);
+   /* when returning ... inverse is true */
+   return put_user((wdt_margin >> 12), (int __user *)arg);
case WDIOC_SETOPTIONS:
if (copy_from_user(, (int __user *)arg, sizeof(int)))
return -EFAULT;
-- 
2.7.4

[PATCH 0/2] DS1374 Watchdog fixes

[Moritz Fischer]

Hi all,

this series fixes two issues that I ran into when trying to use the
watchdog part of the DS1374 on of our products.

This series is basically a precursor to some further cleanup work,
that turns the DS1374 into a MFD device with an RTC and WDT in
separate drivers [1] each integrated in either the watchdog and
the rtc frameworks.

I'm very unhappy with the CONFIG_DRV_RTC_DS1374_WDT way of enabling
the watchdog behavior and currently I'm investigating how to make
that work via DT.

Watchdog maintainers, do you have an idea on how to do that in a
non breaking fashion?

Thanks,
Moritz

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/mdf/linux.git/log/?h=wip/mfd-ds1374-rfc

Moritz Fischer (2):
  rtc: ds1374: wdt: Fix issue with timeout scaling from secs to wdt
ticks
  rtc: ds1374: wdt: Fix stop/start ioctl always returning -EINVAL

 drivers/rtc/rtc-ds1374.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

-- 
2.7.4

[PATCH 2/2] rtc: ds1374: wdt: Fix stop/start ioctl always returning -EINVAL

[Moritz Fischer]

Fix commit 920f91e50c5b ("drivers/rtc/rtc-ds1374.c: add watchdog support")

The WDIOC_SETOPTIONS case in the watchdog ioctl would alwayss falls
through to the -EINVAL case. This is wrong since thew watchdog does
actually get stopped or started correctly.

Signed-off-by: Moritz Fischer <m...@kernel.org>
---
 drivers/rtc/rtc-ds1374.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-ds1374.c b/drivers/rtc/rtc-ds1374.c
index 2a8b5b3..38a2e9e 100644
--- a/drivers/rtc/rtc-ds1374.c
+++ b/drivers/rtc/rtc-ds1374.c
@@ -546,14 +546,15 @@ static long ds1374_wdt_ioctl(struct file *file, unsigned 
int cmd,
if (options & WDIOS_DISABLECARD) {
pr_info("disable watchdog\n");
ds1374_wdt_disable();
+   return 0;
}
 
if (options & WDIOS_ENABLECARD) {
pr_info("enable watchdog\n");
ds1374_wdt_settimeout(wdt_margin);
ds1374_wdt_ping();
+   return 0;
}
-
return -EINVAL;
}
return -ENOTTY;
-- 
2.7.4

[PATCH 2/2] rtc: ds1374: wdt: Fix stop/start ioctl always returning -EINVAL

[Moritz Fischer]

Fix commit 920f91e50c5b ("drivers/rtc/rtc-ds1374.c: add watchdog support")

The WDIOC_SETOPTIONS case in the watchdog ioctl would alwayss falls
through to the -EINVAL case. This is wrong since thew watchdog does
actually get stopped or started correctly.

Signed-off-by: Moritz Fischer 
---
 drivers/rtc/rtc-ds1374.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-ds1374.c b/drivers/rtc/rtc-ds1374.c
index 2a8b5b3..38a2e9e 100644
--- a/drivers/rtc/rtc-ds1374.c
+++ b/drivers/rtc/rtc-ds1374.c
@@ -546,14 +546,15 @@ static long ds1374_wdt_ioctl(struct file *file, unsigned 
int cmd,
if (options & WDIOS_DISABLECARD) {
pr_info("disable watchdog\n");
ds1374_wdt_disable();
+   return 0;
}
 
if (options & WDIOS_ENABLECARD) {
pr_info("enable watchdog\n");
ds1374_wdt_settimeout(wdt_margin);
ds1374_wdt_ping();
+   return 0;
}
-
return -EINVAL;
}
return -ENOTTY;
-- 
2.7.4

[PATCH 0/2] DS1374 Watchdog fixes

[Moritz Fischer]

Hi all,

this series fixes two issues that I ran into when trying to use the
watchdog part of the DS1374 on of our products.

This series is basically a precursor to some further cleanup work,
that turns the DS1374 into a MFD device with an RTC and WDT in
separate drivers [1] each integrated in either the watchdog and
the rtc frameworks.

I'm very unhappy with the CONFIG_DRV_RTC_DS1374_WDT way of enabling
the watchdog behavior and currently I'm investigating how to make
that work via DT.

Watchdog maintainers, do you have an idea on how to do that in a
non breaking fashion?

Thanks,
Moritz

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/mdf/linux.git/log/?h=wip/mfd-ds1374-rfc

Moritz Fischer (2):
  rtc: ds1374: wdt: Fix issue with timeout scaling from secs to wdt
ticks
  rtc: ds1374: wdt: Fix stop/start ioctl always returning -EINVAL

 drivers/rtc/rtc-ds1374.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

-- 
2.7.4

Re: [PATCH 2/3] dt-bindings: hwmon: Add bindings for Google Chromium EC HWMON

[Moritz Fischer]

On Fri, Apr 14, 2017 at 5:48 AM, Rob Herring <r...@kernel.org> wrote:
> On Thu, Apr 13, 2017 at 4:07 PM, Guenter Roeck <li...@roeck-us.net> wrote:
>> On Thu, Apr 13, 2017 at 03:01:40PM -0500, Rob Herring wrote:
>>> On Fri, Apr 07, 2017 at 03:00:09PM -0700, Moritz Fischer wrote:
>>> > From: Moritz Fischer <m...@kernel.org>
>>> >
>>> > Add bindings for the Chromium EC HWMON. The Chromium EC HWMON
>>> > allows monitoring of temperature sensors and fans attached to the
>>> > EC.
>>> >
>>> > Signed-off-by: Moritz Fischer <m...@kernel.org>
>>> > ---
>>> >  .../devicetree/bindings/hwmon/cros-ec-hwmon.txt| 25 
>>> > ++
>>> >  1 file changed, 25 insertions(+)
>>> >  create mode 100644 
>>> > Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt
>>> >
>>> > diff --git a/Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt 
>>> > b/Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt
>>> > new file mode 100644
>>> > index 000..4c94869
>>> > --- /dev/null
>>> > +++ b/Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt
>>> > @@ -0,0 +1,25 @@
>>> > +Chromium Embedded Controller EC temperature and fan control
>>> > +---
>>> > +
>>> > +Google's Chromium EC HWMON is a hwmon implemented byimplemented by the 
>>> > Chromium EC
>>> > +firmware attached to the Embedded Controller (EC) and controlled via a 
>>> > host-command
>>> > +interface.
>>> > +
>>> > +An EC HWMON node should be only found as a sub-node of the EC node (see
>>> > +Documentation/devicetree/bindings/mfd/cros-ec.txt).
>>> > +
>>> > +Required properties:
>>> > +- compatible: Must contain "google,cros-ec-hwmon"
>>> > +
>>> > +Example:
>>> > +   embedded-controller@1e {
>>> > +   reg = <0x1e>;
>>> > +   compatible = "google,cros-ec-i2c";
>>> > +   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
>>> > +   interrupt-parent = <>;
>>> > +
>>> > +   hwmon {
>>> > +   compatible = "google,cros-ec-hwmon";
>>>
>>> This is sufficient for all devices? I don't see that DT provides
>>> anything here other than instantiating a device, but the parent device
>>> can just as easily do that.
>>>
>> The parent driver (drivers/mfd/cros_ec_i2c.c) calls cros_ec_register(),
>> which uses uses of_platform_populate() to populate all sub-devices.
>> There are various examples in the dts files (look for "google,cros-ec").
>> Does it really make sense to start a second method for instantiating
>> sub-devices ?
>
> Okay, I suppose not. That wasn't clear from the example.

Do you want me to clarify that in the example somehow?

Moritz

Re: [PATCH 2/3] dt-bindings: hwmon: Add bindings for Google Chromium EC HWMON

[Moritz Fischer]

On Fri, Apr 14, 2017 at 5:48 AM, Rob Herring  wrote:
> On Thu, Apr 13, 2017 at 4:07 PM, Guenter Roeck  wrote:
>> On Thu, Apr 13, 2017 at 03:01:40PM -0500, Rob Herring wrote:
>>> On Fri, Apr 07, 2017 at 03:00:09PM -0700, Moritz Fischer wrote:
>>> > From: Moritz Fischer 
>>> >
>>> > Add bindings for the Chromium EC HWMON. The Chromium EC HWMON
>>> > allows monitoring of temperature sensors and fans attached to the
>>> > EC.
>>> >
>>> > Signed-off-by: Moritz Fischer 
>>> > ---
>>> >  .../devicetree/bindings/hwmon/cros-ec-hwmon.txt| 25 
>>> > ++
>>> >  1 file changed, 25 insertions(+)
>>> >  create mode 100644 
>>> > Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt
>>> >
>>> > diff --git a/Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt 
>>> > b/Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt
>>> > new file mode 100644
>>> > index 000..4c94869
>>> > --- /dev/null
>>> > +++ b/Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt
>>> > @@ -0,0 +1,25 @@
>>> > +Chromium Embedded Controller EC temperature and fan control
>>> > +---
>>> > +
>>> > +Google's Chromium EC HWMON is a hwmon implemented byimplemented by the 
>>> > Chromium EC
>>> > +firmware attached to the Embedded Controller (EC) and controlled via a 
>>> > host-command
>>> > +interface.
>>> > +
>>> > +An EC HWMON node should be only found as a sub-node of the EC node (see
>>> > +Documentation/devicetree/bindings/mfd/cros-ec.txt).
>>> > +
>>> > +Required properties:
>>> > +- compatible: Must contain "google,cros-ec-hwmon"
>>> > +
>>> > +Example:
>>> > +   embedded-controller@1e {
>>> > +   reg = <0x1e>;
>>> > +   compatible = "google,cros-ec-i2c";
>>> > +   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
>>> > +   interrupt-parent = <>;
>>> > +
>>> > +   hwmon {
>>> > +   compatible = "google,cros-ec-hwmon";
>>>
>>> This is sufficient for all devices? I don't see that DT provides
>>> anything here other than instantiating a device, but the parent device
>>> can just as easily do that.
>>>
>> The parent driver (drivers/mfd/cros_ec_i2c.c) calls cros_ec_register(),
>> which uses uses of_platform_populate() to populate all sub-devices.
>> There are various examples in the dts files (look for "google,cros-ec").
>> Does it really make sense to start a second method for instantiating
>> sub-devices ?
>
> Okay, I suppose not. That wasn't clear from the example.

Do you want me to clarify that in the example somehow?

Moritz

Re: [PATCH 1/3] mfd: cros-ec: Add functions to read mapped memory

[Moritz Fischer]

Hi Guenter,

On Thu, Apr 13, 2017 at 2:03 PM, Guenter Roeck <li...@roeck-us.net> wrote:
> On Fri, Apr 07, 2017 at 03:00:08PM -0700, Moritz Fischer wrote:
>> From: Moritz Fischer <m...@kernel.org>
>>
>> The ChromeOS EC has mapped memory regions where things like temperature
>> sensors and fan speed are stored. Provide access to those from the
>> cros-ec mfd device.
>>
>
> Turns out struct cros_ec_device already provides a cmd_readmem callback,
> which is widely used by other drivers. Why don't you just use it ?

This is only actually set by the lpc version of the cros_ec. I2C and
SPI connected ECs
emulate it. I can most certainly hook it up in the (spi,i2c) drivers,
but the implementation
for SPI and I2C needs to live somewhere. drivers/platform/chrome/cros_ec_proto.c
seemed to be a good place.

Thanks for the feedback!

Moritz

Re: [PATCH 1/3] mfd: cros-ec: Add functions to read mapped memory

[Moritz Fischer]

Hi Guenter,

On Thu, Apr 13, 2017 at 2:03 PM, Guenter Roeck  wrote:
> On Fri, Apr 07, 2017 at 03:00:08PM -0700, Moritz Fischer wrote:
>> From: Moritz Fischer 
>>
>> The ChromeOS EC has mapped memory regions where things like temperature
>> sensors and fan speed are stored. Provide access to those from the
>> cros-ec mfd device.
>>
>
> Turns out struct cros_ec_device already provides a cmd_readmem callback,
> which is widely used by other drivers. Why don't you just use it ?

This is only actually set by the lpc version of the cros_ec. I2C and
SPI connected ECs
emulate it. I can most certainly hook it up in the (spi,i2c) drivers,
but the implementation
for SPI and I2C needs to live somewhere. drivers/platform/chrome/cros_ec_proto.c
seemed to be a good place.

Thanks for the feedback!

Moritz

Re: [PATCH 00/16] Intel FPGA Device Drivers

[Moritz Fischer]

Hi Jerome,

On Wed, Apr 12, 2017 at 6:29 AM, Jerome Glisse  wrote:
> On Tue, Apr 11, 2017 at 12:38:10PM -0700, Luebbers, Enno wrote:
>> Hi Jerome,
>>
>> On Thu, Apr 06, 2017 at 04:27:00PM -0400, Jerome Glisse wrote:
>>
>> > Do we have an open source toolchain to generate the FPGA configuration
>> > (bitstream) ? As it is required for the GPU sub-system that any driver
>> > API must comes with open source userspace.

I think the comparison lacks. No one seems to be bothered by the fact
that the GPUs
hardware is built using closed source CAD tools, even if open source drivers are
available. From an OS perspective the FPGA is hardware.
(Reconfigurable) but hardware.

A better comparison from my point of view would be loading a binary
firmware image ...

>> As far as I know, no FPGA vendor currently provides an open-source version of
>> their FPGA synthesis tools - there are, however, free (as in beer) versions
>> available for download that can be used for generating FPGA bitstreams. Also,
>> there are a number of projects to replace parts of the vendor tools with open
>> alternatives (yosys comes to mind, which I believe recently added initial
>> support for synthesizing logic for Intel FPGAs).
>>
>> As an aside, we are also working on an open-source user-space library that 
>> would
>> allow you to use this driver to load existing accelerator bitstreams as well 
>> as
>> enumerate and access accelerators present in the system. This would enable
>> workflows where users have access to e.g. a library of FPGA accelerator
>> bitstreams and want to write applications that take advantage of these
>> accelerators, even without having access to an FPGA synthesis tool.
>
> Yosys is not an open source toolchain is use quartus at least that is my
> understand from this commit:
> https://github.com/cliffordwolf/yosys/commit/c27dcc1e47fa00cd415893c9d3f637a5d5865988
>
>
> It is like if on GPU we only had close source compiler for the GPU
> instructions set. So FPGA is definitly following different rules than
> open source upstream GPU kernel driver abides to.
>
> I see this as highly problematic if not only for security purposes
> there is no way for anyone to audit how secure and sane the API you
> want to expose to userspace. Those FPGA might have connection to
> memory bus or device bus and thus they might get access to any memory.

It's up to the user to plug a specific piece of hardware into their
machine. After that it is
up to the user to decide whether he wants to load a bitstream that he
doesn't have the
source code for and that he needs to compile with closed source software.
Do you know if NVIDIA has backdoors in their GPU, Intel in their NIC,
or AMD in their
processor? What about that RTC, do you have the source code they
synthesized their
ASIC design from?

Maybe my mental model on FPGAs is different from yours so feel free to
disagree ;-)

Moritz

Re: [PATCH 00/16] Intel FPGA Device Drivers

[Moritz Fischer]

Hi Jerome,

On Wed, Apr 12, 2017 at 6:29 AM, Jerome Glisse  wrote:
> On Tue, Apr 11, 2017 at 12:38:10PM -0700, Luebbers, Enno wrote:
>> Hi Jerome,
>>
>> On Thu, Apr 06, 2017 at 04:27:00PM -0400, Jerome Glisse wrote:
>>
>> > Do we have an open source toolchain to generate the FPGA configuration
>> > (bitstream) ? As it is required for the GPU sub-system that any driver
>> > API must comes with open source userspace.

I think the comparison lacks. No one seems to be bothered by the fact
that the GPUs
hardware is built using closed source CAD tools, even if open source drivers are
available. From an OS perspective the FPGA is hardware.
(Reconfigurable) but hardware.

A better comparison from my point of view would be loading a binary
firmware image ...

>> As far as I know, no FPGA vendor currently provides an open-source version of
>> their FPGA synthesis tools - there are, however, free (as in beer) versions
>> available for download that can be used for generating FPGA bitstreams. Also,
>> there are a number of projects to replace parts of the vendor tools with open
>> alternatives (yosys comes to mind, which I believe recently added initial
>> support for synthesizing logic for Intel FPGAs).
>>
>> As an aside, we are also working on an open-source user-space library that 
>> would
>> allow you to use this driver to load existing accelerator bitstreams as well 
>> as
>> enumerate and access accelerators present in the system. This would enable
>> workflows where users have access to e.g. a library of FPGA accelerator
>> bitstreams and want to write applications that take advantage of these
>> accelerators, even without having access to an FPGA synthesis tool.
>
> Yosys is not an open source toolchain is use quartus at least that is my
> understand from this commit:
> https://github.com/cliffordwolf/yosys/commit/c27dcc1e47fa00cd415893c9d3f637a5d5865988
>
>
> It is like if on GPU we only had close source compiler for the GPU
> instructions set. So FPGA is definitly following different rules than
> open source upstream GPU kernel driver abides to.
>
> I see this as highly problematic if not only for security purposes
> there is no way for anyone to audit how secure and sane the API you
> want to expose to userspace. Those FPGA might have connection to
> memory bus or device bus and thus they might get access to any memory.

It's up to the user to plug a specific piece of hardware into their
machine. After that it is
up to the user to decide whether he wants to load a bitstream that he
doesn't have the
source code for and that he needs to compile with closed source software.
Do you know if NVIDIA has backdoors in their GPU, Intel in their NIC,
or AMD in their
processor? What about that RTC, do you have the source code they
synthesized their
ASIC design from?

Maybe my mental model on FPGAs is different from yours so feel free to
disagree ;-)

Moritz

Re: [PATCH] fpga altera-hps2fpga: disable/unprepare clock on error in alt_fpga_bridge_probe()

[Moritz Fischer]

On Tue, Apr 11, 2017 at 09:53:38AM -0500, Alan Tull wrote:
> On Tue, Apr 11, 2017 at 4:22 AM, Tobias Klauser <tklau...@distanz.ch> wrote:
> 
> Hi Tobias,
> 
> Thanks!
> 
> > If either _alt_hps2fpga_enable_set() or fpga_bridge_register() fail in
> > alt_fpga_bridge_probe(), the clock remains enabled and prepared. Also,
> > in the error path for _alt_hps2fpga_enable_set() a call to
> > fpga_bridge_unregister() is made even though the bridge was not
> > registered yet.
> >
> > Remove the unnecessary call to fpga_bridge_unregister() and call
> > clk_disable_unprepare() in both error paths in order to make sure the
> > clock gets properly disabled and unprepared.
> >
> > Signed-off-by: Tobias Klauser <tklau...@distanz.ch>
> 
Acked-by: Moritz Fischer <m...@kernel.org>
> Signed-off-by: Alan Tull <at...@kernel.org>
> 
> > ---
> >  drivers/fpga/altera-hps2fpga.c | 15 +--
> >  1 file changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/fpga/altera-hps2fpga.c b/drivers/fpga/altera-hps2fpga.c
> > index 4b354c79be31..3066b805f2d0 100644
> > --- a/drivers/fpga/altera-hps2fpga.c
> > +++ b/drivers/fpga/altera-hps2fpga.c
> > @@ -181,15 +181,18 @@ static int alt_fpga_bridge_probe(struct 
> > platform_device *pdev)
> >  (enable ? "enabling" : "disabling"));
> >
> > ret = _alt_hps2fpga_enable_set(priv, enable);
> > -   if (ret) {
> > -   fpga_bridge_unregister(>dev);
> > -   return ret;
> > -   }
> > +   if (ret)
> > +   goto err;
> > }
> > }
> >
> > -   return fpga_bridge_register(dev, priv->name, 
> > _hps2fpga_br_ops,
> > -   priv);
> > +   ret = fpga_bridge_register(dev, priv->name, _hps2fpga_br_ops,
> > +  priv);
> > +err:
> > +   if (ret)
> > +   clk_disable_unprepare(priv->clk);
> > +
> > +   return ret;
> >  }
> >
> >  static int alt_fpga_bridge_remove(struct platform_device *pdev)
> > --
> > 2.12.2
> >
> >

Re: [PATCH] fpga altera-hps2fpga: disable/unprepare clock on error in alt_fpga_bridge_probe()

[Moritz Fischer]

On Tue, Apr 11, 2017 at 09:53:38AM -0500, Alan Tull wrote:
> On Tue, Apr 11, 2017 at 4:22 AM, Tobias Klauser  wrote:
> 
> Hi Tobias,
> 
> Thanks!
> 
> > If either _alt_hps2fpga_enable_set() or fpga_bridge_register() fail in
> > alt_fpga_bridge_probe(), the clock remains enabled and prepared. Also,
> > in the error path for _alt_hps2fpga_enable_set() a call to
> > fpga_bridge_unregister() is made even though the bridge was not
> > registered yet.
> >
> > Remove the unnecessary call to fpga_bridge_unregister() and call
> > clk_disable_unprepare() in both error paths in order to make sure the
> > clock gets properly disabled and unprepared.
> >
> > Signed-off-by: Tobias Klauser 
> 
Acked-by: Moritz Fischer 
> Signed-off-by: Alan Tull 
> 
> > ---
> >  drivers/fpga/altera-hps2fpga.c | 15 +--
> >  1 file changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/fpga/altera-hps2fpga.c b/drivers/fpga/altera-hps2fpga.c
> > index 4b354c79be31..3066b805f2d0 100644
> > --- a/drivers/fpga/altera-hps2fpga.c
> > +++ b/drivers/fpga/altera-hps2fpga.c
> > @@ -181,15 +181,18 @@ static int alt_fpga_bridge_probe(struct 
> > platform_device *pdev)
> >  (enable ? "enabling" : "disabling"));
> >
> > ret = _alt_hps2fpga_enable_set(priv, enable);
> > -   if (ret) {
> > -   fpga_bridge_unregister(>dev);
> > -   return ret;
> > -   }
> > +   if (ret)
> > +   goto err;
> > }
> > }
> >
> > -   return fpga_bridge_register(dev, priv->name, 
> > _hps2fpga_br_ops,
> > -   priv);
> > +   ret = fpga_bridge_register(dev, priv->name, _hps2fpga_br_ops,
> > +  priv);
> > +err:
> > +   if (ret)
> > +   clk_disable_unprepare(priv->clk);
> > +
> > +   return ret;
> >  }
> >
> >  static int alt_fpga_bridge_remove(struct platform_device *pdev)
> > --
> > 2.12.2
> >
> >

Re: [PATCH 1/3] mfd: cros-ec: Add functions to read mapped memory

[Moritz Fischer]

On Sun, Apr 09, 2017 at 04:02:04PM -0700, Guenter Roeck wrote:
> On 04/07/2017 03:00 PM, Moritz Fischer wrote:
> > From: Moritz Fischer <m...@kernel.org>
> >
> > The ChromeOS EC has mapped memory regions where things like temperature
> > sensors and fan speed are stored. Provide access to those from the
> > cros-ec mfd device.
> >
> > Signed-off-by: Moritz Fischer <m...@kernel.org>
>
> I'll have to consult with others at Google if this is a good idea.
> Benson, can you comment ?

Well to my knowledge the only other way to get to it is the 'ectool'
from userland
via ioctl calls. The other option would be IIO ...
>
> > ---
> >  drivers/platform/chrome/cros_ec_proto.c | 55 
> > +
> >  include/linux/mfd/cros_ec.h | 39 +++
> >  2 files changed, 94 insertions(+)
> >
> > diff --git a/drivers/platform/chrome/cros_ec_proto.c 
> > b/drivers/platform/chrome/cros_ec_proto.c
> > index ed5dee7..28063de 100644
> > --- a/drivers/platform/chrome/cros_ec_proto.c
> > +++ b/drivers/platform/chrome/cros_ec_proto.c
> > @@ -494,3 +494,58 @@ int cros_ec_get_next_event(struct cros_ec_device 
> > *ec_dev)
> >   return get_keyboard_state_event(ec_dev);
> >  }
> >  EXPORT_SYMBOL(cros_ec_get_next_event);
> > +
> > +static int __cros_ec_read_mapped_mem(struct cros_ec_device *ec, uint8_t 
> > offset,
> > + void *buf, size_t size)
> > +{
> > + int ret;
> > + struct ec_params_read_memmap *params;
> > + struct cros_ec_command *msg;
> > +
> > + msg = kzalloc(sizeof(*msg) + max(sizeof(*params), size), GFP_KERNEL);
> > + if (!msg)
> > + return -ENOMEM;
> > +
>
> I don't think using kzalloc here makes much sense. It is well known
> that size is <= 4, so using a local buffer should not be a problem.

Good point, that was basically copy & paste from other cros-ec code ;-)
I'll fix this.

>
> > + msg->version = 0;
> > + msg->command = EC_CMD_READ_MEMMAP;
> > + msg->insize = size;
> > + msg->outsize = sizeof(*params);
> > +
> > + params = (struct ec_params_read_memmap *)msg->data;
> > + params->offset = offset;
> > + params->size = size;
> > +
> > + ret = cros_ec_cmd_xfer(ec, msg);
> > + if (ret < 0 || msg->result != EC_RES_SUCCESS) {
>
> cros_ec_cmd_xfer_status() was introduced to be able to avoid the second check.
>

Alright, cool. Will fix this.

> > + dev_warn(ec->dev, "cannot read mapped reg: %d/%d\n",
> > + ret, msg->result);
> > + goto out_free;
> > + }
> > +
> > + memcpy(buf, msg->data, size);
> > +
> > +out_free:
> > + kfree(msg);
> > + return ret;
> > +}
> > +
> > +int cros_ec_read_mapped_mem32(struct cros_ec_device *ec, const uint8_t 
> > offset,
> > +  uint32_t *data)
> > +{
> > + return __cros_ec_read_mapped_mem(ec, offset, data, sizeof(*data));
> > +}
> > +EXPORT_SYMBOL_GPL(cros_ec_read_mapped_mem32);
> > +
> > +int cros_ec_read_mapped_mem16(struct cros_ec_device *ec, const uint8_t 
> > offset,
> > +  uint16_t *data)
> > +{
> > + return __cros_ec_read_mapped_mem(ec, offset, data, sizeof(*data));
> > +}
> > +EXPORT_SYMBOL_GPL(cros_ec_read_mapped_mem16);
> > +
>
> Either case, this assumes that EC endianness matches host endianness. I don't
> think we can just assume that this is the case.

Huh, yeah. Will need to figure out how to detect the EC endianness in
that case.

>
> > +int cros_ec_read_mapped_mem8(struct cros_ec_device *ec, const uint8_t 
> > offset,
> > + uint8_t *data)
> > +{
> > + return __cros_ec_read_mapped_mem(ec, offset, data, sizeof(*data));
> > +}
> > +EXPORT_SYMBOL_GPL(cros_ec_read_mapped_mem8);
> > diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> > index b3d04de..c2de878 100644
> > --- a/include/linux/mfd/cros_ec.h
> > +++ b/include/linux/mfd/cros_ec.h
> > @@ -190,6 +190,45 @@ struct cros_ec_dev {
> >  };
> >
> >  /**
> > + * cros_ec_read_mapped_mem8 - Read mapped memory in the ChromeOS EC
> > + *
> > + * This can be called by drivers to access the mapped memory in the EC
> > + *
> > + * @ec_dev: Device to read from
> > + * @offset: Offset to read
> > + * @data: Return data
> > + * @return: 0 if Ok, -ve on error
> > + */
> > +int cros_ec_read_mapped_mem8(struct cros_ec_device *ec, const uint8_t 
> > offset,
> > + uint8_t *data);
> > +
> > +/**
> > + * cros_ec_r

Re: [PATCH 1/3] mfd: cros-ec: Add functions to read mapped memory

[Moritz Fischer]

On Sun, Apr 09, 2017 at 04:02:04PM -0700, Guenter Roeck wrote:
> On 04/07/2017 03:00 PM, Moritz Fischer wrote:
> > From: Moritz Fischer 
> >
> > The ChromeOS EC has mapped memory regions where things like temperature
> > sensors and fan speed are stored. Provide access to those from the
> > cros-ec mfd device.
> >
> > Signed-off-by: Moritz Fischer 
>
> I'll have to consult with others at Google if this is a good idea.
> Benson, can you comment ?

Well to my knowledge the only other way to get to it is the 'ectool'
from userland
via ioctl calls. The other option would be IIO ...
>
> > ---
> >  drivers/platform/chrome/cros_ec_proto.c | 55 
> > +
> >  include/linux/mfd/cros_ec.h | 39 +++
> >  2 files changed, 94 insertions(+)
> >
> > diff --git a/drivers/platform/chrome/cros_ec_proto.c 
> > b/drivers/platform/chrome/cros_ec_proto.c
> > index ed5dee7..28063de 100644
> > --- a/drivers/platform/chrome/cros_ec_proto.c
> > +++ b/drivers/platform/chrome/cros_ec_proto.c
> > @@ -494,3 +494,58 @@ int cros_ec_get_next_event(struct cros_ec_device 
> > *ec_dev)
> >   return get_keyboard_state_event(ec_dev);
> >  }
> >  EXPORT_SYMBOL(cros_ec_get_next_event);
> > +
> > +static int __cros_ec_read_mapped_mem(struct cros_ec_device *ec, uint8_t 
> > offset,
> > + void *buf, size_t size)
> > +{
> > + int ret;
> > + struct ec_params_read_memmap *params;
> > + struct cros_ec_command *msg;
> > +
> > + msg = kzalloc(sizeof(*msg) + max(sizeof(*params), size), GFP_KERNEL);
> > + if (!msg)
> > + return -ENOMEM;
> > +
>
> I don't think using kzalloc here makes much sense. It is well known
> that size is <= 4, so using a local buffer should not be a problem.

Good point, that was basically copy & paste from other cros-ec code ;-)
I'll fix this.

>
> > + msg->version = 0;
> > + msg->command = EC_CMD_READ_MEMMAP;
> > + msg->insize = size;
> > + msg->outsize = sizeof(*params);
> > +
> > + params = (struct ec_params_read_memmap *)msg->data;
> > + params->offset = offset;
> > + params->size = size;
> > +
> > + ret = cros_ec_cmd_xfer(ec, msg);
> > + if (ret < 0 || msg->result != EC_RES_SUCCESS) {
>
> cros_ec_cmd_xfer_status() was introduced to be able to avoid the second check.
>

Alright, cool. Will fix this.

> > + dev_warn(ec->dev, "cannot read mapped reg: %d/%d\n",
> > + ret, msg->result);
> > + goto out_free;
> > + }
> > +
> > + memcpy(buf, msg->data, size);
> > +
> > +out_free:
> > + kfree(msg);
> > + return ret;
> > +}
> > +
> > +int cros_ec_read_mapped_mem32(struct cros_ec_device *ec, const uint8_t 
> > offset,
> > +  uint32_t *data)
> > +{
> > + return __cros_ec_read_mapped_mem(ec, offset, data, sizeof(*data));
> > +}
> > +EXPORT_SYMBOL_GPL(cros_ec_read_mapped_mem32);
> > +
> > +int cros_ec_read_mapped_mem16(struct cros_ec_device *ec, const uint8_t 
> > offset,
> > +  uint16_t *data)
> > +{
> > + return __cros_ec_read_mapped_mem(ec, offset, data, sizeof(*data));
> > +}
> > +EXPORT_SYMBOL_GPL(cros_ec_read_mapped_mem16);
> > +
>
> Either case, this assumes that EC endianness matches host endianness. I don't
> think we can just assume that this is the case.

Huh, yeah. Will need to figure out how to detect the EC endianness in
that case.

>
> > +int cros_ec_read_mapped_mem8(struct cros_ec_device *ec, const uint8_t 
> > offset,
> > + uint8_t *data)
> > +{
> > + return __cros_ec_read_mapped_mem(ec, offset, data, sizeof(*data));
> > +}
> > +EXPORT_SYMBOL_GPL(cros_ec_read_mapped_mem8);
> > diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
> > index b3d04de..c2de878 100644
> > --- a/include/linux/mfd/cros_ec.h
> > +++ b/include/linux/mfd/cros_ec.h
> > @@ -190,6 +190,45 @@ struct cros_ec_dev {
> >  };
> >
> >  /**
> > + * cros_ec_read_mapped_mem8 - Read mapped memory in the ChromeOS EC
> > + *
> > + * This can be called by drivers to access the mapped memory in the EC
> > + *
> > + * @ec_dev: Device to read from
> > + * @offset: Offset to read
> > + * @data: Return data
> > + * @return: 0 if Ok, -ve on error
> > + */
> > +int cros_ec_read_mapped_mem8(struct cros_ec_device *ec, const uint8_t 
> > offset,
> > + uint8_t *data);
> > +
> > +/**
> > + * cros_ec_read_mapped_mem16 - Read mapped memory in the ChromeOS EC
> &g

[PATCH v5] dt-bindings: fpga: Add bindings document for Xilinx LogiCore PR Decoupler

[Moritz Fischer]

This adds the binding documentation for the Xilinx LogiCORE PR
Decoupler soft core.

Signed-off-by: Moritz Fischer <m...@kernel.org>
Signed-off-by: Michal Simek <michal.si...@xilinx.com>
Acked-by: Alan Tull <at...@kernel.org>
Cc: Sören Brinkmann <soren.brinkm...@xilinx.com>
Cc: linux-kernel@vger.kernel.org
Cc: devicet...@vger.kernel.org
---

Changes from v4:
- Ssubject line
- Replaced 'or' by 'followed by' as suggested by Rob

Changes from v3:
- Addressed Michal's comments
- Addressed Alan's Comments
- Added Alan's Acked-by

Changes from v2:
- Added refence to generic fpga-region bindings
- Fixed up reg property in example
- Added fallback to "xlnx,pr-decoupler" without version

Changes from v1:
- Added clock names & clock to example
- Merged some of the description from Michal's version

---
 .../bindings/fpga/xilinx-pr-decoupler.txt  | 36 ++
 1 file changed, 36 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt

diff --git a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt 
b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
new file mode 100644
index 000..b2c58fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
@@ -0,0 +1,36 @@
+Xilinx LogiCORE Partial Reconfig Decoupler Softcore
+
+The Xilinx LogiCORE Partial Reconfig Decoupler manages one or more
+decouplers / fpga bridges.
+The controller can decouple/disable the bridges which prevents signal
+changes from passing through the bridge.  The controller can also
+couple / enable the bridges which allows traffic to pass through the
+bridge normally.
+
+The Driver supports only MMIO handling. A PR region can have multiple
+PR Decouplers which can be handled independently or chained via decouple/
+decouple_status signals.
+
+Required properties:
+- compatible   : Should contain "xlnx,pr-decoupler-1.00" followed by
+  "xlnx,pr-decoupler"
+- regs : base address and size for decoupler module
+- clocks   : input clock to IP
+- clock-names  : should contain "aclk"
+
+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.
+
+See Documentation/devicetree/bindings/fpga/fpga-region.txt for generic 
bindings.
+
+Example:
+   fpga-bridge@10450 {
+   compatible = "xlnx,pr-decoupler-1.00",
+"xlnx-pr-decoupler";
+   regs = <0x1045 0x10>;
+   clocks = < 15>;
+   clock-names = "aclk";
+   bridge-enable = <0>;
+   };
-- 
2.7.4

[PATCH v5] dt-bindings: fpga: Add bindings document for Xilinx LogiCore PR Decoupler

[Moritz Fischer]

This adds the binding documentation for the Xilinx LogiCORE PR
Decoupler soft core.

Signed-off-by: Moritz Fischer 
Signed-off-by: Michal Simek 
Acked-by: Alan Tull 
Cc: Sören Brinkmann 
Cc: linux-kernel@vger.kernel.org
Cc: devicet...@vger.kernel.org
---

Changes from v4:
- Ssubject line
- Replaced 'or' by 'followed by' as suggested by Rob

Changes from v3:
- Addressed Michal's comments
- Addressed Alan's Comments
- Added Alan's Acked-by

Changes from v2:
- Added refence to generic fpga-region bindings
- Fixed up reg property in example
- Added fallback to "xlnx,pr-decoupler" without version

Changes from v1:
- Added clock names & clock to example
- Merged some of the description from Michal's version

---
 .../bindings/fpga/xilinx-pr-decoupler.txt  | 36 ++
 1 file changed, 36 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt

diff --git a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt 
b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
new file mode 100644
index 000..b2c58fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
@@ -0,0 +1,36 @@
+Xilinx LogiCORE Partial Reconfig Decoupler Softcore
+
+The Xilinx LogiCORE Partial Reconfig Decoupler manages one or more
+decouplers / fpga bridges.
+The controller can decouple/disable the bridges which prevents signal
+changes from passing through the bridge.  The controller can also
+couple / enable the bridges which allows traffic to pass through the
+bridge normally.
+
+The Driver supports only MMIO handling. A PR region can have multiple
+PR Decouplers which can be handled independently or chained via decouple/
+decouple_status signals.
+
+Required properties:
+- compatible   : Should contain "xlnx,pr-decoupler-1.00" followed by
+  "xlnx,pr-decoupler"
+- regs : base address and size for decoupler module
+- clocks   : input clock to IP
+- clock-names  : should contain "aclk"
+
+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.
+
+See Documentation/devicetree/bindings/fpga/fpga-region.txt for generic 
bindings.
+
+Example:
+   fpga-bridge@10450 {
+   compatible = "xlnx,pr-decoupler-1.00",
+"xlnx-pr-decoupler";
+   regs = <0x1045 0x10>;
+   clocks = < 15>;
+   clock-names = "aclk";
+   bridge-enable = <0>;
+   };
-- 
2.7.4

Re: [PATCH v2] fpga fr br: update supported version numbers

[Moritz Fischer]

On Fri, Apr 07, 2017 at 12:26:36PM -0700, matthew.gerl...@linux.intel.com wrote:
> From: Matthew Gerlach <matthew.gerl...@linux.intel.com>
> 
> The value in the version register of the altera freeze bridge
> controller changed from the beta value of 2 to the
> value of 0xad03 in the official release of the IP.
> This patch supports the old and new version numbers, and the
> driver's probe function will fail if neither of the supported
> versions is found.
> 
> Signed-off-by: Matthew Gerlach <matthew.gerl...@linux.intel.com>
Reviewed-by: Moritz Fischer <m...@kernel.org>
> ---
> v2: change warning to fail as per Moritz Fischer <m...@kernel.org>
> ---
>  drivers/fpga/altera-freeze-bridge.c | 30 +++---
>  1 file changed, 19 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/fpga/altera-freeze-bridge.c 
> b/drivers/fpga/altera-freeze-bridge.c
> index 8dcd9fb..114d3cb 100644
> --- a/drivers/fpga/altera-freeze-bridge.c
> +++ b/drivers/fpga/altera-freeze-bridge.c
> @@ -28,6 +28,7 @@
>  #define FREEZE_CSR_REG_VERSION   12
>  
>  #define FREEZE_CSR_SUPPORTED_VERSION 2
> +#define FREEZE_CSR_OFFICIAL_VERSION  0xad03
>  
>  #define FREEZE_CSR_STATUS_FREEZE_REQ_DONEBIT(0)
>  #define FREEZE_CSR_STATUS_UNFREEZE_REQ_DONE  BIT(1)
> @@ -218,6 +219,7 @@ static int altera_freeze_br_probe(struct platform_device 
> *pdev)
>  {
>   struct device *dev = >dev;
>   struct device_node *np = pdev->dev.of_node;
> + void __iomem *base_addr;
>   struct altera_freeze_br_data *priv;
>   struct resource *res;
>   u32 status, revision;
> @@ -225,26 +227,32 @@ static int altera_freeze_br_probe(struct 
> platform_device *pdev)
>   if (!np)
>   return -ENODEV;
>  
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + base_addr = devm_ioremap_resource(dev, res);
> + if (IS_ERR(base_addr))
> + return PTR_ERR(base_addr);
> +
> + revision = readl(base_addr + FREEZE_CSR_REG_VERSION);
> + if ((revision != FREEZE_CSR_SUPPORTED_VERSION) &&
> + (revision != FREEZE_CSR_OFFICIAL_VERSION)) {
> + dev_err(dev,
> + "%s unexpected revision 0x%x != 0x%x != 0x%x\n",
> + __func__, revision, FREEZE_CSR_SUPPORTED_VERSION,
> + FREEZE_CSR_OFFICIAL_VERSION);
> + return -EINVAL;
> + }
> +
>   priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>   if (!priv)
>   return -ENOMEM;
>  
>   priv->dev = dev;
>  
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - priv->base_addr = devm_ioremap_resource(dev, res);
> - if (IS_ERR(priv->base_addr))
> - return PTR_ERR(priv->base_addr);
> -
> - status = readl(priv->base_addr + FREEZE_CSR_STATUS_OFFSET);
> + status = readl(base_addr + FREEZE_CSR_STATUS_OFFSET);
>   if (status & FREEZE_CSR_STATUS_UNFREEZE_REQ_DONE)
>   priv->enable = 1;
>  
> - revision = readl(priv->base_addr + FREEZE_CSR_REG_VERSION);
> - if (revision != FREEZE_CSR_SUPPORTED_VERSION)
> - dev_warn(dev,
> -  "%s Freeze Controller unexpected revision %d != %d\n",
> -  __func__, revision, FREEZE_CSR_SUPPORTED_VERSION);
> + priv->base_addr = base_addr;
>  
>   return fpga_bridge_register(dev, FREEZE_BRIDGE_NAME,
>   _freeze_br_br_ops, priv);
> -- 
> 2.7.4
> 

Thanks,
Moritz


signature.asc
Description: PGP signature

Re: [PATCH v2] fpga fr br: update supported version numbers

[Moritz Fischer]

On Fri, Apr 07, 2017 at 12:26:36PM -0700, matthew.gerl...@linux.intel.com wrote:
> From: Matthew Gerlach 
> 
> The value in the version register of the altera freeze bridge
> controller changed from the beta value of 2 to the
> value of 0xad03 in the official release of the IP.
> This patch supports the old and new version numbers, and the
> driver's probe function will fail if neither of the supported
> versions is found.
> 
> Signed-off-by: Matthew Gerlach 
Reviewed-by: Moritz Fischer 
> ---
> v2: change warning to fail as per Moritz Fischer 
> ---
>  drivers/fpga/altera-freeze-bridge.c | 30 +++---
>  1 file changed, 19 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/fpga/altera-freeze-bridge.c 
> b/drivers/fpga/altera-freeze-bridge.c
> index 8dcd9fb..114d3cb 100644
> --- a/drivers/fpga/altera-freeze-bridge.c
> +++ b/drivers/fpga/altera-freeze-bridge.c
> @@ -28,6 +28,7 @@
>  #define FREEZE_CSR_REG_VERSION   12
>  
>  #define FREEZE_CSR_SUPPORTED_VERSION 2
> +#define FREEZE_CSR_OFFICIAL_VERSION  0xad03
>  
>  #define FREEZE_CSR_STATUS_FREEZE_REQ_DONEBIT(0)
>  #define FREEZE_CSR_STATUS_UNFREEZE_REQ_DONE  BIT(1)
> @@ -218,6 +219,7 @@ static int altera_freeze_br_probe(struct platform_device 
> *pdev)
>  {
>   struct device *dev = >dev;
>   struct device_node *np = pdev->dev.of_node;
> + void __iomem *base_addr;
>   struct altera_freeze_br_data *priv;
>   struct resource *res;
>   u32 status, revision;
> @@ -225,26 +227,32 @@ static int altera_freeze_br_probe(struct 
> platform_device *pdev)
>   if (!np)
>   return -ENODEV;
>  
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + base_addr = devm_ioremap_resource(dev, res);
> + if (IS_ERR(base_addr))
> + return PTR_ERR(base_addr);
> +
> + revision = readl(base_addr + FREEZE_CSR_REG_VERSION);
> + if ((revision != FREEZE_CSR_SUPPORTED_VERSION) &&
> + (revision != FREEZE_CSR_OFFICIAL_VERSION)) {
> + dev_err(dev,
> + "%s unexpected revision 0x%x != 0x%x != 0x%x\n",
> + __func__, revision, FREEZE_CSR_SUPPORTED_VERSION,
> + FREEZE_CSR_OFFICIAL_VERSION);
> + return -EINVAL;
> + }
> +
>   priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
>   if (!priv)
>   return -ENOMEM;
>  
>   priv->dev = dev;
>  
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - priv->base_addr = devm_ioremap_resource(dev, res);
> - if (IS_ERR(priv->base_addr))
> - return PTR_ERR(priv->base_addr);
> -
> - status = readl(priv->base_addr + FREEZE_CSR_STATUS_OFFSET);
> + status = readl(base_addr + FREEZE_CSR_STATUS_OFFSET);
>   if (status & FREEZE_CSR_STATUS_UNFREEZE_REQ_DONE)
>   priv->enable = 1;
>  
> - revision = readl(priv->base_addr + FREEZE_CSR_REG_VERSION);
> - if (revision != FREEZE_CSR_SUPPORTED_VERSION)
> - dev_warn(dev,
> -  "%s Freeze Controller unexpected revision %d != %d\n",
> -  __func__, revision, FREEZE_CSR_SUPPORTED_VERSION);
> + priv->base_addr = base_addr;
>  
>   return fpga_bridge_register(dev, FREEZE_BRIDGE_NAME,
>   _freeze_br_br_ops, priv);
> -- 
> 2.7.4
> 

Thanks,
Moritz


signature.asc
Description: PGP signature

[PATCH 2/3] dt-bindings: hwmon: Add bindings for Google Chromium EC HWMON

[Moritz Fischer]

From: Moritz Fischer <m...@kernel.org>

Add bindings for the Chromium EC HWMON. The Chromium EC HWMON
allows monitoring of temperature sensors and fans attached to the
EC.

Signed-off-by: Moritz Fischer <m...@kernel.org>
---
 .../devicetree/bindings/hwmon/cros-ec-hwmon.txt| 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt

diff --git a/Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt 
b/Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt
new file mode 100644
index 000..4c94869
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt
@@ -0,0 +1,25 @@
+Chromium Embedded Controller EC temperature and fan control
+---
+
+Google's Chromium EC HWMON is a hwmon implemented byimplemented by the 
Chromium EC
+firmware attached to the Embedded Controller (EC) and controlled via a 
host-command
+interface.
+
+An EC HWMON node should be only found as a sub-node of the EC node (see
+Documentation/devicetree/bindings/mfd/cros-ec.txt).
+
+Required properties:
+- compatible: Must contain "google,cros-ec-hwmon"
+
+Example:
+   embedded-controller@1e {
+   reg = <0x1e>;
+   compatible = "google,cros-ec-i2c";
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-parent = <>;
+
+   hwmon {
+   compatible = "google,cros-ec-hwmon";
+   };
+};
+
-- 
2.7.4

[PATCH 2/3] dt-bindings: hwmon: Add bindings for Google Chromium EC HWMON

[Moritz Fischer]

From: Moritz Fischer 

Add bindings for the Chromium EC HWMON. The Chromium EC HWMON
allows monitoring of temperature sensors and fans attached to the
EC.

Signed-off-by: Moritz Fischer 
---
 .../devicetree/bindings/hwmon/cros-ec-hwmon.txt| 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt

diff --git a/Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt 
b/Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt
new file mode 100644
index 000..4c94869
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/cros-ec-hwmon.txt
@@ -0,0 +1,25 @@
+Chromium Embedded Controller EC temperature and fan control
+---
+
+Google's Chromium EC HWMON is a hwmon implemented byimplemented by the 
Chromium EC
+firmware attached to the Embedded Controller (EC) and controlled via a 
host-command
+interface.
+
+An EC HWMON node should be only found as a sub-node of the EC node (see
+Documentation/devicetree/bindings/mfd/cros-ec.txt).
+
+Required properties:
+- compatible: Must contain "google,cros-ec-hwmon"
+
+Example:
+   embedded-controller@1e {
+   reg = <0x1e>;
+   compatible = "google,cros-ec-i2c";
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-parent = <>;
+
+   hwmon {
+   compatible = "google,cros-ec-hwmon";
+   };
+};
+
-- 
2.7.4

[PATCH 3/3] hwmon: cros-ec-hwmon: Add Chromium-EC HWMON driver

[Moritz Fischer]

From: Moritz Fischer <m...@kernel.org>

This adds a hwmon driver for the Chromium EC's fans
and temperature sensors.

Signed-off-by: Moritz Fischer <m...@kernel.org>
---

This one still needs some work, but I figured some early feedback might not 
hurt.
Specifically I was wondering if using the devm_hwmon_register_with_info() is
preferable to the devm_hwmon_register_with_groups().

The EC has a bunch of additional features such as setting thermal limits etc,
which I'd still like to add but I figured I'll get some feedback on what I got 
so far.

Thanks,

Moritz

---
 drivers/hwmon/Kconfig |   8 ++
 drivers/hwmon/Makefile|   1 +
 drivers/hwmon/cros-ec-hwmon.c | 244 ++
 3 files changed, 253 insertions(+)
 create mode 100644 drivers/hwmon/cros-ec-hwmon.c

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 0649d53f3..3b9155f 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1254,6 +1254,14 @@ config SENSORS_PCF8591
  These devices are hard to detect and rarely found on mainstream
  hardware.  If unsure, say N.
 
+config SENSORS_CROS_EC
+   tristate "ChromeOS EC hwmon"
+   depends on MFD_CROS_EC
+   help
+ If you say yes here you get hwmon support that will expose the
+ ChromeOS internal sensors for fanspeed and temperature to the
+ Linux hwmon subsystem.
+
 source drivers/hwmon/pmbus/Kconfig
 
 config SENSORS_PWM_FAN
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 5509edf..e59b5da 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -134,6 +134,7 @@ obj-$(CONFIG_SENSORS_PC87360)   += pc87360.o
 obj-$(CONFIG_SENSORS_PC87427)  += pc87427.o
 obj-$(CONFIG_SENSORS_PCF8591)  += pcf8591.o
 obj-$(CONFIG_SENSORS_POWR1220)  += powr1220.o
+obj-$(CONFIG_SENSORS_CROS_EC)   += cros-ec-hwmon.o
 obj-$(CONFIG_SENSORS_PWM_FAN)  += pwm-fan.o
 obj-$(CONFIG_SENSORS_S3C)  += s3c-hwmon.o
 obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
diff --git a/drivers/hwmon/cros-ec-hwmon.c b/drivers/hwmon/cros-ec-hwmon.c
new file mode 100644
index 000..29d8b06
--- /dev/null
+++ b/drivers/hwmon/cros-ec-hwmon.c
@@ -0,0 +1,244 @@
+/*
+ * Copyright (c) 2017, National Instruments Corp.
+ *
+ * Chromium EC Fan speed and temperature sensor driver
+ *
+ * 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
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct cros_ec_hwmon_priv {
+   struct cros_ec_device *ec;
+   struct device *hwmon_dev;
+
+   struct attribute **attrs;
+
+   struct attribute_group attr_group;
+   const struct attribute_group *groups[2];
+};
+
+#define KELVIN_TO_MILLICELSIUS(x) (((x) - 273) * 1000)
+
+static int __cros_ec_hwmon_probe_fans(struct cros_ec_hwmon_priv *priv)
+{
+   int err, idx;
+   uint16_t data;
+
+   for (idx = 0; idx < EC_FAN_SPEED_ENTRIES; idx++) {
+   err = cros_ec_read_mapped_mem16(priv->ec,
+  EC_MEMMAP_FAN + 2 * idx,
+  );
+   if (err)
+   return err;
+
+   if (data == EC_FAN_SPEED_NOT_PRESENT)
+   break;
+   }
+
+   return idx;
+}
+
+static int __cros_ec_hwmon_probe_temps(struct cros_ec_hwmon_priv *priv)
+{
+   uint8_t data;
+   int err, idx;
+
+   err = cros_ec_read_mapped_mem8(priv->ec, EC_MEMMAP_THERMAL_VERSION,
+  );
+
+   /* if we have a read error, or EC_MEMMAP_THERMAL_VERSION is not set,
+* most likely we don't have temperature sensors ...
+*/
+   if (err || !data)
+   return 0;
+
+   for (idx = 0; idx < EC_TEMP_SENSOR_ENTRIES; idx++) {
+   err = cros_ec_read_mapped_mem8(priv->ec,
+  EC_MEMMAP_TEMP_SENSOR + idx,
+  );
+   if (err)
+   return idx;
+
+   /* this assumes that they're all good up to idx */
+   switch (data) {
+   case EC_TEMP_SENSOR_NOT_PRESENT:
+   case EC_TEMP_SENSOR_ERROR:
+   case EC_TEMP_SENSOR_NOT_POWERED:
+   case EC_TEMP_SENSOR_NOT_CALIBRATED:
+   return idx;
+   default:
+   continue;
+   };
+   }
+
+  

[PATCH 3/3] hwmon: cros-ec-hwmon: Add Chromium-EC HWMON driver

[Moritz Fischer]

From: Moritz Fischer 

This adds a hwmon driver for the Chromium EC's fans
and temperature sensors.

Signed-off-by: Moritz Fischer 
---

This one still needs some work, but I figured some early feedback might not 
hurt.
Specifically I was wondering if using the devm_hwmon_register_with_info() is
preferable to the devm_hwmon_register_with_groups().

The EC has a bunch of additional features such as setting thermal limits etc,
which I'd still like to add but I figured I'll get some feedback on what I got 
so far.

Thanks,

Moritz

---
 drivers/hwmon/Kconfig |   8 ++
 drivers/hwmon/Makefile|   1 +
 drivers/hwmon/cros-ec-hwmon.c | 244 ++
 3 files changed, 253 insertions(+)
 create mode 100644 drivers/hwmon/cros-ec-hwmon.c

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 0649d53f3..3b9155f 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1254,6 +1254,14 @@ config SENSORS_PCF8591
  These devices are hard to detect and rarely found on mainstream
  hardware.  If unsure, say N.
 
+config SENSORS_CROS_EC
+   tristate "ChromeOS EC hwmon"
+   depends on MFD_CROS_EC
+   help
+ If you say yes here you get hwmon support that will expose the
+ ChromeOS internal sensors for fanspeed and temperature to the
+ Linux hwmon subsystem.
+
 source drivers/hwmon/pmbus/Kconfig
 
 config SENSORS_PWM_FAN
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 5509edf..e59b5da 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -134,6 +134,7 @@ obj-$(CONFIG_SENSORS_PC87360)   += pc87360.o
 obj-$(CONFIG_SENSORS_PC87427)  += pc87427.o
 obj-$(CONFIG_SENSORS_PCF8591)  += pcf8591.o
 obj-$(CONFIG_SENSORS_POWR1220)  += powr1220.o
+obj-$(CONFIG_SENSORS_CROS_EC)   += cros-ec-hwmon.o
 obj-$(CONFIG_SENSORS_PWM_FAN)  += pwm-fan.o
 obj-$(CONFIG_SENSORS_S3C)  += s3c-hwmon.o
 obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
diff --git a/drivers/hwmon/cros-ec-hwmon.c b/drivers/hwmon/cros-ec-hwmon.c
new file mode 100644
index 000..29d8b06
--- /dev/null
+++ b/drivers/hwmon/cros-ec-hwmon.c
@@ -0,0 +1,244 @@
+/*
+ * Copyright (c) 2017, National Instruments Corp.
+ *
+ * Chromium EC Fan speed and temperature sensor driver
+ *
+ * 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
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct cros_ec_hwmon_priv {
+   struct cros_ec_device *ec;
+   struct device *hwmon_dev;
+
+   struct attribute **attrs;
+
+   struct attribute_group attr_group;
+   const struct attribute_group *groups[2];
+};
+
+#define KELVIN_TO_MILLICELSIUS(x) (((x) - 273) * 1000)
+
+static int __cros_ec_hwmon_probe_fans(struct cros_ec_hwmon_priv *priv)
+{
+   int err, idx;
+   uint16_t data;
+
+   for (idx = 0; idx < EC_FAN_SPEED_ENTRIES; idx++) {
+   err = cros_ec_read_mapped_mem16(priv->ec,
+  EC_MEMMAP_FAN + 2 * idx,
+  );
+   if (err)
+   return err;
+
+   if (data == EC_FAN_SPEED_NOT_PRESENT)
+   break;
+   }
+
+   return idx;
+}
+
+static int __cros_ec_hwmon_probe_temps(struct cros_ec_hwmon_priv *priv)
+{
+   uint8_t data;
+   int err, idx;
+
+   err = cros_ec_read_mapped_mem8(priv->ec, EC_MEMMAP_THERMAL_VERSION,
+  );
+
+   /* if we have a read error, or EC_MEMMAP_THERMAL_VERSION is not set,
+* most likely we don't have temperature sensors ...
+*/
+   if (err || !data)
+   return 0;
+
+   for (idx = 0; idx < EC_TEMP_SENSOR_ENTRIES; idx++) {
+   err = cros_ec_read_mapped_mem8(priv->ec,
+  EC_MEMMAP_TEMP_SENSOR + idx,
+  );
+   if (err)
+   return idx;
+
+   /* this assumes that they're all good up to idx */
+   switch (data) {
+   case EC_TEMP_SENSOR_NOT_PRESENT:
+   case EC_TEMP_SENSOR_ERROR:
+   case EC_TEMP_SENSOR_NOT_POWERED:
+   case EC_TEMP_SENSOR_NOT_CALIBRATED:
+   return idx;
+   default:
+   continue;
+   };
+   }
+
+   return idx;
+}
+
+static ssize_t cros_ec_hwmon_read_f

[PATCH 1/3] mfd: cros-ec: Add functions to read mapped memory

[Moritz Fischer]

From: Moritz Fischer <m...@kernel.org>

The ChromeOS EC has mapped memory regions where things like temperature
sensors and fan speed are stored. Provide access to those from the
cros-ec mfd device.

Signed-off-by: Moritz Fischer <m...@kernel.org>
---
 drivers/platform/chrome/cros_ec_proto.c | 55 +
 include/linux/mfd/cros_ec.h | 39 +++
 2 files changed, 94 insertions(+)

diff --git a/drivers/platform/chrome/cros_ec_proto.c 
b/drivers/platform/chrome/cros_ec_proto.c
index ed5dee7..28063de 100644
--- a/drivers/platform/chrome/cros_ec_proto.c
+++ b/drivers/platform/chrome/cros_ec_proto.c
@@ -494,3 +494,58 @@ int cros_ec_get_next_event(struct cros_ec_device *ec_dev)
return get_keyboard_state_event(ec_dev);
 }
 EXPORT_SYMBOL(cros_ec_get_next_event);
+
+static int __cros_ec_read_mapped_mem(struct cros_ec_device *ec, uint8_t offset,
+void *buf, size_t size)
+{
+   int ret;
+   struct ec_params_read_memmap *params;
+   struct cros_ec_command *msg;
+
+   msg = kzalloc(sizeof(*msg) + max(sizeof(*params), size), GFP_KERNEL);
+   if (!msg)
+   return -ENOMEM;
+
+   msg->version = 0;
+   msg->command = EC_CMD_READ_MEMMAP;
+   msg->insize = size;
+   msg->outsize = sizeof(*params);
+
+   params = (struct ec_params_read_memmap *)msg->data;
+   params->offset = offset;
+   params->size = size;
+
+   ret = cros_ec_cmd_xfer(ec, msg);
+   if (ret < 0 || msg->result != EC_RES_SUCCESS) {
+   dev_warn(ec->dev, "cannot read mapped reg: %d/%d\n",
+ret, msg->result);
+   goto out_free;
+   }
+
+   memcpy(buf, msg->data, size);
+
+out_free:
+   kfree(msg);
+   return ret;
+}
+
+int cros_ec_read_mapped_mem32(struct cros_ec_device *ec, const uint8_t offset,
+ uint32_t *data)
+{
+   return __cros_ec_read_mapped_mem(ec, offset, data, sizeof(*data));
+}
+EXPORT_SYMBOL_GPL(cros_ec_read_mapped_mem32);
+
+int cros_ec_read_mapped_mem16(struct cros_ec_device *ec, const uint8_t offset,
+ uint16_t *data)
+{
+   return __cros_ec_read_mapped_mem(ec, offset, data, sizeof(*data));
+}
+EXPORT_SYMBOL_GPL(cros_ec_read_mapped_mem16);
+
+int cros_ec_read_mapped_mem8(struct cros_ec_device *ec, const uint8_t offset,
+uint8_t *data)
+{
+   return __cros_ec_read_mapped_mem(ec, offset, data, sizeof(*data));
+}
+EXPORT_SYMBOL_GPL(cros_ec_read_mapped_mem8);
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index b3d04de..c2de878 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -190,6 +190,45 @@ struct cros_ec_dev {
 };
 
 /**
+ * cros_ec_read_mapped_mem8 - Read mapped memory in the ChromeOS EC
+ *
+ * This can be called by drivers to access the mapped memory in the EC
+ *
+ * @ec_dev: Device to read from
+ * @offset: Offset to read
+ * @data: Return data
+ * @return: 0 if Ok, -ve on error
+ */
+int cros_ec_read_mapped_mem8(struct cros_ec_device *ec, const uint8_t offset,
+uint8_t *data);
+
+/**
+ * cros_ec_read_mapped_mem16 - Read mapped memory in the ChromeOS EC
+ *
+ * This can be called by drivers to access the mapped memory in the EC
+ *
+ * @ec_dev: Device to read from
+ * @offset: Offset to read
+ * @data: Return data
+ * @return: 0 if Ok, -ve on error
+ */
+int cros_ec_read_mapped_mem16(struct cros_ec_device *ec, const uint8_t offset,
+ uint16_t *data);
+
+/**
+ * cros_ec_read_mapped_mem32 - Read mapped memory in the ChromeOS EC
+ *
+ * This can be called by drivers to access the mapped memory in the EC
+ *
+ * @ec_dev: Device to read from
+ * @offset: Offset to read
+ * @data: Return data
+ * @return: 0 if Ok, -ve on error
+ */
+int cros_ec_read_mapped_mem32(struct cros_ec_device *ec, const uint8_t offset,
+ uint32_t *data);
+
+/**
  * cros_ec_suspend - Handle a suspend operation for the ChromeOS EC device
  *
  * This can be called by drivers to handle a suspend event.
-- 
2.7.4

[PATCH 1/3] mfd: cros-ec: Add functions to read mapped memory

[Moritz Fischer]

From: Moritz Fischer 

The ChromeOS EC has mapped memory regions where things like temperature
sensors and fan speed are stored. Provide access to those from the
cros-ec mfd device.

Signed-off-by: Moritz Fischer 
---
 drivers/platform/chrome/cros_ec_proto.c | 55 +
 include/linux/mfd/cros_ec.h | 39 +++
 2 files changed, 94 insertions(+)

diff --git a/drivers/platform/chrome/cros_ec_proto.c 
b/drivers/platform/chrome/cros_ec_proto.c
index ed5dee7..28063de 100644
--- a/drivers/platform/chrome/cros_ec_proto.c
+++ b/drivers/platform/chrome/cros_ec_proto.c
@@ -494,3 +494,58 @@ int cros_ec_get_next_event(struct cros_ec_device *ec_dev)
return get_keyboard_state_event(ec_dev);
 }
 EXPORT_SYMBOL(cros_ec_get_next_event);
+
+static int __cros_ec_read_mapped_mem(struct cros_ec_device *ec, uint8_t offset,
+void *buf, size_t size)
+{
+   int ret;
+   struct ec_params_read_memmap *params;
+   struct cros_ec_command *msg;
+
+   msg = kzalloc(sizeof(*msg) + max(sizeof(*params), size), GFP_KERNEL);
+   if (!msg)
+   return -ENOMEM;
+
+   msg->version = 0;
+   msg->command = EC_CMD_READ_MEMMAP;
+   msg->insize = size;
+   msg->outsize = sizeof(*params);
+
+   params = (struct ec_params_read_memmap *)msg->data;
+   params->offset = offset;
+   params->size = size;
+
+   ret = cros_ec_cmd_xfer(ec, msg);
+   if (ret < 0 || msg->result != EC_RES_SUCCESS) {
+   dev_warn(ec->dev, "cannot read mapped reg: %d/%d\n",
+ret, msg->result);
+   goto out_free;
+   }
+
+   memcpy(buf, msg->data, size);
+
+out_free:
+   kfree(msg);
+   return ret;
+}
+
+int cros_ec_read_mapped_mem32(struct cros_ec_device *ec, const uint8_t offset,
+ uint32_t *data)
+{
+   return __cros_ec_read_mapped_mem(ec, offset, data, sizeof(*data));
+}
+EXPORT_SYMBOL_GPL(cros_ec_read_mapped_mem32);
+
+int cros_ec_read_mapped_mem16(struct cros_ec_device *ec, const uint8_t offset,
+ uint16_t *data)
+{
+   return __cros_ec_read_mapped_mem(ec, offset, data, sizeof(*data));
+}
+EXPORT_SYMBOL_GPL(cros_ec_read_mapped_mem16);
+
+int cros_ec_read_mapped_mem8(struct cros_ec_device *ec, const uint8_t offset,
+uint8_t *data)
+{
+   return __cros_ec_read_mapped_mem(ec, offset, data, sizeof(*data));
+}
+EXPORT_SYMBOL_GPL(cros_ec_read_mapped_mem8);
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index b3d04de..c2de878 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -190,6 +190,45 @@ struct cros_ec_dev {
 };
 
 /**
+ * cros_ec_read_mapped_mem8 - Read mapped memory in the ChromeOS EC
+ *
+ * This can be called by drivers to access the mapped memory in the EC
+ *
+ * @ec_dev: Device to read from
+ * @offset: Offset to read
+ * @data: Return data
+ * @return: 0 if Ok, -ve on error
+ */
+int cros_ec_read_mapped_mem8(struct cros_ec_device *ec, const uint8_t offset,
+uint8_t *data);
+
+/**
+ * cros_ec_read_mapped_mem16 - Read mapped memory in the ChromeOS EC
+ *
+ * This can be called by drivers to access the mapped memory in the EC
+ *
+ * @ec_dev: Device to read from
+ * @offset: Offset to read
+ * @data: Return data
+ * @return: 0 if Ok, -ve on error
+ */
+int cros_ec_read_mapped_mem16(struct cros_ec_device *ec, const uint8_t offset,
+ uint16_t *data);
+
+/**
+ * cros_ec_read_mapped_mem32 - Read mapped memory in the ChromeOS EC
+ *
+ * This can be called by drivers to access the mapped memory in the EC
+ *
+ * @ec_dev: Device to read from
+ * @offset: Offset to read
+ * @data: Return data
+ * @return: 0 if Ok, -ve on error
+ */
+int cros_ec_read_mapped_mem32(struct cros_ec_device *ec, const uint8_t offset,
+ uint32_t *data);
+
+/**
  * cros_ec_suspend - Handle a suspend operation for the ChromeOS EC device
  *
  * This can be called by drivers to handle a suspend event.
-- 
2.7.4

Re: [PATCH 5/5] fpga-region: separate out common code from dt specific code

[Moritz Fischer]

Hi Alan,

first pass ... need to get back to it.

On Mon, Mar 13, 2017 at 04:53:33PM -0500, Alan Tull wrote:
> FPGA region is a layer above the FPGA manager and FPGA bridge
> frameworks.  Currently, FPGA region is dependent on device tree.
> This commit separates the device tree specific code from the
> common code, separating fpga-region.c into fpga-region.c,
> of-fpga-region.c, and fpga-region.h.
> 
> Functons exported from fpga-region.c:
> * fpga_region_register
> * fpga_region_unregister
>   Create/remove a FPGA region.  Caller will supply the region
>   struct initialized with a pointer to a FPGA manager and
>   a method to get the FPGA bridges.
> 
> * of_fpga_region_find
>   Find a fpga region, given the node pointer
> 
> * fpga_region_alloc_image_info
> * fpga_region_free_image_info
>   Alloc/free fpga_image_info struct
> 
> * fpga_region_program_fpga
>   Program an FPGA region
> 
> Signed-off-by: Alan Tull 
> ---
>  drivers/fpga/Kconfig  |  12 +-
>  drivers/fpga/Makefile |   1 +
>  drivers/fpga/fpga-region.c| 475 
> +++---
>  drivers/fpga/fpga-region.h|  50 +
>  drivers/fpga/of-fpga-region.c | 453 
>  include/linux/fpga/fpga-mgr.h |   6 +-
>  6 files changed, 599 insertions(+), 398 deletions(-)
>  create mode 100644 drivers/fpga/fpga-region.h
>  create mode 100644 drivers/fpga/of-fpga-region.c
> 
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index ce861a2..be9c23d 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -15,10 +15,18 @@ if FPGA
>  
>  config FPGA_REGION
>   tristate "FPGA Region"
> - depends on OF && FPGA_BRIDGE
> + depends on FPGA_BRIDGE
> + help
> +   FPGA Region common code.  A FPGA Region controls a FPGA Manager
> +   and the FPGA Bridges associated with either a reconfigurable
> +   region of an FPGA or a whole FPGA.
> +
> +config OF_FPGA_REGION
> + tristate "FPGA Region Device Tree Overlay Support"
> + depends on FPGA_REGION

Doesn't this one now need depends on FPGA_REGION & OF ? Since
FPGA_REGION no longer depends on OF, or does FPGA_BRIDGE pull it in?

>   help
> FPGA Regions allow loading FPGA images under control of
> -   the Device Tree.
> +   Device Tree Overlays.
>  
>  config FPGA_MGR_SOCFPGA
>   tristate "Altera SOCFPGA FPGA Manager"
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index 8df07bc..fb88fb0 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -17,3 +17,4 @@ obj-$(CONFIG_ALTERA_FREEZE_BRIDGE)  += 
> altera-freeze-bridge.o
>  
>  # High Level Interfaces
>  obj-$(CONFIG_FPGA_REGION)+= fpga-region.o
> +obj-$(CONFIG_OF_FPGA_REGION) += of-fpga-region.o
> diff --git a/drivers/fpga/fpga-region.c b/drivers/fpga/fpga-region.c
> index 815f178..c06f2f7 100644
> --- a/drivers/fpga/fpga-region.c
> +++ b/drivers/fpga/fpga-region.c
> @@ -16,53 +16,64 @@
>   * this program.  If not, see .
>   */
>  
> +/* todo: prevent programming if region has child regions or overlay applied 
> */
> +
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
> +#include "fpga-region.h"
>  
> -/**
> - * 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
> - * @info: fpga image specific information
> - */
> -struct fpga_region {
> - struct device dev;
> - struct mutex mutex; /* for exclusive reference to region */
> - struct list_head bridge_list;
> +static DEFINE_IDA(fpga_region_ida);
> +struct class *fpga_region_class;
> +
> +struct fpga_image_info *fpga_region_alloc_image_info(struct fpga_region 
> *region)
> +{
> + struct device *dev = >dev;
>   struct fpga_image_info *info;
> -};
>  
> -#define to_fpga_region(d) container_of(d, struct fpga_region, dev)
> + info = devm_kzalloc(dev, sizeof(*info), GFP_KERNEL);
> + if (!info)
> + return ERR_PTR(-ENOMEM);
>  
> -static DEFINE_IDA(fpga_region_ida);
> -static struct class *fpga_region_class;
> + return info;
> +}
> +EXPORT_SYMBOL_GPL(fpga_region_alloc_image_info);
>  
> -static const struct of_device_id fpga_region_of_match[] = {
> - { .compatible = "fpga-region", },
> - {},
> -};
> -MODULE_DEVICE_TABLE(of, fpga_region_of_match);
> +void fpga_region_free_image_info(struct fpga_region *region,
> +  struct fpga_image_info *info)
> +{
> + struct device *dev = >dev;
> +
> + if (!info)
> + return;
> +
> + if (info->firmware_name)
> + devm_kfree(dev, info->firmware_name);
>  
> + devm_kfree(dev, info);
> +}
> +EXPORT_SYMBOL_GPL(fpga_region_free_image_info);
> +
> +#if IS_ENABLED(CONFIG_OF_FPGA_REGION)
>  static int 

Re: [PATCH 5/5] fpga-region: separate out common code from dt specific code

[Moritz Fischer]

Hi Alan,

first pass ... need to get back to it.

On Mon, Mar 13, 2017 at 04:53:33PM -0500, Alan Tull wrote:
> FPGA region is a layer above the FPGA manager and FPGA bridge
> frameworks.  Currently, FPGA region is dependent on device tree.
> This commit separates the device tree specific code from the
> common code, separating fpga-region.c into fpga-region.c,
> of-fpga-region.c, and fpga-region.h.
> 
> Functons exported from fpga-region.c:
> * fpga_region_register
> * fpga_region_unregister
>   Create/remove a FPGA region.  Caller will supply the region
>   struct initialized with a pointer to a FPGA manager and
>   a method to get the FPGA bridges.
> 
> * of_fpga_region_find
>   Find a fpga region, given the node pointer
> 
> * fpga_region_alloc_image_info
> * fpga_region_free_image_info
>   Alloc/free fpga_image_info struct
> 
> * fpga_region_program_fpga
>   Program an FPGA region
> 
> Signed-off-by: Alan Tull 
> ---
>  drivers/fpga/Kconfig  |  12 +-
>  drivers/fpga/Makefile |   1 +
>  drivers/fpga/fpga-region.c| 475 
> +++---
>  drivers/fpga/fpga-region.h|  50 +
>  drivers/fpga/of-fpga-region.c | 453 
>  include/linux/fpga/fpga-mgr.h |   6 +-
>  6 files changed, 599 insertions(+), 398 deletions(-)
>  create mode 100644 drivers/fpga/fpga-region.h
>  create mode 100644 drivers/fpga/of-fpga-region.c
> 
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index ce861a2..be9c23d 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -15,10 +15,18 @@ if FPGA
>  
>  config FPGA_REGION
>   tristate "FPGA Region"
> - depends on OF && FPGA_BRIDGE
> + depends on FPGA_BRIDGE
> + help
> +   FPGA Region common code.  A FPGA Region controls a FPGA Manager
> +   and the FPGA Bridges associated with either a reconfigurable
> +   region of an FPGA or a whole FPGA.
> +
> +config OF_FPGA_REGION
> + tristate "FPGA Region Device Tree Overlay Support"
> + depends on FPGA_REGION

Doesn't this one now need depends on FPGA_REGION & OF ? Since
FPGA_REGION no longer depends on OF, or does FPGA_BRIDGE pull it in?

>   help
> FPGA Regions allow loading FPGA images under control of
> -   the Device Tree.
> +   Device Tree Overlays.
>  
>  config FPGA_MGR_SOCFPGA
>   tristate "Altera SOCFPGA FPGA Manager"
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index 8df07bc..fb88fb0 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -17,3 +17,4 @@ obj-$(CONFIG_ALTERA_FREEZE_BRIDGE)  += 
> altera-freeze-bridge.o
>  
>  # High Level Interfaces
>  obj-$(CONFIG_FPGA_REGION)+= fpga-region.o
> +obj-$(CONFIG_OF_FPGA_REGION) += of-fpga-region.o
> diff --git a/drivers/fpga/fpga-region.c b/drivers/fpga/fpga-region.c
> index 815f178..c06f2f7 100644
> --- a/drivers/fpga/fpga-region.c
> +++ b/drivers/fpga/fpga-region.c
> @@ -16,53 +16,64 @@
>   * this program.  If not, see .
>   */
>  
> +/* todo: prevent programming if region has child regions or overlay applied 
> */
> +
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
> +#include "fpga-region.h"
>  
> -/**
> - * 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
> - * @info: fpga image specific information
> - */
> -struct fpga_region {
> - struct device dev;
> - struct mutex mutex; /* for exclusive reference to region */
> - struct list_head bridge_list;
> +static DEFINE_IDA(fpga_region_ida);
> +struct class *fpga_region_class;
> +
> +struct fpga_image_info *fpga_region_alloc_image_info(struct fpga_region 
> *region)
> +{
> + struct device *dev = >dev;
>   struct fpga_image_info *info;
> -};
>  
> -#define to_fpga_region(d) container_of(d, struct fpga_region, dev)
> + info = devm_kzalloc(dev, sizeof(*info), GFP_KERNEL);
> + if (!info)
> + return ERR_PTR(-ENOMEM);
>  
> -static DEFINE_IDA(fpga_region_ida);
> -static struct class *fpga_region_class;
> + return info;
> +}
> +EXPORT_SYMBOL_GPL(fpga_region_alloc_image_info);
>  
> -static const struct of_device_id fpga_region_of_match[] = {
> - { .compatible = "fpga-region", },
> - {},
> -};
> -MODULE_DEVICE_TABLE(of, fpga_region_of_match);
> +void fpga_region_free_image_info(struct fpga_region *region,
> +  struct fpga_image_info *info)
> +{
> + struct device *dev = >dev;
> +
> + if (!info)
> + return;
> +
> + if (info->firmware_name)
> + devm_kfree(dev, info->firmware_name);
>  
> + devm_kfree(dev, info);
> +}
> +EXPORT_SYMBOL_GPL(fpga_region_free_image_info);
> +
> +#if IS_ENABLED(CONFIG_OF_FPGA_REGION)
>  static int fpga_region_of_node_match(struct device *dev, 

Re: [PATCH 4/5] fpga-mgr: separate getting/locking FPGA manager

[Moritz Fischer]

Hi Alan,

minor nits, inline

On Mon, Mar 13, 2017 at 04:53:32PM -0500, Alan Tull wrote:
> Add fpga_mgr_lock/unlock functions that get a mutex for
> exclusive use.
> 
> of_fpga_mgr_get, fpga_mgr_get, and fpga_mgr_put no longer lock
> the FPGA manager mutex.
> 
> This makes it more straightforward to save a reference to
> a FPGA manager and only attempting to lock it when programming
> the FPGA.
> 
> Signed-off-by: Alan Tull 
> ---
>  drivers/fpga/fpga-mgr.c   | 44 
> +++
>  drivers/fpga/fpga-region.c| 13 +++--
>  include/linux/fpga/fpga-mgr.h |  3 +++
>  3 files changed, 46 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
> index fde605b..f7c3648 100644
> --- a/drivers/fpga/fpga-mgr.c
> +++ b/drivers/fpga/fpga-mgr.c
> @@ -376,28 +376,19 @@ ATTRIBUTE_GROUPS(fpga_mgr);
>  struct fpga_manager *__fpga_mgr_get(struct device *dev)
>  {
>   struct fpga_manager *mgr;
> - int ret = -ENODEV;
>  
>   mgr = to_fpga_manager(dev);
>   if (!mgr)
>   goto err_dev;
>  
> - /* Get exclusive use of fpga manager */
> - if (!mutex_trylock(>ref_mutex)) {
> - ret = -EBUSY;
> - goto err_dev;
> - }
> -
>   if (!try_module_get(dev->parent->driver->owner))
> - goto err_ll_mod;
> + goto err_dev;
>  
>   return mgr;
>  
> -err_ll_mod:
> - mutex_unlock(>ref_mutex);
>  err_dev:
>   put_device(dev);
> - return ERR_PTR(ret);
> + return ERR_PTR(-ENODEV);
>  }
>  
>  static int fpga_mgr_dev_match(struct device *dev, const void *data)
> @@ -457,12 +448,41 @@ EXPORT_SYMBOL_GPL(of_fpga_mgr_get);
>  void fpga_mgr_put(struct fpga_manager *mgr)
>  {
>   module_put(mgr->dev.parent->driver->owner);
> - mutex_unlock(>ref_mutex);
>   put_device(>dev);
>  }
>  EXPORT_SYMBOL_GPL(fpga_mgr_put);
>  
>  /**
> + * fpga_mgr_lock - Lock FPGA manager for exclusive use
> + * @mgr: fpga manager
> + *
> + * Given a pointer to FPGA Manager (from fpga_mgr_get() or
> + * of_fpga_mgr_put()) attempt to get the mutex.
> + *
> + * Return: 0 for success or -EBUSY
> + */
> +int fpga_mgr_lock(struct fpga_manager *mgr)
> +{
> + if (!mutex_trylock(>ref_mutex)) {
> + dev_err(>dev, "FPGA manager is in use.\n");
> + return -EBUSY;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(fpga_mgr_lock);
> +
> +/**
> + * fpga_mgr_unlock - Unlock FPGA manager
> + * @mgr: fpga manager
> + */
> +void fpga_mgr_unlock(struct fpga_manager *mgr)
> +{
> + mutex_unlock(>ref_mutex);
> +}
> +EXPORT_SYMBOL_GPL(fpga_mgr_unlock);
> +
> +/**
>   * fpga_mgr_register - register a low level fpga manager driver
>   * @dev: fpga manager device from pdev
>   * @name:fpga manager name
> diff --git a/drivers/fpga/fpga-region.c b/drivers/fpga/fpga-region.c
> index 294556e..815f178 100644
> --- a/drivers/fpga/fpga-region.c
> +++ b/drivers/fpga/fpga-region.c
> @@ -125,7 +125,7 @@ static void fpga_region_put(struct fpga_region *region)
>  }
>  
>  /**
> - * fpga_region_get_manager - get exclusive reference for FPGA manager
> + * fpga_region_get_manager - get reference for FPGA manager
>   * @region: FPGA region
>   *
>   * Get FPGA Manager from "fpga-mgr" property or from ancestor region.
> @@ -245,10 +245,16 @@ static int fpga_region_program_fpga(struct fpga_region 
> *region,
>   return PTR_ERR(mgr);
>   }
>  
> + ret = fpga_mgr_lock(mgr);
> + if (ret) {
> + pr_err("FPGA manager is busy\n");

Am I missing something here, or could you use dev_err(>dev, ...)
here?

> + goto err_put_mgr;
> + }
> +
>   ret = fpga_region_get_bridges(region, overlay);
>   if (ret) {
>   pr_err("failed to get fpga region bridges\n");

Same here, (I know this is not part of this patch), maybe the above is
for consistency reasons then. Maybe I'm missing something.
> - goto err_put_mgr;
> + goto err_unlock_mgr;
>   }
>  
>   ret = fpga_bridges_disable(>bridge_list);
> @@ -269,6 +275,7 @@ static int fpga_region_program_fpga(struct fpga_region 
> *region,
>   goto err_put_br;
>   }
>  
> + fpga_mgr_unlock(mgr);
>   fpga_mgr_put(mgr);
>   fpga_region_put(region);
>  
> @@ -276,6 +283,8 @@ static int fpga_region_program_fpga(struct fpga_region 
> *region,
>  
>  err_put_br:
>   fpga_bridges_put(>bridge_list);
> +err_unlock_mgr:
> + fpga_mgr_unlock(mgr);
>  err_put_mgr:
>   fpga_mgr_put(mgr);
>   fpga_region_put(region);
> diff --git a/include/linux/fpga/fpga-mgr.h b/include/linux/fpga/fpga-mgr.h
> index 45df05a..ae970ca 100644
> --- a/include/linux/fpga/fpga-mgr.h
> +++ b/include/linux/fpga/fpga-mgr.h
> @@ -149,6 +149,9 @@ int fpga_mgr_firmware_load(struct fpga_manager *mgr,
>  
>  int fpga_mgr_load(struct fpga_manager *mgr, struct fpga_image_info *info);
>  
> +int fpga_mgr_lock(struct 

Re: [PATCH 4/5] fpga-mgr: separate getting/locking FPGA manager

[Moritz Fischer]

Hi Alan,

minor nits, inline

On Mon, Mar 13, 2017 at 04:53:32PM -0500, Alan Tull wrote:
> Add fpga_mgr_lock/unlock functions that get a mutex for
> exclusive use.
> 
> of_fpga_mgr_get, fpga_mgr_get, and fpga_mgr_put no longer lock
> the FPGA manager mutex.
> 
> This makes it more straightforward to save a reference to
> a FPGA manager and only attempting to lock it when programming
> the FPGA.
> 
> Signed-off-by: Alan Tull 
> ---
>  drivers/fpga/fpga-mgr.c   | 44 
> +++
>  drivers/fpga/fpga-region.c| 13 +++--
>  include/linux/fpga/fpga-mgr.h |  3 +++
>  3 files changed, 46 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
> index fde605b..f7c3648 100644
> --- a/drivers/fpga/fpga-mgr.c
> +++ b/drivers/fpga/fpga-mgr.c
> @@ -376,28 +376,19 @@ ATTRIBUTE_GROUPS(fpga_mgr);
>  struct fpga_manager *__fpga_mgr_get(struct device *dev)
>  {
>   struct fpga_manager *mgr;
> - int ret = -ENODEV;
>  
>   mgr = to_fpga_manager(dev);
>   if (!mgr)
>   goto err_dev;
>  
> - /* Get exclusive use of fpga manager */
> - if (!mutex_trylock(>ref_mutex)) {
> - ret = -EBUSY;
> - goto err_dev;
> - }
> -
>   if (!try_module_get(dev->parent->driver->owner))
> - goto err_ll_mod;
> + goto err_dev;
>  
>   return mgr;
>  
> -err_ll_mod:
> - mutex_unlock(>ref_mutex);
>  err_dev:
>   put_device(dev);
> - return ERR_PTR(ret);
> + return ERR_PTR(-ENODEV);
>  }
>  
>  static int fpga_mgr_dev_match(struct device *dev, const void *data)
> @@ -457,12 +448,41 @@ EXPORT_SYMBOL_GPL(of_fpga_mgr_get);
>  void fpga_mgr_put(struct fpga_manager *mgr)
>  {
>   module_put(mgr->dev.parent->driver->owner);
> - mutex_unlock(>ref_mutex);
>   put_device(>dev);
>  }
>  EXPORT_SYMBOL_GPL(fpga_mgr_put);
>  
>  /**
> + * fpga_mgr_lock - Lock FPGA manager for exclusive use
> + * @mgr: fpga manager
> + *
> + * Given a pointer to FPGA Manager (from fpga_mgr_get() or
> + * of_fpga_mgr_put()) attempt to get the mutex.
> + *
> + * Return: 0 for success or -EBUSY
> + */
> +int fpga_mgr_lock(struct fpga_manager *mgr)
> +{
> + if (!mutex_trylock(>ref_mutex)) {
> + dev_err(>dev, "FPGA manager is in use.\n");
> + return -EBUSY;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(fpga_mgr_lock);
> +
> +/**
> + * fpga_mgr_unlock - Unlock FPGA manager
> + * @mgr: fpga manager
> + */
> +void fpga_mgr_unlock(struct fpga_manager *mgr)
> +{
> + mutex_unlock(>ref_mutex);
> +}
> +EXPORT_SYMBOL_GPL(fpga_mgr_unlock);
> +
> +/**
>   * fpga_mgr_register - register a low level fpga manager driver
>   * @dev: fpga manager device from pdev
>   * @name:fpga manager name
> diff --git a/drivers/fpga/fpga-region.c b/drivers/fpga/fpga-region.c
> index 294556e..815f178 100644
> --- a/drivers/fpga/fpga-region.c
> +++ b/drivers/fpga/fpga-region.c
> @@ -125,7 +125,7 @@ static void fpga_region_put(struct fpga_region *region)
>  }
>  
>  /**
> - * fpga_region_get_manager - get exclusive reference for FPGA manager
> + * fpga_region_get_manager - get reference for FPGA manager
>   * @region: FPGA region
>   *
>   * Get FPGA Manager from "fpga-mgr" property or from ancestor region.
> @@ -245,10 +245,16 @@ static int fpga_region_program_fpga(struct fpga_region 
> *region,
>   return PTR_ERR(mgr);
>   }
>  
> + ret = fpga_mgr_lock(mgr);
> + if (ret) {
> + pr_err("FPGA manager is busy\n");

Am I missing something here, or could you use dev_err(>dev, ...)
here?

> + goto err_put_mgr;
> + }
> +
>   ret = fpga_region_get_bridges(region, overlay);
>   if (ret) {
>   pr_err("failed to get fpga region bridges\n");

Same here, (I know this is not part of this patch), maybe the above is
for consistency reasons then. Maybe I'm missing something.
> - goto err_put_mgr;
> + goto err_unlock_mgr;
>   }
>  
>   ret = fpga_bridges_disable(>bridge_list);
> @@ -269,6 +275,7 @@ static int fpga_region_program_fpga(struct fpga_region 
> *region,
>   goto err_put_br;
>   }
>  
> + fpga_mgr_unlock(mgr);
>   fpga_mgr_put(mgr);
>   fpga_region_put(region);
>  
> @@ -276,6 +283,8 @@ static int fpga_region_program_fpga(struct fpga_region 
> *region,
>  
>  err_put_br:
>   fpga_bridges_put(>bridge_list);
> +err_unlock_mgr:
> + fpga_mgr_unlock(mgr);
>  err_put_mgr:
>   fpga_mgr_put(mgr);
>   fpga_region_put(region);
> diff --git a/include/linux/fpga/fpga-mgr.h b/include/linux/fpga/fpga-mgr.h
> index 45df05a..ae970ca 100644
> --- a/include/linux/fpga/fpga-mgr.h
> +++ b/include/linux/fpga/fpga-mgr.h
> @@ -149,6 +149,9 @@ int fpga_mgr_firmware_load(struct fpga_manager *mgr,
>  
>  int fpga_mgr_load(struct fpga_manager *mgr, struct fpga_image_info *info);
>  
> +int fpga_mgr_lock(struct fpga_manager *mgr);
> +void 

Re: [PATCH] fpga fr br: fix warning for unexpected version number

[Moritz Fischer]

Hi Matthew,

On Wed, Apr 5, 2017 at 3:25 PM,   wrote:

>> Maybe you actually wanna bail out if you read a random other value
>> instead of what you
>> expect instead of printing a warning.
>
>
> I thought about making it an error if the version didn't match, but it was a
> dev_warn() before and that allowed folks to use the "old" driver with the
> new IP version.

Or some random other piece of logic in the FPGA that happens to be mapped
to that address ;-)

I agree we should've probably caught this in the initial review, but maybe we
should change it.

Cheers,

Moritz

Re: [PATCH] fpga fr br: fix warning for unexpected version number

[Moritz Fischer]

Hi Matthew,

On Wed, Apr 5, 2017 at 3:25 PM,   wrote:

>> Maybe you actually wanna bail out if you read a random other value
>> instead of what you
>> expect instead of printing a warning.
>
>
> I thought about making it an error if the version didn't match, but it was a
> dev_warn() before and that allowed folks to use the "old" driver with the
> new IP version.

Or some random other piece of logic in the FPGA that happens to be mapped
to that address ;-)

I agree we should've probably caught this in the initial review, but maybe we
should change it.

Cheers,

Moritz

Re: [PATCH] fpga fr br: fix warning for unexpected version number

[Moritz Fischer]

Hi Matthew,

On Wed, Apr 5, 2017 at 12:05 PM,   wrote:
> From: Matthew Gerlach 
>
> The value in the version register of the altera freeze bridge
> controller changed from the beta value of 2 to the
> value of 0xad03 in the official release of the IP.
> This patch supports the old and new version numbers
> without printing an warning.
>
> Signed-off-by: Matthew Gerlach 
> ---
>  drivers/fpga/altera-freeze-bridge.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/fpga/altera-freeze-bridge.c 
> b/drivers/fpga/altera-freeze-bridge.c
> index 8dcd9fb..bdfd5eb 100644
> --- a/drivers/fpga/altera-freeze-bridge.c
> +++ b/drivers/fpga/altera-freeze-bridge.c
> @@ -28,6 +28,7 @@
>  #define FREEZE_CSR_REG_VERSION 12
>
>  #define FREEZE_CSR_SUPPORTED_VERSION   2
> +#define FREEZE_CSR_OFFICIAL_VERSION0xad03
>
>  #define FREEZE_CSR_STATUS_FREEZE_REQ_DONE  BIT(0)
>  #define FREEZE_CSR_STATUS_UNFREEZE_REQ_DONEBIT(1)
> @@ -241,10 +242,12 @@ static int altera_freeze_br_probe(struct 
> platform_device *pdev)
> priv->enable = 1;
>
> revision = readl(priv->base_addr + FREEZE_CSR_REG_VERSION);
> -   if (revision != FREEZE_CSR_SUPPORTED_VERSION)
> +   if ((revision != FREEZE_CSR_SUPPORTED_VERSION) &&
> +   (revision != FREEZE_CSR_OFFICIAL_VERSION))
> dev_warn(dev,
> -"%s Freeze Controller unexpected revision %d != 
> %d\n",
> -__func__, revision, FREEZE_CSR_SUPPORTED_VERSION);
> +"%s unexpected revision 0x%x != 0x%x != 0x%x\n",
> +__func__, revision, FREEZE_CSR_SUPPORTED_VERSION,
> +FREEZE_CSR_OFFICIAL_VERSION);

Maybe you actually wanna bail out if you read a random other value
instead of what you
expect instead of printing a warning.
>
> return fpga_bridge_register(dev, FREEZE_BRIDGE_NAME,
> _freeze_br_br_ops, priv);
> --
> 2.7.4
>

Cheers,

Moritz

Re: [PATCH] fpga fr br: fix warning for unexpected version number

[Moritz Fischer]

Hi Matthew,

On Wed, Apr 5, 2017 at 12:05 PM,   wrote:
> From: Matthew Gerlach 
>
> The value in the version register of the altera freeze bridge
> controller changed from the beta value of 2 to the
> value of 0xad03 in the official release of the IP.
> This patch supports the old and new version numbers
> without printing an warning.
>
> Signed-off-by: Matthew Gerlach 
> ---
>  drivers/fpga/altera-freeze-bridge.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/fpga/altera-freeze-bridge.c 
> b/drivers/fpga/altera-freeze-bridge.c
> index 8dcd9fb..bdfd5eb 100644
> --- a/drivers/fpga/altera-freeze-bridge.c
> +++ b/drivers/fpga/altera-freeze-bridge.c
> @@ -28,6 +28,7 @@
>  #define FREEZE_CSR_REG_VERSION 12
>
>  #define FREEZE_CSR_SUPPORTED_VERSION   2
> +#define FREEZE_CSR_OFFICIAL_VERSION0xad03
>
>  #define FREEZE_CSR_STATUS_FREEZE_REQ_DONE  BIT(0)
>  #define FREEZE_CSR_STATUS_UNFREEZE_REQ_DONEBIT(1)
> @@ -241,10 +242,12 @@ static int altera_freeze_br_probe(struct 
> platform_device *pdev)
> priv->enable = 1;
>
> revision = readl(priv->base_addr + FREEZE_CSR_REG_VERSION);
> -   if (revision != FREEZE_CSR_SUPPORTED_VERSION)
> +   if ((revision != FREEZE_CSR_SUPPORTED_VERSION) &&
> +   (revision != FREEZE_CSR_OFFICIAL_VERSION))
> dev_warn(dev,
> -"%s Freeze Controller unexpected revision %d != 
> %d\n",
> -__func__, revision, FREEZE_CSR_SUPPORTED_VERSION);
> +"%s unexpected revision 0x%x != 0x%x != 0x%x\n",
> +__func__, revision, FREEZE_CSR_SUPPORTED_VERSION,
> +FREEZE_CSR_OFFICIAL_VERSION);

Maybe you actually wanna bail out if you read a random other value
instead of what you
expect instead of printing a warning.
>
> return fpga_bridge_register(dev, FREEZE_BRIDGE_NAME,
> _freeze_br_br_ops, priv);
> --
> 2.7.4
>

Cheers,

Moritz

Re: [PATCH 1/2] doc: Add bindings document for Xilinx LogiCore PR Decoupler

[Moritz Fischer]

On Thu, Mar 30, 2017 at 05:44:29PM -0500, Rob Herring wrote:
> On Fri, Mar 24, 2017 at 10:33:20AM -0500, Alan Tull wrote:
> > From: Moritz Fischer <m...@kernel.org>
>
> Please use "dt-bindings: fpga: ..." for the subject.
>
>
> >
> > This adds the binding documentation for the Xilinx LogiCORE PR
> > Decoupler soft core.
> >
> > Signed-off-by: Moritz Fischer <m...@kernel.org>
> > Signed-off-by: Michal Simek <michal.si...@xilinx.com>
> > Acked-by: Alan Tull <at...@kernel.org>
>
> I'm confused why you are sending these instead of Moritz? If it goes
> through you, then it should have your S-o-B too.

Do you want me to resend this Alan (with Rob's suggestions)?
>
> > Cc: Sören Brinkmann <soren.brinkm...@xilinx.com>
> > Cc: linux-kernel@vger.kernel.org
> > Cc: devicet...@vger.kernel.org
> > ---
> >  .../bindings/fpga/xilinx-pr-decoupler.txt  | 35 
> > ++
> >  1 file changed, 35 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
> >
> > diff --git a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt 
> > b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
> > new file mode 100644
> > index ..2c527ac30398
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
> > @@ -0,0 +1,35 @@
> > +Xilinx LogiCORE Partial Reconfig Decoupler Softcore
> > +
> > +The Xilinx LogiCORE Partial Reconfig Decoupler manages one or more
> > +decouplers / fpga bridges.
> > +The controller can decouple/disable the bridges which prevents signal
> > +changes from passing through the bridge.  The controller can also
> > +couple / enable the bridges which allows traffic to pass through the
> > +bridge normally.
> > +
> > +The Driver supports only MMIO handling. A PR region can have multiple
> > +PR Decouplers which can be handled independently or chained via decouple/
> > +decouple_status signals.
> > +
> > +Required properties:
> > +- compatible : Should contain "xlnx,pr-decoupler-1.00" or 
> > "xlnx,pr-decoupler"
>
> I'd drop xlnx,pr-decoupler, but in any case, it should not be OR rather
> "followed by". Plus the example has both.

Michal wanted to have both, so I put both. Personally I don't care. I
think they have some downstream stuff that relied on it.

>
> > +- regs : base address and size for decoupler module
> > +- clocks : input clock to IP
> > +- clock-names : should contain "aclk"
> > +
> > +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.
> > +
> > +See Documentation/devicetree/bindings/fpga/fpga-region.txt for generic 
> > bindings.
> > +
> > +Example:
> > + fpga-bridge@10450 {
> > + compatible = "xlnx,pr-decoupler-1.00",
> > + "xlnx-pr-decoupler";
> > + regs = <0x1045 0x10>;
> > + clocks = < 15>;
> > + clock-names = "aclk";
> > + bridge-enable = <0>;
> > + };
> > --
> > 2.11.0
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

Thanks,
Moritz

Re: [PATCH 1/2] doc: Add bindings document for Xilinx LogiCore PR Decoupler

[Moritz Fischer]

On Thu, Mar 30, 2017 at 05:44:29PM -0500, Rob Herring wrote:
> On Fri, Mar 24, 2017 at 10:33:20AM -0500, Alan Tull wrote:
> > From: Moritz Fischer 
>
> Please use "dt-bindings: fpga: ..." for the subject.
>
>
> >
> > This adds the binding documentation for the Xilinx LogiCORE PR
> > Decoupler soft core.
> >
> > Signed-off-by: Moritz Fischer 
> > Signed-off-by: Michal Simek 
> > Acked-by: Alan Tull 
>
> I'm confused why you are sending these instead of Moritz? If it goes
> through you, then it should have your S-o-B too.

Do you want me to resend this Alan (with Rob's suggestions)?
>
> > Cc: Sören Brinkmann 
> > Cc: linux-kernel@vger.kernel.org
> > Cc: devicet...@vger.kernel.org
> > ---
> >  .../bindings/fpga/xilinx-pr-decoupler.txt  | 35 
> > ++
> >  1 file changed, 35 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
> >
> > diff --git a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt 
> > b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
> > new file mode 100644
> > index ..2c527ac30398
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
> > @@ -0,0 +1,35 @@
> > +Xilinx LogiCORE Partial Reconfig Decoupler Softcore
> > +
> > +The Xilinx LogiCORE Partial Reconfig Decoupler manages one or more
> > +decouplers / fpga bridges.
> > +The controller can decouple/disable the bridges which prevents signal
> > +changes from passing through the bridge.  The controller can also
> > +couple / enable the bridges which allows traffic to pass through the
> > +bridge normally.
> > +
> > +The Driver supports only MMIO handling. A PR region can have multiple
> > +PR Decouplers which can be handled independently or chained via decouple/
> > +decouple_status signals.
> > +
> > +Required properties:
> > +- compatible : Should contain "xlnx,pr-decoupler-1.00" or 
> > "xlnx,pr-decoupler"
>
> I'd drop xlnx,pr-decoupler, but in any case, it should not be OR rather
> "followed by". Plus the example has both.

Michal wanted to have both, so I put both. Personally I don't care. I
think they have some downstream stuff that relied on it.

>
> > +- regs : base address and size for decoupler module
> > +- clocks : input clock to IP
> > +- clock-names : should contain "aclk"
> > +
> > +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.
> > +
> > +See Documentation/devicetree/bindings/fpga/fpga-region.txt for generic 
> > bindings.
> > +
> > +Example:
> > + fpga-bridge@10450 {
> > + compatible = "xlnx,pr-decoupler-1.00",
> > + "xlnx-pr-decoupler";
> > + regs = <0x1045 0x10>;
> > + clocks = < 15>;
> > + clock-names = "aclk";
> > + bridge-enable = <0>;
> > + };
> > --
> > 2.11.0
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

Thanks,
Moritz

Re: [PATCH 04/16] fpga: intel: pcie: parse feature list and create platform device for features.

[Moritz Fischer]

Xiao,

few nits inline, I'll need to come back to this once I went over the
rest of the patchset ;-)

On Thu, Mar 30, 2017 at 08:08:04PM +0800, Wu Hao wrote:
> From: Xiao Guangrong 
> 
> Device Featuer List structure creates a link list of feature headers
> within the MMIO space to provide an extensiable way of adding features.
> 
> The Intel FPGA PCIe driver walks through the feature headers to enumerate
> feature devices, FPGA Management Engine (FME) and FPGA Port for Accelerated
> Function Unit (AFU), and their private sub features. For feature devices,
> it creates the platform devices and linked the private sub features into
> their platform data.
> 
> Signed-off-by: Tim Whisonant 
> Signed-off-by: Enno Luebbers 
> Signed-off-by: Shiva Rao 
> Signed-off-by: Christopher Rauer 
> Signed-off-by: Kang Luwei 
> Signed-off-by: Zhang Yi 
> Signed-off-by: Xiao Guangrong 
> Signed-off-by: Wu Hao 
> ---
>  drivers/fpga/intel/Makefile  |   2 +-
>  drivers/fpga/intel/feature-dev.c | 139 +++
>  drivers/fpga/intel/feature-dev.h | 342 
>  drivers/fpga/intel/pcie.c| 841 
> ++-
>  4 files changed, 1321 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/fpga/intel/feature-dev.c
>  create mode 100644 drivers/fpga/intel/feature-dev.h
> 
> diff --git a/drivers/fpga/intel/Makefile b/drivers/fpga/intel/Makefile
> index 61fd8ea..c029940 100644
> --- a/drivers/fpga/intel/Makefile
> +++ b/drivers/fpga/intel/Makefile
> @@ -1,3 +1,3 @@
>  obj-$(CONFIG_INTEL_FPGA_PCI) += intel-fpga-pci.o
>  
> -intel-fpga-pci-objs := pcie.o
> +intel-fpga-pci-objs := pcie.o feature-dev.o
> diff --git a/drivers/fpga/intel/feature-dev.c 
> b/drivers/fpga/intel/feature-dev.c
> new file mode 100644
> index 000..6952566
> --- /dev/null
> +++ b/drivers/fpga/intel/feature-dev.c
> @@ -0,0 +1,139 @@
> +/*
> + * Intel FPGA Feature Device Driver
> + *
> + * Copyright (C) 2017 Intel Corporation, Inc.
> + *
> + * Authors:
> + *   Kang Luwei 
> + *   Zhang Yi 
> + *   Wu Hao 
> + *   Xiao Guangrong 
> + *
> + * This work is licensed under a dual BSD/GPLv2 license. When using or
> + * redistributing this file, you may do so under either license. See the
> + * LICENSE.BSD file under this directory for the BSD license and see
> + * the COPYING file in the top-level directory for the GPLv2 license.
> + */
> +
> +#include "feature-dev.h"
> +
> +void feature_platform_data_add(struct feature_platform_data *pdata,
> +int index, const char *name,
> +int resource_index, void __iomem *ioaddr)
> +{
> + WARN_ON(index >= pdata->num);
> +
> + pdata->features[index].name = name;
> + pdata->features[index].resource_index = resource_index;
> + pdata->features[index].ioaddr = ioaddr;
> +}
> +
> +int feature_platform_data_size(int num)

static inline? num can be const

> +{
> + return sizeof(struct feature_platform_data) +
> + num * sizeof(struct feature);
> +}
> +
> +struct feature_platform_data *
> +feature_platform_data_alloc_and_init(struct platform_device *dev, int num)
> +{
> + struct feature_platform_data *pdata;
> +
> + pdata = kzalloc(feature_platform_data_size(num), GFP_KERNEL);
> + if (pdata) {
> + pdata->dev = dev;
> + pdata->num = num;
> + mutex_init(>lock);
> + }
> +
> + return pdata;
> +}
> +
> +int fme_feature_num(void)

is this used outside of this file? if not -> static
> +{
> + return FME_FEATURE_ID_MAX;
> +}
> +
> +int port_feature_num(void)

is this used outside of this file? if not -> static
> +{
> + return PORT_FEATURE_ID_MAX;
> +}
> +
> +int fpga_port_id(struct platform_device *pdev)
> +{
> + struct feature_port_header *port_hdr;
> + struct feature_port_capability capability;
> +
> + port_hdr = get_feature_ioaddr_by_index(>dev,
> +PORT_FEATURE_ID_HEADER);
> + WARN_ON(!port_hdr);
> +
> + capability.csr = readq(_hdr->capability);
> + return capability.port_number;
> +}
> +EXPORT_SYMBOL_GPL(fpga_port_id);
> +
> +/*
> + * Enable Port by clear the port soft reset bit, which is set by default.
> + * The User AFU is unable to respond to any MMIO access while in reset.
> + * __fpga_port_enable function should only be used after __fpga_port_disable
> + * function.
> + */
> +void __fpga_port_enable(struct platform_device *pdev)
> +{
> + struct feature_platform_data *pdata = dev_get_platdata(>dev);
> + struct feature_port_header *port_hdr;
> + struct feature_port_control control;
> +
> + WARN_ON(!pdata->disable_count);
> +
> + if 

Re: [PATCH 04/16] fpga: intel: pcie: parse feature list and create platform device for features.

[Moritz Fischer]

Xiao,

few nits inline, I'll need to come back to this once I went over the
rest of the patchset ;-)

On Thu, Mar 30, 2017 at 08:08:04PM +0800, Wu Hao wrote:
> From: Xiao Guangrong 
> 
> Device Featuer List structure creates a link list of feature headers
> within the MMIO space to provide an extensiable way of adding features.
> 
> The Intel FPGA PCIe driver walks through the feature headers to enumerate
> feature devices, FPGA Management Engine (FME) and FPGA Port for Accelerated
> Function Unit (AFU), and their private sub features. For feature devices,
> it creates the platform devices and linked the private sub features into
> their platform data.
> 
> Signed-off-by: Tim Whisonant 
> Signed-off-by: Enno Luebbers 
> Signed-off-by: Shiva Rao 
> Signed-off-by: Christopher Rauer 
> Signed-off-by: Kang Luwei 
> Signed-off-by: Zhang Yi 
> Signed-off-by: Xiao Guangrong 
> Signed-off-by: Wu Hao 
> ---
>  drivers/fpga/intel/Makefile  |   2 +-
>  drivers/fpga/intel/feature-dev.c | 139 +++
>  drivers/fpga/intel/feature-dev.h | 342 
>  drivers/fpga/intel/pcie.c| 841 
> ++-
>  4 files changed, 1321 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/fpga/intel/feature-dev.c
>  create mode 100644 drivers/fpga/intel/feature-dev.h
> 
> diff --git a/drivers/fpga/intel/Makefile b/drivers/fpga/intel/Makefile
> index 61fd8ea..c029940 100644
> --- a/drivers/fpga/intel/Makefile
> +++ b/drivers/fpga/intel/Makefile
> @@ -1,3 +1,3 @@
>  obj-$(CONFIG_INTEL_FPGA_PCI) += intel-fpga-pci.o
>  
> -intel-fpga-pci-objs := pcie.o
> +intel-fpga-pci-objs := pcie.o feature-dev.o
> diff --git a/drivers/fpga/intel/feature-dev.c 
> b/drivers/fpga/intel/feature-dev.c
> new file mode 100644
> index 000..6952566
> --- /dev/null
> +++ b/drivers/fpga/intel/feature-dev.c
> @@ -0,0 +1,139 @@
> +/*
> + * Intel FPGA Feature Device Driver
> + *
> + * Copyright (C) 2017 Intel Corporation, Inc.
> + *
> + * Authors:
> + *   Kang Luwei 
> + *   Zhang Yi 
> + *   Wu Hao 
> + *   Xiao Guangrong 
> + *
> + * This work is licensed under a dual BSD/GPLv2 license. When using or
> + * redistributing this file, you may do so under either license. See the
> + * LICENSE.BSD file under this directory for the BSD license and see
> + * the COPYING file in the top-level directory for the GPLv2 license.
> + */
> +
> +#include "feature-dev.h"
> +
> +void feature_platform_data_add(struct feature_platform_data *pdata,
> +int index, const char *name,
> +int resource_index, void __iomem *ioaddr)
> +{
> + WARN_ON(index >= pdata->num);
> +
> + pdata->features[index].name = name;
> + pdata->features[index].resource_index = resource_index;
> + pdata->features[index].ioaddr = ioaddr;
> +}
> +
> +int feature_platform_data_size(int num)

static inline? num can be const

> +{
> + return sizeof(struct feature_platform_data) +
> + num * sizeof(struct feature);
> +}
> +
> +struct feature_platform_data *
> +feature_platform_data_alloc_and_init(struct platform_device *dev, int num)
> +{
> + struct feature_platform_data *pdata;
> +
> + pdata = kzalloc(feature_platform_data_size(num), GFP_KERNEL);
> + if (pdata) {
> + pdata->dev = dev;
> + pdata->num = num;
> + mutex_init(>lock);
> + }
> +
> + return pdata;
> +}
> +
> +int fme_feature_num(void)

is this used outside of this file? if not -> static
> +{
> + return FME_FEATURE_ID_MAX;
> +}
> +
> +int port_feature_num(void)

is this used outside of this file? if not -> static
> +{
> + return PORT_FEATURE_ID_MAX;
> +}
> +
> +int fpga_port_id(struct platform_device *pdev)
> +{
> + struct feature_port_header *port_hdr;
> + struct feature_port_capability capability;
> +
> + port_hdr = get_feature_ioaddr_by_index(>dev,
> +PORT_FEATURE_ID_HEADER);
> + WARN_ON(!port_hdr);
> +
> + capability.csr = readq(_hdr->capability);
> + return capability.port_number;
> +}
> +EXPORT_SYMBOL_GPL(fpga_port_id);
> +
> +/*
> + * Enable Port by clear the port soft reset bit, which is set by default.
> + * The User AFU is unable to respond to any MMIO access while in reset.
> + * __fpga_port_enable function should only be used after __fpga_port_disable
> + * function.
> + */
> +void __fpga_port_enable(struct platform_device *pdev)
> +{
> + struct feature_platform_data *pdata = dev_get_platdata(>dev);
> + struct feature_port_header *port_hdr;
> + struct feature_port_control control;
> +
> + WARN_ON(!pdata->disable_count);
> +
> + if (--pdata->disable_count != 0)
> + return;
> +
> + port_hdr = get_feature_ioaddr_by_index(>dev,
> +PORT_FEATURE_ID_HEADER);
> + WARN_ON(!port_hdr);
> +
> + control.csr = readq(_hdr->control);
> + control.port_sftrst = 0x0;
> + writeq(control.csr, 

Re: [PATCH 03/16] fpga: intel: add FPGA PCIe device driver

[Moritz Fischer]

On Thu, Mar 30, 2017 at 08:08:03PM +0800, Wu Hao wrote:
> From: Zhang Yi 
> 
> The Intel FPGA device appears as a PCIe device on the system. This patch
> implements the basic framework of the driver for Intel PCIe device which
> locates between CPU and Accelerated Function Units (AFUs).
> 
> Signed-off-by: Tim Whisonant 
> Signed-off-by: Enno Luebbers 
> Signed-off-by: Shiva Rao 
> Signed-off-by: Christopher Rauer 
> Signed-off-by: Zhang Yi 
> Signed-off-by: Xiao Guangrong 
> Signed-off-by: Wu Hao 
> ---
>  drivers/fpga/Kconfig   |   2 +
>  drivers/fpga/Makefile  |   3 +
>  drivers/fpga/intel/Kconfig |  27 +
>  drivers/fpga/intel/LICENSE.BSD |  24 
>  drivers/fpga/intel/Makefile|   3 +
>  drivers/fpga/intel/pcie.c  | 129 
> +
>  6 files changed, 188 insertions(+)
>  create mode 100644 drivers/fpga/intel/Kconfig
>  create mode 100644 drivers/fpga/intel/LICENSE.BSD
>  create mode 100644 drivers/fpga/intel/Makefile
>  create mode 100644 drivers/fpga/intel/pcie.c
> 
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index d99b640..4e49aee 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -69,6 +69,8 @@ config ALTERA_FREEZE_BRIDGE
> isolate one region of the FPGA from the busses while that
> region is being reprogrammed.
>  
> +source "drivers/fpga/intel/Kconfig"
> +
>  endif # FPGA
>  
>  endmenu
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index 53a41d2..46f1a5d 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -20,3 +20,6 @@ obj-$(CONFIG_ALTERA_FREEZE_BRIDGE)  += 
> altera-freeze-bridge.o
>  
>  # High Level Interfaces
>  obj-$(CONFIG_FPGA_REGION)+= fpga-region.o
> +
> +# Intel FPGA Support
> +obj-$(CONFIG_INTEL_FPGA) += intel/
> diff --git a/drivers/fpga/intel/Kconfig b/drivers/fpga/intel/Kconfig
> new file mode 100644
> index 000..bf402f3
> --- /dev/null
> +++ b/drivers/fpga/intel/Kconfig
> @@ -0,0 +1,27 @@
> +menuconfig INTEL_FPGA
> + tristate "Intel(R) FPGA support"
> + depends on FPGA_DEVICE
> + help
> +   Select this option to enable driver support for Intel(R)
> +   Field-Programmable Gate Array (FPGA) solutions. This driver
> +   provides interfaces for userspace applications to configure,
> +   enumerate, open, and access FPGA accelerators on platforms
> +   equipped with Intel(R) FPGA solutions and enables system
> +   level management functions such as FPGA reconfiguration,
> +   power management, and virtualization.
> +
> +   Say Y if your platform has this technology. Say N if unsure.
> +
> +if INTEL_FPGA
> +
> +config INTEL_FPGA_PCI
> + tristate "Intel FPGA PCIe Driver"
> + depends on PCI
> + help
> +   This is the driver for the PCIe device which locates between
> +   CPU and Accelerated Function Units (AFUs) and allows them to
> +   communicate with each other.
> +
> +   To compile this as a module, choose M here.
> +
> +endif
> diff --git a/drivers/fpga/intel/LICENSE.BSD b/drivers/fpga/intel/LICENSE.BSD
> new file mode 100644
> index 000..309d2b7
> --- /dev/null
> +++ b/drivers/fpga/intel/LICENSE.BSD
> @@ -0,0 +1,24 @@
> +Redistribution and use in source and binary forms, with or without
> +modification, are permitted provided that the following conditions
> +are met:
> +  * Redistributions of source code must retain the above copyright
> +notice, this list of conditions and the following disclaimer.
> +  * Redistributions in binary form must reproduce the above copyright
> +notice, this list of conditions and the following disclaimer in
> +the documentation and/or other materials provided with the
> +distribution.
> +  * Neither the name of Intel Corporation nor the names of its
> +contributors may be used to endorse or promote products derived
> +from this software without specific prior written permission.
> +
> +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> +"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> +LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> +A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> +OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> +SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> +LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> +OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> diff --git 

Re: [PATCH 03/16] fpga: intel: add FPGA PCIe device driver

[Moritz Fischer]

On Thu, Mar 30, 2017 at 08:08:03PM +0800, Wu Hao wrote:
> From: Zhang Yi 
> 
> The Intel FPGA device appears as a PCIe device on the system. This patch
> implements the basic framework of the driver for Intel PCIe device which
> locates between CPU and Accelerated Function Units (AFUs).
> 
> Signed-off-by: Tim Whisonant 
> Signed-off-by: Enno Luebbers 
> Signed-off-by: Shiva Rao 
> Signed-off-by: Christopher Rauer 
> Signed-off-by: Zhang Yi 
> Signed-off-by: Xiao Guangrong 
> Signed-off-by: Wu Hao 
> ---
>  drivers/fpga/Kconfig   |   2 +
>  drivers/fpga/Makefile  |   3 +
>  drivers/fpga/intel/Kconfig |  27 +
>  drivers/fpga/intel/LICENSE.BSD |  24 
>  drivers/fpga/intel/Makefile|   3 +
>  drivers/fpga/intel/pcie.c  | 129 
> +
>  6 files changed, 188 insertions(+)
>  create mode 100644 drivers/fpga/intel/Kconfig
>  create mode 100644 drivers/fpga/intel/LICENSE.BSD
>  create mode 100644 drivers/fpga/intel/Makefile
>  create mode 100644 drivers/fpga/intel/pcie.c
> 
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index d99b640..4e49aee 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -69,6 +69,8 @@ config ALTERA_FREEZE_BRIDGE
> isolate one region of the FPGA from the busses while that
> region is being reprogrammed.
>  
> +source "drivers/fpga/intel/Kconfig"
> +
>  endif # FPGA
>  
>  endmenu
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index 53a41d2..46f1a5d 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -20,3 +20,6 @@ obj-$(CONFIG_ALTERA_FREEZE_BRIDGE)  += 
> altera-freeze-bridge.o
>  
>  # High Level Interfaces
>  obj-$(CONFIG_FPGA_REGION)+= fpga-region.o
> +
> +# Intel FPGA Support
> +obj-$(CONFIG_INTEL_FPGA) += intel/
> diff --git a/drivers/fpga/intel/Kconfig b/drivers/fpga/intel/Kconfig
> new file mode 100644
> index 000..bf402f3
> --- /dev/null
> +++ b/drivers/fpga/intel/Kconfig
> @@ -0,0 +1,27 @@
> +menuconfig INTEL_FPGA
> + tristate "Intel(R) FPGA support"
> + depends on FPGA_DEVICE
> + help
> +   Select this option to enable driver support for Intel(R)
> +   Field-Programmable Gate Array (FPGA) solutions. This driver
> +   provides interfaces for userspace applications to configure,
> +   enumerate, open, and access FPGA accelerators on platforms
> +   equipped with Intel(R) FPGA solutions and enables system
> +   level management functions such as FPGA reconfiguration,
> +   power management, and virtualization.
> +
> +   Say Y if your platform has this technology. Say N if unsure.
> +
> +if INTEL_FPGA
> +
> +config INTEL_FPGA_PCI
> + tristate "Intel FPGA PCIe Driver"
> + depends on PCI
> + help
> +   This is the driver for the PCIe device which locates between
> +   CPU and Accelerated Function Units (AFUs) and allows them to
> +   communicate with each other.
> +
> +   To compile this as a module, choose M here.
> +
> +endif
> diff --git a/drivers/fpga/intel/LICENSE.BSD b/drivers/fpga/intel/LICENSE.BSD
> new file mode 100644
> index 000..309d2b7
> --- /dev/null
> +++ b/drivers/fpga/intel/LICENSE.BSD
> @@ -0,0 +1,24 @@
> +Redistribution and use in source and binary forms, with or without
> +modification, are permitted provided that the following conditions
> +are met:
> +  * Redistributions of source code must retain the above copyright
> +notice, this list of conditions and the following disclaimer.
> +  * Redistributions in binary form must reproduce the above copyright
> +notice, this list of conditions and the following disclaimer in
> +the documentation and/or other materials provided with the
> +distribution.
> +  * Neither the name of Intel Corporation nor the names of its
> +contributors may be used to endorse or promote products derived
> +from this software without specific prior written permission.
> +
> +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> +"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> +LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> +A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> +OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> +SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> +LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> +DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> +THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> +OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> diff --git a/drivers/fpga/intel/Makefile b/drivers/fpga/intel/Makefile
> new file mode 100644
> index 000..61fd8ea
> --- /dev/null
> +++ b/drivers/fpga/intel/Makefile
> @@ -0,0 +1,3 @@
> 

Re: [PATCH 01/16] docs: fpga: add a document for Intel FPGA driver overview

[Moritz Fischer]

On Sat, Apr 01, 2017 at 07:16:19PM +0800, Wu Hao wrote:
> On Fri, Mar 31, 2017 at 01:38:06PM -0500, Alan Tull wrote:
> > On Fri, Mar 31, 2017 at 1:24 PM,   wrote:
> > >
> > >
> > > On Thu, 30 Mar 2017, Wu Hao wrote:
> > >
> > >
> > > Hi Wu Hao,
> > >
> > > Great documentation. I'm looking forward to diving into the rest of the
> > > patches. Please see my comments inline.
> > >
> > > Matthew Gerlach
> > >
> > >
> > >> Add a document for Intel FPGA driver overview.
> > >>
> > >> Signed-off-by: Enno Luebbers 
> > >> Signed-off-by: Xiao Guangrong 
> > >> Signed-off-by: Wu Hao 
> > >> ---
> > >> Documentation/fpga/intel-fpga.txt | 259
> > >> ++
> > >> 1 file changed, 259 insertions(+)
> > >> create mode 100644 Documentation/fpga/intel-fpga.txt
> > >>
> > >> diff --git a/Documentation/fpga/intel-fpga.txt
> > >> b/Documentation/fpga/intel-fpga.txt
> > >> new file mode 100644
> > >> index 000..9396cea
> > >> --- /dev/null
> > >> +++ b/Documentation/fpga/intel-fpga.txt
> > >> @@ -0,0 +1,259 @@
> > >>
> > >> +===
> > >> +Intel FPGA driver Overview
> > >>
> > >> +---
> > >> +Enno Luebbers 
> > >> +Xiao Guangrong 
> > >> +Wu Hao 
> > >> +
> > >> +The Intel FPGA driver provides interfaces for userspace applications to
> > >> +configure, enumerate, open, and access FPGA accelerators on platforms
> > >> equipped
> > >> +with Intel(R) FPGA solutions and enables system level management
> > >> functions such
> > >> +as FPGA reconfiguration, power management, and virtualization.
> > >> +
> > >
> > >
> > > From a Linux kernel perspective, I'm not sure this is the best name for
> > > this code.  The name gives me the impression that it is a driver for all
> > > Intel FPGAs, but not all Intel FPGAs are connected to the processor over a
> > > PCIe bus.  The processor could be directely connected like the Arria10
> > > SOCFPGA.  Such a processor could certainly benefit from this accelerator
> > > usage model.  In an extreme case, couldn't a processor in the FPGA,
> > > running Linux, also benefit from this accelerator model?  Is this code a
> > > "FPGA Accelerator Framework"?
> > >
> > >> +HW Architecture
> > >> +===
> > >> +From the OS's point of view, the FPGA hardware appears as a regular PCIe
> > >> device.
> > >> +The FPGA device memory is organized using a predefined data structure
> > >> (Device
> > >> +Feature List). Features supported by the particular FPGA device are
> > >> exposed
> > >> +through these data structures, as illustrated below:
> > >> +
> > >> +  +---+  +-+
> > >> +  |  PF   |  | VF  |
> > >> +  +---+  +-+
> > >> +  ^^ ^  ^
> > >> +  || |  |
> > >> ++-||-|--|---+
> > >> +| || |  |   |
> > >> +|  +-+ +---+ +---+  +---+   |
> > >> +|  | FME | | Port0 | | Port1 |  | Port2 |   |
> > >> +|  +-+ +---+ +---+  +---+   |
> > >> +|  ^ ^  ^   |
> > >> +|  | |  |   |
> > >> +|  +---+ +--+   +---+   |
> > >> +|  |  AFU  | |  AFU |   |  AFU  |   |
> > >> +|  +---+ +--+   +---+   |
> > >> +|   |
> > >> +| FPGA PCIe Device  |
> > >> ++---+
> > >> +
> > >> +The driver supports PCIe SR-IOV to create virtual functions (VFs) which
> > >> can be
> > >> +used to assign individual accelerators to virtual machines .
> > >
> > >
> > > Does this HW Architecture require an Intel FPGA?  Couldn't any vendors 
> > > FPGA
> > > be used as long as it presented itself the PCIe bus the same and contained
> > > an appropriate Device Feature List?

I think this is a good (and important) point. Especially when sysfs
entries & ioctls constituting ABI depend on it.

> > >
> > >> +
> > >> +FME (FPGA Management Engine)
> > >> +
> > >> +The FPGA Management Enging performs power and thermal management, error
Enging->Engine
> > >> +reporting, reconfiguration, performance reporting, and other
> > >> infrastructure
> > >> +functions. Each FPGA has one FME, which is always accessed through the
> > >> physical
> > >> +function (PF).
> > >> +
> > >> +User-space applications can acquire 

Re: [PATCH 01/16] docs: fpga: add a document for Intel FPGA driver overview

[Moritz Fischer]

On Sat, Apr 01, 2017 at 07:16:19PM +0800, Wu Hao wrote:
> On Fri, Mar 31, 2017 at 01:38:06PM -0500, Alan Tull wrote:
> > On Fri, Mar 31, 2017 at 1:24 PM,   wrote:
> > >
> > >
> > > On Thu, 30 Mar 2017, Wu Hao wrote:
> > >
> > >
> > > Hi Wu Hao,
> > >
> > > Great documentation. I'm looking forward to diving into the rest of the
> > > patches. Please see my comments inline.
> > >
> > > Matthew Gerlach
> > >
> > >
> > >> Add a document for Intel FPGA driver overview.
> > >>
> > >> Signed-off-by: Enno Luebbers 
> > >> Signed-off-by: Xiao Guangrong 
> > >> Signed-off-by: Wu Hao 
> > >> ---
> > >> Documentation/fpga/intel-fpga.txt | 259
> > >> ++
> > >> 1 file changed, 259 insertions(+)
> > >> create mode 100644 Documentation/fpga/intel-fpga.txt
> > >>
> > >> diff --git a/Documentation/fpga/intel-fpga.txt
> > >> b/Documentation/fpga/intel-fpga.txt
> > >> new file mode 100644
> > >> index 000..9396cea
> > >> --- /dev/null
> > >> +++ b/Documentation/fpga/intel-fpga.txt
> > >> @@ -0,0 +1,259 @@
> > >>
> > >> +===
> > >> +Intel FPGA driver Overview
> > >>
> > >> +---
> > >> +Enno Luebbers 
> > >> +Xiao Guangrong 
> > >> +Wu Hao 
> > >> +
> > >> +The Intel FPGA driver provides interfaces for userspace applications to
> > >> +configure, enumerate, open, and access FPGA accelerators on platforms
> > >> equipped
> > >> +with Intel(R) FPGA solutions and enables system level management
> > >> functions such
> > >> +as FPGA reconfiguration, power management, and virtualization.
> > >> +
> > >
> > >
> > > From a Linux kernel perspective, I'm not sure this is the best name for
> > > this code.  The name gives me the impression that it is a driver for all
> > > Intel FPGAs, but not all Intel FPGAs are connected to the processor over a
> > > PCIe bus.  The processor could be directely connected like the Arria10
> > > SOCFPGA.  Such a processor could certainly benefit from this accelerator
> > > usage model.  In an extreme case, couldn't a processor in the FPGA,
> > > running Linux, also benefit from this accelerator model?  Is this code a
> > > "FPGA Accelerator Framework"?
> > >
> > >> +HW Architecture
> > >> +===
> > >> +From the OS's point of view, the FPGA hardware appears as a regular PCIe
> > >> device.
> > >> +The FPGA device memory is organized using a predefined data structure
> > >> (Device
> > >> +Feature List). Features supported by the particular FPGA device are
> > >> exposed
> > >> +through these data structures, as illustrated below:
> > >> +
> > >> +  +---+  +-+
> > >> +  |  PF   |  | VF  |
> > >> +  +---+  +-+
> > >> +  ^^ ^  ^
> > >> +  || |  |
> > >> ++-||-|--|---+
> > >> +| || |  |   |
> > >> +|  +-+ +---+ +---+  +---+   |
> > >> +|  | FME | | Port0 | | Port1 |  | Port2 |   |
> > >> +|  +-+ +---+ +---+  +---+   |
> > >> +|  ^ ^  ^   |
> > >> +|  | |  |   |
> > >> +|  +---+ +--+   +---+   |
> > >> +|  |  AFU  | |  AFU |   |  AFU  |   |
> > >> +|  +---+ +--+   +---+   |
> > >> +|   |
> > >> +| FPGA PCIe Device  |
> > >> ++---+
> > >> +
> > >> +The driver supports PCIe SR-IOV to create virtual functions (VFs) which
> > >> can be
> > >> +used to assign individual accelerators to virtual machines .
> > >
> > >
> > > Does this HW Architecture require an Intel FPGA?  Couldn't any vendors 
> > > FPGA
> > > be used as long as it presented itself the PCIe bus the same and contained
> > > an appropriate Device Feature List?

I think this is a good (and important) point. Especially when sysfs
entries & ioctls constituting ABI depend on it.

> > >
> > >> +
> > >> +FME (FPGA Management Engine)
> > >> +
> > >> +The FPGA Management Enging performs power and thermal management, error
Enging->Engine
> > >> +reporting, reconfiguration, performance reporting, and other
> > >> infrastructure
> > >> +functions. Each FPGA has one FME, which is always accessed through the
> > >> physical
> > >> +function (PF).
> > >> +
> > >> +User-space applications can acquire exclusive access to the FME using
> > >> open(),
> > >> +and release it using close().
> > >> +
> > >> +The following functions are exposed through ioctls:
> > >> +
> > >> +   Get 

Re: [PATCH 00/16] Intel FPGA Device Drivers

[Moritz Fischer]

On Thu, Mar 30, 2017 at 08:08:00PM +0800, Wu Hao wrote:
> Hi All,
> 
> Here is a patch-series adding drivers for Intel FPGA devices.
> 
> The Intel FPGA driver provides interfaces for userspace applications to
> configure, enumerate, open, and access FPGA accelerators on platforms
> equipped with Intel(R) FPGA solutions and enables system level management
> functions such as FPGA partial reconfiguration, power management and
> virtualization.
> 
> This patch series only adds the basic functions for FPGA accelerators and
> partial reconfiguration. Patches for more functions, e.g power management
> and virtualization, will be submitted after this series gets reviewed.
> 
> Patch 1: add a document for Intel FPGA driver overview, including the HW
> architecture, driver organization, device enumeration, virtualization and
> opens.
> 
> Patch 2: introduce a fpga-dev class. It's used in below Intel FPGA PCIe
> device driver, to represent a FPGA device on the system, and all actual
> feature devices should be registered as child nodes of this container
> fpga-dev device.
> 
> Patch 3-7: implement Intel FPGA PCIe device driver. It walks through the
> 'Device Feature List' in the PCI Bar, creates the container fpga-dev as
> parent and platform devices as children for the feature devices it found.
> 
> Patch 8-11: implement Intel FPGA Management Engine (FME) driver. It's a
> platform driver matching with the FME platform device created by above
> PCIe driver. Sysfs and device file ioctls are exposed as user interfaces
> to allow partial reconfiguration to Accelerated Function Units (AFUs) from
> user space applications.
> 
> Patch 12-16: implement Intel FPGA Accelerated Function Unit (AFU) driver.
> It's a platform driver matching with AFU platform device created by above
> PCIe driver. It provides user interfaces to expose the AFU MMIO region,
> map/unmap dma buffer, and control the port which AFU connects to.

This is exciting stuff. It will take some time to review, though. I marked
the patchset as 'In-Review' in patchwork.

Cheers,

Moritz



signature.asc
Description: PGP signature

Re: [PATCH 00/16] Intel FPGA Device Drivers

[Moritz Fischer]

On Thu, Mar 30, 2017 at 08:08:00PM +0800, Wu Hao wrote:
> Hi All,
> 
> Here is a patch-series adding drivers for Intel FPGA devices.
> 
> The Intel FPGA driver provides interfaces for userspace applications to
> configure, enumerate, open, and access FPGA accelerators on platforms
> equipped with Intel(R) FPGA solutions and enables system level management
> functions such as FPGA partial reconfiguration, power management and
> virtualization.
> 
> This patch series only adds the basic functions for FPGA accelerators and
> partial reconfiguration. Patches for more functions, e.g power management
> and virtualization, will be submitted after this series gets reviewed.
> 
> Patch 1: add a document for Intel FPGA driver overview, including the HW
> architecture, driver organization, device enumeration, virtualization and
> opens.
> 
> Patch 2: introduce a fpga-dev class. It's used in below Intel FPGA PCIe
> device driver, to represent a FPGA device on the system, and all actual
> feature devices should be registered as child nodes of this container
> fpga-dev device.
> 
> Patch 3-7: implement Intel FPGA PCIe device driver. It walks through the
> 'Device Feature List' in the PCI Bar, creates the container fpga-dev as
> parent and platform devices as children for the feature devices it found.
> 
> Patch 8-11: implement Intel FPGA Management Engine (FME) driver. It's a
> platform driver matching with the FME platform device created by above
> PCIe driver. Sysfs and device file ioctls are exposed as user interfaces
> to allow partial reconfiguration to Accelerated Function Units (AFUs) from
> user space applications.
> 
> Patch 12-16: implement Intel FPGA Accelerated Function Unit (AFU) driver.
> It's a platform driver matching with AFU platform device created by above
> PCIe driver. It provides user interfaces to expose the AFU MMIO region,
> map/unmap dma buffer, and control the port which AFU connects to.

This is exciting stuff. It will take some time to review, though. I marked
the patchset as 'In-Review' in patchwork.

Cheers,

Moritz



signature.asc
Description: PGP signature

Re: [PATCH 0/5] fpga: enhancements to support non-dt code

[Moritz Fischer]

On Fri, Mar 24, 2017 at 01:09:22PM -0500, Alan Tull wrote:
> On Mon, Mar 13, 2017 at 4:53 PM, Alan Tull  wrote:
> > Set of patches that supports writing code that uses
> > FPGA regions without Device Tree overlays.
> 
> OK here's where I try to clarify my intention for this code.  And
> beg for reviews :)

It's on the todo list ;-)

Cheers,

Moritz


signature.asc
Description: PGP signature

Re: [PATCH 0/5] fpga: enhancements to support non-dt code

[Moritz Fischer]

On Fri, Mar 24, 2017 at 01:09:22PM -0500, Alan Tull wrote:
> On Mon, Mar 13, 2017 at 4:53 PM, Alan Tull  wrote:
> > Set of patches that supports writing code that uses
> > FPGA regions without Device Tree overlays.
> 
> OK here's where I try to clarify my intention for this code.  And
> beg for reviews :)

It's on the todo list ;-)

Cheers,

Moritz


signature.asc
Description: PGP signature

Re: [PATCH v3 1/2] doc: Add bindings document for Xilinx LogiCore PR Decoupler

[Moritz Fischer]

On Fri, Mar 24, 2017 at 12:25:25PM -0500, Alan Tull wrote:
> On Fri, Mar 24, 2017 at 10:23 AM, Moritz Fischer
> <moritz.fischer.priv...@gmail.com> wrote:
> > On Fri, Mar 24, 2017 at 09:59:08AM -0500, Rob Herring wrote:
> >> On Fri, Mar 17, 2017 at 01:11:12PM -0700, Moritz Fischer wrote:
> >> > This adds the binding documentation for the Xilinx LogiCORE PR
> >> > Decoupler soft core.
> >> >
> >> > Signed-off-by: Moritz Fischer <m...@kernel.org>
> >> > Cc: Michal Simek <michal.si...@xilinx.com>
> >> > Cc: Sören Brinkmann <soren.brinkm...@xilinx.com>
> >> > Cc: linux-kernel@vger.kernel.org
> >> > Cc: devicet...@vger.kernel.org
> >> > ---
> >> >
> >> > Changes from v2:
> >> > - Added refence to generic fpga-region bindings
> >> > - Fixed up reg property in example
> >> > - Added fallback to "xlnx,pr-decoupler" without version
> >> >
> >> > Changes from v1:
> >> > - Added clock names & clock to example
> >> > - Merged some of the description from Michal's version
> >> >
> >> > ---
> >> >  .../bindings/fpga/xilinx-pr-decoupler.txt  | 35 
> >> > ++
> >> >  1 file changed, 35 insertions(+)
> >> >  create mode 100644 
> >> > Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
> >> >
> >> > diff --git 
> >> > a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt 
> >> > b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
> >> > new file mode 100644
> >> > index 000..16141bd
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
> >> > @@ -0,0 +1,35 @@
> >> > +Xilinx LogiCORE Partial Reconfig Decoupler Softcore
> >> > +
> >> > +The Xilinx LogiCORE Partial Reconfig Decoupler manages one or more
> >> > +decouplers / fpga bridges.
> >> > +The controller can decouple/disable the bridges which prevents signal
> >> > +changes from passing through the bridge.  The controller can also
> >> > +couple / enable the bridges which allows traffic to pass through the
> >> > +bridge normally.
> >> > +
> >> > +The Driver supports only MMIO handling. A PR region can have multiple
> >> > +PR Decouples which can bhe handled independently or chaines via 
> >> > decouple/
> >>
> >> s/chaines/chains/
> >
> > Fixed in v4.
> >
> >> > +decouple_status signals.
> >> > +
> >> > +Required properties:
> >> > +- compatible   : Should contain "xlnx,pr-decoupler-1.00"
> >> > +- regs : base address and size for decoupler module
> >> > +- clocks   : input clock to IP
> >> > +- clock-names  : should contain "aclk"
> >> > +
> >> > +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.
> >>
> >> This is common and should move into a common doc. Maybe fpga-region.txt
> >> works?
> >
> > Ok will add patch for that to v5 series.
> 
> Arg, our emails criss-crossed.  I've already sent v4 to Greg.  I hope
> we don't need v5 for this one thing.  bridge-enable is common for the
> fpga bridges (altera-fpga2sdram-bridge.txt, altera-freeze-bridge.txt,
> altera-hps2fpga-bridge.txt, xilinx-pr-decoupler.txt).  Probably we
> need a new patch to move this common bridges binding from all the
> above to fpga-region.txt or create a new fpga-bridges.txt.  At first
> blush, I prefer the later.

Yeah, I'll just send a follow-up patch, it's not that it breaks anything
the way it is.

- Moritz


signature.asc
Description: PGP signature

Re: [PATCH v3 1/2] doc: Add bindings document for Xilinx LogiCore PR Decoupler

[Moritz Fischer]

On Fri, Mar 24, 2017 at 12:25:25PM -0500, Alan Tull wrote:
> On Fri, Mar 24, 2017 at 10:23 AM, Moritz Fischer
>  wrote:
> > On Fri, Mar 24, 2017 at 09:59:08AM -0500, Rob Herring wrote:
> >> On Fri, Mar 17, 2017 at 01:11:12PM -0700, Moritz Fischer wrote:
> >> > This adds the binding documentation for the Xilinx LogiCORE PR
> >> > Decoupler soft core.
> >> >
> >> > Signed-off-by: Moritz Fischer 
> >> > Cc: Michal Simek 
> >> > Cc: Sören Brinkmann 
> >> > Cc: linux-kernel@vger.kernel.org
> >> > Cc: devicet...@vger.kernel.org
> >> > ---
> >> >
> >> > Changes from v2:
> >> > - Added refence to generic fpga-region bindings
> >> > - Fixed up reg property in example
> >> > - Added fallback to "xlnx,pr-decoupler" without version
> >> >
> >> > Changes from v1:
> >> > - Added clock names & clock to example
> >> > - Merged some of the description from Michal's version
> >> >
> >> > ---
> >> >  .../bindings/fpga/xilinx-pr-decoupler.txt  | 35 
> >> > ++
> >> >  1 file changed, 35 insertions(+)
> >> >  create mode 100644 
> >> > Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
> >> >
> >> > diff --git 
> >> > a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt 
> >> > b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
> >> > new file mode 100644
> >> > index 000..16141bd
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
> >> > @@ -0,0 +1,35 @@
> >> > +Xilinx LogiCORE Partial Reconfig Decoupler Softcore
> >> > +
> >> > +The Xilinx LogiCORE Partial Reconfig Decoupler manages one or more
> >> > +decouplers / fpga bridges.
> >> > +The controller can decouple/disable the bridges which prevents signal
> >> > +changes from passing through the bridge.  The controller can also
> >> > +couple / enable the bridges which allows traffic to pass through the
> >> > +bridge normally.
> >> > +
> >> > +The Driver supports only MMIO handling. A PR region can have multiple
> >> > +PR Decouples which can bhe handled independently or chaines via 
> >> > decouple/
> >>
> >> s/chaines/chains/
> >
> > Fixed in v4.
> >
> >> > +decouple_status signals.
> >> > +
> >> > +Required properties:
> >> > +- compatible   : Should contain "xlnx,pr-decoupler-1.00"
> >> > +- regs : base address and size for decoupler module
> >> > +- clocks   : input clock to IP
> >> > +- clock-names  : should contain "aclk"
> >> > +
> >> > +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.
> >>
> >> This is common and should move into a common doc. Maybe fpga-region.txt
> >> works?
> >
> > Ok will add patch for that to v5 series.
> 
> Arg, our emails criss-crossed.  I've already sent v4 to Greg.  I hope
> we don't need v5 for this one thing.  bridge-enable is common for the
> fpga bridges (altera-fpga2sdram-bridge.txt, altera-freeze-bridge.txt,
> altera-hps2fpga-bridge.txt, xilinx-pr-decoupler.txt).  Probably we
> need a new patch to move this common bridges binding from all the
> above to fpga-region.txt or create a new fpga-bridges.txt.  At first
> blush, I prefer the later.

Yeah, I'll just send a follow-up patch, it's not that it breaks anything
the way it is.

- Moritz


signature.asc
Description: PGP signature

Re: [PATCH v3 1/2] doc: Add bindings document for Xilinx LogiCore PR Decoupler

[Moritz Fischer]

On Fri, Mar 24, 2017 at 09:59:08AM -0500, Rob Herring wrote:
> On Fri, Mar 17, 2017 at 01:11:12PM -0700, Moritz Fischer wrote:
> > This adds the binding documentation for the Xilinx LogiCORE PR
> > Decoupler soft core.
> > 
> > Signed-off-by: Moritz Fischer <m...@kernel.org>
> > Cc: Michal Simek <michal.si...@xilinx.com>
> > Cc: Sören Brinkmann <soren.brinkm...@xilinx.com>
> > Cc: linux-kernel@vger.kernel.org
> > Cc: devicet...@vger.kernel.org
> > ---
> > 
> > Changes from v2:
> > - Added refence to generic fpga-region bindings
> > - Fixed up reg property in example
> > - Added fallback to "xlnx,pr-decoupler" without version
> > 
> > Changes from v1:
> > - Added clock names & clock to example
> > - Merged some of the description from Michal's version
> > 
> > ---
> >  .../bindings/fpga/xilinx-pr-decoupler.txt  | 35 
> > ++
> >  1 file changed, 35 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt 
> > b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
> > new file mode 100644
> > index 000..16141bd
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
> > @@ -0,0 +1,35 @@
> > +Xilinx LogiCORE Partial Reconfig Decoupler Softcore
> > +
> > +The Xilinx LogiCORE Partial Reconfig Decoupler manages one or more
> > +decouplers / fpga bridges.
> > +The controller can decouple/disable the bridges which prevents signal
> > +changes from passing through the bridge.  The controller can also
> > +couple / enable the bridges which allows traffic to pass through the
> > +bridge normally.
> > +
> > +The Driver supports only MMIO handling. A PR region can have multiple
> > +PR Decouples which can bhe handled independently or chaines via decouple/
> 
> s/chaines/chains/

Fixed in v4.

> > +decouple_status signals.
> > +
> > +Required properties:
> > +- compatible   : Should contain "xlnx,pr-decoupler-1.00"
> > +- regs : base address and size for decoupler module
> > +- clocks   : input clock to IP
> > +- clock-names  : should contain "aclk"
> > +
> > +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.
> 
> This is common and should move into a common doc. Maybe fpga-region.txt 
> works?

Ok will add patch for that to v5 series.

Thanks for your feedback,

Moritz

Re: [PATCH v3 1/2] doc: Add bindings document for Xilinx LogiCore PR Decoupler

[Moritz Fischer]

On Fri, Mar 24, 2017 at 09:59:08AM -0500, Rob Herring wrote:
> On Fri, Mar 17, 2017 at 01:11:12PM -0700, Moritz Fischer wrote:
> > This adds the binding documentation for the Xilinx LogiCORE PR
> > Decoupler soft core.
> > 
> > Signed-off-by: Moritz Fischer 
> > Cc: Michal Simek 
> > Cc: Sören Brinkmann 
> > Cc: linux-kernel@vger.kernel.org
> > Cc: devicet...@vger.kernel.org
> > ---
> > 
> > Changes from v2:
> > - Added refence to generic fpga-region bindings
> > - Fixed up reg property in example
> > - Added fallback to "xlnx,pr-decoupler" without version
> > 
> > Changes from v1:
> > - Added clock names & clock to example
> > - Merged some of the description from Michal's version
> > 
> > ---
> >  .../bindings/fpga/xilinx-pr-decoupler.txt  | 35 
> > ++
> >  1 file changed, 35 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt 
> > b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
> > new file mode 100644
> > index 000..16141bd
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
> > @@ -0,0 +1,35 @@
> > +Xilinx LogiCORE Partial Reconfig Decoupler Softcore
> > +
> > +The Xilinx LogiCORE Partial Reconfig Decoupler manages one or more
> > +decouplers / fpga bridges.
> > +The controller can decouple/disable the bridges which prevents signal
> > +changes from passing through the bridge.  The controller can also
> > +couple / enable the bridges which allows traffic to pass through the
> > +bridge normally.
> > +
> > +The Driver supports only MMIO handling. A PR region can have multiple
> > +PR Decouples which can bhe handled independently or chaines via decouple/
> 
> s/chaines/chains/

Fixed in v4.

> > +decouple_status signals.
> > +
> > +Required properties:
> > +- compatible   : Should contain "xlnx,pr-decoupler-1.00"
> > +- regs : base address and size for decoupler module
> > +- clocks   : input clock to IP
> > +- clock-names  : should contain "aclk"
> > +
> > +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.
> 
> This is common and should move into a common doc. Maybe fpga-region.txt 
> works?

Ok will add patch for that to v5 series.

Thanks for your feedback,

Moritz

[PATCH v4 2/2] fpga: Add support for Xilinx LogiCORE PR Decoupler

[Moritz Fischer]

This adds support for the Xilinx LogiCORE PR Decoupler
soft-ip that does decoupling of PR regions in the FPGA
fabric during partial reconfiguration.

Signed-off-by: Moritz Fischer <m...@kernel.org>
Signed-off-by: Michal Simek <michal.si...@xilinx.com>
Cc: Sören Brinkmann <soren.brinkm...@xilinx.com>
Cc: linux-kernel@vger.kernel.org
Cc: devicet...@vger.kernel.org
---
Changes from v3:
- Adressed build bot issues

Changes from v2:
- Added Michal's Signed-off-by
- Added "xlnx,pr-decoupler" unversioned fallback

Changes from v1:
- Added Michal as Co-Author since I pulled in some of his code
- Reworked clk handling in _remove()
- Pulled in Michal's version of show_enable(), ditched priv->enabled

---
 drivers/fpga/Kconfig   |  10 +++
 drivers/fpga/Makefile  |   1 +
 drivers/fpga/xilinx-pr-decoupler.c | 161 +
 3 files changed, 172 insertions(+)
 create mode 100644 drivers/fpga/xilinx-pr-decoupler.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index ce861a2..6eabfbe 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -63,6 +63,16 @@ config ALTERA_FREEZE_BRIDGE
  isolate one region of the FPGA from the busses while that
  region is being reprogrammed.
 
+config XILINX_PR_DECOUPLER
+   tristate "Xilinx LogiCORE PR Decoupler"
+   depends on FPGA_BRIDGE
+   depends on HAS_IOMEM
+   help
+ Say Y to enable drivers for Xilinx LogiCORE PR Decoupler.
+ The PR Decoupler exists in the FPGA fabric to isolate one
+ region of the FPGA from the busses while that region is
+ being reprogrammed during partial reconfig.
+
 endif # FPGA
 
 endmenu
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 8df07bc..ba94b79 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)  += zynq-fpga.o
 obj-$(CONFIG_FPGA_BRIDGE)  += fpga-bridge.o
 obj-$(CONFIG_SOCFPGA_FPGA_BRIDGE)  += altera-hps2fpga.o altera-fpga2sdram.o
 obj-$(CONFIG_ALTERA_FREEZE_BRIDGE) += altera-freeze-bridge.o
+obj-$(CONFIG_XILINX_PR_DECOUPLER)  += xilinx-pr-decoupler.o
 
 # High Level Interfaces
 obj-$(CONFIG_FPGA_REGION)  += fpga-region.o
diff --git a/drivers/fpga/xilinx-pr-decoupler.c 
b/drivers/fpga/xilinx-pr-decoupler.c
new file mode 100644
index 000..e359930
--- /dev/null
+++ b/drivers/fpga/xilinx-pr-decoupler.c
@@ -0,0 +1,161 @@
+/*
+ * Copyright (c) 2017, National Instruments Corp.
+ * Copyright (c) 2017, Xilix Inc
+ *
+ * FPGA Bridge Driver for the Xilinx LogiCORE Partial Reconfiguration
+ * Decoupler IP Core.
+ *
+ * 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
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CTRL_CMD_DECOUPLE  BIT(0)
+#define CTRL_CMD_COUPLE0
+#define CTRL_OFFSET0
+
+struct xlnx_pr_decoupler_data {
+   void __iomem *io_base;
+   struct clk *clk;
+};
+
+static inline void xlnx_pr_decoupler_write(struct xlnx_pr_decoupler_data *d,
+  u32 offset, u32 val)
+{
+   writel(val, d->io_base + offset);
+}
+
+static inline u32 xlnx_pr_decouple_read(const struct xlnx_pr_decoupler_data *d,
+   u32 offset)
+{
+   return readl(d->io_base + offset);
+}
+
+static int xlnx_pr_decoupler_enable_set(struct fpga_bridge *bridge, bool 
enable)
+{
+   int err;
+   struct xlnx_pr_decoupler_data *priv = bridge->priv;
+
+   err = clk_enable(priv->clk);
+   if (err)
+   return err;
+
+   if (enable)
+   xlnx_pr_decoupler_write(priv, CTRL_OFFSET, CTRL_CMD_COUPLE);
+   else
+   xlnx_pr_decoupler_write(priv, CTRL_OFFSET, CTRL_CMD_DECOUPLE);
+
+   clk_disable(priv->clk);
+
+   return 0;
+}
+
+static int xlnx_pr_decoupler_enable_show(struct fpga_bridge *bridge)
+{
+   const struct xlnx_pr_decoupler_data *priv = bridge->priv;
+   u32 status;
+   int err;
+
+   err = clk_enable(priv->clk);
+   if (err)
+   return err;
+
+   status = readl(priv->io_base);
+
+   clk_disable(priv->clk);
+
+   return !status;
+}
+
+static struct fpga_bridge_ops xlnx_pr_decoupler_br_ops = {
+   .enable_set = xlnx_pr_decoupler_enable_set,
+   .enable_show = xlnx_pr_decoupler_enable_show,
+};
+
+static const struct of_device_id xlnx_pr_decoupler_of_match[] = {
+   { .compatible = &qu

[PATCH v4 1/2] doc: Add bindings document for Xilinx LogiCore PR Decoupler

[Moritz Fischer]

This adds the binding documentation for the Xilinx LogiCORE PR
Decoupler soft core.

Signed-off-by: Moritz Fischer <m...@kernel.org>
Signed-off-by: Michal Simek <michal.si...@xilinx.com>
Acked-by: Alan Tull <at...@kernel.org>
Cc: Sören Brinkmann <soren.brinkm...@xilinx.com>
Cc: linux-kernel@vger.kernel.org
Cc: devicet...@vger.kernel.org
---

Changes from v3:
- Addressed Michal's comments
- Addressed Alan's Comments
- Added Alan's Acked-by

Changes from v2:
- Added refence to generic fpga-region bindings
- Fixed up reg property in example
- Added fallback to "xlnx,pr-decoupler" without version

Changes from v1:
- Added clock names & clock to example
- Merged some of the description from Michal's version

---
 .../bindings/fpga/xilinx-pr-decoupler.txt  | 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt

diff --git a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt 
b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
new file mode 100644
index 000..2c527ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
@@ -0,0 +1,35 @@
+Xilinx LogiCORE Partial Reconfig Decoupler Softcore
+
+The Xilinx LogiCORE Partial Reconfig Decoupler manages one or more
+decouplers / fpga bridges.
+The controller can decouple/disable the bridges which prevents signal
+changes from passing through the bridge.  The controller can also
+couple / enable the bridges which allows traffic to pass through the
+bridge normally.
+
+The Driver supports only MMIO handling. A PR region can have multiple
+PR Decouplers which can be handled independently or chained via decouple/
+decouple_status signals.
+
+Required properties:
+- compatible   : Should contain "xlnx,pr-decoupler-1.00" or 
"xlnx,pr-decoupler"
+- regs : base address and size for decoupler module
+- clocks   : input clock to IP
+- clock-names  : should contain "aclk"
+
+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.
+
+See Documentation/devicetree/bindings/fpga/fpga-region.txt for generic 
bindings.
+
+Example:
+   fpga-bridge@10450 {
+   compatible = "xlnx,pr-decoupler-1.00",
+"xlnx-pr-decoupler";
+   regs = <0x1045 0x10>;
+   clocks = < 15>;
+   clock-names = "aclk";
+   bridge-enable = <0>;
+   };
-- 
2.7.4

[PATCH v4 2/2] fpga: Add support for Xilinx LogiCORE PR Decoupler

[Moritz Fischer]

This adds support for the Xilinx LogiCORE PR Decoupler
soft-ip that does decoupling of PR regions in the FPGA
fabric during partial reconfiguration.

Signed-off-by: Moritz Fischer 
Signed-off-by: Michal Simek 
Cc: Sören Brinkmann 
Cc: linux-kernel@vger.kernel.org
Cc: devicet...@vger.kernel.org
---
Changes from v3:
- Adressed build bot issues

Changes from v2:
- Added Michal's Signed-off-by
- Added "xlnx,pr-decoupler" unversioned fallback

Changes from v1:
- Added Michal as Co-Author since I pulled in some of his code
- Reworked clk handling in _remove()
- Pulled in Michal's version of show_enable(), ditched priv->enabled

---
 drivers/fpga/Kconfig   |  10 +++
 drivers/fpga/Makefile  |   1 +
 drivers/fpga/xilinx-pr-decoupler.c | 161 +
 3 files changed, 172 insertions(+)
 create mode 100644 drivers/fpga/xilinx-pr-decoupler.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index ce861a2..6eabfbe 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -63,6 +63,16 @@ config ALTERA_FREEZE_BRIDGE
  isolate one region of the FPGA from the busses while that
  region is being reprogrammed.
 
+config XILINX_PR_DECOUPLER
+   tristate "Xilinx LogiCORE PR Decoupler"
+   depends on FPGA_BRIDGE
+   depends on HAS_IOMEM
+   help
+ Say Y to enable drivers for Xilinx LogiCORE PR Decoupler.
+ The PR Decoupler exists in the FPGA fabric to isolate one
+ region of the FPGA from the busses while that region is
+ being reprogrammed during partial reconfig.
+
 endif # FPGA
 
 endmenu
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 8df07bc..ba94b79 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA)  += zynq-fpga.o
 obj-$(CONFIG_FPGA_BRIDGE)  += fpga-bridge.o
 obj-$(CONFIG_SOCFPGA_FPGA_BRIDGE)  += altera-hps2fpga.o altera-fpga2sdram.o
 obj-$(CONFIG_ALTERA_FREEZE_BRIDGE) += altera-freeze-bridge.o
+obj-$(CONFIG_XILINX_PR_DECOUPLER)  += xilinx-pr-decoupler.o
 
 # High Level Interfaces
 obj-$(CONFIG_FPGA_REGION)  += fpga-region.o
diff --git a/drivers/fpga/xilinx-pr-decoupler.c 
b/drivers/fpga/xilinx-pr-decoupler.c
new file mode 100644
index 000..e359930
--- /dev/null
+++ b/drivers/fpga/xilinx-pr-decoupler.c
@@ -0,0 +1,161 @@
+/*
+ * Copyright (c) 2017, National Instruments Corp.
+ * Copyright (c) 2017, Xilix Inc
+ *
+ * FPGA Bridge Driver for the Xilinx LogiCORE Partial Reconfiguration
+ * Decoupler IP Core.
+ *
+ * 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
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CTRL_CMD_DECOUPLE  BIT(0)
+#define CTRL_CMD_COUPLE0
+#define CTRL_OFFSET0
+
+struct xlnx_pr_decoupler_data {
+   void __iomem *io_base;
+   struct clk *clk;
+};
+
+static inline void xlnx_pr_decoupler_write(struct xlnx_pr_decoupler_data *d,
+  u32 offset, u32 val)
+{
+   writel(val, d->io_base + offset);
+}
+
+static inline u32 xlnx_pr_decouple_read(const struct xlnx_pr_decoupler_data *d,
+   u32 offset)
+{
+   return readl(d->io_base + offset);
+}
+
+static int xlnx_pr_decoupler_enable_set(struct fpga_bridge *bridge, bool 
enable)
+{
+   int err;
+   struct xlnx_pr_decoupler_data *priv = bridge->priv;
+
+   err = clk_enable(priv->clk);
+   if (err)
+   return err;
+
+   if (enable)
+   xlnx_pr_decoupler_write(priv, CTRL_OFFSET, CTRL_CMD_COUPLE);
+   else
+   xlnx_pr_decoupler_write(priv, CTRL_OFFSET, CTRL_CMD_DECOUPLE);
+
+   clk_disable(priv->clk);
+
+   return 0;
+}
+
+static int xlnx_pr_decoupler_enable_show(struct fpga_bridge *bridge)
+{
+   const struct xlnx_pr_decoupler_data *priv = bridge->priv;
+   u32 status;
+   int err;
+
+   err = clk_enable(priv->clk);
+   if (err)
+   return err;
+
+   status = readl(priv->io_base);
+
+   clk_disable(priv->clk);
+
+   return !status;
+}
+
+static struct fpga_bridge_ops xlnx_pr_decoupler_br_ops = {
+   .enable_set = xlnx_pr_decoupler_enable_set,
+   .enable_show = xlnx_pr_decoupler_enable_show,
+};
+
+static const struct of_device_id xlnx_pr_decoupler_of_match[] = {
+   { .compatible = "xlnx,pr-decoupler-1.00", },
+   { .compatible = "xlnx,pr-decoupler", },
+   {},
+

[PATCH v4 1/2] doc: Add bindings document for Xilinx LogiCore PR Decoupler

[Moritz Fischer]

This adds the binding documentation for the Xilinx LogiCORE PR
Decoupler soft core.

Signed-off-by: Moritz Fischer 
Signed-off-by: Michal Simek 
Acked-by: Alan Tull 
Cc: Sören Brinkmann 
Cc: linux-kernel@vger.kernel.org
Cc: devicet...@vger.kernel.org
---

Changes from v3:
- Addressed Michal's comments
- Addressed Alan's Comments
- Added Alan's Acked-by

Changes from v2:
- Added refence to generic fpga-region bindings
- Fixed up reg property in example
- Added fallback to "xlnx,pr-decoupler" without version

Changes from v1:
- Added clock names & clock to example
- Merged some of the description from Michal's version

---
 .../bindings/fpga/xilinx-pr-decoupler.txt  | 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt

diff --git a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt 
b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
new file mode 100644
index 000..2c527ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
@@ -0,0 +1,35 @@
+Xilinx LogiCORE Partial Reconfig Decoupler Softcore
+
+The Xilinx LogiCORE Partial Reconfig Decoupler manages one or more
+decouplers / fpga bridges.
+The controller can decouple/disable the bridges which prevents signal
+changes from passing through the bridge.  The controller can also
+couple / enable the bridges which allows traffic to pass through the
+bridge normally.
+
+The Driver supports only MMIO handling. A PR region can have multiple
+PR Decouplers which can be handled independently or chained via decouple/
+decouple_status signals.
+
+Required properties:
+- compatible   : Should contain "xlnx,pr-decoupler-1.00" or 
"xlnx,pr-decoupler"
+- regs : base address and size for decoupler module
+- clocks   : input clock to IP
+- clock-names  : should contain "aclk"
+
+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.
+
+See Documentation/devicetree/bindings/fpga/fpga-region.txt for generic 
bindings.
+
+Example:
+   fpga-bridge@10450 {
+   compatible = "xlnx,pr-decoupler-1.00",
+"xlnx-pr-decoupler";
+   regs = <0x1045 0x10>;
+   clocks = < 15>;
+   clock-names = "aclk";
+   bridge-enable = <0>;
+   };
-- 
2.7.4

Re: [RFC v0 0/2] Introduce on-chip interconnect API

[Moritz Fischer]

On Tue, Mar 14, 2017 at 05:41:54PM +0200, Georgi Djakov wrote:
> On 03/03/2017 08:21 AM, Rob Herring wrote:
> > On Wed, Mar 01, 2017 at 08:22:33PM +0200, Georgi Djakov wrote:
> > > Modern SoCs have multiple processors and various dedicated cores (video, 
> > > gpu,
> > > graphics, modem). These cores are talking to each other and can generate 
> > > a lot
> > > of data flowing through the on-chip interconnects. These interconnect 
> > > buses
> > > could form different topologies such as crossbar, point to point buses,
> > > hierarchical buses or use the network-on-chip concept.
> > > 
> > > These buses have been sized usually to handle use cases with high data
> > > throughput but it is not necessary all the time and consume a lot of 
> > > power.
> > > Furthermore, the priority between masters can vary depending on the 
> > > running
> > > use case like video playback or cpu intensive tasks.
> > > 
> > > Having an API to control the requirement of the system in term of 
> > > bandwidth
> > > and QoS, so we can adapt the interconnect configuration to match those by
> > > scaling the frequencies, setting link priority and tuning QoS parameters.
> > > This configuration can be a static, one-time operation done at boot for 
> > > some
> > > platforms or a dynamic set of operations that happen at run-time.
> > > 
> > > This patchset introduce a new API to get the requirement and configure the
> > > interconnect buses across the entire chipset to fit with the current 
> > > demand.
> > > The API is NOT for changing the performance of the endpoint devices, but 
> > > only
> > > the interconnect path in between them.
> > > 
> > > The API is using a consumer/provider-based model, where the providers are
> > > the interconnect controllers and the consumers could be various drivers.
> > > The consumers request interconnect resources (path) to an endpoint and set
> > > the desired constraints on this data flow path. The provider(s) receive
> > > requests from consumers and aggregate these requests for all master-slave
> > > pairs on that path. Then the providers configure each participating in the
> > > topology node according to the requested data flow path, physical links 
> > > and
> > > constraints. The topology could be complicated and multi-tiered and is SoC
> > > specific.
> > > 
> > > Below is a simplified diagram of a real-world SoC topology. The 
> > > interconnect
> > > providers are the memory front-end and the NoCs.
> > > 
> > > ++++
> > > | HW Accelerator |--->|  M NoC |<---+
> > > ++++|
> > > |  |++
> > >   +-+  V   +--+ ||
> > >   |++  | PCIe | ||
> > >   || Slaves |  +--+ ||
> > >   |++ | |   C NoC|
> > >   V   V ||
> > > +--+   ++   ||   
> > > +-+
> > > |  |-->||-->||-->| 
> > > CPU |
> > > |  |-->||<--||   
> > > +-+
> > > |  Memory  |   | S NoC  |   ++
> > > |  |<--||-+|
> > > |  |<--||<--+ ||   
> > > ++
> > > +--+   ++   | |+-->| 
> > > Slaves |
> > >^ ^^   ^ | |
> > > ++
> > >| ||   | | V
> > > +-+  |  +-++-+  +-+   ++   
> > > ++
> > > | CPU |  |  | GPU || DSP |  | Masters |-->|   P NoC|-->| 
> > > Slaves |
> > > +-+  |  +-++-+  +-+   ++   
> > > ++
> > >  |
> > >  +---+
> > >  | Modem |
> > >  +---+
> > > 
> > > This RFC does not implement all features but only main skeleton to check 
> > > the
> > > validity of the proposal. Currently it only works with device-tree and 
> > > platform
> > > devices.
> > > 
> > > TODO:
> > >  * Constraints are currently stored in internal data structure. Should PM 
> > > QoS
> > >  be used instead?
> > >  * Rework the framework to not depend on DT as frameworks cannot be tied
> > >  directly to firmware interfaces. Add support for ACPI?
> > 
> > I would start without DT even. You can always have the data you need in
> > the kernel. This will be more flexible as you're not defining an ABI as
> > this evolves. I think it will take some time to have consensus on how to
> > represent the bus master view of buses/interconnects (It's been
> > attempted before).
> > 

Re: [RFC v0 0/2] Introduce on-chip interconnect API

[Moritz Fischer]

On Tue, Mar 14, 2017 at 05:41:54PM +0200, Georgi Djakov wrote:
> On 03/03/2017 08:21 AM, Rob Herring wrote:
> > On Wed, Mar 01, 2017 at 08:22:33PM +0200, Georgi Djakov wrote:
> > > Modern SoCs have multiple processors and various dedicated cores (video, 
> > > gpu,
> > > graphics, modem). These cores are talking to each other and can generate 
> > > a lot
> > > of data flowing through the on-chip interconnects. These interconnect 
> > > buses
> > > could form different topologies such as crossbar, point to point buses,
> > > hierarchical buses or use the network-on-chip concept.
> > > 
> > > These buses have been sized usually to handle use cases with high data
> > > throughput but it is not necessary all the time and consume a lot of 
> > > power.
> > > Furthermore, the priority between masters can vary depending on the 
> > > running
> > > use case like video playback or cpu intensive tasks.
> > > 
> > > Having an API to control the requirement of the system in term of 
> > > bandwidth
> > > and QoS, so we can adapt the interconnect configuration to match those by
> > > scaling the frequencies, setting link priority and tuning QoS parameters.
> > > This configuration can be a static, one-time operation done at boot for 
> > > some
> > > platforms or a dynamic set of operations that happen at run-time.
> > > 
> > > This patchset introduce a new API to get the requirement and configure the
> > > interconnect buses across the entire chipset to fit with the current 
> > > demand.
> > > The API is NOT for changing the performance of the endpoint devices, but 
> > > only
> > > the interconnect path in between them.
> > > 
> > > The API is using a consumer/provider-based model, where the providers are
> > > the interconnect controllers and the consumers could be various drivers.
> > > The consumers request interconnect resources (path) to an endpoint and set
> > > the desired constraints on this data flow path. The provider(s) receive
> > > requests from consumers and aggregate these requests for all master-slave
> > > pairs on that path. Then the providers configure each participating in the
> > > topology node according to the requested data flow path, physical links 
> > > and
> > > constraints. The topology could be complicated and multi-tiered and is SoC
> > > specific.
> > > 
> > > Below is a simplified diagram of a real-world SoC topology. The 
> > > interconnect
> > > providers are the memory front-end and the NoCs.
> > > 
> > > ++++
> > > | HW Accelerator |--->|  M NoC |<---+
> > > ++++|
> > > |  |++
> > >   +-+  V   +--+ ||
> > >   |++  | PCIe | ||
> > >   || Slaves |  +--+ ||
> > >   |++ | |   C NoC|
> > >   V   V ||
> > > +--+   ++   ||   
> > > +-+
> > > |  |-->||-->||-->| 
> > > CPU |
> > > |  |-->||<--||   
> > > +-+
> > > |  Memory  |   | S NoC  |   ++
> > > |  |<--||-+|
> > > |  |<--||<--+ ||   
> > > ++
> > > +--+   ++   | |+-->| 
> > > Slaves |
> > >^ ^^   ^ | |
> > > ++
> > >| ||   | | V
> > > +-+  |  +-++-+  +-+   ++   
> > > ++
> > > | CPU |  |  | GPU || DSP |  | Masters |-->|   P NoC|-->| 
> > > Slaves |
> > > +-+  |  +-++-+  +-+   ++   
> > > ++
> > >  |
> > >  +---+
> > >  | Modem |
> > >  +---+
> > > 
> > > This RFC does not implement all features but only main skeleton to check 
> > > the
> > > validity of the proposal. Currently it only works with device-tree and 
> > > platform
> > > devices.
> > > 
> > > TODO:
> > >  * Constraints are currently stored in internal data structure. Should PM 
> > > QoS
> > >  be used instead?
> > >  * Rework the framework to not depend on DT as frameworks cannot be tied
> > >  directly to firmware interfaces. Add support for ACPI?
> > 
> > I would start without DT even. You can always have the data you need in
> > the kernel. This will be more flexible as you're not defining an ABI as
> > this evolves. I think it will take some time to have consensus on how to
> > represent the bus master view of buses/interconnects (It's been
> > attempted before).
> > 

[PATCH] fpga: altera_freeze_bridge: Constify ops

[Moritz Fischer]

The ops are not changing, make them const.

Signed-off-by: Moritz Fischer <m...@kernel.org>
Cc: Alan Tull <at...@kernel.org>
Cc: linux-kernel@vger.kernel.org
Cc: linux-f...@vger.kernel.org
---
 drivers/fpga/altera-freeze-bridge.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/fpga/altera-freeze-bridge.c 
b/drivers/fpga/altera-freeze-bridge.c
index 8dcd9fb..8c1bc7e 100644
--- a/drivers/fpga/altera-freeze-bridge.c
+++ b/drivers/fpga/altera-freeze-bridge.c
@@ -203,7 +203,7 @@ static int altera_freeze_br_enable_show(struct fpga_bridge 
*bridge)
return priv->enable;
 }
 
-static struct fpga_bridge_ops altera_freeze_br_br_ops = {
+static const struct fpga_bridge_ops altera_freeze_br_br_ops = {
.enable_set = altera_freeze_br_enable_set,
.enable_show = altera_freeze_br_enable_show,
 };
-- 
2.7.4

[PATCH] fpga: altera_freeze_bridge: Constify ops

[Moritz Fischer]

The ops are not changing, make them const.

Signed-off-by: Moritz Fischer 
Cc: Alan Tull 
Cc: linux-kernel@vger.kernel.org
Cc: linux-f...@vger.kernel.org
---
 drivers/fpga/altera-freeze-bridge.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/fpga/altera-freeze-bridge.c 
b/drivers/fpga/altera-freeze-bridge.c
index 8dcd9fb..8c1bc7e 100644
--- a/drivers/fpga/altera-freeze-bridge.c
+++ b/drivers/fpga/altera-freeze-bridge.c
@@ -203,7 +203,7 @@ static int altera_freeze_br_enable_show(struct fpga_bridge 
*bridge)
return priv->enable;
 }
 
-static struct fpga_bridge_ops altera_freeze_br_br_ops = {
+static const struct fpga_bridge_ops altera_freeze_br_br_ops = {
.enable_set = altera_freeze_br_enable_set,
.enable_show = altera_freeze_br_enable_show,
 };
-- 
2.7.4

[PATCH v3 1/2] doc: Add bindings document for Xilinx LogiCore PR Decoupler

[Moritz Fischer]

This adds the binding documentation for the Xilinx LogiCORE PR
Decoupler soft core.

Signed-off-by: Moritz Fischer <m...@kernel.org>
Cc: Michal Simek <michal.si...@xilinx.com>
Cc: Sören Brinkmann <soren.brinkm...@xilinx.com>
Cc: linux-kernel@vger.kernel.org
Cc: devicet...@vger.kernel.org
---

Changes from v2:
- Added refence to generic fpga-region bindings
- Fixed up reg property in example
- Added fallback to "xlnx,pr-decoupler" without version

Changes from v1:
- Added clock names & clock to example
- Merged some of the description from Michal's version

---
 .../bindings/fpga/xilinx-pr-decoupler.txt  | 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt

diff --git a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt 
b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
new file mode 100644
index 000..16141bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
@@ -0,0 +1,35 @@
+Xilinx LogiCORE Partial Reconfig Decoupler Softcore
+
+The Xilinx LogiCORE Partial Reconfig Decoupler manages one or more
+decouplers / fpga bridges.
+The controller can decouple/disable the bridges which prevents signal
+changes from passing through the bridge.  The controller can also
+couple / enable the bridges which allows traffic to pass through the
+bridge normally.
+
+The Driver supports only MMIO handling. A PR region can have multiple
+PR Decouples which can bhe handled independently or chaines via decouple/
+decouple_status signals.
+
+Required properties:
+- compatible   : Should contain "xlnx,pr-decoupler-1.00"
+- regs : base address and size for decoupler module
+- clocks   : input clock to IP
+- clock-names  : should contain "aclk"
+
+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.
+
+See Documentation/devicetree/bindings/fpga/fpga-region.txt for generic 
bindings.
+
+Example:
+   fpga-bridge@10450 {
+   compatible = "xlnx,pr-decoupler-1.00",
+"xlnx-pr-decoupler";
+   regs = <0x1045 0x10>;
+   clocks = < 15>;
+   clock-names = "aclk";
+   bridge-enable = <0>;
+   };
-- 
2.7.4

[PATCH v3 1/2] doc: Add bindings document for Xilinx LogiCore PR Decoupler

[Moritz Fischer]

This adds the binding documentation for the Xilinx LogiCORE PR
Decoupler soft core.

Signed-off-by: Moritz Fischer 
Cc: Michal Simek 
Cc: Sören Brinkmann 
Cc: linux-kernel@vger.kernel.org
Cc: devicet...@vger.kernel.org
---

Changes from v2:
- Added refence to generic fpga-region bindings
- Fixed up reg property in example
- Added fallback to "xlnx,pr-decoupler" without version

Changes from v1:
- Added clock names & clock to example
- Merged some of the description from Michal's version

---
 .../bindings/fpga/xilinx-pr-decoupler.txt  | 35 ++
 1 file changed, 35 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt

diff --git a/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt 
b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
new file mode 100644
index 000..16141bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/xilinx-pr-decoupler.txt
@@ -0,0 +1,35 @@
+Xilinx LogiCORE Partial Reconfig Decoupler Softcore
+
+The Xilinx LogiCORE Partial Reconfig Decoupler manages one or more
+decouplers / fpga bridges.
+The controller can decouple/disable the bridges which prevents signal
+changes from passing through the bridge.  The controller can also
+couple / enable the bridges which allows traffic to pass through the
+bridge normally.
+
+The Driver supports only MMIO handling. A PR region can have multiple
+PR Decouples which can bhe handled independently or chaines via decouple/
+decouple_status signals.
+
+Required properties:
+- compatible   : Should contain "xlnx,pr-decoupler-1.00"
+- regs : base address and size for decoupler module
+- clocks   : input clock to IP
+- clock-names  : should contain "aclk"
+
+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.
+
+See Documentation/devicetree/bindings/fpga/fpga-region.txt for generic 
bindings.
+
+Example:
+   fpga-bridge@10450 {
+   compatible = "xlnx,pr-decoupler-1.00",
+"xlnx-pr-decoupler";
+   regs = <0x1045 0x10>;
+   clocks = < 15>;
+   clock-names = "aclk";
+   bridge-enable = <0>;
+   };
-- 
2.7.4