Re: [RESEND RFC/PATCH 0/8] Add MT8173 Video Encoder Driver and VPU Driver

2015-11-18 Thread Hans Verkuil
On 11/17/2015 01:54 PM, Tiffany Lin wrote:
> ==
>  Introduction
> ==
> 
> The purpose of this RFC is to discuss the driver for a hw video codec
> embedded in the Mediatek's MT8173 SoCs. Mediatek Video Codec is able to
> handle video encoding of in a range of formats.
> 
> This RFC also include VPU driver. Mediatek Video Codec driver rely on
> VPU driver to load, communicate with VPU.
> 
> Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI.
> MTK IOMMU and MTK SMI have not yet been merged, but we wanted to start
> discussion about the driver earlier so it could be merged sooner. The
> driver posted here is the initial version, so I suppose it will require
> more work.

I plan on reviewing this patch series (at least the non-dt parts). It's busy,
though, and I don't know exactly when I get the chance. But just so you know
that someone will be reviewing it.

Regards,

Hans

> 
> [1]http://lists.infradead.org/pipermail/linux-mediatek/2015-October/002525.html
> 
> ==
>  Device interface
> ==
> 
> In principle the driver bases on memory-to-memory framework:
> it provides a single video node and each opened file handle gets its own
> private context with separate buffer queues. Each context consist of 2
> buffer queues: OUTPUT (for source buffers, i.e. raw video frames)
> and CAPTURE (for destination buffers, i.e. encoded video frames).
> 
> The process of encoding video data from stream is a bit more complicated
> than typical memory-to-memory processing. We base on memory-to-memory
> framework and add the complicated part in our vb2 and v4l2 callback 
> functionss. So we can base on well done m2m memory-to-memory framework, 
> reduce duplicate code and make our driver code simple.
> 
> ==
>  VPU (Video Processor Unit)
> ==
> The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs.
> It is able to handle video decoding/encoding of in a range of formats.
> The driver provides with VPU firmware download, memory management and
> the communication interface between CPU and VPU.
> For VPU initialization, it will create virtual memory for CPU access and
> IOMMU address for vcodec hw device access. When a decode/encode instance
> opens a device node, vpu driver will download vpu firmware to the device.
> A decode/encode instant will decode/encode a frame using VPU 
> interface to interrupt vpu to handle decoding/encoding jobs.
> 
> Please have a look at the code and comments will be very much appreciated.
> 
> Andrew-CT Chen (3):
>   dt-bindings: Add a binding for Mediatek Video Processor Unit
>   arm64: dts: mediatek: Add node for Mediatek Video Processor Unit
>   media: platform: mtk-vpu: Support Mediatek VPU
> 
> Daniel Hsiao (1):
>   media: platform: mtk-vcodec: Add Mediatek VP8 Video Encoder Driver
> 
> Tiffany Lin (4):
>   dt-bindings: Add a binding for Mediatek Video Encoder
>   arm64: dts: mediatek: Add Video Encoder for MT8173
>   media: platform: mtk-vcodec: Add Mediatek V4L2 Video Encoder Driver
>   media: platform: mtk-vcodec: Add Mediatek H264 Video Encoder Driver
> 
>  .../devicetree/bindings/media/mediatek-vcodec.txt  |   58 +
>  .../devicetree/bindings/media/mediatek-vpu.txt |   27 +
>  arch/arm64/boot/dts/mediatek/mt8173.dtsi   |   58 +
>  drivers/media/platform/Kconfig |   19 +
>  drivers/media/platform/Makefile|5 +
>  drivers/media/platform/mtk-vcodec/Kconfig  |5 +
>  drivers/media/platform/mtk-vcodec/Makefile |   12 +
>  drivers/media/platform/mtk-vcodec/common/Makefile  |   12 +
>  .../media/platform/mtk-vcodec/common/venc_drv_if.c |  159 ++
>  .../media/platform/mtk-vcodec/h264_enc/Makefile|9 +
>  .../platform/mtk-vcodec/h264_enc/venc_h264_if.c|  529 ++
>  .../platform/mtk-vcodec/h264_enc/venc_h264_if.h|   53 +
>  .../platform/mtk-vcodec/h264_enc/venc_h264_vpu.c   |  341 
>  .../platform/mtk-vcodec/include/venc_drv_base.h|   68 +
>  .../platform/mtk-vcodec/include/venc_drv_if.h  |  187 +++
>  .../platform/mtk-vcodec/include/venc_ipi_msg.h |  212 +++
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h |  441 +
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 1773 
> 
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h |   28 +
>  .../media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c |  535 ++
>  .../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c  |  122 ++
>  .../media/platform/mtk-vcodec/mtk_vcodec_intr.c|  110 ++
>  .../media/platform/mtk-vcodec/mtk_vcodec_intr.h|   30 +
>  drivers/media/platform/mtk-vcodec/mtk_vcodec_pm.h  |   26 +
>  .../media/platform/mtk-vcodec/mtk_vcodec_util.c|  106 ++
>  .../media/platform/mtk-vcodec/mtk_vcodec_util.h|   66 +
>  drivers/media/platform/mtk-vcodec/vp8_enc/Makefile |9 +
>  .../platform/mtk-vcodec/vp8_enc/venc_vp8_if.c  |  371 
>  .../p

[PATCH 1/2] dts: dra7: add spi alias for qspi

2015-11-18 Thread Mugunthan V N
Set the alias for qspi to spi0

Signed-off-by: Mugunthan V N 
---
 arch/arm/boot/dts/dra7.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index bc672fb..b2badf9 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -41,6 +41,7 @@
ethernet1 = &cpsw_emac1;
d_can0 = &dcan1;
d_can1 = &dcan2;
+   spi0 = &qspi;
};
 
timer {
-- 
2.6.2.280.g74301d6

--
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


[PATCH 2/2] arm: dts: am4372: add spi alias for qspi

2015-11-18 Thread Mugunthan V N
Set the alias for qspi to spi0

Signed-off-by: Mugunthan V N 
---
 arch/arm/boot/dts/am4372.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index d83ff9c..bb03b80 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -30,6 +30,7 @@
serial5 = &uart5;
ethernet0 = &cpsw_emac0;
ethernet1 = &cpsw_emac1;
+   spi0 = &qspi;
};
 
cpus {
-- 
2.6.2.280.g74301d6

--
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


[PATCH 0/2] adding spi alias for qspi

2015-11-18 Thread Mugunthan V N
Adding missed spi alias for qspi which helps probe the qspi
device in U-Boot.

Mugunthan V N (2):
  dts: dra7: add spi alias for qspi
  arm: dts: am4372: add spi alias for qspi

 arch/arm/boot/dts/am4372.dtsi | 1 +
 arch/arm/boot/dts/dra7.dtsi   | 1 +
 2 files changed, 2 insertions(+)

-- 
2.6.2.280.g74301d6

--
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


Re: [PATCH] ARM: dts: vfxxx: Include support for dspi[23] functionality.

2015-11-18 Thread Stefan Agner
Verified too, looks good to me.

Acked-by: Stefan Agner 

--
Stefan

On 2015-11-18 19:54, Cory Tusar wrote:
> Extend the existing Vybrid DSPI devicetree implementation to also
> describe the dspi2 and dspi3 functional blocks.
> 
> Signed-off-by: Cory Tusar 
> ---
>  arch/arm/boot/dts/vfxxx.dtsi | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> index 1cca43a..858e60a 100644
> --- a/arch/arm/boot/dts/vfxxx.dtsi
> +++ b/arch/arm/boot/dts/vfxxx.dtsi
> @@ -453,6 +453,30 @@
>   status = "disabled";
>   };
>  
> + dspi2: dspi2@400ac000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,vf610-dspi";
> + reg = <0x400ac000 0x1000>;
> + interrupts = <69 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks VF610_CLK_DSPI2>;
> + clock-names = "dspi";
> + spi-num-chipselects = <2>;
> + status = "disabled";
> + };
> +
> + dspi3: dspi3@400ad000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "fsl,vf610-dspi";
> + reg = <0x400ad000 0x1000>;
> + interrupts = <70 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks VF610_CLK_DSPI3>;
> + clock-names = "dspi";
> + spi-num-chipselects = <2>;
> + status = "disabled";
> + };
> +
>   adc1: adc@400bb000 {
>   compatible = "fsl,vf610-adc";
>   reg = <0x400bb000 0x1000>;
--
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


Re: [PATCH] ARM: dts: vfxxx: Fix dspi[01] spi-num-chipselects.

2015-11-18 Thread Stefan Agner
On 2015-11-18 19:54, Cory Tusar wrote:
> Per the Vybrid Reference Manual (section 3.8.6.1), dspi0 has 6 chip
> select signals associated with it, while dspi1 has only 4.

That is right, verified by in my RM!

Acked-by: Stefan Agner 

> 
> Signed-off-by: Cory Tusar 
> ---
>  arch/arm/boot/dts/vfxxx.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> index 6736bae..1cca43a 100644
> --- a/arch/arm/boot/dts/vfxxx.dtsi
> +++ b/arch/arm/boot/dts/vfxxx.dtsi
> @@ -158,7 +158,7 @@
>   interrupts = <67 IRQ_TYPE_LEVEL_HIGH>;
>   clocks = <&clks VF610_CLK_DSPI0>;
>   clock-names = "dspi";
> - spi-num-chipselects = <5>;
> + spi-num-chipselects = <6>;
>   status = "disabled";
>   };
>  
> @@ -170,7 +170,7 @@
>   interrupts = <68 IRQ_TYPE_LEVEL_HIGH>;
>   clocks = <&clks VF610_CLK_DSPI1>;
>   clock-names = "dspi";
> - spi-num-chipselects = <5>;
> + spi-num-chipselects = <4>;
>   status = "disabled";
>   };
--
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


Re: [PATCH v2 5/5] misc: eeprom_93xx46: Add support for a GPIO 'select' line.

2015-11-18 Thread Vladimir Zapolskiy
On 19.11.2015 05:29, Cory Tusar wrote:
> This commit adds support to the eeprom_93x46 driver allowing a GPIO line
> to function as a 'select' or 'enable' signal prior to accessing the
> EEPROM.
> 
> Signed-off-by: Cory Tusar 
> ---
>  drivers/misc/eeprom/eeprom_93xx46.c | 26 ++
>  include/linux/eeprom_93xx46.h   |  1 +
>  2 files changed, 27 insertions(+)
> 
> diff --git a/drivers/misc/eeprom/eeprom_93xx46.c 
> b/drivers/misc/eeprom/eeprom_93xx46.c
> index 0386b03..375951f 100644
> --- a/drivers/misc/eeprom/eeprom_93xx46.c
> +++ b/drivers/misc/eeprom/eeprom_93xx46.c
> @@ -10,11 +10,14 @@
>  
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 

Please double check, adding only linux/of_gpio.h header should work,
linux/gpio.h and linux/gpio/consumer.h are redundant.

>  #include 
>  #include 
>  #include 
> @@ -344,6 +347,20 @@ static ssize_t eeprom_93xx46_store_erase(struct device 
> *dev,
>  static DEVICE_ATTR(erase, S_IWUSR, NULL, eeprom_93xx46_store_erase);
>  
>  #ifdef CONFIG_OF
> +static void select_assert(void *context)
> +{
> + struct eeprom_93xx46_dev *edev = context;
> +
> + gpiod_set_value_cansleep(gpio_to_desc(edev->pdata->select_gpio), 1);

I would suggest to use gpio_set_value()

> +}
> +
> +static void select_deassert(void *context)
> +{
> + struct eeprom_93xx46_dev *edev = context;
> +
> + gpiod_set_value_cansleep(gpio_to_desc(edev->pdata->select_gpio), 0);

Same here.

> +}
> +
>  static const struct of_device_id eeprom_93xx46_of_table[] = {
>   { .compatible = "eeprom-93xx46", },
>   { .compatible = "atmel,at93c46d", .data = &atmel_at93c46d_data, },
> @@ -385,6 +402,15 @@ static int eeprom_93xx46_probe_dt(struct spi_device *spi)
>   if (of_property_read_bool(np, "read-only"))
>   pd->flags |= EE_READONLY;
>  
> + ret = of_get_named_gpio(np, "select-gpios", 0);

gpios or gpio? I see only one requested gpio.

> + if (ret < 0) {
> + pd->select_gpio = -1;
> + } else {
> + pd->select_gpio = ret;
> + pd->prepare = select_assert;
> + pd->finish = select_deassert;
> + }
> +
>   if (of_id->data) {
>   const struct eeprom_93xx46_devtype_data *data = of_id->data;
>  
> diff --git a/include/linux/eeprom_93xx46.h b/include/linux/eeprom_93xx46.h
> index 92fa4c3..aa472c7 100644
> --- a/include/linux/eeprom_93xx46.h
> +++ b/include/linux/eeprom_93xx46.h
> @@ -21,4 +21,5 @@ struct eeprom_93xx46_platform_data {
>*/
>   void (*prepare)(void *);
>   void (*finish)(void *);
> + unsigned int select_gpio;

Same questions as in v2 4/5.

>  };
> 

--
With best wishes,
Vladimir
--
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


Re: [PATCH v2 4/5] misc: eeprom_93xx46: Add quirks to support Atmel AT93C46D device.

2015-11-18 Thread Vladimir Zapolskiy
On 19.11.2015 05:29, Cory Tusar wrote:
> Atmel devices in this family have some quirks not found in other similar
> chips - they do not support a sequential read of the entire EEPROM
> contents, and the control word sent at the start of each operation
> varies in bit length.
> 
> This commit adds quirk support to the driver and modifies the read
> implementation to support non-sequential reads for consistency with
> other misc/eeprom drivers.
> 
> Tested on a custom Freescale VF610-based platform, with an AT93C46D
> device attached via dspi2.  The spi-gpio driver was used to allow the
> necessary non-byte-sized transfers.
> 
> Signed-off-by: Cory Tusar 
> ---
>  drivers/misc/eeprom/eeprom_93xx46.c | 128 
> ++--
>  include/linux/eeprom_93xx46.h   |   6 ++
>  2 files changed, 98 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/misc/eeprom/eeprom_93xx46.c 
> b/drivers/misc/eeprom/eeprom_93xx46.c
> index 1f29d9a..0386b03 100644
> --- a/drivers/misc/eeprom/eeprom_93xx46.c
> +++ b/drivers/misc/eeprom/eeprom_93xx46.c
> @@ -27,6 +27,15 @@
>  #define ADDR_ERAL0x20
>  #define ADDR_EWEN0x30
>  
> +struct eeprom_93xx46_devtype_data {
> + unsigned int quirks;
> +};
> +
> +static const struct eeprom_93xx46_devtype_data atmel_at93c46d_data = {
> + .quirks = EEPROM_93XX46_QUIRK_SINGLE_WORD_READ |
> +   EEPROM_93XX46_QUIRK_INSTRUCTION_LENGTH,
> +};
> +
>  struct eeprom_93xx46_dev {
>   struct spi_device *spi;
>   struct eeprom_93xx46_platform_data *pdata;
> @@ -35,6 +44,16 @@ struct eeprom_93xx46_dev {
>   int addrlen;
>  };
>  
> +static inline bool has_quirk_single_word_read(struct eeprom_93xx46_dev *edev)
> +{
> + return !!(edev->pdata->quirks & EEPROM_93XX46_QUIRK_SINGLE_WORD_READ);

bool return type will do the work, please remove !!.

> +}
> +
> +static inline bool has_quirk_instruction_length(struct eeprom_93xx46_dev 
> *edev)
> +{
> + return !!(edev->pdata->quirks & EEPROM_93XX46_QUIRK_INSTRUCTION_LENGTH);

Same here.

> +}
> +
>  static ssize_t
>  eeprom_93xx46_bin_read(struct file *filp, struct kobject *kobj,
>  struct bin_attribute *bin_attr,
> @@ -42,58 +61,73 @@ eeprom_93xx46_bin_read(struct file *filp, struct kobject 
> *kobj,
>  {
>   struct eeprom_93xx46_dev *edev;
>   struct device *dev;
> - struct spi_message m;
> - struct spi_transfer t[2];
> - int bits, ret;
> - u16 cmd_addr;
> + ssize_t ret = 0;
>  
>   dev = container_of(kobj, struct device, kobj);
>   edev = dev_get_drvdata(dev);
>  
> - cmd_addr = OP_READ << edev->addrlen;
> + mutex_lock(&edev->lock);
>  
> - if (edev->addrlen == 7) {
> - cmd_addr |= off & 0x7f;
> - bits = 10;
> - } else {
> - cmd_addr |= (off >> 1) & 0x3f;
> - bits = 9;
> - }
> + if (edev->pdata->prepare)
> + edev->pdata->prepare(edev);
>  
> - dev_dbg(&edev->spi->dev, "read cmd 0x%x, %d Hz\n",
> - cmd_addr, edev->spi->max_speed_hz);
> + while (count) {
> + struct spi_message m;
> + struct spi_transfer t[2] = { { 0 } };

Just { 0 };

> + u16 cmd_addr = OP_READ << edev->addrlen;
> + size_t nbytes = count;
> + int bits;
> + int err;
> +
> + if (edev->addrlen == 7) {
> + cmd_addr |= off & 0x7f;
> + bits = 10;
> + if (has_quirk_single_word_read(edev))
> + nbytes = 1;
> + } else {
> + cmd_addr |= (off >> 1) & 0x3f;
> + bits = 9;
> + if (has_quirk_single_word_read(edev))
> + nbytes = 2;
> + }
>  
> - spi_message_init(&m);
> - memset(t, 0, sizeof(t));
> + dev_dbg(&edev->spi->dev, "read cmd 0x%x, %d Hz\n",
> + cmd_addr, edev->spi->max_speed_hz);
>  
> - t[0].tx_buf = (char *)&cmd_addr;
> - t[0].len = 2;
> - t[0].bits_per_word = bits;
> - spi_message_add_tail(&t[0], &m);
> + spi_message_init(&m);
>  
> - t[1].rx_buf = buf;
> - t[1].len = count;
> - t[1].bits_per_word = 8;
> - spi_message_add_tail(&t[1], &m);
> + t[0].tx_buf = (char *)&cmd_addr;
> + t[0].len = 2;
> + t[0].bits_per_word = bits;
> + spi_message_add_tail(&t[0], &m);
>  
> - mutex_lock(&edev->lock);
> + t[1].rx_buf = buf;
> + t[1].len = count;
> + t[1].bits_per_word = 8;
> + spi_message_add_tail(&t[1], &m);
>  
> - if (edev->pdata->prepare)
> - edev->pdata->prepare(edev);
> + err = spi_sync(edev->spi, &m);
> + /* have to wait at least Tcsl ns */
> + ndelay(250);
>  
> - ret = spi_sync(edev->spi, &m);
> - /* have to wait at least Tcsl ns */
> - ndelay(250);
> -

Re: [PATCH v2 3/5] misc: eeprom_93xx46: Implement eeprom_93xx46 DT bindings.

2015-11-18 Thread Vladimir Zapolskiy
Hi Cory,

On 19.11.2015 05:29, Cory Tusar wrote:
> This commit implements bindings in the eeprom_93xx46 driver allowing
> device word size and read-only attributes to be specified via
> devicetree.
> 
> Signed-off-by: Cory Tusar 
> ---
>  drivers/misc/eeprom/eeprom_93xx46.c | 62 
> +
>  1 file changed, 62 insertions(+)
> 
> diff --git a/drivers/misc/eeprom/eeprom_93xx46.c 
> b/drivers/misc/eeprom/eeprom_93xx46.c
> index e1bf0a5..1f29d9a 100644
> --- a/drivers/misc/eeprom/eeprom_93xx46.c
> +++ b/drivers/misc/eeprom/eeprom_93xx46.c
> @@ -13,6 +13,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -294,12 +296,71 @@ static ssize_t eeprom_93xx46_store_erase(struct device 
> *dev,
>  }
>  static DEVICE_ATTR(erase, S_IWUSR, NULL, eeprom_93xx46_store_erase);
>  
> +#ifdef CONFIG_OF
> +static const struct of_device_id eeprom_93xx46_of_table[] = {
> + { .compatible = "eeprom-93xx46", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, eeprom_93xx46_of_table);
> +

Please move this declaration closer to struct spi_driver
eeprom_93xx46_driver below.

Also you can avoid #ifdef here, if you write

   .of_match_table = of_match_ptr(eeprom_93xx46_of_table)

Whenever possible please avoid #ifdef's in .c files.

> +static int eeprom_93xx46_probe_dt(struct spi_device *spi)
> +{
> + struct device_node *np = spi->dev.of_node;
> + struct eeprom_93xx46_platform_data *pd;
> + u32 tmp;
> + int ret;
> +
> + if (!of_match_device(eeprom_93xx46_of_table, &spi->dev))
> + return 0;
> +
> + pd = devm_kzalloc(&spi->dev, sizeof(*pd), GFP_KERNEL);
> + if (!pd)
> + return -ENOMEM;
> +
> + ret = of_property_read_u32(np, "data-size", &tmp);
> + if (ret < 0) {
> + dev_err(&spi->dev, "data-size property not found\n");
> + goto error_free;

Because you use devm_* resource allocation in .probe, just return error.

Plus I would suggest to change "data-size" property to an optional one,
here I mean that if it is omitted, then by default consider pd->flags |=
EE_ADDR8.

> + }
> +
> + if (tmp == 8) {
> + pd->flags |= EE_ADDR8;
> + } else if (tmp == 16) {
> + pd->flags |= EE_ADDR16;
> + } else {
> + dev_err(&spi->dev, "invalid data-size (%d)\n", tmp);
> + goto error_free;

Same here.

> + }
> +
> + if (of_property_read_bool(np, "read-only"))
> + pd->flags |= EE_READONLY;
> +
> + spi->dev.platform_data = pd;
> +
> + return 1;

On success please return 0.

> +error_free:
> + devm_kfree(&spi->dev, pd);
> + return ret;
> +}
> +
> +#else
> +static inline int eeprom_93xx46_probe_dt(struct spi_device *spi)
> +{
> + return 0;
> +}
> +#endif
> +

I actually don't see a point to have #ifdef CONFIG_OF here.

Instead please add a check for !spi->dev.of_node at the beginning of
eeprom_93xx46_probe_dt() or in .probe()

>  static int eeprom_93xx46_probe(struct spi_device *spi)
>  {
>   struct eeprom_93xx46_platform_data *pd;
>   struct eeprom_93xx46_dev *edev;
>   int err;
>  
> + err = eeprom_93xx46_probe_dt(spi);
> + if (err < 0)
> + return err;
> +
>   pd = spi->dev.platform_data;
>   if (!pd) {
>   dev_err(&spi->dev, "missing platform data\n");
> @@ -370,6 +431,7 @@ static int eeprom_93xx46_remove(struct spi_device *spi)
>  static struct spi_driver eeprom_93xx46_driver = {
>   .driver = {
>   .name   = "93xx46",
> + .of_match_table = eeprom_93xx46_of_table,
>   },
>   .probe  = eeprom_93xx46_probe,
>   .remove = eeprom_93xx46_remove,
> 
--
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


[PATCH v9] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller

2015-11-18 Thread Bharat Kumar Gogada
Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.

Signed-off-by: Bharat Kumar Gogada 
Signed-off-by: Ravi Kiran Gummaluri 
Acked-by: Rob Herring 
---
Changes for v9:
- Modified logic in nwl_irq_domain_alloc to check availabilty of contiguous
hw irq for multi MSI.
- Removed allocation of page for MSI address, using dummy address.
---
 .../devicetree/bindings/pci/xilinx-nwl-pcie.txt|   68 ++
 drivers/pci/host/Kconfig   |   10 +
 drivers/pci/host/Makefile  |1 +
 drivers/pci/host/pcie-xilinx-nwl.c | 1100 
 4 files changed, 1179 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
 create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c

diff --git a/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt 
b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
new file mode 100644
index 000..3b2a9ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
@@ -0,0 +1,68 @@
+* Xilinx NWL PCIe Root Port Bridge DT description
+
+Required properties:
+- compatible: Should contain "xlnx,nwl-pcie-2.11"
+- #address-cells: Address representation for root ports, set to <3>
+- #size-cells: Size representation for root ports, set to <2>
+- #interrupt-cells: specifies the number of cells needed to encode an
+   interrupt source. The value must be 1.
+- reg: Should contain Bridge, PCIe Controller registers location,
+   configuration sapce, and length
+- reg-names: Must include the following entries:
+   "breg": bridge registers
+   "pcireg": PCIe controller registers
+   "cfg": configuration space region
+- device_type: must be "pci"
+- interrupts: Should contain NWL PCIe interrupt
+- interrupt-names: Must include the following entries:
+   "msi1, msi0": interrupt asserted when msi is received
+   "intx": interrupt that is asserted when an legacy interrupt is received
+   "misc": interrupt asserted when miscellaneous is received
+- interrupt-map-mask and interrupt-map: standard PCI properties to define the
+   mapping of the PCI interface to interrupt numbers.
+- ranges: ranges for the PCI memory regions (I/O space region is not
+   supported by hardware)
+   Please refer to the standard PCI bus binding document for a more
+   detailed explanation
+- msi-controller: indicates that this is MSI controller node
+- msi-parent:  MSI parent of the root complex itself
+- legacy-interrupt-controller: Interrupt controller device node for Legacy 
interrupts
+   - interrupt-controller: identifies the node as an interrupt controller
+   - #interrupt-cells: should be set to 1
+   - #address-cells: specifies the number of cells needed to encode an
+   address. The value must be 0.
+
+
+Example:
+
+
+nwl_pcie: pcie@fd0e {
+   #address-cells = <3>;
+   #size-cells = <2>;
+   compatible = "xlnx,nwl-pcie-2.11";
+   #interrupt-cells = <1>;
+   msi-controller;
+   device_type = "pci";
+   interrupt-parent = <&gic>;
+   interrupts = <0 114 4>, <0 115 4>, <0 116 4>, <0 117 4>, <0 118 4>;
+   interrupt-names = "msi0", "msi1", "intx", "dummy", "misc";
+   interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+   interrupt-map = <0x0 0x0 0x0 0x1 &pcie_intc 0x1>,
+   <0x0 0x0 0x0 0x2 &pcie_intc 0x2>,
+   <0x0 0x0 0x0 0x3 &pcie_intc 0x3>,
+   <0x0 0x0 0x0 0x4 &pcie_intc 0x4>;
+
+   msi-parent = <&nwl_pcie>;
+   reg = <0x0 0xfd0e 0x1000>,
+ <0x0 0xfd48 0x1000>,
+ <0x0 0xe000 0x100>;
+   reg-names = "breg", "pcireg", "cfg";
+   ranges = <0x0200 0x 0xe100 0x 0xe100 0 
0x0f00>;
+
+   pcie_intc: legacy-interrupt-controller {
+   interrupt-controller;
+   #address-cells = <0>;
+   #interrupt-cells = <1>;
+   };
+
+};
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index d5e58ba..24cbcba 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -15,6 +15,16 @@ config PCI_MVEBU
depends on ARCH_MVEBU || ARCH_DOVE
depends on OF
 
+config PCIE_XILINX_NWL
+   bool "NWL PCIe Core"
+   depends on ARCH_ZYNQMP
+   select PCI_MSI_IRQ_DOMAIN if PCI_MSI
+   help
+Say 'Y' here if you want kernel to support for Xilinx
+NWL PCIe controller. The controller can act as Root Port
+or End Point. The current option selection will only
+support root port enabling.
+
 config PCIE_DW
bool
 
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 140d66f..6a56df7 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_PCI_HOST_GENERIC) += pci-host-generic.o
 obj-$(CONFIG_PCIE_SPEAR13XX) += pcie-spear13xx.o
 obj-$(CONFIG_PCI_KEYSTONE) += pci-keystone-

Re: [PATCH 1/2] usb: doc: dwc3-xilinx: Add devicetree bindings

2015-11-18 Thread Felipe Balbi

Hi,

Rob Herring  writes:
> On Wed, Nov 18, 2015 at 5:02 PM, Felipe Balbi  wrote:
>>
>> Hi,
>>
>> Rob Herring  writes:
>>> On Wed, Nov 18, 2015 at 06:20:31PM +0530, Subbaraya Sundeep Bhatta wrote:
 This patch adds binding doc for Xilinx DWC3 glue driver.

 Signed-off-by: Subbaraya Sundeep Bhatta 
>>>
>>> I really dislike how the DWC3 binding has been done. The sub-node here
>>> is pointless. The only thing the outer node does is add clocks which
>>> should simply be part of the DWC3 node. Presumably the IP block needs
>>> some clocks...
>>>
>>> Anyway, it's self-contained within the DWC3, so I won't make you clean
>>> up the mess.
>>
>> heh, it's definitely not pointless. We get a lot of free goodies by
>> doing it that way. I'm just not going to repeat it once again. But in
>> summary:
>>
>> a) we force people to write glue layers for *only* their HW specific
>> details
>>
>> b) there's really no way to abuse dwc3 core because there's no symbol
>> exported from dwc3 core to glue
>
> Both are doable independent of DT.
>
>> c) PM (both system sleep and runtime) becomes a lot simpler with core
>> only caring about what PM details delivered by SNPS (e.g. Hibernation
>> mode from DWC3) and glue only has to consider the SoC integration parts
>> of PM (for OMAP that would be PRCM details, hwmod, etc).
>
> No doubt OMAP is special.

not only OMAP. Every single SoC will integrate a particular IP in its
own way.

>> I'm definitely not going to change dwc3 because it has made my life a
>> lot saner. Definitely a lot saner than MUSB. Besides, DTS is supposed to
>> describe the HW and that's, really, how the HW is.
>
> So reading the description, the DWC3 has no clocks?

of course it has, and you have registers in DWC3 to change some of the
parents of the clocks it uses internally.

>> There's a piece of HW which is somewhat platform agnostic and delivered
>> by SNPS as a black box (SNPS customers don't touch SNPS RTL) and there's
>> another piece of HW which bridges this dwc3 to the platform specific
>> details and integration context of the platform (for OMAP that would the
>> SYSCONFIG/SYSSTATUS registers, Clock autogating, PRCM, etc, etc etc).
>
> It is a black box, but with dozens of configuration options typically.

all of which are detected within the driver. For those which can't be,
we have bindings.

>> So you _do_ in fact, have two separate pieces of HW which are SW visible
>> and controllable independently. They each have their own IRQs (though in
>> some SoCs they share the same line), they're own address space, yada
>> yada yada.
>
> When that is the case, I have no problem with this split, but I don't
> see any of these examples in this particular case. So how should the
> binding look when there is no vendor specific glue? Are we supposed to
> keep the binding structure to appease the needs of the driver?

If there really is *no* vendor specific glue, nothing prevents them from
patching dwc3 to understand *OPTIONAL* clocks and use dwc3 directly. As
long as it doesn't break any of the platforms currently supported and
doesn't look ugly, fine with me.

In fact, there's one company which has been using dwc3 without a glue
layer. I forgot who told me they didn't need a glue layer, but it's in
the archives.

-- 
balbi


signature.asc
Description: PGP signature


Re: [PATCH v4 3/3] ARM: dts: rockchip: Add the OTP gpio pinctrl

2015-11-18 Thread Heiko Stuebner
Hi Caesar,

Am Donnerstag, 19. November 2015, 10:44:02 schrieb Caesar Wang:
> 在 2015年10月25日 15:55, Heiko Stübner 写道:
> > Am Freitag, 23. Oktober 2015, 08:25:08 schrieb Doug Anderson:
> >> On Fri, Oct 23, 2015 at 4:25 AM, Caesar Wang  wrote:
> >>> Add the "init" anf "sleep" pinctrl as the OTP gpio state.
> >>> We need the OTP pin is gpio state before resetting the TSADC controller,
> >>> since the tshut polarity will generate a high signal.
> >>>
> >>> "init" pinctrl property is defined by Doug's Patch[0].
> >>>
> >>> Patch[0]:
> >>> https://patchwork.kernel.org/patch/7454311/
> >>>
> >>> Signed-off-by: Caesar Wang 
> >>> Reviewed-by: Douglas Anderson 
> >>> ---
> >>>
> >>> Changes in v4: None
> >>>
> >>> Changes in v3:
> >>>- Add the "sleep" pinctrl as the gpio state in PATCH[3/3]
> >>>
> >>> Changes in v2:
> >>>- Add some commits for more obvious in PATCH[2/2]
> >>>
> >>> Changes in v1:
> >>>- As the Doug comments, drop the thermal driver patchs since
> >>>
> >>>  we can with pinctrl changing to work.
> >>>
> >>>- As the Doug's patch to add the 'init' property.
> >>>   
> >>>   arch/arm/boot/dts/rk3288.dtsi | 10 --
> >>>   1 file changed, 8 insertions(+), 2 deletions(-)
> >> I realized that the subject of this patch should probably contain the
> >> word rk3288, but I presume Heiko would rather add that himself than
> >> for you to spin this again.  ;)
> > yep :-) ... no need to respin for such an easy change
> 
> That's seem this patch didn't merge into your v4.5-armsoc/soc branch.:-)
> 
> I guess this patch should merge into  kernel-4.4 since the Patch[1/3] / 
> [2/3] have been merged into 4.4-rc1.:-P

thanks for the reminder :-)

It seems I didn't get a notice when the core thermal changes were merged, so 
this patch seems to have dropped of my radar. It is clearly a fix for a real 
issue, so I've added it to my fixes branch for 4.4.


Heiko
--
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


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

2015-11-18 Thread Moritz Fischer
Hi Alan,

while trying to implement something that works for Zynq along these lines
I stumbled upon some minor stuff.

On Tue, Nov 3, 2015 at 9:11 AM,   wrote:

> + * Return: 0 on success, negative error code otherwise.
> + */
> +int fpga_bridge_register(struct device *dev, const char *name,
> +struct fpga_bridge_ops *br_ops, void *priv)

const struct fpga_bridge_ops

> +int fpga_bridge_register(struct device *dev, const char *name,
> +struct fpga_bridge_ops *br_ops, void *priv);
const struct fpga_bridge_ops

Cheers,

Moritz
--
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


Re: [PATCH v3 2/5] dt-bindings: soc: add document for rockchip reboot notifier driver

2015-11-18 Thread Heiko Stuebner
Hi Andy,

Am Donnerstag, 19. November 2015, 09:17:37 schrieb Andy Yan:
> Hi Rob:
> 
> On 2015年11月19日 06:59, Rob Herring wrote:
> > On Wed, Nov 18, 2015 at 05:53:30PM +0800, Andy Yan wrote:
> >> Add devicetree binding document for rockchip reboot nofifier driver
> > Just reading the subject this is way too specific to the Linux driver
> > needs rather than a h/w description. Please don't create fake DT nodes
> > just to bind to drivers. Whatever &pmu is is probably what should have
> > the DT node. Let the driver for it create child devices if you need
> > that.
> 
>  This is note a fake DT nodes, we really need it to tell the driver
>   which register to use to store the reboot mode. Because rockchip
>   use different register file to store the reboot mode on different
>   platform, on rk3066,rk3188, rk3288,it use  one of the PMU 
> register, on
>   the incoming RK3036, it use one of the GRF register, and it use 
> one  of
>   the PMUGRF register for arm64 platform rk3368. On the other hand, the
>   PMU/GRF/PMUGRF register file are mapped as "syscon", then referenced
>   by other DT nodes by phandle. So maybe let it as a separate DT 
> node here
>   is better.

or alternatively we could do something similar to what the bl-switcher 
cupfreq-driver does. Take a look at

drivers/cpufreq/arm_big_little.c
drivers/clk/clk-mb86s7x.c

We already have the core restart-handler code in the clock-tree, so could 
maybe simply do the
platform_device_register_simple("rockchip-reboot", -1, NULL, 0);
in that common code?

Though I'm not yet sure how to get the platform-data. I guess one option would 
be to do things like the 3288 suspend code does (arch/arm/mach-rockchip/pm.c 
at the bottom), by having the per-soc-data in the driver and then matching 
against the pmu. Because the pmu is not part of the clock controller binding 
(and probably also shouldn't be).


Heiko


--
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


[PATCH] ARM: dts: vfxxx: Fix dspi[01] spi-num-chipselects.

2015-11-18 Thread Cory Tusar
Per the Vybrid Reference Manual (section 3.8.6.1), dspi0 has 6 chip
select signals associated with it, while dspi1 has only 4.

Signed-off-by: Cory Tusar 
---
 arch/arm/boot/dts/vfxxx.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 6736bae..1cca43a 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -158,7 +158,7 @@
interrupts = <67 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks VF610_CLK_DSPI0>;
clock-names = "dspi";
-   spi-num-chipselects = <5>;
+   spi-num-chipselects = <6>;
status = "disabled";
};
 
@@ -170,7 +170,7 @@
interrupts = <68 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks VF610_CLK_DSPI1>;
clock-names = "dspi";
-   spi-num-chipselects = <5>;
+   spi-num-chipselects = <4>;
status = "disabled";
};
 
-- 
2.4.10

--
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


[PATCH] ARM: dts: vfxxx: Include support for dspi[23] functionality.

2015-11-18 Thread Cory Tusar
Extend the existing Vybrid DSPI devicetree implementation to also
describe the dspi2 and dspi3 functional blocks.

Signed-off-by: Cory Tusar 
---
 arch/arm/boot/dts/vfxxx.dtsi | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 1cca43a..858e60a 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -453,6 +453,30 @@
status = "disabled";
};
 
+   dspi2: dspi2@400ac000 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,vf610-dspi";
+   reg = <0x400ac000 0x1000>;
+   interrupts = <69 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&clks VF610_CLK_DSPI2>;
+   clock-names = "dspi";
+   spi-num-chipselects = <2>;
+   status = "disabled";
+   };
+
+   dspi3: dspi3@400ad000 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,vf610-dspi";
+   reg = <0x400ad000 0x1000>;
+   interrupts = <70 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&clks VF610_CLK_DSPI3>;
+   clock-names = "dspi";
+   spi-num-chipselects = <2>;
+   status = "disabled";
+   };
+
adc1: adc@400bb000 {
compatible = "fsl,vf610-adc";
reg = <0x400bb000 0x1000>;
-- 
2.4.10

--
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


[PATCH v2 1/7] dt-binding: Add ngpios property to GPIO controller node

2015-11-18 Thread Pramod Kumar
Add ngpios property to the gpio controller's DT node so that controller
driver extracts total number of in-use gpio lines from DT and removes
dependency on driver.

Signed-off-by: Pramod Kumar 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt 
b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt
index 16589fb6..8b1e5d1 100644
--- a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt
@@ -10,6 +10,9 @@ Required properties:
 Define the base and range of the I/O address space that contains the Cygnus
 GPIO/PINCONF controller registers
 
+- ngpios:
+Total number of in-use slots in GPIO controller
+
 - #gpio-cells:
 Must be two. The first cell is the GPIO pin number (within the
 controller's pin space) and the second cell is used for the following:
@@ -57,6 +60,7 @@ Example:
compatible = "brcm,cygnus-ccm-gpio";
reg = <0x1800a000 0x50>,
  <0x0301d164 0x20>;
+   ngpios = <24>;
#gpio-cells = <2>;
gpio-controller;
interrupts = ;
@@ -78,6 +82,7 @@ Example:
gpio_asiu: gpio@180a5000 {
compatible = "brcm,cygnus-asiu-gpio";
reg = <0x180a5000 0x668>;
+   ngpios = <146>;
#gpio-cells = <2>;
gpio-controller;
interrupts = ;
-- 
1.9.1

--
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


[PATCH v2 5/7] gpio: Rename func/macro/var to IP-block,iproc

2015-11-18 Thread Pramod Kumar
Change functions, macros and variables name from cygnus to IP block,
iproc, so that it could be used in all iproc based future SoCs having
same GPIO controller block.

Signed-off-by: Pramod Kumar 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c | 306 +++---
 1 file changed, 154 insertions(+), 152 deletions(-)

diff --git a/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c 
b/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
index d0d788f..ed21ab2 100644
--- a/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
+++ b/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
@@ -10,14 +10,16 @@
  * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  *
- * This file contains the Broadcom Cygnus GPIO driver that supports 3
- * GPIO controllers on Cygnus including the ASIU GPIO controller, the
+ * This file contains the Broadcom Iproc GPIO driver that supports 3
+ * GPIO controllers on Iproc including the ASIU GPIO controller, the
  * chipCommonG GPIO controller, and the always-on GPIO controller. Basic
  * PINCONF such as bias pull up/down, and drive strength are also supported
  * in this driver.
  *
- * Pins from the ASIU GPIO can be individually muxed to GPIO function,
- * through the interaction with the Cygnus IOMUX controller
+ * It provides the functionality where pins from the GPIO can be
+ * individually muxed to GPIO function, if individual pad
+ * configuration is supported, through the interaction with respective
+ * SoCs IOMUX controller.
  */
 
 #include 
@@ -34,42 +36,42 @@
 
 #include "../pinctrl-utils.h"
 
-#define CYGNUS_GPIO_DATA_IN_OFFSET   0x00
-#define CYGNUS_GPIO_DATA_OUT_OFFSET  0x04
-#define CYGNUS_GPIO_OUT_EN_OFFSET0x08
-#define CYGNUS_GPIO_INT_TYPE_OFFSET  0x0c
-#define CYGNUS_GPIO_INT_DE_OFFSET0x10
-#define CYGNUS_GPIO_INT_EDGE_OFFSET  0x14
-#define CYGNUS_GPIO_INT_MSK_OFFSET   0x18
-#define CYGNUS_GPIO_INT_STAT_OFFSET  0x1c
-#define CYGNUS_GPIO_INT_MSTAT_OFFSET 0x20
-#define CYGNUS_GPIO_INT_CLR_OFFSET   0x24
-#define CYGNUS_GPIO_PAD_RES_OFFSET   0x34
-#define CYGNUS_GPIO_RES_EN_OFFSET0x38
+#define IPROC_GPIO_DATA_IN_OFFSET   0x00
+#define IPROC_GPIO_DATA_OUT_OFFSET  0x04
+#define IPROC_GPIO_OUT_EN_OFFSET0x08
+#define IPROC_GPIO_INT_TYPE_OFFSET  0x0c
+#define IPROC_GPIO_INT_DE_OFFSET0x10
+#define IPROC_GPIO_INT_EDGE_OFFSET  0x14
+#define IPROC_GPIO_INT_MSK_OFFSET   0x18
+#define IPROC_GPIO_INT_STAT_OFFSET  0x1c
+#define IPROC_GPIO_INT_MSTAT_OFFSET 0x20
+#define IPROC_GPIO_INT_CLR_OFFSET   0x24
+#define IPROC_GPIO_PAD_RES_OFFSET   0x34
+#define IPROC_GPIO_RES_EN_OFFSET0x38
 
 /* drive strength control for ASIU GPIO */
-#define CYGNUS_GPIO_ASIU_DRV0_CTRL_OFFSET 0x58
+#define IPROC_GPIO_ASIU_DRV0_CTRL_OFFSET 0x58
 
 /* drive strength control for CCM/CRMU (AON) GPIO */
-#define CYGNUS_GPIO_DRV0_CTRL_OFFSET  0x00
+#define IPROC_GPIO_DRV0_CTRL_OFFSET  0x00
 
 #define GPIO_BANK_SIZE 0x200
 #define NGPIOS_PER_BANK 32
 #define GPIO_BANK(pin) ((pin) / NGPIOS_PER_BANK)
 
-#define CYGNUS_GPIO_REG(pin, reg) (GPIO_BANK(pin) * GPIO_BANK_SIZE + (reg))
-#define CYGNUS_GPIO_SHIFT(pin) ((pin) % NGPIOS_PER_BANK)
+#define IPROC_GPIO_REG(pin, reg) (GPIO_BANK(pin) * GPIO_BANK_SIZE + (reg))
+#define IPROC_GPIO_SHIFT(pin) ((pin) % NGPIOS_PER_BANK)
 
 #define GPIO_DRV_STRENGTH_BIT_SHIFT  20
 #define GPIO_DRV_STRENGTH_BITS   3
 #define GPIO_DRV_STRENGTH_BIT_MASK   ((1 << GPIO_DRV_STRENGTH_BITS) - 1)
 
 /*
- * Cygnus GPIO core
+ * Iproc GPIO core
  *
  * @dev: pointer to device
- * @base: I/O register base for Cygnus GPIO controller
- * @io_ctrl: I/O register base for certain type of Cygnus GPIO controller that
+ * @base: I/O register base for Iproc GPIO controller
+ * @io_ctrl: I/O register base for certain type of Iproc GPIO controller that
  * has the PINCONF support implemented outside of the GPIO block
  * @lock: lock to protect access to I/O registers
  * @gc: GPIO chip
@@ -79,7 +81,7 @@
  * @pctl: pointer to pinctrl_dev
  * @pctldesc: pinctrl descriptor
  */
-struct cygnus_gpio {
+struct iproc_gpio {
struct device *dev;
 
void __iomem *base;
@@ -96,33 +98,33 @@ struct cygnus_gpio {
struct pinctrl_desc pctldesc;
 };
 
-static inline struct cygnus_gpio *to_cygnus_gpio(struct gpio_chip *gc)
+static inline struct iproc_gpio *to_iproc_gpio(struct gpio_chip *gc)
 {
-   return container_of(gc, struct cygnus_gpio, gc);
+   return container_of(gc, struct iproc_gpio, gc);
 }
 
 /*
  * Mapping from PINCONF pins to GPIO pins is 1-to-1
  */
-static inline unsigned cygnus_pin_to_gpio(unsigned pin)
+static inline unsigned iproc_pin_to_gpio(unsigned pin)
 {
return pin;
 }
 
 /**
- *  cygnus_set_bit - set or clear one bit (corresponding to the GPIO pin) in a
- *  Cygnus GPIO register
+ *  iproc_set_bit - set or clear one bit (corresponding to the GPIO pin) in a
+ *  Iproc GPIO register
  *
- *  @cygnus_gpio: Cygnus GPIO device
+ *  @iproc_gpio: Iproc GPIO devi

[PATCH v2 2/7] dts: define ngpios property in gpio controller's node

2015-11-18 Thread Pramod Kumar
Add ngpios property in cygnus ASIU, CCM and CRMU gpio controller's node

Signed-off-by: Pramod Kumar 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 arch/arm/boot/dts/bcm-cygnus.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi 
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 2778533..59c4330 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -101,6 +101,7 @@
compatible = "brcm,cygnus-crmu-gpio";
reg = <0x03024800 0x50>,
  <0x03024008 0x18>;
+   ngpios = <6>;
#gpio-cells = <2>;
gpio-controller;
};
@@ -127,6 +128,7 @@
compatible = "brcm,cygnus-ccm-gpio";
reg = <0x1800a000 0x50>,
  <0x0301d164 0x20>;
+   ngpios = <24>;
#gpio-cells = <2>;
gpio-controller;
interrupts = ;
@@ -245,6 +247,7 @@
gpio_asiu: gpio@180a5000 {
compatible = "brcm,cygnus-asiu-gpio";
reg = <0x180a5000 0x668>;
+   ngpios = <146>;
#gpio-cells = <2>;
gpio-controller;
 
-- 
1.9.1

--
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


[PATCH v2 4/7] pinctrl: Add new compatible string to GPIO controller driver

2015-11-18 Thread Pramod Kumar
This compatible string should be used for all new iproc based future
SoCs having the same GPIO controller hardware.

Signed-off-by: Pramod Kumar 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c 
b/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
index 498a58a..d0d788f 100644
--- a/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
+++ b/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
@@ -646,6 +646,7 @@ static const struct of_device_id cygnus_gpio_of_match[] = {
{ .compatible = "brcm,cygnus-ccm-gpio" },
{ .compatible = "brcm,cygnus-asiu-gpio" },
{ .compatible = "brcm,cygnus-crmu-gpio" },
+   { .compatible = "brcm,iproc-gpio" },
{ }
 };
 
-- 
1.9.1

--
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


[PATCH v2 3/7] pinctrl: use ngpios propety from DT

2015-11-18 Thread Pramod Kumar
Since identical hardware is used in several instances and every
instance will have different in-use pins. Hence extracting this
number from DT via "ngpios" property.

Signed-off-by: Pramod Kumar 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c | 45 +++
 1 file changed, 9 insertions(+), 36 deletions(-)

diff --git a/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c 
b/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
index 12a48f4..498a58a 100644
--- a/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
+++ b/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
@@ -642,35 +642,11 @@ static void cygnus_gpio_unregister_pinconf(struct 
cygnus_gpio *chip)
pinctrl_unregister(chip->pctl);
 }
 
-struct cygnus_gpio_data {
-   unsigned num_gpios;
-};
-
-static const struct cygnus_gpio_data cygnus_cmm_gpio_data = {
-   .num_gpios = 24,
-};
-
-static const struct cygnus_gpio_data cygnus_asiu_gpio_data = {
-   .num_gpios = 146,
-};
-
-static const struct cygnus_gpio_data cygnus_crmu_gpio_data = {
-   .num_gpios = 6,
-};
-
 static const struct of_device_id cygnus_gpio_of_match[] = {
-   {
-   .compatible = "brcm,cygnus-ccm-gpio",
-   .data = &cygnus_cmm_gpio_data,
-   },
-   {
-   .compatible = "brcm,cygnus-asiu-gpio",
-   .data = &cygnus_asiu_gpio_data,
-   },
-   {
-   .compatible = "brcm,cygnus-crmu-gpio",
-   .data = &cygnus_crmu_gpio_data,
-   }
+   { .compatible = "brcm,cygnus-ccm-gpio" },
+   { .compatible = "brcm,cygnus-asiu-gpio" },
+   { .compatible = "brcm,cygnus-crmu-gpio" },
+   { }
 };
 
 static int cygnus_gpio_probe(struct platform_device *pdev)
@@ -681,14 +657,6 @@ static int cygnus_gpio_probe(struct platform_device *pdev)
struct gpio_chip *gc;
u32 ngpios;
int irq, ret;
-   const struct of_device_id *match;
-   const struct cygnus_gpio_data *gpio_data;
-
-   match = of_match_device(cygnus_gpio_of_match, dev);
-   if (!match)
-   return -ENODEV;
-   gpio_data = match->data;
-   ngpios = gpio_data->num_gpios;
 
chip = devm_kzalloc(dev, sizeof(*chip), GFP_KERNEL);
if (!chip)
@@ -713,6 +681,11 @@ static int cygnus_gpio_probe(struct platform_device *pdev)
}
}
 
+   if (of_property_read_u32(dev->of_node, "ngpios", &ngpios)) {
+   dev_err(&pdev->dev, "missing ngpios DT property\n");
+   return -ENODEV;
+   }
+
spin_lock_init(&chip->lock);
 
gc = &chip->gc;
-- 
1.9.1

--
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


[PATCH v2 7/7] pinctrl: Rename gpio driver from cygnus to iproc

2015-11-18 Thread Pramod Kumar
Rename gpio driver file name from pinctrl-cygnus-gpio.c to
pinctrl-iproc-gpio.c to make it more generic so that all
iproc based future SoCs using the same gpio block could
use this driver.

Signed-off-by: Pramod Kumar 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
Acked-by: Rob Herring 
---
 drivers/pinctrl/bcm/Kconfig| 30 --
 drivers/pinctrl/bcm/Makefile   |  2 +-
 ...{pinctrl-cygnus-gpio.c => pinctrl-iproc-gpio.c} |  3 +--
 3 files changed, 24 insertions(+), 11 deletions(-)
 rename drivers/pinctrl/bcm/{pinctrl-cygnus-gpio.c => pinctrl-iproc-gpio.c} 
(99%)

diff --git a/drivers/pinctrl/bcm/Kconfig b/drivers/pinctrl/bcm/Kconfig
index cd11d4d..5949547 100644
--- a/drivers/pinctrl/bcm/Kconfig
+++ b/drivers/pinctrl/bcm/Kconfig
@@ -20,27 +20,41 @@ config PINCTRL_BCM2835
select PINMUX
select PINCONF
 
-config PINCTRL_CYGNUS_GPIO
-   bool "Broadcom Cygnus GPIO (with PINCONF) driver"
-   depends on OF_GPIO && ARCH_BCM_CYGNUS
+config PINCTRL_IPROC_GPIO
+   bool "Broadcom iProc GPIO (with PINCONF) driver"
+   depends on OF_GPIO && (ARCH_BCM_IPROC || COMPILE_TEST)
select GPIOLIB_IRQCHIP
select PINCONF
select GENERIC_PINCONF
-   default ARCH_BCM_CYGNUS
+   default ARCH_BCM_IPROC
help
- Say yes here to enable the Broadcom Cygnus GPIO driver.
+ Say yes here to enable the Broadcom iProc GPIO driver.
+
+ The Broadcom iProc based SoCs- Cygnus, NS2, NSP and Stingray, use
+ same GPIO Controller IP hence this driver could be used for all.
 
  The Broadcom Cygnus SoC has 3 GPIO controllers including the ASIU
  GPIO controller (ASIU), the chipCommonG GPIO controller (CCM), and
  the always-ON GPIO controller (CRMU/AON). All 3 GPIO controllers are
  supported by this driver.
 
- All 3 Cygnus GPIO controllers support basic PINCONF functions such
+ The Broadcom NSP has two GPIO controllers including the ChipcommonA
+ GPIO, the ChipcommonB GPIO. Later controller is supported by this
+ driver.
+
+ The Broadcom NS2 has two GPIO controller including the CRMU GPIO,
+ the ChipcommonG GPIO. Both controllers are supported by this driver.
+
+ The Broadcom Stingray GPIO controllers are supported by this driver.
+
+ All above SoCs GPIO controllers support basic PINCONF functions such
  as bias pull up, pull down, and drive strength configurations, when
  these pins are muxed to GPIO.
 
- Pins from the ASIU GPIO can be individually muxed to GPIO function,
- through interaction with the Cygnus IOMUX controller.
+ It provides the framework where pins from the individual GPIO can be
+ individually muxed to GPIO function, through interaction with the
+ SoCs IOMUX controller. This features could be used only on SoCs which
+ support individual pin muxing.
 
 config PINCTRL_CYGNUS_MUX
bool "Broadcom Cygnus IOMUX driver"
diff --git a/drivers/pinctrl/bcm/Makefile b/drivers/pinctrl/bcm/Makefile
index 2b2f70e..9ac6370 100644
--- a/drivers/pinctrl/bcm/Makefile
+++ b/drivers/pinctrl/bcm/Makefile
@@ -2,5 +2,5 @@
 
 obj-$(CONFIG_PINCTRL_BCM281XX) += pinctrl-bcm281xx.o
 obj-$(CONFIG_PINCTRL_BCM2835)  += pinctrl-bcm2835.o
-obj-$(CONFIG_PINCTRL_CYGNUS_GPIO)  += pinctrl-cygnus-gpio.o
+obj-$(CONFIG_PINCTRL_IPROC_GPIO)   += pinctrl-iproc-gpio.o
 obj-$(CONFIG_PINCTRL_CYGNUS_MUX)   += pinctrl-cygnus-mux.o
diff --git a/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c 
b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
similarity index 99%
rename from drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
rename to drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
index ed21ab2..de09859 100644
--- a/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
+++ b/drivers/pinctrl/bcm/pinctrl-iproc-gpio.c
@@ -531,8 +531,7 @@ static int iproc_pin_config_get(struct pinctrl_dev 
*pctldev, unsigned pin,
ret = iproc_gpio_get_strength(chip, gpio, &arg);
if (ret)
return ret;
-   else
-   *config = pinconf_to_config_packed(param, arg);
+   *config = pinconf_to_config_packed(param, arg);
 
return 0;
 
-- 
1.9.1

--
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


[PATCH v2 6/7] Documentation: Rename gpio controller name from cygnus to iproc

2015-11-18 Thread Pramod Kumar
Renamed gpio controller's driver name from cygnus to iproc to make it
more generic so that all iProc based SoCs having the same gpio controller
could use this.

Signed-off-by: Pramod Kumar 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../bindings/pinctrl/{brcm,cygnus-gpio.txt => brcm,iproc-gpio.txt}| 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename Documentation/devicetree/bindings/pinctrl/{brcm,cygnus-gpio.txt => 
brcm,iproc-gpio.txt} (97%)

diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt 
b/Documentation/devicetree/bindings/pinctrl/brcm,iproc-gpio.txt
similarity index 97%
rename from Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt
rename to Documentation/devicetree/bindings/pinctrl/brcm,iproc-gpio.txt
index 8b1e5d1..e427792 100644
--- a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,iproc-gpio.txt
@@ -1,4 +1,4 @@
-Broadcom Cygnus GPIO/PINCONF Controller
+Broadcom iProc GPIO/PINCONF Controller
 
 Required properties:
 
@@ -7,7 +7,7 @@ Required properties:
 "brcm,cygnus-crmu-gpio" or "brcm,iproc-gpio"
 
 - reg:
-Define the base and range of the I/O address space that contains the Cygnus
+Define the base and range of the I/O address space that contains SoC
 GPIO/PINCONF controller registers
 
 - ngpios:
-- 
1.9.1

--
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


[PATCH v2 0/7] Generalized broadcom cygnus gpio driver

2015-11-18 Thread Pramod Kumar
Generalized pinctrl-cygnus-gpio driver so that it could be used for all
iProc architecture based future SoCs having same gpio pin controller.
Generalization process made the below changes in driver-

1. Addressed number of pins from DT through "ngpios" property and removed
from driver.
2. Since all iProc based SoCs would use this driver hence renamed all
variables/macros/functions and even file name on iproc.


This patchset applies on v4.4-rc1 and is tested on cygnus SVK and could be
find at-
https://github.com/Broadcom/arm64-linux/tree/iproc-gpio-v2

Changes from v1:
-Rebased patches to v4.4-rc1
-Removed accepted patches

Pramod Kumar (7):
  dt-binding: Add ngpios property to GPIO controller node
  dts: define ngpios property in gpio controller's node
  pinctrl: use ngpios propety from DT
  pinctrl: Add new compatible string to GPIO controller driver
  gpio: Rename func/macro/var to IP-block,iproc
  Documentation: Rename gpio controller name from cygnus to iproc
  pinctrl: Rename gpio driver from cygnus to iproc

 .../{brcm,cygnus-gpio.txt => brcm,iproc-gpio.txt}  |   9 +-
 arch/arm/boot/dts/bcm-cygnus.dtsi  |   3 +
 drivers/pinctrl/bcm/Kconfig|  30 +-
 drivers/pinctrl/bcm/Makefile   |   2 +-
 ...{pinctrl-cygnus-gpio.c => pinctrl-iproc-gpio.c} | 355 ++---
 5 files changed, 198 insertions(+), 201 deletions(-)
 rename Documentation/devicetree/bindings/pinctrl/{brcm,cygnus-gpio.txt => 
brcm,iproc-gpio.txt} (94%)
 rename drivers/pinctrl/bcm/{pinctrl-cygnus-gpio.c => pinctrl-iproc-gpio.c} 
(56%)

-- 
1.9.1

--
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


Re: [PATCH] thermal: Add support for Sunxi THS on the Allwinner H3

2015-11-18 Thread Chen-Yu Tsai
On Thu, Nov 19, 2015 at 4:51 AM, Josef Gajdusek  wrote:
> This patch adds support for the Sunxi thermal sensor on the Allwinner H3.
> Also adds declaration of the H3 THS clock to clk-sunxi.c ignoring the
> dividers as they are not continuous (clk-divider.c cannot be used as it
> does not support setting an enable bit).

That is not right. See below.

> Should be easily extendable for the A33/A83T/... as they have similar but
> not completely identical sensors.
>
> Signed-off-by: Josef Gajdusek 
> ---
>  Documentation/devicetree/bindings/clock/sunxi.txt  |   1 +
>  .../devicetree/bindings/thermal/sunxi-ths.txt  |  24 ++
>  arch/arm/boot/dts/sun8i-h3.dtsi|  27 +++
>  drivers/clk/sunxi/clk-sunxi.c  |  16 ++
>  drivers/thermal/Kconfig|   7 +
>  drivers/thermal/Makefile   |   1 +
>  drivers/thermal/sunxi_ths.c| 263 
> +

Thanks for working on this.

This patch should be split into 5 patches: clock binding, clock driver,
THS binding, THS driver, and DTS updates.

>  7 files changed, 339 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/thermal/sunxi-ths.txt
>  create mode 100644 drivers/thermal/sunxi_ths.c
>
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt 
> b/Documentation/devicetree/bindings/clock/sunxi.txt
> index 23e7bce..6d63b35 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -73,6 +73,7 @@ Required properties:
> "allwinner,sun8i-h3-usb-clk" - for usb gates + resets on H3
> "allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80
> "allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
> +   "allwinner,sun8i-h3-ths-clk" - for THS on H3
>
>  Required properties for all clocks:
>  - reg : shall be the control register address for the clock.
> diff --git a/Documentation/devicetree/bindings/thermal/sunxi-ths.txt 
> b/Documentation/devicetree/bindings/thermal/sunxi-ths.txt
> new file mode 100644
> index 000..75c9211
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/sunxi-ths.txt
> @@ -0,0 +1,24 @@
> +* sunxi THS
> +
> +Required properties:
> +- compatible : "allwinner,sun8i-h3-ths"
> +- reg : Address range of the thermal registers and location of the 
> calibration
> +value

The latter is part of the Security ID (efuses) block, for which we have
Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt.
Please use a phandle to the security id block instead.

See Documentation/devicetree/bindings/nvmem/nvmem.txt for the generic
nvmem bindings.

> +- resets : Must contain an entry for each entry in reset-names.
> +   see ../reset/reset.txt for details
> +- reset-names : Must include the name "ahb"
> +- clocks : Must contain an entry for each entry in clock-names.
> +- clock-names : Must contain "ahb" for the bus gate and "ths" for the THS
> +  clock
> +
> +Example:
> +ths: ths@01c25000 {
> +   #thermal-sensor-cells = <0>;
> +   compatible = "allwinner,sun8i-h3-ths";
> +   reg = <0x01c25000 0x88>, <0x01c14234 0x4>;
> +   interrupts = ;
> +   resets = <&bus_rst 136>;
> +   reset-names = "ahb";
> +   clocks = <&bus_gates 72>, <&ths_clk>;
> +   clock-names = "ahb", "ths";
> +};
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> index 0faa38a..b82881d 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -77,6 +77,14 @@
> };
> };
>
> +   thermal-zones {
> +   cpu_thermal: cpu_thermal {
> +   polling-delay-passive = <1000>;
> +   polling-delay = <5000>;
> +   thermal-sensors = <&ths 0>;
> +   };
> +   };
> +
> timer {
> compatible = "arm,armv7-timer";
> interrupts =  IRQ_TYPE_LEVEL_LOW)>,
> @@ -236,6 +244,14 @@
> "ahb1_ephy", "ahb1_dbg";
> };
>
> +   ths_clk: clk@01c20074 {
> +   #clock-cells = <0>;
> +   compatible = "allwinner,sun8i-h3-ths-clk";
> +   reg = <0x01c20074 0x4>;
> +   clocks = <&osc24M>;
> +   clock-output-names = "ths";
> +   };
> +
> mmc0_clk: clk@01c20088 {
> #clock-cells = <1>;
> compatible = "allwinner,sun4i-a10-mmc-clk";
> @@ -522,6 +538,17 @@
> interrupts = ;
> };
>
> +   ths: ths@01c25000 {
> +   #thermal-sensor-cells = <0>;
> +   compatible = "allwinner,sun8i-h3-ths";
> +   reg = <0x01c25000 0x88>, <0x01c14234 0x4>;
> +   interrup

[PATCH v3 12/12] ARM: dts: rockchip: add support mipi panel tv080wum-nl0 for rk3288-evb

2015-11-18 Thread Chris Zhong
This tv080wum-nl0 panel is a mipi panel, it can use in MIPI_TX socket
of rk3288 evb board.

Signed-off-by: Chris Zhong 

---

Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/rk3288-evb.dtsi | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi 
b/arch/arm/boot/dts/rk3288-evb.dtsi
index f6d2e78..d04878f 100644
--- a/arch/arm/boot/dts/rk3288-evb.dtsi
+++ b/arch/arm/boot/dts/rk3288-evb.dtsi
@@ -47,7 +47,7 @@
reg = <0x0 0x8000>;
};
 
-   backlight {
+   backlight: backlight {
compatible = "pwm-backlight";
brightness-levels = <
  0   1   2   3   4   5   6   7
@@ -177,6 +177,21 @@
status = "okay";
 };
 
+&mipi_dsi {
+   status = "okay";
+
+   panel {
+   compatible ="boe,tv080wum-nl0";
+   reg = <0>;
+
+   enable-gpios = <&gpio7 3 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&lcd_en>;
+   backlight = <&backlight>;
+   status = "okay";
+   };
+};
+
 &sdmmc {
bus-width = <4>;
cap-mmc-highspeed;
@@ -247,6 +262,9 @@
bl_en: bl-en {
rockchip,pins = <7 2 RK_FUNC_GPIO &pcfg_pull_none>;
};
+   lcd_en: lcd-en {
+   rockchip,pins = <7 3 RK_FUNC_GPIO &pcfg_pull_none>;
+   };
};
 
buttons {
-- 
2.6.3

--
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


[PATCH v3 09/12] ARM: dts: rockchip: add rk3288 mipi_dsi nodes

2015-11-18 Thread Chris Zhong
Add a mipi_dsi node, and also add mipi_dsi endpoints to vopb and vopl
output port nodes.

Signed-off-by: Chris Zhong 
---

Changes in v3: None
Changes in v2: None

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

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 6a79c9c..a5c5670 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -798,6 +798,10 @@
reg = <0>;
remote-endpoint = <&hdmi_in_vopb>;
};
+   vopb_out_mipi: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <&mipi_in_vopb>;
+   };
};
};
 
@@ -831,6 +835,10 @@
reg = <0>;
remote-endpoint = <&hdmi_in_vopl>;
};
+   vopl_out_mipi: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <&mipi_in_vopl>;
+   };
};
};
 
@@ -871,6 +879,37 @@
};
};
 
+   mipi_dsi: mipi@ff96 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi";
+   reg = <0xff96 0x4000>;
+   interrupts = ;
+   clocks = <&cru SCLK_MIPI_24M>, <&cru PCLK_MIPI_DSI0>;
+   clock-names = "ref", "pclk";
+   rockchip,grf = <&grf>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   mipi_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   mipi_in_vopb: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <&vopb_out_mipi>;
+   };
+   mipi_in_vopl: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <&vopl_out_mipi>;
+   };
+   };
+   };
+   };
+
gic: interrupt-controller@ffc01000 {
compatible = "arm,gic-400";
interrupt-controller;
-- 
2.6.3

--
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


[PATCH v3 11/12] drm/panel: simple: Add boe,tv080wum-nl0 simple panel device tree binding

2015-11-18 Thread Chris Zhong
This binding specifies a set of common properties for display panels. It
can be used as a basis by bindings for specific panels.
Bindings for three specific panels are provided to show how the
simple panel binding can be used.

Signed-off-by: Chris Zhong 

---

Changes in v3:
move boe,tv080wum-nl0.txt to bindings/display/panel/

Changes in v2:
As Thierry.Reding comment, add a documentation for this panel.

 .../devicetree/bindings/display/panel/boe,tv080wum-nl0.txt | 7 +++
 1 file changed, 7 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/boe,tv080wum-nl0.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/boe,tv080wum-nl0.txt 
b/Documentation/devicetree/bindings/display/panel/boe,tv080wum-nl0.txt
new file mode 100644
index 000..50be5e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/boe,tv080wum-nl0.txt
@@ -0,0 +1,7 @@
+Boe Corporation 8.0" WUXGA TFT LCD panel
+
+Required properties:
+- compatible: should be "boe,tv080wum-nl0"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
-- 
2.6.3

--
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


[PATCH v3 08/12] Documentation: dt-bindings: Add bindings for rk3288 DW MIPI DSI driver

2015-11-18 Thread Chris Zhong
add device tree bindings for rk3288 specific Synopsys DW MIPI DSI driver

Signed-off-by: Chris Zhong 

---

Changes in v3:
move dw_mipi_dsi_rockchip.txt to bindings/display/rockchip/

Changes in v2: None

 .../display/rockchip/dw_mipi_dsi_rockchip.txt  | 56 ++
 1 file changed, 56 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
new file mode 100644
index 000..acd9ec9
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
@@ -0,0 +1,56 @@
+Rockchip specific extensions to the Synopsys Designware MIPI DSI
+
+
+Required properties:
+- compatible: "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi".
+- rockchip,grf: this soc should set GRF regs to mux vopl/vopb.
+- ports: contain a port node with endpoint definitions as defined in [1].
+  For vopb,set the reg = <0> and set the reg = <1> for vopl.
+
+For more required properties, please refer to [2].
+
+[1] Documentation/devicetree/bindings/media/video-interfaces.txt
+[2] Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt
+
+Example:
+   mipi_dsi: mipi@ff96 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi";
+   reg = <0xff96 0x4000>;
+   interrupts = ;
+   clocks = <&cru SCLK_MIPI_24M>, <&cru PCLK_MIPI_DSI0>;
+   clock-names = "ref", "pclk";
+   rockchip,grf = <&grf>;
+   status = "okay";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   mipi_in: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   mipi_in_vopb: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <&vopb_out_mipi>;
+   };
+   mipi_in_vopl: endpoint@1 {
+   reg = <1>;
+   remote-endpoint = <&vopl_out_mipi>;
+   };
+   };
+   };
+
+   panel {
+   compatible ="boe,tv080wum-nl0";
+   reg = <0>;
+
+   enable-gpios = <&gpio7 3 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&lcd_en>;
+   backlight = <&backlight>;
+   status = "okay";
+   };
+   };
-- 
2.6.3

--
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


[PATCH v3 05/12] Documentation: dt-bindings: Add bindings for Synopsys DW MIPI DSI DRM bridge driver

2015-11-18 Thread Chris Zhong
From: Liu Ying 

This patch adds device tree bindings for Synopsys DesignWare MIPI DSI
host controller DRM bridge driver.

Signed-off-by: Liu Ying 
Signed-off-by: Chris Zhong 

---

Changes in v3:
move the dw_mipi_dsi.txt to Documentation/devicetree/bindings/display/bridge

Changes in v2: None

 .../bindings/display/bridge/dw_mipi_dsi.txt| 76 ++
 1 file changed, 76 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt 
b/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt
new file mode 100644
index 000..0e5c140
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt
@@ -0,0 +1,76 @@
+Device-Tree bindings for Synopsys DesignWare MIPI DSI host controller
+
+The controller is a digital core that implements all protocol functions
+defined in the MIPI DSI specification, providing an interface between
+the system and the MIPI DPHY, and allowing communication with a MIPI DSI
+compliant display.
+
+Required properties:
+ - #address-cells: Should be <1>.
+ - #size-cells: Should be <0>.
+ - compatible: The first compatible string should be "fsl,imx6q-mipi-dsi"
+   for i.MX6q/sdl SoCs.  For other SoCs, please refer to their specific
+   device tree binding documentations.  A common compatible string
+   "snps,dw-mipi-dsi" should be appended for all SoCs.
+ - reg: Represent the physical address range of the controller.
+ - interrupts: Represent the controller's interrupt to the CPU(s).
+ - clocks, clock-names: Phandles to the controller's pll reference
+   clock(ref), configuration clock(cfg) and APB clock(pclk), as
+   described in [1].
+
+For more required properties, please refer to relevant device tree binding
+documentations which describe the controller embedded in specific SoCs.
+
+Required sub-nodes:
+ - A node to represent a DSI peripheral as described in [2].
+
+For more required sub-nodes, please refer to relevant device tree binding
+documentations which describe the controller embedded in specific SoCs.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
+
+example:
+   gpr: iomuxc-gpr@020e {
+   /* ... */
+   };
+
+   mipi_dsi: mipi@021e {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   compatible = "fsl,imx6q-mipi-dsi", "snps,dw-mipi-dsi";
+   reg = <0x021e 0x4000>;
+   interrupts = <0 102 IRQ_TYPE_LEVEL_HIGH>;
+   gpr = <&gpr>;
+   clocks = <&clks IMX6QDL_CLK_MIPI_CORE_CFG>,
+<&clks IMX6QDL_CLK_MIPI_CORE_CFG>,
+<&clks IMX6QDL_CLK_MIPI_IPG>;
+   clock-names = "ref", "cfg", "pclk";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   mipi_mux_0: endpoint {
+   remote-endpoint = <&ipu1_di0_mipi>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   mipi_mux_1: endpoint {
+   remote-endpoint = <&ipu1_di1_mipi>;
+   };
+   };
+   };
+
+   panel {
+   compatible = "truly,tft480800-16-e-dsi";
+   reg = <0>;
+   /* ... */
+   };
+   };
-- 
2.6.3

--
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


Re: [PATCH v12 1/3] dt-bindings: Add a binding for Mediatek xHCI host controller

2015-11-18 Thread chunfeng yun
Hi,
On Tue, 2015-11-17 at 13:58 +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 11/17/2015 12:18 PM, Chunfeng Yun wrote:
> 
> > add a DT binding documentation of xHCI host controller for the
> > MT8173 SoC from Mediatek.
> >
> > Signed-off-by: Chunfeng Yun 
> > ---
> >   .../devicetree/bindings/usb/mt8173-xhci.txt| 51 
> > ++
> >   1 file changed, 51 insertions(+)
> >   create mode 100644 Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> >
> > diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt 
> > b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> > new file mode 100644
> > index 000..a78f20b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
> > @@ -0,0 +1,51 @@
> > +MT8173 xHCI
> > +
> > +The device node for Mediatek SOC USB3.0 host controller
> > +
> > +Required properties:
> > + - compatible : should contain "mediatek,mt8173-xhci"
> > + - reg : specifies physical base address and size of the registers,
> > +   the first one for MAC, the second for IPPC
> > + - interrupts : interrupt used by the controller
> > + - power-domains : a phandle to USB power domain node to control USB's
> > +   mtcmos
> 
> What's that?
It works as a gateway in fact which can turn on/off usb power
> 
> > + - vusb33-supply : regulator of USB avdd3.3v
> > +
> > + - clocks : a list of phandle + clock-specifier pairs, one for each
> > +   entry in clock-names
> > + - clock-names : must contain
> > +   "sys_ck": for clock of xHCI MAC
> > +   "wakeup_deb_p0": for USB wakeup debounce clock of port0
> > +   "wakeup_deb_p0": for USB wakeup debounce clock of port1
> 
> "wakeup_deb_p1"?
Yes, it's a typo
> 
> > +
> > + - phys : a list of phandle + phy specifier pairs
> > +
> > +Optional properties:
> > + - mediatek,wakeup-src : 1: ip sleep wakeup mode; 2: line state wakeup
> ^^ IP?
Ok
> 
> > +   mode;
> > + - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup
> > +   control register, it depends on "mediatek,wakeup-src".
> > + - vbus-supply : reference to the VBUS regulator;
> > + - usb3-lpm-capable : supports USB3.0 LPM
> 
> [...]
> 
> MBR, Sergei
> 


--
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


[PATCH v3 00/12] Add mipi dsi support for rk3288

2015-11-18 Thread Chris Zhong
The rk3288 MIPI DSI is a Synopsys DesignWare MIPI DSI host controller
IP. This series adds support for a Synopsys DesignWare MIPI DSI host
controller DRM bridge driver and a rockchip MIPI DSI specific DRM
driver.

This series also includes a DRM panel driver for BOE TV080WUM-NL0 panel.
This panel only use the MIPI DSI video mode.

The MIPI DSI feature is tested on rk3288 evb board, backport them to
chrome os kernel v3.14, and it can display normally.

This patchset is base on the patchset from ying@freescale.com.



Changes in v3:
move the dw_mipi_dsi.txt to Documentation/devicetree/bindings/display/bridge
move dw_mipi_dsi_rockchip.txt to bindings/display/rockchip/
move boe,tv080wum-nl0.txt to bindings/display/panel/

Changes in v2:
add the mipi clk id in a single patch
As Thierry.Reding comment, add a documentation for this panel.

Chris Zhong (10):
  clk: rockchip: add id for mipidsi sclk on rk3288
  clk: rockchip: add mipidsi clocks on rk3288
  drm/rockchip: return a true clock rate to adjusted_mode
  drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver
  drm: rockchip: Support Synopsys DesignWare MIPI DSI host controller
  Documentation: dt-bindings: Add bindings for rk3288 DW MIPI DSI driver
  ARM: dts: rockchip: add rk3288 mipi_dsi nodes
  drm/panel: simple: Add support for BOE TV080WUM-NL0
  drm/panel: simple: Add boe,tv080wum-nl0 simple panel device tree
binding
  ARM: dts: rockchip: add support mipi panel tv080wum-nl0 for rk3288-evb

Liu Ying (2):
  drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format
  Documentation: dt-bindings: Add bindings for Synopsys DW MIPI DSI DRM
bridge driver

 .../bindings/display/bridge/dw_mipi_dsi.txt|   76 ++
 .../bindings/display/panel/boe,tv080wum-nl0.txt|7 +
 .../display/rockchip/dw_mipi_dsi_rockchip.txt  |   56 ++
 arch/arm/boot/dts/rk3288-evb.dtsi  |   20 +-
 arch/arm/boot/dts/rk3288.dtsi  |   39 +
 drivers/clk/rockchip/clk-rk3288.c  |2 +-
 drivers/gpu/drm/bridge/Kconfig |   11 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/dw_mipi_dsi.c   | 1055 
 drivers/gpu/drm/panel/panel-simple.c   |   33 +
 drivers/gpu/drm/rockchip/Kconfig   |   10 +
 drivers/gpu/drm/rockchip/Makefile  |1 +
 drivers/gpu/drm/rockchip/dw_mipi_dsi_rockchip.c|  249 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c|9 +
 include/drm/bridge/dw_mipi_dsi.h   |   27 +
 include/drm/drm_mipi_dsi.h |   14 +
 include/dt-bindings/clock/rk3288-cru.h |1 +
 17 files changed, 1609 insertions(+), 2 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/dw_mipi_dsi.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/boe,tv080wum-nl0.txt
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
 create mode 100644 drivers/gpu/drm/bridge/dw_mipi_dsi.c
 create mode 100644 drivers/gpu/drm/rockchip/dw_mipi_dsi_rockchip.c
 create mode 100644 include/drm/bridge/dw_mipi_dsi.h

-- 
2.6.3

--
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


[PATCH v3 01/12] clk: rockchip: add id for mipidsi sclk on rk3288

2015-11-18 Thread Chris Zhong
Adds a new id for the sclk supplying the mipidsi on rk3288 socs.

Signed-off-by: Chris Zhong 

---

Changes in v3: None
Changes in v2:
add the mipi clk id in a single patch

 include/dt-bindings/clock/rk3288-cru.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/dt-bindings/clock/rk3288-cru.h 
b/include/dt-bindings/clock/rk3288-cru.h
index c719aac..b07cdd3 100644
--- a/include/dt-bindings/clock/rk3288-cru.h
+++ b/include/dt-bindings/clock/rk3288-cru.h
@@ -86,6 +86,7 @@
 #define SCLK_USBPHY480M_SRC122
 #define SCLK_PVTM_CORE 123
 #define SCLK_PVTM_GPU  124
+#define SCLK_MIPI_24M  125
 
 #define SCLK_MAC   151
 #define SCLK_MACREF_OUT152
-- 
2.6.3

--
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


RE: [PATCH 03/11] dts: pinctrl: Add GPIO to Pinctrl pin mapping in DT

2015-11-18 Thread Pramod Kumar
Hi Florian,

> -Original Message-
> From: Florian Fainelli [mailto:f.faine...@gmail.com]
> Sent: 19 November 2015 00:10
> To: Pramod Kumar; Rob Herring; Pawel Moll; Mark Rutland; Ian Campbell;
> Kumar Gala; Ray Jui; Scott Branden; Russell King; Linus Walleij; linux-
> g...@vger.kernel.org
> Cc: bcm-kernel-feedback-list; Jason Uy; Masahiro Yamada; Thomas Gleixner;
> Laurent Pinchart; devicetree@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-ker...@vger.kernel.org; Jonas Gorski
> Subject: Re: [PATCH 03/11] dts: pinctrl: Add GPIO to Pinctrl pin mapping in DT
> 
> On 18/10/15 22:43, Pramod Kumar wrote:
> > ASIU gpio controller's pins are muxed with pin-cntroller.
> > Add this mapping through property "gpio-ranges".
> >
> > Signed-off-by: Pramod Kumar 
> > Reviewed-by: Ray Jui 
> > Reviewed-by: Scott Branden 
> 
> Applied to devicetree/next, since there was a bit of restructuring, I had to
> manually apply it, please verify the resolution looks correct to you.

Applied patch looks fine. Thanks for having time in restructuring. 

Regards,
Pramod

> 
> Thanks!
> --
> Florian


[PATCH v2 0/5] Devicetree support for misc/eeprom/eeprom_93xx46.

2015-11-18 Thread Cory Tusar
This series of patches adds an initial set of devicetree bindings to the
eeprom_93xx46 driver which mirror the configuration options previously
available as a platform device.  These bindings are then extended to
include support for specific Atmel devices in this family and also to
support GPIO-based selection of the device (e.g. for use with an SPI bus
mux).

Additionally, an address aliasing issue with 16-bit read and write
accesses in the eeprom_93xx46 driver discovered during testing is fixed.

Changes since v1:
  - Consolidated all Documentation/devictree additions into a single patch.
  - Clarified compatible string shall be only one of the supported values.
  - Renamed the 'select-gpio' binding to 'select-gpios'.

Cory Tusar (5):
  misc: eeprom_93xx46: Fix 16-bit read and write accesses.
  Documentation: devicetree: Add DT bindings to eeprom_93xx46 driver.
  misc: eeprom_93xx46: Implement eeprom_93xx46 DT bindings.
  misc: eeprom_93xx46: Add quirks to support Atmel AT93C46D device.
  misc: eeprom_93xx46: Add support for a GPIO 'select' line.

 .../devicetree/bindings/misc/eeprom-93xx46.txt |  25 +++
 drivers/misc/eeprom/eeprom_93xx46.c| 216 +
 include/linux/eeprom_93xx46.h  |   7 +
 3 files changed, 212 insertions(+), 36 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/misc/eeprom-93xx46.txt

-- 
2.4.10

--
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


[PATCH v2 3/5] misc: eeprom_93xx46: Implement eeprom_93xx46 DT bindings.

2015-11-18 Thread Cory Tusar
This commit implements bindings in the eeprom_93xx46 driver allowing
device word size and read-only attributes to be specified via
devicetree.

Signed-off-by: Cory Tusar 
---
 drivers/misc/eeprom/eeprom_93xx46.c | 62 +
 1 file changed, 62 insertions(+)

diff --git a/drivers/misc/eeprom/eeprom_93xx46.c 
b/drivers/misc/eeprom/eeprom_93xx46.c
index e1bf0a5..1f29d9a 100644
--- a/drivers/misc/eeprom/eeprom_93xx46.c
+++ b/drivers/misc/eeprom/eeprom_93xx46.c
@@ -13,6 +13,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -294,12 +296,71 @@ static ssize_t eeprom_93xx46_store_erase(struct device 
*dev,
 }
 static DEVICE_ATTR(erase, S_IWUSR, NULL, eeprom_93xx46_store_erase);
 
+#ifdef CONFIG_OF
+static const struct of_device_id eeprom_93xx46_of_table[] = {
+   { .compatible = "eeprom-93xx46", },
+   {}
+};
+MODULE_DEVICE_TABLE(of, eeprom_93xx46_of_table);
+
+static int eeprom_93xx46_probe_dt(struct spi_device *spi)
+{
+   struct device_node *np = spi->dev.of_node;
+   struct eeprom_93xx46_platform_data *pd;
+   u32 tmp;
+   int ret;
+
+   if (!of_match_device(eeprom_93xx46_of_table, &spi->dev))
+   return 0;
+
+   pd = devm_kzalloc(&spi->dev, sizeof(*pd), GFP_KERNEL);
+   if (!pd)
+   return -ENOMEM;
+
+   ret = of_property_read_u32(np, "data-size", &tmp);
+   if (ret < 0) {
+   dev_err(&spi->dev, "data-size property not found\n");
+   goto error_free;
+   }
+
+   if (tmp == 8) {
+   pd->flags |= EE_ADDR8;
+   } else if (tmp == 16) {
+   pd->flags |= EE_ADDR16;
+   } else {
+   dev_err(&spi->dev, "invalid data-size (%d)\n", tmp);
+   goto error_free;
+   }
+
+   if (of_property_read_bool(np, "read-only"))
+   pd->flags |= EE_READONLY;
+
+   spi->dev.platform_data = pd;
+
+   return 1;
+
+error_free:
+   devm_kfree(&spi->dev, pd);
+   return ret;
+}
+
+#else
+static inline int eeprom_93xx46_probe_dt(struct spi_device *spi)
+{
+   return 0;
+}
+#endif
+
 static int eeprom_93xx46_probe(struct spi_device *spi)
 {
struct eeprom_93xx46_platform_data *pd;
struct eeprom_93xx46_dev *edev;
int err;
 
+   err = eeprom_93xx46_probe_dt(spi);
+   if (err < 0)
+   return err;
+
pd = spi->dev.platform_data;
if (!pd) {
dev_err(&spi->dev, "missing platform data\n");
@@ -370,6 +431,7 @@ static int eeprom_93xx46_remove(struct spi_device *spi)
 static struct spi_driver eeprom_93xx46_driver = {
.driver = {
.name   = "93xx46",
+   .of_match_table = eeprom_93xx46_of_table,
},
.probe  = eeprom_93xx46_probe,
.remove = eeprom_93xx46_remove,
-- 
2.4.10

--
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


[PATCH v2 1/5] misc: eeprom_93xx46: Fix 16-bit read and write accesses.

2015-11-18 Thread Cory Tusar
Compatible at93xx46 devices from both Microchip and Atmel expect a
word-based address, regardless of whether the device is strapped for 8-
or 16-bit operation.  However, the offset parameter passed in when
reading or writing at a specific location is always specified in terms
of bytes.

This commit fixes 16-bit read and write accesses by shifting the offset
parameter to account for this difference between a byte offset and a
word-based address.

Signed-off-by: Cory Tusar 
---
 drivers/misc/eeprom/eeprom_93xx46.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/eeprom/eeprom_93xx46.c 
b/drivers/misc/eeprom/eeprom_93xx46.c
index ff63f05..e1bf0a5 100644
--- a/drivers/misc/eeprom/eeprom_93xx46.c
+++ b/drivers/misc/eeprom/eeprom_93xx46.c
@@ -54,7 +54,7 @@ eeprom_93xx46_bin_read(struct file *filp, struct kobject 
*kobj,
cmd_addr |= off & 0x7f;
bits = 10;
} else {
-   cmd_addr |= off & 0x3f;
+   cmd_addr |= (off >> 1) & 0x3f;
bits = 9;
}
 
@@ -155,7 +155,7 @@ eeprom_93xx46_write_word(struct eeprom_93xx46_dev *edev,
bits = 10;
data_len = 1;
} else {
-   cmd_addr |= off & 0x3f;
+   cmd_addr |= (off >> 1) & 0x3f;
bits = 9;
data_len = 2;
}
-- 
2.4.10

--
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


[PATCH v2 4/5] misc: eeprom_93xx46: Add quirks to support Atmel AT93C46D device.

2015-11-18 Thread Cory Tusar
Atmel devices in this family have some quirks not found in other similar
chips - they do not support a sequential read of the entire EEPROM
contents, and the control word sent at the start of each operation
varies in bit length.

This commit adds quirk support to the driver and modifies the read
implementation to support non-sequential reads for consistency with
other misc/eeprom drivers.

Tested on a custom Freescale VF610-based platform, with an AT93C46D
device attached via dspi2.  The spi-gpio driver was used to allow the
necessary non-byte-sized transfers.

Signed-off-by: Cory Tusar 
---
 drivers/misc/eeprom/eeprom_93xx46.c | 128 ++--
 include/linux/eeprom_93xx46.h   |   6 ++
 2 files changed, 98 insertions(+), 36 deletions(-)

diff --git a/drivers/misc/eeprom/eeprom_93xx46.c 
b/drivers/misc/eeprom/eeprom_93xx46.c
index 1f29d9a..0386b03 100644
--- a/drivers/misc/eeprom/eeprom_93xx46.c
+++ b/drivers/misc/eeprom/eeprom_93xx46.c
@@ -27,6 +27,15 @@
 #define ADDR_ERAL  0x20
 #define ADDR_EWEN  0x30
 
+struct eeprom_93xx46_devtype_data {
+   unsigned int quirks;
+};
+
+static const struct eeprom_93xx46_devtype_data atmel_at93c46d_data = {
+   .quirks = EEPROM_93XX46_QUIRK_SINGLE_WORD_READ |
+ EEPROM_93XX46_QUIRK_INSTRUCTION_LENGTH,
+};
+
 struct eeprom_93xx46_dev {
struct spi_device *spi;
struct eeprom_93xx46_platform_data *pdata;
@@ -35,6 +44,16 @@ struct eeprom_93xx46_dev {
int addrlen;
 };
 
+static inline bool has_quirk_single_word_read(struct eeprom_93xx46_dev *edev)
+{
+   return !!(edev->pdata->quirks & EEPROM_93XX46_QUIRK_SINGLE_WORD_READ);
+}
+
+static inline bool has_quirk_instruction_length(struct eeprom_93xx46_dev *edev)
+{
+   return !!(edev->pdata->quirks & EEPROM_93XX46_QUIRK_INSTRUCTION_LENGTH);
+}
+
 static ssize_t
 eeprom_93xx46_bin_read(struct file *filp, struct kobject *kobj,
   struct bin_attribute *bin_attr,
@@ -42,58 +61,73 @@ eeprom_93xx46_bin_read(struct file *filp, struct kobject 
*kobj,
 {
struct eeprom_93xx46_dev *edev;
struct device *dev;
-   struct spi_message m;
-   struct spi_transfer t[2];
-   int bits, ret;
-   u16 cmd_addr;
+   ssize_t ret = 0;
 
dev = container_of(kobj, struct device, kobj);
edev = dev_get_drvdata(dev);
 
-   cmd_addr = OP_READ << edev->addrlen;
+   mutex_lock(&edev->lock);
 
-   if (edev->addrlen == 7) {
-   cmd_addr |= off & 0x7f;
-   bits = 10;
-   } else {
-   cmd_addr |= (off >> 1) & 0x3f;
-   bits = 9;
-   }
+   if (edev->pdata->prepare)
+   edev->pdata->prepare(edev);
 
-   dev_dbg(&edev->spi->dev, "read cmd 0x%x, %d Hz\n",
-   cmd_addr, edev->spi->max_speed_hz);
+   while (count) {
+   struct spi_message m;
+   struct spi_transfer t[2] = { { 0 } };
+   u16 cmd_addr = OP_READ << edev->addrlen;
+   size_t nbytes = count;
+   int bits;
+   int err;
+
+   if (edev->addrlen == 7) {
+   cmd_addr |= off & 0x7f;
+   bits = 10;
+   if (has_quirk_single_word_read(edev))
+   nbytes = 1;
+   } else {
+   cmd_addr |= (off >> 1) & 0x3f;
+   bits = 9;
+   if (has_quirk_single_word_read(edev))
+   nbytes = 2;
+   }
 
-   spi_message_init(&m);
-   memset(t, 0, sizeof(t));
+   dev_dbg(&edev->spi->dev, "read cmd 0x%x, %d Hz\n",
+   cmd_addr, edev->spi->max_speed_hz);
 
-   t[0].tx_buf = (char *)&cmd_addr;
-   t[0].len = 2;
-   t[0].bits_per_word = bits;
-   spi_message_add_tail(&t[0], &m);
+   spi_message_init(&m);
 
-   t[1].rx_buf = buf;
-   t[1].len = count;
-   t[1].bits_per_word = 8;
-   spi_message_add_tail(&t[1], &m);
+   t[0].tx_buf = (char *)&cmd_addr;
+   t[0].len = 2;
+   t[0].bits_per_word = bits;
+   spi_message_add_tail(&t[0], &m);
 
-   mutex_lock(&edev->lock);
+   t[1].rx_buf = buf;
+   t[1].len = count;
+   t[1].bits_per_word = 8;
+   spi_message_add_tail(&t[1], &m);
 
-   if (edev->pdata->prepare)
-   edev->pdata->prepare(edev);
+   err = spi_sync(edev->spi, &m);
+   /* have to wait at least Tcsl ns */
+   ndelay(250);
 
-   ret = spi_sync(edev->spi, &m);
-   /* have to wait at least Tcsl ns */
-   ndelay(250);
-   if (ret) {
-   dev_err(&edev->spi->dev, "read %zu bytes at %d: err. %d\n",
-   count, (int)off, ret);
+   if (err) {
+   dev_err(&edev->spi->dev, "read %zu bytes at %d: err. 
%d\

[PATCH v2 2/5] Documentation: devicetree: Add DT bindings to eeprom_93xx46 driver.

2015-11-18 Thread Cory Tusar
This commit documents bindings to be added to the eeprom_93xx46 driver
which will allow:

  - Device word size and read-only attributes to be specified.
  - A device-specific compatible string for use with Atmel AT93C46D
EEPROMs.
  - Specifying a GPIO line to function as a 'select' or 'enable' signal
prior to accessing the EEPROM.

Signed-off-by: Cory Tusar 
---
 .../devicetree/bindings/misc/eeprom-93xx46.txt | 25 ++
 1 file changed, 25 insertions(+)

diff --git a/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt 
b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
new file mode 100644
index 000..8e116a1
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt
@@ -0,0 +1,25 @@
+EEPROMs (SPI) compatible with Microchip Technology 93xx46 family.
+
+Required properties:
+- compatible : shall be one of:
+"atmel,at93c46d"
+"eeprom-93xx46"
+- data-size : number of data bits per word (either 8 or 16)
+
+Optional properties:
+- read-only : parameter-less property which disables writes to the EEPROM
+- select-gpios : if present, specifies the GPIO that will be asserted prior to
+  each access to the EEPROM (e.g. for SPI bus multiplexing)
+
+Property rules described in Documentation/devicetree/bindings/spi/spi-bus.txt
+apply.  In particular, "reg" and "spi-max-frequency" properties must be given.
+
+Example:
+   93c46c@0 {
+   compatible = "eeprom-93xx46";
+   reg = <0>;
+   spi-max-frequency = <100>;
+   spi-cs-high;
+   data-size = <8>;
+   select-gpios = <&gpio4 4 GPIO_ACTIVE_HIGH>;
+   };
-- 
2.4.10

--
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


[PATCH v2 5/5] misc: eeprom_93xx46: Add support for a GPIO 'select' line.

2015-11-18 Thread Cory Tusar
This commit adds support to the eeprom_93x46 driver allowing a GPIO line
to function as a 'select' or 'enable' signal prior to accessing the
EEPROM.

Signed-off-by: Cory Tusar 
---
 drivers/misc/eeprom/eeprom_93xx46.c | 26 ++
 include/linux/eeprom_93xx46.h   |  1 +
 2 files changed, 27 insertions(+)

diff --git a/drivers/misc/eeprom/eeprom_93xx46.c 
b/drivers/misc/eeprom/eeprom_93xx46.c
index 0386b03..375951f 100644
--- a/drivers/misc/eeprom/eeprom_93xx46.c
+++ b/drivers/misc/eeprom/eeprom_93xx46.c
@@ -10,11 +10,14 @@
 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -344,6 +347,20 @@ static ssize_t eeprom_93xx46_store_erase(struct device 
*dev,
 static DEVICE_ATTR(erase, S_IWUSR, NULL, eeprom_93xx46_store_erase);
 
 #ifdef CONFIG_OF
+static void select_assert(void *context)
+{
+   struct eeprom_93xx46_dev *edev = context;
+
+   gpiod_set_value_cansleep(gpio_to_desc(edev->pdata->select_gpio), 1);
+}
+
+static void select_deassert(void *context)
+{
+   struct eeprom_93xx46_dev *edev = context;
+
+   gpiod_set_value_cansleep(gpio_to_desc(edev->pdata->select_gpio), 0);
+}
+
 static const struct of_device_id eeprom_93xx46_of_table[] = {
{ .compatible = "eeprom-93xx46", },
{ .compatible = "atmel,at93c46d", .data = &atmel_at93c46d_data, },
@@ -385,6 +402,15 @@ static int eeprom_93xx46_probe_dt(struct spi_device *spi)
if (of_property_read_bool(np, "read-only"))
pd->flags |= EE_READONLY;
 
+   ret = of_get_named_gpio(np, "select-gpios", 0);
+   if (ret < 0) {
+   pd->select_gpio = -1;
+   } else {
+   pd->select_gpio = ret;
+   pd->prepare = select_assert;
+   pd->finish = select_deassert;
+   }
+
if (of_id->data) {
const struct eeprom_93xx46_devtype_data *data = of_id->data;
 
diff --git a/include/linux/eeprom_93xx46.h b/include/linux/eeprom_93xx46.h
index 92fa4c3..aa472c7 100644
--- a/include/linux/eeprom_93xx46.h
+++ b/include/linux/eeprom_93xx46.h
@@ -21,4 +21,5 @@ struct eeprom_93xx46_platform_data {
 */
void (*prepare)(void *);
void (*finish)(void *);
+   unsigned int select_gpio;
 };
-- 
2.4.10

--
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


Re: [linux-sunxi] [PATCH] thermal: Add support for Sunxi THS on the Allwinner H3

2015-11-18 Thread Siarhei Siamashka
Hello,

On Wed, 18 Nov 2015 21:51:48 +0100
Josef Gajdusek  wrote:

> This patch adds support for the Sunxi thermal sensor on the Allwinner H3.
> Also adds declaration of the H3 THS clock to clk-sunxi.c ignoring the
> dividers as they are not continuous (clk-divider.c cannot be used as it
> does not support setting an enable bit).
> Should be easily extendable for the A33/A83T/... as they have similar but
> not completely identical sensors.
> 
> Signed-off-by: Josef Gajdusek 

Thanks for working on this. The thermal sensor is very useful on
H3 because this SoC tends to be running rather hot at high clock
frequencies.

Do you also have plans for making use of an irq handler?

> ---
>  Documentation/devicetree/bindings/clock/sunxi.txt  |   1 +
>  .../devicetree/bindings/thermal/sunxi-ths.txt  |  24 ++
>  arch/arm/boot/dts/sun8i-h3.dtsi|  27 +++
>  drivers/clk/sunxi/clk-sunxi.c  |  16 ++
>  drivers/thermal/Kconfig|   7 +
>  drivers/thermal/Makefile   |   1 +
>  drivers/thermal/sunxi_ths.c| 263 
> +
>  7 files changed, 339 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/thermal/sunxi-ths.txt
>  create mode 100644 drivers/thermal/sunxi_ths.c

[...]

> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -604,6 +604,13 @@ static void sun7i_a20_get_out_factors(u32 *freq, u32 
> parent_rate,
>   *p = calcp;
>  }
>  
> +static void sun8i_h3_get_ths_factors(u32 *freq, u32 parent_rate,
> +   u8 *n, u8 *k, u8 *m, u8 *p)
> +{
> + /* Ignore the dividers as they are not continuous */
> + *freq = parent_rate;
> +}

Can you elaborate on this? What's wrong with the dividers? Which clock
frequency happens to be used for THS in the end?

> +static int sunxi_ths_h3_init(struct sunxi_ths_data *data)
> +{
> + if (data->calreg)
> + writel(readl(data->calreg) & 0xfff, data->regs + THS_H3_CDATA);
> + /* Magical constants mostly taken from Allwinner 3.4 kernel.
> +  * Seem to work fine, though this could be configurable in DT/sysft
> +  */
> + writel(0xff << THS_H3_CTRL0_SENSOR_ACQ0,
> + data->regs + THS_H3_CTRL0);
> + writel((0x3f << THS_H3_CTRL2_SENSOR_ACQ1) | BIT(THS_H3_CTRL2_SENSE_EN),
> + data->regs + THS_H3_CTRL2);
> + writel((0x390 << THS_H3_INT_CTRL_THERMAL_PER) | 
> BIT(THS_H3_INT_CTRL_DATA_IRQ_EN),
> + data->regs + THS_H3_INT_CTRL);
> + writel(BIT(THS_H3_FILTER_EN) | (0x2 << THS_H3_FILTER_TYPE),
> + data->regs + THS_H3_FILTER);
> + return 0;
> +}

The H3 manual has some nice description of these registers and explains
how these parameters should be calculated (they depend on the THS clock
frequency). No magic involved.

Currently the H3 manual is available from Orange Pi people and OLIMEX.
There is also an open request about releasing it "officially":
https://github.com/allwinner-zh/documents/issues/9

-- 
Best regards,
Siarhei Siamashka
--
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


Re: [PATCH v5 00/32] HiSilicon SAS driver

2015-11-18 Thread Martin K. Petersen
> "John" == John Garry  writes:

John> thanks, please note that we still have the dependency on
John> http://www.spinics.net/lists/arm-kernel/msg452833.html

John> Without it the driver can only be built into the kernel, and not
John> as a module.

I have your driver in a staging branch rather than the main 4.5 SCSI
queue because I wanted to see what kind of additional fallout I'd get
from the zeroday testing.

It's not a problem for me to wait for that patch to go in (or take it
through SCSI if that makes things easier).

-- 
Martin K. Petersen  Oracle Linux Engineering
--
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


Re: [RESEND RFC/PATCH 1/8] dt-bindings: Add a binding for Mediatek Video Processor Unit

2015-11-18 Thread andrew-ct chen
On Tue, 2015-11-17 at 14:13 +, Mark Rutland wrote:
> On Tue, Nov 17, 2015 at 08:54:38PM +0800, Tiffany Lin wrote:
> > From: Andrew-CT Chen 
> > 
> > Add a DT binding documentation of Video Processor Unit for the
> > MT8173 SoC from Mediatek.
> > 
> > Signed-off-by: Andrew-CT Chen 
> > ---
> >  .../devicetree/bindings/media/mediatek-vpu.txt |   27 
> > 
> >  1 file changed, 27 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/media/mediatek-vpu.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/media/mediatek-vpu.txt 
> > b/Documentation/devicetree/bindings/media/mediatek-vpu.txt
> > new file mode 100644
> > index 000..99a4e5e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/mediatek-vpu.txt
> > @@ -0,0 +1,27 @@
> > +* Mediatek Video Processor Unit
> > +
> > +Video Processor Unit is a HW video controller. It controls HW Codec 
> > including
> > +H.264/VP8/VP9 Decode, H.264/VP8 Encode and Image Processor 
> > (scale/rotate/color convert).
> > +
> > +Required properties:
> > +  - compatible: "mediatek,mt8173-vpu"
> > +  - reg: Must contain an entry for each entry in reg-names.
> > +  - reg-names: Must include the following entries:
> > +"sram": SRAM base
> > +"cfg_reg": Main configuration registers base
> > +  - interrupts: interrupt number to the cpu.
> > +  - clocks : clock name from clock manager
> > +  - clock-names: the clocks of the VPU H/W
> 
> You need to explicitly define the set of clock-names you expect here.
> 
> Mark.

Sorry, only one clock to enable VPU hardware.
We will modify to
- clocks : must contain one entry for each clock-names.
- clock-names : must be "main", It is the main clock of VPU.

Thanks..

> 
> > +  - iommus : phandle and IOMMU spcifier for the IOMMU that serves the VPU.
> > +
> > +Example:
> > +   vpu: vpu@1002 {
> > +   compatible = "mediatek,mt8173-vpu";
> > +   reg = <0 0x1002 0 0x3>,
> > + <0 0x1005 0 0x100>;
> > +   reg-names = "sram", "cfg_reg";
> > +   interrupts = ;
> > +   clocks = <&topckgen TOP_SCP_SEL>;
> > +   clock-names = "main";
> > +   iommus = <&iommu M4U_PORT_VENC_RCPU>;
> > +   };
> > -- 
> > 1.7.9.5
> > 


--
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


Re: [PATCH v4 3/3] ARM: dts: rockchip: Add the OTP gpio pinctrl

2015-11-18 Thread Caesar Wang

Hi Heiko,

在 2015年10月25日 15:55, Heiko Stübner 写道:

Am Freitag, 23. Oktober 2015, 08:25:08 schrieb Doug Anderson:

On Fri, Oct 23, 2015 at 4:25 AM, Caesar Wang  wrote:

Add the "init" anf "sleep" pinctrl as the OTP gpio state.
We need the OTP pin is gpio state before resetting the TSADC controller,
since the tshut polarity will generate a high signal.

"init" pinctrl property is defined by Doug's Patch[0].

Patch[0]:
https://patchwork.kernel.org/patch/7454311/

Signed-off-by: Caesar Wang 
Reviewed-by: Douglas Anderson 
---

Changes in v4: None

Changes in v3:
   - Add the "sleep" pinctrl as the gpio state in PATCH[3/3]

Changes in v2:
   - Add some commits for more obvious in PATCH[2/2]

Changes in v1:
   - As the Doug comments, drop the thermal driver patchs since
   
 we can with pinctrl changing to work.
   
   - As the Doug's patch to add the 'init' property.
  
  arch/arm/boot/dts/rk3288.dtsi | 10 --

  1 file changed, 8 insertions(+), 2 deletions(-)

I realized that the subject of this patch should probably contain the
word rk3288, but I presume Heiko would rather add that himself than
for you to spin this again.  ;)

yep :-) ... no need to respin for such an easy change


That's seem this patch didn't merge into your v4.5-armsoc/soc branch.:-)

I guess this patch should merge into  kernel-4.4 since the Patch[1/3] / 
[2/3] have been merged into 4.4-rc1.:-P




___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



--
Thanks,
Caesar

--
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


Re: [PATCH] usb: dwc2: add support of hi6220

2015-11-18 Thread John Youn
On 11/17/2015 11:39 PM, Zhangfei Gao wrote:
> Support hisilicon,hi6220-usb for HiKey board
> 
> Signed-off-by: Zhangfei Gao 
> ---
>  Documentation/devicetree/bindings/usb/dwc2.txt |  1 +
>  drivers/usb/dwc2/platform.c| 32 
> ++
>  2 files changed, 33 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt 
> b/Documentation/devicetree/bindings/usb/dwc2.txt
> index fd132cb..2213682 100644
> --- a/Documentation/devicetree/bindings/usb/dwc2.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
> @@ -4,6 +4,7 @@ Platform DesignWare HS OTG USB 2.0 controller
>  Required properties:
>  - compatible : One of:
>- brcm,bcm2835-usb: The DWC2 USB controller instance in the BCM2835 SoC.
> +  - hisilicon,hi6220-usb: The DWC2 USB controller instance in the hi6220 SoC.
>- rockchip,rk3066-usb: The DWC2 USB controller instance in the rk3066 Soc;
>- "rockchip,rk3188-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3188 
> Soc;
>- "rockchip,rk3288-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3288 
> Soc;
> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> index 5859b0f..a5cb1bf 100644
> --- a/drivers/usb/dwc2/platform.c
> +++ b/drivers/usb/dwc2/platform.c
> @@ -54,6 +54,37 @@
>  
>  static const char dwc2_driver_name[] = "dwc2";
>  
> +static const struct dwc2_core_params params_hi6220 = {
> + .otg_cap= 2,/* No HNP/SRP capable */
> + .otg_ver= 0,/* 1.3 */
> + .dma_enable = 1,
> + .dma_desc_enable= 0,
> + .speed  = 0,/* High Speed */
> + .enable_dynamic_fifo= 1,
> + .en_multiple_tx_fifo= 1,
> + .host_rx_fifo_size  = 512,
> + .host_nperio_tx_fifo_size   = 512,
> + .host_perio_tx_fifo_size= 512,
> + .max_transfer_size  = 65535,
> + .max_packet_count   = 511,
> + .host_channels  = 16,
> + .phy_type   = 1,/* UTMI */
> + .phy_utmi_width = 8,
> + .phy_ulpi_ddr   = 0,/* Single */
> + .phy_ulpi_ext_vbus  = 0,
> + .i2c_enable = 0,
> + .ulpi_fs_ls = 0,
> + .host_support_fs_ls_low_power   = 0,
> + .host_ls_low_power_phy_clk  = 0,/* 48 MHz */
> + .ts_dline   = 0,
> + .reload_ctl = 0,
> + .ahbcfg = GAHBCFG_HBSTLEN_INCR16 <<
> +   GAHBCFG_HBSTLEN_SHIFT,
> + .uframe_sched   = 0,
> + .external_id_pin_ctl= -1,
> + .hibernation= -1,
> +};
> +
>  static const struct dwc2_core_params params_bcm2835 = {
>   .otg_cap= 0,/* HNP/SRP capable */
>   .otg_ver= 0,/* 1.3 */
> @@ -282,6 +313,7 @@ static int dwc2_driver_remove(struct platform_device *dev)
>  
>  static const struct of_device_id dwc2_of_match_table[] = {
>   { .compatible = "brcm,bcm2835-usb", .data = ¶ms_bcm2835 },
> + { .compatible = "hisilicon,hi6220-usb", .data = ¶ms_hi6220 },
>   { .compatible = "rockchip,rk3066-usb", .data = ¶ms_rk3066 },
>   { .compatible = "snps,dwc2", .data = NULL },
>   { .compatible = "samsung,s3c6400-hsotg", .data = NULL},
> 

Acked-by: John Youn 

Regards,
John


--
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


Re: [PATCH 1/3] ARM: imx: clk-vf610: fix SAI clock tree

2015-11-18 Thread Stefan Agner
Hi Shawn,

Any thoughts on that patchset? I kind of hoped that it would make it
into 4.4 since it actually fixes issues (at least 1 and 2)... That said,
I don't think it is stable material since it also breaks the device
tree...

--
Stefan

On 2015-10-17 21:05, Stefan Agner wrote:
> The Synchronous Audio Interface (SAI) instances are clocked by
> independent clocks: The bus clock and the audio clock (as shown in
> Figure 51-1 in the Vybrid Reference Manual). The clock gates in
> CCGR0/CCGR1 for SAI0 through SAI3 are bus clock gates, as access
> tests to the registers with/without gating those clocks have shown.
> The audio clock is gated by the SAIx_EN gates in CCM_CSCDR1,
> followed by a clock divider (SAIx_DIV). Currently, the parent of
> the bus clock gates has been assigned to SAIx_DIV, which is not
> involved in the bus clock path for the SAI instances (see chapter
> 9.10.12, SAI clocking in the Vybrid Reference Manual).
> 
> Fix this by define the parent clock of VF610_CLK_SAIx to be the bus
> clock.
> 
> If the driver needs the audio clock (when used in master mode), a
> fixed device tree is required which assign the audio clock properly
> to VF610_CLK_SAIx_DIV.
> 
> Signed-off-by: Stefan Agner 
> ---
> Hi all,
> 
> Patch 1 and 2 are actual fixes and should be applied toghether. If
> the clock tree changes are applied only, master mode won't work
> anymore. With only the device tree changes applied, it probably
> will still work but the VF610_CLK_SAIx_DIV will be enabled twice.
> 
> Since Patch 3 also uses the fixed clock layout, it should be
> applied after the clock tree fix too...
> 
> Not sure through which tree these changes should go?
> 
> --
> Stefan
> 
>  drivers/clk/imx/clk-vf610.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/clk/imx/clk-vf610.c b/drivers/clk/imx/clk-vf610.c
> index bff45ea..42a7a23 100644
> --- a/drivers/clk/imx/clk-vf610.c
> +++ b/drivers/clk/imx/clk-vf610.c
> @@ -335,22 +335,22 @@ static void __init vf610_clocks_init(struct
> device_node *ccm_node)
>   clk[VF610_CLK_SAI0_SEL] = imx_clk_mux("sai0_sel", CCM_CSCMR1, 0, 2,
> sai_sels, 4);
>   clk[VF610_CLK_SAI0_EN] = imx_clk_gate("sai0_en", "sai0_sel", 
> CCM_CSCDR1, 16);
>   clk[VF610_CLK_SAI0_DIV] = imx_clk_divider("sai0_div", "sai0_en",
> CCM_CSCDR1, 0, 4);
> - clk[VF610_CLK_SAI0] = imx_clk_gate2("sai0", "sai0_div", CCM_CCGR0,
> CCM_CCGRx_CGn(15));
> + clk[VF610_CLK_SAI0] = imx_clk_gate2("sai0", "ipg_bus", CCM_CCGR0,
> CCM_CCGRx_CGn(15));
>  
>   clk[VF610_CLK_SAI1_SEL] = imx_clk_mux("sai1_sel", CCM_CSCMR1, 2, 2,
> sai_sels, 4);
>   clk[VF610_CLK_SAI1_EN] = imx_clk_gate("sai1_en", "sai1_sel", 
> CCM_CSCDR1, 17);
>   clk[VF610_CLK_SAI1_DIV] = imx_clk_divider("sai1_div", "sai1_en",
> CCM_CSCDR1, 4, 4);
> - clk[VF610_CLK_SAI1] = imx_clk_gate2("sai1", "sai1_div", CCM_CCGR1,
> CCM_CCGRx_CGn(0));
> + clk[VF610_CLK_SAI1] = imx_clk_gate2("sai1", "ipg_bus", CCM_CCGR1,
> CCM_CCGRx_CGn(0));
>  
>   clk[VF610_CLK_SAI2_SEL] = imx_clk_mux("sai2_sel", CCM_CSCMR1, 4, 2,
> sai_sels, 4);
>   clk[VF610_CLK_SAI2_EN] = imx_clk_gate("sai2_en", "sai2_sel", 
> CCM_CSCDR1, 18);
>   clk[VF610_CLK_SAI2_DIV] = imx_clk_divider("sai2_div", "sai2_en",
> CCM_CSCDR1, 8, 4);
> - clk[VF610_CLK_SAI2] = imx_clk_gate2("sai2", "sai2_div", CCM_CCGR1,
> CCM_CCGRx_CGn(1));
> + clk[VF610_CLK_SAI2] = imx_clk_gate2("sai2", "ipg_bus", CCM_CCGR1,
> CCM_CCGRx_CGn(1));
>  
>   clk[VF610_CLK_SAI3_SEL] = imx_clk_mux("sai3_sel", CCM_CSCMR1, 6, 2,
> sai_sels, 4);
>   clk[VF610_CLK_SAI3_EN] = imx_clk_gate("sai3_en", "sai3_sel", 
> CCM_CSCDR1, 19);
>   clk[VF610_CLK_SAI3_DIV] = imx_clk_divider("sai3_div", "sai3_en",
> CCM_CSCDR1, 12, 4);
> - clk[VF610_CLK_SAI3] = imx_clk_gate2("sai3", "sai3_div", CCM_CCGR1,
> CCM_CCGRx_CGn(2));
> + clk[VF610_CLK_SAI3] = imx_clk_gate2("sai3", "ipg_bus", CCM_CCGR1,
> CCM_CCGRx_CGn(2));
>  
>   clk[VF610_CLK_NFC_SEL] = imx_clk_mux("nfc_sel", CCM_CSCMR1, 12, 2,
> nfc_sels, 4);
>   clk[VF610_CLK_NFC_EN] = imx_clk_gate("nfc_en", "nfc_sel", CCM_CSCDR2, 
> 9);
--
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


Re: [PATCH 1/2] usb: doc: dwc3-xilinx: Add devicetree bindings

2015-11-18 Thread Rob Herring
On Wed, Nov 18, 2015 at 5:02 PM, Felipe Balbi  wrote:
>
> Hi,
>
> Rob Herring  writes:
>> On Wed, Nov 18, 2015 at 06:20:31PM +0530, Subbaraya Sundeep Bhatta wrote:
>>> This patch adds binding doc for Xilinx DWC3 glue driver.
>>>
>>> Signed-off-by: Subbaraya Sundeep Bhatta 
>>
>> I really dislike how the DWC3 binding has been done. The sub-node here
>> is pointless. The only thing the outer node does is add clocks which
>> should simply be part of the DWC3 node. Presumably the IP block needs
>> some clocks...
>>
>> Anyway, it's self-contained within the DWC3, so I won't make you clean
>> up the mess.
>
> heh, it's definitely not pointless. We get a lot of free goodies by
> doing it that way. I'm just not going to repeat it once again. But in
> summary:
>
> a) we force people to write glue layers for *only* their HW specific
> details
>
> b) there's really no way to abuse dwc3 core because there's no symbol
> exported from dwc3 core to glue

Both are doable independent of DT.

> c) PM (both system sleep and runtime) becomes a lot simpler with core
> only caring about what PM details delivered by SNPS (e.g. Hibernation
> mode from DWC3) and glue only has to consider the SoC integration parts
> of PM (for OMAP that would be PRCM details, hwmod, etc).

No doubt OMAP is special.

> I'm definitely not going to change dwc3 because it has made my life a
> lot saner. Definitely a lot saner than MUSB. Besides, DTS is supposed to
> describe the HW and that's, really, how the HW is.

So reading the description, the DWC3 has no clocks?

> There's a piece of HW which is somewhat platform agnostic and delivered
> by SNPS as a black box (SNPS customers don't touch SNPS RTL) and there's
> another piece of HW which bridges this dwc3 to the platform specific
> details and integration context of the platform (for OMAP that would the
> SYSCONFIG/SYSSTATUS registers, Clock autogating, PRCM, etc, etc etc).

It is a black box, but with dozens of configuration options typically.

> So you _do_ in fact, have two separate pieces of HW which are SW visible
> and controllable independently. They each have their own IRQs (though in
> some SoCs they share the same line), they're own address space, yada
> yada yada.

When that is the case, I have no problem with this split, but I don't
see any of these examples in this particular case. So how should the
binding look when there is no vendor specific glue? Are we supposed to
keep the binding structure to appease the needs of the driver?

Rob
--
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


Re: [PATCH v3 2/5] dt-bindings: soc: add document for rockchip reboot notifier driver

2015-11-18 Thread Andy Yan

Hi Rob:

On 2015年11月19日 06:59, Rob Herring wrote:

On Wed, Nov 18, 2015 at 05:53:30PM +0800, Andy Yan wrote:

Add devicetree binding document for rockchip reboot nofifier driver

Just reading the subject this is way too specific to the Linux driver
needs rather than a h/w description. Please don't create fake DT nodes
just to bind to drivers. Whatever &pmu is is probably what should have
the DT node. Let the driver for it create child devices if you need
that.


This is note a fake DT nodes, we really need it to tell the driver
 which register to use to store the reboot mode. Because rockchip
 use different register file to store the reboot mode on different
 platform, on rk3066,rk3188, rk3288,it use  one of the PMU 
register, on
 the incoming RK3036, it use one of the GRF register, and it use 
one  of

 the PMUGRF register for arm64 platform rk3368. On the other hand, the
 PMU/GRF/PMUGRF register file are mapped as "syscon", then referenced
 by other DT nodes by phandle. So maybe let it as a separate DT 
node here

 is better.


Rob

Signed-off-by: Andy Yan 

---

Changes in v3:
  - add dt binding

Changes in v2: None

  .../bindings/soc/rockchip/rockchip-reboot.txt  | 18 ++
  1 file changed, 18 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/soc/rockchip/rockchip-reboot.txt

diff --git a/Documentation/devicetree/bindings/soc/rockchip/rockchip-reboot.txt 
b/Documentation/devicetree/bindings/soc/rockchip/rockchip-reboot.txt
new file mode 100644
index 000..6f69c8d
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/rockchip/rockchip-reboot.txt
@@ -0,0 +1,18 @@
+Rockchip reboot notifier driver
+
+This driver get reboot mode arguments from userspace
+and stores it in special register. Then the bootloader
+will read it and take different action according the
+argument stored.
+
+Required properties:
+- compatible: should be "rockchip,reboot"
+- regmap: this is phandle to the register map node
+- offset: offset in the register map for the storage register (in bytes)
+
+Examples:
+   reboot {
+  compatible = "rockchip,reboot";
+  regmap = <&pmu>;
+  offset = <0x94>;
+   };
--
1.9.1








--
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


[RESEND PATCH v3] dt-bindings: Consolidate SRAM bindings from all vendors

2015-11-18 Thread Krzysztof Kozlowski
SRAM bindings for various SoCs, using the mmio-sram genalloc
API, are spread over different places - per SoC vendor. Since all of
these are quite similar (they depend on mmio-sram) move them to a common
place.

Suggested-by: Rob Herring 
Signed-off-by: Krzysztof Kozlowski 
Cc: Heiko Stuebner 
Cc: Maxime Ripard 
Cc: Chen-Yu Tsai 
Cc: Kukjin Kim 
Acked-by: Maxime Ripard 
Acked-by: Heiko Stuebner 

---

Changes since v2:
1. Update paths to sram.txt.

Changes since v1:
1. New patch. Extended suggestion from Rob.
---
 Documentation/devicetree/bindings/arm/arm,scpi.txt  | 2 +-
 .../bindings/{arm/rockchip/pmu-sram.txt => sram/rockchip-pmu-sram.txt}  | 0
 .../bindings/{arm/rockchip/smp-sram.txt => sram/rockchip-smp-sram.txt}  | 2 +-
 .../bindings/{arm/exynos/smp-sysram.txt => sram/samsung-sram.txt}   | 2 +-
 Documentation/devicetree/bindings/{misc => sram}/sram.txt   | 0
 .../devicetree/bindings/{soc/sunxi/sram.txt => sram/sunxi-sram.txt} | 2 +-
 6 files changed, 4 insertions(+), 4 deletions(-)
 rename Documentation/devicetree/bindings/{arm/rockchip/pmu-sram.txt => 
sram/rockchip-pmu-sram.txt} (100%)
 rename Documentation/devicetree/bindings/{arm/rockchip/smp-sram.txt => 
sram/rockchip-smp-sram.txt} (92%)
 rename Documentation/devicetree/bindings/{arm/exynos/smp-sysram.txt => 
sram/samsung-sram.txt} (95%)
 rename Documentation/devicetree/bindings/{misc => sram}/sram.txt (100%)
 rename Documentation/devicetree/bindings/{soc/sunxi/sram.txt => 
sram/sunxi-sram.txt} (97%)

diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt 
b/Documentation/devicetree/bindings/arm/arm,scpi.txt
index 86302de67c2c..313dabdc14f9 100644
--- a/Documentation/devicetree/bindings/arm/arm,scpi.txt
+++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt
@@ -63,7 +63,7 @@ Required properties:
 - compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno
 
 The rest of the properties should follow the generic mmio-sram description
-found in ../../misc/sysram.txt
+found in ../../sram/sram.txt
 
 Each sub-node represents the reserved area for SCPI.
 
diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt 
b/Documentation/devicetree/bindings/sram/rockchip-pmu-sram.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/rockchip/pmu-sram.txt
rename to Documentation/devicetree/bindings/sram/rockchip-pmu-sram.txt
diff --git a/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt 
b/Documentation/devicetree/bindings/sram/rockchip-smp-sram.txt
similarity index 92%
rename from Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt
rename to Documentation/devicetree/bindings/sram/rockchip-smp-sram.txt
index d9416fb8db6f..800701ecffca 100644
--- a/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt
+++ b/Documentation/devicetree/bindings/sram/rockchip-smp-sram.txt
@@ -12,7 +12,7 @@ Required sub-node properties:
 - compatible : should be "rockchip,rk3066-smp-sram"
 
 The rest of the properties should follow the generic mmio-sram discription
-found in ../../misc/sram.txt
+found in Documentation/devicetree/bindings/sram/sram.txt
 
 Example:
 
diff --git a/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt 
b/Documentation/devicetree/bindings/sram/samsung-sram.txt
similarity index 95%
rename from Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
rename to Documentation/devicetree/bindings/sram/samsung-sram.txt
index 4a0a4f70a0ce..6bc474b2b885 100644
--- a/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
+++ b/Documentation/devicetree/bindings/sram/samsung-sram.txt
@@ -15,7 +15,7 @@ Required sub-node properties:
"samsung,exynos4210-sysram-ns" : for Non-secure SYSRAM
 
 The rest of the properties should follow the generic mmio-sram discription
-found in ../../misc/sysram.txt
+found in Documentation/devicetree/bindings/sram/sram.txt
 
 Example:
 
diff --git a/Documentation/devicetree/bindings/misc/sram.txt 
b/Documentation/devicetree/bindings/sram/sram.txt
similarity index 100%
rename from Documentation/devicetree/bindings/misc/sram.txt
rename to Documentation/devicetree/bindings/sram/sram.txt
diff --git a/Documentation/devicetree/bindings/soc/sunxi/sram.txt 
b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
similarity index 97%
rename from Documentation/devicetree/bindings/soc/sunxi/sram.txt
rename to Documentation/devicetree/bindings/sram/sunxi-sram.txt
index 067698112f5f..8d5665468fe7 100644
--- a/Documentation/devicetree/bindings/soc/sunxi/sram.txt
+++ b/Documentation/devicetree/bindings/sram/sunxi-sram.txt
@@ -16,7 +16,7 @@ SRAM nodes
 --
 
 Each SRAM is described using the mmio-sram bindings documented in
-Documentation/devicetree/bindings/misc/sram.txt
+Documentation/devicetree/bindings/sram/sram.txt
 
 Each SRAM will have SRAM sections that are going to be handled by the
 SRAM controller as subnodes. These sections are represented following
-- 
1.9.1

--
To unsubscribe from this

Re: [PATCH v3 3/5] soc: rockchip: add reboot notifier driver

2015-11-18 Thread kbuild test robot
Hi Andy,

[auto build test WARNING on rockchip/for-next]
[also build test WARNING on v4.4-rc1 next-20151118]

url:
https://github.com/0day-ci/linux/commits/Andy-Yan/Add-reboot-notifier-driver-for-rockchip-platform/20151118-181000
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git 
for-next
config: arm64-allmodconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All warnings (new ones prefixed by >>):

>> WARNING: drivers/soc/built-in.o(.data+0x718): Section mismatch in reference 
>> from the variable rockchip_reboot_driver to the function 
>> .init.text:rockchip_reboot_probe()
   The variable rockchip_reboot_driver references
   the function __init rockchip_reboot_probe()
   If the reference is valid then annotate the
   variable with or __refdata (see linux/init.h) or name the variable:
   

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data


Re: [PATCH v7 25/50] powerpc/powernv: Reserve PE for root bus

2015-11-18 Thread Alexey Kardashevskiy

On 11/17/2015 08:06 PM, Gavin Shan wrote:

On Tue, Nov 17, 2015 at 05:04:42PM +1100, Alexey Kardashevskiy wrote:

On 11/05/2015 12:12 AM, Gavin Shan wrote:

We're going to reserve/assign PEs when pcibios_setup_bridge() is
called. The function won't be called for root bus as it doesn't
have parent bridge. However, the root bus still needs a PE to be
covered.

This reserves PE numbers that are adjacent to the reserved one
for root buses.



Somewhere in the patchset you need to describe why you need a separate PE for
a root bus and why reserved_pe_idx is not enough for this.



Please confirm if it's fine to add the descrption in this patch's chagelog.


Yes, it is fine. Thanks!


--
Alexey
--
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


Re: [PATCH v7 14/50] powerpc/powernv: M64 support on P7IOC

2015-11-18 Thread Alexey Kardashevskiy

On 11/17/2015 12:37 PM, Gavin Shan wrote:

On Mon, Nov 16, 2015 at 07:01:46PM +1100, Alexey Kardashevskiy wrote:

On 11/05/2015 12:12 AM, Gavin Shan wrote:

This enables M64 window on P7IOC, which has been enabled on PHB3.
Different from PHB3 where 16 M64 BARs are supported and each of
them can be owned by one particular PE# exclusively or divided
evenly to 256 segments, every P7IOC PHB has 16 M64 BARs and each
of them are divided to 8 segments. So every P7IOC PHB supports
128 M64 segments in total. P7IOC has M64DT, which helps mapping
one particular M64 segment# to arbitrary PE#. PHB3 doesn't have
M64DT, indicating that one M64 segment can only be pinned to the
fixed PE#. In order to have same code to support M64 on P7IOC and
PHB3, we just provide 128 M64 segments on every P7IOC PHB and each
of them is pinned to the fixed PE# by bypassing the function of
M64DT. In turn, we just need different phb->init_m64() for P7IOC
and PHB3 to support M64.

Signed-off-by: Gavin Shan 
---
  arch/powerpc/platforms/powernv/pci-ioda.c | 86 +--
  arch/powerpc/platforms/powernv/pci.h  |  3 ++
  2 files changed, 86 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 1f7d985..bfe69f1 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -256,6 +256,64 @@ static void pnv_ioda_reserve_dev_m64_pe(struct pci_dev 
*pdev,
}
  }

+static int pnv_ioda1_init_m64(struct pnv_phb *phb)
+{
+   struct resource *r;
+   int index;
+
+   /*
+* There are 16 M64 BARs, each of which has 8 segments. So
+* there are as many M64 segments as the maximum number of
+* PEs, which is 128.
+*/
+   for (index = 0; index < PNV_IODA1_M64_NUM; index++) {
+   unsigned long base, segsz = phb->ioda.m64_segsize;
+   int64_t rc;
+
+   base = phb->ioda.m64_base +
+  index * PNV_IODA1_M64_SEGS * segsz;
+   rc = opal_pci_set_phb_mem_window(phb->opal_id,
+   OPAL_M64_WINDOW_TYPE, index, base, 0,
+   PNV_IODA1_M64_SEGS * segsz);
+   if (rc != OPAL_SUCCESS) {
+   pr_warn("  Error %lld setting M64 PHB#%d-BAR#%d\n",
+   rc, phb->hose->global_number, index);
+   goto fail;
+   }
+
+   rc = opal_pci_phb_mmio_enable(phb->opal_id,
+   OPAL_M64_WINDOW_TYPE, index,
+   OPAL_ENABLE_M64_SPLIT);
+   if (rc != OPAL_SUCCESS) {
+   pr_warn("  Error %lld enabling M64 PHB#%d-BAR#%d\n",
+   rc, phb->hose->global_number, index);
+   goto fail;
+   }
+   }
+
+   /*
+* Exclude the segment used by the reserved PE, which
+* is expected to be 0 or last supported PE#.
+*/
+   r = &phb->hose->mem_resources[1];
+   if (phb->ioda.reserved_pe_idx == 0)
+   r->start += phb->ioda.m64_segsize;
+   else if (phb->ioda.reserved_pe_idx == (phb->ioda.total_pe_num - 1))
+   r->end -= phb->ioda.m64_segsize;
+   else
+   pr_warn("  Cannot cut M64 segment for reserved PE#%d\n",
+   phb->ioda.reserved_pe_idx);
+
+   return 0;
+
+fail:
+   for ( ; index >= 0; index--)
+   opal_pci_phb_mmio_enable(phb->opal_id,
+   OPAL_M64_WINDOW_TYPE, index, OPAL_DISABLE_M64);
+
+   return -EIO;
+}
+
  static void pnv_ioda_reserve_m64_pe(struct pci_bus *bus,
unsigned long *pe_bitmap,
bool all)
@@ -325,6 +383,26 @@ static int pnv_ioda_pick_m64_pe(struct pci_bus *bus, bool 
all)
pe->master = master_pe;
list_add_tail(&pe->list, &master_pe->slaves);
}
+
+   /*
+* P7IOC supports M64DT, which helps mapping M64 segment
+* to one particular PE#. However, PHB3 has fixed mapping
+* between M64 segment and PE#. In order to have same logic
+* for P7IOC and PHB3, we enforce fixed mapping between M64
+* segment and PE# on P7IOC.
+*/
+   if (phb->type == PNV_PHB_IODA1) {
+   int64_t rc;
+
+   rc = opal_pci_map_pe_mmio_window(phb->opal_id,
+   pe->pe_number, OPAL_M64_WINDOW_TYPE,
+   pe->pe_number / PNV_IODA1_M64_SEGS,
+   pe->pe_number % PNV_IODA1_M64_SEGS);
+   if (rc != OPAL_SUCCESS)
+   pr_warn("%s: Error %lld mapping M64 for 
PHB#%d-PE#%d\n",
+   

Re: [PATCH 3/3] ARM64: dts: enable clock support for Broadcom NS2

2015-11-18 Thread Ray Jui



On 11/18/2015 4:07 PM, Florian Fainelli wrote:

On 18/11/15 16:03, Ray Jui wrote:



On 11/18/2015 3:13 PM, Jon Mason wrote:

Add device tree entries for clock support for Broadcom Northstar 2 SoC

Signed-off-by: Jon Mason 
---
   arch/arm64/boot/dts/broadcom/ns2.dtsi | 80
++-
   1 file changed, 79 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index 9610822..a510d3a 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -31,6 +31,7 @@
*/

   #include 
+#include 

   /memreserve/ 0x84b0 0x0008;

@@ -109,6 +110,33 @@
<&A57_3>;
   };

+clocks {


Is this a new convention? That is, group all clocks without a base
register address in a node named "clocks", but at the same time, put all
other clocks with base register address under a bus node.


I do not think that is new, lots of platforms do that. The clock
providers/controllers would typically be in the 'bus' nodes because it
has a register interface, while the synthetic clocks would be under
'clocks'.



Okay that's very good to know. Thanks!

Ray
--
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


Re: [PATCH v7 12/50] powerpc/powernv: Track M64 segment consumption

2015-11-18 Thread Alexey Kardashevskiy

On 11/17/2015 12:04 PM, Gavin Shan wrote:

On Mon, Nov 16, 2015 at 07:01:59PM +1100, Alexey Kardashevskiy wrote:

On 11/05/2015 12:12 AM, Gavin Shan wrote:

As we track M32 segment consumption, this introduces an array to
the PHB to track the mapping between M64 segment and PE number.
The information is going to be used to find M64 segment from the
PE number during PCI unplugging time in subsequent patches.



It would not hurt to put a few words about how we managed to live without
such a mapping for M64 before but we needed mapping for M32.



The M32 mapping (phb->ioda.m32_segmap[]) isn't used for anything before
this patcheset. There're no need for M64 mapping before this patchset
similarly, no need to add the words.


After years I learned that reviewers ask less questions about new but yet 
unused code when I put few words in the commit log confirming that it is 
not used now but it will be used for  later.


And it is not obvious that m32_segment is not used. And m64_segmap is 
started being used only 13 patches later in:


[PATCH v7 27/50] powerpc/powernv: Dynamically release PEs

which is quite far, complicates reviewing. 12/50 is better be moved there 
(to make it 26/50) or just merged into 27/50.



--
Alexey
--
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


Re: [PATCH 3/3] ARM64: dts: enable clock support for Broadcom NS2

2015-11-18 Thread Florian Fainelli
On 18/11/15 16:03, Ray Jui wrote:
> 
> 
> On 11/18/2015 3:13 PM, Jon Mason wrote:
>> Add device tree entries for clock support for Broadcom Northstar 2 SoC
>>
>> Signed-off-by: Jon Mason 
>> ---
>>   arch/arm64/boot/dts/broadcom/ns2.dtsi | 80
>> ++-
>>   1 file changed, 79 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi
>> b/arch/arm64/boot/dts/broadcom/ns2.dtsi
>> index 9610822..a510d3a 100644
>> --- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
>> +++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
>> @@ -31,6 +31,7 @@
>>*/
>>
>>   #include 
>> +#include 
>>
>>   /memreserve/ 0x84b0 0x0008;
>>
>> @@ -109,6 +110,33 @@
>><&A57_3>;
>>   };
>>
>> +clocks {
> 
> Is this a new convention? That is, group all clocks without a base
> register address in a node named "clocks", but at the same time, put all
> other clocks with base register address under a bus node.

I do not think that is new, lots of platforms do that. The clock
providers/controllers would typically be in the 'bus' nodes because it
has a register interface, while the synthetic clocks would be under
'clocks'.
-- 
Florian
--
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


Re: [PATCH 3/3] ARM64: dts: enable clock support for Broadcom NS2

2015-11-18 Thread Ray Jui



On 11/18/2015 3:13 PM, Jon Mason wrote:

Add device tree entries for clock support for Broadcom Northstar 2 SoC

Signed-off-by: Jon Mason 
---
  arch/arm64/boot/dts/broadcom/ns2.dtsi | 80 ++-
  1 file changed, 79 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi 
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index 9610822..a510d3a 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -31,6 +31,7 @@
   */

  #include 
+#include 

  /memreserve/ 0x84b0 0x0008;

@@ -109,6 +110,33 @@
 <&A57_3>;
};

+   clocks {


Is this a new convention? That is, group all clocks without a base 
register address in a node named "clocks", but at the same time, put all 
other clocks with base register address under a bus node.



+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   osc: oscillator {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <2500>;
+   };
+
+   iprocmed: iprocmed {
+   #clock-cells = <0>;
+   compatible = "fixed-factor-clock";
+   clocks = <&genpll_scr BCM_NS2_GENPLL_SCR_SCR_CLK>;
+   clock-div = <2>;
+   clock-mult = <1>;
+   };
+
+   iprocslow: iprocslow {
+   #clock-cells = <0>;
+   compatible = "fixed-factor-clock";
+   clocks = <&genpll_scr BCM_NS2_GENPLL_SCR_SCR_CLK>;
+   clock-div = <4>;
+   clock-mult = <1>;
+   };
+   };
+
soc: soc {
compatible = "simple-bus";
#address-cells = <1>;
@@ -156,6 +184,56 @@
mmu-masters;
};

+   lcpll_ddr: lcpll_ddr@6501d058 {
+   #clock-cells = <1>;
+   compatible = "brcm,ns2-lcpll-ddr";
+   reg = <0x6501d058 0x20>,
+ <0x6501c020 0x4>,
+ <0x6501d04c 0x4>;
+   clocks = <&osc>;
+   clock-output-names = "lcpll_ddr", "pcie_sata_usb",
+"ddr", "ddr_ch2_unused",
+"ddr_ch3_unused", "ddr_ch4_unused",
+"ddr_ch5_unused";
+   };
+
+   lcpll_ports: lcpll_ports@6501d078 {
+   #clock-cells = <1>;
+   compatible = "brcm,ns2-lcpll-ports";
+   reg = <0x6501d078 0x20>,
+ <0x6501c020 0x4>,
+ <0x6501d054 0x4>;
+   clocks = <&osc>;
+   clock-output-names = "lcpll_ports", "wan", "rgmii",
+"ports_ch2_unused",
+"ports_ch3_unused",
+"ports_ch4_unused",
+"ports_ch5_unused";
+   };
+
+   genpll_scr: genpll_scr@6501d098 {
+   #clock-cells = <1>;
+   compatible = "brcm,ns2-genpll-scr";
+   reg = <0x6501d098 0x32>,
+ <0x6501c020 0x4>,
+ <0x6501d044 0x4>;
+   clocks = <&osc>;
+   clock-output-names = "genpll_scr", "scr", "fs",
+"audio_ref", "scr_ch3_unused",
+"scr_ch4_unused", "scr_ch5_unused";
+   };
+
+   genpll_sw: genpll_sw@6501d0c4 {
+   #clock-cells = <1>;
+   compatible = "brcm,ns2-genpll-sw";
+   reg = <0x6501d0c4 0x32>,
+ <0x6501c020 0x4>,
+ <0x6501d044 0x4>;
+   clocks = <&osc>;
+   clock-output-names = "genpll_sw", "rpe", "250", "nic",
+"chimp", "port", "sdio";
+   };
+
crmu: crmu@65024000 {
compatible = "syscon";
reg = <0x65024000 0x100>;
@@ -204,7 +282,7 @@
interrupts = ;
reg-shift = <2>;
reg-io-width = <4>;
-   clock-frequency = <23961600>;
+   clocks = <&osc>;
status = "disabled";
};



--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org

Re: [PATCH 2/3] ARM: dts: enable clock support for Broadcom NSP

2015-11-18 Thread Ray Jui
Would this patch merge properly with the other NSP DT clean up patch + 
I2C DT patch that you worked out internally but have not sent out?


I thought it's going to make the maintainers' life easier if you can 
group DT changes per platform and send them out in the same series.


I also have some inline comments below.

On 11/18/2015 3:13 PM, Jon Mason wrote:

Replace current device tree dummy clocks with real clock support for
Broadcom Northstar Plus SoC

Signed-off-by: Jon Mason 
---
  arch/arm/boot/dts/bcm-nsp.dtsi | 99 --
  1 file changed, 75 insertions(+), 24 deletions(-)

diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index 4bcdd28..f85a4f1 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -32,6 +32,7 @@

  #include 
  #include 
+#include 

  #include "skeleton.dtsi"

@@ -42,7 +43,7 @@

mpcore {
compatible = "simple-bus";
-   ranges = <0x 0x1902 0x3000>;
+   ranges = <0x 0x1900 0x00023000>;


Why does this have anything to do with clocks? Shouldn't it be a 
separate patch?



#address-cells = <1>;
#size-cells = <1>;

@@ -58,32 +59,23 @@
};
};

-   L2: l2-cache {
-   compatible = "arm,pl310-cache";
-   reg = <0x2000 0x1000>;
-   cache-unified;
-   cache-level = <2>;
-   };
-
-   gic: interrupt-controller@19021000 {
-   compatible = "arm,cortex-a9-gic";
-   #interrupt-cells = <3>;
-   #address-cells = <0>;
-   interrupt-controller;
-   reg = <0x1000 0x1000>,
- <0x0100 0x100>;
+   a9pll: arm_clk@1900 {
+   #clock-cells = <0>;
+   compatible = "brcm,nsp-armpll";
+   clocks = <&osc>;
+   reg = <0x0 0x1000>;
};

timer@19020200 {
compatible = "arm,cortex-a9-global-timer";
-   reg = <0x0200 0x100>;
+   reg = <0x20200 0x100>;
interrupts = ;
clocks = <&periph_clk>;
};

twd-timer@19020600 {
compatible = "arm,cortex-a9-twd-timer";
-   reg = <0x0600 0x20>;
+   reg = <0x20600 0x20>;
interrupts = ;
clocks = <&periph_clk>;
@@ -91,11 +83,27 @@

twd-watchdog@19020620 {
compatible = "arm,cortex-a9-twd-wdt";
-   reg = <0x0620 0x20>;
+   reg = <0x20620 0x20>;
interrupts = ;
clocks = <&periph_clk>;
};
+
+   gic: interrupt-controller@19021000 {
+   compatible = "arm,cortex-a9-gic";
+   #interrupt-cells = <3>;
+   #address-cells = <0>;
+   interrupt-controller;
+   reg = <0x21000 0x1000>,
+ <0x20100 0x100>;
+   };
+
+   L2: l2-cache {
+   compatible = "arm,pl310-cache";
+   reg = <0x22000 0x1000>;
+   cache-unified;
+   cache-level = <2>;
+   };


From here and above, all labels are wrong. You are moving them into a 
bus that has translated bus addresses, but you still use absolute 
addresses for all labels.


And again, 1) Why is this change imbedded in a patch meant for adding DT 
clock support according to the commit message; 2) how does the 
dependency work with the other patches that you are about to send out?




};

clocks {
@@ -103,10 +111,34 @@
#size-cells = <1>;
ranges;

-   periph_clk: periph_clk {
+   osc: oscillator {
+   #clock-cells = <0>;
compatible = "fixed-clock";
+   clock-frequency = <2500>;
+   };
+
+   iprocmed: iprocmed {
+   #clock-cells = <0>;
+   compatible = "fixed-factor-clock";
+   clocks = <&genpll BCM_NSP_GENPLL_IPROCFAST_CLK>;
+   clock-div = <2>;
+   clock-mult = <1>;
+   };
+
+   iprocslow: iprocslow {
+   #clock-cells = <0>;
+   compatible = "fixed-factor-clock";
+   clocks = <&genpll BCM_NSP_GENPLL_IPROCFAST_CLK>;
+   clock-div = <4>;
+   clock-mult

Re: [PATCH 2/2] power: Add support for TI BQ24261 charger

2015-11-18 Thread Andreas Dannenberg
Hi Ram,
I'm back in the battery charger game, please find additional feedback
below. Generally speaking I'd like us to pick up the work on this
driver again to get it over the hump. If you are B/W constrained I'd be
happy to take over the upstreaming process - your call. It's just like I
said earlier I'm on the hook providing support for bq24261M and bq24262
devices from a TI POV and this work is gating the progress on that
front.

On Thu, Oct 29, 2015 at 10:07:05PM +0530, Ramakrishna Pallala wrote:
> Add new charger driver support for TI BQ24261 charger IC.
> 
> TI BQ24261 charger driver relies on extcon notifications to get the
> charger cable type and based on that it will set the charging parameters.
> 
> Signed-off-by: Ramakrishna Pallala 
> Signed-off-by: Jenny TC 
> ---
>  drivers/power/Kconfig |6 +
>  drivers/power/Makefile|1 +
>  drivers/power/bq24261_charger.c   | 1195 
> +
>  include/linux/power/bq24261_charger.h |   26 +
>  4 files changed, 1228 insertions(+)
>  create mode 100644 drivers/power/bq24261_charger.c
>  create mode 100644 include/linux/power/bq24261_charger.h
> 
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index cb0ae66..d817dd9 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -408,6 +408,12 @@ config CHARGER_BQ24190
>   help
> Say Y to enable support for the TI BQ24190 battery charger.
>  
> +config CHARGER_BQ24261
> + tristate "TI BQ24261 charger driver"
> + depends on I2C && EXTCON
> + help
> +   Say Y here to enable support for TI BQ24261 battery charger.
> +
>  config CHARGER_BQ24257
>   tristate "TI BQ24250/24251/24257 battery charger driver"
>   depends on I2C
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index b0e1bf1..f59d8bd 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -61,6 +61,7 @@ obj-$(CONFIG_CHARGER_MAX8998)   += max8998_charger.o
>  obj-$(CONFIG_CHARGER_QCOM_SMBB)  += qcom_smbb.o
>  obj-$(CONFIG_CHARGER_BQ2415X)+= bq2415x_charger.o
>  obj-$(CONFIG_CHARGER_BQ24190)+= bq24190_charger.o
> +obj-$(CONFIG_CHARGER_BQ24261)+= bq24261_charger.o
>  obj-$(CONFIG_CHARGER_BQ24257)+= bq24257_charger.o
>  obj-$(CONFIG_CHARGER_BQ24735)+= bq24735-charger.o
>  obj-$(CONFIG_CHARGER_BQ25890)+= bq25890_charger.o
> diff --git a/drivers/power/bq24261_charger.c b/drivers/power/bq24261_charger.c
> new file mode 100644
> index 000..04b5752
> --- /dev/null
> +++ b/drivers/power/bq24261_charger.c
> @@ -0,0 +1,1195 @@
> +/*
> + * bq24261_charger.c - BQ24261 Charger driver
> + *
> + * Copyright (C) 2014 Intel Corporation
> + * Author:   Jenny TC 
> + *   Ramakrishna Pallala 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * 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 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DEV_NAME "bq24261-charger"
> +
> +#define EXCEPTION_MONITOR_DELAY  (60 * HZ)
> +#define WDT_RESET_DELAY  (15 * HZ)
> +
> +/* BQ24261 registers */
> +#define BQ24261_STAT_CTRL0_ADDR  0x00
> +#define BQ24261_CTRL_ADDR0x01
> +#define BQ24261_BATT_VOL_CTRL_ADDR   0x02
> +#define BQ24261_VENDOR_REV_ADDR  0x03
> +#define BQ24261_TERM_FCC_ADDR0x04
> +#define BQ24261_VINDPM_STAT_ADDR 0x05
> +#define BQ24261_ST_NTC_MON_ADDR  0x06
> +
> +#define BQ24261_RESET_ENABLE BIT(7)

Similar to the comment made earlier by Andy... Would be good to prefix
each block of register bits with a comment containing the register name.
This way, it'll be easier to understand/maintain the code without having
to need to double-check with the datasheet all the time where which bit
needs to go.

For this to work the register bits would also need to be
organized/grouped by control register which is not always the case right
now (for rexample BQ24261_RESET_ENABLE should be defined further down,
and BQ24261_TMR_RST* should be up there with the first block).

> +
> +#define BQ24261_FAULT_MASK   GENMASK(2, 0)
> +#define BQ24261_VOVP 0x01
> +#define BQ24261_LOW_SUPPLY   0x02
> +#define BQ24261_THERMAL_SHUTDOWN 0x03
> +#define BQ24261_BATT_TEMP_FAULT  0x04
> +#define BQ24261_TIMER_FAULT  0x05
> +#define BQ24261_BATT_OVP 0x06
> +#de

[PATCH 1/3] ARM: dts: enable clock support for BCM5301X

2015-11-18 Thread Jon Mason
Replace current device tree dummy clocks with real clock support for
Broadcom Northstar SoCs.

Signed-off-by: Jon Mason 
---
 arch/arm/boot/dts/bcm5301x.dtsi | 92 +++--
 1 file changed, 71 insertions(+), 21 deletions(-)

diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
index 6f50f67..65a1309 100644
--- a/arch/arm/boot/dts/bcm5301x.dtsi
+++ b/arch/arm/boot/dts/bcm5301x.dtsi
@@ -8,6 +8,7 @@
  * Licensed under the GNU/GPL. See COPYING for details.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -27,7 +28,7 @@
compatible = "ns16550";
reg = <0x0300 0x100>;
interrupts = ;
-   clock-frequency = <1>;
+   clocks = <&iprocslow>;
status = "disabled";
};
 
@@ -35,48 +36,55 @@
compatible = "ns16550";
reg = <0x0400 0x100>;
interrupts = ;
-   clock-frequency = <1>;
+   clocks = <&iprocslow>;
status = "disabled";
};
};
 
mpcore {
compatible = "simple-bus";
-   ranges = <0x 0x1902 0x3000>;
+   ranges = <0x 0x1900 0x00023000>;
#address-cells = <1>;
#size-cells = <1>;
 
-   scu@ {
+   a9pll: arm_clk@0 {
+   #clock-cells = <0>;
+   compatible = "brcm,nsp-armpll";
+   clocks = <&osc>;
+   reg = <0x0 0x1000>;
+   };
+
+   scu@2 {
compatible = "arm,cortex-a9-scu";
-   reg = <0x 0x100>;
+   reg = <0x2 0x100>;
};
 
-   timer@0200 {
+   timer@20200 {
compatible = "arm,cortex-a9-global-timer";
-   reg = <0x0200 0x100>;
+   reg = <0x20200 0x100>;
interrupts = ;
-   clocks = <&clk_periph>;
+   clocks = <&periph_clk>;
};
 
-   local-timer@0600 {
+   local-timer@20600 {
compatible = "arm,cortex-a9-twd-timer";
-   reg = <0x0600 0x100>;
+   reg = <0x20600 0x100>;
interrupts = ;
-   clocks = <&clk_periph>;
+   clocks = <&periph_clk>;
};
 
-   gic: interrupt-controller@1000 {
+   gic: interrupt-controller@21000 {
compatible = "arm,cortex-a9-gic";
#interrupt-cells = <3>;
#address-cells = <0>;
interrupt-controller;
-   reg = <0x1000 0x1000>,
- <0x0100 0x100>;
+   reg = <0x21000 0x1000>,
+ <0x20100 0x100>;
};
 
-   L2: cache-controller@2000 {
+   L2: cache-controller@22000 {
compatible = "arm,pl310-cache";
-   reg = <0x2000 0x1000>;
+   reg = <0x22000 0x1000>;
cache-unified;
arm,shared-override;
prefetch-data = <1>;
@@ -94,14 +102,37 @@
 
clocks {
#address-cells = <1>;
-   #size-cells = <0>;
+   #size-cells = <1>;
+   ranges;
 
-   /* As long as we do not have a real clock driver us this
-* fixed clock */
-   clk_periph: periph {
+   osc: oscillator {
+   #clock-cells = <0>;
compatible = "fixed-clock";
+   clock-frequency = <2500>;
+   };
+
+   iprocmed: iprocmed {
+   #clock-cells = <0>;
+   compatible = "fixed-factor-clock";
+   clocks = <&genpll BCM_NSP_GENPLL_IPROCFAST_CLK>;
+   clock-div = <2>;
+   clock-mult = <1>;
+   };
+
+   iprocslow: iprocslow {
+   #clock-cells = <0>;
+   compatible = "fixed-factor-clock";
+   clocks = <&genpll BCM_NSP_GENPLL_IPROCFAST_CLK>;
+   clock-div = <4>;
+   clock-mult = <1>;
+   };
+
+   periph_clk: periph_clk {
#clock-cells = <0>;
-   clock-frequency = <4>;
+   compatible = "fixed-factor-clock";
+   clocks = <&a9pll>;
+ 

[PATCH 2/3] ARM: dts: enable clock support for Broadcom NSP

2015-11-18 Thread Jon Mason
Replace current device tree dummy clocks with real clock support for
Broadcom Northstar Plus SoC

Signed-off-by: Jon Mason 
---
 arch/arm/boot/dts/bcm-nsp.dtsi | 99 --
 1 file changed, 75 insertions(+), 24 deletions(-)

diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index 4bcdd28..f85a4f1 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -32,6 +32,7 @@
 
 #include 
 #include 
+#include 
 
 #include "skeleton.dtsi"
 
@@ -42,7 +43,7 @@
 
mpcore {
compatible = "simple-bus";
-   ranges = <0x 0x1902 0x3000>;
+   ranges = <0x 0x1900 0x00023000>;
#address-cells = <1>;
#size-cells = <1>;
 
@@ -58,32 +59,23 @@
};
};
 
-   L2: l2-cache {
-   compatible = "arm,pl310-cache";
-   reg = <0x2000 0x1000>;
-   cache-unified;
-   cache-level = <2>;
-   };
-
-   gic: interrupt-controller@19021000 {
-   compatible = "arm,cortex-a9-gic";
-   #interrupt-cells = <3>;
-   #address-cells = <0>;
-   interrupt-controller;
-   reg = <0x1000 0x1000>,
- <0x0100 0x100>;
+   a9pll: arm_clk@1900 {
+   #clock-cells = <0>;
+   compatible = "brcm,nsp-armpll";
+   clocks = <&osc>;
+   reg = <0x0 0x1000>;
};
 
timer@19020200 {
compatible = "arm,cortex-a9-global-timer";
-   reg = <0x0200 0x100>;
+   reg = <0x20200 0x100>;
interrupts = ;
clocks = <&periph_clk>;
};
 
twd-timer@19020600 {
compatible = "arm,cortex-a9-twd-timer";
-   reg = <0x0600 0x20>;
+   reg = <0x20600 0x20>;
interrupts = ;
clocks = <&periph_clk>;
@@ -91,11 +83,27 @@
 
twd-watchdog@19020620 {
compatible = "arm,cortex-a9-twd-wdt";
-   reg = <0x0620 0x20>;
+   reg = <0x20620 0x20>;
interrupts = ;
clocks = <&periph_clk>;
};
+
+   gic: interrupt-controller@19021000 {
+   compatible = "arm,cortex-a9-gic";
+   #interrupt-cells = <3>;
+   #address-cells = <0>;
+   interrupt-controller;
+   reg = <0x21000 0x1000>,
+ <0x20100 0x100>;
+   };
+
+   L2: l2-cache {
+   compatible = "arm,pl310-cache";
+   reg = <0x22000 0x1000>;
+   cache-unified;
+   cache-level = <2>;
+   };
};
 
clocks {
@@ -103,10 +111,34 @@
#size-cells = <1>;
ranges;
 
-   periph_clk: periph_clk {
+   osc: oscillator {
+   #clock-cells = <0>;
compatible = "fixed-clock";
+   clock-frequency = <2500>;
+   };
+
+   iprocmed: iprocmed {
+   #clock-cells = <0>;
+   compatible = "fixed-factor-clock";
+   clocks = <&genpll BCM_NSP_GENPLL_IPROCFAST_CLK>;
+   clock-div = <2>;
+   clock-mult = <1>;
+   };
+
+   iprocslow: iprocslow {
+   #clock-cells = <0>;
+   compatible = "fixed-factor-clock";
+   clocks = <&genpll BCM_NSP_GENPLL_IPROCFAST_CLK>;
+   clock-div = <4>;
+   clock-mult = <1>;
+   };
+
+   periph_clk: periph_clk {
#clock-cells = <0>;
-   clock-frequency = <5>;
+   compatible = "fixed-factor-clock";
+   clocks = <&a9pll>;
+   clock-div = <2>;
+   clock-mult = <1>;
};
};
 
@@ -118,17 +150,17 @@
 
uart0: serial@18000300 {
compatible = "ns16550a";
-   reg = <0x0300 0x100>;
+   reg = <0x000300 0x100>;
interrupts = ;
-   clock-frequency = <62499840>;
+   clocks = <&osc>;
status = "disabled";
};
 
uart1: serial@1

[PATCH 0/3] ARM: dts: add support for NS, NSP, and NS2 clocks

2015-11-18 Thread Jon Mason

This patch series adds device tree support for the Broadcom Northstar,
Northstar Plus, and Northstar 2 clocks.

Last sent as an RFC (see https://lkml.org/lkml/2015/10/13/882) due to
the inability to merge because of the driver dependencies.  Those
necessary driver changes were merged into 4.4.  All comments have been
addressed and it is ready to be pulled in.


Jon Mason (3):
  ARM: dts: enable clock support for BCM5301X
  ARM: dts: enable clock support for Broadcom NSP
  ARM64: dts: enable clock support for Broadcom NS2

 arch/arm/boot/dts/bcm-nsp.dtsi| 99 ++-
 arch/arm/boot/dts/bcm5301x.dtsi   | 92 
 arch/arm64/boot/dts/broadcom/ns2.dtsi | 80 +++-
 3 files changed, 225 insertions(+), 46 deletions(-)

-- 
1.9.1

--
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


[PATCH 3/3] ARM64: dts: enable clock support for Broadcom NS2

2015-11-18 Thread Jon Mason
Add device tree entries for clock support for Broadcom Northstar 2 SoC

Signed-off-by: Jon Mason 
---
 arch/arm64/boot/dts/broadcom/ns2.dtsi | 80 ++-
 1 file changed, 79 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi 
b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index 9610822..a510d3a 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -31,6 +31,7 @@
  */
 
 #include 
+#include 
 
 /memreserve/ 0x84b0 0x0008;
 
@@ -109,6 +110,33 @@
 <&A57_3>;
};
 
+   clocks {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   osc: oscillator {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <2500>;
+   };
+
+   iprocmed: iprocmed {
+   #clock-cells = <0>;
+   compatible = "fixed-factor-clock";
+   clocks = <&genpll_scr BCM_NS2_GENPLL_SCR_SCR_CLK>;
+   clock-div = <2>;
+   clock-mult = <1>;
+   };
+
+   iprocslow: iprocslow {
+   #clock-cells = <0>;
+   compatible = "fixed-factor-clock";
+   clocks = <&genpll_scr BCM_NS2_GENPLL_SCR_SCR_CLK>;
+   clock-div = <4>;
+   clock-mult = <1>;
+   };
+   };
+
soc: soc {
compatible = "simple-bus";
#address-cells = <1>;
@@ -156,6 +184,56 @@
mmu-masters;
};
 
+   lcpll_ddr: lcpll_ddr@6501d058 {
+   #clock-cells = <1>;
+   compatible = "brcm,ns2-lcpll-ddr";
+   reg = <0x6501d058 0x20>,
+ <0x6501c020 0x4>,
+ <0x6501d04c 0x4>;
+   clocks = <&osc>;
+   clock-output-names = "lcpll_ddr", "pcie_sata_usb",
+"ddr", "ddr_ch2_unused",
+"ddr_ch3_unused", "ddr_ch4_unused",
+"ddr_ch5_unused";
+   };
+
+   lcpll_ports: lcpll_ports@6501d078 {
+   #clock-cells = <1>;
+   compatible = "brcm,ns2-lcpll-ports";
+   reg = <0x6501d078 0x20>,
+ <0x6501c020 0x4>,
+ <0x6501d054 0x4>;
+   clocks = <&osc>;
+   clock-output-names = "lcpll_ports", "wan", "rgmii",
+"ports_ch2_unused",
+"ports_ch3_unused",
+"ports_ch4_unused",
+"ports_ch5_unused";
+   };
+
+   genpll_scr: genpll_scr@6501d098 {
+   #clock-cells = <1>;
+   compatible = "brcm,ns2-genpll-scr";
+   reg = <0x6501d098 0x32>,
+ <0x6501c020 0x4>,
+ <0x6501d044 0x4>;
+   clocks = <&osc>;
+   clock-output-names = "genpll_scr", "scr", "fs",
+"audio_ref", "scr_ch3_unused",
+"scr_ch4_unused", "scr_ch5_unused";
+   };
+
+   genpll_sw: genpll_sw@6501d0c4 {
+   #clock-cells = <1>;
+   compatible = "brcm,ns2-genpll-sw";
+   reg = <0x6501d0c4 0x32>,
+ <0x6501c020 0x4>,
+ <0x6501d044 0x4>;
+   clocks = <&osc>;
+   clock-output-names = "genpll_sw", "rpe", "250", "nic",
+"chimp", "port", "sdio";
+   };
+
crmu: crmu@65024000 {
compatible = "syscon";
reg = <0x65024000 0x100>;
@@ -204,7 +282,7 @@
interrupts = ;
reg-shift = <2>;
reg-io-width = <4>;
-   clock-frequency = <23961600>;
+   clocks = <&osc>;
status = "disabled";
};
 
-- 
1.9.1

--
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


Re: [PATCH 1/4] devicetree: bindings: Document Kryo cpu

2015-11-18 Thread Rob Herring
On Tue, Nov 17, 2015 at 05:12:26PM -0800, Stephen Boyd wrote:
> Document the compatible string for the Kryo family of qcom cpus.
> 
> Cc: 
> Signed-off-by: Stephen Boyd 

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/arm/cpus.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt 
> b/Documentation/devicetree/bindings/arm/cpus.txt
> index 3a07a87fef20..6008b99ccb2b 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.txt
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -177,6 +177,7 @@ nodes to be present and contain the properties described 
> below.
>   "marvell,sheeva-v5"
>   "nvidia,tegra132-denver"
>   "qcom,krait"
> + "qcom,kryo"
>   "qcom,scorpion"
>   - enable-method
>   Value type: 
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 
> --
> 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
--
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


Re: [PATCH] phy: add phy-hi6220-usb

2015-11-18 Thread Rob Herring
On Wed, Nov 18, 2015 at 03:35:23PM +0800, Zhangfei Gao wrote:
> Support hi6220 use phy for HiKey board
> 
> Signed-off-by: Zhangfei Gao 
> ---
>  .../devicetree/bindings/phy/phy-hi6220-usb.txt |  16 ++

For the binding:

Acked-by: Rob Herring 

>  drivers/phy/Kconfig|   9 ++
>  drivers/phy/Makefile   |   1 +
>  drivers/phy/phy-hi6220-usb.c   | 168 
> +
>  4 files changed, 194 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/phy-hi6220-usb.txt
>  create mode 100644 drivers/phy/phy-hi6220-usb.c
> 
> diff --git a/Documentation/devicetree/bindings/phy/phy-hi6220-usb.txt 
> b/Documentation/devicetree/bindings/phy/phy-hi6220-usb.txt
> new file mode 100644
> index 000..f17a56e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-hi6220-usb.txt
> @@ -0,0 +1,16 @@
> +Hisilicon hi6220 usb PHY
> +---
> +
> +Required properties:
> +- compatible: should be "hisilicon,hi6220-usb-phy"
> +- #phy-cells: must be 0
> +- hisilicon,peripheral-syscon: phandle of syscon used to control phy.
> +Refer to phy/phy-bindings.txt for the generic PHY binding properties
> +
> +Example:
> + usb_phy: usbphy {
> + compatible = "hisilicon,hi6220-usb-phy";
> + #phy-cells = <0>;
> + phy-supply = <&fixed_5v_hub>;
> + hisilicon,peripheral-syscon = <&sys_ctrl>;
> + };
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 47da573..c91a612 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -206,6 +206,15 @@ config PHY_HIX5HD2_SATA
>   help
> Support for SATA PHY on Hisilicon hix5hd2 Soc.
>  
> +config PHY_HI6220_USB
> + tristate "hi6220 USB PHY support"
> + select GENERIC_PHY
> + select MFD_SYSCON
> + help
> +   Enable this to support the HISILICON HI6220 USB PHY.
> +
> +   To compile this driver as a module, choose M here.
> +
>  config PHY_SUN4I_USB
>   tristate "Allwinner sunxi SoC USB PHY driver"
>   depends on ARCH_SUNXI && HAS_IOMEM && OF
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index a5b18c1..0c5ccc9 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_TI_PIPE3)  += 
> phy-ti-pipe3.o
>  obj-$(CONFIG_TWL4030_USB)+= phy-twl4030-usb.o
>  obj-$(CONFIG_PHY_EXYNOS5250_SATA)+= phy-exynos5250-sata.o
>  obj-$(CONFIG_PHY_HIX5HD2_SATA)   += phy-hix5hd2-sata.o
> +obj-$(CONFIG_PHY_HI6220_USB) += phy-hi6220-usb.o
>  obj-$(CONFIG_PHY_SUN4I_USB)  += phy-sun4i-usb.o
>  obj-$(CONFIG_PHY_SUN9I_USB)  += phy-sun9i-usb.o
>  obj-$(CONFIG_PHY_SAMSUNG_USB2)   += phy-exynos-usb2.o
> diff --git a/drivers/phy/phy-hi6220-usb.c b/drivers/phy/phy-hi6220-usb.c
> new file mode 100644
> index 000..b2141cb
> --- /dev/null
> +++ b/drivers/phy/phy-hi6220-usb.c
> @@ -0,0 +1,168 @@
> +/*
> + * Copyright (c) 2015 Linaro Ltd.
> + * Copyright (c) 2015 Hisilicon Limited.
> + *
> + * 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; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define SC_PERIPH_CTRL4  0x00c
> +
> +#define CTRL4_PICO_SIDDQ BIT(6)
> +#define CTRL4_PICO_OGDISABLE BIT(8)
> +#define CTRL4_PICO_VBUSVLDEXTBIT(10)
> +#define CTRL4_PICO_VBUSVLDEXTSEL BIT(11)
> +#define CTRL4_OTG_PHY_SELBIT(21)
> +
> +#define SC_PERIPH_CTRL5  0x010
> +
> +#define CTRL5_USBOTG_RES_SEL BIT(3)
> +#define CTRL5_PICOPHY_ACAENB BIT(4)
> +#define CTRL5_PICOPHY_BC_MODEBIT(5)
> +#define CTRL5_PICOPHY_CHRGSELBIT(6)
> +#define CTRL5_PICOPHY_VDATSRCEND BIT(7)
> +#define CTRL5_PICOPHY_VDATDETENB BIT(8)
> +#define CTRL5_PICOPHY_DCDENB BIT(9)
> +#define CTRL5_PICOPHY_IDDIG  BIT(10)
> +
> +#define SC_PERIPH_CTRL8  0x018
> +#define SC_PERIPH_RSTEN0 0x300
> +#define SC_PERIPH_RSTDIS00x304
> +
> +#define RST0_USBOTG_BUS  BIT(4)
> +#define RST0_POR_PICOPHY BIT(5)
> +#define RST0_USBOTG  BIT(6)
> +#define RST0_USBOTG_32K  BIT(7)
> +
> +#define EYE_PATTERN_PARA 0x7053348c
> +
> +struct hi6220_priv {
> + struct regmap *reg;
> + struct device *dev;
> +};
> +
> +static void hi6220_phy_init(struct hi6220_priv *priv)
> +{
> + struct regmap *reg = priv->reg;
> + u32 val, mask;
> +
> + val = RST0_USBOTG_BUS | RST0_POR_PICOPHY |
> +   RST0_USBOTG | RST0_USBOTG_32K;
> + mask = val;
> + regmap_update_bits(reg, SC_PERIPH_RSTEN0, 

Re: [PATCH] usb: dwc2: add support of hi6220

2015-11-18 Thread Rob Herring
On Wed, Nov 18, 2015 at 03:39:47PM +0800, Zhangfei Gao wrote:
> Support hisilicon,hi6220-usb for HiKey board
> 
> Signed-off-by: Zhangfei Gao 
> ---
>  Documentation/devicetree/bindings/usb/dwc2.txt |  1 +

For the binding:

Acked-by: Rob Herring 

>  drivers/usb/dwc2/platform.c| 32 
> ++
>  2 files changed, 33 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt 
> b/Documentation/devicetree/bindings/usb/dwc2.txt
> index fd132cb..2213682 100644
> --- a/Documentation/devicetree/bindings/usb/dwc2.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc2.txt
> @@ -4,6 +4,7 @@ Platform DesignWare HS OTG USB 2.0 controller
>  Required properties:
>  - compatible : One of:
>- brcm,bcm2835-usb: The DWC2 USB controller instance in the BCM2835 SoC.
> +  - hisilicon,hi6220-usb: The DWC2 USB controller instance in the hi6220 SoC.
>- rockchip,rk3066-usb: The DWC2 USB controller instance in the rk3066 Soc;
>- "rockchip,rk3188-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3188 
> Soc;
>- "rockchip,rk3288-usb", "rockchip,rk3066-usb", "snps,dwc2": for rk3288 
> Soc;
> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> index 5859b0f..a5cb1bf 100644
> --- a/drivers/usb/dwc2/platform.c
> +++ b/drivers/usb/dwc2/platform.c
> @@ -54,6 +54,37 @@
>  
>  static const char dwc2_driver_name[] = "dwc2";
>  
> +static const struct dwc2_core_params params_hi6220 = {
> + .otg_cap= 2,/* No HNP/SRP capable */
> + .otg_ver= 0,/* 1.3 */
> + .dma_enable = 1,
> + .dma_desc_enable= 0,
> + .speed  = 0,/* High Speed */
> + .enable_dynamic_fifo= 1,
> + .en_multiple_tx_fifo= 1,
> + .host_rx_fifo_size  = 512,
> + .host_nperio_tx_fifo_size   = 512,
> + .host_perio_tx_fifo_size= 512,
> + .max_transfer_size  = 65535,
> + .max_packet_count   = 511,
> + .host_channels  = 16,
> + .phy_type   = 1,/* UTMI */
> + .phy_utmi_width = 8,
> + .phy_ulpi_ddr   = 0,/* Single */
> + .phy_ulpi_ext_vbus  = 0,
> + .i2c_enable = 0,
> + .ulpi_fs_ls = 0,
> + .host_support_fs_ls_low_power   = 0,
> + .host_ls_low_power_phy_clk  = 0,/* 48 MHz */
> + .ts_dline   = 0,
> + .reload_ctl = 0,
> + .ahbcfg = GAHBCFG_HBSTLEN_INCR16 <<
> +   GAHBCFG_HBSTLEN_SHIFT,
> + .uframe_sched   = 0,
> + .external_id_pin_ctl= -1,
> + .hibernation= -1,
> +};
> +
>  static const struct dwc2_core_params params_bcm2835 = {
>   .otg_cap= 0,/* HNP/SRP capable */
>   .otg_ver= 0,/* 1.3 */
> @@ -282,6 +313,7 @@ static int dwc2_driver_remove(struct platform_device *dev)
>  
>  static const struct of_device_id dwc2_of_match_table[] = {
>   { .compatible = "brcm,bcm2835-usb", .data = ¶ms_bcm2835 },
> + { .compatible = "hisilicon,hi6220-usb", .data = ¶ms_hi6220 },
>   { .compatible = "rockchip,rk3066-usb", .data = ¶ms_rk3066 },
>   { .compatible = "snps,dwc2", .data = NULL },
>   { .compatible = "samsung,s3c6400-hsotg", .data = NULL},
> -- 
> 1.9.1
> 
> --
> 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
--
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


Re: [PATCH 1/2] usb: doc: dwc3-xilinx: Add devicetree bindings

2015-11-18 Thread Felipe Balbi

Hi,

Rob Herring  writes:
> On Wed, Nov 18, 2015 at 06:20:31PM +0530, Subbaraya Sundeep Bhatta wrote:
>> This patch adds binding doc for Xilinx DWC3 glue driver.
>> 
>> Signed-off-by: Subbaraya Sundeep Bhatta 
>
> I really dislike how the DWC3 binding has been done. The sub-node here 
> is pointless. The only thing the outer node does is add clocks which 
> should simply be part of the DWC3 node. Presumably the IP block needs 
> some clocks...
>
> Anyway, it's self-contained within the DWC3, so I won't make you clean 
> up the mess.

heh, it's definitely not pointless. We get a lot of free goodies by
doing it that way. I'm just not going to repeat it once again. But in
summary:

a) we force people to write glue layers for *only* their HW specific
details

b) there's really no way to abuse dwc3 core because there's no symbol
exported from dwc3 core to glue

c) PM (both system sleep and runtime) becomes a lot simpler with core
only caring about what PM details delivered by SNPS (e.g. Hibernation
mode from DWC3) and glue only has to consider the SoC integration parts
of PM (for OMAP that would be PRCM details, hwmod, etc).

I'm definitely not going to change dwc3 because it has made my life a
lot saner. Definitely a lot saner than MUSB. Besides, DTS is supposed to
describe the HW and that's, really, how the HW is.

There's a piece of HW which is somewhat platform agnostic and delivered
by SNPS as a black box (SNPS customers don't touch SNPS RTL) and there's
another piece of HW which bridges this dwc3 to the platform specific
details and integration context of the platform (for OMAP that would the
SYSCONFIG/SYSSTATUS registers, Clock autogating, PRCM, etc, etc etc).

So you _do_ in fact, have two separate pieces of HW which are SW visible
and controllable independently. They each have their own IRQs (though in
some SoCs they share the same line), they're own address space, yada
yada yada.

cheers

-- 
balbi


signature.asc
Description: PGP signature


Re: [PATCH v3 2/5] dt-bindings: soc: add document for rockchip reboot notifier driver

2015-11-18 Thread Rob Herring
On Wed, Nov 18, 2015 at 05:53:30PM +0800, Andy Yan wrote:
> Add devicetree binding document for rockchip reboot nofifier driver

Just reading the subject this is way too specific to the Linux driver 
needs rather than a h/w description. Please don't create fake DT nodes 
just to bind to drivers. Whatever &pmu is is probably what should have 
the DT node. Let the driver for it create child devices if you need 
that.

Rob
> 
> Signed-off-by: Andy Yan 
> 
> ---
> 
> Changes in v3:
>  - add dt binding
> 
> Changes in v2: None
> 
>  .../bindings/soc/rockchip/rockchip-reboot.txt  | 18 
> ++
>  1 file changed, 18 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/soc/rockchip/rockchip-reboot.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/soc/rockchip/rockchip-reboot.txt 
> b/Documentation/devicetree/bindings/soc/rockchip/rockchip-reboot.txt
> new file mode 100644
> index 000..6f69c8d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/rockchip/rockchip-reboot.txt
> @@ -0,0 +1,18 @@
> +Rockchip reboot notifier driver
> +
> +This driver get reboot mode arguments from userspace
> +and stores it in special register. Then the bootloader
> +will read it and take different action according the
> +argument stored.
> +
> +Required properties:
> +- compatible: should be "rockchip,reboot"
> +- regmap: this is phandle to the register map node
> +- offset: offset in the register map for the storage register (in bytes)
> +
> +Examples:
> + reboot {
> +compatible = "rockchip,reboot";
> +regmap = <&pmu>;
> +offset = <0x94>;
> + };
> -- 
> 1.9.1
> 
> 
--
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


Re: [PATCH 1/2] usb: doc: dwc3-xilinx: Add devicetree bindings

2015-11-18 Thread Rob Herring
On Wed, Nov 18, 2015 at 06:20:31PM +0530, Subbaraya Sundeep Bhatta wrote:
> This patch adds binding doc for Xilinx DWC3 glue driver.
> 
> Signed-off-by: Subbaraya Sundeep Bhatta 

I really dislike how the DWC3 binding has been done. The sub-node here 
is pointless. The only thing the outer node does is add clocks which 
should simply be part of the DWC3 node. Presumably the IP block needs 
some clocks...

Anyway, it's self-contained within the DWC3, so I won't make you clean 
up the mess.

Acked-by: Rob Herring 

> ---
>  .../devicetree/bindings/usb/dwc3-xilinx.txt| 33 
> ++
>  1 file changed, 33 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/dwc3-xilinx.txt
> 
> diff --git a/Documentation/devicetree/bindings/usb/dwc3-xilinx.txt 
> b/Documentation/devicetree/bindings/usb/dwc3-xilinx.txt
> new file mode 100644
> index 000..30361b3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/dwc3-xilinx.txt
> @@ -0,0 +1,33 @@
> +Xilinx SuperSpeed DWC3 USB SoC controller
> +
> +Required properties:
> +- compatible:Should contain "xlnx,zynqmp-dwc3"
> +- clocks:A list of phandles for the clocks listed in clock-names
> +- clock-names:   Should contain the following:
> +  "bus_clk"   Master/Core clock, have to be >= 125 MHz for SS
> +  operation and >= 60MHz for HS operation
> +
> +  "ref_clk"   Clock source to core during PHY power down
> +
> +Required child node:
> +A child node must exist to represent the core DWC3 IP block. The name of
> +the node is not important. The content of the node is defined in dwc3.txt.
> +
> +Example device node:
> +
> + usb@0 {
> + #address-cells = <0x2>;
> + #size-cells = <0x1>;
> + status = "okay";
> + compatible = "xlnx,zynqmp-dwc3";
> + clock-names = "bus_clk" "ref_clk";
> + clocks = <&clk125>, <&clk125>;
> + ranges;
> +
> + dwc3@fe20 {
> + compatible = "snps,dwc3";
> + reg = <0x0 0xfe20 0x4>;
> + interrupts = <0x0 0x41 0x4>;
> + dr_mode = "host";
> + };
> + };
> -- 
> 2.1.2
> 
> --
> 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
--
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


Re: [PATCH] clk: add generic driver for fixed rate clock

2015-11-18 Thread Geert Uytterhoeven
Hi Stephen,

On Wed, Nov 18, 2015 at 9:34 PM, Stephen Boyd  wrote:
> On 11/17, Geert Uytterhoeven wrote:
>> (quoting the full driver, as it predates linux-clk)
>>
>> On Sun, Sep 1, 2013 at 6:40 AM, Stefan Kristiansson
>>  wrote:
>> > This adds a simple driver with the only purpose to initialise
>> > the fixed rate clock.
>> > This is useful for systems that do not wish to use seperate init
>> > code for the fixed rate clock init, but rather only rely on a
>> > device tree description of it.
>> >
>> > Signed-off-by: Stefan Kristiansson 
>>
>> Thanks, this is still very useful!
>>
>> I stumbled across this old patch while trying to instantiate a fixed rate
>> clock from a DT overlay.
>> Without this, the clock is never instantiated, as 
>> drivers/clk/clk-fixed-rate.c
>> uses CLK_OF_DECLARE() :-( With your driver, it works as expected
>> (after fixing the modpost complaint, cfr. below).
>>
>> However, I think that instead of creating a new driver, you should just add
>> the meat of clk-generic-fixed.c to clk-fixed-rate.c.
>
> Hm... what happens when of_clk_init() runs and instantiates the
> clock, and then of_platform_populate() runs and creates the clock
> again? The platform device probe fails because the framework
> checks to make sure two clocks don't have the same name? I guess
> that's going to work, but it doesn't make me feel good.

My DTS does have other clocks that are compatible with "fixed-clock"
and I didn't notice any ill behavior. Perhaps the driver core knows the
node has already been bound to something, and thus no longer tries
to bind it to a platform driver?

I'll double-check that later...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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


Re: [PATCH v10 6/8] Input: goodix - add support for ESD

2015-11-18 Thread Rob Herring
On Wed, Nov 18, 2015 at 06:31:39PM +0200, Irina Tirdea wrote:
> Add ESD (Electrostatic Discharge) protection mechanism.
> 
> The driver enables ESD protection in HW and checks a register
> to determine if ESD occurred. If ESD is signalled by the HW,
> the driver will reset the device.
> 
> The ESD poll time (in ms) can be set through the sysfs property
> esd_timeout. If it is set to 0, ESD protection is disabled.
> Recommended value is 2000 ms. The initial value for ESD timeout
> can be set through esd-recovery-timeout-ms ACPI/DT property.
> If there is no such property defined, ESD protection is disabled.
> For ACPI 5.1, the property can be specified using _DSD properties:
>  Device (STAC)
>  {
>  Name (_HID, "GDIX1001")
>  ...
> 
>  Name (_DSD,  Package ()
>  {
>  ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>  Package ()
>  {
>  Package (2) { "esd-recovery-timeout-ms", Package(1) { 2000 }},
>  ...
>  }
>  })
>  }
> 
> The ESD protection mechanism is only available if the gpio pins
> are properly initialized from ACPI/DT.
> 
> This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
> driver gt9xx.c for Android (publicly available in Android kernel
> trees for various devices).
> 
> Signed-off-by: Irina Tirdea 
> ---
>  .../bindings/input/touchscreen/goodix.txt  |   6 +

For the binding:

Acked-by: Rob Herring 

>  drivers/input/touchscreen/goodix.c | 160 
> -
>  2 files changed, 161 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt 
> b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> index 7137881..4db3393 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> @@ -14,6 +14,12 @@ Required properties:
>   - interrupts: Interrupt to which the chip is connected
>   - irq-gpio  : GPIO pin used for IRQ
>   - reset-gpio: GPIO pin used for reset
> +Optional properties:
> +
> + - esd-recovery-timeout-ms : ESD poll time (in milli seconds) for the driver 
> to
> +check if ESD occurred and in that case reset the
> +device. ESD is disabled if this property is not 
> set
> +or is set to 0.
>  
>  Example:
>  
--
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


Re: [PATCH v10 2/8] Input: goodix - reset device at init

2015-11-18 Thread Rob Herring
On Wed, Nov 18, 2015 at 06:31:35PM +0200, Irina Tirdea wrote:
> After power on, it is recommended that the driver resets the device.
> The reset procedure timing is described in the datasheet and is used
> at device init (before writing device configuration) and
> for power management. It is a sequence of setting the interrupt
> and reset pins high/low at specific timing intervals. This procedure
> also includes setting the slave address to the one specified in the
> ACPI/device tree.
> 
> This is based on Goodix datasheets for GT911 and GT9271 and on Goodix
> driver gt9xx.c for Android (publicly available in Android kernel
> trees for various devices).
> 
> For reset the driver needs to control the interrupt and
> reset gpio pins (configured through ACPI/device tree). For devices
> that do not have the gpio pins properly declared, the functionality
> depending on these pins will not be available, but the device can still
> be used with basic functionality.
> 
> For both device tree and ACPI, the interrupt gpio pin configuration is
> read from the "irq-gpio" property and the reset pin configuration is
> read from the "reset-gpio" property. For ACPI 5.1, named properties
> can be specified using the _DSD section. This functionality will not be
> available for devices that use indexed gpio pins declared in the _CRS
> section (we need to provide backward compatibility with devices
> that do not support using the interrupt gpio pin as output).
> 
> For ACPI, the pins can be specified using ACPI 5.1:
> Device (STAC)
> {
> Name (_HID, "GDIX1001")
> ...
> 
> Method (_CRS, 0, Serialized)
> {
> Name (RBUF, ResourceTemplate ()
> {
> I2cSerialBus (0x0014, ControllerInitiated, 0x00061A80,
> AddressingMode7Bit, "\\I2C0",
> 0x00, ResourceConsumer, ,
> )
> 
> GpioInt (Edge, ActiveHigh, Exclusive, PullNone, 0x,
> "\\I2C0", 0x00, ResourceConsumer, ,
>  )
>  {   // Pin list
>  0
>  }
> 
> GpioIo (Exclusive, PullDown, 0x, 0x,
> IoRestrictionOutputOnly, "\\I2C0", 0x00,
> ResourceConsumer, ,
> )
> {
>  1
> }
> })
> Return (RBUF)
> }
> 
> Name (_DSD,  Package ()
> {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package ()
> {
> Package (2) {"irq-gpio", Package() {^STAC, 0, 0, 0 }},
> Package (2) {"reset-gpio", Package() {^STAC, 1, 0, 0 }},
> ...
> }
> }
> 
> Signed-off-by: Octavian Purdila 
> Signed-off-by: Irina Tirdea 
> ---
>  .../bindings/input/touchscreen/goodix.txt  |   5 +
>  drivers/input/touchscreen/Kconfig  |   1 +
>  drivers/input/touchscreen/goodix.c | 101 
> +
>  3 files changed, 107 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt 
> b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> index 8ba98ee..7137881 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
> @@ -12,6 +12,8 @@ Required properties:
>   - reg   : I2C address of the chip. Should be 0x5d or 
> 0x14
>   - interrupt-parent  : Interrupt controller to which the chip is connected
>   - interrupts: Interrupt to which the chip is connected
> + - irq-gpio  : GPIO pin used for IRQ

Please note here why you need this in addition to just "interrupts". 
Also, it should be irq-gpios instead.

> + - reset-gpio: GPIO pin used for reset

Should be reset-gpios instead.

Rob
--
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


Re: [PATCH 1/2] Add binding documentation for Zodiac Watchdog Timer

2015-11-18 Thread Rob Herring
On Wed, Nov 18, 2015 at 04:38:50PM +, Martyn Welch wrote:
> This patchs adds documentation for the binding of the Zodiac RAVE
> Switch Watchdog Processor. This is an i2c based watchdog.
> 
> Cc: Rob Herring 
> Cc: Pawel Moll 
> Cc: Mark Rutland 
> Cc: Ian Campbell 
> Cc: Kumar Gala 
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Martyn Welch 

You could document this under trivial-devices.txt, but this is fine too.

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/watchdog/ziirave-wdt.txt | 12 
>  1 file changed, 12 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/watchdog/ziirave-wdt.txt
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/ziirave-wdt.txt 
> b/Documentation/devicetree/bindings/watchdog/ziirave-wdt.txt
> new file mode 100644
> index 000..2f34157
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/ziirave-wdt.txt
> @@ -0,0 +1,12 @@
> +Zodiac RAVE Watchdog Timer
> +
> +Required properties:
> +- compatible: must be "zii,rave-wdt"
> +- reg: i2c slave address of device, usually 0x38
> +
> +Example:
> +
> + watchdog@38 {
> + compatible = "zii,rave-wdt";
> + reg = <0x38>;
> + };
> -- 
> 2.1.4
> 
> --
> 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
--
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


Re: [PATCH v2 1/2] devicetree: watchdog: add binding for Sigma Designs SMP8642 watchdog

2015-11-18 Thread Rob Herring
On Wed, Nov 18, 2015 at 05:55:42PM +, Mans Rullgard wrote:
> This adds a binding for the watchdog in Sigma Designs SMP8642 and
> similar devices.
> 
> Signed-off-by: Mans Rullgard 

Acked-by: Rob Herring 

> ---
> Changes:
> - add timeout-sec property
> ---
>  .../devicetree/bindings/watchdog/sigma,smp8642-wdt.txt | 18 
> ++
>  1 file changed, 18 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/watchdog/sigma,smp8642-wdt.txt
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/sigma,smp8642-wdt.txt 
> b/Documentation/devicetree/bindings/watchdog/sigma,smp8642-wdt.txt
> new file mode 100644
> index 000..5b7ec2c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/sigma,smp8642-wdt.txt
> @@ -0,0 +1,18 @@
> +Sigma Designs SMP86xx/SMP87xx watchdog
> +
> +Required properties:
> +- compatible: Should be "sigma,smp8642-wdt"
> +- reg: Specifies the physical address region
> +- clocks: Should be a phandle to the clock
> +
> +Optional properties:
> +- timeout-sec: watchdog timeout in seconds
> +
> +Example:
> +
> +watchdog@1fd00 {
> + compatible = "sigma,smp8642-wdt";
> + reg = <0x1fd00 8>;
> + clocks = <&xtal_in_clk>;
> + timeout-sec = <30>;
> +};
> -- 
> 2.6.3
> 
--
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


Re: [PATCH v7 1/5] Documentation: tps65912: Add DT bindings for the TPS65912 PMIC

2015-11-18 Thread Rob Herring
On Wed, Nov 18, 2015 at 11:59:36AM -0600, Andrew F. Davis wrote:
> The TPS65912 PMIC contains several regulators and a GPIO controller.
> Add bindings for the TPS65912 PMIC.
> 
> Signed-off-by: Andrew F. Davis 

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/mfd/tps65912.txt | 50 
> ++
>  1 file changed, 50 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/tps65912.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/tps65912.txt 
> b/Documentation/devicetree/bindings/mfd/tps65912.txt
> new file mode 100644
> index 000..717e66d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/tps65912.txt
> @@ -0,0 +1,50 @@
> +* TPS65912 Power Management Integrated Circuit bindings
> +
> +Required properties:
> + - compatible: Should be "ti,tps65912".
> + - reg   : Slave address or chip select number (I2C / 
> SPI).
> + - interrupt-parent  : The parent interrupt controller.
> + - interrupts: The interrupt line the device is connected to.
> + - interrupt-controller  : Marks the device node as an interrupt 
> controller.
> + - #interrupt-cells  : The number of cells to describe an IRQ, should be 2.
> + The first cell is the IRQ number.
> + The second cell is the flags, encoded as trigger
> + masks from ../interrupt-controller/interrupts.txt.
> + - gpio-controller   : Marks the device node as a GPIO Controller.
> + - #gpio-cells   : Should be two.  The first cell is the pin 
> number and
> + the second cell is used to specify flags.
> + See ../gpio/gpio.txt for more information.
> + - regulators:   : List of child nodes that specify the regulator
> + initialization data. Child nodes must be named
> + after their hardware counterparts: dcdc[1-4] and
> + ldo[1-10]. Each child nodes is defined using the
> + standard binding for regulators.
> +
> +Example:
> +
> + pmic: tps65912@2d {
> + compatible = "ti,tps65912";
> + reg = <0x2d>;
> + interrupt-parent = <&gpio1>;
> + interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + gpio-controller;
> + #gpio-cells = <2>;
> +
> + regulators {
> + dcdc1 {
> + regulator-name = "vdd_core";
> + regulator-min-microvolt = <912000>;
> + regulator-max-microvolt = <1144000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + ldo1 {
> + regulator-name = "ldo1";
> + regulator-min-microvolt = <190>;
> + regulator-max-microvolt = <190>;
> + };
> + };
> + };
> -- 
> 1.9.1
> 
--
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


[PATCH] thermal: Add support for Sunxi THS on the Allwinner H3

2015-11-18 Thread Josef Gajdusek
This patch adds support for the Sunxi thermal sensor on the Allwinner H3.
Also adds declaration of the H3 THS clock to clk-sunxi.c ignoring the
dividers as they are not continuous (clk-divider.c cannot be used as it
does not support setting an enable bit).
Should be easily extendable for the A33/A83T/... as they have similar but
not completely identical sensors.

Signed-off-by: Josef Gajdusek 
---
 Documentation/devicetree/bindings/clock/sunxi.txt  |   1 +
 .../devicetree/bindings/thermal/sunxi-ths.txt  |  24 ++
 arch/arm/boot/dts/sun8i-h3.dtsi|  27 +++
 drivers/clk/sunxi/clk-sunxi.c  |  16 ++
 drivers/thermal/Kconfig|   7 +
 drivers/thermal/Makefile   |   1 +
 drivers/thermal/sunxi_ths.c| 263 +
 7 files changed, 339 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/thermal/sunxi-ths.txt
 create mode 100644 drivers/thermal/sunxi_ths.c

diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt 
b/Documentation/devicetree/bindings/clock/sunxi.txt
index 23e7bce..6d63b35 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -73,6 +73,7 @@ Required properties:
"allwinner,sun8i-h3-usb-clk" - for usb gates + resets on H3
"allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80
"allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
+   "allwinner,sun8i-h3-ths-clk" - for THS on H3
 
 Required properties for all clocks:
 - reg : shall be the control register address for the clock.
diff --git a/Documentation/devicetree/bindings/thermal/sunxi-ths.txt 
b/Documentation/devicetree/bindings/thermal/sunxi-ths.txt
new file mode 100644
index 000..75c9211
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/sunxi-ths.txt
@@ -0,0 +1,24 @@
+* sunxi THS
+
+Required properties:
+- compatible : "allwinner,sun8i-h3-ths"
+- reg : Address range of the thermal registers and location of the calibration
+value
+- resets : Must contain an entry for each entry in reset-names.
+   see ../reset/reset.txt for details
+- reset-names : Must include the name "ahb"
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : Must contain "ahb" for the bus gate and "ths" for the THS
+  clock
+
+Example:
+ths: ths@01c25000 {
+   #thermal-sensor-cells = <0>;
+   compatible = "allwinner,sun8i-h3-ths";
+   reg = <0x01c25000 0x88>, <0x01c14234 0x4>;
+   interrupts = ;
+   resets = <&bus_rst 136>;
+   reset-names = "ahb";
+   clocks = <&bus_gates 72>, <&ths_clk>;
+   clock-names = "ahb", "ths";
+};
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 0faa38a..b82881d 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -77,6 +77,14 @@
};
};
 
+   thermal-zones {
+   cpu_thermal: cpu_thermal {
+   polling-delay-passive = <1000>;
+   polling-delay = <5000>;
+   thermal-sensors = <&ths 0>;
+   };
+   };
+
timer {
compatible = "arm,armv7-timer";
interrupts = ,
@@ -236,6 +244,14 @@
"ahb1_ephy", "ahb1_dbg";
};
 
+   ths_clk: clk@01c20074 {
+   #clock-cells = <0>;
+   compatible = "allwinner,sun8i-h3-ths-clk";
+   reg = <0x01c20074 0x4>;
+   clocks = <&osc24M>;
+   clock-output-names = "ths";
+   };
+
mmc0_clk: clk@01c20088 {
#clock-cells = <1>;
compatible = "allwinner,sun4i-a10-mmc-clk";
@@ -522,6 +538,17 @@
interrupts = ;
};
 
+   ths: ths@01c25000 {
+   #thermal-sensor-cells = <0>;
+   compatible = "allwinner,sun8i-h3-ths";
+   reg = <0x01c25000 0x88>, <0x01c14234 0x4>;
+   interrupts = ;
+   resets = <&bus_rst 104>;
+   reset-names = "ahb";
+   clocks = <&bus_gates 72>, <&ths_clk>;
+   clock-names = "ahb", "ths";
+   };
+
uart0: serial@01c28000 {
compatible = "snps,dw-apb-uart";
reg = <0x01c28000 0x400>;
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 6293c65..637401a 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -604,6 +604,13 @@ static void sun7i_a20_get_out_factors(u32 *freq, u32 
parent_rate,
*p = calcp;
 }
 
+static void sun8i_h3_get_ths_factors(u32 *freq, u32 parent_rate,
+

[PATCH] drm/panel: simple: Add support for G121X1-L03

2015-11-18 Thread Akshay Bhat
Add support for Innolux CheMei 12" G121X1-L03 XGA LVDS display.

Datasheet: http://www.azdisplays.com/PDF/G121X1-L03.pdf
Signed-off-by: Akshay Bhat 
---
 .../bindings/display/panel/innolux,g121x1-l03.txt  |  7 +
 drivers/gpu/drm/panel/panel-simple.c   | 31 ++
 2 files changed, 38 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/innolux,g121x1-l03.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/innolux,g121x1-l03.txt 
b/Documentation/devicetree/bindings/display/panel/innolux,g121x1-l03.txt
new file mode 100644
index 000..6497446
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/innolux,g121x1-l03.txt
@@ -0,0 +1,7 @@
+Innolux Corporation 12.1" G121X1-L03 XGA (1024x768) TFT LCD panel
+
+Required properties:
+- compatible: should be "innolux,g121x1-l03"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index f97b73e..d1821f7 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -832,6 +832,34 @@ static const struct panel_desc innolux_g121i1_l01 = {
},
 };
 
+static const struct drm_display_mode innolux_g121x1_l03_mode = {
+   .clock = 65000,
+   .hdisplay = 1024,
+   .hsync_start = 1024 + 0,
+   .hsync_end = 1024 + 1,
+   .htotal = 1024 + 0 + 1 + 320,
+   .vdisplay = 768,
+   .vsync_start = 768 + 38,
+   .vsync_end = 768 + 38 + 1,
+   .vtotal = 768 + 38 + 1 + 0,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc innolux_g121x1_l03 = {
+   .modes = &innolux_g121x1_l03_mode,
+   .num_modes = 1,
+   .bpc = 6,
+   .size = {
+   .width = 246,
+   .height = 185,
+   },
+   .delay = {
+   .enable = 200,
+   .unprepare = 200,
+   .disable = 400,
+   },
+};
+
 static const struct drm_display_mode innolux_n116bge_mode = {
.clock = 76420,
.hdisplay = 1366,
@@ -1158,6 +1186,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible ="innolux,g121i1-l01",
.data = &innolux_g121i1_l01
}, {
+   .compatible = "innolux,g121x1-l03",
+   .data = &innolux_g121x1_l03,
+   }, {
.compatible = "innolux,n116bge",
.data = &innolux_n116bge,
}, {
-- 
2.6.3

--
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


Re: Re: [Qemu-devel] [PATCH v4 4/4] devicetree: update documentation for fw_cfg ARM bindings

2015-11-18 Thread Gabriel L. Somlo
On Wed, Nov 18, 2015 at 02:04:24PM +0100, François Revol wrote:
> On 17/11/2015 23:14, Rob Herring wrote:
> > On Mon, Nov 16, 2015 at 2:38 AM, Paolo Bonzini  wrote:
> >>
> >>
> >> On 15/11/2015 03:07, Rob Herring wrote:
> >>> We generally don't want DT docs to depend on other kernel documentation.
> >>
> >> DT docs do not contain a copy of the data sheets, either.  There is no
> >> reason to say how to use the device (and even then, only doing so
> >> partially) in the DT docs.
> > 
> > The difference is datasheets apply to all OS's, kernel documentation
> > does not. In theory at least this could be used for other OS's, right?
> 
> Would be nice indeed, as it's part of their intended purpose.
> 
> For now we have to shoehorn things into linux-only stuff (like initrd)
> because well, nobody cares enough about NetBSD to compile U-Boot with
> its internal API, so let alone adding custom Haiku code.
> 
> And of course, for things linux doesn't care about (like framebuffer
> description) then we're stuck trying to guess where it's at and writing
> drivers for our bootloader.
> 
> So if at least people were considering they aren't the only users of
> this, that'd make life better for everyone.
> 
> > Perhaps QEMU is the right place to thoroughly describe this and DT and
> > sysfs docs can refer to it.
> 
> The brilliant idea of FDT was that we could have a canonical source and
> blob for it where people could send patches, but of course Linux and BSD
> freaks disagreed, so you now find Linux-flavoured DTs for rPi and other
> things, as well as BSD versions.
> 
> Please, at least get the binding documentation for this unique and
> usable for everyone!

That would be 'docs/specs/fw_cfg.txt' in the QEMU source tree. I will
avoid cut'n'pasting anything from there into either the proposed
Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg (leaving only the
sysfs specific bits in there), and also remove any redundant bits from
Documentation/devicetree/bindings/arm/fw-cfg.txt.

I'm inclined to add (in v5) a mention of 'qemu:docs/specs/fw_cfg.txt'
to both the proposed fw_cfg sysfs doc file, and to the existing fw_cfg
arm/dt node doc file, unless I get strong objections against doing so... :)

Thanks,
--Gabriel
--
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


Re: [PATCH 0/2] VIN, ADV7180 for r8a7794/alt

2015-11-18 Thread Simon Horman
On Wed, Nov 18, 2015 at 01:51:05PM +0100, Ulrich Hecht wrote:
> Hi!
> 
> This series adds VIN support for the Alt board.  The hardware configuration
> for I2C1 and the video decoder of Alt is exactly identical to that of Silk,
> so these are largely identical to Sergei's Silk definitions.
> 
> To be applied on top of Horms's "ARM: shmobile: alt: Add pfc pins to DT"
> patch.

Thanks, I have queued-up this series on top of the patch mentioned above.
--
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


[Patch v5 1/2] media: v4l: ti-vpe: Add CAL v4l2 camera capture driver

2015-11-18 Thread Benoit Parrot
The Camera Adaptation Layer (CAL) is a block which consists of a dual
port CSI2/MIPI camera capture engine.
Port #0 can handle CSI2 camera connected to up to 4 data lanes.
Port #1 can handle CSI2 camera connected to up to 2 data lanes.
The driver implements the required API/ioctls to be V4L2 compliant.
Driver supports the following:
- V4L2 API using DMABUF/MMAP buffer access based on videobuf2 api
- Asynchronous sensor sub device registration

Signed-off-by: Benoit Parrot 
Signed-off-by: Hans Verkuil 
---
 drivers/media/platform/Kconfig   |   12 +
 drivers/media/platform/Makefile  |2 +
 drivers/media/platform/ti-vpe/Makefile   |4 +
 drivers/media/platform/ti-vpe/cal.c  | 2143 ++
 drivers/media/platform/ti-vpe/cal_regs.h |  779 +++
 5 files changed, 2940 insertions(+)
 create mode 100644 drivers/media/platform/ti-vpe/cal.c
 create mode 100644 drivers/media/platform/ti-vpe/cal_regs.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 0c53805dff0e..db052f5a627a 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -120,6 +120,18 @@ source "drivers/media/platform/s5p-tv/Kconfig"
 source "drivers/media/platform/am437x/Kconfig"
 source "drivers/media/platform/xilinx/Kconfig"
 
+config VIDEO_TI_CAL
+   tristate "TI CAL (Camera Adaptation Layer) driver"
+   depends on VIDEO_DEV && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
+   depends on SOC_DRA7XX || COMPILE_TEST
+   select VIDEOBUF2_DMA_CONTIG
+   default n
+   ---help---
+ Support for the TI CAL (Camera Adaptation Layer) block
+ found on DRA72X SoC.
+ In TI Technical Reference Manual this module is referred as
+ Camera Interface Subsystem (CAMSS).
+
 endif # V4L_PLATFORM_DRIVERS
 
 menuconfig V4L_MEM2MEM_DRIVERS
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index efa0295af87b..028a7233096b 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -18,6 +18,8 @@ obj-$(CONFIG_VIDEO_VIM2M) += vim2m.o
 
 obj-$(CONFIG_VIDEO_TI_VPE) += ti-vpe/
 
+obj-$(CONFIG_VIDEO_TI_CAL) += ti-vpe/
+
 obj-$(CONFIG_VIDEO_MX2_EMMAPRP)+= mx2_emmaprp.o
 obj-$(CONFIG_VIDEO_CODA)   += coda/
 
diff --git a/drivers/media/platform/ti-vpe/Makefile 
b/drivers/media/platform/ti-vpe/Makefile
index be680f839e77..e236059a60ad 100644
--- a/drivers/media/platform/ti-vpe/Makefile
+++ b/drivers/media/platform/ti-vpe/Makefile
@@ -3,3 +3,7 @@ obj-$(CONFIG_VIDEO_TI_VPE) += ti-vpe.o
 ti-vpe-y := vpe.o sc.o csc.o vpdma.o
 
 ccflags-$(CONFIG_VIDEO_TI_VPE_DEBUG) += -DDEBUG
+
+obj-$(CONFIG_VIDEO_TI_CAL) += ti-cal.o
+
+ti-cal-y := cal.o
diff --git a/drivers/media/platform/ti-vpe/cal.c 
b/drivers/media/platform/ti-vpe/cal.c
new file mode 100644
index ..61cd5b9bd8f6
--- /dev/null
+++ b/drivers/media/platform/ti-vpe/cal.c
@@ -0,0 +1,2143 @@
+/*
+ * TI CAL camera interface driver
+ *
+ * Copyright (c) 2015 Texas Instruments Inc.
+ * Benoit Parrot, 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "cal_regs.h"
+
+#define CAL_MODULE_NAME "cal"
+
+#define MAX_WIDTH 1920
+#define MAX_HEIGHT 1200
+
+#define CAL_VERSION "0.1.0"
+
+MODULE_DESCRIPTION("TI CAL driver");
+MODULE_AUTHOR("Benoit Parrot, ");
+MODULE_LICENSE("GPL v2");
+MODULE_VERSION(CAL_VERSION);
+
+static unsigned video_nr = -1;
+module_param(video_nr, uint, 0644);
+MODULE_PARM_DESC(video_nr, "videoX start number, -1 is autodetect");
+
+static unsigned debug;
+module_param(debug, uint, 0644);
+MODULE_PARM_DESC(debug, "activates debug info");
+
+/* timeperframe: min/max and default */
+static const struct v4l2_fract
+   tpf_default = {.numerator = 1001,   .denominator = 3};
+
+#define cal_dbg(level, caldev, fmt, arg...)\
+   v4l2_dbg(level, debug, &caldev->v4l2_dev, fmt, ##arg)
+#define cal_info(caldev, fmt, arg...)  \
+   v4l2_info(&caldev->v4l2_dev, fmt, ##arg)
+#define cal_err(caldev, fmt, arg...)   \
+   v4l2_err(&caldev->v4l2_dev, fmt, ##arg)
+
+#define ctx_dbg(level, ctx, fmt, arg...)   \
+   v4l2_dbg(level, debug, &ctx->v4l2_dev, fmt, ##arg)
+#define ctx_info(ctx, fmt, arg...) \
+   v4l2_info(&ctx->v4l2_dev, fmt, ##arg)
+#define ctx_err(ctx, fmt, arg...)  \
+   v4l2_err(&ctx->v4l2_dev, fmt, ##arg)
+
+#define CAL_NUM_INPUT 1
+#define CAL_NUM_CONTEXT 2
+
+/* 

[Patch v5 2/2] media: v4l: ti-vpe: Document DRA72 CAL h/w module

2015-11-18 Thread Benoit Parrot
Device Tree bindings for the DRA72 Camera Adaptation Layer (CAL)
H/W module.

Signed-off-by: Benoit Parrot 
---
 Documentation/devicetree/bindings/media/ti-cal.txt | 72 ++
 1 file changed, 72 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/ti-cal.txt

diff --git a/Documentation/devicetree/bindings/media/ti-cal.txt 
b/Documentation/devicetree/bindings/media/ti-cal.txt
new file mode 100644
index ..ae9b52f37576
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/ti-cal.txt
@@ -0,0 +1,72 @@
+Texas Instruments DRA72x CAMERA ADAPTATION LAYER (CAL)
+--
+
+The Camera Adaptation Layer (CAL) is a key component for image capture
+applications. The capture module provides the system interface and the
+processing capability to connect CSI2 image-sensor modules to the
+DRA72x device.
+
+Required properties:
+- compatible: must be "ti,dra72-cal"
+- reg: CAL Top level, Receiver Core #0, Receiver Core #1 and Camera RX
+   control address space
+- reg-names: cal_top, cal_rx_core0, cal_rx_core1, and camerrx_control
+registers
+- interrupts: should contain IRQ line for the CAL;
+
+CAL supports 2 camera port nodes on MIPI bus. Each CSI2 camera port nodes
+should contain a 'port' child node with child 'endpoint' node. Please
+refer to the bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+   cal: cal@4845b000 {
+   compatible = "ti,dra72-cal";
+   ti,hwmods = "cal";
+   reg = <0x4845B000 0x400>,
+ <0x4845B800 0x40>,
+ <0x4845B900 0x40>,
+ <0x4A002e94 0x4>;
+   reg-names = "cal_top",
+   "cal_rx_core0",
+   "cal_rx_core1",
+   "camerrx_control";
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   csi2_0: port@0 {
+   reg = <0>;
+   endpoint {
+   slave-mode;
+   remote-endpoint = <&ar0330_1>;
+   };
+   };
+   csi2_1: port@1 {
+   reg = <1>;
+   };
+   };
+   };
+
+   i2c5: i2c@4807c000 {
+   ar0330@10 {
+   compatible = "ti,ar0330";
+   reg = <0x10>;
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ar0330_1: endpoint {
+   reg = <0>;
+   clock-lanes = <1>;
+   data-lanes = <0 2 3 4>;
+   remote-endpoint = <&csi2_0>;
+   };
+   };
+   };
+   };
-- 
1.8.5.1

--
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


[Patch v5 0/2] media: v4l: ti-vpe: Add CAL v4l2 camera capture driver

2015-11-18 Thread Benoit Parrot
The Camera Adaptation Layer (CAL) is a block which consists of a dual
port CSI2/MIPI camera capture engine.
This camera engine is currently found on DRA72xx family of devices.

Port #0 can handle CSI2 camera connected to up to 4 data lanes.
Port #1 can handle CSI2 camera connected to up to 2 data lanes.

The driver implements the required API/ioctls to be V4L2 compliant.
Driver supports the following:
- V4L2 API using DMABUF/MMAP buffer access based on videobuf2 api
- Asynchronous sensor sub device registration
- DT support

Currently each port is designed to connect to a single sub-device.
In other words port aggregation is not currently supported.

Changes since v4:
- Corrected dt bindings per review comment.
- Applied related dt bindings changes to driver code.
- Folded in coccinelle generated patches.
- Corrected checkpatch.pl --strict warnings.

Changes since v3:
- Nothing really I messed up the previous format-patch with the
  wrong commit-id. Sorry about the repeat.

Changes since v2:
- Rework Kconfig options and added COMPILE_TEST
- Merged in provided vb2 buffer rework
- Rebase on tip of lmm master and fixe vb2 split related changes

Changes since v1:
- Remove unnecessary format description
- Reworked how transient frame format is maintained
  in order to make it easier to use the fill helper functions
- Added a per port list of active frame format
- Reworked an added missing vb2 cleanup code
- Fix a module load/unload kernel oops
- Switch to use proper int64 get function for pixel rate control

=

Here is a sample output of the v4l2-compliance tool:

# ./v4l2-compliance -f -s -v -d /dev/video0 
Driver Info:
Driver name   : cal
Card type : cal
Bus info : platform:cal-000

Capabilities  : 0x8521
Video Capture
Read/Write
Streaming
Extended Pix Format
Device Capabilities
Device Caps   : 0x0521
Video Capture
Read/Write
Streaming
Extended Pix Format

Compliance test for device /dev/video0 (not using libv4l2):

Required ioctls:
test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK

Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK

Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 1 Audio Inputs: 0 Tuners: 0

Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)

Test input 0:

Control ioctls:
info: checking v4l2_queryctrl of control 'User Controls' 
(0x00980001)
info: checking v4l2_queryctrl of control 'Horizontal Flip' 
(0x00980914)
info: checking v4l2_queryctrl of control 'Vertical Flip' 
(0x00980915)
info: checking v4l2_queryctrl of control 'Image Processing 
Controls' (0x009f0001)
info: checking v4l2_queryctrl of control 'Pixel Rate' 
(0x009f0902)
info: checking v4l2_queryctrl of control 'Horizontal Flip' 
(0x00980914)
info: checking v4l2_queryctrl of control 'Vertical Flip' 
(0x00980915)
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
info: checking control 'User Controls' (0x00980001)
info: checking control 'Horizontal Flip' (0x00980914)
info: checking control 'Vertical Flip' (0x00980915)
info: checking control 'Image Processing Controls' (0x009f0001)
info: checking control 'Pixel Rate' (0x009f0902)
test VIDIOC_G/S_CTRL: OK
info: checking extended control 'User Controls' (0x00980001)
info: checking extended control 'Horizontal Flip' (0x00980914)
info: checking extended control 'Vertical Flip' (0x00980915)
info: checking extended control 'Image Processing Controls' 
(0x009f0001)
info: checking extended control 'Pixel Rate' (0x009f0902)
test VIDIOC_G/S/T

Re: device_node lifetime (was: Re: [PATCH 1/7] phy: brcmstb-sata: add missing of_node_put)

2015-11-18 Thread Julia Lawall


On Wed, 18 Nov 2015, Brian Norris wrote:

> (changing subject, add devicetree@vger.kernel.org)
> 
> On Tue, Nov 17, 2015 at 11:33:25PM +0100, Julia Lawall wrote:
> > On Tue, 17 Nov 2015, Brian Norris wrote:
> > > On Tue, Nov 17, 2015 at 06:48:39PM +0100, Julia Lawall wrote:
> > > > Is this something that should be checked for elsewhere?
> > > 
> > > I expect the same sort of problem shows up plenty of other places. I
> > > don't think many people use CONFIG_OF_DYNAMIC, so the effects of these
> > > failures probably aren't felt by many.
> > 
> > I tried the following semantic patch:
> > 
> > @@
> > struct device_node *e;
> > expression e1;
> > identifier fld;
> > @@
> > 
> >  ... when != of_node_get(...)
> > *(<+...e1->fld...+>) = e
> >  ... when != of_node_get(...)
> >  return e1;
> > 
> > basically, this says that a structure field is initilized to a device node 
> > value, the structure is returned by the containing function, and the 
> > containing function contains no of_node_get at all.  Certainly this is 
> > quite constrained, but it does produce a number of examples.
> > 
> > I looked at a few of them:
> > 
> > drivers/clk/ingenic/cgu.c, ingenic_cgu_new
> > clk/pistachio/clk.c, pistachio_clk_alloc_provider
> 
> It looks like the clock core (drivers/clk/clk.c) initially grabs the clk
> provider node in of_clk_init(), then drops it after it's initialized,
> but most of these providers use of_clk_add_provider(), which seems to
> manage the device_node lifetime for the user. So I think these are OK.
> 
> > drivers/mfd/syscon.c, of_syscon_register
> 
> This one looks potentially suspect. Syscon nodes aren't usually directly
> managed by a single driver, and the device_node pointer is used for
> lookups later...so I think it should keep a kref, and it doesn't.
> 
> > drivers/of/pdt.c, function of_pdt_create_node
> 
> Not real sure about this one.
> 
> > Any idea whether these need of_node_get?  In all cases the device node 
> > value comes in as a parameter.
> 
> I'm really not an expert on this stuff. I just saw a potential problem
> that I happen to be looking at in other subsystems, and I wanted to know
> what others thought.

Thanks for the analysis.  I will look into them a bit more.  Hopefully at 
least the maintainer of each file will know what should be done.

julia

> I think this discussion should include the DT folks
> and the subsystems in question. For one, I'm as interested as anyone in
> getting this todo clarified:
> 
> Documentation/devicetree/todo.txt
> - Document node lifecycle for CONFIG_OF_DYNAMIC
> 
> Regards,
> Brian
> 
--
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


Re: [PATCH] clk: add generic driver for fixed rate clock

2015-11-18 Thread Stephen Boyd
On 11/17, Geert Uytterhoeven wrote:
> Hi Stefan,
> 
> (quoting the full driver, as it predates linux-clk)
> 
> On Sun, Sep 1, 2013 at 6:40 AM, Stefan Kristiansson
>  wrote:
> > This adds a simple driver with the only purpose to initialise
> > the fixed rate clock.
> > This is useful for systems that do not wish to use seperate init
> > code for the fixed rate clock init, but rather only rely on a
> > device tree description of it.
> >
> > Signed-off-by: Stefan Kristiansson 
> 
> Thanks, this is still very useful!
> 
> I stumbled across this old patch while trying to instantiate a fixed rate
> clock from a DT overlay.
> Without this, the clock is never instantiated, as drivers/clk/clk-fixed-rate.c
> uses CLK_OF_DECLARE() :-( With your driver, it works as expected
> (after fixing the modpost complaint, cfr. below).
> 
> However, I think that instead of creating a new driver, you should just add
> the meat of clk-generic-fixed.c to clk-fixed-rate.c.

Hm... what happens when of_clk_init() runs and instantiates the
clock, and then of_platform_populate() runs and creates the clock
again? The platform device probe fails because the framework
checks to make sure two clocks don't have the same name? I guess
that's going to work, but it doesn't make me feel good.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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


Re: [PATCH 3/3] doc: dt: mtd: stop referring to driver code for spi-nor IDs

2015-11-18 Thread Javier Martinez Canillas
Hello Brian,

On 11/18/2015 04:43 PM, Brian Norris wrote:
> Hi,
> 
> On Tue, Nov 17, 2015 at 11:04:55AM -0300, Javier Martinez Canillas wrote:
>> On 11/16/2015 07:34 PM, Brian Norris wrote:
>>> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt 
>>> b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
>>> index 2bee68103b01..2c91c03e7eb0 100644
>>> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
>>> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
>>> @@ -1,15 +1,61 @@
>>> -* MTD SPI driver for ST M25Pxx (and similar) serial flash chips
>>> +* SPI NOR flash: ST M25Pxx (and similar) serial flash chips
>>>  
>>>  Required properties:
>>>  - #address-cells, #size-cells : Must be present if the device has sub-nodes
>>>representing partitions.
>>>  - compatible : May include a device-specific string consisting of the
>>> -   manufacturer and name of the chip. Bear in mind the DT 
>>> binding
>>> -   is not Linux-only, but in case of Linux, see the "m25p_ids"
>>> -   table in drivers/mtd/devices/m25p80.c for the list of 
>>> supported
>>> -   chips.
>>> +   manufacturer and name of the chip. A list of supported chip
>>> +   names follows.
>>
>> Here says that the compatible string consists of manufacturer and name...
>>
>>> Must also include "jedec,spi-nor" for any SPI NOR flash 
>>> that can
>>> be identified by the JEDEC READ ID opcode (0x9F).
>>> +
>>> +   Supported chip names:
>>> + at25df321a
>>> + at25df641
> [...]
>> +
>>
>> ... but the entries in the list don't have a manufacturer. I know this is
>> due backward compatibility because as we discussed in the thread mentioned
>> in the cover letter, the SPI core didn't use the manufacturer and that
>> implementation detail leaked into the DTBs.
>>
>> But I think that either only the correct list with vendor should be added
>> to the DT binding docs (but make sure that backward compatibility in the
>> driver and SPI core is maintained) or both the wrong and correct list should
>> be documented and the former be marked as deprecated.
> 
> First, note that the list says "Supported chip *names*" (not "Supported
> compatible values"). It does not attempt to specify the full compatible
> value, and that's intentional.
> 

Right, sorry I missed that subtlety.

> Second, I believe it is hard to determine after-the-fact what all the
> reasonable pairings of vendors might be. For some of these parts,
> various companies have produced parts under the same chip ID -- usually
> because one company bought another. For most chips though, this probably
> isn't a problem, so I could probably pick reasonable vendor pairings.
>
> IOW, there isn't just "a wrong" and "a correct" list; there's a
> (probably?) correct list and an enormous space of "I don't know what
> people might have put here" list. It's nearly unbounded, but even a
> reasonable list might get pretty large. So in practice, we'd essentially
> be sacrificing completeness for...what reason?
>

I see.

>>> +   The following chip names have been used historically to
>>> +   designate quirky versions of flash chips that do not 
>>> support the
>>> +   JEDEC READ ID opcode (0x9F):
>>> + m25p05-nonjedec
>>> + m25p10-nonjedec
>>> + m25p20-nonjedec
>>> + m25p40-nonjedec
>>> + m25p80-nonjedec
>>> + m25p16-nonjedec
>>> + m25p32-nonjedec
>>> + m25p64-nonjedec
>>> + m25p128-nonjedec
>>> +
>>
>> Same here, I would prefer if the DT binding make it clear that not having
>> a vendor is wrong and is only documented to maintain backward compatibility.
> 
> The doc never says anything about not including the vendor. It says
> 
>   "May include a device-specific string consisting of the manufacturer
>   and name of the chip"
> 
> and it lists the chip names. So if someone is actually following the
> documentation, they will include a vendor. The vendor names are not
> listed because they're really not relevant to the implementation. But I
> could try to include them.
>

My goal was to start forcing people to use a complete compatible string
to avoid the "garbage,chip-name" that you mentioned in the other thread.

The vendor are not relevant in the current implementation because how the
SPI core is implemented but I think that shouldn't affect the accuracy on
which hardware is described in the DT.
 
>>>  - reg : Chip-Select number
>>>  - spi-max-frequency : Maximum frequency of the SPI bus the chip can 
>>> operate at
>>>  
>>>
> 
> So, what makes sense? I can make a separate list of vendors (my
> preference), or even try to pair up vendors with chip names (even if
> it's sometimes an N:1 relationship). But I don't see that really buying
> us much, since the 

Re: [PATCH v3 net-next] net: hisilicon: fix binding document of mdio

2015-11-18 Thread David Miller
From: huangdaode 
Date: Wed, 18 Nov 2015 10:08:00 +0800

> This patch explains the occasion of "hisilcon,mdio" and
> "hisilicon,hns-mdio" according to Arnd's comments.
> and reformat it according to comments from Rob.
> 
> Signed-off-by: huangdaode 

Applied, thanks.
--
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


Re: [PATCH 3/3] doc: dt: mtd: stop referring to driver code for spi-nor IDs

2015-11-18 Thread Brian Norris
Hi,

On Tue, Nov 17, 2015 at 11:04:55AM -0300, Javier Martinez Canillas wrote:
> On 11/16/2015 07:34 PM, Brian Norris wrote:
> > diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt 
> > b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> > index 2bee68103b01..2c91c03e7eb0 100644
> > --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> > +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> > @@ -1,15 +1,61 @@
> > -* MTD SPI driver for ST M25Pxx (and similar) serial flash chips
> > +* SPI NOR flash: ST M25Pxx (and similar) serial flash chips
> >  
> >  Required properties:
> >  - #address-cells, #size-cells : Must be present if the device has sub-nodes
> >representing partitions.
> >  - compatible : May include a device-specific string consisting of the
> > -   manufacturer and name of the chip. Bear in mind the DT 
> > binding
> > -   is not Linux-only, but in case of Linux, see the "m25p_ids"
> > -   table in drivers/mtd/devices/m25p80.c for the list of 
> > supported
> > -   chips.
> > +   manufacturer and name of the chip. A list of supported chip
> > +   names follows.
> 
> Here says that the compatible string consists of manufacturer and name...
> 
> > Must also include "jedec,spi-nor" for any SPI NOR flash 
> > that can
> > be identified by the JEDEC READ ID opcode (0x9F).
> > +
> > +   Supported chip names:
> > + at25df321a
> > + at25df641
[...]
> +
> 
> ... but the entries in the list don't have a manufacturer. I know this is
> due backward compatibility because as we discussed in the thread mentioned
> in the cover letter, the SPI core didn't use the manufacturer and that
> implementation detail leaked into the DTBs.
> 
> But I think that either only the correct list with vendor should be added
> to the DT binding docs (but make sure that backward compatibility in the
> driver and SPI core is maintained) or both the wrong and correct list should
> be documented and the former be marked as deprecated.

First, note that the list says "Supported chip *names*" (not "Supported
compatible values"). It does not attempt to specify the full compatible
value, and that's intentional.

Second, I believe it is hard to determine after-the-fact what all the
reasonable pairings of vendors might be. For some of these parts,
various companies have produced parts under the same chip ID -- usually
because one company bought another. For most chips though, this probably
isn't a problem, so I could probably pick reasonable vendor pairings.

IOW, there isn't just "a wrong" and "a correct" list; there's a
(probably?) correct list and an enormous space of "I don't know what
people might have put here" list. It's nearly unbounded, but even a
reasonable list might get pretty large. So in practice, we'd essentially
be sacrificing completeness for...what reason?

> > +   The following chip names have been used historically to
> > +   designate quirky versions of flash chips that do not 
> > support the
> > +   JEDEC READ ID opcode (0x9F):
> > + m25p05-nonjedec
> > + m25p10-nonjedec
> > + m25p20-nonjedec
> > + m25p40-nonjedec
> > + m25p80-nonjedec
> > + m25p16-nonjedec
> > + m25p32-nonjedec
> > + m25p64-nonjedec
> > + m25p128-nonjedec
> > +
> 
> Same here, I would prefer if the DT binding make it clear that not having
> a vendor is wrong and is only documented to maintain backward compatibility.

The doc never says anything about not including the vendor. It says

  "May include a device-specific string consisting of the manufacturer
  and name of the chip"

and it lists the chip names. So if someone is actually following the
documentation, they will include a vendor. The vendor names are not
listed because they're really not relevant to the implementation. But I
could try to include them.

> >  - reg : Chip-Select number
> >  - spi-max-frequency : Maximum frequency of the SPI bus the chip can 
> > operate at
> >  
> > 

So, what makes sense? I can make a separate list of vendors (my
preference), or even try to pair up vendors with chip names (even if
it's sometimes an N:1 relationship). But I don't see that really buying
us much, since the implementation never has (and probably never will)
enforce this. What do you think?

Regards,
Brian
--
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


device_node lifetime (was: Re: [PATCH 1/7] phy: brcmstb-sata: add missing of_node_put)

2015-11-18 Thread Brian Norris
(changing subject, add devicetree@vger.kernel.org)

On Tue, Nov 17, 2015 at 11:33:25PM +0100, Julia Lawall wrote:
> On Tue, 17 Nov 2015, Brian Norris wrote:
> > On Tue, Nov 17, 2015 at 06:48:39PM +0100, Julia Lawall wrote:
> > > Is this something that should be checked for elsewhere?
> > 
> > I expect the same sort of problem shows up plenty of other places. I
> > don't think many people use CONFIG_OF_DYNAMIC, so the effects of these
> > failures probably aren't felt by many.
> 
> I tried the following semantic patch:
> 
> @@
> struct device_node *e;
> expression e1;
> identifier fld;
> @@
> 
>  ... when != of_node_get(...)
> *(<+...e1->fld...+>) = e
>  ... when != of_node_get(...)
>  return e1;
> 
> basically, this says that a structure field is initilized to a device node 
> value, the structure is returned by the containing function, and the 
> containing function contains no of_node_get at all.  Certainly this is 
> quite constrained, but it does produce a number of examples.
> 
> I looked at a few of them:
> 
> drivers/clk/ingenic/cgu.c, ingenic_cgu_new
> clk/pistachio/clk.c, pistachio_clk_alloc_provider

It looks like the clock core (drivers/clk/clk.c) initially grabs the clk
provider node in of_clk_init(), then drops it after it's initialized,
but most of these providers use of_clk_add_provider(), which seems to
manage the device_node lifetime for the user. So I think these are OK.

> drivers/mfd/syscon.c, of_syscon_register

This one looks potentially suspect. Syscon nodes aren't usually directly
managed by a single driver, and the device_node pointer is used for
lookups later...so I think it should keep a kref, and it doesn't.

> drivers/of/pdt.c, function of_pdt_create_node

Not real sure about this one.

> Any idea whether these need of_node_get?  In all cases the device node 
> value comes in as a parameter.

I'm really not an expert on this stuff. I just saw a potential problem
that I happen to be looking at in other subsystems, and I wanted to know
what others thought. I think this discussion should include the DT folks
and the subsystems in question. For one, I'm as interested as anyone in
getting this todo clarified:

Documentation/devicetree/todo.txt
- Document node lifecycle for CONFIG_OF_DYNAMIC

Regards,
Brian
--
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


Re: [PATCH V2 net-next 1/5] net:hns: Add support of Hip06 SoC to the Hislicon Network Subsystem

2015-11-18 Thread David Miller
From: Salil 
Date: Wed, 18 Nov 2015 02:52:23 +0800

> @@ -387,19 +409,23 @@ static void hns_rcb_ring_get_cfg(struct hnae_queue *q, 
> int ring_type)
>   struct rcb_common_cb *rcb_common;
>   struct ring_pair_cb *ring_pair_cb;
>   u32 buf_size;
> - u16 desc_num;
> - int irq_idx;
> + u16 desc_num, mdnum_ppkt;
> + int irq_idx, is_ver1;

Please use "bool" and true/false for boolean conditions like is_ver1.

Please audit your entire submission for this problem.
--
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


Re: [PATCH 03/11] dts: pinctrl: Add GPIO to Pinctrl pin mapping in DT

2015-11-18 Thread Florian Fainelli
On 18/10/15 22:43, Pramod Kumar wrote:
> ASIU gpio controller's pins are muxed with pin-cntroller.
> Add this mapping through property "gpio-ranges".
> 
> Signed-off-by: Pramod Kumar 
> Reviewed-by: Ray Jui 
> Reviewed-by: Scott Branden 

Applied to devicetree/next, since there was a bit of restructuring, I
had to manually apply it, please verify the resolution looks correct to you.

Thanks!
-- 
Florian
--
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


[PATCH] ARM: dts: enable PCIe PHY support for Cygnus

2015-11-18 Thread Ray Jui
Enable PCIe PHY for both PCIe root complexes on Cygnus

Signed-off-by: Ray Jui 
---
 arch/arm/boot/dts/bcm-cygnus.dtsi | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi 
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 2778533..5df5300 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -91,6 +91,21 @@
#address-cells = <1>;
#size-cells = <1>;
 
+   pcie_phy: phy@0301d0a0 {
+   compatible = "brcm,cygnus-pcie-phy";
+   reg = <0x0301d0a0 0x14>;
+
+   pcie0_phy: phy@0 {
+   reg = <0>;
+   #phy-cells = <0>;
+   };
+
+   pcie1_phy: phy@1 {
+   reg = <1>;
+   #phy-cells = <0>;
+   };
+   };
+
pinctrl: pinctrl@0x0301d0c8 {
compatible = "brcm,cygnus-pinmux";
reg = <0x0301d0c8 0x30>,
@@ -161,6 +176,9 @@
ranges = <0x8100 0 0  0x2800 0 
0x0001
  0x8200 0 0x2000 0x2000 0 
0x0400>;
 
+   phys = <&pcie0_phy>;
+   phy-names = "pcie-phy";
+
status = "disabled";
};
 
@@ -182,6 +200,9 @@
ranges = <0x8100 0 0  0x4800 0 
0x0001
  0x8200 0 0x4000 0x4000 0 
0x0400>;
 
+   phys = <&pcie1_phy>;
+   phy-names = "pcie-phy";
+
status = "disabled";
};
 
-- 
1.9.1

--
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


[PATCH] Enable PCIe PHY support in Cygnus

2015-11-18 Thread Ray Jui
This patch enales PCIe PHY in device tree for Broadcom Cygnus based platforms

This patch is developed based on v4.4-rc1 and available here:
https://github.com/Broadcom/cygnus-linux/tree/cygnus-pcie-phy-dt-v1

Ray Jui (1):
  ARM: dts: enable PCIe PHY support for Cygnus

 arch/arm/boot/dts/bcm-cygnus.dtsi | 21 +
 1 file changed, 21 insertions(+)

-- 
1.9.1

--
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


Re: [PATCH 2/2] usb: dwc3: Add Xilinx ZynqMP platform specific glue layer

2015-11-18 Thread Felipe Balbi

Hi,

Subbaraya Sundeep Bhatta  writes:
> This patch adds glue driver for DWC3 core in Xilinx ZynqMP SOC.
> DWC3 glue layer is hardware layer around Synopsys DesignWare
> USB3 core. Its purpose is to supply Synopsys IP with required clocks
> and interface it with the rest of the SoC.
>
> Signed-off-by: Subbaraya Sundeep Bhatta 
> ---
>  drivers/usb/dwc3/Kconfig   |   8 +++
>  drivers/usb/dwc3/Makefile  |   1 +
>  drivers/usb/dwc3/dwc3-xilinx.c | 131 
> +
>  3 files changed, 140 insertions(+)
>  create mode 100644 drivers/usb/dwc3/dwc3-xilinx.c
>
> diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
> index 5a42c45..a447879 100644
> --- a/drivers/usb/dwc3/Kconfig
> +++ b/drivers/usb/dwc3/Kconfig
> @@ -104,4 +104,12 @@ config USB_DWC3_QCOM
> Recent Qualcomm SoCs ship with one DesignWare Core USB3 IP inside,
> say 'Y' or 'M' if you have one such device.
>  
> +config USB_DWC3_XILINX
> + tristate "Xilinx ZynqMP Platform"
> + depends on ARCH_ZYNQMP || COMPILE_TEST
> + default USB_DWC3
> + help
> +   Xilinx ZynqMP SOC ship with two DesignWare Core USB3 IPs inside,
> +   say 'Y' or 'M' if you have one such device.
> +
>  endif
> diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
> index acc951d..50cb626 100644
> --- a/drivers/usb/dwc3/Makefile
> +++ b/drivers/usb/dwc3/Makefile
> @@ -39,3 +39,4 @@ obj-$(CONFIG_USB_DWC3_PCI)  += dwc3-pci.o
>  obj-$(CONFIG_USB_DWC3_KEYSTONE)  += dwc3-keystone.o
>  obj-$(CONFIG_USB_DWC3_QCOM)  += dwc3-qcom.o
>  obj-$(CONFIG_USB_DWC3_ST)+= dwc3-st.o
> +obj-$(CONFIG_USB_DWC3_XILINX)+= dwc3-xilinx.o
> diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
> new file mode 100644
> index 000..a0dce3e
> --- /dev/null
> +++ b/drivers/usb/dwc3/dwc3-xilinx.c
> @@ -0,0 +1,131 @@
> +/**
> + * dwc3-xilinx.c - Xilinx ZynqMP specific Glue layer
> + *
> + * Copyright (C) 2015 Xilinx Inc.
> + *
> + * Author: Subbaraya Sundeep 
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2  of
> + * the License as published by the Free Software Foundation.
> + *
> + * 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 
> +
> +/**
> + * struct xilinx_dwc3 - dwc3 xilinx glue structure
> + * @dev: device pointer
> + * @ref_clk: clock input to core during PHY power down
> + * @bus_clk: bus clock input to core
> + */
> +struct xilinx_dwc3 {
> + struct device   *dev;
> + struct clk  *ref_clk;
> + struct clk  *bus_clk;
> +};
> +
> +/**
> + * xilinx_dwc3_probe - The device probe function for driver initialization.
> + * @pdev: pointer to the platform device structure.
> + *
> + * Return: 0 for success and error value on failure
> + */
> +static int xilinx_dwc3_probe(struct platform_device *pdev)
> +{
> + struct device_node *node = pdev->dev.of_node;
> + struct xilinx_dwc3 *xdwc3;
> + int ret;
> +
> + xdwc3 = devm_kzalloc(&pdev->dev, sizeof(*xdwc3), GFP_KERNEL);
> + if (!xdwc3)
> + return -ENOMEM;
> +
> + xdwc3->dev = &pdev->dev;
> +
> + xdwc3->bus_clk = devm_clk_get(xdwc3->dev, "bus_clk");
> + if (IS_ERR(xdwc3->bus_clk)) {
> + dev_err(xdwc3->dev, "unable to get usb bus clock");
> + return PTR_ERR(xdwc3->bus_clk);
> + }
> +
> + xdwc3->ref_clk = devm_clk_get(xdwc3->dev, "ref_clk");
> + if (IS_ERR(xdwc3->ref_clk)) {
> + dev_err(xdwc3->dev, "unable to get usb ref clock");
> + return PTR_ERR(xdwc3->ref_clk);
> + }
> +
> + ret = clk_prepare_enable(xdwc3->bus_clk);
> + if (ret)
> + goto err_bus_clk;
> + ret = clk_prepare_enable(xdwc3->ref_clk);
> + if (ret)
> + goto err_ref_clk;
> +
> + platform_set_drvdata(pdev, xdwc3);
> +
> + ret = of_platform_populate(node, NULL, NULL, xdwc3->dev);
> + if (ret) {
> + dev_err(xdwc3->dev, "failed to create dwc3 core\n");
> + goto err_dwc3_core;
> + }
> +
> + return 0;
> +
> +err_dwc3_core:
> + clk_disable_unprepare(xdwc3->ref_clk);
> +err_ref_clk:
> + clk_disable_unprepare(xdwc3->bus_clk);
> +err_bus_clk:
> + return ret;
> +}
> +
> +/**
> + * xilinx_dwc3_remove - Releases the resources allocated during 
> initialization.
> + * @pdev: pointer to the platform device structure.
> + *
> + * Return: 0 always
> + */
> +static int xilinx_dwc3_remove(struct platform_device *pdev)
> +{
> + struct xilinx_dwc3 *xdwc3 = platform_get_drvdata(pdev);
> +
> + of_platform_depopulate(xdwc3->dev);
> +
> +  

[PATCH v7 4/5] regulator: tps65912: Add regulator driver for the TPS65912 PMIC

2015-11-18 Thread Andrew F. Davis
This patch adds support for TPS65912 PMIC regulators.

The regulators set consists of 4 DCDCs and 10 LDOs. The output
voltages are configurable and are meant to supply power to the
main processor and other components.

Signed-off-by: Andrew F. Davis 
---
 drivers/regulator/Kconfig  |   6 ++
 drivers/regulator/Makefile |   1 +
 drivers/regulator/tps65912-regulator.c | 169 +
 3 files changed, 176 insertions(+)
 create mode 100644 drivers/regulator/tps65912-regulator.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 90c7612..3b08452 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -727,6 +727,12 @@ config REGULATOR_TPS65910
help
  This driver supports TPS65910/TPS65911 voltage regulator chips.
 
+config REGULATOR_TPS65912
+   tristate "TI TPS65912 Power regulator"
+   depends on MFD_TPS65912
+   help
+   This driver supports TPS65912 voltage regulator chip.
+
 config REGULATOR_TPS80031
tristate "TI TPS80031/TPS80032 power regualtor driver"
depends on MFD_TPS80031
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 222ff5f..0f81749 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -91,6 +91,7 @@ obj-$(CONFIG_REGULATOR_TPS65218) += tps65218-regulator.o
 obj-$(CONFIG_REGULATOR_TPS6524X) += tps6524x-regulator.o
 obj-$(CONFIG_REGULATOR_TPS6586X) += tps6586x-regulator.o
 obj-$(CONFIG_REGULATOR_TPS65910) += tps65910-regulator.o
+obj-$(CONFIG_REGULATOR_TPS65912) += tps65912-regulator.o
 obj-$(CONFIG_REGULATOR_TPS80031) += tps80031-regulator.o
 obj-$(CONFIG_REGULATOR_TWL4030) += twl-regulator.o
 obj-$(CONFIG_REGULATOR_VEXPRESS) += vexpress.o
diff --git a/drivers/regulator/tps65912-regulator.c 
b/drivers/regulator/tps65912-regulator.c
new file mode 100644
index 000..a87f04e
--- /dev/null
+++ b/drivers/regulator/tps65912-regulator.c
@@ -0,0 +1,169 @@
+/*
+ * Regulator driver for TI TPS65912x PMICs
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author: Andrew F. Davis 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License version 2 for more details.
+ *
+ * Based on the TPS65218 driver and the previous TPS65912 driver by
+ * Margarita Olaya Cabrera 
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+
+enum tps65912_regulators { DCDC1, DCDC2, DCDC3, DCDC4, LDO1, LDO2, LDO3,
+   LDO4, LDO5, LDO6, LDO7, LDO8, LDO9, LDO10 };
+
+#define TPS65912_REGULATOR(_name, _id, _of_match, _ops, _vr, _er, _lr) \
+   [_id] = {   \
+   .name   = _name,\
+   .of_match   = _of_match,\
+   .regulators_node= "regulators", \
+   .id = _id,  \
+   .ops= &_ops,\
+   .n_voltages = 64,   \
+   .type   = REGULATOR_VOLTAGE,\
+   .owner  = THIS_MODULE,  \
+   .vsel_reg   = _vr,  \
+   .vsel_mask  = 0x3f, \
+   .enable_reg = _er,  \
+   .enable_mask= BIT(7),   \
+   .volt_table = NULL, \
+   .linear_ranges  = _lr,  \
+   .n_linear_ranges= ARRAY_SIZE(_lr),  \
+   }
+
+static const struct regulator_linear_range tps65912_dcdc_ranges[] = {
+   REGULATOR_LINEAR_RANGE(50, 0x0, 0x3f, 5),
+};
+
+static const struct regulator_linear_range tps65912_ldo_ranges[] = {
+   REGULATOR_LINEAR_RANGE(80, 0x0, 0x20, 25000),
+   REGULATOR_LINEAR_RANGE(165, 0x21, 0x3c, 5),
+   REGULATOR_LINEAR_RANGE(310, 0x3d, 0x3f, 10),
+};
+
+/* Operations permitted on DCDCx */
+static struct regulator_ops tps65912_ops_dcdc = {
+   .is_enabled = regulator_is_enabled_regmap,
+   .enable = regulator_enable_regmap,
+   .disable= regulator_disable_regmap,
+   .get_voltage_sel= regulator_get_voltage_sel_regmap,
+   .set_voltage_sel= regulator_set_voltage_sel_regmap,
+   .list_voltage   = regula

[PATCH v7 0/5] mfd: tps65912: Driver rewrite with DT support

2015-11-18 Thread Andrew F. Davis
In an effort to cleanup this driver and add Device Tree support
the driver has been rewritten based on new driver styles and
modern kernel driver helpers. This has nearly halved the lines
of code while keeping all previous functionality.

Platform file based initialization has been dropped as there is
no examples of this use in the kernel.

v1 can be found here: [1] v2: [2] v3: [3] v4: [4] v5: [5] v6: [6]

Changes from v6:
 - Removed compatible strings from DT sub-nodes
 - Rearranged DT bindings
 - Small fixes

Changes from v5:
 - Small formatting changes to DT Docs
 - Converted to_tps65912_gpio from macro to inline function

Changes from v4:
 - Use mfd core to add sub-devices

Changes from v3:
 - Reorganized regulator driver and related DT node
 - Other small fixes as discussed in v3 thread

Changes from v2:
 - Split the series further into subsystems

Changes from v1:
 - Split the rewrite into delete/create patches
 - Several small fixes as discussed in v1 thread

[1] http://www.spinics.net/lists/devicetree/msg93863.html
[2] http://www.spinics.net/lists/devicetree/msg95003.html
[3] http://www.spinics.net/lists/devicetree/msg95133.html
[4] http://www.spinics.net/lists/devicetree/msg96109.html
[5] http://www.spinics.net/lists/devicetree/msg100601.html
[6] https://lkml.org/lkml/2015/10/30/690

Andrew F. Davis (5):
  Documentation: tps65912: Add DT bindings for the TPS65912 PMIC
  mfd: tps65912: Remove old driver in preparation for new driver
  mfd: tps65912: Add driver for the TPS65912 PMIC
  regulator: tps65912: Add regulator driver for the TPS65912 PMIC
  gpio: tps65912: Add GPIO driver for the TPS65912 PMIC

 Documentation/devicetree/bindings/mfd/tps65912.txt |  50 ++
 drivers/gpio/Kconfig   |   2 +-
 drivers/gpio/gpio-tps65912.c   | 317 -
 drivers/mfd/Kconfig|  20 +-
 drivers/mfd/Makefile   |   3 +-
 drivers/mfd/tps65912-core.c| 290 -
 drivers/mfd/tps65912-i2c.c | 219 +++
 drivers/mfd/tps65912-irq.c | 217 ---
 drivers/mfd/tps65912-spi.c | 219 +++
 drivers/regulator/Kconfig  |   2 +-
 drivers/regulator/tps65912-regulator.c | 710 +
 include/linux/mfd/tps65912.h   | 208 +++---
 12 files changed, 780 insertions(+), 1477 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/tps65912.txt
 rewrite drivers/gpio/gpio-tps65912.c (74%)
 rewrite drivers/mfd/tps65912-core.c (95%)
 rewrite drivers/mfd/tps65912-i2c.c (93%)
 delete mode 100644 drivers/mfd/tps65912-irq.c
 rewrite drivers/mfd/tps65912-spi.c (92%)
 rewrite drivers/regulator/tps65912-regulator.c (94%)

-- 
1.9.1

--
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


[PATCH v7 5/5] gpio: tps65912: Add GPIO driver for the TPS65912 PMIC

2015-11-18 Thread Andrew F. Davis
This patch adds support for the TPS65912 PMIC GPIOs.

TPS65912 has five configurable GPIOs that can be used for several
purposes.

Signed-off-by: Andrew F. Davis 
Reviewed-by: Linus Walleij 
---
 drivers/gpio/Kconfig |   6 ++
 drivers/gpio/Makefile|   1 +
 drivers/gpio/gpio-tps65912.c | 164 +++
 3 files changed, 171 insertions(+)
 create mode 100644 drivers/gpio/gpio-tps65912.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 131a89b..a5fab31 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -852,6 +852,12 @@ config GPIO_TPS65910
  Select this option to enable GPIO driver for the TPS65910
  chip family.
 
+config GPIO_TPS65912
+   tristate "TI TPS65912 GPIO"
+   depends on MFD_TPS65912
+   help
+ This driver supports TPS65912 gpio chip
+
 config GPIO_TWL4030
tristate "TWL4030, TWL5030, and TPS659x0 GPIOs"
depends on TWL4030_CORE
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index f13b59f..986dbd8 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -97,6 +97,7 @@ obj-$(CONFIG_GPIO_TIMBERDALE) += gpio-timberdale.o
 obj-$(CONFIG_GPIO_PALMAS)  += gpio-palmas.o
 obj-$(CONFIG_GPIO_TPS6586X)+= gpio-tps6586x.o
 obj-$(CONFIG_GPIO_TPS65910)+= gpio-tps65910.o
+obj-$(CONFIG_GPIO_TPS65912)+= gpio-tps65912.o
 obj-$(CONFIG_GPIO_TS5500)  += gpio-ts5500.o
 obj-$(CONFIG_GPIO_TWL4030) += gpio-twl4030.o
 obj-$(CONFIG_GPIO_TWL6040) += gpio-twl6040.o
diff --git a/drivers/gpio/gpio-tps65912.c b/drivers/gpio/gpio-tps65912.c
new file mode 100644
index 000..41e1a72
--- /dev/null
+++ b/drivers/gpio/gpio-tps65912.c
@@ -0,0 +1,164 @@
+/*
+ * GPIO driver for TI TPS65912x PMICs
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author: Andrew F. Davis 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License version 2 for more details.
+ *
+ * Based on the Arizona GPIO driver and the previous TPS65912 driver by
+ * Margarita Olaya Cabrera 
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+
+struct tps65912_gpio {
+   struct gpio_chip gpio_chip;
+   struct tps65912 *tps;
+};
+
+static inline struct tps65912_gpio *to_tps65912_gpio(struct gpio_chip *chip)
+{
+   return container_of(chip, struct tps65912_gpio, gpio_chip);
+}
+
+static int tps65912_gpio_get_direction(struct gpio_chip *gc,
+  unsigned offset)
+{
+   struct tps65912_gpio *gpio = to_tps65912_gpio(gc);
+
+   int ret, val;
+
+   ret = regmap_read(gpio->tps->regmap, TPS65912_GPIO1 + offset, &val);
+   if (ret)
+   return ret;
+
+   if (val & GPIO_CFG_MASK)
+   return GPIOF_DIR_OUT;
+   else
+   return GPIOF_DIR_IN;
+}
+
+static int tps65912_gpio_direction_input(struct gpio_chip *gc, unsigned offset)
+{
+   struct tps65912_gpio *gpio = to_tps65912_gpio(gc);
+
+   return regmap_update_bits(gpio->tps->regmap, TPS65912_GPIO1 + offset,
+ GPIO_CFG_MASK, 0);
+}
+
+static int tps65912_gpio_direction_output(struct gpio_chip *gc,
+ unsigned offset, int value)
+{
+   struct tps65912_gpio *gpio = to_tps65912_gpio(gc);
+
+   /* Set the initial value */
+   regmap_update_bits(gpio->tps->regmap, TPS65912_GPIO1 + offset,
+  GPIO_SET_MASK, value ? GPIO_SET_MASK : 0);
+
+   return regmap_update_bits(gpio->tps->regmap, TPS65912_GPIO1 + offset,
+ GPIO_CFG_MASK, GPIO_CFG_MASK);
+}
+
+static int tps65912_gpio_get(struct gpio_chip *gc, unsigned offset)
+{
+   struct tps65912_gpio *gpio = to_tps65912_gpio(gc);
+   int ret, val;
+
+   ret = regmap_read(gpio->tps->regmap, TPS65912_GPIO1 + offset, &val);
+   if (ret)
+   return ret;
+
+   if (val & GPIO_STS_MASK)
+   return 1;
+
+   return 0;
+}
+
+static void tps65912_gpio_set(struct gpio_chip *gc, unsigned offset,
+ int value)
+{
+   struct tps65912_gpio *gpio = to_tps65912_gpio(gc);
+
+   regmap_update_bits(gpio->tps->regmap, TPS65912_GPIO1 + offset,
+  GPIO_SET_MASK, value ? GPIO_SET_MASK : 0);
+}
+
+static struct gpio_chip template_chip = {
+   .label  = "tps65912-gpio",
+   .owner  = THIS_MODULE,
+   .get_direction  = tps65912_gpio_get_direction,
+   .direction_input= tps65912_gpio_direction_input,
+   .direction_out

[PATCH v7 3/5] mfd: tps65912: Add driver for the TPS65912 PMIC

2015-11-18 Thread Andrew F. Davis
This patch adds support for TPS65912 PMIC MFD core. It provides
communication through the I2C and SPI interfaces. It contains
the following components:

 - Regulators
 - GPIO controller

Signed-off-by: Andrew F. Davis 
Acked-by: Lee Jones 
---
 drivers/mfd/Kconfig  |  24 +++
 drivers/mfd/Makefile |   3 +
 drivers/mfd/tps65912-core.c  | 115 +++
 drivers/mfd/tps65912-i2c.c   |  80 ++
 drivers/mfd/tps65912-spi.c   |  79 ++
 include/linux/mfd/tps65912.h | 342 +++
 6 files changed, 643 insertions(+)
 create mode 100644 drivers/mfd/tps65912-core.c
 create mode 100644 drivers/mfd/tps65912-i2c.c
 create mode 100644 drivers/mfd/tps65912-spi.c
 create mode 100644 include/linux/mfd/tps65912.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 7c0398d..fe3cc44 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1180,6 +1180,30 @@ config MFD_TPS65910
  if you say yes here you get support for the TPS65910 series of
  Power Management chips.
 
+config MFD_TPS65912
+   tristate
+   select MFD_CORE
+   select REGMAP
+   select REGMAP_IRQ
+
+config MFD_TPS65912_I2C
+   tristate "TI TPS65912 Power Management chip with I2C"
+   select MFD_TPS65912
+   select REGMAP_I2C
+   depends on I2C
+   help
+ If you say yes here you get support for the TPS65912 series of
+ PM chips with I2C interface.
+
+config MFD_TPS65912_SPI
+   tristate "TI TPS65912 Power Management chip with SPI"
+   select MFD_TPS65912
+   select REGMAP_SPI
+   depends on SPI_MASTER
+   help
+ If you say yes here you get support for the TPS65912 series of
+ PM chips with SPI interface.
+
 config MFD_TPS80031
bool "TI TPS80031/TPS80032 Power Management chips"
depends on I2C=y
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 66cffb1..cb7af8a 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -69,6 +69,9 @@ obj-$(CONFIG_TPS6507X)+= tps6507x.o
 obj-$(CONFIG_MFD_TPS65217) += tps65217.o
 obj-$(CONFIG_MFD_TPS65218) += tps65218.o
 obj-$(CONFIG_MFD_TPS65910) += tps65910.o
+obj-$(CONFIG_MFD_TPS65912) += tps65912-core.o
+obj-$(CONFIG_MFD_TPS65912_I2C) += tps65912-i2c.o
+obj-$(CONFIG_MFD_TPS65912_SPI)  += tps65912-spi.o
 obj-$(CONFIG_MFD_TPS80031) += tps80031.o
 obj-$(CONFIG_MENELAUS) += menelaus.o
 
diff --git a/drivers/mfd/tps65912-core.c b/drivers/mfd/tps65912-core.c
new file mode 100644
index 000..d854b18
--- /dev/null
+++ b/drivers/mfd/tps65912-core.c
@@ -0,0 +1,115 @@
+/*
+ * Core functions for TI TPS65912x PMICs
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author: Andrew F. Davis 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License version 2 for more details.
+ *
+ * Based on the TPS65218 driver and the previous TPS65912 driver by
+ * Margarita Olaya Cabrera 
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+
+static const struct mfd_cell tps65912_cells[] = {
+   { .name = "tps65912-regulator", },
+   { .name = "tps65912-gpio", },
+};
+
+static const struct regmap_irq tps65912_irqs[] = {
+   /* INT_STS IRQs */
+   REGMAP_IRQ_REG(TPS65912_IRQ_PWRHOLD_F, 0, TPS65912_INT_STS_PWRHOLD_F),
+   REGMAP_IRQ_REG(TPS65912_IRQ_VMON, 0, TPS65912_INT_STS_VMON),
+   REGMAP_IRQ_REG(TPS65912_IRQ_PWRON, 0, TPS65912_INT_STS_PWRON),
+   REGMAP_IRQ_REG(TPS65912_IRQ_PWRON_LP, 0, TPS65912_INT_STS_PWRON_LP),
+   REGMAP_IRQ_REG(TPS65912_IRQ_PWRHOLD_R, 0, TPS65912_INT_STS_PWRHOLD_R),
+   REGMAP_IRQ_REG(TPS65912_IRQ_HOTDIE, 0, TPS65912_INT_STS_HOTDIE),
+   REGMAP_IRQ_REG(TPS65912_IRQ_GPIO1_R, 0, TPS65912_INT_STS_GPIO1_R),
+   REGMAP_IRQ_REG(TPS65912_IRQ_GPIO1_F, 0, TPS65912_INT_STS_GPIO1_F),
+   /* INT_STS2 IRQs */
+   REGMAP_IRQ_REG(TPS65912_IRQ_GPIO2_R, 1, TPS65912_INT_STS2_GPIO2_R),
+   REGMAP_IRQ_REG(TPS65912_IRQ_GPIO2_F, 1, TPS65912_INT_STS2_GPIO2_F),
+   REGMAP_IRQ_REG(TPS65912_IRQ_GPIO3_R, 1, TPS65912_INT_STS2_GPIO3_R),
+   REGMAP_IRQ_REG(TPS65912_IRQ_GPIO3_F, 1, TPS65912_INT_STS2_GPIO3_F),
+   REGMAP_IRQ_REG(TPS65912_IRQ_GPIO4_R, 1, TPS65912_INT_STS2_GPIO4_R),
+   REGMAP_IRQ_REG(TPS65912_IRQ_GPIO4_F, 1, TPS65912_INT_STS2_GPIO4_F),
+   REGMAP_IRQ_REG(TPS65912_IRQ_GPIO5_R, 1, TPS65912_INT_STS2_GPIO5_R),
+   REGMAP_IRQ_REG(TPS65912_IRQ_GPIO5_F, 1, TPS65912_INT_STS2_GPIO5_F),
+   /* INT_STS3 IRQs */
+   REGMAP_IRQ_REG(TPS65912_IRQ_PGOOD_DCDC1, 2, 
TPS65912_INT_STS3_PGOOD_DCDC1),
+

[PATCH v7 2/5] mfd: tps65912: Remove old driver in preparation for new driver

2015-11-18 Thread Andrew F. Davis
The old tps65912 driver is being replaced, delete old driver.

Signed-off-by: Andrew F. Davis 
Acked-by: Lee Jones 
---
 drivers/gpio/Kconfig   |   6 -
 drivers/gpio/Makefile  |   1 -
 drivers/gpio/gpio-tps65912.c   | 153 --
 drivers/mfd/Kconfig|  26 --
 drivers/mfd/Makefile   |   4 -
 drivers/mfd/tps65912-core.c| 175 ---
 drivers/mfd/tps65912-i2c.c | 139 -
 drivers/mfd/tps65912-irq.c | 217 -
 drivers/mfd/tps65912-spi.c | 140 -
 drivers/regulator/Kconfig  |   6 -
 drivers/regulator/Makefile |   1 -
 drivers/regulator/tps65912-regulator.c | 541 -
 include/linux/mfd/tps65912.h   | 328 
 13 files changed, 1737 deletions(-)
 delete mode 100644 drivers/gpio/gpio-tps65912.c
 delete mode 100644 drivers/mfd/tps65912-core.c
 delete mode 100644 drivers/mfd/tps65912-i2c.c
 delete mode 100644 drivers/mfd/tps65912-irq.c
 delete mode 100644 drivers/mfd/tps65912-spi.c
 delete mode 100644 drivers/regulator/tps65912-regulator.c
 delete mode 100644 include/linux/mfd/tps65912.h

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b18bea0..131a89b 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -852,12 +852,6 @@ config GPIO_TPS65910
  Select this option to enable GPIO driver for the TPS65910
  chip family.
 
-config GPIO_TPS65912
-   tristate "TI TPS65912 GPIO"
-   depends on (MFD_TPS65912_I2C || MFD_TPS65912_SPI)
-   help
- This driver supports TPS65912 gpio chip
-
 config GPIO_TWL4030
tristate "TWL4030, TWL5030, and TPS659x0 GPIOs"
depends on TWL4030_CORE
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 986dbd8..f13b59f 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -97,7 +97,6 @@ obj-$(CONFIG_GPIO_TIMBERDALE) += gpio-timberdale.o
 obj-$(CONFIG_GPIO_PALMAS)  += gpio-palmas.o
 obj-$(CONFIG_GPIO_TPS6586X)+= gpio-tps6586x.o
 obj-$(CONFIG_GPIO_TPS65910)+= gpio-tps65910.o
-obj-$(CONFIG_GPIO_TPS65912)+= gpio-tps65912.o
 obj-$(CONFIG_GPIO_TS5500)  += gpio-ts5500.o
 obj-$(CONFIG_GPIO_TWL4030) += gpio-twl4030.o
 obj-$(CONFIG_GPIO_TWL6040) += gpio-twl6040.o
diff --git a/drivers/gpio/gpio-tps65912.c b/drivers/gpio/gpio-tps65912.c
deleted file mode 100644
index 9cdbc0c..000
--- a/drivers/gpio/gpio-tps65912.c
+++ /dev/null
@@ -1,153 +0,0 @@
-/*
- * Copyright 2011 Texas Instruments Inc.
- *
- * Author: Margarita Olaya 
- *
- *  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;  either version 2 of the License, or (at your
- *  option) any later version.
- *
- * This driver is based on wm8350 implementation.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-struct tps65912_gpio_data {
-   struct tps65912 *tps65912;
-   struct gpio_chip gpio_chip;
-};
-
-#define to_tgd(gc) container_of(gc, struct tps65912_gpio_data, gpio_chip)
-
-static int tps65912_gpio_get(struct gpio_chip *gc, unsigned offset)
-{
-   struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
-   struct tps65912 *tps65912 = tps65912_gpio->tps65912;
-   int val;
-
-   val = tps65912_reg_read(tps65912, TPS65912_GPIO1 + offset);
-
-   if (val & GPIO_STS_MASK)
-   return 1;
-
-   return 0;
-}
-
-static void tps65912_gpio_set(struct gpio_chip *gc, unsigned offset,
- int value)
-{
-   struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
-   struct tps65912 *tps65912 = tps65912_gpio->tps65912;
-
-   if (value)
-   tps65912_set_bits(tps65912, TPS65912_GPIO1 + offset,
-   GPIO_SET_MASK);
-   else
-   tps65912_clear_bits(tps65912, TPS65912_GPIO1 + offset,
-   GPIO_SET_MASK);
-}
-
-static int tps65912_gpio_output(struct gpio_chip *gc, unsigned offset,
-   int value)
-{
-   struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
-   struct tps65912 *tps65912 = tps65912_gpio->tps65912;
-
-   /* Set the initial value */
-   tps65912_gpio_set(gc, offset, value);
-
-   return tps65912_set_bits(tps65912, TPS65912_GPIO1 + offset,
-   GPIO_CFG_MASK);
-}
-
-static int tps65912_gpio_input(struct gpio_chip *gc, unsigned offset)
-{
-   struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
-   struct tps65912 *tps65912 = tps65912_gpio->tps65912;
-
-   return tps65912_clear_bits(tps65912, TPS65912_GPIO1 + offset,
-   GPIO_CFG

[PATCH v7 1/5] Documentation: tps65912: Add DT bindings for the TPS65912 PMIC

2015-11-18 Thread Andrew F. Davis
The TPS65912 PMIC contains several regulators and a GPIO controller.
Add bindings for the TPS65912 PMIC.

Signed-off-by: Andrew F. Davis 
---
 Documentation/devicetree/bindings/mfd/tps65912.txt | 50 ++
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/tps65912.txt

diff --git a/Documentation/devicetree/bindings/mfd/tps65912.txt 
b/Documentation/devicetree/bindings/mfd/tps65912.txt
new file mode 100644
index 000..717e66d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tps65912.txt
@@ -0,0 +1,50 @@
+* TPS65912 Power Management Integrated Circuit bindings
+
+Required properties:
+ - compatible  : Should be "ti,tps65912".
+ - reg : Slave address or chip select number (I2C / SPI).
+ - interrupt-parent: The parent interrupt controller.
+ - interrupts  : The interrupt line the device is connected to.
+ - interrupt-controller: Marks the device node as an interrupt 
controller.
+ - #interrupt-cells: The number of cells to describe an IRQ, should be 2.
+   The first cell is the IRQ number.
+   The second cell is the flags, encoded as trigger
+   masks from ../interrupt-controller/interrupts.txt.
+ - gpio-controller : Marks the device node as a GPIO Controller.
+ - #gpio-cells : Should be two.  The first cell is the pin number and
+   the second cell is used to specify flags.
+   See ../gpio/gpio.txt for more information.
+ - regulators: : List of child nodes that specify the regulator
+   initialization data. Child nodes must be named
+   after their hardware counterparts: dcdc[1-4] and
+   ldo[1-10]. Each child nodes is defined using the
+   standard binding for regulators.
+
+Example:
+
+   pmic: tps65912@2d {
+   compatible = "ti,tps65912";
+   reg = <0x2d>;
+   interrupt-parent = <&gpio1>;
+   interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   regulators {
+   dcdc1 {
+   regulator-name = "vdd_core";
+   regulator-min-microvolt = <912000>;
+   regulator-max-microvolt = <1144000>;
+   regulator-boot-on;
+   regulator-always-on;
+   };
+
+   ldo1 {
+   regulator-name = "ldo1";
+   regulator-min-microvolt = <190>;
+   regulator-max-microvolt = <190>;
+   };
+   };
+   };
-- 
1.9.1

--
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


[PATCH v2 1/2] devicetree: watchdog: add binding for Sigma Designs SMP8642 watchdog

2015-11-18 Thread Mans Rullgard
This adds a binding for the watchdog in Sigma Designs SMP8642 and
similar devices.

Signed-off-by: Mans Rullgard 
---
Changes:
- add timeout-sec property
---
 .../devicetree/bindings/watchdog/sigma,smp8642-wdt.txt | 18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/watchdog/sigma,smp8642-wdt.txt

diff --git a/Documentation/devicetree/bindings/watchdog/sigma,smp8642-wdt.txt 
b/Documentation/devicetree/bindings/watchdog/sigma,smp8642-wdt.txt
new file mode 100644
index 000..5b7ec2c
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/sigma,smp8642-wdt.txt
@@ -0,0 +1,18 @@
+Sigma Designs SMP86xx/SMP87xx watchdog
+
+Required properties:
+- compatible: Should be "sigma,smp8642-wdt"
+- reg: Specifies the physical address region
+- clocks: Should be a phandle to the clock
+
+Optional properties:
+- timeout-sec: watchdog timeout in seconds
+
+Example:
+
+watchdog@1fd00 {
+   compatible = "sigma,smp8642-wdt";
+   reg = <0x1fd00 8>;
+   clocks = <&xtal_in_clk>;
+   timeout-sec = <30>;
+};
-- 
2.6.3

--
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


Re: Re: [Qemu-devel] [PATCH v4 4/4] devicetree: update documentation for fw_cfg ARM bindings

2015-11-18 Thread François Revol
On 17/11/2015 23:14, Rob Herring wrote:
> On Mon, Nov 16, 2015 at 2:38 AM, Paolo Bonzini  wrote:
>>
>>
>> On 15/11/2015 03:07, Rob Herring wrote:
>>> We generally don't want DT docs to depend on other kernel documentation.
>>
>> DT docs do not contain a copy of the data sheets, either.  There is no
>> reason to say how to use the device (and even then, only doing so
>> partially) in the DT docs.
> 
> The difference is datasheets apply to all OS's, kernel documentation
> does not. In theory at least this could be used for other OS's, right?

Would be nice indeed, as it's part of their intended purpose.

For now we have to shoehorn things into linux-only stuff (like initrd)
because well, nobody cares enough about NetBSD to compile U-Boot with
its internal API, so let alone adding custom Haiku code.

And of course, for things linux doesn't care about (like framebuffer
description) then we're stuck trying to guess where it's at and writing
drivers for our bootloader.

So if at least people were considering they aren't the only users of
this, that'd make life better for everyone.

> Perhaps QEMU is the right place to thoroughly describe this and DT and
> sysfs docs can refer to it.

The brilliant idea of FDT was that we could have a canonical source and
blob for it where people could send patches, but of course Linux and BSD
freaks disagreed, so you now find Linux-flavoured DTs for rPi and other
things, as well as BSD versions.

Please, at least get the binding documentation for this unique and
usable for everyone!

François.

--
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


  1   2   >