Re: [PATCH 2/6] dmaengine: Add driver for TI DMA crossbar on DRA7x

2015-03-01 Thread Peter Ujfalusi
On 02/28/2015 06:00 PM, Paul Bolle wrote:
> On Tue, 2015-02-24 at 16:21 +0200, Peter Ujfalusi wrote:
>> The DRA7x has more peripherals with DMA requests than the sDMA can handle:
>> 205 vs 127. All DMA requests are routed through the DMA crossbar, which can
>> be configured to route selected incoming DMA requests to specific sDMA
>> request.
>>
>> Signed-off-by: Peter Ujfalusi 
>> ---
>>  drivers/dma/Kconfig   |   4 +
>>  drivers/dma/Makefile  |   1 +
>>  drivers/dma/ti-dma-crossbar.c | 191 
>> ++
>>  3 files changed, 196 insertions(+)
>>  create mode 100644 drivers/dma/ti-dma-crossbar.c
> 
> A simple observation follows.
> 
>> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
>> index a874b6ec6650..dfe72a0f46dc 100644
>> --- a/drivers/dma/Kconfig
>> +++ b/drivers/dma/Kconfig
>> @@ -245,6 +245,9 @@ config TI_EDMA
>>Enable support for the TI EDMA controller. This DMA
>>engine is found on TI DaVinci and AM33xx parts.
>>  
>> +config TI_DMA_CROSSBAR
>> +bool
>> +
> 
> This is a bool symbol...
> 
>>  config ARCH_HAS_ASYNC_TX_FIND_CHANNEL
>>  bool
>>  
>> @@ -330,6 +333,7 @@ config DMA_OMAP
>>  depends on ARCH_OMAP
>>  select DMA_ENGINE
>>  select DMA_VIRTUAL_CHANNELS
>> +select TI_DMA_CROSSBAR if SOC_DRA7XX
>>  
>>  config DMA_BCM2835
>>  tristate "BCM2835 DMA engine support"
>> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
>> index f915f61ec574..bc12f9a4e62b 100644
>> --- a/drivers/dma/Makefile
>> +++ b/drivers/dma/Makefile
>> @@ -38,6 +38,7 @@ obj-$(CONFIG_EP93XX_DMA) += ep93xx_dma.o
>>  obj-$(CONFIG_DMA_SA11X0) += sa11x0-dma.o
>>  obj-$(CONFIG_MMP_TDMA) += mmp_tdma.o
>>  obj-$(CONFIG_DMA_OMAP) += omap-dma.o
>> +obj-$(CONFIG_TI_DMA_CROSSBAR) += ti-dma-crossbar.o
> 
> ... so this file will be either not built or built into the kernel...
> 
>>  obj-$(CONFIG_DMA_BCM2835) += bcm2835-dma.o
>>  obj-$(CONFIG_MMP_PDMA) += mmp_pdma.o
>>  obj-$(CONFIG_DMA_JZ4740) += dma-jz4740.o
>> diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
>> new file mode 100644
>> index ..bf01434df46a
>> --- /dev/null
>> +++ b/drivers/dma/ti-dma-crossbar.c
>> @@ -0,0 +1,191 @@
>> +/*
>> + *  Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
>> + *  Author: Peter Ujfalusi 
>> + *
>> + * 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 
> 
> ...  this includes linux/module.h ...
> 
> [...]
> 
>> +static struct platform_driver ti_dma_xbar_driver = {
>> +.probe  = ti_dma_xbar_probe,
>> +.driver = {
>> +.name = "ti-dma-crossbar",
>> +.owner = THIS_MODULE,
> 
> ... is that needed to make this work?
> 
>> +.of_match_table = of_match_ptr(ti_dma_xbar_match),
>> +},
>> +};
>> +
>> +int omap_dmaxbar_init(void)
>> +{
>> +return platform_driver_register(&ti_dma_xbar_driver);
>> +}
>> +arch_initcall(omap_dmaxbar_init);
>> +
>> +MODULE_DESCRIPTION("TI DMA Crossbar");
>> +MODULE_AUTHOR("Peter Ujfalusi ");
>> +MODULE_LICENSE("GPL");
> 
> And why are these three macros needed?
> 
> By the way: there's a mismatch between the header (which is GPL v2) and
> the MODULE_LICENSE() string (which means GPL v2 or later).

True, the linux/module.h and the lines with *MODULE* in it is not needed in
case the driver will be not built as module. I have not really thought about
this to be honest, I have had these macros in most (all?) of the drivers I 
wrote.
They will be gone in V2 of the series.

Thanks,
Péter
--
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: [STLinux Kernel] [PATCH v3 5/8] watchdog: st_wdt: Add new driver for ST's LPC Watchdog

2015-03-01 Thread Peter Griffin
Hi Lee,

On Mon, 23 Feb 2015, Peter Griffin wrote:

> Hi Lee,

I noticed you sent another version, but I didn't see a reply on this point 
below.

As your now doing a re-spin for Pauls comments, I thought I would send a 
reminder
just in case you hadn't seen it.

regards,

Peter.

> 
> 
> 
> > +#ifdef CONFIG_PM_SLEEP
> > +static int st_wdog_suspend(struct device *dev)
> > +{
> > +   struct st_wdog *st_wdog = watchdog_get_drvdata(&st_wdog_dev);
> > +
> > +   if (watchdog_active(&st_wdog_dev))
> > +   st_wdog_stop(&st_wdog_dev);
> > +
> > +   st_wdog_setup(st_wdog, false);
> 
> I was expecting the suspend / resume callbacks would be disabling / enabling
> the IP clock.
> 
> Is there a reason why it doesn't?
> 
> From looking at the code by this point the watchdog has already been disabled 
> so gating
> the IP seems reasonable.
> 
> regards,
> 
> Peter
--
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/5] mfd: arizona: Add DT binding for the DMIC references

2015-03-01 Thread Lee Jones
On Sat, 28 Feb 2015, Charles Keepax wrote:

> Signed-off-by: Charles Keepax 
> ---
>  drivers/mfd/arizona-core.c |   10 ++
>  1 files changed, 10 insertions(+), 0 deletions(-)

Same here.  Requires DT/Clk Ack.

> diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
> index dddaaef..6002ce9 100644
> --- a/drivers/mfd/arizona-core.c
> +++ b/drivers/mfd/arizona-core.c
> @@ -564,6 +564,16 @@ static int arizona_of_get_core_pdata(struct arizona 
> *arizona)
>   count++;
>   }
>  
> + count = 0;
> + of_property_for_each_u32(arizona->dev->of_node, "wlf,dmic-ref", prop,
> +  cur, val) {
> + if (count == ARRAY_SIZE(arizona->pdata.dmic_ref))
> + break;
> +
> + arizona->pdata.dmic_ref[count] = val;
> + count++;
> + }
> +
>   return 0;
>  }
>  

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/5] mfd: arizona: Add DT binding for setting 32kHz clock source

2015-03-01 Thread Lee Jones
On Sat, 28 Feb 2015, Charles Keepax wrote:

> From: Richard Fitzgerald 
> 
> Signed-off-by: Richard Fitzgerald 
> Signed-off-by: Charles Keepax 
> ---
>  drivers/mfd/arizona-core.c |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)

Requires a DT, or at least a Clk Ack.

> diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
> index 09ba8f1..dddaaef 100644
> --- a/drivers/mfd/arizona-core.c
> +++ b/drivers/mfd/arizona-core.c
> @@ -552,6 +552,9 @@ static int arizona_of_get_core_pdata(struct arizona 
> *arizona)
>   ret);
>   }
>  
> + of_property_read_u32(arizona->dev->of_node, "wlf,clk32k-src",
> +  &pdata->clk32k_src);
> +
>   of_property_for_each_u32(arizona->dev->of_node, "wlf,inmode", prop,
>cur, val) {
>   if (count == ARRAY_SIZE(arizona->pdata.inmode))

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 6/9] watchdog: st_wdt: Add new driver for ST's LPC Watchdog

2015-03-01 Thread Lee Jones
On Sat, 28 Feb 2015, Paul Bolle wrote:
> On Wed, 2015-02-25 at 13:52 +, Lee Jones wrote:
> > Reviewed-by: Guenter Roeck 
> > Signed-off-by: David Paris 
> > Signed-off-by: Lee Jones 
> > ---
> >  drivers/watchdog/Kconfig  |  13 ++
> >  drivers/watchdog/Makefile |   1 +
> >  drivers/watchdog/st_lpc_wdt.c | 333 
> > ++
> >  3 files changed, 347 insertions(+)
> >  create mode 100644 drivers/watchdog/st_lpc_wdt.c
> 
> A few nits follow.

Thanks Paul, will fix.

[...]

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/3] Add ktd2692 Flash LED driver

2015-03-01 Thread Ingi Kim
Hi Jacek

On 2015년 02월 27일 17:42, Jacek Anaszewski wrote:
> Hi Ingi,
> 
> On 02/27/2015 02:01 AM, Ingi Kim wrote:
>> This patch supports KTD2692 flash LED driver
>>
>> Ingi Kim (3):
>>of: Add vendor prefix for Kinetic technologies
>>leds: ktd2692: add device tree bindings for ktd2692
>>leds: Add ktd2692 flash LED driver
>>
>>   .../devicetree/bindings/leds/leds-ktd2692.txt  |   19 ++
>>   .../devicetree/bindings/vendor-prefixes.txt|1 +
>>   drivers/leds/Kconfig   |8 +
>>   drivers/leds/Makefile  |1 +
>>   drivers/leds/leds-ktd2692.c|  245 
>> 
>>   5 files changed, 274 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/leds/leds-ktd2692.txt
>>   create mode 100644 drivers/leds/leds-ktd2692.c
>>
> 
> In your device tree binding documentation there is torch-gpio mentioned,
> but you seem not to use it in the driver.
> 
> We have already LED Flash class (/drivers/leds/led-class-flash.c) for
> this type of devices, which handles both torch and flash modes
> (flash_strobe sysfs attribute is provided for strobing the flash).
> 
> The reference drivers using LED Flash class are still pending [1], but I
> think that at least leds-aat1290 driver is almost ready for merging.
> It controls very similar device to yours.
> 
> Another advantage of using LED Flash class is that it has been designed
> to be compatible with Video for Linux 2 subsystem, which will allow for 
> registering LED Flash class devices as a V4L2 sub-devices.
> 
> Adding Sakari.
> 

Ok, I'll check LED Flash class, and add torch-gpio
Thanks,

Adding Seung-woo Kim and Inha Song
--
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] of/selftest: remove the duplicate of_changeset_init

2015-03-01 Thread Wang Long
Remove the duplicate of_changeset_init. In of_selftest_changeset
testcase, the "struct of_changeset chgset" is initialized twice,
but only once is enough. so, drop the first initializtion code.

Signed-off-by: Wang Long 
---
 drivers/of/unittest.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 0cf9a23..199fb23 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -478,7 +478,6 @@ static void __init of_selftest_changeset(void)
struct device_node *n1, *n2, *n21, *nremove, *parent, *np;
struct of_changeset chgset;
 
-   of_changeset_init(&chgset);
n1 = __of_node_dup(NULL, "/testcase-data/changeset/n1");
selftest(n1, "testcase setup failure\n");
n2 = __of_node_dup(NULL, "/testcase-data/changeset/n2");
-- 
1.8.3.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


[PATCH] ARM: dts: at919260/at91sam9g20: fix SRAM device tree node

2015-03-01 Thread Wenyou Yang
Fix PM does not work on the at91sam9g20ek board
--->8---
at91_pm_sram_init: failed to find sram device!
---<8---

Signed-off-by: Wenyou Yang 
---
 arch/arm/boot/dts/at91sam9260.dtsi |9 +++--
 arch/arm/boot/dts/at91sam9g20.dtsi |9 +
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/at91sam9260.dtsi 
b/arch/arm/boot/dts/at91sam9260.dtsi
index fff0ee6..d1eb27c 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -69,9 +69,14 @@
};
};
 
-   sram0: sram@002ff000 {
+   sram0: sram@0020 {
compatible = "mmio-sram";
-   reg = <0x002ff000 0x2000>;
+   reg = <0x0020 0x1000>;
+   };
+
+   sram1: sram@0030 {
+   compatible = "mmio-sram";
+   reg = <0x0030 0x1000>;
};
 
ahb {
diff --git a/arch/arm/boot/dts/at91sam9g20.dtsi 
b/arch/arm/boot/dts/at91sam9g20.dtsi
index f593016..eb9a62d 100644
--- a/arch/arm/boot/dts/at91sam9g20.dtsi
+++ b/arch/arm/boot/dts/at91sam9g20.dtsi
@@ -16,13 +16,14 @@
reg = <0x2000 0x0800>;
};
 
-   sram0: sram@002ff000 {
-   status = "disabled";
+   sram0: sram@0020 {
+   compatible = "mmio-sram";
+   reg = <0x0020 0x4000>;
};
 
-   sram1: sram@002fc000 {
+   sram1: sram@0030 {
compatible = "mmio-sram";
-   reg = <0x002fc000 0x8000>;
+   reg = <0x0030 0x4000>;
};
 
ahb {
-- 
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 v6 4/5] Input: add haptic drvier on max77843

2015-03-01 Thread Jaewon Kim

HI Dmitry,

On 28/02/2015 02:49, Dmitry Torokhov wrote:

On Thu, Feb 26, 2015 at 11:49:36AM +0900, Jaewon Kim wrote:

Hi Dmitry,

On 26/02/2015 10:23, Dmitry Torokhov wrote:

Hi Jaewon,

On Tue, Feb 24, 2015 at 10:29:07AM +0900, Jaewon Kim wrote:

+static void max77843_haptic_play_work(struct work_struct *work)
+{
+   struct max77843_haptic *haptic =
+   container_of(work, struct max77843_haptic, work);
+   int error;
+
+   mutex_lock(&haptic->mutex);
+
+   if (haptic->suspended) {
+   goto err_play;
+   }
+

You do not need braces around single statement. Also, this is not error
that you are handling, I'd prefer if we called this label out_unlock.

You are right.
I will change label name and remove braces.

+   error = max77843_haptic_set_duty_cycle(haptic);
+   if (error) {
+   dev_err(haptic->dev, "failed to set duty cycle: %d\n", error);
+   goto err_play;
+   }

Do you need to configure duty cycle if you stopping the playback? Or
maybe disabling pwm is enough?

It do not need to set duty cycle requisitely when disabling haptic.

I will move this function to front of max77843_haptic_enable().


+
+   if (haptic->magnitude) {
+   error = max77843_haptic_enable(haptic);
+   if (error)
+   dev_err(haptic->dev,
+   "cannot enable haptic: %d\n", error);
+   } else {
+   max77843_haptic_disable(haptic);
+   if (error)
+   dev_err(haptic->dev,
+   "cannot disable haptic: %d\n", error);

What error? You did not assign it...

Detailed error message printed in enable/disable() function.

What I was trying to say is that you do not assign new value to 'error'
variable in this path; it still carries the value from
max77843_haptic_set_duty_cycle() above and so this "if" statement will
never work and the message will never show up.

I never image at all that i am not assign 'error' variable.
I will assign it.



Thanks.



Thanks,
Jaewon Kim
--
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 v6 1/2] DT: hwspinlock: Add binding documentation for Qualcomm hwmutex

2015-03-01 Thread Andy Gross
On Fri, Feb 27, 2015 at 02:30:16PM -0800, Bjorn Andersson wrote:
> Add binding documentation for the Qualcomm Hardware Mutex.
> 
> Signed-off-by: Bjorn Andersson 
> ---

Looks fine.

Reviewed-by: Andy Gross 

-- 
Qualcomm Innovation Center, Inc.
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


[PATCH v5 2/4][resend] media: ov2640: add async probe function

2015-03-01 Thread Josh Wu
In async probe, there is a case that ov2640 is probed before the
host device which provided 'mclk'.
To support this async probe, we will get 'mclk' at first in the probe(),
if failed it will return -EPROBE_DEFER. That will let ov2640 wait for
the host device probed.

Signed-off-by: Josh Wu 
---

Changes in v5 resend:
- refine the error handling flow according to Guennadi's comment.

Changes in v5:
- don't change the ov2640_s_power() code.
- will get 'mclk' at the beginning of ov2640_probe().

 drivers/media/i2c/soc_camera/ov2640.c | 36 +--
 1 file changed, 22 insertions(+), 14 deletions(-)

diff --git a/drivers/media/i2c/soc_camera/ov2640.c 
b/drivers/media/i2c/soc_camera/ov2640.c
index 1fdce2f..16adbcc 100644
--- a/drivers/media/i2c/soc_camera/ov2640.c
+++ b/drivers/media/i2c/soc_camera/ov2640.c
@@ -1068,6 +1068,10 @@ static int ov2640_probe(struct i2c_client *client,
return -ENOMEM;
}
 
+   priv->clk = v4l2_clk_get(&client->dev, "mclk");
+   if (IS_ERR(priv->clk))
+   return -EPROBE_DEFER;
+
v4l2_i2c_subdev_init(&priv->subdev, client, &ov2640_subdev_ops);
v4l2_ctrl_handler_init(&priv->hdl, 2);
v4l2_ctrl_new_std(&priv->hdl, &ov2640_ctrl_ops,
@@ -1075,24 +1079,27 @@ static int ov2640_probe(struct i2c_client *client,
v4l2_ctrl_new_std(&priv->hdl, &ov2640_ctrl_ops,
V4L2_CID_HFLIP, 0, 1, 1, 0);
priv->subdev.ctrl_handler = &priv->hdl;
-   if (priv->hdl.error)
-   return priv->hdl.error;
-
-   priv->clk = v4l2_clk_get(&client->dev, "mclk");
-   if (IS_ERR(priv->clk)) {
-   ret = PTR_ERR(priv->clk);
-   goto eclkget;
+   if (priv->hdl.error) {
+   ret = priv->hdl.error;
+   goto err_clk;
}
 
ret = ov2640_video_probe(client);
-   if (ret) {
-   v4l2_clk_put(priv->clk);
-eclkget:
-   v4l2_ctrl_handler_free(&priv->hdl);
-   } else {
-   dev_info(&adapter->dev, "OV2640 Probed\n");
-   }
+   if (ret < 0)
+   goto err_videoprobe;
 
+   ret = v4l2_async_register_subdev(&priv->subdev);
+   if (ret < 0)
+   goto err_videoprobe;
+
+   dev_info(&adapter->dev, "OV2640 Probed\n");
+
+   return 0;
+
+err_videoprobe:
+   v4l2_ctrl_handler_free(&priv->hdl);
+err_clk:
+   v4l2_clk_put(priv->clk);
return ret;
 }
 
@@ -1100,6 +1107,7 @@ static int ov2640_remove(struct i2c_client *client)
 {
struct ov2640_priv   *priv = to_ov2640(client);
 
+   v4l2_async_unregister_subdev(&priv->subdev);
v4l2_clk_put(priv->clk);
v4l2_device_unregister_subdev(&priv->subdev);
v4l2_ctrl_handler_free(&priv->hdl);
-- 
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 v5 0/8] Xilinx Video IP Core support

2015-03-01 Thread Laurent Pinchart
Hello,

Here's the fifth, latest and greatest version of the Xilinx FPGA Video IP
Cores kernel drivers.

I won't detail in great lengths the Xilinx Video IP architecture here, as that
would result in dozens of pages of documentation. The interested reader can
refer to the Zynq ZC702 Base TRD (Targeted Reference Design) User Guide
(http://www.xilinx.com/support/documentation/boards_and_kits/zc702_zvik/2014_2/ug925-zynq-zc702-base-trd.pdf).

In a nutshell, the Xilinx Video IP Cores architecture specifies how
video-related IP cores need to be designed to interoperate and how to assemble
them in pipelines of various complexities. The concepts map neatly to the
media controller architecture, which this patch set uses extensively.

The series starts with various new V4L2 core features, bug fixes or cleanups,
with a small documentation enhancement (1/8), the addition of new media bus
formats needed by the new drivers (2/8 to 4/8) and a new V4L2 OF link
parsing function (5/8).

The last three patches are the core of this series.

Patch 6/8 adds support for the Xilinx Video IP architecture core in the form
of a base object to model video IP cores (xilinx-vip.c - Video IP), a
framework that parses a DT representation of a video pipeline and connects the
corresponding V4L2 subdevices together (xilinx-vipp.c - Video IP Pipeline) and
a glue between the Video DMA engine driver and the V4L2 API (xilinx-dma.c).

Patch 7/8 adds a driver for the Video Timing Controller (VTC) IP core. While
not strictly a video processing IP core, the VTC is required by other video IP
core drivers.

Finally, patch 8/8 adds a first video IP core driver for the Test Pattern
Generator (TPG). Drivers for other IP cores will be added in the future.

Changes since v4:

- Clarify the v4l2_of_parse_link() documentation
- Use a DT format description closer to the hardware
- Document the xvip_device clk field
- Fix a crash in the TPG probe error path

Cc: devicetree@vger.kernel.org

Hyun Kwon (2):
  v4l: Sort YUV formats of v4l2_mbus_pixelcode
  v4l: Add VUY8 24 bits bus format

Laurent Pinchart (6):
  media: entity: Document the media_entity_ops structure
  v4l: Add RBG and RGB 8:8:8 media bus formats on 24 and 32 bit busses
  v4l: of: Add v4l2_of_parse_link() function
  v4l: xilinx: Add Xilinx Video IP core
  v4l: xilinx: Add Video Timing Controller driver
  v4l: xilinx: Add Test Pattern Generator driver

 Documentation/DocBook/media/v4l/subdev-formats.xml | 719 +---
 .../devicetree/bindings/media/xilinx/video.txt |  35 +
 .../devicetree/bindings/media/xilinx/xlnx,v-tc.txt |  33 +
 .../bindings/media/xilinx/xlnx,v-tpg.txt   |  71 ++
 .../bindings/media/xilinx/xlnx,video.txt   |  55 ++
 MAINTAINERS|  10 +
 drivers/media/platform/Kconfig |   1 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/xilinx/Kconfig  |  23 +
 drivers/media/platform/xilinx/Makefile |   5 +
 drivers/media/platform/xilinx/xilinx-dma.c | 753 +
 drivers/media/platform/xilinx/xilinx-dma.h | 109 +++
 drivers/media/platform/xilinx/xilinx-tpg.c | 926 +
 drivers/media/platform/xilinx/xilinx-vip.c | 309 +++
 drivers/media/platform/xilinx/xilinx-vip.h | 236 ++
 drivers/media/platform/xilinx/xilinx-vipp.c| 669 +++
 drivers/media/platform/xilinx/xilinx-vipp.h|  49 ++
 drivers/media/platform/xilinx/xilinx-vtc.c | 380 +
 drivers/media/platform/xilinx/xilinx-vtc.h |  42 +
 drivers/media/v4l2-core/v4l2-of.c  |  61 ++
 include/dt-bindings/media/xilinx-vip.h |  39 +
 include/media/media-entity.h   |   9 +
 include/media/v4l2-of.h|  27 +
 include/uapi/linux/Kbuild  |   1 +
 include/uapi/linux/media-bus-format.h  |  19 +-
 include/uapi/linux/xilinx-v4l2-controls.h  |  73 ++
 26 files changed, 4337 insertions(+), 319 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/xilinx/video.txt
 create mode 100644 Documentation/devicetree/bindings/media/xilinx/xlnx,v-tc.txt
 create mode 100644 
Documentation/devicetree/bindings/media/xilinx/xlnx,v-tpg.txt
 create mode 100644 
Documentation/devicetree/bindings/media/xilinx/xlnx,video.txt
 create mode 100644 drivers/media/platform/xilinx/Kconfig
 create mode 100644 drivers/media/platform/xilinx/Makefile
 create mode 100644 drivers/media/platform/xilinx/xilinx-dma.c
 create mode 100644 drivers/media/platform/xilinx/xilinx-dma.h
 create mode 100644 drivers/media/platform/xilinx/xilinx-tpg.c
 create mode 100644 drivers/media/platform/xilinx/xilinx-vip.c
 create mode 100644 drivers/media/platform/xilinx/xilinx-vip.h
 create mode 100644 drivers/media/platform/xilinx/xilinx-vipp.c
 create mode 100644 drivers/media/platform/xilinx/xilinx-vipp.h
 c

[PATCH v5 6/8] v4l: xilinx: Add Xilinx Video IP core

2015-03-01 Thread Laurent Pinchart
Xilinx platforms have no hardwired video capture or video processing
interface. Users create capture and memory to memory processing
pipelines in the FPGA fabric to suit their particular needs, by
instantiating video IP cores from a large library.

The Xilinx Video IP core is a framework that models a video pipeline
described in the device tree and expose the pipeline to userspace
through the media controller and V4L2 APIs.

Signed-off-by: Laurent Pinchart 
Signed-off-by: Hyun Kwon 
Signed-off-by: Radhey Shyam Pandey 
Signed-off-by: Michal Simek 

---

Cc: devicetree@vger.kernel.org

Changes since v4:

- Use a DT format description closer to the hardware
- Document the xvip_device clk field

Changes since v3:

- Rename V4L2_MBUS_FMT_* to MEDIA_BUS_FMT_*
- Cleanup unused vdma configuration.
- Add resource init and cleanup helpers
- Return buffers to vb2 when media pipeline start fails

Changes since v2:

- Remove explicit trailing \0 after snprintf
- Don't hardcode colorspace

Changes since v1:

- Remove unnecessary fields from struct xvip_dma_buffer
- Fix querycap capabilities and bus_info reporting
- Refuse to set format when the queue is busy
- Return buffers to vb2 when start_streaming fails
- Use vb2 fops and ioctl ops

v1 was made of the following individual patches.

media: xilinx: vip: Add yuv444 and bayer formats
media: xilinx: vip: Remove _TIMING_ from register definition
media: xilinx: dma: Add vidioc_enum_fmt_vid_cap callback
media: xilinx: dma: Fix alignments of xvip_dma_fops definition
media: xilinx: dma: Workaround for bytesperline
media: xilinx: vip: Add default min/max height/width definitions
media: xilinx: vip: Add common sink/source pad IDs
media: xilinx: vip: Add xvip_set_format_size()
media: xilinx: vip: Add xvip_enum_mbus_code()
media: xilinx: vip: Add xvip_enum_frame_size()
media: xilinx: vip: Add register clear and set functions
media: xilinx: vip: Add xvip_start()
media: xilinx: vip: Add xvip_stop()
media: xilinx: vip: Add xvip_set_frame_size()
media: xilinx: vip: Add enable/disable reg update functions
media: xilinx: vip: Add xvip_print_version()
media: xilinx: vip: Add xvip_reset()
media: xilinx: vip: Add xvip_get_frame_size()
media: xilinx: vip: Add suspend/resume helper functions
media: xilinx: vip: Change the return value of xvip_get_format_by_code()
media: xilinx: vip: Change the return value of xvip_of_get_format()
media: xilinx: vip: Change the return value of xvip_get_format_by_fourcc()
media: xilinx: vipp: Remove of_match_ptr()
media: xilinx: vipp: Add control to inherit subdevice controls
media: xilinx: Make disconnected video nodes return -EPIPE at stream on
media: xilinx: Make links configurable
media: xilinx: Rename xvip_pipeline_entity to xvip_graph_entity
media: xilinx: Rename xvip_pipeline to xvip_composite_device
media: xilinx: Rename xvipp_pipeline_* functions to xvip_graph_*
media: xilinx: Rename xvipp_v4l2_* functions to xvip_composite_v4l2_*
media: xilinx: Rename xvipp_* functions to xvip_composite_*
media: xilinx: Move pipeline management code to xilinx-dma.c
media: xilinx: Add missing mutex_destroy call
media: xilinx: Create xvip_pipeline structure
media: xilinx: Support more than two VDMAs in DT
media: xilinx: dma: Change vdma configuration to cyclic-mode
Revert "media: xilinx: dma: Workaround for bytesperline"
media: xilinx: Added DMA error handling
media: xilinx: Fix error handling
media: xilinx: Reordered mutexes initialization
media: xilinx: vipp: Add devicetree bindings documentation
media: xilinx: Reordered mutexes initialization
media: xilinx: Set format description in enum_fmt
media: xilinx: Remove global control handler
media: xilinx: dma: Use the interleaved dmaengine API
xilinx: Remove .owner field for drivers
v4l: xilinx: video: Rename compatible string to xlnx,video
v4l: xilinx: Remove axi- prefix from DT properties
v4l: xilinx: dma: Give back queued buffers at streamoff time
---
 .../devicetree/bindings/media/xilinx/video.txt |  35 +
 .../bindings/media/xilinx/xlnx,video.txt   |  55 ++
 MAINTAINERS|   9 +
 drivers/media/platform/Kconfig |   1 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/xilinx/Kconfig  |  10 +
 drivers/media/platform/xilinx/Makefile |   3 +
 drivers/media/platform/xilinx/xilinx-dma.c | 753 +
 drivers/media/platform/xilinx/xilinx-dma.h | 109 +++
 drivers/media/platform/xilinx/xilinx-vip.c | 309 +
 drivers/media/platform/xilinx/xilinx-vip.h | 236 +++
 drivers/media/platform/xilinx/xilinx-vipp.c| 669 ++
 drivers/media/platform/xilinx/xilinx-vipp.h|  49 ++
 include/dt-bindings/media/xilinx-vip.h |  39 ++
 14 files changed, 2279 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/xilinx/video.txt
 create mode 100644 
Documentation/devicetree/bindings/media/xilinx/xlnx,v

[PATCH v5 7/8] v4l: xilinx: Add Video Timing Controller driver

2015-03-01 Thread Laurent Pinchart
The Video Timing Controller (VTC) includes a timing detector and/or a
timing generator. Only the generator is currently supported.

Signed-off-by: Laurent Pinchart 
Signed-off-by: Michal Simek 
Acked-by: Hans Verkuil 

---

Cc: devicetree@vger.kernel.org

Changes since v3:

- Use xvip_init_resources()

v1 was made of the following individual patches.

xilinx: Remove .owner field for drivers
v4l: xilinx: vtc: Rename compatible string to xlnx,v-tc
---
 .../devicetree/bindings/media/xilinx/xlnx,v-tc.txt |  33 ++
 drivers/media/platform/xilinx/Kconfig  |   6 +
 drivers/media/platform/xilinx/Makefile |   1 +
 drivers/media/platform/xilinx/xilinx-vtc.c | 380 +
 drivers/media/platform/xilinx/xilinx-vtc.h |  42 +++
 5 files changed, 462 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/xilinx/xlnx,v-tc.txt
 create mode 100644 drivers/media/platform/xilinx/xilinx-vtc.c
 create mode 100644 drivers/media/platform/xilinx/xilinx-vtc.h

diff --git a/Documentation/devicetree/bindings/media/xilinx/xlnx,v-tc.txt 
b/Documentation/devicetree/bindings/media/xilinx/xlnx,v-tc.txt
new file mode 100644
index 000..2aed3b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/xilinx/xlnx,v-tc.txt
@@ -0,0 +1,33 @@
+Xilinx Video Timing Controller (VTC)
+
+
+The Video Timing Controller is a general purpose video timing generator and
+detector.
+
+Required properties:
+
+  - compatible: Must be "xlnx,v-tc-6.1".
+
+  - reg: Physical base address and length of the registers set for the device.
+
+  - clocks: Must contain a clock specifier for the VTC core and timing
+interfaces clock.
+
+Optional properties:
+
+  - xlnx,detector: The VTC has a timing detector
+  - xlnx,generator: The VTC has a timing generator
+
+  At least one of the xlnx,detector and xlnx,generator properties must be
+  specified.
+
+
+Example:
+
+   vtc: vtc@43c4 {
+   compatible = "xlnx,v-tc-6.1";
+   reg = <0x43c4 0x1>;
+
+   clocks = <&clkc 15>;
+   xlnx,generator;
+   };
diff --git a/drivers/media/platform/xilinx/Kconfig 
b/drivers/media/platform/xilinx/Kconfig
index f4347e9..19db823 100644
--- a/drivers/media/platform/xilinx/Kconfig
+++ b/drivers/media/platform/xilinx/Kconfig
@@ -7,4 +7,10 @@ config VIDEO_XILINX
 
 if VIDEO_XILINX
 
+config VIDEO_XILINX_VTC
+   tristate "Xilinx Video Timing Controller"
+   depends on VIDEO_XILINX
+   ---help---
+  Driver for the Xilinx Video Timing Controller
+
 endif #VIDEO_XILINX
diff --git a/drivers/media/platform/xilinx/Makefile 
b/drivers/media/platform/xilinx/Makefile
index 3ef9c8e..6611e32 100644
--- a/drivers/media/platform/xilinx/Makefile
+++ b/drivers/media/platform/xilinx/Makefile
@@ -1,3 +1,4 @@
 xilinx-video-objs += xilinx-dma.o xilinx-vip.o xilinx-vipp.o
 
 obj-$(CONFIG_VIDEO_XILINX) += xilinx-video.o
+obj-$(CONFIG_VIDEO_XILINX_VTC) += xilinx-vtc.o
diff --git a/drivers/media/platform/xilinx/xilinx-vtc.c 
b/drivers/media/platform/xilinx/xilinx-vtc.c
new file mode 100644
index 000..194bdf2
--- /dev/null
+++ b/drivers/media/platform/xilinx/xilinx-vtc.c
@@ -0,0 +1,380 @@
+/*
+ * Xilinx Video Timing Controller
+ *
+ * Copyright (C) 2013-2014 Ideas on Board
+ * Copyright (C) 2013-2014 Xilinx, Inc.
+ *
+ * Contacts: Hyun Kwon 
+ *   Laurent Pinchart 
+ *
+ * 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 "xilinx-vip.h"
+#include "xilinx-vtc.h"
+
+#define XVTC_CONTROL_FIELD_ID_POL_SRC  (1 << 26)
+#define XVTC_CONTROL_ACTIVE_CHROMA_POL_SRC (1 << 25)
+#define XVTC_CONTROL_ACTIVE_VIDEO_POL_SRC  (1 << 24)
+#define XVTC_CONTROL_HSYNC_POL_SRC (1 << 23)
+#define XVTC_CONTROL_VSYNC_POL_SRC (1 << 22)
+#define XVTC_CONTROL_HBLANK_POL_SRC(1 << 21)
+#define XVTC_CONTROL_VBLANK_POL_SRC(1 << 20)
+#define XVTC_CONTROL_CHROMA_SRC(1 << 18)
+#define XVTC_CONTROL_VBLANK_HOFF_SRC   (1 << 17)
+#define XVTC_CONTROL_VSYNC_END_SRC (1 << 16)
+#define XVTC_CONTROL_VSYNC_START_SRC   (1 << 15)
+#define XVTC_CONTROL_ACTIVE_VSIZE_SRC  (1 << 14)
+#define XVTC_CONTROL_FRAME_VSIZE_SRC   (1 << 13)
+#define XVTC_CONTROL_HSYNC_END_SRC (1 << 11)
+#define XVTC_CONTROL_HSYNC_START_SRC   (1 << 10)
+#define XVTC_CONTROL_ACTIVE_HSIZE_SRC  (1 << 9)
+#define XVTC_CONTROL_FRAME_HSIZE_SRC   (1 << 8)
+#define XVTC_CONTROL_SYNC_ENABLE   (1 << 5)
+#define XVTC_CONTROL_DET_ENABLE(1 << 3)
+#define XVTC_CONTROL_GEN_ENABLE(1 << 2)
+
+#define XVTC_STATUS_FSYNC(n)   ((n) << 16)
+#define XVTC_STATUS_G

Re: [PATCH v5 2/4] media: ov2640: add async probe function

2015-03-01 Thread Josh Wu

On 3/2/2015 5:06 AM, Guennadi Liakhovetski wrote:

Hi Josh,

Thanks for a patch update. I think it looks good as a first step in your
patch series, just a minor comment below:

On Tue, 10 Feb 2015, Josh Wu wrote:


In async probe, there is a case that ov2640 is probed before the
host device which provided 'mclk'.
To support this async probe, we will get 'mclk' at first in the probe(),
if failed it will return -EPROBE_DEFER. That will let ov2640 wait for
the host device probed.

Signed-off-by: Josh Wu 
---

Changes in v5:
- don't change the ov2640_s_power() code.
- will get 'mclk' at the beginning of ov2640_probe().

Changes in v4: None
Changes in v3: None
Changes in v2: None

  drivers/media/i2c/soc_camera/ov2640.c | 29 +++--
  1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/drivers/media/i2c/soc_camera/ov2640.c 
b/drivers/media/i2c/soc_camera/ov2640.c
index 1fdce2f..057dd49 100644
--- a/drivers/media/i2c/soc_camera/ov2640.c
+++ b/drivers/media/i2c/soc_camera/ov2640.c
@@ -1068,6 +1068,10 @@ static int ov2640_probe(struct i2c_client *client,
return -ENOMEM;
}
  
+	priv->clk = v4l2_clk_get(&client->dev, "mclk");

+   if (IS_ERR(priv->clk))
+   return -EPROBE_DEFER;
+
v4l2_i2c_subdev_init(&priv->subdev, client, &ov2640_subdev_ops);
v4l2_ctrl_handler_init(&priv->hdl, 2);
v4l2_ctrl_new_std(&priv->hdl, &ov2640_ctrl_ops,
@@ -1075,24 +1079,28 @@ static int ov2640_probe(struct i2c_client *client,
v4l2_ctrl_new_std(&priv->hdl, &ov2640_ctrl_ops,
V4L2_CID_HFLIP, 0, 1, 1, 0);
priv->subdev.ctrl_handler = &priv->hdl;
-   if (priv->hdl.error)
-   return priv->hdl.error;
-
-   priv->clk = v4l2_clk_get(&client->dev, "mclk");
-   if (IS_ERR(priv->clk)) {
-   ret = PTR_ERR(priv->clk);
-   goto eclkget;
+   if (priv->hdl.error) {
+   ret = priv->hdl.error;
+   goto err_clk;
}
  
  	ret = ov2640_video_probe(client);

if (ret) {
-   v4l2_clk_put(priv->clk);
-eclkget:
-   v4l2_ctrl_handler_free(&priv->hdl);
+   goto err_videoprobe;

Since you add a "goto" here, you don't need an "else" after it, and the
"probed" success message should go down, so, just make it

ret = ov2640_video_probe(client);
if (ret < 0)
goto err_videoprobe;

ret = v4l2_async_register_subdev(&priv->subdev);
if (ret < 0)
goto err_videoprobe;

dev_info(&adapter->dev, "OV2640 Probed\n");

return 0;

err_...


Yes. This looks better.
I'll update and resend this patch. This change is independent and no 
need to resend the whole patch series.

Thanks.

Best Regards,
Josh Wu



Thanks
Guennadi


} else {
dev_info(&adapter->dev, "OV2640 Probed\n");
}
  
+	ret = v4l2_async_register_subdev(&priv->subdev);

+   if (ret < 0)
+   goto err_videoprobe;
+
+   return 0;
+
+err_videoprobe:
+   v4l2_ctrl_handler_free(&priv->hdl);
+err_clk:
+   v4l2_clk_put(priv->clk);
return ret;
  }
  
@@ -1100,6 +1108,7 @@ static int ov2640_remove(struct i2c_client *client)

  {
struct ov2640_priv   *priv = to_ov2640(client);
  
+	v4l2_async_unregister_subdev(&priv->subdev);

v4l2_clk_put(priv->clk);
v4l2_device_unregister_subdev(&priv->subdev);
v4l2_ctrl_handler_free(&priv->hdl);
--
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 v5 8/8] v4l: xilinx: Add Test Pattern Generator driver

2015-03-01 Thread Laurent Pinchart
The TPG generates multiple static or dynamic test patterns. The driver
currently hardcodes the pattern to the moving box pattern.

Signed-off-by: Christian Kohn 
Signed-off-by: Hyun Kwon 
Signed-off-by: Laurent Pinchart 
Signed-off-by: Michal Simek 
Acked-by: Hans Verkuil 

---

Cc: devicetree@vger.kernel.org

Changes since v4:

- Use the v5 DT format description
- Fix a crash in the probe error path

Changes since v3:

- Rename V4L2_MBUS_FMT_* to MEDIA_BUS_FMT_*
- Use xvip_init_resources()

Changes since v1:

v4l: xilinx: tpg: Fix typo

v1 was made of the following individual patches.

media: xilinx: tpg: Add the version number in DT compatible string
media: xilinx: tpg: Use  instead of 
media: xilinx: tpg: Reset in probe()
media: xilinx: tpg: Add controls for TPG
media: xilinx: tpg: Add the default format
media: xilinx: tpg: Fix alignments around __xtpg_get_pad_format()
media: xilinx: tpg: Change 'format' to 'fmt'
media: xilinx: tpg: Fix alignments
media: xilinx: tpg: Fix the structure comment
media: xilinx: tpg: Use xvip_enum_mbus_code()
media: xilinx: tpg: Use xvip_enum_frame_size()
media: xilinx: tpg: Use xvip_set_format_size()
media: xilinx: tpg: Use xvip_start()
media: xilinx: tpg: Use xvip_stop()
media: xilinx: tpg: Use xvip_set_frame_size()
media: xilinx: tpg: Use xvip_print_version()
media: xilinx: tpg: Add power management functions
media: xilinx: tpg: Remove of_match_ptr()
media: xilinx: tpg: Fix devm_ioremap_resource() return value check
media: xilinx: tpg: Make number of pads dynamic
media: xilinx: tpg: Configure the bayer phase
media: xilinx: tpg: Allocate active formats for each pad
media: xilinx: tpg: Include the format infomation in 'port' node
media: xilinx: tpg: Add VTC support
media: xilinx: tpg: Add video timing mux support
media: xilinx: tpg: Default to the color bars test pattern
media: xilinx: tpg: Disallow switching passthrough mode during streaming
media: xilinx: tpg: Move control IDs to xilinx-controls.h
media: xilinx: tpg: Make horizontal and vertical blanking configurable
media: xilinx: tpg: Ignore unconnected input ports
xilinx: Remove .owner field for drivers
v4l: xilinx: tpg: Rename compatible string to xlnx,v-tpg
v4l: xilinx: tpg: Lock the control handler when modifying control range
v4l: xilinx: tpg: Use devm_gpiod_get_optional
v4l: xilinx: tpg: Remove axi- prefix from DT properties
---
 .../bindings/media/xilinx/xlnx,v-tpg.txt   |  71 ++
 MAINTAINERS|   1 +
 drivers/media/platform/xilinx/Kconfig  |   7 +
 drivers/media/platform/xilinx/Makefile |   1 +
 drivers/media/platform/xilinx/xilinx-tpg.c | 926 +
 include/uapi/linux/Kbuild  |   1 +
 include/uapi/linux/xilinx-v4l2-controls.h  |  73 ++
 7 files changed, 1080 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/xilinx/xlnx,v-tpg.txt
 create mode 100644 drivers/media/platform/xilinx/xilinx-tpg.c
 create mode 100644 include/uapi/linux/xilinx-v4l2-controls.h

diff --git a/Documentation/devicetree/bindings/media/xilinx/xlnx,v-tpg.txt 
b/Documentation/devicetree/bindings/media/xilinx/xlnx,v-tpg.txt
new file mode 100644
index 000..9dd86b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/xilinx/xlnx,v-tpg.txt
@@ -0,0 +1,71 @@
+Xilinx Video Test Pattern Generator (TPG)
+-
+
+Required properties:
+
+- compatible: Must contain at least one of
+
+"xlnx,v-tpg-5.0" (TPG version 5.0)
+"xlnx,v-tpg-6.0" (TPG version 6.0)
+
+  TPG versions backward-compatible with previous versions should list all
+  compatible versions in the newer to older order.
+
+- reg: Physical base address and length of the registers set for the device.
+
+- clocks: Reference to the video core clock.
+
+- xlnx,video-format, xlnx,video-width: Video format and width, as defined in
+  video.txt.
+
+- port: Video port, using the DT bindings defined in ../video-interfaces.txt.
+  The TPG has a single output port numbered 0.
+
+Optional properties:
+
+- xlnx,vtc: A phandle referencing the Video Timing Controller that generates
+  video timings for the TPG test patterns.
+
+- timing-gpios: Specifier for a GPIO that controls the timing mux at the TPG
+  input. The GPIO active level corresponds to the selection of VTC-generated
+  video timings.
+
+The xlnx,vtc and timing-gpios properties are mandatory when the TPG is
+synthesized with two ports and forbidden when synthesized with one port.
+
+Example:
+
+   tpg_0: tpg@4005 {
+   compatible = "xlnx,v-tpg-6.0", "xlnx,v-tpg-5.0";
+   reg = <0x4005 0x1>;
+   clocks = <&clkc 15>;
+
+   xlnx,vtc = <&vtc_3>;
+   timing-gpios = <&ps7_gpio_0 55 GPIO_ACTIVE_LOW>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+  

Re: [PATCH v6 2/5] power: max77843_charger: Add Max77843 charger device driver

2015-03-01 Thread Beomho Seo
On 03/01/2015 05:03 AM, Paul Bolle wrote:
> On Tue, 2015-02-24 at 10:29 +0900, Jaewon Kim wrote:
>> diff --git a/drivers/power/max77843_charger.c 
>> b/drivers/power/max77843_charger.c
>> new file mode 100644
>> index 000..392eebc1a
>> --- /dev/null
>> +++ b/drivers/power/max77843_charger.c
>> @@ -0,0 +1,508 @@
>> +/*
>> + * Charger driver for Maxim MAX77843
>> + *
>> + * Copyright (C) 2015 Samsung Electronics, Co., Ltd.
>> + * Author: Beomho Seo 
>> + *
>> + * 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 bythe Free Software Foundation.
> 
> There's "bythe" again.
> 
>> + */
> 
> [...]
> 

OK, I will add spacer.

>> +MODULE_LICENSE("GPL");
> 
> And that should probably be
> MODULE_LICENSE("GPL v2");
> 
> 
> Paul Bolle
> 
> 

OK, I will change license.
Thank you for your review.

Thanks,
Beomho Seo

--
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 v6 3/5] power: max77843_battery: Add Max77843 fuel gauge device driver

2015-03-01 Thread Beomho Seo
On 03/01/2015 05:00 AM, Paul Bolle wrote:
> On Tue, 2015-02-24 at 10:29 +0900, Jaewon Kim wrote:
>> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
>> index 994793d..555e436 100644
>> --- a/drivers/power/Kconfig
>> +++ b/drivers/power/Kconfig
>> @@ -212,6 +212,15 @@ config BATTERY_MAX17042
>>with MAX17042. This driver also supports max17047/50 chips which are
>>improved version of max17042.
>>  
>> +config BATTERY_MAX77843
>> +tristate "Maxim MAX77843 Fuel Gauge"
>> +depends on MFD_MAX77843
>> +help
>> +  This adds support for battery fuel gauge in Maxim MAX77843. It is
>> +  fuel-gauge for a lithium-ion batteries with a single cell and can be
>> +  found in portable devices. The MAX17040 is configured to operate with
> 
> Could MAX17040 be a copy/paste error?
> 
>> +  a single lithium cell.
>> +
>>  config BATTERY_Z2
>>  tristate "Z2 battery driver"
>>  depends on I2C && MACH_ZIPIT2
> 
> [...]
> 
>> diff --git a/drivers/power/max77843_battery.c 
>> b/drivers/power/max77843_battery.c
>> new file mode 100644
>> index 000..0c59a16
>> --- /dev/null
>> +++ b/drivers/power/max77843_battery.c
>> @@ -0,0 +1,286 @@
>> +/*
>> + * Fuel gauge driver for Maxim MAX77843
>> + *
>> + * Copyright (C) 2015 Samsung Electronics, Co., Ltd.
>> + * Author: Beomho Seo 
>> + *
>> + * 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 bythe Free Software Foundation.
>> + */
> 
> I did
> git grep "bythe Free" next-20150227
> 
> and it returned five hits. This would be the sixth.
> 
> Anyhow, this states that this file is licensed GPL v2.
> 
> [...]
> 
>> +MODULE_LICENSE("GPL");
> 
> So this should probably be
> MODULE_LICENSE("GPL v2");
> 
> 
> Paul Bolle
> 

Thank you for your review.
I will fix next revision.

Thanks,

Beomho Seo

> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" 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] ARM: OMAP2: hwmod: AM43XX: Add hwmod support for HDQ-1W

2015-03-01 Thread Paul Walmsley
Hi

On Fri, 27 Feb 2015, Vignesh R wrote:

> From: "Poddar, Sourav" 
> 
> This patch adds hwmod data for hdq/1w driver on AM43xx.
> 
> Signed-off-by: Sourav Poddar 
> [vigne...@ti.com: Ported patch to v4.0-rc1]
> Signed-off-by: Vignesh R 
> ---
>  arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 36 
> ++
>  arch/arm/mach-omap2/prcm43xx.h |  1 +
>  2 files changed, 37 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c 
> b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> index 8eb85925e444..d4f1df28475c 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
> @@ -20,6 +20,7 @@
>  #include "omap_hwmod_33xx_43xx_common_data.h"
>  #include "prcm43xx.h"
>  #include "omap_hwmod_common_data.h"
> +#include "hdq1w.h"
>  
>  
>  /* IP blocks */
> @@ -516,6 +517,33 @@ static struct omap_hwmod am43xx_dss_rfbi_hwmod = {
>   .parent_hwmod   = &am43xx_dss_core_hwmod,
>  };
>  
> +/* HDQ1W */
> +static struct omap_hwmod_class_sysconfig am43xx_hdq1w_sysc = {
> + .rev_offs   = 0x,
> + .sysc_offs  = 0x0014,
> + .syss_offs  = 0x0018,
> + .sysc_flags = (SYSC_HAS_SOFTRESET),

This is missing the SYSC_HAS_AUTOIDLE bit.  Is this intentional?

> + .sysc_fields= &omap_hwmod_sysc_type1,
> +};
> +
> +static struct omap_hwmod_class am43xx_hdq1w_hwmod_class = {
> + .name   = "hdq1w",
> + .sysc   = &am43xx_hdq1w_sysc,
> + .reset  = &omap_hdq1w_reset,
> +};
> +
> +static struct omap_hwmod am43xx_hdq1w_hwmod = {
> + .name   = "hdq1w",
> + .class  = &am43xx_hdq1w_hwmod_class,
> + .clkdm_name = "l4ls_clkdm",
> + .prcm = {
> + .omap4 = {
> + .clkctrl_offs = AM43XX_CM_PER_HDQ1W_CLKCTRL_OFFSET,
> + .modulemode   = MODULEMODE_SWCTRL,
> + },
> + },
> +};
> +
>  /* Interfaces */
>  static struct omap_hwmod_ocp_if am43xx_l3_main__l4_hs = {
>   .master = &am33xx_l3_main_hwmod,
> @@ -790,6 +818,13 @@ static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_rfbi = 
> {
>   .user   = OCP_USER_MPU | OCP_USER_SDMA,
>  };
>  
> +static struct omap_hwmod_ocp_if am43xx_l4_ls__hdq1w = {
> + .master = &am33xx_l4_ls_hwmod,
> + .slave  = &am43xx_hdq1w_hwmod,
> + .clk= "l4ls_gclk",
> + .user   = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
>  static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
>   &am33xx_l4_wkup__synctimer,
>   &am43xx_l4_ls__timer8,
> @@ -889,6 +924,7 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] 
> __initdata = {
>   &am43xx_l4_ls__dss,
>   &am43xx_l4_ls__dss_dispc,
>   &am43xx_l4_ls__dss_rfbi,
> + &am43xx_l4_ls__hdq1w,
>   NULL,
>  };
>  
> diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h
> index ad7b3e9977f8..48df3b55057e 100644
> --- a/arch/arm/mach-omap2/prcm43xx.h
> +++ b/arch/arm/mach-omap2/prcm43xx.h
> @@ -143,5 +143,6 @@
>  #define AM43XX_CM_PER_USB_OTG_SS1_CLKCTRL_OFFSET0x0268
>  #define AM43XX_CM_PER_USBPHYOCP2SCP1_CLKCTRL_OFFSET  0x05C0
>  #define AM43XX_CM_PER_DSS_CLKCTRL_OFFSET 0x0a20
> +#define AM43XX_CM_PER_HDQ1W_CLKCTRL_OFFSET   0x04a0
>  
>  #endif
> -- 
> 1.9.1
> 


- Paul
--
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 v6 3/3] ARM: dts: vf610: add Miscellaneous System Control Module (MSCM)

2015-03-01 Thread Stefan Agner
Add the Miscellaneous System Control Module (MSCM) to the base
device tree for Vybrid SoC's. This module contains registers
to get information of the individual and current (accessing)
CPU. In a second block, there is an interrupt router, which
handles the routing of the interrupts between the two CPU cores
on VF6xx variants of the SoC. However, also on single core
variants the interrupt router needs to be configured in order
to receive interrupts on the CPU's interrupt controller. Almost
all peripheral interrupts are routed through the router, hence
the MSCM module is the default interrupt parent for this SoC.

In a earlier commit the interrupt nodes were moved out of the
peripheral nodes and specified in the CPU specific vf500.dtsi
device tree. This allowed to use the base device tree vfxxx.dtsi
also for a Cortex-M4 specific device tree, which uses different
interrupt nodes due to the NVIC interrupt controller. However,
since the interrupt parent for peripherals is the MSCM module
independently which CPU the device tree is used for, we can move
the interrupt nodes into the base device tree vfxxx.dtsi again.
Depending on which CPU this base device tree will be used with,
the correct parent interrupt controller has to be assigned to
the MSCM-IR node (GIC or NVIC). The driver takes care of the
parent interrupt controller specific needs (interrupt-cells).

Acked-by: Marc Zyngier 
Signed-off-by: Stefan Agner 
---
 arch/arm/boot/dts/vf500.dtsi | 137 ++-
 arch/arm/boot/dts/vfxxx.dtsi |  49 
 2 files changed, 53 insertions(+), 133 deletions(-)

diff --git a/arch/arm/boot/dts/vf500.dtsi b/arch/arm/boot/dts/vf500.dtsi
index 1dbf8d2..e976d2f 100644
--- a/arch/arm/boot/dts/vf500.dtsi
+++ b/arch/arm/boot/dts/vf500.dtsi
@@ -24,14 +24,13 @@
};
 
soc {
-   interrupt-parent = <&intc>;
-
aips-bus@4000 {
 
intc: interrupt-controller@40002000 {
compatible = "arm,cortex-a9-gic";
#interrupt-cells = <3>;
interrupt-controller;
+   interrupt-parent = <&intc>;
reg = <0x40003000 0x1000>,
  <0x40002100 0x100>;
};
@@ -40,145 +39,17 @@
compatible = "arm,cortex-a9-global-timer";
reg = <0x40002200 0x20>;
interrupts = ;
+   interrupt-parent = <&intc>;
clocks = <&clks VF610_CLK_PLATFORM_BUS>;
};
};
};
 };
 
-&adc0 {
-   interrupts = ;
-};
-
-&adc1 {
-   interrupts = ;
-};
-
-&can0 {
-   interrupts = ;
-};
-
-&can1 {
-   interrupts = ;
-};
-
-&dspi0 {
-   interrupts = ;
-};
-
-&edma0 {
-   interrupts = ,
-   ;
-   interrupt-names = "edma-tx", "edma-err";
-};
-
-&edma1 {
-   interrupts = ,
-   ;
-   interrupt-names = "edma-tx", "edma-err";
-};
-
-&esdhc1 {
-   interrupts = ;
-};
-
-&fec0 {
-   interrupts = ;
-};
-
-&fec1 {
-   interrupts = ;
-};
-
-&ftm {
-   interrupts = ;
-};
-
-&gpio0 {
-   interrupts = ;
-};
-
-&gpio1 {
-   interrupts = ;
-};
-
-&gpio2 {
-   interrupts = ;
-};
-
-&gpio3 {
-   interrupts = ;
-};
-
-&gpio4 {
-   interrupts = ;
-};
-
-&i2c0 {
-   interrupts = ;
-};
-
-&pit {
-   interrupts = ;
-};
-
-&qspi0 {
-   interrupts = ;
-};
-
-&sai2 {
-   interrupts = ;
-};
-
-&snvsrtc {
-   interrupts = ;
-};
-
-&src {
-   interrupts = ;
-};
-
-&uart0 {
-   interrupts = ;
-};
-
-&uart1 {
-   interrupts = ;
-};
-
-&uart2 {
-   interrupts = ;
-};
-
-&uart3 {
-   interrupts = ;
-};
-
-&uart4 {
-   interrupts = ;
-};
-
-&uart5 {
-   interrupts = ;
-};
-
-&usbdev0 {
-   interrupts = ;
-};
-
-&usbh1 {
-   interrupts = ;
-};
-
-&usbphy0 {
-   interrupts = ;
-};
-
-&usbphy1 {
-   interrupts = ;
+&mscm_ir {
+   interrupt-parent = <&intc>;
 };
 
 &wdoga5 {
-   interrupts = ;
status = "okay";
 };
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index a29c7ce..32de809 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -54,6 +54,7 @@
#address-cells = <1>;
#size-cells = <1>;
compatible = "simple-bus";
+   interrupt-parent = <&mscm_ir>;
ranges;
 
aips0: aips-bus@4000 {
@@ -62,6 +63,19 @@
#size-cells = <1>;
ranges;
 
+   mscm_cpucfg: cpucfg@40001000 {
+   compatible = "fsl,vf610-mscm-cpucfg", "syscon";
+   reg = <0x40001000 0x800>;
+   

[PATCH v6 2/3] irqchip: vf610-mscm: dt-bindings: add MSCM bindings

2015-03-01 Thread Stefan Agner
Add binding documentation for CPU configuration and interrupt router
submodule of the Miscellaneous System Control Module. The MSCM is
used in all variants of Freescale Vybrid SoC's.

Acked-by: Marc Zyngier 
Signed-off-by: Stefan Agner 
---
 .../arm/freescale/fsl,vf610-mscm-cpucfg.txt| 14 +
 .../bindings/arm/freescale/fsl,vf610-mscm-ir.txt   | 33 ++
 2 files changed, 47 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-cpucfg.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-ir.txt

diff --git 
a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-cpucfg.txt 
b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-cpucfg.txt
new file mode 100644
index 000..44aa3c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-cpucfg.txt
@@ -0,0 +1,14 @@
+Freescale Vybrid Miscellaneous System Control - CPU Configuration
+
+The MSCM IP contains multiple sub modules, this binding describes the first
+block of registers which contains CPU configuration information.
+
+Required properties:
+- compatible:  "fsl,vf610-mscm-cpucfg", "syscon"
+- reg: the register range of the MSCM CPU configuration registers
+
+Example:
+   mscm_cpucfg: cpucfg@40001000 {
+   compatible = "fsl,vf610-mscm-cpucfg", "syscon";
+   reg = <0x40001000 0x800>;
+   }
diff --git 
a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-ir.txt 
b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-ir.txt
new file mode 100644
index 000..669808b2a
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-ir.txt
@@ -0,0 +1,33 @@
+Freescale Vybrid Miscellaneous System Control - Interrupt Router
+
+The MSCM IP contains multiple sub modules, this binding describes the second
+block of registers which control the interrupt router. The interrupt router
+allows to configure the recipient of each peripheral interrupt. Furthermore
+it controls the directed processor interrupts. The module is available in all
+Vybrid SoC's but is only really useful in dual core configurations (VF6xx
+which comes with a Cortex-A5/Cortex-M4 combination).
+
+Required properties:
+- compatible:  "fsl,vf610-mscm-ir"
+- reg: the register range of the MSCM Interrupt Router
+- fsl,cpucfg:  The handle to the MSCM CPU configuration node, required
+   to get the current CPU ID
+- interrupt-controller:Identifies the node as an interrupt controller
+- #interrupt-cells:Two cells, interrupt number and cells.
+   The hardware interrupt number according to interrupt
+   assignment of the interrupt router is required.
+   Flags get passed only when using GIC as parent. Flags
+   encoding as documented by the GIC bindings.
+- interrupt-parent:Should be the phandle for the interrupt controller of
+   the CPU the device tree is intended to be used on. This
+   is either the node of the GIC or NVIC controller.
+
+Example:
+   mscm_ir: interrupt-controller@40001800 {
+   compatible = "fsl,vf610-mscm-ir";
+   reg = <0x40001800 0x400>;
+   fsl,cpucfg = <&mscm_cpucfg>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   interrupt-parent = <&intc>;
+   }
-- 
2.3.0

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


[PATCH v6 0/3] irqchip: vf610-mscm: add MSCM interrupt router driver

2015-03-01 Thread Stefan Agner
So far the MSCM interrupt router was initialized by the boot loader
and configured all interrupts for the Cortex-A5 CPU. There are two
use cases where a proper driver is necessary:
- To run Linux on the Cortex-M4. When the kernel is running on the
  non-preconfigured CPU, the interrupt router need to be configured
  properly.
- To support deeper sleep modes: LPSTOP clears the interrupt router
  configuration, hence a driver needs to restore the configuration
  on resume.

Due to the concernes of using "syscon" for the interrupt router
this 4th version uses device tree bindings which split the MSCM
module into sub-modules.

In detail, the registers inside the MSCM module are grouped:
- 0x40001000-0x4000105C: Processor information e.g. CPU ID
- 0x40001800-0x40001820: CPU2CPU directed interrupt registers
- 0x40001880-0x4000195E: The interrupt router registers
- 0x40001C00-0x40001DDC: ACTZS TrustZone registers

This version of the patchset defines bindings for the first submodule
and combines the second and third submodule into one block. However,
the driver currently does not support the CPU2CPU interrupts. The
fourth submodule is completely left out for now.

Due to this and the better documentation the patchset grew by ~40
lines. I think this bindings honer the quite individual functionality
inside the MSCM better.

Still looking for an ack by device tree folks...

Changes since v5
- Remove seperate Kconfig symbol since this driver is presumably only
  used on Vybrid
- Warn only if IRQ is already in use by another CPU (avoids spurious
  warnings on older boot loaders)
- Rebased on v4.0-rc1

Changes since v4
- Fix config selection in SOC_VF610 (VF610_MSCM => VF610_MSCM_IR)

Changes since v3
- Splitted MSCM bindings: MSCM CPU configuration and interrupt router
- Use syscon to access the CPU configuration registers
- Renamed the driver (irq-vf610-mscm => irq-vf610-mscm-ir)
- Extended general and property description of the bindings
- Rebased on v3.19-rc6

Changes since v2
- Use two cell layout for MSCM interrupt router
- Move peripheral interrupt properties to base device tree vfxxx.dtsi
- Use generic two cell xlate (irq_domain_xlate_twocell)
- Add syscon to compatible string
- Remove some line breaks for better readability

Changes since v1 (part of Vybrid Cortex-M4 support)
- Rewrite with irqdomain hierarchy
- Implemented as proper irqchip and move to driver/irqchip/
- Doesn't work on Cortex-M4 anymore (NVIC as parent is not yet
  implemented)

Stefan Agner (3):
  irqchip: vf610-mscm-ir: add support for MSCM interrupt router
  irqchip: vf610-mscm: dt-bindings: add MSCM bindings
  ARM: dts: vf610: add Miscellaneous System Control Module (MSCM)

 .../arm/freescale/fsl,vf610-mscm-cpucfg.txt|  14 ++
 .../bindings/arm/freescale/fsl,vf610-mscm-ir.txt   |  33 
 arch/arm/boot/dts/vf500.dtsi   | 137 +
 arch/arm/boot/dts/vfxxx.dtsi   |  49 +
 arch/arm/mach-imx/Kconfig  |   1 +
 drivers/irqchip/Makefile   |   1 +
 drivers/irqchip/irq-vf610-mscm-ir.c| 212 +
 7 files changed, 314 insertions(+), 133 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-cpucfg.txt
 create mode 100644 
Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-ir.txt
 create mode 100644 drivers/irqchip/irq-vf610-mscm-ir.c

-- 
2.3.0

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


[PATCH v6 1/3] irqchip: vf610-mscm-ir: add support for MSCM interrupt router

2015-03-01 Thread Stefan Agner
This adds support for Vybrid's interrupt router. On VF6xx models,
almost all peripherals can be used by either of the two CPU's,
the Cortex-A5 or the Cortex-M4. The interrupt router routes the
peripheral interrupts to the configured CPU.

This IRQ chip driver configures the interrupt router to route
the requested interrupt to the CPU the kernel is running on.
The driver makes use of the irqdomain hierarchy support. The
parent is given by the device tree. This should be one of the
two possible parents either ARM GIC or the ARM NVIC interrupt
controller. The latter is currently not yet supported.

Note that there is no resource control mechnism implemented to
avoid concurrent access of the same peripheral. The user needs
to make sure to use device trees which assign the peripherals
orthogonally. However, this driver warns the user in case the
interrupt is already configured for the other CPU. This provides
a poor man's resource controller.

Acked-by: Marc Zyngier 
Signed-off-by: Stefan Agner 
---
 arch/arm/mach-imx/Kconfig   |   1 +
 drivers/irqchip/Makefile|   1 +
 drivers/irqchip/irq-vf610-mscm-ir.c | 212 
 3 files changed, 214 insertions(+)
 create mode 100644 drivers/irqchip/irq-vf610-mscm-ir.c

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index e8627e0..c8dffce 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -631,6 +631,7 @@ config SOC_IMX6SX
 
 config SOC_VF610
bool "Vybrid Family VF610 support"
+   select IRQ_DOMAIN_HIERARCHY
select ARM_GIC
select PINCTRL_VF610
select PL310_ERRATA_769419 if CACHE_L2X0
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 42965d2..9176c76 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_TB10X_IRQC)  += irq-tb10x.o
 obj-$(CONFIG_XTENSA)   += irq-xtensa-pic.o
 obj-$(CONFIG_XTENSA_MX)+= irq-xtensa-mx.o
 obj-$(CONFIG_IRQ_CROSSBAR) += irq-crossbar.o
+obj-$(CONFIG_SOC_VF610)+= irq-vf610-mscm-ir.o
 obj-$(CONFIG_BCM7120_L2_IRQ)   += irq-bcm7120-l2.o
 obj-$(CONFIG_BRCMSTB_L2_IRQ)   += irq-brcmstb-l2.o
 obj-$(CONFIG_KEYSTONE_IRQ) += irq-keystone.o
diff --git a/drivers/irqchip/irq-vf610-mscm-ir.c 
b/drivers/irqchip/irq-vf610-mscm-ir.c
new file mode 100644
index 000..9521057
--- /dev/null
+++ b/drivers/irqchip/irq-vf610-mscm-ir.c
@@ -0,0 +1,212 @@
+/*
+ * Copyright (C) 2014-2015 Toradex AG
+ * Author: Stefan Agner 
+ *
+ * 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.
+ *
+ *
+ * IRQ chip driver for MSCM interrupt router available on Vybrid SoC's.
+ * The interrupt router is between the CPU's interrupt controller and the
+ * peripheral. The router allows to route the peripheral interrupts to
+ * one of the two available CPU's on Vybrid VF6xx SoC's (Cortex-A5 or
+ * Cortex-M4). The router will be configured transparently on a IRQ
+ * request.
+ *
+ * o All peripheral interrupts of the Vybrid SoC can be routed to
+ *   CPU 0, CPU 1 or both. The routing is useful for dual-core
+ *   variants of Vybrid SoC such as VF6xx. This driver routes the
+ *   requested interrupt to the CPU currently running on.
+ *
+ * o It is required to setup the interrupt router even on single-core
+ *   variants of Vybrid.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "irqchip.h"
+
+#define MSCM_CPxNUM0x4
+
+#define MSCM_IRSPRC(n) (0x80 + 2 * (n))
+#define MSCM_IRSPRC_CPEN_MASK  0x3
+
+#define MSCM_IRSPRC_NUM112
+
+struct vf610_mscm_ir_chip_data {
+   void __iomem *mscm_ir_base;
+   u16 cpu_mask;
+   u16 saved_irsprc[MSCM_IRSPRC_NUM];
+};
+
+static struct vf610_mscm_ir_chip_data *mscm_ir_data;
+
+static inline void vf610_mscm_ir_save(struct vf610_mscm_ir_chip_data *data)
+{
+   int i;
+
+   for (i = 0; i < MSCM_IRSPRC_NUM; i++)
+   data->saved_irsprc[i] = readw_relaxed(data->mscm_ir_base + 
MSCM_IRSPRC(i));
+}
+
+static inline void vf610_mscm_ir_restore(struct vf610_mscm_ir_chip_data *data)
+{
+   int i;
+
+   for (i = 0; i < MSCM_IRSPRC_NUM; i++)
+   writew_relaxed(data->saved_irsprc[i], data->mscm_ir_base + 
MSCM_IRSPRC(i));
+}
+
+static int vf610_mscm_ir_notifier(struct notifier_block *self,
+ unsigned long cmd, void *v)
+{
+   switch (cmd) {
+   case CPU_CLUSTER_PM_ENTER:
+   vf610_mscm_ir_save(mscm_ir_data);
+   break;
+   case CPU_CLUSTER_PM_ENTER_FAILED:
+   case CPU_CLUSTER_PM_EXIT:
+   vf610_mscm_ir_restore(mscm_ir_data);
+   break;
+   }
+
+   return NOTIFY_OK;
+}
+
+s

Re: [PATCH V3 5/7] serial: earlycon: Set UPIO_MEM32BE based on DT properties

2015-03-01 Thread Peter Hurley
Hi Kevin,

On 11/24/2014 06:36 PM, Kevin Cernekee wrote:
> If an earlycon (stdout-path) node is being used, check for "big-endian"
> or "native-endian" properties and pass the appropriate iotype to the
> driver.
> 
> Note that LE sets UPIO_MEM (8-bit) but BE sets UPIO_MEM32BE (32-bit).  The
> big-endian property only really makes sense in the context of 32-bit
> registers, since 8-bit accesses never require data swapping.
> 
> At some point, the of_earlycon code may want to pass in the reg-io-width,
> reg-offset, and reg-shift parameters too.
> 
> Signed-off-by: Kevin Cernekee 
> ---
>  drivers/of/fdt.c  | 7 ++-
>  drivers/tty/serial/earlycon.c | 4 ++--
>  include/linux/serial_core.h   | 2 +-
>  3 files changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 658656f..9d21472 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -794,6 +794,8 @@ int __init early_init_dt_scan_chosen_serial(void)
>  
>   while (match->compatible[0]) {
>   unsigned long addr;
> + unsigned char iotype = UPIO_MEM;
> +
>   if (fdt_node_check_compatible(fdt, offset, match->compatible)) {
>   match++;
>   continue;
> @@ -803,7 +805,10 @@ int __init early_init_dt_scan_chosen_serial(void)
>   if (!addr)
>   return -ENXIO;
>  
> - of_setup_earlycon(addr, match->data);
> + if (of_fdt_is_big_endian(fdt, offset))
> + iotype = UPIO_MEM32BE;
> +
> + of_setup_earlycon(addr, iotype, match->data);

I know these got ACKs already but as you point out in the commit log,
earlycon _will_ need reg-io-width, reg-offset and reg-shift. Since the
distinction between early_init_dt_scan_chosen_serial() and
of_setup_earlycon() is arbitrary, I'd rather see of_setup_earlycon()
taught to properly decode of_serial driver bindings instead of a
stack of parameters to of_setup_earlycon().

In fact, this patch allows a mis-defined devicetree to bring up a
functioning earlycon because the 'big-endian' property is directly
associated with UPIO_MEM32BE, which will create incompatibility problems
when DT earlycon is fixed to decode the of_serial DT bindings.

[rant]
In general, the ability to query devicetree from all over the
kernel creates all kinds of compatibility issues which eventually
will cause unresolvable breakage.

The same rigor applied to ioctls is the analysis required for how
DT bindings are used in the kernel.

I realize that since this particular case only applies to earlycon, it's
no big deal, but if this same mistake had been made in the of_serial
driver, the serial core would be permanently stuck with the
'big-endian' property == UPIO_MEM32BE which could impact future designs.
[/rant]

Regards,
Peter Hurley

>   return 0;
>   }
>   return -ENODEV;
> diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
> index a514ee6..548f7d7 100644
> --- a/drivers/tty/serial/earlycon.c
> +++ b/drivers/tty/serial/earlycon.c
> @@ -148,13 +148,13 @@ int __init setup_earlycon(char *buf, const char *match,
>   return 0;
>  }
>  
> -int __init of_setup_earlycon(unsigned long addr,
> +int __init of_setup_earlycon(unsigned long addr, unsigned char iotype,
>int (*setup)(struct earlycon_device *, const char 
> *))
>  {
>   int err;
>   struct uart_port *port = &early_console_dev.port;
>  
> - port->iotype = UPIO_MEM;
> + port->iotype = iotype;
>   port->mapbase = addr;
>   port->uartclk = BASE_BAUD * 16;
>   port->membase = earlycon_map(addr, SZ_4K);
> diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
> index d2d5bf6..0d60c64 100644
> --- a/include/linux/serial_core.h
> +++ b/include/linux/serial_core.h
> @@ -310,7 +310,7 @@ struct earlycon_device {
>  int setup_earlycon(char *buf, const char *match,
>  int (*setup)(struct earlycon_device *, const char *));
>  
> -extern int of_setup_earlycon(unsigned long addr,
> +extern int of_setup_earlycon(unsigned long addr, unsigned char iotype,
>int (*setup)(struct earlycon_device *, const char 
> *));
>  
>  #define EARLYCON_DECLARE(name, func) \
> 

--
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 2/8] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC

2015-03-01 Thread Arnd Bergmann
On Saturday 28 February 2015 09:47:01 Chanwoo Choi wrote:
> "earlycon=exynos4210,0x14C2" is correct bootparam. You can check
> it on Documentation/kernel-parameters.txt as following.
> 
>  exynos4210,
> Use early console provided by serial driver available
> on Samsung SoCs, requires selecting proper type and
> a correct base address of the selected UART port. The
> serial port must already be setup and configured.
> Options are not yet supported.
> 
> 

But it's crazy to do this when you have a DT. Please fix the existing
devicetree files that use this to just list 'earlycon'.

The syntax above only makes sense for classic board files that we
do not support for exynos any more.

Arnd
--
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 2/4] media: ov2640: add async probe function

2015-03-01 Thread Guennadi Liakhovetski
Hi Josh,

Thanks for a patch update. I think it looks good as a first step in your 
patch series, just a minor comment below:

On Tue, 10 Feb 2015, Josh Wu wrote:

> In async probe, there is a case that ov2640 is probed before the
> host device which provided 'mclk'.
> To support this async probe, we will get 'mclk' at first in the probe(),
> if failed it will return -EPROBE_DEFER. That will let ov2640 wait for
> the host device probed.
> 
> Signed-off-by: Josh Wu 
> ---
> 
> Changes in v5:
> - don't change the ov2640_s_power() code.
> - will get 'mclk' at the beginning of ov2640_probe().
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/media/i2c/soc_camera/ov2640.c | 29 +++--
>  1 file changed, 19 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/media/i2c/soc_camera/ov2640.c 
> b/drivers/media/i2c/soc_camera/ov2640.c
> index 1fdce2f..057dd49 100644
> --- a/drivers/media/i2c/soc_camera/ov2640.c
> +++ b/drivers/media/i2c/soc_camera/ov2640.c
> @@ -1068,6 +1068,10 @@ static int ov2640_probe(struct i2c_client *client,
>   return -ENOMEM;
>   }
>  
> + priv->clk = v4l2_clk_get(&client->dev, "mclk");
> + if (IS_ERR(priv->clk))
> + return -EPROBE_DEFER;
> +
>   v4l2_i2c_subdev_init(&priv->subdev, client, &ov2640_subdev_ops);
>   v4l2_ctrl_handler_init(&priv->hdl, 2);
>   v4l2_ctrl_new_std(&priv->hdl, &ov2640_ctrl_ops,
> @@ -1075,24 +1079,28 @@ static int ov2640_probe(struct i2c_client *client,
>   v4l2_ctrl_new_std(&priv->hdl, &ov2640_ctrl_ops,
>   V4L2_CID_HFLIP, 0, 1, 1, 0);
>   priv->subdev.ctrl_handler = &priv->hdl;
> - if (priv->hdl.error)
> - return priv->hdl.error;
> -
> - priv->clk = v4l2_clk_get(&client->dev, "mclk");
> - if (IS_ERR(priv->clk)) {
> - ret = PTR_ERR(priv->clk);
> - goto eclkget;
> + if (priv->hdl.error) {
> + ret = priv->hdl.error;
> + goto err_clk;
>   }
>  
>   ret = ov2640_video_probe(client);
>   if (ret) {
> - v4l2_clk_put(priv->clk);
> -eclkget:
> - v4l2_ctrl_handler_free(&priv->hdl);
> + goto err_videoprobe;

Since you add a "goto" here, you don't need an "else" after it, and the 
"probed" success message should go down, so, just make it

ret = ov2640_video_probe(client);
if (ret < 0)
goto err_videoprobe;

ret = v4l2_async_register_subdev(&priv->subdev);
if (ret < 0)
goto err_videoprobe;

dev_info(&adapter->dev, "OV2640 Probed\n");

return 0;

err_...

Thanks
Guennadi

>   } else {
>   dev_info(&adapter->dev, "OV2640 Probed\n");
>   }
>  
> + ret = v4l2_async_register_subdev(&priv->subdev);
> + if (ret < 0)
> + goto err_videoprobe;
> +
> + return 0;
> +
> +err_videoprobe:
> + v4l2_ctrl_handler_free(&priv->hdl);
> +err_clk:
> + v4l2_clk_put(priv->clk);
>   return ret;
>  }
>  
> @@ -1100,6 +1108,7 @@ static int ov2640_remove(struct i2c_client *client)
>  {
>   struct ov2640_priv   *priv = to_ov2640(client);
>  
> + v4l2_async_unregister_subdev(&priv->subdev);
>   v4l2_clk_put(priv->clk);
>   v4l2_device_unregister_subdev(&priv->subdev);
>   v4l2_ctrl_handler_free(&priv->hdl);
> -- 
> 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 v3 1/2] dts: vt8500: Add SDHC node to DTS file for WM8650

2015-03-01 Thread Sergei Shtylyov

Hello.

On 03/01/2015 10:49 PM, Roman Volkov wrote:


Since WM8650 has the same 'WMT' SDHC controller as WM8505, and the
driver is already in the kernel, this node enables the controller
support for WM8650



Signed-off-by: Roman Volkov 
Reviewed-by: Alexey Charkov 
---
   arch/arm/boot/dts/wm8650.dtsi | 9 +
   1 file changed, 9 insertions(+)



diff --git a/arch/arm/boot/dts/wm8650.dtsi
b/arch/arm/boot/dts/wm8650.dtsi index b1c59a7..e12213d 100644
--- a/arch/arm/boot/dts/wm8650.dtsi
+++ b/arch/arm/boot/dts/wm8650.dtsi
@@ -187,6 +187,15 @@
interrupts = <43>;
};

+   sdhc@d800a000 {



 According to the ePAPR standard, the device nodes should have
generic names according to their functions, so this node should be
named just "sd@d800a000".



WBR, Sergei



Sergei,



Why not "sdmmc" or "sdhci" or "sdio" then? It would be great to name


   SDHCI is the SD host controller standard, while the names should describe 
"the function of the device and not its precise programming model". SDIO isn't 
the physical interface name, the physical interface underneath is still SD. 
"mmcsd" or "mmc-sd" would be appropriate, however just "mmc" is typically used.



nodes in same way, but there is no exact requirement in ePAPR v1.1
regarding SD/MMC controllers.


   Yes, MMC/SD node names are not yet standardized.


Also, in Linux I don't see that someone
strictly follows this requirement.


   Because people for the most part are not aware of it, despite 
http://www.devicetree.org/Device_Tree_Usage points to ePAPR and the section 
2.4 of this page also tells to use generic names.



This renaming will affect driver,
since .compatible strings likely also need changing.


   Why on earth they'll need change?!


Roman


WBR, 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 RESEND 2/2] dts: vt8500: Fix errors in SDHC node for WM8505

2015-03-01 Thread Roman Volkov
According to datasheet, the registers space of SDHC controller is 1Kb,
not '0x1000', the correct value should be '0x400'. Bracket interrupt
numbers individually per recommendations.

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

diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
index a1a854b..e9ef539 100644
--- a/arch/arm/boot/dts/wm8505.dtsi
+++ b/arch/arm/boot/dts/wm8505.dtsi
@@ -281,8 +281,8 @@
 
sdhc@d800a000 {
compatible = "wm,wm8505-sdhc";
-   reg = <0xd800a000 0x1000>;
-   interrupts = <20 21>;
+   reg = <0xd800a000 0x400>;
+   interrupts = <20>, <21>;
clocks = <&clksdhc>;
bus-width = <4>;
};
-- 
2.3.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 v3 RESEND 1/2] dts: vt8500: Add SDHC node to DTS file for WM8650

2015-03-01 Thread Roman Volkov
Since WM8650 has the same 'WMT' SDHC controller as WM8505, and the driver
is already in the kernel, this node enables the controller support for
WM8650

Signed-off-by: Roman Volkov 
Reviewed-by: Alexey Charkov 
---
 arch/arm/boot/dts/wm8650.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/wm8650.dtsi b/arch/arm/boot/dts/wm8650.dtsi
index b1c59a7..e12213d 100644
--- a/arch/arm/boot/dts/wm8650.dtsi
+++ b/arch/arm/boot/dts/wm8650.dtsi
@@ -187,6 +187,15 @@
interrupts = <43>;
};
 
+   sdhc@d800a000 {
+   compatible = "wm,wm8505-sdhc";
+   reg = <0xd800a000 0x400>;
+   interrupts = <20>, <21>;
+   clocks = <&clksdhc>;
+   bus-width = <4>;
+   sdon-inverted;
+   };
+
fb: fb@d8050800 {
compatible = "wm,wm8505-fb";
reg = <0xd8050800 0x200>;
-- 
2.3.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 v3 RESEND 0/2] WM8505/WM8650 DT fixes for SD card controller

2015-03-01 Thread Roman Volkov
This patch set enables SD controller support for WM8650 and
fixes minor errors in WM8505 Device Tree file.

Changes in v3:
1. Add minor fixes for WM8505 SDHC node

Tested on both WM8505 and WM8650.

Roman Volkov (2):
  dts: vt8500: Add SDHC node to DTS file for WM8650
  dts: vt8500: Fix errors in SDHC node for WM8505

 arch/arm/boot/dts/wm8505.dtsi | 4 ++--
 arch/arm/boot/dts/wm8650.dtsi | 9 +
 2 files changed, 11 insertions(+), 2 deletions(-)

-- 
Hi maintainers, I see my previous versions were not applied. Could this
little patch set be applied for the linux-next? I don't think this is new
functionality, this must be considered as bugfix for existing Device Tree.

Any other suggestions?

2.3.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 v3 0/2] WM8505/WM8650 DT fixes for SD card controller

2015-03-01 Thread Roman Volkov
В Sun, 01 Mar 2015 20:52:55 +0100
Arnd Bergmann  пишет:

> On Sunday 01 March 2015 19:06:45 Roman Volkov wrote:
> > This patch set enables SD controller support for WM8650 and
> > fixes minor errors in WM8505 Device Tree file.
> > 
> > Changes in v3:
> > 1. Add minor fixes for WM8505 SDHC node
> > 
> > Tested on both WM8505 and WM8650.
> > 
> > Roman Volkov (2):
> >   dts: vt8500: Add SDHC node to DTS file for WM8650
> >   dts: vt8500: Fix errors in SDHC node for WM8505
> > 
> >  arch/arm/boot/dts/wm8505.dtsi | 4 ++--
> >  arch/arm/boot/dts/wm8650.dtsi | 9 +
> >  2 files changed, 11 insertions(+), 2 deletions(-)
> > 
> > -- 
> > Hi maintainers, I see my previous versions were not applied. Could
> > this little patch set be applied for the linux-next? I don't think
> > this is new functionality, this must be considered as bugfix for
> > existing Device Tree.
> > 
> > Any other suggestions?
> 
> According to the MAINTAINERS file, Tony Prisk should be the person to
> pick them up, but he was not the recipient of the mail.
> 
>   Arnd

Thanks for the tip. Tony probably need to add these files to his list
of maintained files. get_maintainer.pl doesn't mention him.

Roman
--
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 0/2] WM8505/WM8650 DT fixes for SD card controller

2015-03-01 Thread Arnd Bergmann
On Sunday 01 March 2015 19:06:45 Roman Volkov wrote:
> This patch set enables SD controller support for WM8650 and
> fixes minor errors in WM8505 Device Tree file.
> 
> Changes in v3:
> 1. Add minor fixes for WM8505 SDHC node
> 
> Tested on both WM8505 and WM8650.
> 
> Roman Volkov (2):
>   dts: vt8500: Add SDHC node to DTS file for WM8650
>   dts: vt8500: Fix errors in SDHC node for WM8505
> 
>  arch/arm/boot/dts/wm8505.dtsi | 4 ++--
>  arch/arm/boot/dts/wm8650.dtsi | 9 +
>  2 files changed, 11 insertions(+), 2 deletions(-)
> 
> -- 
> Hi maintainers, I see my previous versions were not applied. Could this
> little patch set be applied for the linux-next? I don't think this is new
> functionality, this must be considered as bugfix for existing Device Tree.
> 
> Any other suggestions?

According to the MAINTAINERS file, Tony Prisk should be the person to
pick them up, but he was not the recipient of the mail.

Arnd
--
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 1/2] dts: vt8500: Add SDHC node to DTS file for WM8650

2015-03-01 Thread Roman Volkov
В Sun, 01 Mar 2015 20:59:13 +0300
Sergei Shtylyov  пишет:

> On 3/1/2015 7:06 PM, Roman Volkov wrote:
> 
> > Since WM8650 has the same 'WMT' SDHC controller as WM8505, and the
> > driver is already in the kernel, this node enables the controller
> > support for WM8650
> 
> > Signed-off-by: Roman Volkov 
> > Reviewed-by: Alexey Charkov 
> > ---
> >   arch/arm/boot/dts/wm8650.dtsi | 9 +
> >   1 file changed, 9 insertions(+)
> 
> > diff --git a/arch/arm/boot/dts/wm8650.dtsi
> > b/arch/arm/boot/dts/wm8650.dtsi index b1c59a7..e12213d 100644
> > --- a/arch/arm/boot/dts/wm8650.dtsi
> > +++ b/arch/arm/boot/dts/wm8650.dtsi
> > @@ -187,6 +187,15 @@
> > interrupts = <43>;
> > };
> >
> > +   sdhc@d800a000 {
> 
> According to the ePAPR standard, the device nodes should have
> generic names according to their functions, so this node should be
> named just "sd@d800a000".
> 
> WBR, Sergei
> 

Sergei,

Why not "sdmmc" or "sdhci" or "sdio" then? It would be great to name
nodes in same way, but there is no exact requirement in ePAPR v1.1
regarding SD/MMC controllers. Also, in Linux I don't see that someone
strictly follows this requirement. This renaming will affect driver,
since .compatible strings likely also need changing.

Roman
--
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 RESEND] ARM: dts: OMAP3-N900: Add microphone bias voltages

2015-03-01 Thread Jarkko Nikula
From: Pavel Machek 

N900 audio recording needs that codec provides bias voltage for integrated
digital microphone and headset microphone depending which one is used.
Digital microphone uses 2 V bias and it comes from the codec A part. Codec
B part drives the headset microphone bias and that is set to 2.5 V.

Signed-off-by: Pavel Machek 
[Jarkko: Headset mic bias changed to 2 (2.5 V) as it was before commit
e2e8bfdf6157 ("ASoC: tlv320aic3x: Convert mic bias to a supply widget")]
Signed-off-by: Jarkko Nikula 
---
 arch/arm/boot/dts/omap3-n900.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index db80f9d376fa..9c8bdf2c93a1 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -484,6 +484,8 @@
DRVDD-supply = <&vmmc2>;
IOVDD-supply = <&vio>;
DVDD-supply = <&vio>;
+
+   ai3x-micbias-vg = <1>;
};
 
tlv320aic3x_aux: tlv320aic3x@19 {
@@ -495,6 +497,8 @@
DRVDD-supply = <&vmmc2>;
IOVDD-supply = <&vio>;
DVDD-supply = <&vio>;
+
+   ai3x-micbias-vg = <2>;
};
 
tsl2563: tsl2563@29 {
-- 
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


Re: [PATCH v3 1/2] dts: vt8500: Add SDHC node to DTS file for WM8650

2015-03-01 Thread Sergei Shtylyov

On 3/1/2015 7:06 PM, Roman Volkov wrote:


Since WM8650 has the same 'WMT' SDHC controller as WM8505, and the driver
is already in the kernel, this node enables the controller support for
WM8650



Signed-off-by: Roman Volkov 
Reviewed-by: Alexey Charkov 
---
  arch/arm/boot/dts/wm8650.dtsi | 9 +
  1 file changed, 9 insertions(+)



diff --git a/arch/arm/boot/dts/wm8650.dtsi b/arch/arm/boot/dts/wm8650.dtsi
index b1c59a7..e12213d 100644
--- a/arch/arm/boot/dts/wm8650.dtsi
+++ b/arch/arm/boot/dts/wm8650.dtsi
@@ -187,6 +187,15 @@
interrupts = <43>;
};

+   sdhc@d800a000 {


   According to the ePAPR standard, the device nodes should have generic 
names according to their functions, so this node should be named just 
"sd@d800a000".


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


Re: [PATCH -next 00/13] Extensible console matching & direct earlycon

2015-03-01 Thread Peter Hurley
[ +cc devicetree, Mark Rutland, Grant Likely ]

On 02/26/2015 09:58 AM, Rob Herring wrote:
> On Thu, Feb 26, 2015 at 8:48 AM, Peter Hurley  
> wrote:
>> Hi Rob,
>>
>> On 02/24/2015 03:20 PM, Rob Herring wrote:
>>> On Tue, Feb 24, 2015 at 1:53 PM, Peter Hurley  
>>> wrote:
>>
>> [...]
>>
>> Direct earlycon
>>
>> This feature enables arches and proms to start an earlycon directly,
>> rather than requiring an "earlycon=" command line parameter.
>> Devicetree can already do this via the 'linux,stdout-path' property,
>> but arch and prom code requires direct coupling to the serial driver.
>>
>> This support is implemented by judicious refactoring and the same
>> construct that devicetree and early_param use: a link table containing
>> the necessary information (name and setup() function) to find and
>> bind the appropriate earlycon "driver".
>
> I've skimmed thru this and it looks like a great improvement.
>
> One problem we have currently with DT stdout-path and earlycon is a
> preferred console does not get registered, so the console will get
> switched to tty0 and you lose your console. The problem is DT does not
> know the console name to register a preferred console. It looks like
> this series may help this problem, but I'm not sure and wanted your
> thoughts.

 I thought that of_alias_scan() + of_console_check() caused DT stdout-path
 to add_preferred_console() the driver console @ port registration time
 via uart_add_one_port() -> of_console_check().

 Is that not how that works?
>>>
>>> Yes, I believe that is how it works with earlycon not enabled. This
>>> doesn't work when earlycon is enabled with just "earlycon" on the
>>> command line. The fix I have is here[1], but I don't like putting DT
>>> specifics into the console code.
>>
>> After much gnashing of teeth and pulling of hair yesterday, I managed
>> to mock up the situation you describe, but I need to study it in more
>> detail. Some things I did learn:
>>
>> 1. The serial console _does_ come back up when using stdout-path but the
>>line settings don't match, because the serial core sets them to the
>>default of 9600n8 if unspecified.
> 
> That may have been what I saw as I tested on QEMU which ignores the
> baud rate. But it does stop between the time tty0 is enabled and the
> "real" serial console which is a time period we really want the
> console.

The bug is that of_alias_scan() does not emit a preferred console, but
rather defers it until of_console_check().

In many setups, this means there is no preferred console. So when the
dummy vt console loads (which happens via console_init()), all the boot
consoles are disabled.

The trivial fix is to emit a preferred console from of_alias_scan(), even
if that console is never matched. I've sent you a patch to do just that.


>> 2. The line settings can now be set with stdout-path like,
>>  stdout-path = "serial0:115200n8"
>>but this breaks DT earlycon (as I wrote in the other email you were
>>cc'd on).
> 
> Right. We should fix libfdt.

Ok.

Regards,
Peter Hurley

--
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] of: Fix premature bootconsole disable with 'stdout-path'

2015-03-01 Thread Peter Hurley
Support for devicetree serial consoles via 'stdout-path' causes
bootconsoles to be disabled when the vt dummy console loads, since
there is no preferred console (the preferred console is not added
until the device is probed).

Ensure there is at least a preferred console, even if never matched.

Requires: "console: Fix console name size mismatch"
Cc: Andrew Morton 
Signed-off-by: Peter Hurley 
---
 drivers/of/base.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 36536b6..83dc8a6 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -1885,8 +1885,10 @@ void of_alias_scan(void * (*dt_alloc)(u64 size, u64 
align))
name = of_get_property(of_chosen, "linux,stdout-path", 
NULL);
if (IS_ENABLED(CONFIG_PPC) && !name)
name = of_get_property(of_aliases, "stdout", NULL);
-   if (name)
+   if (name) {
of_stdout = of_find_node_opts_by_path(name, 
&of_stdout_options);
+   add_preferred_console("stdout-path", 0, NULL);
+   }
}
 
if (!of_aliases)
-- 
2.3.0

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


[PATCH 2/3] arm64: dts: Fix interrupt active level for the generic timer on exynos7

2015-03-01 Thread Abhilash Kesavan
Fix the exynos7 device tree to indicate that the arm generic timers
provide an active low interrupt output. Also, update the CPU mask to
match the number of CPUs on the SoC.

Signed-off-by: Abhilash Kesavan 
---
 arch/arm64/boot/dts/exynos/exynos7.dtsi | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi 
b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index 749c4b3..c5687f9 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -10,6 +10,7 @@
  */
 
 #include 
+#include 
 
 / {
compatible = "samsung,exynos7";
@@ -440,10 +441,10 @@
 
timer {
compatible = "arm,armv8-timer";
-   interrupts = <1 13 0xff01>,
-<1 14 0xff01>,
-<1 11 0xff01>,
-<1 10 0xff01>;
+   interrupts = <1 13 (GIC_CPU_MASK_SIMPLE(4) | 
IRQ_TYPE_LEVEL_LOW)>,
+<1 14 (GIC_CPU_MASK_SIMPLE(4) | 
IRQ_TYPE_LEVEL_LOW)>,
+<1 11 (GIC_CPU_MASK_SIMPLE(4) | 
IRQ_TYPE_LEVEL_LOW)>,
+<1 10 (GIC_CPU_MASK_SIMPLE(4) | 
IRQ_TYPE_LEVEL_LOW)>;
};
 
pmu_system_controller: system-controller@105c {
-- 
2.1.0

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


[PATCH 3/3] arm64: Enable Exynos7 SOC in the defconfig

2015-03-01 Thread Abhilash Kesavan
From: Alim Akhtar 

Enable Exynos7 SOC in the arm64 defconfig. Also enable the
samsung serial driver needed by this SoC.

Signed-off-by: Alim Akhtar 
Signed-off-by: Abhilash Kesavan 
---
 arch/arm64/configs/defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index be1f12a..e45f290 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -31,6 +31,8 @@ CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 # CONFIG_BLK_DEV_BSG is not set
 # CONFIG_IOSCHED_DEADLINE is not set
+CONFIG_ARCH_EXYNOS=y
+CONFIG_ARCH_EXYNOS7=y
 CONFIG_ARCH_FSL_LS2085A=y
 CONFIG_ARCH_MEDIATEK=y
 CONFIG_ARCH_THUNDER=y
@@ -93,6 +95,8 @@ CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_8250_MT6577=y
 CONFIG_SERIAL_AMBA_PL011=y
 CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
+CONFIG_SERIAL_SAMSUNG=y
+CONFIG_SERIAL_SAMSUNG_CONSOLE=y
 CONFIG_SERIAL_OF_PLATFORM=y
 CONFIG_VIRTIO_CONSOLE=y
 # CONFIG_HW_RANDOM is not set
-- 
2.1.0

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


[PATCH 0/3] Minor exynos7 device tree/config patches

2015-03-01 Thread Abhilash Kesavan
Patch 1 specifies the fifo sizes for UART channels on exnyos7. Without
this the 4210 compatible defaults will be picked up which are different
from that on exynos7.
Patch 2 is based on a patch from Liviu Dudau fixing a similar issue
for arm boards.
Patch 3 is needed to enable support for arm64 based exynos7 platform.

Abhilash Kesavan (2):
  arm64: dts: add fifo size property for uart channels on exynos7
  arm64: dts: Fix interrupt active level for the generic timer on
exynos7

Alim Akhtar (1):
  arm64: Enable Exynos7 SOC in the defconfig

 arch/arm64/boot/dts/exynos/exynos7.dtsi | 13 +
 arch/arm64/configs/defconfig|  4 
 2 files changed, 13 insertions(+), 4 deletions(-)

-- 
2.1.0

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


[PATCH 1/3] arm64: dts: add fifo size property for uart channels on exynos7

2015-03-01 Thread Abhilash Kesavan
Specify the fifo sizes of the 4 uart channels on exynos7 via dt.

Signed-off-by: Abhilash Kesavan 
---
 arch/arm64/boot/dts/exynos/exynos7.dtsi | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi 
b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index d7a37c3..749c4b3 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -192,6 +192,7 @@
clocks = <&clock_peric0 PCLK_UART0>,
 <&clock_peric0 SCLK_UART0>;
clock-names = "uart", "clk_uart_baud0";
+   samsung,uart-fifosize = <64>;
status = "disabled";
};
 
@@ -202,6 +203,7 @@
clocks = <&clock_peric1 PCLK_UART1>,
 <&clock_peric1 SCLK_UART1>;
clock-names = "uart", "clk_uart_baud0";
+   samsung,uart-fifosize = <256>;
status = "disabled";
};
 
@@ -212,6 +214,7 @@
clocks = <&clock_peric1 PCLK_UART2>,
 <&clock_peric1 SCLK_UART2>;
clock-names = "uart", "clk_uart_baud0";
+   samsung,uart-fifosize = <16>;
status = "disabled";
};
 
@@ -222,6 +225,7 @@
clocks = <&clock_peric1 PCLK_UART3>,
 <&clock_peric1 SCLK_UART3>;
clock-names = "uart", "clk_uart_baud0";
+   samsung,uart-fifosize = <64>;
status = "disabled";
};
 
-- 
2.1.0

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


[PATCH v3 1/2] dts: vt8500: Add SDHC node to DTS file for WM8650

2015-03-01 Thread Roman Volkov
Since WM8650 has the same 'WMT' SDHC controller as WM8505, and the driver
is already in the kernel, this node enables the controller support for
WM8650

Signed-off-by: Roman Volkov 
Reviewed-by: Alexey Charkov 
---
 arch/arm/boot/dts/wm8650.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/wm8650.dtsi b/arch/arm/boot/dts/wm8650.dtsi
index b1c59a7..e12213d 100644
--- a/arch/arm/boot/dts/wm8650.dtsi
+++ b/arch/arm/boot/dts/wm8650.dtsi
@@ -187,6 +187,15 @@
interrupts = <43>;
};
 
+   sdhc@d800a000 {
+   compatible = "wm,wm8505-sdhc";
+   reg = <0xd800a000 0x400>;
+   interrupts = <20>, <21>;
+   clocks = <&clksdhc>;
+   bus-width = <4>;
+   sdon-inverted;
+   };
+
fb: fb@d8050800 {
compatible = "wm,wm8505-fb";
reg = <0xd8050800 0x200>;
-- 
2.3.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 v3 2/2] dts: vt8500: Fix errors in SDHC node for WM8505

2015-03-01 Thread Roman Volkov
According to datasheet, the registers space of SDHC controller is 1Kb,
not '0x1000', the correct value should be '0x400'. Bracket interrupt
numbers individually per recommendations.

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

diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
index a1a854b..e9ef539 100644
--- a/arch/arm/boot/dts/wm8505.dtsi
+++ b/arch/arm/boot/dts/wm8505.dtsi
@@ -281,8 +281,8 @@
 
sdhc@d800a000 {
compatible = "wm,wm8505-sdhc";
-   reg = <0xd800a000 0x1000>;
-   interrupts = <20 21>;
+   reg = <0xd800a000 0x400>;
+   interrupts = <20>, <21>;
clocks = <&clksdhc>;
bus-width = <4>;
};
-- 
2.3.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 v3 0/2] WM8505/WM8650 DT fixes for SD card controller

2015-03-01 Thread Roman Volkov
This patch set enables SD controller support for WM8650 and
fixes minor errors in WM8505 Device Tree file.

Changes in v3:
1. Add minor fixes for WM8505 SDHC node

Tested on both WM8505 and WM8650.

Roman Volkov (2):
  dts: vt8500: Add SDHC node to DTS file for WM8650
  dts: vt8500: Fix errors in SDHC node for WM8505

 arch/arm/boot/dts/wm8505.dtsi | 4 ++--
 arch/arm/boot/dts/wm8650.dtsi | 9 +
 2 files changed, 11 insertions(+), 2 deletions(-)

-- 
Hi maintainers, I see my previous versions were not applied. Could this
little patch set be applied for the linux-next? I don't think this is new
functionality, this must be considered as bugfix for existing Device Tree.

Any other suggestions?

2.3.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 v8 13/18] cpufreq: tegra124: Add device tree bindings

2015-03-01 Thread Mikko Perttunen
From: Tuomas Tynkkynen 

The cpufreq driver for Tegra124 will be a different one than the old
Tegra20 cpufreq driver (tegra-cpufreq), which does not use the device
tree.

Signed-off-by: Tuomas Tynkkynen 
Signed-off-by: Mikko Perttunen 
Cc: devicetree@vger.kernel.org
---
 .../bindings/cpufreq/tegra124-cpufreq.txt  | 44 ++
 1 file changed, 44 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/cpufreq/tegra124-cpufreq.txt

diff --git a/Documentation/devicetree/bindings/cpufreq/tegra124-cpufreq.txt 
b/Documentation/devicetree/bindings/cpufreq/tegra124-cpufreq.txt
new file mode 100644
index 000..b1669fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/tegra124-cpufreq.txt
@@ -0,0 +1,44 @@
+Tegra124 CPU frequency scaling driver bindings
+--
+
+Both required and optional properties listed below must be defined
+under node /cpus/cpu@0.
+
+Required properties:
+- clocks: Must contain an entry for each entry in clock-names.
+  See ../clocks/clock-bindings.txt for details.
+- clock-names: Must include the following entries:
+  - cpu_g: Clock mux for the fast CPU cluster.
+  - cpu_lp: Clock mux for the low-power CPU cluster.
+  - pll_x: Fast PLL clocksource.
+  - pll_p: Auxiliary PLL used during fast PLL rate changes.
+  - dfll: Fast DFLL clocksource that also automatically scales CPU voltage.
+- vdd-cpu-supply: Regulator for CPU voltage
+
+Optional properties:
+- clock-latency: Specify the possible maximum transition latency for clock,
+  in unit of nanoseconds.
+
+Example:
+
+cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a15";
+   reg = <0>;
+
+   clocks = <&tegra_car TEGRA124_CLK_CCLK_G>,
+<&tegra_car TEGRA124_CLK_CCLK_LP>,
+<&tegra_car TEGRA124_CLK_PLL_X>,
+<&tegra_car TEGRA124_CLK_PLL_P>,
+<&dfll>;
+   clock-names = "cpu_g", "cpu_lp", "pll_x", "pll_p", "dfll";
+   clock-latency = <30>;
+   vdd-cpu-supply: <&vdd_cpu>;
+   };
+
+   <...>
+};
--
2.3.0

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


[PATCH v8 01/18] clk: tegra: Add binding for the Tegra124 DFLL clocksource

2015-03-01 Thread Mikko Perttunen
From: Tuomas Tynkkynen 

The DFLL is the main clocksource for the fast CPU cluster on Tegra124
and also provides automatic CPU rail voltage scaling as well. The DFLL
is a separate IP block from the usual Tegra124 clock-and-reset
controller, so it gets its own node in the device tree.

Signed-off-by: Tuomas Tynkkynen 
Signed-off-by: Mikko Perttunen 
Cc: devicetree@vger.kernel.org
---
v8:
- Changed dfll@ -> clock@
- Changed compatibility string to "nvidia,tegra124-dfll"
- Clarified how the vdd-cpu-supply property is used
- Marked nvidia,cg-scale as optional since it is a boolean property
- Expanded the 'FS mode' term to 'full speed mode'
- Added dvco reset control

 .../bindings/clock/nvidia,tegra124-dfll.txt| 79 ++
 1 file changed, 79 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt

diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt 
b/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
new file mode 100644
index 000..ee7e5fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
@@ -0,0 +1,79 @@
+NVIDIA Tegra124 DFLL FCPU clocksource
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The DFLL IP block on Tegra is a root clocksource designed for clocking
+the fast CPU cluster. It consists of a free-running voltage controlled
+oscillator connected to the CPU voltage rail (VDD_CPU), and a closed loop
+control module that will automatically adjust the VDD_CPU voltage by
+communicating with an off-chip PMIC either via an I2C bus or via PWM signals.
+Currently only the I2C mode is supported by these bindings.
+
+Required properties:
+- compatible : should be "nvidia,tegra124-dfll"
+- reg : Defines the following set of registers, in the order listed:
+- registers for the DFLL control logic.
+- registers for the I2C output logic.
+- registers for the integrated I2C master controller.
+- look-up table RAM for voltage register values.
+- interrupts: Should contain the DFLL block interrupt.
+- clocks: Must contain an entry for each entry in clock-names.
+  See clock-bindings.txt for details.
+- clock-names: Must include the following entries:
+  - soc: Clock source for the DFLL control logic.
+  - ref: The closed loop reference clock
+  - i2c: Clock source for the integrated I2C master.
+- resets: Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names: Must include the following entries:
+  - dvco: Reset control for the DFLL DVCO.
+- #clock-cells: Must be 0.
+- clock-output-names: Name of the clock output.
+- vdd-cpu-supply: Regulator for the CPU voltage rail that the DFLL
+  hardware will start controlling. The regulator will be queried for
+  the I2C register, control values and supported voltages.
+
+Required properties for the control loop parameters:
+- nvidia,sample-rate: Sample rate of the DFLL control loop.
+- nvidia,droop-ctrl: See the register CL_DVFS_DROOP_CTRL in the TRM.
+- nvidia,force-mode: See the field DFLL_PARAMS_FORCE_MODE in the TRM.
+- nvidia,cf: Numeric value, see the field DFLL_PARAMS_CF_PARAM in the TRM.
+- nvidia,ci: Numeric value, see the field DFLL_PARAMS_CI_PARAM in the TRM.
+- nvidia,cg: Numeric value, see the field DFLL_PARAMS_CG_PARAM in the TRM.
+
+Optional properties for the control loop parameters:
+- nvidia,cg-scale: Boolean value, see the field DFLL_PARAMS_CG_SCALE in the 
TRM.
+
+Required properties for I2C mode:
+- nvidia,i2c-fs-rate: I2C transfer rate, if using full speed mode.
+
+Example:
+
+clock@0,7011 {
+compatible = "nvidia,tegra124-dfll";
+reg = <0 0x7011 0 0x100>, /* DFLL control */
+  <0 0x7011 0 0x100>, /* I2C output control */
+  <0 0x70110100 0 0x100>, /* Integrated I2C controller */
+  <0 0x70110200 0 0x100>; /* Look-up table RAM */
+interrupts = ;
+clocks = <&tegra_car TEGRA124_CLK_DFLL_SOC>,
+ <&tegra_car TEGRA124_CLK_DFLL_REF>,
+ <&tegra_car TEGRA124_CLK_I2C5>;
+clock-names = "soc", "ref", "i2c";
+resets = <&tegra_car TEGRA124_RST_DFLL_DVCO>;
+reset-names = "dvco";
+#clock-cells = <0>;
+clock-output-names = "dfllCPU_out";
+vdd-cpu-supply = <&vdd_cpu>;
+status = "okay";
+
+nvidia,sample-rate = <12500>;
+nvidia,droop-ctrl = <0x0f00>;
+nvidia,force-mode = <1>;
+nvidia,cf = <10>;
+nvidia,ci = <0>;
+nvidia,cg = <2>;
+
+nvidia,i2c-fs-rate = <40>;
+};
-- 
2.3.0

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


Re: [RFC/PATCH] pinctrl: sh-pfc: Accept standard function, pins and groups properties

2015-03-01 Thread Laurent Pinchart
Hi Linus,

I'd like to move forward with this patch, could you please comment on my reply 
?

On Wednesday 04 February 2015 11:53:34 Laurent Pinchart wrote:
> On Wednesday 04 February 2015 09:40:48 Linus Walleij wrote:
> > On Tue, Jan 27, 2015 at 9:31 PM, Laurent Pinchart wrote:
> >> The "function", "pins" and "groups" pinmux and pinctrl properties have
> >> been standardized. Support them in addition to the custom "renesas,*"
> >> properties. New-style and old-style properties can't be mixed in DT.
> >> 
> >> Signed-off-by: Laurent Pinchart
> >> 
> > 
> > (...)
> > 
> >>> Would be nice if the PFC driver could be augmented to also accept the
> >>> now standard bindings "groups" and "function" simply :) we're adding
> >>> parse functions for those to the core.
> >> 
> >> Something like this ?
> > 
> > Yes :)
> > 
> >> Please note two differences between the Renesas PFC bindings and the
> >> standard bindings:
> >> 
> >> - The standard bindings state that a pinctrl node must contain either a
> >>   "pins" property or a "groups" property, while the Renesas bindings
> >>   allows for both to coexist in the same node.
> > 
> > Sascha also says this makes sense for him so I guess I'm getting a bit
> > soft on the issue.
> > 
> >> - The standard bindings don't allow a pinmux node to contain a "pins"
> >>   property, while the Renesas bindings do.
> > 
> > Does that mean "pins" affect the muxing or that "pins" is about some
> > per-pin config shoveled into the same node?
> > 
> > The former is not OK, the latter is.
> 
> It means "pins" affect the muxing. The sh-pfc driver supports both muxing
> groups and muxing individual pins.
> 
> >> mmcif_pins: mmcif {
> >> 
> >> mux {
> >> 
> >> -   renesas,groups = "mmc0_data8_0",
> >> "mmc0_ctrl_0";
> >> -   renesas,function = "mmc0";
> >> +   groups = "mmc0_data8_0", "mmc0_ctrl_0";
> >> +   function = "mmc0";
> >> 
> >> };
> > 
> > So that looks just very nice.
> > 
> >> cfg {
> >> 
> >> -   renesas,groups = "mmc0_data8_0";
> >> -   renesas,pins = "PORT279";
> >> +   groups = "mmc0_data8_0";
> >> +   pins = "PORT279";
> >> 
> >> bias-pull-up;
> > 
> > And here I can't see the use of "groups" in this node since it
> > doesn't match a function. It's a bit ambiguous what "groups"
> > mean when you run into it like this.
> 
> It means that the bias-pull-up configuration is applied to all pins of the
> "mmc0_data8_0" group, as well as to pin 279.

-- 
Regards,

Laurent Pinchart

--
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 2/2] ARM: dts: add rk3288 PopMetal board

2015-03-01 Thread Andy Yan
PopMetal is a rockchip rk3288 based board made by ChipSpark,
which has many interface such as VGA,HDMI,usb,ir,sdcad and lots of
sensors such as gyroscope(L3G4200D),accelerometer(mma8452),
compass(AK8963C).

This patch add a basic support for this board, which make the board
boot into a initramfs shell with sdcard,hdmi and all sensors enabled

Signed-off-by: Andy Yan 

---

Changes in v2:
- use GPL + X11 dual license, adviced by Heiko
- indent pwrbtn
- move node "ak8963" before "buttons"
- add cpu0-supply
- add supply for rk808 regulator

 arch/arm/boot/dts/rk3288-popmetal.dts | 447 ++
 1 file changed, 447 insertions(+)
 create mode 100644 arch/arm/boot/dts/rk3288-popmetal.dts

diff --git a/arch/arm/boot/dts/rk3288-popmetal.dts 
b/arch/arm/boot/dts/rk3288-popmetal.dts
new file mode 100644
index 000..d081f0e
--- /dev/null
+++ b/arch/arm/boot/dts/rk3288-popmetal.dts
@@ -0,0 +1,447 @@
+/*
+ * Copyright (c) 2014, 2015 Andy Yan 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file 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 file 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.
+ *
+ *  Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "rk3288.dtsi"
+
+/ {
+   model = "PopMetal-RK3288";
+   compatible = "chipspark,popmetal-rk3288", "rockchip,rk3288";
+
+   memory{
+   reg = <0 0x8000>;
+   };
+
+   ext_gmac: external-gmac-clock {
+   compatible = "fixed-clock";
+   clock-frequency = <12500>;
+   clock-output-names = "ext_gmac";
+   #clock-cells = <0>;
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   autorepeat;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <&pwrbtn>;
+
+   button@0 {
+   gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
+   linux,code = <116>;
+   label = "GPIO Key Power";
+   linux,input-type = <1>;
+   gpio-key,wakeup = <1>;
+   debounce-interval = <100>;
+   };
+   };
+
+   ir: ir-receiver {
+   compatible = "gpio-ir-receiver";
+   gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&ir_int>;
+   };
+
+   vcc_sys: vsys-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_sys";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+};
+
+&cpu0 {
+   cpu0-supply = <&vdd_cpu>;
+};
+
+&emmc {
+   broken-cd;
+   bus-width = <8>;
+   cap-mmc-highspeed;
+   disable-wp;
+   non-removable;
+   num-slots = <1>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&emmc_clk &emmc_cmd &emmc_pwr &emmc_bus8>;
+   status = "okay";
+};
+
+&sdmmc {
+   bus-width = <4>;
+   cap-mmc-highspeed;
+   cap-sd-highspeed;
+   card-detect-delay = <200>;
+   

[PATCH v2 1/2] dt-bindings: add root compatible property for PopMetal board

2015-03-01 Thread Andy Yan
PopMetal board is a rk3288 based board made by ChipSpark, this
add root compatible property for it

Signed-off-by: Andy Yan 

---

Changes in v2:
- change "PopMetal PopMetal-RK3288 board" to "ChipSPARK PopMetal-RK3288 board"

 Documentation/devicetree/bindings/arm/rockchip.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt 
b/Documentation/devicetree/bindings/arm/rockchip.txt
index 6809e4e..60d4a1e 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -22,3 +22,7 @@ Rockchip platforms device tree bindings
   - compatible = "firefly,firefly-rk3288", "rockchip,rk3288";
 or
   - compatible = "firefly,firefly-rk3288-beta", "rockchip,rk3288";
+
+- ChipSPARK PopMetal-RK3288 board:
+Required root node properties:
+  - compatible = "chipspark,popmetal-rk3288", "rockchip,rk3288";
-- 
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/2] add dts for PopMetal board

2015-03-01 Thread Andy Yan

PopMetal is a rockchip rk3288 based board made by ChipSpark,
which has many interface such as VGA,HDMI,usb,ir,sdcad and lots of
sensors such as gyroscope(L3G4200D),accelerometer(mma8452),compass(AK8963C).

http://wiki.chipspark.com/en/index.php?title=PopMetal

This patch add basic support for it, which can boot the board
into a shell with linux boot logo on hdmi, sdcard and many
sensors enabled. More feather will be enabled later.

Changes in v2:
- change "PopMetal PopMetal-RK3288 board" to "ChipSPARK PopMetal-RK3288 board"
- use GPL + X11 dual license, adviced by Heiko
- indent pwrbtn
- move node "ak8963" before "buttons"

Andy Yan (2):
  dt-bindings: add root compatible property for PopMetal board
  ARM: dts: add rk3288 PopMetal board

 Documentation/devicetree/bindings/arm/rockchip.txt |   4 +
 arch/arm/boot/dts/rk3288-popmetal.dts  | 447 +
 2 files changed, 451 insertions(+)
 create mode 100644 arch/arm/boot/dts/rk3288-popmetal.dts

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