[PATCH] regulator: max77802: Separate sections for nodes and properties

[Javier Martinez Canillas]

The optional "regulators" is a node and not a property so it should not
be in the "Optional properties" section but in an "Optional nodes" one.

Suggested-by: Rob Herring 
Signed-off-by: Javier Martinez Canillas 

---

 Documentation/devicetree/bindings/regulator/max77802.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/regulator/max77802.txt 
b/Documentation/devicetree/bindings/regulator/max77802.txt
index b466689c47ea..09d796ed48be 100644
--- a/Documentation/devicetree/bindings/regulator/max77802.txt
+++ b/Documentation/devicetree/bindings/regulator/max77802.txt
@@ -28,6 +28,8 @@ Optional properties:
 - inl7-supply:  The input supply for LDO18, LDO20, LDO28 and LDO29
 - inl9-supply:  The input supply for LDO12, LDO23, LDO25, LDO26, LDO32 and 
LDO34
 - inl10-supply: The input supply for LDO1 and LDO2
+
+Optional nodes:
 - regulators : The regulators of max77802 have to be instantiated
   under subnode named "regulators" using the following format.
 
-- 
2.4.3

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

Re: [PATCH] regulator: max77802: Add input supply properties to DT binding doc

[Javier Martinez Canillas]

Hello Rob,

Thanks for your feedback.

On 10/05/2015 06:15 PM, Rob Herring wrote:
> On Mon, Oct 5, 2015 at 10:07 AM, Javier Martinez Canillas
>  wrote:
>> The max77802 regulator driver defines the supply name for each regulator
>> so these can be described in DT but is not mentioned in the binding doc.
>>
>> Signed-off-by: Javier Martinez Canillas 
>>
>> ---
>>
>>  .../devicetree/bindings/regulator/max77802.txt | 23 
>> +-
>>  1 file changed, 22 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/regulator/max77802.txt 
>> b/Documentation/devicetree/bindings/regulator/max77802.txt
>> index 79e5476444f7..b466689c47ea 100644
>> --- a/Documentation/devicetree/bindings/regulator/max77802.txt
>> +++ b/Documentation/devicetree/bindings/regulator/max77802.txt
>> @@ -8,7 +8,26 @@ regulators that can be controlled over I2C.
>>
>>  Following properties should be present in main device node of the MFD chip.
>>
>> -Optional node:
> 
> regulators is still a node, so you should have 2 sections.
>

You are right, I included both because I saw other DT bindings doing
this but agree the correct approach is to have two separate sections.

Mark already applied this patch though so I can't send a v2 but I'll
post an incremental patch on top of his topic/max77802 branch:

https://git.kernel.org/cgit/linux/kernel/git/broonie/regulator.git/log/?h=topic/max77802

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] ARM: OMAP: dmtimer: check for fixed timers during config

[Suman Anna]

On 10/05/2015 11:58 AM, Tony Lindgren wrote:
> * Suman Anna  [151005 09:47]:
>> Tony,
>>
>> On 10/03/2015 12:29 PM, kbuild test robot wrote:
>>> Hi Suman,
>>>
>>> [auto build test results on v4.3-rc3 -- if it's inappropriate base, please 
>>> ignore]
>>>
>>> config: arm-omap1_defconfig (attached as .config)
>>> reproduce:
>>> wget 
>>> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>>>  -O ~/bin/make.cross
>>> chmod +x ~/bin/make.cross
>>> # save the attached .config to linux build tree
>>> make.cross ARCH=arm 
>>>
>>> All error/warnings (new ones prefixed by >>):
>>>
>>>arch/arm/plat-omap/dmtimer.c: In function 'omap_dm_timer_set_source':
> arch/arm/plat-omap/dmtimer.c:509:2: error: implicit declaration of 
> function 'clk_hw_get_num_parents' [-Werror=implicit-function-declaration]
>>>  if (!clk_hw_get_num_parents(__clk_get_hw(timer->fclk)))
>>>  ^
> arch/arm/plat-omap/dmtimer.c:509:2: error: implicit declaration of 
> function '__clk_get_hw' [-Werror=implicit-function-declaration]
>>>cc1: some warnings being treated as errors
>>>
>>> vim +/clk_hw_get_num_parents +509 arch/arm/plat-omap/dmtimer.c
>>>
>>>503  return pdata->set_timer_src(timer->pdev, 
>>> source);
>>>504  
>>>505  if (IS_ERR(timer->fclk))
>>>506  return -EINVAL;
>>>507  
>>>508  /* Check if the clock has parents if not no point 
>>> checking */
>>>  > 509  if (!clk_hw_get_num_parents(__clk_get_hw(timer->fclk)))
>>>510  return 0;
>>
>> CONFIG_COMMON_CLK is not defined for OMAP1. So, are you ok if I enclose
>> this within #ifdef CONFIG_COMMON_CLK?
> 
> Yes, or maybe you can just clk_get_rate() on the 32k oscillator?
> 
> Boards with no 32k oscillator should set the rate for that 0 zero.

Well, this API is about setting the timer clk's mux source, and not
really dealing with the clk rate or just setting it to the 32k
oscillator. A 32k is usually one of the mux parents (if the timer has
them). If there is a way to find if the clk is a mux clock, then that
check would be ideal. But since no such thing exists, so I will go ahead
and fix this by adding the #ifdef check.

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

Re: [PATCH v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi

[Timo Sigurdsson]

Hi Kevin,

Kevin Hilman schrieb am 24.09.2015 19:57:
> kernelci.org started finding boot faiulres[1] on bananapi linux-next
> around next-20150918, but it was only failing in some labs and not
> others.  I finally bisected it down to this patch, which landed in
> linux-next in the form of 2d665a8a8350 ARM: dts: sunxi: Add regulators
> for LeMaker BananaPi.  Reverting that commit on top of next-20150923
> gets my bananapi booting again.
> 
> Note it's kind of an interesting boot failure.  The kernel boots fully
> to a shell, but panics after running a few commands.  In particular
> 'dmesg -n1' seems to trigger it usually[2].
> 
> Kevin
> 
> [1]
> http://kernelci.org/boot/sun7i-a20-bananapi/job/next/kernel/next-20150923/defconfig/multi_v7_defconfig/lab/lab-khilman/?_id=5602504359b514be146c326f
> [2]
> http://storage.kernelci.org/next/next-20150923/arm-multi_v7_defconfig/lab-khilman/boot-sun7i-a20-bananapi.html

following up on my last email: I'm back from my vacation and I tried to
reproduce your problem, but my board doesn't seem to be affected, so I
cannot trigger it.

I still think that the lower voltages may be the cause of your problem
with that specific board, so could you please test the attached patch on
top of my patch that you first experienced the problem with? Please let 
us know whether this solves your issue or whether we need to dig deeper.

Has anybody else been able to reproduce Kevin's issue?

Kind regards,

Timodiff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index 74382f3..39b6b67b 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -94,6 +94,16 @@
 
  {
 	cpu-supply = <_dcdc2>;
+	operating-points = <
+		/* kHz	  uV */
+		96	140
+		912000	140
+		864000	135
+		72	125
+		528000	115
+		312000	110
+		144000	105
+		>;
 };
 
  {
-- 
2.1.4

Re: [RFC PATCH v6 3/3] dtc: dts source location annotation, short location format

[David Gibson]

On Fri, Oct 02, 2015 at 09:55:17PM -0700, Frank Rowand wrote:

Uh.. the actual patch seems to be missing.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [PATCH v5 1/9] Input: goodix - sort includes alphabetically

[Pavel Machek]

Hi!

> > Subject: Re: [PATCH v5 1/9] Input: goodix - sort includes alphabetically
> > 
> > On Mon 2015-09-07 17:36:15, Irina Tirdea wrote:
> > > Signed-off-by: Irina Tirdea 
> > > ---
> > >  drivers/input/touchscreen/goodix.c | 12 ++--
> > >  1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> > Don't.
> > 
> > Yes, we sometimes sort includes... to avoid patch rejects.
> > 
> > This is guaranteed to cause rejects.
> > 
> > If we do sort them, we use "longest-first" usually.
> > 
> 
> When using random order, I've been told by reviewers that my ordering
> is wrong [1], but I could not figure out what the "right" ordering is in 
> order to apply.
> I did not find any mention of how to sort includes in  
> Documentation/CodingStyle,
> but I've seen patches in the kernel that fix random ordering by sorting them
> alphabetically [2].

Ok, I have seen this more often:

https://lkml.org/lkml/2009/3/28/99
 
> However, I do not feel strongly about this so I can drop this patch.

Well, its really nit picking.


Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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

[PATCH] iio:adc: fix platform_no_drv_owner.cocci warnings

[kbuild test robot]

drivers/iio/adc/palmas_gpadc.c:798:3-8: No need to set .owner here. The core 
will do it.

 Remove .owner field if calls are used which set it automatically

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

CC: H. Nikolaus Schaller 
Signed-off-by: Fengguang Wu 
---

 palmas_gpadc.c |1 -
 1 file changed, 1 deletion(-)

--- a/drivers/iio/adc/palmas_gpadc.c
+++ b/drivers/iio/adc/palmas_gpadc.c
@@ -795,7 +795,6 @@ static struct platform_driver palmas_gpa
.remove = palmas_gpadc_remove,
.driver = {
.name = MOD_NAME,
-   .owner = THIS_MODULE,
.pm = _pm_ops,
},
 };
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] iio:adc: add iio driver for Palmas (twl6035/7) gpadc

[kbuild test robot]

Hi Nikolaus,

[auto build test WARNING on v4.3-rc4 -- if it's inappropriate base, please 
ignore]


coccinelle warnings: (new ones prefixed by >>)

>> drivers/iio/adc/palmas_gpadc.c:798:3-8: No need to set .owner here. The core 
>> will do it.

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
--
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] extcon: gpio: Add the support for Device tree bindings

[Chanwoo Choi]

This patch adds the support for Device tree bindings of extcon-gpio driver.
The extcon-gpio device tree node must include the both 'extcon-id' and
'extcon-gpio' property.

For exmaple:
usb_cable: extcon-gpio-0 {
compatible = "extcon-gpio";
extcon-id = ;
extcon-gpio = < 1 GPIO_ACTIVE_HIGH>;
}

ta_cable: extcon-gpio-1 {
compatible = "extcon-gpio";
extcon-id = ;
extcon-gpio = < 2 GPIO_ACTIVE_LOW>;
debounce-ms = <50>; /* 50 millisecond */
wakeup-source;
}

_usb {
extcon = <_cable>;
};

 {
extcon = <_cable>;
};

Signed-off-by: Chanwoo Choi 
---
Changes from v1:
- Create the include/dt-bindings/extcon/extcon.h including the identification
  of external connector. These definitions are used in dts file.
- Fix error if CONFIG_OF is disabled.

 .../devicetree/bindings/extcon/extcon-gpio.txt |  38 +++
 drivers/extcon/extcon-gpio.c   | 110 -
 include/dt-bindings/extcon/extcon.h|  44 +
 include/linux/extcon/extcon-gpio.h |   6 +-
 4 files changed, 173 insertions(+), 25 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio.txt
 create mode 100644 include/dt-bindings/extcon/extcon.h

diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt 
b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
new file mode 100644
index ..70c36f729963
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
@@ -0,0 +1,38 @@
+GPIO Extcon device
+
+This is a virtual device used to generate specific external connector
+from the GPIO pin connected to a GPIO pin.
+
+Required properties:
+- compatible: Must be "extcon-gpio".
+- extcon-id: unique id for specific external connector.
+See include/dt-bindings/extcon/extcon.h.
+- extcon-gpio: GPIO pin to detect the external connector. See gpio binding.
+
+Optional properties:
+- debounce-ms: the debounce dealy for GPIO pin in millisecond.
+- wakeup-source: Boolean, extcon can wake-up the system.
+
+Example: Examples of extcon-gpio node as listed below:
+
+   usb_cable: extcon-gpio-0 {
+   compatible = "extcon-gpio";
+   extcon-id = ;
+   extcon-gpio = < 1 GPIO_ACTIVE_HIGH>;
+   }
+
+   ta_cable: extcon-gpio-1 {
+   compatible = "extcon-gpio";
+   extcon-id = ;
+   extcon-gpio = < 2 GPIO_ACTIVE_LOW>;
+   debounce-ms = <50>; /* 50 millisecond */
+   wakeup-source;
+   }
+
+   _usb {
+   extcon = <_cable>;
+   };
+
+{
+   extcon = <_cable>;
+   };
diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 279ff8f6637d..7f3e24aae0c4 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -1,8 +1,8 @@
 /*
  * extcon_gpio.c - Single-state GPIO extcon driver based on extcon class
  *
- * Copyright (C) 2008 Google, Inc.
- * Author: Mike Lockwood 
+ * Copyright (C) 2015 Chanwoo Choi , Samsung Electronics
+ * Copyright (C) 2008 Mike Lockwood , Google, Inc.
  *
  * Modified by MyungJoo Ham  to support extcon
  * (originally switch class is supported)
@@ -26,12 +26,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
 struct gpio_extcon_data {
struct extcon_dev *edev;
int irq;
+   bool irq_wakeup;
struct delayed_work work;
unsigned long debounce_jiffies;
 
@@ -61,19 +63,50 @@ static irqreturn_t gpio_irq_handler(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
-static int gpio_extcon_init(struct device *dev, struct gpio_extcon_data *data)
+static int gpio_extcon_parse_of(struct device *dev,
+   struct gpio_extcon_data *data)
 {
-   struct gpio_extcon_pdata *pdata = data->pdata;
+   struct gpio_extcon_pdata *pdata;
int ret;
 
-   ret = devm_gpio_request_one(dev, pdata->gpio, GPIOF_DIR_IN,
-   dev_name(dev));
+   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return -ENOMEM;
+
+   ret = device_property_read_u32(dev, "extcon-id", >extcon_id);
+   if (ret < 0)
+   return -EINVAL;
+
+   data->id_gpiod = devm_gpiod_get(dev, "extcon", GPIOD_IN);
if (ret < 0)
return ret;
 
-   data->id_gpiod = gpio_to_desc(pdata->gpio);
-   if (!data->id_gpiod)
-   return -EINVAL;
+   data->irq_wakeup = device_property_read_bool(dev, "wakeup-source");
+
+   device_property_read_u32(dev, "debounce-ms", >debounce);
+
+   pdata->irq_flags = 

[PATCH v2] extcon: gpio: Add the support for Device tree bindings

[Chanwoo Choi]

This patch adds the support for Device tree bindings of extcon-gpio driver.
The extcon-gpio device tree node must include the both 'extcon-id' and
'extcon-gpio' property.

For exmaple:
usb_cable: extcon-gpio-0 {
compatible = "extcon-gpio";
extcon-id = ;
extcon-gpio = < 1 GPIO_ACTIVE_HIGH>;
}

ta_cable: extcon-gpio-1 {
compatible = "extcon-gpio";
extcon-id = ;
extcon-gpio = < 2 GPIO_ACTIVE_LOW>;
debounce-ms = <50>; /* 50 millisecond */
wakeup-source;
}

_usb {
extcon = <_cable>;
};

 {
extcon = <_cable>;
};

Signed-off-by: Chanwoo Choi 
---
This patch is based on following patch[1].
[1] https://lkml.org/lkml/2015/10/3/304

Changes from v1:
- Create the include/dt-bindings/extcon/extcon.h including the identification
  of external connector. These definitions are used in dts file.
- Fix error if CONFIG_OF is disabled.

 .../devicetree/bindings/extcon/extcon-gpio.txt |  38 +++
 drivers/extcon/extcon-gpio.c   | 110 -
 include/dt-bindings/extcon/extcon.h|  44 +
 include/linux/extcon/extcon-gpio.h |   6 +-
 4 files changed, 173 insertions(+), 25 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio.txt
 create mode 100644 include/dt-bindings/extcon/extcon.h

diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt 
b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
new file mode 100644
index ..70c36f729963
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
@@ -0,0 +1,38 @@
+GPIO Extcon device
+
+This is a virtual device used to generate specific external connector
+from the GPIO pin connected to a GPIO pin.
+
+Required properties:
+- compatible: Must be "extcon-gpio".
+- extcon-id: unique id for specific external connector.
+See include/dt-bindings/extcon/extcon.h.
+- extcon-gpio: GPIO pin to detect the external connector. See gpio binding.
+
+Optional properties:
+- debounce-ms: the debounce dealy for GPIO pin in millisecond.
+- wakeup-source: Boolean, extcon can wake-up the system.
+
+Example: Examples of extcon-gpio node as listed below:
+
+   usb_cable: extcon-gpio-0 {
+   compatible = "extcon-gpio";
+   extcon-id = ;
+   extcon-gpio = < 1 GPIO_ACTIVE_HIGH>;
+   }
+
+   ta_cable: extcon-gpio-1 {
+   compatible = "extcon-gpio";
+   extcon-id = ;
+   extcon-gpio = < 2 GPIO_ACTIVE_LOW>;
+   debounce-ms = <50>; /* 50 millisecond */
+   wakeup-source;
+   }
+
+   _usb {
+   extcon = <_cable>;
+   };
+
+{
+   extcon = <_cable>;
+   };
diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 279ff8f6637d..7f3e24aae0c4 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -1,8 +1,8 @@
 /*
  * extcon_gpio.c - Single-state GPIO extcon driver based on extcon class
  *
- * Copyright (C) 2008 Google, Inc.
- * Author: Mike Lockwood 
+ * Copyright (C) 2015 Chanwoo Choi , Samsung Electronics
+ * Copyright (C) 2008 Mike Lockwood , Google, Inc.
  *
  * Modified by MyungJoo Ham  to support extcon
  * (originally switch class is supported)
@@ -26,12 +26,14 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
 struct gpio_extcon_data {
struct extcon_dev *edev;
int irq;
+   bool irq_wakeup;
struct delayed_work work;
unsigned long debounce_jiffies;
 
@@ -61,19 +63,50 @@ static irqreturn_t gpio_irq_handler(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
-static int gpio_extcon_init(struct device *dev, struct gpio_extcon_data *data)
+static int gpio_extcon_parse_of(struct device *dev,
+   struct gpio_extcon_data *data)
 {
-   struct gpio_extcon_pdata *pdata = data->pdata;
+   struct gpio_extcon_pdata *pdata;
int ret;
 
-   ret = devm_gpio_request_one(dev, pdata->gpio, GPIOF_DIR_IN,
-   dev_name(dev));
+   pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return -ENOMEM;
+
+   ret = device_property_read_u32(dev, "extcon-id", >extcon_id);
+   if (ret < 0)
+   return -EINVAL;
+
+   data->id_gpiod = devm_gpiod_get(dev, "extcon", GPIOD_IN);
if (ret < 0)
return ret;
 
-   data->id_gpiod = gpio_to_desc(pdata->gpio);
-   if (!data->id_gpiod)
-   return -EINVAL;
+   data->irq_wakeup = device_property_read_bool(dev, "wakeup-source");
+
+   

Re: [PATCH 2/2] leds: rt5033: Add RT5033 Flash led device driver

[Lee Jones]

On Fri, 02 Oct 2015, Ingi Kim wrote:

> This patch adds device driver of Richtek RT5033 PMIC.
> The driver supports a current regulated output to drive
> white LEDs for camera flash.
> 
> Signed-off-by: Ingi Kim 
> ---
>  drivers/leds/Kconfig   |   8 ++
>  drivers/leds/Makefile  |   1 +
>  drivers/leds/leds-rt5033.c | 222 
> +
>  drivers/mfd/rt5033.c   |   3 +
>  include/linux/mfd/rt5033-private.h |  67 +--
>  include/linux/mfd/rt5033.h |  27 -

Please pull the MFD changes out into to separate patch(es).

>  6 files changed, 317 insertions(+), 11 deletions(-)
>  create mode 100644 drivers/leds/leds-rt5033.c

[...]

> diff --git a/drivers/mfd/rt5033.c b/drivers/mfd/rt5033.c
> index d60f916..035421c 100644
> --- a/drivers/mfd/rt5033.c
> +++ b/drivers/mfd/rt5033.c
> @@ -47,6 +47,9 @@ static const struct mfd_cell rt5033_devs[] = {
>   }, {
>   .name = "rt5033-battery",
>   .of_compatible = "richtek,rt5033-battery",
> + }, {
> + .name = "rt5033-led",
> + .of_compatible = "richtek,rt5033-led",
>   },
>  };

Needs to be in a patch of its own.

> diff --git a/include/linux/mfd/rt5033-private.h 
> b/include/linux/mfd/rt5033-private.h
> index 1b63fc2..21c3aff 100644
> --- a/include/linux/mfd/rt5033-private.h
> +++ b/include/linux/mfd/rt5033-private.h
> @@ -25,15 +25,15 @@ enum rt5033_reg {
>   /* Reserved 0x09~0x18 */
>   RT5033_REG_RT_CTRL1 = 0x19,
>   /* Reserved 0x1A~0x20 */
> - RT5033_REG_FLED_FUNCTION1   = 0x21,
> - RT5033_REG_FLED_FUNCTION2   = 0x22,
> - RT5033_REG_FLED_STROBE_CTRL1= 0x23,
> - RT5033_REG_FLED_STROBE_CTRL2= 0x24,
> - RT5033_REG_FLED_CTRL1   = 0x25,
> - RT5033_REG_FLED_CTRL2   = 0x26,
> - RT5033_REG_FLED_CTRL3   = 0x27,
> - RT5033_REG_FLED_CTRL4   = 0x28,
> - RT5033_REG_FLED_CTRL5   = 0x29,
> + RT5033_REG_FL_FUNCTION1 = 0x21,
> + RT5033_REG_FL_FUNCTION2 = 0x22,
> + RT5033_REG_FL_STROBE_CTRL1  = 0x23,
> + RT5033_REG_FL_STROBE_CTRL2  = 0x24,
> + RT5033_REG_FL_CTRL1 = 0x25,
> + RT5033_REG_FL_CTRL2 = 0x26,
> + RT5033_REG_FL_CTRL3 = 0x27,
> + RT5033_REG_FL_CTRL4 = 0x28,
> + RT5033_REG_FL_CTRL5 = 0x29,

Why this change?

The previous naming convention was better.

>   /* Reserved 0x2A~0x40 */
>   RT5033_REG_CTRL = 0x41,
>   RT5033_REG_BUCK_CTRL= 0x42,
> @@ -93,6 +93,55 @@ enum rt5033_reg {
>  #define RT5033_RT_CTRL1_UUG_MASK 0x02
>  #define RT5033_RT_HZ_MASK0x01
>  
> +/* RT5033 FLED Function1 register */
> +#define RT5033_FL_FLED1_MASK 0x94
> +#define RT5033_FL_STROBE_SEL 0x04
> +#define RT5033_FL_PIN_CTRL   0x10
> +#define RT5033_FL_RESET  0x80
> +
> +/* RT5033 FLED Function2 register */
> +#define RT5033_FL_FLED2_MASK 0x81
> +#define RT5033_FL_ENFLED 0x01
> +#define RT5033_FL_SREG_STROBE0x80
> +
> +/* RT5033 FLED Strobe Control1 */
> +#define RT5033_FL_STRBCTRL1_MASK 0xFF
> +#define RT5033_FL_STRBCTRL1_TM_CUR_MAX   0xE0
> +#define RT5033_FL_STRBCTRL1_FL_CUR_DEF   0x0D
> +#define RT5033_FL_STRBCTRL1_FL_CUR_MAX   0x1F
> +
> +/* RT5033 FLED Strobe Control2 */
> +#define RT5033_FL_STRBCTRL2_MASK 0x3F
> +#define RT5033_FL_STRBCTRL2_TM_DEF   0x0F
> +#define RT5033_FL_STRBCTRL2_TM_MAX   0x3F
> +
> +/* RT5033 FLED Control1 */
> +#define RT5033_FL_CTRL1_MASK 0xF7
> +#define RT5033_FL_CTRL1_TORCH_CUR_DEF0x20
> +#define RT5033_FL_CTRL1_TORCH_CUR_MAX0xF0
> +#define RT5033_FL_CTRL1_LBP_DEF  0x02
> +#define RT5033_FL_CTRL1_LBP_MAX  0x07
> +
> +/* RT5033 FLED Control2 */
> +#define RT5033_FL_CTRL2_MASK 0xFF
> +#define RT5033_FL_CTRL2_VMID_DEF 0x37
> +#define RT5033_FL_CTRL2_VMID_MAX 0x3F
> +#define RT5033_FL_CTRL2_TRACK_ALIVE  0x40
> +#define RT5033_FL_CTRL2_MID_TRACK0x80
> +
> +/* RT5033 FLED Control4 */
> +#define RT5033_FL_CTRL4_MASK 0xE0
> +#define RT5033_FL_CTRL4_RESV 0x14
> +#define RT5033_FL_CTRL4_VTRREG_DEF   0x40
> +#define RT5033_FL_CTRL4_VTRREG_MAX   0x60
> +#define RT5033_FL_CTRL4_TRACK_CLK0x80
> +
> +/* RT5033 FLED Control5 */
> +#define RT5033_FL_CTRL5_MASK 0xC0
> +#define RT5033_FL_CTRL5_RESV 0x10
> +#define RT5033_FL_CTRL5_TA_GOOD  0x40
> +#define RT5033_FL_CTRL5_TA_EXIST 0x80
> +
>  /* RT5033 control register */
>  #define RT5033_CTRL_FCCM_BUCK_MASK   0x00
>  #define RT5033_CTRL_BUCKOMS_MASK 0x01
> diff --git a/include/linux/mfd/rt5033.h b/include/linux/mfd/rt5033.h
> index 6cff5cf..45c97b7 100644
> --- a/include/linux/mfd/rt5033.h
> +++ b/include/linux/mfd/rt5033.h
> @@ -12,10 +12,11 @@
>  

RE: [PATCH 1/3][v4] Documentation: dt: dwc3: Add snps,quirk-frame-length-adjustment property

[RAJESH BHAGAT]

Hi Shawn,

Regarding below patch, Felipe has suggested to talk to you:

> [PATCH 3/3][v4] arm: dts: ls1021a: Add quirk for Erratum A009116

talk to you ARM-SoC maintainer.

https://lkml.org/lkml/2015/9/4/7

Please provide your comments. Inform me in case, if a resend is required.

Best Regards,
Rajesh Bhagat

-Original Message-
From: Felipe Balbi [mailto:ba...@ti.com] 
Sent: Saturday, October 03, 2015 1:29 AM
To: Bhagat Rajesh-B56421
Cc: ba...@ti.com; linux-ker...@vger.kernel.org; devicetree@vger.kernel.org; 
linux-...@vger.kernel.org
Subject: Re: [PATCH 1/3][v4] Documentation: dt: dwc3: Add 
snps,quirk-frame-length-adjustment property

On Thu, Sep 24, 2015 at 09:42:59AM +, RAJESH BHAGAT wrote:
> Hi Felipe, 
> 
> Any comments on the below [v4] patches?
> 
> [PATCH 1/3][v4] Documentation: dt: dwc3: Add 
> snps,quirk-frame-length-adjustment property

https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=next=3737c54418c35034127bf2837e9b27a3c3c67940

> [PATCH 2/3][v4] drivers: usb: dwc3: Add frame length adjustment quirk

https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=next=db2be4e9e30c6e43e48c5749d3fc74cee0a6bbb3

> [PATCH 3/3][v4] arm: dts: ls1021a: Add quirk for Erratum A009116

talk to you ARM-SoC maintainer.

> I will be taking forward these patches, as Nikhil has left freescale.

okay, thanks for letting me know.

-- 
balbi
--
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/3] iio:adc:palmas: add DT support

[H. Nikolaus Schaller]

From: Marek Belisko 

Code was found at:
https://android.googlesource.com/kernel/tegra/+/a90856a6626d502d42c6e7abccbdf9d730b36270%5E%21/#F1

Signed-off-by: Laxman Dewangan 
[Fixed minor typos + add channels list to documentation]
Signed-off-by: Marek Belisko 
---
 .../devicetree/bindings/iio/adc/palmas-gpadc.txt   | 46 +++
 drivers/iio/adc/palmas_gpadc.c | 52 +++---
 2 files changed, 93 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt 
b/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
new file mode 100644
index 000..2149afe
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
@@ -0,0 +1,46 @@
+* Palmas general purpose ADC IP block devicetree bindings
+
+Channels list:
+   0 battery type
+   1 battery temp NTC (optional current source)
+   2 GP
+   3 temp (with ext. diode, optional current source)
+   4 GP
+   5 GP
+   6 VBAT_SENSE
+   7 VCC_SENSE
+   8 Backup Battery voltage
+   9 external charger (VCHG)
+   10 VBUS
+   11 DC-DC current probe (how does this work?)
+   12 internal die temp
+   13 internal die temp
+   14 USB ID pin voltage
+   15 test network
+
+Required properties:
+- compatible : Must be "ti,palmas-gpadc".
+
+Optional sub-nodes:
+ti,channel0-current-microamp: Channel 0 current in uA.
+   Values are rounded to derive 0uA, 5uA, 15uA, 20uA.
+ti,channel3-current-microamp: Channel 3 current in uA.
+   Valid are rounded to derive 0uA, 10uA, 400uA, 800uA.
+ti,enable-extended-delay: Enable extended delay.
+
+Example:
+
+pmic {
+   compatible = "ti,twl6035-pmic", "ti,palmas-pmic";
+   ...
+   gpadc {
+   compatible = "ti,palmas-gpadc";
+   interrupts = <18 0
+ 16 0
+ 17 0>;
+   ti,channel0-current-microamp = <5>;
+   ti,channel3-current-microamp = <10>;
+   };
+   };
+   ...
+};
diff --git a/drivers/iio/adc/palmas_gpadc.c b/drivers/iio/adc/palmas_gpadc.c
index 6805d81..1297c81 100644
--- a/drivers/iio/adc/palmas_gpadc.c
+++ b/drivers/iio/adc/palmas_gpadc.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -460,6 +462,34 @@ static const struct iio_chan_spec 
palmas_gpadc_iio_channel[] = {
PALMAS_ADC_CHAN_IIO(IN15, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
 };
 
+static int palmas_gpadc_get_adc_dt_data(struct platform_device *pdev,
+   struct palmas_gpadc_platform_data **gpadc_pdata)
+{
+   struct device_node *np = pdev->dev.of_node;
+   struct palmas_gpadc_platform_data *gp_data;
+   int ret;
+   u32 pval;
+
+   gp_data = devm_kzalloc(>dev, sizeof(*gp_data), GFP_KERNEL);
+   if (!gp_data)
+   return -ENOMEM;
+
+   ret = of_property_read_u32(np, "ti,channel0-current-microamp", );
+   if (!ret)
+   gp_data->ch0_current = pval;
+
+   ret = of_property_read_u32(np, "ti,channel3-current-microamp", );
+   if (!ret)
+   gp_data->ch3_current = pval;
+
+   gp_data->extended_delay = of_property_read_bool(np,
+   "ti,enable-extended-delay");
+
+   *gpadc_pdata = gp_data;
+
+   return 0;
+}
+
 static int palmas_gpadc_probe(struct platform_device *pdev)
 {
struct palmas_gpadc *adc;
@@ -469,12 +499,17 @@ static int palmas_gpadc_probe(struct platform_device 
*pdev)
int ret, i;
 
pdata = dev_get_platdata(pdev->dev.parent);
-   if (!pdata || !pdata->gpadc_pdata) {
-   dev_err(>dev, "No platform data\n");
-   return -ENODEV;
-   }
 
-   gpadc_pdata = pdata->gpadc_pdata;
+   if (pdata && pdata->gpadc_pdata)
+   gpadc_pdata = pdata->gpadc_pdata;
+
+   if (!gpadc_pdata && pdev->dev.of_node) {
+   ret = palmas_gpadc_get_adc_dt_data(pdev, _pdata);
+   if (ret < 0)
+   return ret;
+   }
+   if (!gpadc_pdata)
+   return -EINVAL;
 
indio_dev = devm_iio_device_alloc(>dev, sizeof(*adc));
if (!indio_dev) {
@@ -790,6 +825,12 @@ static const struct dev_pm_ops palmas_pm_ops = {
palmas_gpadc_resume)
 };
 
+static const struct of_device_id of_palmas_gpadc_match_tbl[] = {
+   { .compatible = "ti,palmas-gpadc", },
+   { /* end */ }
+};
+MODULE_DEVICE_TABLE(of, of_palmas_gpadc_match_tbl);
+
 static struct platform_driver palmas_gpadc_driver = {
.probe = palmas_gpadc_probe,
.remove = palmas_gpadc_remove,
@@ -797,6 +838,7 @@ static struct platform_driver palmas_gpadc_driver = {
.name = MOD_NAME,
.owner = 

[PATCH v2 1/3] iio:adc: add iio driver for Palmas (twl6035/7) gpadc

[H. Nikolaus Schaller]

This driver code was found as:

https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc

Fixed various compilation issues and test this driver on omap5 evm.

Signed-off-by: Pradeep Goudagunta 
Signed-off-by: H. Nikolaus Schaller 
Signed-off-by: Marek Belisko 
---
 drivers/iio/adc/Kconfig|   9 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/palmas_gpadc.c | 818 +
 include/linux/mfd/palmas.h |  75 ++--
 4 files changed, 879 insertions(+), 24 deletions(-)
 create mode 100644 drivers/iio/adc/palmas_gpadc.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index eb0cd89..05a0368 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -242,6 +242,15 @@ config NAU7802
  To compile this driver as a module, choose M here: the
  module will be called nau7802.
 
+config PALMAS_GPADC
+   tristate "TI Palmas General Purpose ADC"
+   depends on MFD_PALMAS
+   help
+ Say yes here to build support for Texas Instruments Palmas.
+
+ Palmas series pmic chip (twl6035/6037) is used in smartphones and
+ tablets and supports a 16 channel general purpose ADC.
+
 config QCOM_SPMI_IADC
tristate "Qualcomm SPMI PMIC current ADC"
depends on SPMI
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index a096210..716f112 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
 obj-$(CONFIG_MCP3422) += mcp3422.o
 obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
 obj-$(CONFIG_NAU7802) += nau7802.o
+obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
 obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
 obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
 obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
diff --git a/drivers/iio/adc/palmas_gpadc.c b/drivers/iio/adc/palmas_gpadc.c
new file mode 100644
index 000..6805d81
--- /dev/null
+++ b/drivers/iio/adc/palmas_gpadc.c
@@ -0,0 +1,818 @@
+/*
+ * palmas-adc.c -- TI PALMAS GPADC.
+ *
+ * Copyright (c) 2013, NVIDIA Corporation. All rights reserved.
+ *
+ * Author: Pradeep Goudagunta 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MOD_NAME "palmas-gpadc"
+#define PALMAS_ADC_CONVERSION_TIMEOUT  (msecs_to_jiffies(5000))
+#define PALMAS_TO_BE_CALCULATED 0
+#define PALMAS_GPADC_TRIMINVALID   -1
+
+struct palmas_gpadc_info {
+/* calibration codes and regs */
+   int x1; /* lower ideal code */
+   int x2; /* higher ideal code */
+   int v1; /* expected lower volt reading */
+   int v2; /* expected higher volt reading */
+   u8 trim1_reg;   /* register number for lower trim */
+   u8 trim2_reg;   /* register number for upper trim */
+   int gain;   /* calculated from above (after reading trim regs) */
+   int offset; /* calculated from above (after reading trim regs) */
+   int gain_error; /* calculated from above (after reading trim regs) */
+   bool is_uncalibrated;   /* if channel has calibration data */
+};
+
+#define PALMAS_ADC_INFO(_chan, _x1, _x2, _v1, _v2, _t1, _t2, _is_uncalibrated) 
\
+   [PALMAS_ADC_CH_##_chan] = { \
+   .x1 = _x1, \
+   .x2 = _x2, \
+   .v1 = _v1, \
+   .v2 = _v2, \
+   .gain = PALMAS_TO_BE_CALCULATED, \
+   .offset = PALMAS_TO_BE_CALCULATED, \
+   .gain_error = PALMAS_TO_BE_CALCULATED, \
+   .trim1_reg = PALMAS_GPADC_TRIM##_t1, \
+   .trim2_reg = PALMAS_GPADC_TRIM##_t2,  \
+   .is_uncalibrated = _is_uncalibrated \
+   }
+
+static struct palmas_gpadc_info palmas_gpadc_info[] = {
+   PALMAS_ADC_INFO(IN0, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN1, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN2, 2064, 3112, 1260, 1900, 3, 4, false),
+   PALMAS_ADC_INFO(IN3, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN4, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN5, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN6, 2064, 3112, 2520, 3800, 5, 6, false),
+   PALMAS_ADC_INFO(IN7, 2064, 3112, 2520, 3800, 7, 8, false),
+   PALMAS_ADC_INFO(IN8, 2064, 3112, 3150, 4750, 9, 10, false),
+   PALMAS_ADC_INFO(IN9, 2064, 3112, 5670, 8550, 11, 12, false),
+   PALMAS_ADC_INFO(IN10, 2064, 3112, 3465, 5225, 13, 14, false),
+   PALMAS_ADC_INFO(IN11, 0, 0, 0, 0, INVALID, INVALID, true),
+   PALMAS_ADC_INFO(IN12, 0, 0, 0, 0, INVALID, 

[PATCH v2 3/3] ARM: dts: omap5-uevm: enable iio gpadc for Palmas

[H. Nikolaus Schaller]

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap5-uevm.dts | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 3b16e8f..c78ee2f 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -342,6 +342,15 @@
 
ti,ldo6-vibrator;
 
+   gpadc {
+   compatible = "ti,palmas-gpadc";
+   interrupts = <18 0
+ 16 0
+ 17 0>;
+   ti,channel0-current-microamp = <5>;
+   ti,channel3-current-microamp = <10>;
+   };
+
regulators {
smps123_reg: smps123 {
/* VDD_OPP_MPU */
-- 
2.5.1

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

[PATCH v2 0/3] Add Palmas iio gpadc

[H. Nikolaus Schaller]

V2 changes:
- worked in review comments by Peter Meerwald
- made channels 1 and 3 report (raw) temperature values
- moved PALMAS_GPADC_TRIMINVALID to driver core
- worked in review comments by Jonathan Cameron
- iio_map removed

Add iio driver for the TI Palmas (twl6035, 6037) including device tree bindings.
It enables the gpadc for the OMAP5 uevm.

This patch series is based on original code taken from Android Tegra kernels:
(https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc)

Tegra code was developed by:
Pradeep Goudagunta 
Laxman Dewangan 

Edited and extended for mainline by:
H. Nikolaus Schaller 
Marek Belisko 


H. Nikolaus Schaller (2):
  iio:adc: add iio driver for Palmas (twl6035/7) gpadc
  ARM: dts: omap5-uevm: enable iio gpadc for Palmas

Marek Belisko (1):
  iio:adc:palmas: add DT support

 .../devicetree/bindings/iio/adc/palmas-gpadc.txt   |  46 ++
 arch/arm/boot/dts/omap5-uevm.dts   |   9 +
 drivers/iio/adc/Kconfig|   9 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/palmas_gpadc.c | 860 +
 include/linux/mfd/palmas.h |  75 +-
 6 files changed, 976 insertions(+), 24 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
 create mode 100644 drivers/iio/adc/palmas_gpadc.c

-- 
2.5.1

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

RE: [PATCH 3/5] mtd: brcmnand: Optional DT flag to reset IPROC NAND controller

[Anup Patel]

> -Original Message-
> From: Brian Norris [mailto:computersforpe...@gmail.com]
> Sent: 05 October 2015 03:20
> To: Anup Patel
> Cc: linux-arm-ker...@lists.infradead.org; Rob Herring; Pawel Moll; Mark
> Rutland; Ian Campbell; Kumar Gala; Catalin Marinas; Will Deacon; David
> Woodhouse; Ray Jui; Scott Branden; Florian Fainelli; Pramod Kumar; Vikram
> Prakash; Sandeep Tripathy; devicetree@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-...@lists.infradead.org; bcm-kernel-feedback-
> list; Rafal Milecki
> Subject: Re: [PATCH 3/5] mtd: brcmnand: Optional DT flag to reset IPROC NAND
> controller
> 
> + Rafal (to extend this mighty CC list)
> 
> On Fri, Oct 02, 2015 at 11:26:44PM +0530, Anup Patel wrote:
> > The BRCM NAND controller on NS2 SoC requires a reset to cleanup
> > previously configured NAND controller state.
> >
> > This patch adds optional boolean device tree flag named
> > "brcm,nand-iproc-reset". If this flag is present in NAND controller DT
> > node then BRCM IPROC NAND driver will reset the NAND controller before
> > any commands are issued.
> 
> Is there a reason not to do this reset unconditionally? I recall this came up 
> in
> discussion previously, when the OpenWRT folks were trying to integrate with
> BCMA, where this reset was one of the few differences between the platform-
> device-based driver (i.e., this one) and the BCMA based driver. Might it help
> simplify things a bit if we just did the same thing everywhere?

This driver is currently shared by Cygnus and NS2.

We had similar suggestion when this patch was reviewed
internally in Broadcom.

The rationale for adding optional DT flag is as follows:
1. The NAND controller reset is currently required for NS2 only so
that it is in sane state before any NAND commands are issued. We
are not sure if Cygnus and all future iProc SoCs will require NAND
controller reset.
2. The NAND controller reset in probe would certainly increase
Linux boot time so for certain iProc SoCs we might choose avoid
NAND controller reset to reduce boot time if possible.

Regards
Anup

> 
> Brian
> 
> > Signed-off-by: Anup Patel 
> > Reviewed-by: Pramod KUMAR 
> > Reviewed-by: Ray Jui 
> > Reviewed-by: Scott Branden 
> > ---
> >  drivers/mtd/nand/brcmnand/iproc_nand.c | 19 +++
> >  1 file changed, 19 insertions(+)
> >
> > diff --git a/drivers/mtd/nand/brcmnand/iproc_nand.c
> > b/drivers/mtd/nand/brcmnand/iproc_nand.c
> > index 683495c..d837207 100644
> > --- a/drivers/mtd/nand/brcmnand/iproc_nand.c
> > +++ b/drivers/mtd/nand/brcmnand/iproc_nand.c
> > @@ -11,6 +11,7 @@
> >   * GNU General Public License for more details.
> >   */
> >
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -35,6 +36,10 @@ struct iproc_nand_soc_priv {
> >  #define IPROC_NAND_APB_LE_MODE BIT(24)
> >  #define IPROC_NAND_INT_CTRL_READ_ENABLEBIT(6)
> >
> > +#define IPROC_NAND_RESET_OFFSET0x3f8
> > +#define IPROC_NAND_RESET_BIT_SHIFT 0
> > +#define IPROC_NAND_RESET_BIT
> BIT(IPROC_NAND_RESET_BIT_SHIFT)
> > +
> >  static bool iproc_nand_intc_ack(struct brcmnand_soc *soc)  {
> > struct iproc_nand_soc_priv *priv = soc->priv; @@ -93,6 +98,7 @@
> > static void iproc_nand_apb_access(struct brcmnand_soc *soc, bool
> > prepare)
> >
> >  static int iproc_nand_probe(struct platform_device *pdev)  {
> > +   u32 reset;
> > struct device *dev = >dev;
> > struct iproc_nand_soc_priv *priv;
> > struct brcmnand_soc *soc;
> > @@ -124,6 +130,19 @@ static int iproc_nand_probe(struct platform_device
> *pdev)
> > soc->ctlrdy_set_enabled = iproc_nand_intc_set;
> > soc->prepare_data_bus = iproc_nand_apb_access;
> >
> > +   if (of_property_read_bool(dev->of_node, "brcm,nand-iproc-reset")) {
> > +   /* Put controller in reset and wait 10 usecs */
> > +   reset = readl(priv->idm_base + IPROC_NAND_RESET_OFFSET);
> > +   reset |= IPROC_NAND_RESET_BIT;
> > +   writel(reset, priv->idm_base + IPROC_NAND_RESET_OFFSET);
> > +   udelay(10);
> > +   /* Bring controller out of reset and wait 10 usecs */
> > +   reset = readl(priv->idm_base + IPROC_NAND_RESET_OFFSET);
> > +   reset &= ~IPROC_NAND_RESET_BIT;
> > +   writel(reset, priv->idm_base + IPROC_NAND_RESET_OFFSET);
> > +   udelay(10);
> > +   }
> > +
> > return brcmnand_probe(pdev, soc);
> >  }
> >
> > --
> > 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 2/2] ARM: dts: mediatek: add MT2701 basic support

[Erin Lo]

This adds basic chip support for Mediatek 2701.

Signed-off-by: Erin Lo 
---
 arch/arm/boot/dts/Makefile   |   1 +
 arch/arm/boot/dts/mt2701-evb.dts |  29 
 arch/arm/boot/dts/mt2701.dtsi| 146 +++
 3 files changed, 176 insertions(+)
 create mode 100644 arch/arm/boot/dts/mt2701-evb.dts
 create mode 100644 arch/arm/boot/dts/mt2701.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 233159d..aec787e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -732,6 +732,7 @@ dtb-$(CONFIG_MACH_DOVE) += \
dove-dove-db.dtb \
dove-sbc-a510.dtb
 dtb-$(CONFIG_ARCH_MEDIATEK) += \
+   mt2701-evb.dtb \
mt6580-evbp1.dtb \
mt6589-aquaris5.dtb \
mt6592-evb.dtb \
diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
new file mode 100644
index 000..082ca88
--- /dev/null
+++ b/arch/arm/boot/dts/mt2701-evb.dts
@@ -0,0 +1,29 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author: Erin Lo 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+/dts-v1/;
+#include "mt2701.dtsi"
+
+/ {
+   model = "MediaTek MT2701 evaluation board";
+   compatible = "mediatek,mt2701-evb", "mediatek,mt2701";
+
+   memory {
+   reg = <0 0x8000 0 0x4000>;
+   };
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
new file mode 100644
index 000..69f240f
--- /dev/null
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -0,0 +1,146 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author: Erin.Lo 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include "skeleton64.dtsi"
+
+/ {
+   compatible = "mediatek,mt2701";
+   interrupt-parent = <>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x0>;
+   };
+   cpu@1 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x1>;
+   };
+   cpu@2 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x2>;
+   };
+   cpu@3 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a7";
+   reg = <0x3>;
+   };
+   };
+
+   system_clk: dummy13m {
+   compatible = "fixed-clock";
+   clock-frequency = <1300>;
+   #clock-cells = <0>;
+   };
+
+   rtc_clk: dummy32k {
+   compatible = "fixed-clock";
+   clock-frequency = <32000>;
+   #clock-cells = <0>;
+   };
+
+   uart_clk: dummy26m {
+   compatible = "fixed-clock";
+   clock-frequency = <2600>;
+   #clock-cells = <0>;
+   };
+
+   timer {
+   compatible = "arm,armv7-timer";
+   interrupt-parent = <>;
+   interrupts = ,
+,
+,
+;
+   };
+
+   watchdog: watchdog@10007000 {
+   compatible = "mediatek,mt2701-wdt",
+"mediatek,mt6589-wdt";
+   reg = <0 0x10007000 0 0x100>;
+   };
+
+   timer: timer@10008000 {
+   compatible = "mediatek,mt2701-timer",
+"mediatek,mt6577-timer";
+   reg = <0x10008000 0x80>;
+   interrupts = ;
+   clocks = <_clk>, <_clk>;
+   clock-names = "system-clk", "rtc-clk";
+   };
+
+   sysirq: interrupt-controller@10200100 {
+   compatible = "mediatek,mt2701-sysirq",
+"mediatek,mt6577-sysirq";
+   interrupt-controller;
+   #interrupt-cells = 

[PATCH v2 0/2] Add basic support for Mediatek MT2701 SoC

[Erin Lo]

MT2701 is a SoC based on 32bit ARMv7 architecture. It contains 4 CA7 cores.
MT2701 share many HW IP with MT65xx series. This patchset was tested
on MT2701 evaluation board, and boot to shell ok.

This series contains document bindings, device tree including
interrupt, uart, timer and wdt.

Change in v2:
1. Use one tab in stead of spaces in front of "mediatek,mt2701-sysirq" 
(mediatek,sysirq.txt)
2. Sorting the compatible SoC and add back mt6595 since accidently deleted in 
previous version (mtk-uart.txt)
3. Correct the mt2701-timer from mt6589-timer since the mistake in previous 
version (mediatek,mtk-timer.txt)

Erin Lo (2):
  Document: DT: Add bindings for mediatek MT2701 SoC Platform
  ARM: dts: mediatek: add MT2701 basic support

 Documentation/devicetree/bindings/arm/mediatek.txt |   4 +
 .../bindings/arm/mediatek/mediatek,sysirq.txt  |   1 +
 .../devicetree/bindings/serial/mtk-uart.txt|  14 +-
 .../bindings/timer/mediatek,mtk-timer.txt  |   5 +-
 .../devicetree/bindings/watchdog/mtk-wdt.txt   |   6 +-
 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/mt2701-evb.dts   |  29 
 arch/arm/boot/dts/mt2701.dtsi  | 146 +
 8 files changed, 196 insertions(+), 10 deletions(-)
 create mode 100644 arch/arm/boot/dts/mt2701-evb.dts
 create mode 100644 arch/arm/boot/dts/mt2701.dtsi 

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

[PATCH v2 1/2] Document: DT: Add bindings for mediatek MT2701 SoC Platform

[Erin Lo]

This adds a DT binding documentation for the MT2701 SoC from Mediatek.

Signed-off-by: Erin Lo 
---
 Documentation/devicetree/bindings/arm/mediatek.txt |  4 
 .../devicetree/bindings/arm/mediatek/mediatek,sysirq.txt   |  1 +
 Documentation/devicetree/bindings/serial/mtk-uart.txt  | 14 +++---
 .../devicetree/bindings/timer/mediatek,mtk-timer.txt   |  5 +++--
 Documentation/devicetree/bindings/watchdog/mtk-wdt.txt |  6 +-
 5 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt 
b/Documentation/devicetree/bindings/arm/mediatek.txt
index 618a919..54f43bc 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek.txt
@@ -6,6 +6,7 @@ following property:
 Required root node property:
 
 compatible: Must contain one of
+   "mediatek,mt2701"
"mediatek,mt6580"
"mediatek,mt6589"
"mediatek,mt6592"
@@ -17,6 +18,9 @@ compatible: Must contain one of
 
 Supported boards:
 
+- Evaluation board for MT2701:
+Required root node properties:
+  - compatible = "mediatek,mt2701-evb", "mediatek,mt2701";
 - Evaluation board for MT6580:
 Required root node properties:
   - compatible = "mediatek,mt6580-evbp1", "mediatek,mt6580";
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,sysirq.txt 
b/Documentation/devicetree/bindings/arm/mediatek/mediatek,sysirq.txt
index afef6a8..b8e1674 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,sysirq.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,sysirq.txt
@@ -14,6 +14,7 @@ Required properties:
"mediatek,mt6582-sysirq"
"mediatek,mt6580-sysirq"
"mediatek,mt6577-sysirq"
+   "mediatek,mt2701-sysirq"
 - interrupt-controller : Identifies the node as an interrupt controller
 - #interrupt-cells : Use the same format as specified by GIC in
   Documentation/devicetree/bindings/arm/gic.txt
diff --git a/Documentation/devicetree/bindings/serial/mtk-uart.txt 
b/Documentation/devicetree/bindings/serial/mtk-uart.txt
index 2d47add..a833a01 100644
--- a/Documentation/devicetree/bindings/serial/mtk-uart.txt
+++ b/Documentation/devicetree/bindings/serial/mtk-uart.txt
@@ -2,15 +2,15 @@
 
 Required properties:
 - compatible should contain:
-  * "mediatek,mt8135-uart" for MT8135 compatible UARTS
+  * "mediatek,mt2701-uart" for MT2701 compatible UARTS
+  * "mediatek,mt6580-uart" for MT6580 compatible UARTS
+  * "mediatek,mt6582-uart" for MT6582 compatible UARTS
+  * "mediatek,mt6589-uart" for MT6589 compatible UARTS
+  * "mediatek,mt6795-uart" for MT6795 compatible UARTS
   * "mediatek,mt8127-uart" for MT8127 compatible UARTS
+  * "mediatek,mt8135-uart" for MT8135 compatible UARTS
   * "mediatek,mt8173-uart" for MT8173 compatible UARTS
-  * "mediatek,mt6795-uart" for MT6795 compatible UARTS
-  * "mediatek,mt6589-uart" for MT6589 compatible UARTS
-  * "mediatek,mt6582-uart" for MT6582 compatible UARTS
-  * "mediatek,mt6580-uart" for MT6580 compatible UARTS
-  * "mediatek,mt6577-uart" for all compatible UARTS (MT8173, MT6795,
-MT6589, MT6582, MT6580, MT6577)
+  * "mediatek,mt6577-uart" for MT6577 and all of the above
 
 - reg: The base address of the UART register bank.
 
diff --git a/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt 
b/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt
index 53a3029..54f858c 100644
--- a/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt
+++ b/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt
@@ -3,10 +3,11 @@ Mediatek MT6577, MT6572 and MT6589 Timers
 
 Required properties:
 - compatible should contain:
+   * "mediatek,mt2701-timer" for MT2701 compatible timers
* "mediatek,mt6589-timer" for MT6589 compatible timers
* "mediatek,mt6580-timer" for MT6580 compatible timers
-   * "mediatek,mt6577-timer" for all compatible timers (MT6589, MT6580,
-   MT6577)
+   * "mediatek,mt6577-timer" for all compatible timers (MT2701, MT6589,
+   MT6580, MT6577)
 - reg: Should contain location and length for timers register.
 - clocks: Clocks driving the timer hardware. This list should include two
clocks. The order is system clock and as second clock the RTC clock.
diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt 
b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
index af9eb5b..6a00939 100644
--- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt
@@ -2,7 +2,11 @@ Mediatek SoCs Watchdog timer
 
 Required properties:
 
-- compatible : should be "mediatek,mt6589-wdt"
+- compatible should contain:
+   * "mediatek,mt2701-wdt" for MT2701 compatible watchdog timers
+   * "mediatek,mt6589-wdt" for all compatible watchdog timers (MT2701,
+   MT6589)
+
 - reg : Specifies base physical address and size 

Re: [PATCH v2] extcon: gpio: Add the support for Device tree bindings

[MyungJoo Ham]

>   
>  This patch adds the support for Device tree bindings of extcon-gpio driver.
> The extcon-gpio device tree node must include the both 'extcon-id' and
> 'extcon-gpio' property.
> 
[]
> 
> Signed-off-by: Chanwoo Choi 


Except for some beautification issues described below,

Signed-off-by: MyungJoo Ham 

> ---
> This patch is based on following patch[1].
> [1] https://lkml.org/lkml/2015/10/3/304
> 
> Changes from v1:
> - Create the include/dt-bindings/extcon/extcon.h including the identification
>   of external connector. These definitions are used in dts file.
> - Fix error if CONFIG_OF is disabled.
> 
>  .../devicetree/bindings/extcon/extcon-gpio.txt |  38 +++
>  drivers/extcon/extcon-gpio.c   | 110 
> -
>  include/dt-bindings/extcon/extcon.h|  44 +
>  include/linux/extcon/extcon-gpio.h |   6 +-
>  4 files changed, 173 insertions(+), 25 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio.txt
>  create mode 100644 include/dt-bindings/extcon/extcon.h
> 
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt 
> b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
> new file mode 100644
> index ..70c36f729963
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
[]
> diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
> index 279ff8f6637d..7f3e24aae0c4 100644
> --- a/drivers/extcon/extcon-gpio.c
> +++ b/drivers/extcon/extcon-gpio.c
> @@ -1,8 +1,8 @@
>  /*
>   * extcon_gpio.c - Single-state GPIO extcon driver based on extcon class
>   *
> - * Copyright (C) 2008 Google, Inc.
> - * Author: Mike Lockwood 
> + * Copyright (C) 2015 Chanwoo Choi , Samsung 
> Electronics
> + * Copyright (C) 2008 Mike Lockwood , Google, Inc.
>   *
>   * Modified by MyungJoo Ham  to support extcon
>   * (originally switch class is supported)

Let's make it in chronological order.
(may need to "beautify the last two lines as well)

I.e., 2008-->2012-->2015 or 2015-->2012-->2008.
Not 2015-->2008-->2012


> @@ -26,12 +26,14 @@
[]
> diff --git a/include/dt-bindings/extcon/extcon.h 
> b/include/dt-bindings/extcon/extcon.h
> new file mode 100644
> index ..14c7f36b2206
> --- /dev/null
> +++ b/include/dt-bindings/extcon/extcon.h
[]
> diff --git a/include/linux/extcon/extcon-gpio.h 
> b/include/linux/extcon/extcon-gpio.h
> index 7cacafb78b09..bcc6d7f7116a 100644
> --- a/include/linux/extcon/extcon-gpio.h
> +++ b/include/linux/extcon/extcon-gpio.h
[]
> @@ -38,7 +38,7 @@ struct gpio_extcon_pdata {
>   unsigned int extcon_id;
>   unsigned gpio;
>   bool gpio_active_low;
> - unsigned long debounce;
> + unsigned int debounce;

What about u32, making it more clear?
( > +   device_property_read_u32(dev, "debounce-ms", >debounce); )

>   unsigned long irq_flags;
>  
>   bool check_on_resume;
> -- 
> 1.8.0
N�r��yb�X��ǧv�^�)޺{.n�+���z��z��z)w*jg����ݢj/���z�ޖ��2�ޙ&�)ߡ�a�����G���h��j:+v���w��٥

[PATCH v3 3/4] drivers: clk: st: Correct the pll-type for A9 for stih418

[Gabriel Fernandez]

Add support for new PLL-type for stih418 A9-PLL.
Currently the 407_A9_PLL type being used, it is corrected with this patch
4600c28 PLL allows to reach higher frequencies
so its programming algorithm is extended.

Signed-off-by: Pankaj Dev 
Signed-off-by: Gabriel Fernandez 
---
 .../devicetree/bindings/clock/st/st,clkgen-pll.txt |   1 +
 drivers/clk/st/clkgen-pll.c| 194 +
 2 files changed, 195 insertions(+)

diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt 
b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt
index e2c6db0..8f84c81 100644
--- a/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt
+++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt
@@ -23,6 +23,7 @@ Required properties:
"st,stih407-plls-c32-a9",   "st,clkgen-plls-c32"
"st,plls-c32-cx_0", "st,clkgen-plls-c32"
"st,plls-c32-cx_1", "st,clkgen-plls-c32"
+   "st,stih418-plls-c28-a9",   "st,clkgen-plls-c32"
 
"st,stih415-gpu-pll-c32",   "st,clkgengpu-pll-c32"
"st,stih416-gpu-pll-c32",   "st,clkgengpu-pll-c32"
diff --git a/drivers/clk/st/clkgen-pll.c b/drivers/clk/st/clkgen-pll.c
index 22b6201..ba75cae 100644
--- a/drivers/clk/st/clkgen-pll.c
+++ b/drivers/clk/st/clkgen-pll.c
@@ -44,6 +44,13 @@ DEFINE_SPINLOCK(clkgen_a9_lock);
 
 #define C32_MAX_ODFS (4)
 
+/*
+ * PLL configuration register bits for PLL4600 C28
+ */
+#define C28_NDIV_MASK (0xff)
+#define C28_IDF_MASK (0x7)
+#define C28_ODF_MASK (0x3f)
+
 struct clkgen_pll_data {
struct clkgen_field pdn_status;
struct clkgen_field pdn_ctrl;
@@ -68,6 +75,7 @@ static const struct clk_ops st_pll800c65_ops;
 static const struct clk_ops stm_pll3200c32_ops;
 static const struct clk_ops stm_pll3200c32_a9_ops;
 static const struct clk_ops st_pll1200c32_ops;
+static const struct clk_ops stm_pll4600c28_ops;
 
 static const struct clkgen_pll_data st_pll1600c65_ax = {
.pdn_status = CLKGEN_FIELD(0x0, 0x1,19),
@@ -256,6 +264,22 @@ static const struct clkgen_pll_data st_pll3200c32_407_a9 = 
{
.ops= _pll3200c32_a9_ops,
 };
 
+static struct clkgen_pll_data st_pll4600c28_418_a9 = {
+   /* 418 A9 */
+   .pdn_status = CLKGEN_FIELD(0x1a8,   0x1,0),
+   .pdn_ctrl   = CLKGEN_FIELD(0x1a8,   0x1,0),
+   .locked_status  = CLKGEN_FIELD(0x87c,   0x1,0),
+   .ndiv   = CLKGEN_FIELD(0x1b0,   C28_NDIV_MASK,  0),
+   .idf= CLKGEN_FIELD(0x1a8,   C28_IDF_MASK,   25),
+   .num_odfs = 1,
+   .odf= { CLKGEN_FIELD(0x1b0, C28_ODF_MASK,   8) },
+   .odf_gate   = { CLKGEN_FIELD(0x1ac, 0x1,28) },
+   .switch2pll_en  = true,
+   .switch2pll = CLKGEN_FIELD(0x1a4,   0x1,1),
+   .lock   = _a9_lock,
+   .ops= _pll4600c28_ops,
+};
+
 /**
  * DOC: Clock Generated by PLL, rate set and enabled by bootloader
  *
@@ -611,6 +635,163 @@ static unsigned long recalc_stm_pll1200c32(struct clk_hw 
*hw,
return rate;
 }
 
+/* PLL output structure
+ * FVCO >> /2 >> FVCOBY2 (no output)
+ * |> Divider (ODF) >> PHI
+ *
+ * FVCOby2 output = (input * 2 * NDIV) / IDF (assuming FRAC_CONTROL==L)
+ *
+ * Rules:
+ *   4Mhz <= INFF input <= 350Mhz
+ *   4Mhz <= INFIN (INFF / IDF) <= 50Mhz
+ *   19.05Mhz <= FVCOby2 output (PHI w ODF=1) <= 3000Mhz
+ *   1 <= i (register/dec value for IDF) <= 7
+ *   8 <= n (register/dec value for NDIV) <= 246
+ */
+
+static int clk_pll4600c28_get_params(unsigned long input, unsigned long output,
+ struct stm_pll *pll)
+{
+
+   unsigned long i, infin, n;
+   unsigned long deviation = ~0;
+   unsigned long new_freq, new_deviation;
+
+   /* Output clock range: 19Mhz to 3000Mhz */
+   if (output < 1900 || output > 30u)
+   return -EINVAL;
+
+   /* For better jitter, IDF should be smallest and NDIV must be maximum */
+   for (i = 1; i <= 7 && deviation; i++) {
+   /* INFIN checks */
+   infin = input / i;
+   if (infin < 400 || infin > 5000)
+   continue;   /* Invalid case */
+
+   n = output / (infin * 2);
+   if (n < 8 || n > 246)
+   continue;   /* Invalid case */
+   if (n < 246)
+   n++;/* To work around 'y' when n=x.y */
+
+   for (; n >= 8 && deviation; n--) {
+   new_freq = infin * 2 * n;
+   if (new_freq < output)
+   break;  /* Optimization: shorting loop */
+
+   new_deviation = new_freq - output;
+   if (!new_deviation || 

[PATCH v3 0/4] ST PLL improvement

[Gabriel Fernandez]

Changes in v3:
 - reorganize patch 1 and 2 to avoid a break git bisect

Changes in v2:
 - Add const for st_pll4600c28_418_a9 structure
 - Use readl_relaxed_poll_timeout macro instead Jiffies
 - Add patch to enable stih418 A9 pll via DT.

This patchset is based on '[PATCH 0/2] ST PLL fixes for 4.3'

Gabriel Fernandez (4):
  drivers: clk: st: Support for enable/disable in Clockgen PLLs
  drivers: clk: st: PLL rate change implementation for DVFS
  drivers: clk: st: Correct the pll-type for A9 for stih418
  ARM: STi: DT: Add support for stih418 A9 pll

 .../devicetree/bindings/clock/st/st,clkgen-pll.txt |   1 +
 arch/arm/boot/dts/stih418-clock.dtsi   |   2 +-
 drivers/clk/st/clkgen-mux.c|   3 +
 drivers/clk/st/clkgen-pll.c| 468 -
 drivers/clk/st/clkgen.h|   2 +
 5 files changed, 467 insertions(+), 9 deletions(-)

-- 
1.9.1

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

[PATCH v3 1/4] drivers: clk: st: Support for enable/disable in Clockgen PLLs

[Gabriel Fernandez]

The patch adds support for enable/disable of the Clockgen PLLs.
clkgen_pll_enable/clkgen_pll_disable added as generic function for all PLLs.

Signed-off-by: Pankaj Dev 
Signed-off-by: Gabriel Fernandez 
---
 drivers/clk/st/clkgen-pll.c | 60 -
 1 file changed, 59 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/st/clkgen-pll.c b/drivers/clk/st/clkgen-pll.c
index b2a332c..092f82c 100644
--- a/drivers/clk/st/clkgen-pll.c
+++ b/drivers/clk/st/clkgen-pll.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "clkgen.h"
 
@@ -43,6 +44,7 @@ static DEFINE_SPINLOCK(clkgena_c32_odf_lock);
 
 struct clkgen_pll_data {
struct clkgen_field pdn_status;
+   struct clkgen_field pdn_ctrl;
struct clkgen_field locked_status;
struct clkgen_field mdiv;
struct clkgen_field ndiv;
@@ -62,6 +64,7 @@ static const struct clk_ops st_pll1200c32_ops;
 
 static const struct clkgen_pll_data st_pll1600c65_ax = {
.pdn_status = CLKGEN_FIELD(0x0, 0x1,19),
+   .pdn_ctrl   = CLKGEN_FIELD(0x10,0x1,0),
.locked_status  = CLKGEN_FIELD(0x0, 0x1,31),
.mdiv   = CLKGEN_FIELD(0x0, C65_MDIV_PLL1600_MASK,  0),
.ndiv   = CLKGEN_FIELD(0x0, C65_NDIV_MASK,  8),
@@ -70,6 +73,7 @@ static const struct clkgen_pll_data st_pll1600c65_ax = {
 
 static const struct clkgen_pll_data st_pll800c65_ax = {
.pdn_status = CLKGEN_FIELD(0x0, 0x1,19),
+   .pdn_ctrl   = CLKGEN_FIELD(0xC, 0x1,1),
.locked_status  = CLKGEN_FIELD(0x0, 0x1,31),
.mdiv   = CLKGEN_FIELD(0x0, C65_MDIV_PLL800_MASK,   0),
.ndiv   = CLKGEN_FIELD(0x0, C65_NDIV_MASK,  8),
@@ -79,6 +83,7 @@ static const struct clkgen_pll_data st_pll800c65_ax = {
 
 static const struct clkgen_pll_data st_pll3200c32_a1x_0 = {
.pdn_status = CLKGEN_FIELD(0x0, 0x1,31),
+   .pdn_ctrl   = CLKGEN_FIELD(0x18,0x1,0),
.locked_status  = CLKGEN_FIELD(0x4, 0x1,31),
.ndiv   = CLKGEN_FIELD(0x0, C32_NDIV_MASK,  0x0),
.idf= CLKGEN_FIELD(0x4, C32_IDF_MASK,   0x0),
@@ -96,6 +101,7 @@ static const struct clkgen_pll_data st_pll3200c32_a1x_0 = {
 
 static const struct clkgen_pll_data st_pll3200c32_a1x_1 = {
.pdn_status = CLKGEN_FIELD(0xC, 0x1,31),
+   .pdn_ctrl   = CLKGEN_FIELD(0x18,0x1,1),
.locked_status  = CLKGEN_FIELD(0x10,0x1,31),
.ndiv   = CLKGEN_FIELD(0xC, C32_NDIV_MASK,  0x0),
.idf= CLKGEN_FIELD(0x10,C32_IDF_MASK,   0x0),
@@ -114,6 +120,7 @@ static const struct clkgen_pll_data st_pll3200c32_a1x_1 = {
 /* 415 specific */
 static const struct clkgen_pll_data st_pll3200c32_a9_415 = {
.pdn_status = CLKGEN_FIELD(0x0, 0x1,0),
+   .pdn_ctrl   = CLKGEN_FIELD(0x0, 0x1,0),
.locked_status  = CLKGEN_FIELD(0x6C,0x1,0),
.ndiv   = CLKGEN_FIELD(0x0, C32_NDIV_MASK,  9),
.idf= CLKGEN_FIELD(0x0, C32_IDF_MASK,   22),
@@ -125,6 +132,7 @@ static const struct clkgen_pll_data st_pll3200c32_a9_415 = {
 
 static const struct clkgen_pll_data st_pll3200c32_ddr_415 = {
.pdn_status = CLKGEN_FIELD(0x0, 0x1,0),
+   .pdn_ctrl   = CLKGEN_FIELD(0x0, 0x1,0),
.locked_status  = CLKGEN_FIELD(0x100,   0x1,0),
.ndiv   = CLKGEN_FIELD(0x8, C32_NDIV_MASK,  0),
.idf= CLKGEN_FIELD(0x0, C32_IDF_MASK,   25),
@@ -137,7 +145,8 @@ static const struct clkgen_pll_data st_pll3200c32_ddr_415 = 
{
 };
 
 static const struct clkgen_pll_data st_pll1200c32_gpu_415 = {
-   .pdn_status = CLKGEN_FIELD(0x144,   0x1,3),
+   .pdn_status = CLKGEN_FIELD(0x4, 0x1,0),
+   .pdn_ctrl   = CLKGEN_FIELD(0x4, 0x1,0),
.locked_status  = CLKGEN_FIELD(0x168,   0x1,0),
.ldf= CLKGEN_FIELD(0x0, C32_LDF_MASK,   3),
.idf= CLKGEN_FIELD(0x0, C32_IDF_MASK,   0),
@@ -149,6 +158,7 @@ static const struct clkgen_pll_data st_pll1200c32_gpu_415 = 
{
 /* 416 specific */
 static const struct clkgen_pll_data st_pll3200c32_a9_416 = {
.pdn_status = CLKGEN_FIELD(0x0, 0x1,0),
+   .pdn_ctrl   = CLKGEN_FIELD(0x0, 0x1,0),
   

Re: [PATCH v4 1/3] leds: netxbig: add device tree binding

[Simon Guinot]

On Mon, Sep 28, 2015 at 09:58:44AM +0200, Jacek Anaszewski wrote:
> Hi Rob.
> 
> If you are satisfied with Simon's explanation, could you confirm
> that with your ack, please?

Hi Rob,

Please let us know your answer.

Thanks in advance.

Simon

> On 09/22/2015 11:30 AM, Simon Guinot wrote:
> >On Mon, Sep 21, 2015 at 10:38:45AM -0500, Rob Herring wrote:
> >
> >Hi Rob,
> >
> >Thanks for your feedback. Please, see my answers below.
> >
> >>On 09/17/2015 10:59 AM, Simon Guinot wrote:
> >>>This patch adds device tree support for the netxbig LEDs.
> >>>
> >>>This also introduces a additionnal DT binding for the GPIO extension bus
> >>>(netxbig-gpio-ext) used to configure the LEDs. Since this bus could also
> >>>be used to control other devices, then it seems more suitable to have it
> >>>in a separate DT binding.
> >>>
> >>>Signed-off-by: Simon Guinot 
> >>>Acked-by: Linus Walleij 
> >>>---
> >>>  .../devicetree/bindings/gpio/netxbig-gpio-ext.txt  |  22 ++
> >>>  .../devicetree/bindings/leds/leds-netxbig.txt  |  92 
> >>>  drivers/leds/leds-netxbig.c| 258 
> >>> +++--
> >>>  include/dt-bindings/leds/leds-netxbig.h|  18 ++
> >>>  4 files changed, 369 insertions(+), 21 deletions(-)
> >>>  create mode 100644 
> >>> Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt
> >>>  create mode 100644 
> >>> Documentation/devicetree/bindings/leds/leds-netxbig.txt
> >>>  create mode 100644 include/dt-bindings/leds/leds-netxbig.h
> >>>
> >>>Changes for v2:
> >>>- Check timer mode value retrieved from DT.
> >>>- In netxbig_leds_get_of_pdata, don't use unsigned long variables to get
> >>>   timer delay values from DT with function of_property_read_u32_index.
> >>>   Instead, use a temporary u32 variable. This allows to silence a static
> >>>   checker warning.
> >>>- Make timer property optional in the binding documentation. It is now
> >>>   aligned with the driver code.
> >>>
> >>>Changes for v3:
> >>>- Fix pointer usage with the temporary u32 variable while calling
> >>>   of_property_read_u32_index.
> >>>
> >>>Changes for v4:
> >>>- In DT binding document netxbig-gpio-ext.txt, detail byte order for
> >>>   registers and latch mechanism for "enable-gpio".
> >>>- In leds-netxbig.c, add some error messages.
> >>>- In leds-netxbig.c, fix some "sizeof" style issues.
> >>>- In leds-netxbig.c, in netxbig_leds_get_of_pdata(), move the
> >>>   of_property_read_string() calls after the error-prone checks.
> >>>- Add some Acked-by.
> >>>
> >>>diff --git a/Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt 
> >>>b/Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt
> >>>new file mode 100644
> >>>index ..50ec2e690701
> >>>--- /dev/null
> >>>+++ b/Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt
> >>>@@ -0,0 +1,22 @@
> >>>+Binding for the GPIO extension bus found on some LaCie/Seagate boards
> >>>+(Example: 2Big/5Big Network v2, 2Big NAS).
> >>>+
> >>>+Required properties:
> >>>+- compatible: "lacie,netxbig-gpio-ext".
> >>>+- addr-gpios: GPIOs representing the address register (LSB -> MSB).
> >>>+- data-gpios: GPIOs representing the data register (LSB -> MSB).
> >>>+- enable-gpio: latches the new configuration (address, data) on raising 
> >>>edge.
> >>>+
> >>>+Example:
> >>>+
> >>>+netxbig_gpio_ext: netxbig-gpio-ext {
> >>>+  compatible = "lacie,netxbig-gpio-ext";
> >>>+
> >>>+  addr-gpios = < 15 GPIO_ACTIVE_HIGH
> >>>+ 16 GPIO_ACTIVE_HIGH
> >>>+ 17 GPIO_ACTIVE_HIGH>;
> >>>+  data-gpios = < 12 GPIO_ACTIVE_HIGH
> >>>+ 13 GPIO_ACTIVE_HIGH
> >>>+ 14 GPIO_ACTIVE_HIGH>;
> >>>+  enable-gpio = < 29 GPIO_ACTIVE_HIGH>;
> >>>+};
> >>>diff --git a/Documentation/devicetree/bindings/leds/leds-netxbig.txt 
> >>>b/Documentation/devicetree/bindings/leds/leds-netxbig.txt
> >>>new file mode 100644
> >>>index ..efadbecbfeb9
> >>>--- /dev/null
> >>>+++ b/Documentation/devicetree/bindings/leds/leds-netxbig.txt
> >>>@@ -0,0 +1,92 @@
> >>>+Binding for the CPLD LEDs (GPIO extension bus) found on some LaCie/Seagate
> >>>+boards (Example: 2Big/5Big Network v2, 2Big NAS).
> >>>+
> >>>+Required properties:
> >>>+- compatible: "lacie,netxbig-leds".
> >>>+- gpio-ext: Phandle for the gpio-ext bus.
> >>
> >>Would being a subnode of gpio-ext work instead?
> >
> >Well, it is really unclear to me. I think that the GPIO extension bus
> >can be seen as a "kind of" GPIO chip. And devices which are using a GPIO
> >resource are not represented in DT as sub-nodes of the GPIO node. That's
> >why I chose to use a phandle here.
> >
> >Let me know if this representation is not correct.
> >
> >>
> >>>+
> >>>+Optional properties:
> >>>+- timers: Timer array. Each timer entry is represented by three integers:
> >>>+  Mode (gpio-ext bus), delay_on and delay_off.
> >>>+
> >>>+Each LED is represented as a sub-node of the netxbig-leds device.
> >>>+

[PATCH v3 2/4] drivers: clk: st: PLL rate change implementation for DVFS

[Gabriel Fernandez]

Change A9 PLL rate, as per requirement from the cpufreq framework,
for DVFS. For rate change, the A9 clock needs to be temporarily sourced
from PLL external to A9 and then sourced back to A9-PLL

Signed-off-by: Pankaj Dev 
Signed-off-by: Gabriel Fernandez 
---
 drivers/clk/st/clkgen-mux.c |   3 +
 drivers/clk/st/clkgen-pll.c | 220 ++--
 drivers/clk/st/clkgen.h |   2 +
 3 files changed, 215 insertions(+), 10 deletions(-)

diff --git a/drivers/clk/st/clkgen-mux.c b/drivers/clk/st/clkgen-mux.c
index 4f7f6c0..5dc5ce2 100644
--- a/drivers/clk/st/clkgen-mux.c
+++ b/drivers/clk/st/clkgen-mux.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include "clkgen.h"
 
 static DEFINE_SPINLOCK(clkgena_divmux_lock);
 static DEFINE_SPINLOCK(clkgenf_lock);
@@ -576,6 +577,7 @@ static struct clkgen_mux_data stih415_a9_mux_data = {
.offset = 0,
.shift = 1,
.width = 2,
+   .lock = _a9_lock,
 };
 static struct clkgen_mux_data stih416_a9_mux_data = {
.offset = 0,
@@ -586,6 +588,7 @@ static struct clkgen_mux_data stih407_a9_mux_data = {
.offset = 0x1a4,
.shift = 0,
.width = 2,
+   .lock = _a9_lock,
 };
 
 static const struct of_device_id mux_of_match[] = {
diff --git a/drivers/clk/st/clkgen-pll.c b/drivers/clk/st/clkgen-pll.c
index 092f82c..22b6201 100644
--- a/drivers/clk/st/clkgen-pll.c
+++ b/drivers/clk/st/clkgen-pll.c
@@ -23,6 +23,7 @@
 #include "clkgen.h"
 
 static DEFINE_SPINLOCK(clkgena_c32_odf_lock);
+DEFINE_SPINLOCK(clkgen_a9_lock);
 
 /*
  * Common PLL configuration register bits for PLL800 and PLL1600 C65
@@ -39,6 +40,7 @@ static DEFINE_SPINLOCK(clkgena_c32_odf_lock);
 #define C32_IDF_MASK (0x7)
 #define C32_ODF_MASK (0x3f)
 #define C32_LDF_MASK (0x7f)
+#define C32_CP_MASK (0x1f)
 
 #define C32_MAX_ODFS (4)
 
@@ -51,15 +53,20 @@ struct clkgen_pll_data {
struct clkgen_field pdiv;
struct clkgen_field idf;
struct clkgen_field ldf;
+   struct clkgen_field cp;
unsigned int num_odfs;
struct clkgen_field odf[C32_MAX_ODFS];
struct clkgen_field odf_gate[C32_MAX_ODFS];
+   bool switch2pll_en;
+   struct clkgen_field switch2pll;
+   spinlock_t *lock;
const struct clk_ops *ops;
 };
 
 static const struct clk_ops st_pll1600c65_ops;
 static const struct clk_ops st_pll800c65_ops;
 static const struct clk_ops stm_pll3200c32_ops;
+static const struct clk_ops stm_pll3200c32_a9_ops;
 static const struct clk_ops st_pll1200c32_ops;
 
 static const struct clkgen_pll_data st_pll1600c65_ax = {
@@ -242,7 +249,11 @@ static const struct clkgen_pll_data st_pll3200c32_407_a9 = 
{
.num_odfs = 1,
.odf= { CLKGEN_FIELD(0x1b0, C32_ODF_MASK,   8) },
.odf_gate   = { CLKGEN_FIELD(0x1ac, 0x1,28) },
-   .ops= _pll3200c32_ops,
+   .switch2pll_en  = true,
+   .cp = CLKGEN_FIELD(0x1a8,   C32_CP_MASK,1),
+   .switch2pll = CLKGEN_FIELD(0x1a4,   0x1,1),
+   .lock = _a9_lock,
+   .ops= _pll3200c32_a9_ops,
 };
 
 /**
@@ -268,10 +279,26 @@ struct clkgen_pll {
struct clk_hw   hw;
struct clkgen_pll_data  *data;
void __iomem*regs_base;
+   spinlock_t  *lock;
+
+   u32 ndiv;
+   u32 idf;
+   u32 odf;
+   u32 cp;
 };
 
 #define to_clkgen_pll(_hw) container_of(_hw, struct clkgen_pll, hw)
 
+struct stm_pll {
+   unsigned long mdiv;
+   unsigned long ndiv;
+   unsigned long pdiv;
+   unsigned long odf;
+   unsigned long idf;
+   unsigned long ldf;
+   unsigned long cp;
+};
+
 static int clkgen_pll_is_locked(struct clk_hw *hw)
 {
struct clkgen_pll *pll = to_clkgen_pll(hw);
@@ -287,7 +314,7 @@ static int clkgen_pll_is_enabled(struct clk_hw *hw)
return !poweroff;
 }
 
-static int clkgen_pll_enable(struct clk_hw *hw)
+static int __clkgen_pll_enable(struct clk_hw *hw)
 {
struct clkgen_pll *pll = to_clkgen_pll(hw);
void __iomem *base =  pll->regs_base;
@@ -303,24 +330,62 @@ static int clkgen_pll_enable(struct clk_hw *hw)
ret = readl_relaxed_poll_timeout(base + field->offset, reg,
!!((reg >> field->shift) & field->mask),  0, 1);
 
-   if (!ret)
+   if (!ret) {
+   if (pll->data->switch2pll_en)
+   CLKGEN_WRITE(pll, switch2pll, 0);
+
pr_debug("%s:%s enabled\n", __clk_get_name(hw->clk), __func__);
+   }
 
return ret;
 }
 
-static void clkgen_pll_disable(struct clk_hw *hw)
+static int clkgen_pll_enable(struct clk_hw *hw)
+{
+   struct clkgen_pll *pll = to_clkgen_pll(hw);
+   unsigned long flags = 0;
+   int ret = 0;
+
+   if (pll->lock)
+   spin_lock_irqsave(pll->lock, flags);
+
+   ret = __clkgen_pll_enable(hw);
+
+   if 

[PATCH v3 4/4] ARM: STi: DT: Add support for stih418 A9 pll

[Gabriel Fernandez]

Add support for new PLL-type for stih418 A9-PLL.

Signed-off-by: Gabriel Fernandez 
---
 arch/arm/boot/dts/stih418-clock.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/stih418-clock.dtsi 
b/arch/arm/boot/dts/stih418-clock.dtsi
index 148e177..ae6d997 100644
--- a/arch/arm/boot/dts/stih418-clock.dtsi
+++ b/arch/arm/boot/dts/stih418-clock.dtsi
@@ -44,7 +44,7 @@
 
clockgen_a9_pll: clockgen-a9-pll {
#clock-cells = <1>;
-   compatible = "st,stih407-plls-c32-a9", 
"st,clkgen-plls-c32";
+   compatible = "st,stih418-plls-c28-a9", 
"st,clkgen-plls-c32";
 
clocks = <_sysin>;
 
-- 
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 v4] QEMU fw_cfg DMA interface documentation

[Stefan Hajnoczi]

On Thu, Oct 1, 2015 at 1:15 PM, Marc Marí  wrote:
> +Additionaly, if the DMA interface is available then a read to the DMA Address
> +will return 0x51454d5520434647 ("QEMU CFG" in big-endian format).

What does this mean?

Stefan
--
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 13/13] scsi: ufs: Add exynos ufs platform data

[Alim Akhtar]

CCing Rob Herring,

Hi Arnd,

On 10/01/2015 04:59 PM, Arnd Bergmann wrote:

On Thursday 01 October 2015 18:46:34 kbuild test robot wrote:

[auto build test results on v4.3-rc3 -- if it's inappropriate base, please 
ignore]

config: x86_64-allmodconfig (attached as .config)
reproduce:
 git checkout 6e153e3bf7c68b019e987c5a0ffadebd9c7d4fbb
 # save the attached .config to linux build tree
 make ARCH=x86_64

All error/warnings (new ones prefixed by >>):


ERROR: "ufs_hba_exynos_ops" [drivers/scsi/ufs/ufshcd-pltfrm.ko] undefined!





Ah, this seems to be a case of layering violation. It would be best to
restructure the code so that the exynos driver registers a platform_driver
by itself for the respective DT compatible string, and then calls
into the common code from its probe function, rather than having the
generic driver know about the specific backends.

That approach will also make the generic driver more scalable as we
add further chip-specific variations, and matches what we do in other
drivers.



Looks like some discussions on ufs variant driver probe method happened 
here [1] few months back.

[1]-> https://lkml.org/lkml/2015/6/3/180

And since ufshcd-pltfrm is already a platform_driver, so I just add a 
platform data for the variant driver.
I should have add a IS_ENABLED for it to avoid the compilation error for 
other ARCH.



Thanks!!


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 13/13] scsi: ufs: Add exynos ufs platform data

[Arnd Bergmann]

On Monday 05 October 2015 13:44:29 Alim Akhtar wrote:
> CCing Rob Herring,
> 
> Hi Arnd,
> 
> On 10/01/2015 04:59 PM, Arnd Bergmann wrote:
> > On Thursday 01 October 2015 18:46:34 kbuild test robot wrote:
> >> [auto build test results on v4.3-rc3 -- if it's inappropriate base, please 
> >> ignore]
> >>
> >> config: x86_64-allmodconfig (attached as .config)
> >> reproduce:
> >>  git checkout 6e153e3bf7c68b019e987c5a0ffadebd9c7d4fbb
> >>  # save the attached .config to linux build tree
> >>  make ARCH=x86_64
> >>
> >> All error/warnings (new ones prefixed by >>):
> >>
>  ERROR: "ufs_hba_exynos_ops" [drivers/scsi/ufs/ufshcd-pltfrm.ko] 
>  undefined!
> >>
> >>
> >
> > Ah, this seems to be a case of layering violation. It would be best to
> > restructure the code so that the exynos driver registers a platform_driver
> > by itself for the respective DT compatible string, and then calls
> > into the common code from its probe function, rather than having the
> > generic driver know about the specific backends.
> >
> > That approach will also make the generic driver more scalable as we
> > add further chip-specific variations, and matches what we do in other
> > drivers.
> >
> 
> Looks like some discussions on ufs variant driver probe method happened 
> here [1] few months back.
> [1]-> https://lkml.org/lkml/2015/6/3/180

Hmm, too bad we didn't catch it then, it's much more work to fix now.

> And since ufshcd-pltfrm is already a platform_driver, so I just add a 
> platform data for the variant driver.
> I should have add a IS_ENABLED for it to avoid the compilation error for 
> other ARCH.

I still think we should do this properly here. From looking at the qcom
driver, it seems to me that the integration there was done in a way that
could not work at all:

$ git grep -w ufs_hba_qcom_vops
drivers/scsi/ufs/ufs-qcom.c: * struct ufs_hba_qcom_vops - UFS QCOM specific 
variant operations
drivers/scsi/ufs/ufs-qcom.c:static const struct ufs_hba_variant_ops 
ufs_hba_qcom_vops = {
drivers/scsi/ufs/ufs-qcom.c:EXPORT_SYMBOL(ufs_hba_qcom_vops);

In short, nothing references the ufs_hba_qcom_vops symbol, so the driver
is never used, and if it did, it would not work for ufs being built-in
beause the symbol is marked 'static'.

Please do the samsung front-end as I suggested and send a patch to
convert the qcom front-end the same way. No need to test that one
as the current approach doesn't work.

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 2/3] hwrng: stm32 - add support for STM32 HW RNG

[Daniel Thompson]

On 4 October 2015 at 11:32, Linus Walleij  wrote:
> On Sat, Oct 3, 2015 at 10:35 PM, Daniel Thompson
>  wrote:
>
>> Add support for STMicroelectronics STM32 random number generator.
>>
>> The config value defaults to N, reflecting the fact that STM32 is a
>> very low resource microcontroller platform and unlikely to be targeted
>> by any "grown up" defconfigs.
>>
>> Signed-off-by: Daniel Thompson 
>
> Incidentally both you and Lee Jones submitted similar RNG drivers from
> the same company (ST) recent weeks:
>
> Lee's ST thing:
> http://marc.info/?l=linux-crypto-vger=144249760524971=2
>
> Daniel's ST thing:
> http://marc.info/?l=linux-crypto-vger=144390463810134=2
>
> And we also have from old ST:
> drivers/char/hw_random/nomadik-rng.c
>
> 1. Are these similar IPs that could be unified in a driver, just different
> offsets in memory?

I don't think so. I can't see any commonality of register structure or
data transfer approach (neither PIO nor DMA).

There have been exceptions but, in general, STM32 microcontrollers
seem to have very little in common with ST SoC/ASIC devices except for
the manufacturers id.


> 2. Could you at least cross-review each others drivers because both
> tight loops to read bytes seem to contain similar semantics.

I'll take a look although, as above, I suspect any similarities in
structure will be based on the problem domain rather than shared
heritage in the hardware design.


> 3. I took out the datasheet for Nomadik STn8820 and it seems that
> the hardware is very similar to what this driver is trying to drive.
> CR, SR and DR are in the same place, can you check if you also even
> have the PrimeCell magic in the words at offset 0xfe0 thru 0xffc?

The register window for the STM32 RNG is only 0x400 (and I'll fix the
DT for v2 ;-) ) so the STM32 version isn't primecell-like.


> In any case it seems likely that this driver should supercede and replace
> drivers/char/hw_random/nomadik-rng.c
> still using the PrimeCell bus, and if it doesn't have the PrimeCell
> IDs in hardware, this can be specified in the device tree using
> arm,primecell-periphid = <0x000805e1>; in the node if need be.
> The in-tree driver is dangerously simple and assume too much IMO.

Not sure about this, but I'll take a closer look. There is a certain
family resemblance in the register set but there are significant
differences in data transfer between the Nomadik and STM32 hardware.


>
> Now the rest:
>
>> +   /* enable random number generation */
>> +   clk_enable(priv->clk);
>> +   cr = readl(priv->base + RNG_CR);
>> +   writel(cr | RNG_CR_RNGEN, priv->base + RNG_CR);
>
> The Nomadik datasheet says this works the inverse way: setting
> bit 2 to 1 *disables* the RNG. Can you double-check this?

Nomadik driver doesn't seem to have to set anything to enable the RNG,
so assuming the CR is resets to zero on nomadik I guess the bit
meaning is inverted on the two platforms.


> The Nomadik version also has a TSTCLK bit 3, that should
> always be set and loop-back checked in SR bit 1 to see that the block
> is properly clocked. (Read data will hang on an AHB stall if it's
> unclocked) Is this missing from STM32?

Bit 3 is reserved on STM32. I don't think the STM32 has logic to hang
the bus if the cell doesn't have data ready (it's not mentioned in the
datasheet but I've not verified what happens if we read when things
are not ready).


>> + sr = readl(priv->base + RNG_SR);
>
> I strongly recommend that you use readl_relaxed() for this and
> all other reads on the hotpath, the Nomadik uses __raw_readl()
> but that is just for the same reasons that readl_relaxed() should
> be used: we just wanna read, not clean buffers etc.

I'll fix this. Choosing writel/readl was deliberate (STM32 is a niche
platform so I *really* wanted COMPILE_TEST to work) but this reasons
is no longer relevant.


>> + /* Has h/ware error dection been triggered? */
>> + if (WARN_ON(sr & (RNG_SR_SEIS | RNG_SR_CEIS)))
>> + break;
>> +
>> + /* No data ready... */
>> + if (!sr)
>> + break;
>
> This assumes that only bits 6,5 and 0 are ever used in this hardware.
> Are you sure? On Nomadik DRDY bit 0 is the same, bit 1
> is the clock test bit mentioned above, bit 2 is FAULT set if an invalid
> bit sequence is detected and should definately be checked if
> the HW supports it. Please mask explicitly for DRDY at least.

There are also bits 1 and 2 but these are non-sticky versions of bits
5 and 6 so it should work... but I agree its not very conservative.

I plan to combine both branches into a simple "if (sr != RNG_SR_DRDY)"
since any other value indicates an error condition that we should warn
about anyway.

> The bit layout gives at hand that this is indeed a derived IP block,
> I wonder what bits 3 & 4 may be used for in some or all
> revisions?
>
> Then this construct:
>
>> +static int stm32_rng_read(struct hwrng *rng, void *data, size_t 

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

[Lee Jones]

On Thu, 01 Oct 2015, Andrew F. Davis wrote:

> This patch adds support for TPS65912 mfd device. It provides
> communication through the I2C and SPI interfaces. It contains
> the following components:
> 
>  - Regulators
>  - GPIO controller
> 
> Signed-off-by: Andrew F. Davis 
> ---
>  drivers/mfd/Kconfig  |  25 
>  drivers/mfd/Makefile |   3 +
>  drivers/mfd/tps65912-core.c  | 108 ++
>  drivers/mfd/tps65912-i2c.c   |  82 ++
>  drivers/mfd/tps65912-spi.c   |  81 ++
>  include/linux/mfd/tps65912.h | 345 
> +++
>  6 files changed, 644 insertions(+)
>  create mode 100644 drivers/mfd/tps65912-core.c
>  create mode 100644 drivers/mfd/tps65912-i2c.c
>  create mode 100644 drivers/mfd/tps65912-spi.c
>  create mode 100644 include/linux/mfd/tps65912.h

Applied, thanks.

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

Re: [PATCH 2/3] hwrng: stm32 - add support for STM32 HW RNG

[Daniel Thompson]

On 4 October 2015 at 09:52, Maxime Coquelin  wrote:
> Hi Daniel,
>
> On 10/03/2015 10:35 PM, Daniel Thompson wrote:
>>
>> Add support for STMicroelectronics STM32 random number generator.
>>
>> The config value defaults to N, reflecting the fact that STM32 is a
>> very low resource microcontroller platform and unlikely to be targeted
>> by any "grown up" defconfigs.
>>
>> Signed-off-by: Daniel Thompson 
>> ---
>>   drivers/char/hw_random/Kconfig |  12 +++
>>   drivers/char/hw_random/Makefile|   1 +
>>   drivers/char/hw_random/stm32-rng.c | 192
>> +
>>   3 files changed, 205 insertions(+)
>>   create mode 100644 drivers/char/hw_random/stm32-rng.c
>
> 
>>
>> diff --git a/drivers/char/hw_random/stm32-rng.c
>> b/drivers/char/hw_random/stm32-rng.c
>> new file mode 100644
>> index ..37dfa5fca105
>> --- /dev/null
>> +++ b/drivers/char/hw_random/stm32-rng.c
>> @@ -0,0 +1,192 @@
>
> 
>
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define RNG_CR 0x00
>> +#define RNG_CR_RNGEN BIT(2)
>> +
>> +#define RNG_SR 0x04
>> +#define RNG_SR_SEIS BIT(6)
>> +#define RNG_SR_CEIS BIT(5)
>> +#define RNG_SR_DRDY BIT(0)
>> +
>> +#define RNG_DR 0x08
>> +
>> +/*
>> + * It takes 40 cycles @ 48MHz to generate each random number (e.g. <1us).
>> + * At the time of writing STM32 parts max out at ~200MHz meaning a
>> timeout
>> + * of 500 leaves us a very comfortable margin for error. The loop to
>> which
>> + * the timeout applies takes at least 4 instructions per cycle so the
>> + * timeout is enough to take us up to multi-GHz parts!
>> + */
>> +#define RNG_TIMEOUT 500
>> +
>> +struct stm32_rng_private {
>> +   struct hwrng rng;
>> +   void __iomem *base;
>> +   struct clk *clk;
>> +};
>> +
>> +static int stm32_rng_read(struct hwrng *rng, void *data, size_t max, bool
>> wait)
>> +{
>> +   struct stm32_rng_private *priv =
>> +   container_of(rng, struct stm32_rng_private, rng);
>> +   u32 cr, sr;
>> +   int retval = 0;
>> +
>> +   /* enable random number generation */
>> +   clk_enable(priv->clk);
>> +   cr = readl(priv->base + RNG_CR);
>> +   writel(cr | RNG_CR_RNGEN, priv->base + RNG_CR);
>> +
>> +   while (max > sizeof(u32)) {
>> +   sr = readl(priv->base + RNG_SR);
>> +   if (!sr && wait) {
>> +   unsigned int timeout = RNG_TIMEOUT;
>> +
>> +   do {
>> +   cpu_relax();
>> +   sr = readl(priv->base + RNG_SR);
>> +   } while (!sr && --timeout);
>> +   }
>> +
>> +   /* Has h/ware error dection been triggered? */
>> +   if (WARN_ON(sr & (RNG_SR_SEIS | RNG_SR_CEIS)))
>
> Maybe you should instead use WARN_ONCE?
> Because from what I understand in the datasheet, CEIS bit indicates and
> error with clock configuration.
> If that happens, it is likely the same error will occur each time this
> function will be called.

Ok.


>> +   break;
>> +
>> +   /* No data ready... */
>> +   if (!sr)
>> +   break;
>
> Maybe you could perform this check before the error detection, as if !sr,
> the HW error condition will be always false.

I plan to combine both checks since timing out is still a serious
error even if the h/ware didn't detect it.

>>
>> +
>> +   *(u32 *)data = readl(priv->base + RNG_DR);
>> +
>> +   retval += sizeof(u32);
>> +   data += sizeof(u32);
>> +   max -= sizeof(u32);
>> +   }
>> +
>> +   /* disable the generator */
>> +   writel(cr, priv->base + RNG_CR);
>> +   clk_disable(priv->clk);
>> +
>> +   return retval || !wait ? retval : -EIO;
>> +}
>
>
> Couldn't we use "_relaxed" versions of readl/writel?
> I might save some not needed barriers.

Will fix. I had a "historic" reason to avoid _relaxed but this is no
longer relevant.


>> +static int stm32_rng_probe(struct platform_device *ofdev)
>> +{
>> +   struct device *dev = >dev;
>> +   struct device_node *np = ofdev->dev.of_node;
>> +   struct stm32_rng_private *priv;
>> +   struct resource res;
>> +   int err;
>> +
>> +   priv = devm_kzalloc(dev, sizeof(struct stm32_rng_private),
>> GFP_KERNEL);
>> +   if (!priv)
>> +   return -ENOMEM;
>> +
>> +   err = of_address_to_resource(np, 0, );
>> +   if (err)
>> +   return err;
>> +
>> +   priv->base = devm_ioremap_resource(dev, );
>> +   if (IS_ERR(priv->base))
>> +   return PTR_ERR(priv->base);
>> +
>> +   priv->clk = devm_clk_get(>dev, NULL);
>> +   if (IS_ERR(priv->clk))
>> +   return PTR_ERR(priv->clk);
>> +
>> +   dev_set_drvdata(dev, priv);
>> +
>> +   priv->rng.name = 

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

[Lee Jones]

On Mon, 05 Oct 2015, Lee Jones wrote:

> On Thu, 01 Oct 2015, Andrew F. Davis wrote:
> 
> > This patch adds support for TPS65912 mfd device. It provides
> > communication through the I2C and SPI interfaces. It contains
> > the following components:
> > 
> >  - Regulators
> >  - GPIO controller
> > 
> > Signed-off-by: Andrew F. Davis 
> > ---
> >  drivers/mfd/Kconfig  |  25 
> >  drivers/mfd/Makefile |   3 +
> >  drivers/mfd/tps65912-core.c  | 108 ++
> >  drivers/mfd/tps65912-i2c.c   |  82 ++
> >  drivers/mfd/tps65912-spi.c   |  81 ++
> >  include/linux/mfd/tps65912.h | 345 
> > +++
> >  6 files changed, 644 insertions(+)
> >  create mode 100644 drivers/mfd/tps65912-core.c
> >  create mode 100644 drivers/mfd/tps65912-i2c.c
> >  create mode 100644 drivers/mfd/tps65912-spi.c
> >  create mode 100644 include/linux/mfd/tps65912.h
> 
> Applied, thanks.

Whoops, I forgot about the removal patch.

For this patch:
  Acked-by: Lee Jones 

Can you break up the removal patch into subsystems as well?

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

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

[Lee Jones]

On Thu, 01 Oct 2015, Andrew F. Davis wrote:

> The old tps65912 driver is being replaced, delete old driver.
> 
> Signed-off-by: Andrew F. Davis 

I already Acked this in v3.

Acked-by: Lee Jones 

> ---
>  drivers/gpio/Kconfig   |   6 -
>  drivers/gpio/Makefile  |   1 -
>  drivers/gpio/gpio-tps65912.c   | 153 --
>  drivers/mfd/Kconfig|  26 --
>  drivers/mfd/Makefile   |   4 -
>  drivers/mfd/tps65912-core.c| 175 ---
>  drivers/mfd/tps65912-i2c.c | 139 -
>  drivers/mfd/tps65912-irq.c | 217 -
>  drivers/mfd/tps65912-spi.c | 141 -
>  drivers/regulator/Kconfig  |   6 -
>  drivers/regulator/Makefile |   1 -
>  drivers/regulator/tps65912-regulator.c | 541 
> -
>  include/linux/mfd/tps65912.h   | 328 
>  13 files changed, 1738 deletions(-)
>  delete mode 100644 drivers/gpio/gpio-tps65912.c
>  delete mode 100644 drivers/mfd/tps65912-core.c
>  delete mode 100644 drivers/mfd/tps65912-i2c.c
>  delete mode 100644 drivers/mfd/tps65912-irq.c
>  delete mode 100644 drivers/mfd/tps65912-spi.c
>  delete mode 100644 drivers/regulator/tps65912-regulator.c
>  delete mode 100644 include/linux/mfd/tps65912.h
> 
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index b4fc9e4..fb28483 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -838,12 +838,6 @@ config GPIO_TPS65910
> Select this option to enable GPIO driver for the TPS65910
> chip family.
>  
> -config GPIO_TPS65912
> - tristate "TI TPS65912 GPIO"
> - depends on (MFD_TPS65912_I2C || MFD_TPS65912_SPI)
> - help
> -   This driver supports TPS65912 gpio chip
> -
>  config GPIO_TWL4030
>   tristate "TWL4030, TWL5030, and TPS659x0 GPIOs"
>   depends on TWL4030_CORE
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index f79a7c4..605bf89 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -96,7 +96,6 @@ obj-$(CONFIG_GPIO_TIMBERDALE)   += gpio-timberdale.o
>  obj-$(CONFIG_GPIO_PALMAS)+= gpio-palmas.o
>  obj-$(CONFIG_GPIO_TPS6586X)  += gpio-tps6586x.o
>  obj-$(CONFIG_GPIO_TPS65910)  += gpio-tps65910.o
> -obj-$(CONFIG_GPIO_TPS65912)  += gpio-tps65912.o
>  obj-$(CONFIG_GPIO_TS5500)+= gpio-ts5500.o
>  obj-$(CONFIG_GPIO_TWL4030)   += gpio-twl4030.o
>  obj-$(CONFIG_GPIO_TWL6040)   += gpio-twl6040.o
> diff --git a/drivers/gpio/gpio-tps65912.c b/drivers/gpio/gpio-tps65912.c
> deleted file mode 100644
> index 9cdbc0c..000
> --- a/drivers/gpio/gpio-tps65912.c
> +++ /dev/null
> @@ -1,153 +0,0 @@
> -/*
> - * Copyright 2011 Texas Instruments Inc.
> - *
> - * Author: Margarita Olaya 
> - *
> - *  This program is free software; you can redistribute it and/or modify it
> - *  under  the terms of the GNU General  Public License as published by the
> - *  Free Software Foundation;  either version 2 of the License, or (at your
> - *  option) any later version.
> - *
> - * This driver is based on wm8350 implementation.
> - */
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -struct tps65912_gpio_data {
> - struct tps65912 *tps65912;
> - struct gpio_chip gpio_chip;
> -};
> -
> -#define to_tgd(gc) container_of(gc, struct tps65912_gpio_data, gpio_chip)
> -
> -static int tps65912_gpio_get(struct gpio_chip *gc, unsigned offset)
> -{
> - struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
> - struct tps65912 *tps65912 = tps65912_gpio->tps65912;
> - int val;
> -
> - val = tps65912_reg_read(tps65912, TPS65912_GPIO1 + offset);
> -
> - if (val & GPIO_STS_MASK)
> - return 1;
> -
> - return 0;
> -}
> -
> -static void tps65912_gpio_set(struct gpio_chip *gc, unsigned offset,
> -   int value)
> -{
> - struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
> - struct tps65912 *tps65912 = tps65912_gpio->tps65912;
> -
> - if (value)
> - tps65912_set_bits(tps65912, TPS65912_GPIO1 + offset,
> - GPIO_SET_MASK);
> - else
> - tps65912_clear_bits(tps65912, TPS65912_GPIO1 + offset,
> - GPIO_SET_MASK);
> -}
> -
> -static int tps65912_gpio_output(struct gpio_chip *gc, unsigned offset,
> - int value)
> -{
> - struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
> - struct tps65912 *tps65912 = tps65912_gpio->tps65912;
> -
> - /* Set the initial value */
> - tps65912_gpio_set(gc, offset, value);
> -
> - return tps65912_set_bits(tps65912, TPS65912_GPIO1 + offset,
> - GPIO_CFG_MASK);
> -}
> -
> -static int 

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

[Lee Jones]

On Mon, 05 Oct 2015, Lee Jones wrote:

> On Thu, 01 Oct 2015, Andrew F. Davis wrote:
> 
> > The old tps65912 driver is being replaced, delete old driver.
> > 
> > Signed-off-by: Andrew F. Davis 
> 
> I already Acked this in v3.
> 
> Acked-by: Lee Jones 

Ack can carry, but is there any chance this can be split up for easy
digestion into the respective trees?

> > ---
> >  drivers/gpio/Kconfig   |   6 -
> >  drivers/gpio/Makefile  |   1 -
> >  drivers/gpio/gpio-tps65912.c   | 153 --
> >  drivers/mfd/Kconfig|  26 --
> >  drivers/mfd/Makefile   |   4 -
> >  drivers/mfd/tps65912-core.c| 175 ---
> >  drivers/mfd/tps65912-i2c.c | 139 -
> >  drivers/mfd/tps65912-irq.c | 217 -
> >  drivers/mfd/tps65912-spi.c | 141 -
> >  drivers/regulator/Kconfig  |   6 -
> >  drivers/regulator/Makefile |   1 -
> >  drivers/regulator/tps65912-regulator.c | 541 
> > -
> >  include/linux/mfd/tps65912.h   | 328 
> >  13 files changed, 1738 deletions(-)
> >  delete mode 100644 drivers/gpio/gpio-tps65912.c
> >  delete mode 100644 drivers/mfd/tps65912-core.c
> >  delete mode 100644 drivers/mfd/tps65912-i2c.c
> >  delete mode 100644 drivers/mfd/tps65912-irq.c
> >  delete mode 100644 drivers/mfd/tps65912-spi.c
> >  delete mode 100644 drivers/regulator/tps65912-regulator.c
> >  delete mode 100644 include/linux/mfd/tps65912.h
> > 
> > diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> > index b4fc9e4..fb28483 100644
> > --- a/drivers/gpio/Kconfig
> > +++ b/drivers/gpio/Kconfig
> > @@ -838,12 +838,6 @@ config GPIO_TPS65910
> >   Select this option to enable GPIO driver for the TPS65910
> >   chip family.
> >  
> > -config GPIO_TPS65912
> > -   tristate "TI TPS65912 GPIO"
> > -   depends on (MFD_TPS65912_I2C || MFD_TPS65912_SPI)
> > -   help
> > - This driver supports TPS65912 gpio chip
> > -
> >  config GPIO_TWL4030
> > tristate "TWL4030, TWL5030, and TPS659x0 GPIOs"
> > depends on TWL4030_CORE
> > diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> > index f79a7c4..605bf89 100644
> > --- a/drivers/gpio/Makefile
> > +++ b/drivers/gpio/Makefile
> > @@ -96,7 +96,6 @@ obj-$(CONFIG_GPIO_TIMBERDALE) += gpio-timberdale.o
> >  obj-$(CONFIG_GPIO_PALMAS)  += gpio-palmas.o
> >  obj-$(CONFIG_GPIO_TPS6586X)+= gpio-tps6586x.o
> >  obj-$(CONFIG_GPIO_TPS65910)+= gpio-tps65910.o
> > -obj-$(CONFIG_GPIO_TPS65912)+= gpio-tps65912.o
> >  obj-$(CONFIG_GPIO_TS5500)  += gpio-ts5500.o
> >  obj-$(CONFIG_GPIO_TWL4030) += gpio-twl4030.o
> >  obj-$(CONFIG_GPIO_TWL6040) += gpio-twl6040.o
> > diff --git a/drivers/gpio/gpio-tps65912.c b/drivers/gpio/gpio-tps65912.c
> > deleted file mode 100644
> > index 9cdbc0c..000
> > --- a/drivers/gpio/gpio-tps65912.c
> > +++ /dev/null
> > @@ -1,153 +0,0 @@
> > -/*
> > - * Copyright 2011 Texas Instruments Inc.
> > - *
> > - * Author: Margarita Olaya 
> > - *
> > - *  This program is free software; you can redistribute it and/or modify it
> > - *  under  the terms of the GNU General  Public License as published by the
> > - *  Free Software Foundation;  either version 2 of the License, or (at your
> > - *  option) any later version.
> > - *
> > - * This driver is based on wm8350 implementation.
> > - */
> > -
> > -#include 
> > -#include 
> > -#include 
> > -#include 
> > -#include 
> > -#include 
> > -#include 
> > -#include 
> > -#include 
> > -
> > -struct tps65912_gpio_data {
> > -   struct tps65912 *tps65912;
> > -   struct gpio_chip gpio_chip;
> > -};
> > -
> > -#define to_tgd(gc) container_of(gc, struct tps65912_gpio_data, gpio_chip)
> > -
> > -static int tps65912_gpio_get(struct gpio_chip *gc, unsigned offset)
> > -{
> > -   struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
> > -   struct tps65912 *tps65912 = tps65912_gpio->tps65912;
> > -   int val;
> > -
> > -   val = tps65912_reg_read(tps65912, TPS65912_GPIO1 + offset);
> > -
> > -   if (val & GPIO_STS_MASK)
> > -   return 1;
> > -
> > -   return 0;
> > -}
> > -
> > -static void tps65912_gpio_set(struct gpio_chip *gc, unsigned offset,
> > - int value)
> > -{
> > -   struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
> > -   struct tps65912 *tps65912 = tps65912_gpio->tps65912;
> > -
> > -   if (value)
> > -   tps65912_set_bits(tps65912, TPS65912_GPIO1 + offset,
> > -   GPIO_SET_MASK);
> > -   else
> > -   tps65912_clear_bits(tps65912, TPS65912_GPIO1 + offset,
> > -   GPIO_SET_MASK);
> > -}
> > -
> > -static int tps65912_gpio_output(struct gpio_chip *gc, unsigned offset,
> > -   int value)
> > -{
> > -   struct 

Re: [PATCH] ARM: shmobile: porter: add Ether DT support

[Simon Horman]

On Tue, Oct 06, 2015 at 01:51:01AM +0300, Sergei Shtylyov wrote:
> Define  the Porter board dependent part of  the Ether device node.
> Enable DHCP and NFS root for the kernel booting.
> 
> This  patch  is analogous to the commit 26b0d2cf73cb (ARM: shmobile: 
> henninger:
> add Ether DT support)  as there  are no differences between those boards in 
> this
> respect.
> 
> Signed-off-by: Sergei Shtylyov 
> 
> ---

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

Re: [PATCH v2 3/4] ARM: dts: DRA7: Add timer12 node

[Felipe Balbi]

Suman Anna  writes:

> Add the DT node for Timer12 present on DRA7 family of
> SoCs. Timer12 is present in PD_WKUPAON power domain, and
> has the same capabilities as the other timers, except for
> the fact that it serves as a secure timer on HS devices
> and is clocked only from the secure 32K clock.
>
> The node is marked disabled for now, and the kernel should
> refrain from using this secure timer on HS devices.
>
> Signed-off-by: Suman Anna 
> ---
>  arch/arm/boot/dts/dra7.dtsi | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index e289c706d27d..37d632dad576 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -762,6 +762,16 @@
>   ti,hwmods = "timer11";
>   };
>  
> + timer12: timer@4ae2 {
> + compatible = "ti,omap5430-timer";
> + reg = <0x4ae2 0x80>;
> + interrupts = ;
> + ti,hwmods = "timer12";
> + ti,timer-alwon;
> + ti,timer-secure;
> + status = "disabled";

according to Tony we should avoid using status at all for in-SoC
devices.

Tony, can you confirm I understood you correctly ?

-- 
balbi


signature.asc
Description: PGP signature

Re: How to parse delete-property annotations

[Stefan Monnier]

>> Could someone point me to some documentation explaining/describing
>> this syntax?
[...]
> The best documentation that I know of for this is the lexer
> source at:

Thanks,


Stefan
--
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] soc: mediatek: Fix random hang up issue while kernel init

[Daniel Kurtz]

On Fri, Sep 25, 2015 at 2:31 PM, James Liao  wrote:
> In kernel late init, it turns off all unused clocks, which
> needs to access subsystem registers such as VENC and VENC_LT.
>
> Accessing MT8173 VENC registers needs two top clocks, mm_sel and
> venc_sel. Accessing VENC_LT registers needs mm_sel and venclt_sel.
> So we need to keep these clocks on before accessing their registers.
>
> This patch keeps venc_sel / venclt_sel clock on when
> VENC / VENC_LT's power is on, to prevent system hang up while
> accessing its registeres.
>
> Signed-off-by: James Liao 

After the discussions with James here on the list, I'm happy with this fix.
Compared to any proposed alternative, this patch seems just as
effective and is also simpler and more maintainable and extensible (if
other clocks/power domains need the same treatment).

Reviewed-by: Daniel Kurtz 
--
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/3] powerpc/512x: add LocalPlus Bus FIFO device driver

[Alexander Popov]

On 01.10.2015 20:11, Timur Tabi wrote:
> On 09/30/2015 04:24 PM, Alexander Popov wrote:
>>> Driver code that has to parse #address-cells or #size-cells
>>> is usually wrong.
>>
>> I would not call it "parsing", I just check whether the dts-file is good.
>> Anyway, could you give me a clue how to do better?
> 
> You should use of_n_size_cells() and of_n_addr_cells().

It seems that of_n_size_cells() and of_n_addr_cells() don't work well in
my case. These functions just help to get "#address-cells" and "#size-cells"
from a parent node of a given node.

"sclpc" device tree node is a child of "soc" node (not "localbus" node),
but the driver must use "ranges" property of "localbus" to determine
the chip select number of a client device which ordered the DMA transfer.

It seems that ns2_leds_get_of_pdata() from linux/drivers/leds/leds-ns2.c
or pnv_init_idle_states() from arch/powerpc/platforms/powernv/idle.c do
something similar to get_cs_ranges().
Is it OK?

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

[PATCH 2/2] dt: update Tegra PCIe binding for Tegra210

[Stephen Warren]

From: Stephen Warren 

Reword the description of the ranges property so it is correct
irrespective of how many #address-cells the PCI node's parent uses.

Be more explicit about the valid values for the compatible property, and
in particular point out that Tegra210 isn't fully backwards-compatible due
to the introduction of some HW bugs whose workarounds are not present in
drivers written solely for previous chips. with Tegra124,

Still "TODO" is to fill in a complete "Power supplies for Tegra210"
section. My main use-case for the binding is U-Boot, which doesn't use
regulator bindings at present, so I have not yet researched this aspect
of the hardware.

Signed-off-by: Stephen Warren 
---
 .../bindings/pci/nvidia,tegra20-pcie.txt   | 27 +++---
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt 
b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
index 75321ae23c08..3d92934a079c 100644
--- a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
@@ -1,10 +1,15 @@
 NVIDIA Tegra PCIe controller
 
 Required properties:
-- compatible: For Tegra20, must contain "nvidia,tegra20-pcie".  For Tegra30,
-  "nvidia,tegra30-pcie".  For Tegra124, must contain "nvidia,tegra124-pcie".
-  Otherwise, must contain "nvidia,-pcie", plus one of the above, where
-   is tegra132 or tegra210.
+- compatible: Valid options are:
+  Tegra20: "nvidia,tegra20-pcie".
+  Tegra30: "nvidia,tegra30-pcie".
+  Tegra124: "nvidia,tegra124-pcie".
+  Tegra132: "nvidia,tegra132-pcie", "nvidia,tegra124-pcie".
+  Tegra210: "nvidia,tegra210-pcie".
+Note that Tegra210 is not backwards-compatible with Tegra124 due to the
+introduction of some HW bugs whose workarounds are not present in drivers
+written solely for previous chips.
 - device_type: Must be "pci"
 - reg: A list of physical base address and length for each set of controller
   registers. Must contain an entry for each entry in the reg-names property.
@@ -27,10 +32,16 @@ Required properties:
 CPU address space
 - #size-cells: Size representation for root ports (must be 2)
 - ranges: Describes the translation of addresses for root ports and standard
-  PCI regions. The entries must be 6 cells each, where the first three cells
-  correspond to the address as described for the #address-cells property
-  above, the fourth cell is the physical CPU address to translate to and the
-  fifth and six cells are as described for the #size-cells property above.
+  PCI regions. The entries must be (na_pcie + na_parent + ns_pcie) cells each,
+  where:
+na_pcie refers to #address-cells in the PCIe controller,
+na_parent refers to #address-cells in the PCIe controller's parent node,
+ns_pcie refers to #size-cells in the PCIe controller,
+  The first na_pcie cells correspond to the address as described for the
+  #address-cells property. The next na_parent cells contain the physical CPU
+  address to translate to and the final ns_pcie cells are as described for the
+  #size-cells property above.
+  Multiple entries must be present:
   - The first two entries are expected to translate the addresses for the root
 port registers, which are referenced by the assigned-addresses property of
 the root port nodes (see below).
-- 
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 1/2] dt: update Tegra XUSB padctl binding for Tegra210

[Stephen Warren]

From: Stephen Warren 

Tegra210 introduces some new options for pad muxing. Document these in
the XUSB padctl binding.

Be more explicit about the valid values for the compatible property, and
in particular point out that Tegra210 isn't fully backwards-compatible
with Tegra124, since some registers have moved about.

Signed-off-by: Stephen Warren 
---
 .../pinctrl/nvidia,tegra124-xusb-padctl.txt| 34 +++---
 1 file changed, 24 insertions(+), 10 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt 
b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt
index 30676ded85bb..3952d893635c 100644
--- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-xusb-padctl.txt
@@ -13,9 +13,12 @@ how to describe and reference PHYs in device trees.
 
 Required properties:
 
-- compatible: For Tegra124, must contain "nvidia,tegra124-xusb-padctl".
-  Otherwise, must contain '"nvidia,-xusb-padctl",
-  "nvidia-tegra124-xusb-padctl"', where  is tegra132 or tegra210.
+- compatible: Valid options are:
+  Tegra124: "nvidia,tegra124-xusb-padctl".
+  Tegra132: "nvidia,tegra132-xusb-padctl", "nvidia-tegra124-xusb-padctl".
+  Tegra210: "nvidia-tegra210-xusb-padctl".
+Note that Tegra210 is not backwards-compatible with Tegra124 due to some
+registers having been moved.
 - reg: Physical base address and length of the controller's registers.
 - resets: Must contain an entry for each entry in reset-names.
   See ../reset/reset.txt for details.
@@ -45,18 +48,21 @@ Unspecified is represented as an absent property, and 
off/on are represented
 as integer values 0 and 1.
 
 Required properties:
-- nvidia,lanes: An array of strings. Each string is the name of a lane.
+- nvidia,lanes: An array of strings. Each string is the name of a lane (pad).
+  Valid values for lanes are listed below.
 
 Optional properties:
-- nvidia,function: A string that is the name of the function (pad) that the
-  pin or group should be assigned to. Valid values for function names are
-  listed below.
+- nvidia,function: A string that is the name of the function (IO controller)
+  that the pin or group should be assigned to. Valid values for function names
+  are  listed below.
 - nvidia,iddq: Enables IDDQ mode of the lane. (0: no, 1: yes)
 
 Note that not all of these properties are valid for all lanes. Lanes can be
 divided into three groups:
 
-  - otg-0, otg-1, otg-2:
+  - otg-0, otg-1, otg-2, otg-3, usb2-bias:
+
+(otg-3, usb2-bias are valid on Tegra210 only.)
 
 Valid functions for this group are: "snps", "xusb", "uart", "rsvd".
 
@@ -64,13 +70,21 @@ divided into three groups:
 
   - ulpi-0, hsic-0, hsic-1:
 
+(ulpi-0 is valid on Tegra124 and Tegra132 only.)
+
 Valid functions for this group are: "snps", "xusb".
 
 The nvidia,iddq property does not apply to this group.
 
-  - pcie-0, pcie-1, pcie-2, pcie-3, pcie-4, sata-0:
+  - pcie-0, pcie-1, pcie-2, pcie-3, pcie-4, pcie-5, pcie-6, sata-0:
+
+(pcie-5, pcie-6 are valid on Tegra210 only.)
+
+On Tegra124, Tegra132, valid functions for this group are: "pcie", "usb3",
+"sata", "rsvd".
 
-Valid functions for this group are: "pcie", "usb3", "sata", "rsvd".
+On Tegra210, valid functions for this group are "pcie-x1", "usb3",
+"sata", "pcie-x4".
 
 
 Example:
-- 
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 3/3] mfd: sec-core: Disable buck voltage reset on watchdog falling edge

[Krzysztof Kozlowski]

On 05.10.2015 22:35, Bartlomiej Zolnierkiewicz wrote:
> 
> Hi,
> 
> On Friday, October 02, 2015 05:25:51 PM Krzysztof Kozlowski wrote:
>> The WRSTBI bit (disabled by default but enabled by bootloader), when
>> set, is responsible for resetting voltages to default values of
>> certain bucks on falling edge of Warm Reset Input pin from AP.
>>
>> However on some boards (with S2MPS13) the pin is pulled down so any
>> suspend will effectively trigger the reset of bucks supplying the power
>> to the little and big cores. In the same time when resuming, these bucks
>> must provide voltage greater or equal to voltage before suspend to match
>> the frequency chosen by cpufreq. If voltage (default value of voltage
>> after reset) is lower than one set by cpufreq before suspend, then
>> system will hang during resuming.
>>
>> Signed-off-by: Krzysztof Kozlowski 
> 
> I tested this (with some additional Exynos5433 patches) and it works
> like expected (suspend/resume issue is fixed).
> 
> Tested-by: Bartlomiej Zolnierkiewicz 
> 

Thanks!

> You could also add:
> 
> Reported-by: Bartlomiej Zolnierkiewicz 
> 
> (since the issue got narrowed down and reported to you by me :).

I didn't put it because I wasn't sure who was the author of our report.
I'll wait a one more day for any comments and add it in v2/resend.

BTW, any comments on the binding itself?
Actually I had hard time choosing the name for binding because unlike
the ACOKB the WRSTBI pin is not grounded but pulled down. However it is
quite similar so I stick to the same convention:
 - samsung,s2mps11-acokb-ground
 - samsung,s2mps11-wrstbi-ground


Best regards,
Krzysztof
--
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 21/22] driver core: Start processing deferred probes earlier

[Frank Rowand]

On 9/21/2015 7:03 AM, Tomeu Vizoso wrote:
> Some initcalls in the late level assume that some devices will have
> already probed without explicitly checking for that.
> 
> After the recent move to defer most device probes when they are
> registered, pressure increased in the late initcall level.
> 
> By starting the processing of the deferred queue in device_initcall_sync
> we increase the chances that the initcalls mentioned before will find
> the devices they depend on to have already probed.
> 
> Signed-off-by: Tomeu Vizoso 
> ---
> 
> Changes in v4:
> - Start processing deferred probes in device_initcall_sync
> 
>  drivers/base/dd.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index 269ea76c1a4f..f0ef9233fcd6 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -176,7 +176,7 @@ static void driver_deferred_probe_trigger(void)
>   *
>   * We don't want to get in the way when the bulk of drivers are getting 
> probed.
>   * Instead, this initcall makes sure that deferred probing is delayed until
> - * late_initcall time.
> + * device_initcall_sync time.

This is a misuse of the *_sync initcall level.

If a deferred probe created a thread and expected a wait at the
following *_sync level then the wait would not occur because
there is no subsequent *_sync level.  This is not a problem today
because (as far as I know) there are no threads in the probe
functions.  But there has been interest in adding parallel
probing and that could expose this problem.

The purpose of the *_sync initcall levels is to allow the corresponding
initcall level to use multiple threads of execution instead of a single
thread.  The *_sync level provides a location for a wait for all of the
threads at the corresponding init level to complete.  This is better
explained in the git log:

commit 735a7ffb739b6efeaeb1e720306ba308eaaeb20e
Author: Andrew Morton 
Date:   Fri Oct 27 11:42:37 2006 -0700

[PATCH] drivers: wait for threaded probes between initcall levels

The multithreaded-probing code has a problem: after one initcall level (eg,
core_initcall) has been processed, we will then start processing the next
level (postcore_initcall) while the kernel threads which are handling
core_initcall are still executing.  This breaks the guarantees which the
layered initcalls previously gave us.

IOW, we want to be multithreaded _within_ an initcall level, but not between
different levels.

Fix that up by causing the probing code to wait for all outstanding probes 
at
one level to complete before we start processing the next level.

>   */
>  static int deferred_probe_initcall(void)
>  {
> @@ -190,7 +190,7 @@ static int deferred_probe_initcall(void)
>   flush_workqueue(deferred_wq);
>   return 0;
>  }
> -late_initcall(deferred_probe_initcall);
> +device_initcall_sync(deferred_probe_initcall);
>  
>  static void driver_bound(struct device *dev)
>  {
> 

--
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: How to parse delete-property annotations

[Frank Rowand]

On 9/29/2015 5:54 AM, Stefan Monnier wrote:
> [ In the context of Emacs's dts-mode (http://elpa.gnu.org/packages/dts-mode). 
> ]
> 
> I recently came across the following piece of DTS code:
> 
> {
> /* Unset otg detect pins as we force dr_mode */
> /delete-property/ usb0_id_det-gpio;
> /delete-property/ usb0_vbus_det-gpio;
>};
> 
> and was wondering how dts-mode should understand this.  `dts-mode'
> doesn't try to understand the actual *meaning* of such code, but it does
> try to understand the syntax (i.e. how the abstract-syntax-tree would
> look like).
> 
> Is "/delete-property/" is special syntax in itself, or is it a special
> case of a more general syntax (like "/.../ blabla;")?  Where exactly is
> it allowed to appear?
> Could someone point me to some documentation explaining/describing this 
> syntax?
> 
> 
> Stefan

The best documentation that I know of for this is the lexer
source at:

   https://git.kernel.org/cgit/utils/dtc/dtc.git/tree/dtc-lexer.l

The lexer detects tokens for "/delete-property/" and "/delete-node/"
at lines 128 - 140.

-Frank
--
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] ASoC: da7213: Add DT support to codec driver

[Opensource [Adam Thomson]]

On October 05, 2015 16:56, Mark Brown wrote:

> On Mon, Oct 05, 2015 at 04:40:18PM +0100, Adam Thomson wrote:
> 
> > This patch adds support for DT bindings in the codec driver.
> > As part of this support, the mclk data can now be provided and
> > used to control the mclk during codec operation.
> 
> Please split out the new MCLK configuration into a separate patch which
> describes what that configuration is, it's much easier to review that
> way.  Otherwise there's a couple of minor issues here but nothing too
> critical.

Ok, no problem. Will do.

> 
> > case SND_SOC_BIAS_STANDBY:
> > if (snd_soc_codec_get_bias_level(codec) == SND_SOC_BIAS_OFF) {
> > +   /* MCLK */
> > +   clk_prepare_enable(da7213->mclk);
> > +
> 
> This doesn't check the return value.

Yep, will update.

> 
> > .driver = {
> > .name = "da7213",
> > +   .of_match_table = da7213_of_match,
> 
> Please use of_match_ptr() here.

Ok, didn't know about that. Will update.

Re: [PATCH RESEND] ARM: dts: Fix Makefile target for sun4i-a10-itead-iteaduino-plus

[Ben Hutchings]

On Sun, 2015-09-06 at 13:20 +0200, Maxime Ripard wrote:
> On Fri, Sep 04, 2015 at 08:49:34AM -0400, Josh Boyer wrote:
> > Commit 79ae3e66f8d (ARM: dts: sun4i: Add Iteaduino Plus A10) added a new
> > make target for the sun4i-a10-itead-iteaduino-plus dts file, but mistakenly
> > used .dts instead of the correct .dtb suffix.  This resulted in a build 
> > error
> > like:
> > 
> > scripts/Makefile.dtbinst:42: target 
> > 'sun4i-a10-itead-iteaduino-plus.dts' doesn't match the target pattern
> > 
> > when doing a make dtbs_install.
> > 
> > Fix it to use the proper file name.
> > 
> > Signed-off-by: Josh Boyer 
> 
> Queued, thanks!

This still isn't in Linus's tree; please make sure it gets to him
before 4.3.

Ben.

-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source

signature.asc
Description: This is a digitally signed message part

[PATCH v2 0/4] DRA7 Timer12 Support

[Suman Anna]

Hi Tony,

This is a revised version of the DRA7 Timer12 support patch series [1].
The series mainly is respun to fix a build issue caused by Patch1 [2]
with omap1_defconfig due to the absence of Common Clock framework for
OMAP1.

Only Patch 1 is modified from the previous series. I have also revised
the check slightly to fix another issue seen when requesting Timer12
on OMAP3, as that is a fixed clock and does return back with a parent
count of 1.

Series baselined on v4.3-rc3 just like the original series, and tested
on all generations (AMx3x, OMAP4, OMAP5 and DRA7) except OMAP1 and OMAP2
generations. 

regards
Suman

[1] http://marc.info/?l=linux-omap=144372799601354=2
[2] https://patchwork.kernel.org/patch/7311021/

Suman Anna (4):
  ARM: OMAP: dmtimer: check for fixed timers during config
  ARM: OMAP2+: timer: Remove secure timer for DRA7xx HS devices
  ARM: dts: DRA7: Add timer12 node
  ARM: DRA7: hwmod: Add data for GPTimer 12

 arch/arm/boot/dts/dra7.dtsi   | 10 +
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 36 +--
 arch/arm/mach-omap2/timer.c   |  6 +++---
 arch/arm/plat-omap/dmtimer.c  |  7 ++
 4 files changed, 54 insertions(+), 5 deletions(-)

-- 
2.6.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 v2 3/4] ARM: dts: DRA7: Add timer12 node

[Suman Anna]

Add the DT node for Timer12 present on DRA7 family of
SoCs. Timer12 is present in PD_WKUPAON power domain, and
has the same capabilities as the other timers, except for
the fact that it serves as a secure timer on HS devices
and is clocked only from the secure 32K clock.

The node is marked disabled for now, and the kernel should
refrain from using this secure timer on HS devices.

Signed-off-by: Suman Anna 
---
 arch/arm/boot/dts/dra7.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index e289c706d27d..37d632dad576 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -762,6 +762,16 @@
ti,hwmods = "timer11";
};
 
+   timer12: timer@4ae2 {
+   compatible = "ti,omap5430-timer";
+   reg = <0x4ae2 0x80>;
+   interrupts = ;
+   ti,hwmods = "timer12";
+   ti,timer-alwon;
+   ti,timer-secure;
+   status = "disabled";
+   };
+
timer13: timer@48828000 {
compatible = "ti,omap5430-timer";
reg = <0x48828000 0x80>;
-- 
2.6.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 v2 4/4] ARM: DRA7: hwmod: Add data for GPTimer 12

[Suman Anna]

Add the hwmod data for GPTimer 12. GPTimer 12 is present in
WKUPAON power domain and is clocked from a secure 32K clock.
GPTimer 12 serves as a secure timer on HS devices, but is
available for kernel on regular GP devices.

The hwmod link is registered only on GP devices. The hwmod data
also reused the existing timer class instead of reintroducing
the identical dra7xx_timer_secure_sysc class which was dropped
in commit edec17863362 ("ARM: DRA7: hwmod: Fix the hwmod class
for GPTimer4").

Signed-off-by: Suman Anna 
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 36 +--
 1 file changed, 34 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 562247bced49..37a10f87fbcd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1929,6 +1929,20 @@ static struct omap_hwmod dra7xx_timer11_hwmod = {
},
 };
 
+/* timer12 */
+static struct omap_hwmod dra7xx_timer12_hwmod = {
+   .name   = "timer12",
+   .class  = _timer_hwmod_class,
+   .clkdm_name = "wkupaon_clkdm",
+   .main_clk   = "secure_32k_clk_src_ck",
+   .prcm = {
+   .omap4 = {
+   .clkctrl_offs = 
DRA7XX_CM_WKUPAON_TIMER12_CLKCTRL_OFFSET,
+   .context_offs = 
DRA7XX_RM_WKUPAON_TIMER12_CONTEXT_OFFSET,
+   },
+   },
+};
+
 /* timer13 */
 static struct omap_hwmod dra7xx_timer13_hwmod = {
.name   = "timer13",
@@ -3135,6 +3149,14 @@ static struct omap_hwmod_ocp_if dra7xx_l4_per1__timer11 
= {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
+/* l4_wkup -> timer12 */
+static struct omap_hwmod_ocp_if dra7xx_l4_wkup__timer12 = {
+   .master = _l4_wkup_hwmod,
+   .slave  = _timer12_hwmod,
+   .clk= "wkupaon_iclk_mux",
+   .user   = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
 /* l4_per3 -> timer13 */
 static struct omap_hwmod_ocp_if dra7xx_l4_per3__timer13 = {
.master = _l4_per3_hwmod,
@@ -3429,6 +3451,13 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] 
__initdata = {
NULL,
 };
 
+/* GP-only hwmod links */
+static struct omap_hwmod_ocp_if *dra7xx_gp_hwmod_ocp_ifs[] __initdata = {
+   _l4_wkup__timer12,
+   NULL,
+};
+
+/* SoC variant specific hwmod links */
 static struct omap_hwmod_ocp_if *dra74x_hwmod_ocp_ifs[] __initdata = {
_l4_per3__usb_otg_ss4,
NULL,
@@ -3446,9 +3475,12 @@ int __init dra7xx_hwmod_init(void)
ret = omap_hwmod_register_links(dra7xx_hwmod_ocp_ifs);
 
if (!ret && soc_is_dra74x())
-   return omap_hwmod_register_links(dra74x_hwmod_ocp_ifs);
+   ret = omap_hwmod_register_links(dra74x_hwmod_ocp_ifs);
else if (!ret && soc_is_dra72x())
-   return omap_hwmod_register_links(dra72x_hwmod_ocp_ifs);
+   ret = omap_hwmod_register_links(dra72x_hwmod_ocp_ifs);
+
+   if (!ret && omap_type() == OMAP2_DEVICE_TYPE_GP)
+   ret = omap_hwmod_register_links(dra7xx_gp_hwmod_ocp_ifs);
 
return ret;
 }
-- 
2.6.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 v2 2/4] ARM: OMAP2+: timer: Remove secure timer for DRA7xx HS devices

[Suman Anna]

Timer 12 on DRA7 SoCs is reserved for secure usage on high-secure (HS)
devices. The timer cannot be used by the kernel on HS devices, but is
available on regular general purpose (GP) devices. This is similar to the
behavior on OMAP3 devices, so extend the logic used in commit ad24bde8f102
("ARM: OMAP3: Dynamically disable secure timer nodes for secure devices")
to remove the secure timer on DRA7xx SoCs at run-time based on the SoC
device type.

Signed-off-by: Suman Anna 
---
 arch/arm/mach-omap2/timer.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index a55655127ef2..1e346aa0a687 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -193,8 +193,8 @@ static struct device_node * __init omap_get_timer_dt(const 
struct of_device_id *
 /**
  * omap_dmtimer_init - initialisation function when device tree is used
  *
- * For secure OMAP3 devices, timers with device type "timer-secure" cannot
- * be used by the kernel as they are reserved. Therefore, to prevent the
+ * For secure OMAP3/DRA7xx devices, timers with device type "timer-secure"
+ * cannot be used by the kernel as they are reserved. Therefore, to prevent the
  * kernel registering these devices remove them dynamically from the device
  * tree on boot.
  */
@@ -202,7 +202,7 @@ static void __init omap_dmtimer_init(void)
 {
struct device_node *np;
 
-   if (!cpu_is_omap34xx())
+   if (!cpu_is_omap34xx() && !soc_is_dra7xx())
return;
 
/* If we are a secure device, remove any secure timer nodes */
-- 
2.6.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 v2 1/4] ARM: OMAP: dmtimer: check for fixed timers during config

[Suman Anna]

The omap_dm_timer_set_source() function provides a means for client
users to configure the mux parent for a GPTimer's functional clock.
However, not all timers are configurable (Eg: Timer12 on DRA7 is fed
by an internal 32k oscillator clock, and does not have configurable
parent clocks). So, check for such cases and proceed with out throwing
an error.

Signed-off-by: Suman Anna 
---
 arch/arm/plat-omap/dmtimer.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 8ca94d379bc3..4c48b52c4a7c 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -36,6 +36,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -504,6 +505,12 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer, 
int source)
if (IS_ERR(timer->fclk))
return -EINVAL;
 
+#if defined(CONFIG_COMMON_CLK)
+   /* Check if the clock has configurable parents */
+   if (clk_hw_get_num_parents(__clk_get_hw(timer->fclk)) < 2)
+   return 0;
+#endif
+
switch (source) {
case OMAP_TIMER_SRC_SYS_CLK:
parent_name = "timer_sys_ck";
-- 
2.6.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] ARM: shmobile: porter: add Ether DT support

[Sergei Shtylyov]

Define  the Porter board dependent part of  the Ether device node.
Enable DHCP and NFS root for the kernel booting.

This  patch  is analogous to the commit 26b0d2cf73cb (ARM: shmobile: henninger:
add Ether DT support)  as there  are no differences between those boards in this
respect.

Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>

---
This patch is against the 'renesas-devel-20151005-v4.3-rc4' tag of Simon
Horman's 'renesas.git' repo.

 arch/arm/boot/dts/r8a7791-porter.dts |   28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

Index: renesas/arch/arm/boot/dts/r8a7791-porter.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7791-porter.dts
+++ renesas/arch/arm/boot/dts/r8a7791-porter.dts
@@ -20,7 +20,7 @@
};
 
chosen {
-   bootargs = "ignore_loglevel";
+   bootargs = "ignore_loglevel rw root=/dev/nfs ip=dhcp";
stdout-path = 
};
 
@@ -44,6 +44,16 @@
renesas,groups = "scif0_data_d";
renesas,function = "scif0";
};
+
+   ether_pins: ether {
+   renesas,groups = "eth_link", "eth_mdio", "eth_rmii";
+   renesas,function = "eth";
+   };
+
+   phy1_pins: phy1 {
+   renesas,groups = "intc_irq0";
+   renesas,function = "intc";
+   };
 };
 
  {
@@ -52,3 +62,19 @@
 
status = "okay";
 };
+
+ {
+   pinctrl-0 = <_pins _pins>;
+   pinctrl-names = "default";
+
+   phy-handle = <>;
+   renesas,ether-link-active-low;
+   status = "ok";
+
+   phy1: ethernet-phy@1 {
+   reg = <1>;
+   interrupt-parent = <>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   micrel,led-mode = <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 v6 21/22] driver core: Start processing deferred probes earlier

[Rob Herring]

On Mon, Oct 5, 2015 at 6:52 PM, Frank Rowand  wrote:
> On 9/21/2015 7:03 AM, Tomeu Vizoso wrote:
>> Some initcalls in the late level assume that some devices will have
>> already probed without explicitly checking for that.
>>
>> After the recent move to defer most device probes when they are
>> registered, pressure increased in the late initcall level.
>>
>> By starting the processing of the deferred queue in device_initcall_sync
>> we increase the chances that the initcalls mentioned before will find
>> the devices they depend on to have already probed.
>>
>> Signed-off-by: Tomeu Vizoso 
>> ---
>>
>> Changes in v4:
>> - Start processing deferred probes in device_initcall_sync
>>
>>  drivers/base/dd.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
>> index 269ea76c1a4f..f0ef9233fcd6 100644
>> --- a/drivers/base/dd.c
>> +++ b/drivers/base/dd.c
>> @@ -176,7 +176,7 @@ static void driver_deferred_probe_trigger(void)
>>   *
>>   * We don't want to get in the way when the bulk of drivers are getting 
>> probed.
>>   * Instead, this initcall makes sure that deferred probing is delayed until
>> - * late_initcall time.
>> + * device_initcall_sync time.
>
> This is a misuse of the *_sync initcall level.
>
> If a deferred probe created a thread and expected a wait at the
> following *_sync level then the wait would not occur because
> there is no subsequent *_sync level.  This is not a problem today
> because (as far as I know) there are no threads in the probe
> functions.  But there has been interest in adding parallel
> probing and that could expose this problem.
>
> The purpose of the *_sync initcall levels is to allow the corresponding
> initcall level to use multiple threads of execution instead of a single
> thread.  The *_sync level provides a location for a wait for all of the
> threads at the corresponding init level to complete.  This is better
> explained in the git log:

The things I was worried about like clk and regulator disabling are
actually late_initcall_sync, so maybe late_initcall is fine here after
all.

However, looking at other *_initcall_sync users, I'm not so sure they
are doing the same abuse.

Rob

>
> commit 735a7ffb739b6efeaeb1e720306ba308eaaeb20e
> Author: Andrew Morton 
> Date:   Fri Oct 27 11:42:37 2006 -0700
>
> [PATCH] drivers: wait for threaded probes between initcall levels
>
> The multithreaded-probing code has a problem: after one initcall level 
> (eg,
> core_initcall) has been processed, we will then start processing the next
> level (postcore_initcall) while the kernel threads which are handling
> core_initcall are still executing.  This breaks the guarantees which the
> layered initcalls previously gave us.
>
> IOW, we want to be multithreaded _within_ an initcall level, but not 
> between
> different levels.
>
> Fix that up by causing the probing code to wait for all outstanding 
> probes at
> one level to complete before we start processing the next level.
>
>>   */
>>  static int deferred_probe_initcall(void)
>>  {
>> @@ -190,7 +190,7 @@ static int deferred_probe_initcall(void)
>>   flush_workqueue(deferred_wq);
>>   return 0;
>>  }
>> -late_initcall(deferred_probe_initcall);
>> +device_initcall_sync(deferred_probe_initcall);
>>
>>  static void driver_bound(struct device *dev)
>>  {
>>
>
--
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 v6 1/3] dtc: protect against null pointer dereference in srcpos_string()

[David Gibson]

On Fri, Oct 02, 2015 at 09:49:08PM -0700, Frank Rowand wrote:
> From: Frank Rowand 
> 
> Check for NULL pos before dereferencing it in srcpos_string().
> 
> Signed-off-by: Frank Rowand 
> ---
>  srcpos.c |6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> Index: b/srcpos.c
> ===
> --- a/srcpos.c
> +++ b/srcpos.c
> @@ -268,11 +268,13 @@ srcpos_string(struct srcpos *pos)
>   char *pos_str;
>   int rc;
>  
> - if (pos)
> + if (pos && pos->file)
>   fname = pos->file->name;
>  
>  
> - if (pos->first_line != pos->last_line)
> + if (!pos)
> + rc = asprintf(_str, "%s:", fname);
> + else if (pos->first_line != pos->last_line)

This logic still seems backwards to me.  I'd really prefer the !pos
check to go first, then !pos->file, then the normal case.

>   rc = asprintf(_str, "%s:%d.%d-%d.%d", fname,
> pos->first_line, pos->first_column,
> pos->last_line, pos->last_column);

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [PATCH][RESEND] drm: panel-simple: add URT UMSH-8596MD-xT panel support

[Thierry Reding]

On Fri, Oct 02, 2015 at 11:40:16PM +0200, Maciej S. Szmigiero wrote:
> Anybody here?
> 
> I've already submitted this patch two times but received no response...
> 
> Maciej Szmigiero
> 
> On 01.09.2015 15:50, Maciej S. Szmigiero wrote:
> > This patch adds support for United Radiant Technology
> > UMSH-8596MD-xT 7.0" WVGA TFT LCD panels
> > (both LVDS and parallel versions) to DRM
> > panel-simple driver.
> > 
> > Signed-off-by: Maciej Szmigiero 
> > ---
> > This is a resend without changes.
> > 
> > diff --git a/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt 
> > b/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt
> > new file mode 100644
> > index 000..2990e6b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt
> > @@ -0,0 +1,11 @@
> > +United Radiant Technology UMSH-8596MD-xT 7.0" WVGA TFT LCD panel
> > +
> > +Supported are LVDS versions (-11T, -19T) and parallel ones
> > +(-T, -1T, -7T, -20T).

Please don't use this kind of wildcard compatible values. If these are
different models then each of them deserves a separate compatible
string.

Thierry


signature.asc
Description: PGP signature

[PATCH] ARM64: dts: vexpress: Use a symlink to vexpress-v2m-rs1.dtsi from arch=arm

[Ian Campbell]

Commit 9ccd608070b6 "arm64: dts: add device tree for ARM SMM-A53x2 on
LogicTile Express 20MG" added a new dts file to arch/arm64 which
included "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi", i.e. a
.dtsi supplied by arch/arm.

Unfortunately this causes some issues for the split device tree
repository[0], since things get moved around there. In that context
the new .dts ends up at src/arm64/arm/vexpress-v2f-1xv7-ca53x2.dts
while the include is at src/arm/vexpress-v2m-rs1.dtsi.

The sharing of the .dtsi is legitimate since the baseboard is the same
for various vexpress systems whatever processor they use.

Previously I attempted to resolve this by creating a shared location
for such things but we have been unable to come to a consensus on
where that should be.

Instead this patch simply replaces the use of ../../ in the dts
/include/ with a symlink in arch/arm64/boot/dts/arm pointing to the
file arch/arm/boot/dts.

Since the split device tree repo will shortly be required to flatten
symlinks for other reasons this will cause the dtsi file to appear in
both src/arm and src/arm64 in the split repo, which is an improvement
on not building for arm64 now.

[0] 
https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/

Signed-off-by: Ian Campbell 
Cc: Rob Herring 
Cc: Pawel Moll 
Cc: Mark Rutland 
Cc: Kumar Gala 
Cc: Liviu Dudau 
Cc: Sudeep Holla 
Cc: Lorenzo Pieralisi 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Kristina Martsenko 
Cc: Kevin Hilman 
Cc: Frank Rowand 
Cc: Olof Johansson 
Cc: devicetree@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: a...@kernel.org
Cc: linux-kbu...@vger.kernel.org
---
For more on flattening symlinks see
http://thread.gmane.org/gmane.linux.kernel.input/45646/focus=45742
---
 arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts | 2 +-
 arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi| 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)
 create mode 12 arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi

diff --git a/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts 
b/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
index 5b1d018..bb3c26d 100644
--- a/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
+++ b/arch/arm64/boot/dts/arm/vexpress-v2f-1xv7-ca53x2.dts
@@ -186,6 +186,6 @@
<0 0 41  GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>,
<0 0 42  GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
 
-   /include/ "../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi"
+   /include/ "vexpress-v2m-rs1.dtsi"
};
 };
diff --git a/arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi 
b/arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi
new file mode 12
index 000..68fd0f8
--- /dev/null
+++ b/arch/arm64/boot/dts/arm/vexpress-v2m-rs1.dtsi
@@ -0,0 +1 @@
+../../../../arm/boot/dts/vexpress-v2m-rs1.dtsi
\ No newline at end of file
-- 
2.5.3

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

Re: "clk: sunxi: Add a simple gates driver" breaks kernel with older DTB

[Maxime Ripard]

1;3803;0c
On Fri, Oct 02, 2015 at 12:15:52PM +0100, Julien Grall wrote:
> On 02/10/15 11:53, Maxime Ripard wrote:
> >> If no, that's very unfortunate because it means that you can't
> >> re-use the same DT across multiple OS and the DT provided by the
> >> firmware (if it's built-in).
> > 
> > Is there such OS yet (and by that, I mean one that actually shares our
> > DT, instead of rewriting its own) ?
> 
> Yes, FreeBSD started to support the DT provided by vendors which are
> based on Linux bindings. The ARM64 port is only using DTB provided by
> the hardware. For ARM32, there is still some platform using a specific
> DT for FreeBSD but they are trying to get a ride.

Well, it would have been good if they contacted us in the first place
then, because this has never been considered seriously afaik, and we
never stated that it actually was an ABI.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH v2 5/7] hwrng: st: Add support for ST's HW Random Number Generator

[Daniel Thompson]

On 05/10/15 13:11, Lee Jones wrote:

On Mon, 05 Oct 2015, Daniel Thompson wrote:

Late but...


That's okay.  Fixup patches can always be submitted.

We have forever. :)


On 17/09/15 14:45, Lee Jones wrote:

diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 055bb01..8bcfb45 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -30,4 +30,5 @@ obj-$(CONFIG_HW_RANDOM_TPM) += tpm-rng.o
  obj-$(CONFIG_HW_RANDOM_BCM2835) += bcm2835-rng.o
  obj-$(CONFIG_HW_RANDOM_IPROC_RNG200) += iproc-rng200.o
  obj-$(CONFIG_HW_RANDOM_MSM) += msm-rng.o
+obj-$(CONFIG_HW_RANDOM_ST) += st-rng.o
  obj-$(CONFIG_HW_RANDOM_XGENE) += xgene-rng.o
diff --git a/drivers/char/hw_random/st-rng.c b/drivers/char/hw_random/st-rng.c
new file mode 100644
index 000..8c8a435
--- /dev/null
+++ b/drivers/char/hw_random/st-rng.c
@@ -0,0 +1,144 @@
+/*
+ * ST Random Number Generator Driver ST's Platforms
+ *
+ * Author: Pankaj Dev: 
+ * Lee Jones 
+ *
+ * Copyright (C) 2015 STMicroelectronics (R) Limited
+ *
+ * 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 
+
+/* Registers */
+#define ST_RNG_STATUS_REG  0x20
+#define ST_RNG_DATA_REG0x24
+
+/* Registers fields */
+#define ST_RNG_STATUS_BAD_SEQUENCE BIT(0)
+#define ST_RNG_STATUS_BAD_ALTERNANCE   BIT(1)
+#define ST_RNG_STATUS_FIFO_FULLBIT(5)
+
+#define ST_RNG_FIFO_SIZE   8
+#define ST_RNG_SAMPLE_SIZE 2 /* 2 Byte (16bit) samples */
+
+/* Samples are available every 0.667us, which we round to 1us */
+#define ST_RNG_FILL_FIFO_TIMEOUT   (1 * (ST_RNG_FIFO_SIZE / 
ST_RNG_SAMPLE_SIZE))
+
+struct st_rng_data {
+   void __iomem*base;
+   struct clk  *clk;
+   struct hwrngops;
+};
+
+static int st_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
+{
+   struct st_rng_data *ddata = (struct st_rng_data *)rng->priv;
+   u32 status;
+   int i;
+
+   if (max < sizeof(u16))
+   return -EINVAL;
+
+   /* Wait until FIFO is full - max 4uS*/
+   for (i = 0; i < ST_RNG_FILL_FIFO_TIMEOUT; i++) {
+   status = readl_relaxed(ddata->base + ST_RNG_STATUS_REG);
+   if (status & ST_RNG_STATUS_FIFO_FULL)
+   break;
+   udelay(1);


How much bandwidth does using udelay() cost? I think it could be

10% compared to a tighter polling loop.


Samples are only available every 0.7uS and we only do this for every
4.  The maximum it could 'cost' is <1uS.  Do we really want to fuss
over that tiny amount of time?  It's an understandable point if we
were talking about milliseconds, but a single microsecond?


This code is called in a tight loop so we're not talking about a 
*single* microsecond! We are are talking about about one microsecond in 
every five[1] and yes, I think we should care about that.


It takes 2.67uS for the FIFO to come ready so with a polling interval of 
1uS + loop overhead so I would fully expect on average to "waste" 0.5uS 
each time st_rng_read() is called (in a tight loop).



[1]... point three recurring  ;-)



+   }
+
+   if (i == ST_RNG_FILL_FIFO_TIMEOUT)
+   return 0;


Isn't a timeout an error condition?


Yes, which is why we're returning 0.  In this context 0 == 'no data'.
This will be converted to -EAGAIN if the caller did not request
NONBLOCKING.


I took the view that hitting the timeout means the hardware is broken. 
Is it likely that the next time we call it there will be data ready? If 
it is should it be trusted?



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

Re: [PATCH v2] extcon: gpio: Add the support for Device tree bindings

[Mark Rutland]

On Mon, Oct 05, 2015 at 03:58:19PM +0900, Chanwoo Choi wrote:
> This patch adds the support for Device tree bindings of extcon-gpio driver.
> The extcon-gpio device tree node must include the both 'extcon-id' and
> 'extcon-gpio' property.
> 
> For exmaple:
>   usb_cable: extcon-gpio-0 {
>   compatible = "extcon-gpio";
>   extcon-id = ;
>   extcon-gpio = < 1 GPIO_ACTIVE_HIGH>;
>   }
> 
>   ta_cable: extcon-gpio-1 {
>   compatible = "extcon-gpio";
>   extcon-id = ;
>   extcon-gpio = < 2 GPIO_ACTIVE_LOW>;
>   debounce-ms = <50>; /* 50 millisecond */
>   wakeup-source;
>   }
> 
>   _usb {
>   extcon = <_cable>;
>   };
> 
>{
>   extcon = <_cable>;
>   };
> 
> Signed-off-by: Chanwoo Choi 
> ---
> Changes from v1:
> - Create the include/dt-bindings/extcon/extcon.h including the identification
>   of external connector. These definitions are used in dts file.
> - Fix error if CONFIG_OF is disabled.
> 
>  .../devicetree/bindings/extcon/extcon-gpio.txt |  38 +++
>  drivers/extcon/extcon-gpio.c   | 110 
> -
>  include/dt-bindings/extcon/extcon.h|  44 +
>  include/linux/extcon/extcon-gpio.h |   6 +-
>  4 files changed, 173 insertions(+), 25 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio.txt
>  create mode 100644 include/dt-bindings/extcon/extcon.h
> 
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt 
> b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
> new file mode 100644
> index ..70c36f729963
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
> @@ -0,0 +1,38 @@
> +GPIO Extcon device
> +
> +This is a virtual device used to generate specific external connector
> +from the GPIO pin connected to a GPIO pin.
> +
> +Required properties:
> +- compatible: Must be "extcon-gpio".
> +- extcon-id: unique id for specific external connector.
> +  See include/dt-bindings/extcon/extcon.h.

This property is either misnamed and badly described, or it is
pointless (the node is sufficient to form a unique ID which can be
referenced by phandle).

What is this used for exactly?

> +- extcon-gpio: GPIO pin to detect the external connector. See gpio binding.
> +
> +Optional properties:
> +- debounce-ms: the debounce dealy for GPIO pin in millisecond.
> +- wakeup-source: Boolean, extcon can wake-up the system.
> +
> +Example: Examples of extcon-gpio node as listed below:
> +
> + usb_cable: extcon-gpio-0 {
> + compatible = "extcon-gpio";
> + extcon-id = ;
> + extcon-gpio = < 1 GPIO_ACTIVE_HIGH>;
> + }
> +
> + ta_cable: extcon-gpio-1 {
> + compatible = "extcon-gpio";
> + extcon-id = ;
> + extcon-gpio = < 2 GPIO_ACTIVE_LOW>;
> + debounce-ms = <50>; /* 50 millisecond */
> + wakeup-source;
> + }
> +
> + _usb {
> + extcon = <_cable>;
> + };
> +
> +  {
> + extcon = <_cable>;
> + };
> diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
> index 279ff8f6637d..7f3e24aae0c4 100644
> --- a/drivers/extcon/extcon-gpio.c
> +++ b/drivers/extcon/extcon-gpio.c
> @@ -1,8 +1,8 @@
>  /*
>   * extcon_gpio.c - Single-state GPIO extcon driver based on extcon class
>   *
> - * Copyright (C) 2008 Google, Inc.
> - * Author: Mike Lockwood 
> + * Copyright (C) 2015 Chanwoo Choi , Samsung 
> Electronics
> + * Copyright (C) 2008 Mike Lockwood , Google, Inc.
>   *
>   * Modified by MyungJoo Ham  to support extcon
>   * (originally switch class is supported)
> @@ -26,12 +26,14 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
>  struct gpio_extcon_data {
>   struct extcon_dev *edev;
>   int irq;
> + bool irq_wakeup;
>   struct delayed_work work;
>   unsigned long debounce_jiffies;
>  
> @@ -61,19 +63,50 @@ static irqreturn_t gpio_irq_handler(int irq, void *dev_id)
>   return IRQ_HANDLED;
>  }
>  
> -static int gpio_extcon_init(struct device *dev, struct gpio_extcon_data 
> *data)
> +static int gpio_extcon_parse_of(struct device *dev,
> + struct gpio_extcon_data *data)
>  {
> - struct gpio_extcon_pdata *pdata = data->pdata;
> + struct gpio_extcon_pdata *pdata;
>   int ret;
>  
> - ret = devm_gpio_request_one(dev, pdata->gpio, GPIOF_DIR_IN,
> - dev_name(dev));
> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return -ENOMEM;
> +
> + ret = device_property_read_u32(dev, "extcon-id", >extcon_id);
> + if (ret < 0)
> + return 

Re: [PATCH v2 5/7] hwrng: st: Add support for ST's HW Random Number Generator

[Lee Jones]

On Mon, 05 Oct 2015, Daniel Thompson wrote:
> Late but...

That's okay.  Fixup patches can always be submitted.

We have forever. :)

> On 17/09/15 14:45, Lee Jones wrote:
> >diff --git a/drivers/char/hw_random/Makefile 
> >b/drivers/char/hw_random/Makefile
> >index 055bb01..8bcfb45 100644
> >--- a/drivers/char/hw_random/Makefile
> >+++ b/drivers/char/hw_random/Makefile
> >@@ -30,4 +30,5 @@ obj-$(CONFIG_HW_RANDOM_TPM) += tpm-rng.o
> >  obj-$(CONFIG_HW_RANDOM_BCM2835) += bcm2835-rng.o
> >  obj-$(CONFIG_HW_RANDOM_IPROC_RNG200) += iproc-rng200.o
> >  obj-$(CONFIG_HW_RANDOM_MSM) += msm-rng.o
> >+obj-$(CONFIG_HW_RANDOM_ST) += st-rng.o
> >  obj-$(CONFIG_HW_RANDOM_XGENE) += xgene-rng.o
> >diff --git a/drivers/char/hw_random/st-rng.c 
> >b/drivers/char/hw_random/st-rng.c
> >new file mode 100644
> >index 000..8c8a435
> >--- /dev/null
> >+++ b/drivers/char/hw_random/st-rng.c
> >@@ -0,0 +1,144 @@
> >+/*
> >+ * ST Random Number Generator Driver ST's Platforms
> >+ *
> >+ * Author: Pankaj Dev: 
> >+ * Lee Jones 
> >+ *
> >+ * Copyright (C) 2015 STMicroelectronics (R) Limited
> >+ *
> >+ * 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 
> >+
> >+/* Registers */
> >+#define ST_RNG_STATUS_REG   0x20
> >+#define ST_RNG_DATA_REG 0x24
> >+
> >+/* Registers fields */
> >+#define ST_RNG_STATUS_BAD_SEQUENCE  BIT(0)
> >+#define ST_RNG_STATUS_BAD_ALTERNANCEBIT(1)
> >+#define ST_RNG_STATUS_FIFO_FULL BIT(5)
> >+
> >+#define ST_RNG_FIFO_SIZE8
> >+#define ST_RNG_SAMPLE_SIZE  2 /* 2 Byte (16bit) samples */
> >+
> >+/* Samples are available every 0.667us, which we round to 1us */
> >+#define ST_RNG_FILL_FIFO_TIMEOUT   (1 * (ST_RNG_FIFO_SIZE / 
> >ST_RNG_SAMPLE_SIZE))
> >+
> >+struct st_rng_data {
> >+void __iomem*base;
> >+struct clk  *clk;
> >+struct hwrngops;
> >+};
> >+
> >+static int st_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
> >+{
> >+struct st_rng_data *ddata = (struct st_rng_data *)rng->priv;
> >+u32 status;
> >+int i;
> >+
> >+if (max < sizeof(u16))
> >+return -EINVAL;
> >+
> >+/* Wait until FIFO is full - max 4uS*/
> >+for (i = 0; i < ST_RNG_FILL_FIFO_TIMEOUT; i++) {
> >+status = readl_relaxed(ddata->base + ST_RNG_STATUS_REG);
> >+if (status & ST_RNG_STATUS_FIFO_FULL)
> >+break;
> >+udelay(1);
> 
> How much bandwidth does using udelay() cost? I think it could be
> >10% compared to a tighter polling loop.

Samples are only available every 0.7uS and we only do this for every
4.  The maximum it could 'cost' is <1uS.  Do we really want to fuss
over that tiny amount of time?  It's an understandable point if we
were talking about milliseconds, but a single microsecond?

> >+}
> >+
> >+if (i == ST_RNG_FILL_FIFO_TIMEOUT)
> >+return 0;
> 
> Isn't a timeout an error condition?

Yes, which is why we're returning 0.  In this context 0 == 'no data'.
This will be converted to -EAGAIN if the caller did not request
NONBLOCKING.

> >+
> >+for (i = 0; i < ST_RNG_FIFO_SIZE && i < max; i += 2)
> >+*(u16 *)(data + i) =
> >+readl_relaxed(ddata->base + ST_RNG_DATA_REG);
> >+
> >+return i;   /* No of bytes read */
> >+}
> >+
> >+static int st_rng_probe(struct platform_device *pdev)
> >+{
> >+struct st_rng_data *ddata;
> >+struct resource *res;
> >+struct clk *clk;
> >+void __iomem *base;
> >+int ret;
> >+
> >+ddata = devm_kzalloc(>dev, sizeof(*ddata), GFP_KERNEL);
> >+if (!ddata)
> >+return -ENOMEM;
> >+
> >+res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >+base = devm_ioremap_resource(>dev, res);
> >+if (IS_ERR(base))
> >+return PTR_ERR(base);
> >+
> >+clk = devm_clk_get(>dev, NULL);
> >+if (IS_ERR(clk))
> >+return PTR_ERR(clk);
> >+
> >+ret = clk_prepare_enable(clk);
> >+if (ret)
> >+return ret;
> >+
> >+ddata->ops.priv = (unsigned long)ddata;
> >+ddata->ops.read = st_rng_read;
> >+ddata->ops.name = pdev->name;
> >+ddata->base = base;
> >+ddata->clk  = clk;
> >+
> >+dev_set_drvdata(>dev, ddata);
> >+
> >+ret = hwrng_register(>ops);
> >+if (ret) {
> >+dev_err(>dev, "Failed to register HW RNG\n");
> 
> Why shout about this particular error but not any others? Perhaps
> just rely on the driver core to report the error here?

I have omitted error prints from subsystem calls which do all the
shouting required.  Unfortunately the HWRNG is somewhat stuck in the
past in a number of ways; a lack of subsystem level 

[PATCH v4 3/5] ARM: STi: stih407-family: Add nodes for Mailbox

[Lee Jones]

This patch supplies the Mailbox Controller nodes.  In order to
request channels, these nodes will be referenced by Mailbox
Client nodes.

Signed-off-by: Lee Jones 
---
 arch/arm/boot/dts/stih407-family.dtsi | 36 +++
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
b/arch/arm/boot/dts/stih407-family.dtsi
index 838b812..32da3f8 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -565,5 +565,41 @@
  <_port2 PHY_TYPE_USB3>;
};
};
+
+   mailbox0: mailbox@0  {
+   compatible  = "st,stih407-mailbox";
+   reg = <0x8f0 0x1000>;
+   interrupts  = ;
+   #mbox-cells = <2>;
+   mbox-name   = "a9";
+   status  = "okay";
+   };
+
+   mailbox1: mailbox@1 {
+   compatible  = "st,stih407-mailbox";
+   reg = <0x8f01000 0x1000>;
+   #mbox-cells = <2>;
+   mbox-name   = "st231_gp_1";
+   status  = "okay";
+   tx-only;
+   };
+
+   mailbox2: mailbox@2 {
+   compatible  = "st,stih407-mailbox";
+   reg = <0x8f02000 0x1000>;
+   #mbox-cells = <2>;
+   mbox-name   = "st231_gp_0";
+   status  = "okay";
+   tx-only;
+   };
+
+   mailbox3: mailbox@3 {
+   compatible  = "st,stih407-mailbox";
+   reg = <0x8f03000 0x1000>;
+   #mbox-cells = <2>;
+   mbox-name   = "st231_audio_video";
+   status  = "okay";
+   tx-only;
+   };
};
 };
-- 
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 v4 5/5] ARM: STi: DT: STiH407: Enable Mailbox testing facility

[Lee Jones]

This patch supplies a Client node to enable the Mailbox testing
facility.  It will be used to send and receive messages from any
given co-processor in order to test the STi Mailbox Controller
driver.

Signed-off-by: Lee Jones 
---
 arch/arm/boot/dts/stih407-family.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi 
b/arch/arm/boot/dts/stih407-family.dtsi
index 32da3f8..ac1d1ee 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -566,6 +566,12 @@
};
};
 
+   mailbox_test {
+   compatible = "mailbox_test";
+   mboxes = < 1 31>, < 1 31>;
+   mbox-names = "tx", "rx";
+   };
+
mailbox0: mailbox@0  {
compatible  = "st,stih407-mailbox";
reg = <0x8f0 0x1000>;
-- 
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: [linux-sunxi] [PATCH 1/3] ARM: dts: sun4i: Allow to use the PH6 pin for GPIO on pcDuino1/2

[Maxime Ripard]

On Mon, Oct 05, 2015 at 08:39:40AM +0300, Siarhei Siamashka wrote:
> On Mon, 5 Oct 2015 09:55:28 +0800
> Chen-Yu Tsai  wrote:
> 
> > On Mon, Oct 5, 2015 at 2:58 AM, Siarhei Siamashka
> >  wrote:
> > > The pcDuino1 board does not use any power switches at all for its
> > > two USB host ports and the VBUS pins are always connected to 5V.
> > >
> > > The pcDuino2 board uses the RT9701GB power switch for its single
> > > USB host port, but the USB_EN pin (PD2) is pulled up with a 10K
> > > resistor. So that the USB power is still enabled by default even
> > > if nobody bothers to configure the PD2 pin or runs the pcDuino1
> > > firmware.
> > 
> > Seems like it would be better if you had a regulator controlled
> > by PD2. At least can shut down VBUS power when it wants to?
> 
> That's a good question.
> 
> Describing the regulator controlled by PD2 in the dts file is surely
> the right solution for pcDuino2 boards. But in the case of using this
> dts for pcDuino1, the kernel would think that it can shut down VBUS
> power, while in fact this is not true.

I do agree that this is the right solution for the pcduino1, but it's
definitely not the right one for the pcduino 2 then.

Declaring this as a regulator isn't just meant for the USB to be
working, it's also meant so that it keeps working. If the pin is not
claimed by anyone, the userspace and / or some other driver, will
actually be able to grab that pin and do whatever it wants with it,
effectively fiddling with the VBUS supply behind the USB driver's
back.

It also allows to disable the regulator if VBUS isn't going to be
used, for example because the driver has not be compiled in, or that
it's actually a module that might (or might not) be loaded later.

Finally, it also allows to keep track of who consumes what amount of
power in the system, which is a nice plus.

> The RT9701GB switch also provides the current limiting feature in
> addition to the ability to enable/disable the VBUS power. Probably
> this was a real reason why it was added to the board.
> 
> Everything boils down to the question whether we want to have a
> common dts file for pcDuino1 and pcDuino2 or decide to split them.

You don't have to split them, if this is really the only difference,
just create a new dts for the pcduino2 that includes the first one,
and add the supply there.

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH][RESEND] drm: panel-simple: add URT UMSH-8596MD-xT panel support

[Thierry Reding]

On Mon, Oct 05, 2015 at 01:33:49AM +0200, Maciej S. Szmigiero wrote:
> Hi Emil,
> 
> Thanks for your response,
> 
> On 04.10.2015 12:43, Emil Velikov wrote:
> > Hi Maciej,
> > 
> > On 2 October 2015 at 22:40, Maciej S. Szmigiero
> >  wrote:
> >> Anybody here?
> >>
> >> I've already submitted this patch two times but received no response...
> >>
> > Seems that the maintainer (Thierry) isn't Cc'ed.
> 
> Yes, he was Cc'ed - see for example 
> https://patchwork.ozlabs.org/patch/512858/ .

Sorry, I never received any of your earlier patches. It's in none of my
mailboxes nor was it classified as spam. Even searching by message ID
doesn't give me a positive hit.

> > You might want to
> > split the DT binding and vendor prefix to separate patches.
> 
> Do you mean to first submit new vendor prefix then panel patch with docs?
> Or even docs separately?

This should be three patches: the vendor prefix is usually a separate
patch and needs an Acked-by from one of the device tree bindings
maintainers. The binding itself should also be a separate patch and the
driver changes should come last.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH 3/3] ARM: dts: sun4i: Add AXP209 PMU regulators for pcDuino1/2

[Maxime Ripard]

On Sun, Oct 04, 2015 at 09:58:48PM +0300, Siarhei Siamashka wrote:
> This allows voltage-scaling with cpufreq-dt. The reliability of
> voltage-scaling has been checked by reducing the voltage of all
> operating points by 0.025V (for extra safety headroom) and running
> libjpeg-turbo decoding tests on 5 pcDuino2 boards. It means that
> the standard sun4i voltages should be perfectly fine too.
> 
> Signed-off-by: Siarhei Siamashka 

Applied, thanks!

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH v2 4/5] mfd: arizona: Update DT binding documentation for mic detection

[Lee Jones]

On Fri, 02 Oct 2015, Charles Keepax wrote:

> Add additional bindings to allow configuration of the system specific
> microphone detection settings.
> 
> Signed-off-by: Charles Keepax 
> ---
>  Documentation/devicetree/bindings/mfd/arizona.txt |   21 
> +
>  include/dt-bindings/mfd/arizona.h |5 +
>  2 files changed, 26 insertions(+), 0 deletions(-)

You either need a sound guy or a DT guy or both to Ack this.

> diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt 
> b/Documentation/devicetree/bindings/mfd/arizona.txt
> index a8fee60..b98a11b 100644
> --- a/Documentation/devicetree/bindings/mfd/arizona.txt
> +++ b/Documentation/devicetree/bindings/mfd/arizona.txt
> @@ -73,6 +73,27 @@ Optional properties:
>  If this node is not mentioned or if the value is unknown, then
>  headphone detection mode is set to HPDETL.
>  
> +  - wlf,micd-software-compare : Use a software comparison to determine mic
> +presence
> +  - wlf,micd-detect-debounce : Additional software microphone detection
> +debounce specified in milliseconds.
> +  - wlf,micd-pol-gpio : GPIO specifier for the GPIO controlling the headset
> +polarity if one exists.
> +  - wlf,micd-bias-start-time : Time allowed for MICBIAS to startup prior to
> +performing microphone detection, specified as per the 
> ARIZONA_MICD_TIME_XXX
> +defines.
> +  - wlf,micd-rate : Delay between successive microphone detection 
> measurements,
> +specified as per the ARIZONA_MICD_TIME_XXX defines.
> +  - wlf,micd-dbtime : Microphone detection hardware debounces specified as 
> the
> +number of measurements to take, valid values being 2 and 4.
> +  - wlf,micd-timeout : Timeout for microphone detection, specified in
> +milliseconds.
> +  - wlf,micd-force-micbias : Force MICBIAS continuously on during microphone
> +detection.
> +
> +  - wlf,gpsw : Settings for the general purpose switch, set as one of the
> +ARIZONA_GPSW_XXX defines.
> +
>- DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified 
> if
>  they are being externally supplied. As covered in
>  Documentation/devicetree/bindings/regulator/regulator.txt
> diff --git a/include/dt-bindings/mfd/arizona.h 
> b/include/dt-bindings/mfd/arizona.h
> index c40f665..dedf46f 100644
> --- a/include/dt-bindings/mfd/arizona.h
> +++ b/include/dt-bindings/mfd/arizona.h
> @@ -110,4 +110,9 @@
>  #define ARIZONA_ACCDET_MODE_HPM 4
>  #define ARIZONA_ACCDET_MODE_ADC 7
>  
> +#define ARIZONA_GPSW_OPEN   0
> +#define ARIZONA_GPSW_CLOSED 1
> +#define ARIZONA_GPSW_CLAMP_ENABLED  2
> +#define ARIZONA_GPSW_CLAMP_DISABLED 3
> +
>  #endif

-- 
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 v2 5/5] mfd: arizona: Update DT binding document for jack detection invert

[Lee Jones]

On Fri, 02 Oct 2015, Charles Keepax wrote:

> Add additional binding for inverting the polarity of the detection on
> the jack detection pins.
> 
> Signed-off-by: Charles Keepax 
> ---
>  Documentation/devicetree/bindings/mfd/arizona.txt |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt 
> b/Documentation/devicetree/bindings/mfd/arizona.txt
> index b98a11b..ef59696 100644
> --- a/Documentation/devicetree/bindings/mfd/arizona.txt
> +++ b/Documentation/devicetree/bindings/mfd/arizona.txt
> @@ -73,6 +73,8 @@ Optional properties:
>  If this node is not mentioned or if the value is unknown, then
>  headphone detection mode is set to HPDETL.
>  
> +  - wlf,jd-invert : Invert the polarity of the jack detection switch
> +

There are other jack detection properties in the bindings docs.

Please generify.

>- wlf,micd-software-compare : Use a software comparison to determine mic
>  presence
>- wlf,micd-detect-debounce : Additional software microphone detection

-- 
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] QEMU fw_cfg DMA interface documentation

[Stefan Hajnoczi]

On Mon, Oct 5, 2015 at 11:06 AM, Marc Marí  wrote:
> On Mon, 5 Oct 2015 09:20:55 +0100
> Stefan Hajnoczi  wrote:
>
>> On Thu, Oct 1, 2015 at 1:15 PM, Marc Marí  wrote:
>> > +Additionaly, if the DMA interface is available then a read to the
>> > DMA Address +will return 0x51454d5520434647 ("QEMU CFG" in
>> > big-endian format).
>>
>> What does this mean?
>>
>
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg325546.html
>
> Proposed by Kevin O'Connor in v3.
>
> (I could not find this thread in gnu.org or gmane archives. It's
> strange).

The following is clearer to me:

If the DMA interface is available, then reading the DMA Address
Register returns 0x51454d5520434647 ("QEMU CFG" in big-endian format).

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

Re: [PATCH v2 5/7] hwrng: st: Add support for ST's HW Random Number Generator

[Daniel Thompson]

Hi Lee

Late but...

On 17/09/15 14:45, Lee Jones wrote:

diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 055bb01..8bcfb45 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -30,4 +30,5 @@ obj-$(CONFIG_HW_RANDOM_TPM) += tpm-rng.o
  obj-$(CONFIG_HW_RANDOM_BCM2835) += bcm2835-rng.o
  obj-$(CONFIG_HW_RANDOM_IPROC_RNG200) += iproc-rng200.o
  obj-$(CONFIG_HW_RANDOM_MSM) += msm-rng.o
+obj-$(CONFIG_HW_RANDOM_ST) += st-rng.o
  obj-$(CONFIG_HW_RANDOM_XGENE) += xgene-rng.o
diff --git a/drivers/char/hw_random/st-rng.c b/drivers/char/hw_random/st-rng.c
new file mode 100644
index 000..8c8a435
--- /dev/null
+++ b/drivers/char/hw_random/st-rng.c
@@ -0,0 +1,144 @@
+/*
+ * ST Random Number Generator Driver ST's Platforms
+ *
+ * Author: Pankaj Dev: 
+ * Lee Jones 
+ *
+ * Copyright (C) 2015 STMicroelectronics (R) Limited
+ *
+ * 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 
+
+/* Registers */
+#define ST_RNG_STATUS_REG  0x20
+#define ST_RNG_DATA_REG0x24
+
+/* Registers fields */
+#define ST_RNG_STATUS_BAD_SEQUENCE BIT(0)
+#define ST_RNG_STATUS_BAD_ALTERNANCE   BIT(1)
+#define ST_RNG_STATUS_FIFO_FULLBIT(5)
+
+#define ST_RNG_FIFO_SIZE   8
+#define ST_RNG_SAMPLE_SIZE 2 /* 2 Byte (16bit) samples */
+
+/* Samples are available every 0.667us, which we round to 1us */
+#define ST_RNG_FILL_FIFO_TIMEOUT   (1 * (ST_RNG_FIFO_SIZE / 
ST_RNG_SAMPLE_SIZE))
+
+struct st_rng_data {
+   void __iomem*base;
+   struct clk  *clk;
+   struct hwrngops;
+};
+
+static int st_rng_read(struct hwrng *rng, void *data, size_t max, bool wait)
+{
+   struct st_rng_data *ddata = (struct st_rng_data *)rng->priv;
+   u32 status;
+   int i;
+
+   if (max < sizeof(u16))
+   return -EINVAL;
+
+   /* Wait until FIFO is full - max 4uS*/
+   for (i = 0; i < ST_RNG_FILL_FIFO_TIMEOUT; i++) {
+   status = readl_relaxed(ddata->base + ST_RNG_STATUS_REG);
+   if (status & ST_RNG_STATUS_FIFO_FULL)
+   break;
+   udelay(1);


How much bandwidth does using udelay() cost? I think it could be >10% 
compared to a tighter polling loop.




+   }
+
+   if (i == ST_RNG_FILL_FIFO_TIMEOUT)
+   return 0;


Isn't a timeout an error condition?



+
+   for (i = 0; i < ST_RNG_FIFO_SIZE && i < max; i += 2)
+   *(u16 *)(data + i) =
+   readl_relaxed(ddata->base + ST_RNG_DATA_REG);
+
+   return i;   /* No of bytes read */
+}
+
+static int st_rng_probe(struct platform_device *pdev)
+{
+   struct st_rng_data *ddata;
+   struct resource *res;
+   struct clk *clk;
+   void __iomem *base;
+   int ret;
+
+   ddata = devm_kzalloc(>dev, sizeof(*ddata), GFP_KERNEL);
+   if (!ddata)
+   return -ENOMEM;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   base = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(base))
+   return PTR_ERR(base);
+
+   clk = devm_clk_get(>dev, NULL);
+   if (IS_ERR(clk))
+   return PTR_ERR(clk);
+
+   ret = clk_prepare_enable(clk);
+   if (ret)
+   return ret;
+
+   ddata->ops.priv  = (unsigned long)ddata;
+   ddata->ops.read  = st_rng_read;
+   ddata->ops.name  = pdev->name;
+   ddata->base  = base;
+   ddata->clk   = clk;
+
+   dev_set_drvdata(>dev, ddata);
+
+   ret = hwrng_register(>ops);
+   if (ret) {
+   dev_err(>dev, "Failed to register HW RNG\n");


Why shout about this particular error but not any others? Perhaps just 
rely on the driver core to report the error here?




+   return ret;
+   }
+
+   dev_info(>dev, "Successfully registered HW RNG\n");
+
+   return 0;
+}
+
+static int st_rng_remove(struct platform_device *pdev)
+{
+   struct st_rng_data *ddata = dev_get_drvdata(>dev);
+
+   hwrng_unregister(>ops);
+
+   clk_disable_unprepare(ddata->clk);


This mismatches the error paths in the probe function (there is no 
cleanup of clock counts in probe function).



Daniel.
--
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] leds: rt5033: add DT binding for RT5033

[Ingi Kim]

Hello, Rob Herring

I'll push ver2 patch soon with your acked
because other patch has some issues.

Thanks for the review.

On 2015년 10월 02일 23:31, Rob Herring wrote:
> On Fri, Oct 2, 2015 at 4:41 AM, Ingi Kim  wrote:
>> This patch adds the device tree bindings for RT5033 flash LEDs.
>>
>> Signed-off-by: Ingi Kim 
> 
> Acked-by: Rob Herring 
> 
>> ---
>>  .../devicetree/bindings/leds/leds-rt5033.txt   | 38 
>> ++
>>  1 file changed, 38 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/leds/leds-rt5033.txt
>>
>> diff --git a/Documentation/devicetree/bindings/leds/leds-rt5033.txt 
>> b/Documentation/devicetree/bindings/leds/leds-rt5033.txt
>> new file mode 100644
>> index 000..2ef7bdc
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/leds/leds-rt5033.txt
>> @@ -0,0 +1,38 @@
>> +* Richtek Technology Corporation - RT5033 Flash LED Driver
>> +
>> +The RT5033 Flash LED Circuit is designed for one or two LEDs driving
>> +for torch and strobe applications, it provides an I2C software command
>> +to trigger the torch and strobe operation.
>> +
>> +Required properties:
>> +- compatible : Must be "richtek,rt5033-led".
>> +
>> +A discrete LED element connected to the device must be represented by a 
>> child
>> +node - see Documentation/devicetree/bindings/leds/common.txt.
>> +
>> +Required properties of the LED child node:
>> +  See Documentation/devicetree/bindings/leds/common.txt
>> +- led-max-microamp : Minimum Threshold for Timer protection
>> +  is defined internally (Maximum 200mA).
>> +- flash-max-microamp : Flash LED maximum current
>> +- flash-max-timeout-us : Flash LED maximum timeout
>> +
>> +Optional properties of the LED child node:
>> +- label : see Documentation/devicetree/bindings/leds/common.txt
>> +
>> +Example:
>> +
>> +rt5033 {
>> +   compatible = "richtek,rt5033";
>> +
>> +   led {
>> +   compatible = "richtek,rt5033-led";
>> +
>> +   flash-led {
>> +   label = "rt5033-flash";
>> +   led-max-microamp = <20>;
>> +   flash-max-microamp = <80>;
>> +   flash-max-timeout-us = <1216000>;
>> +   };
>> +   };
>> +}
>> --
>> 2.0.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 v2] extcon: gpio: Add the support for Device tree bindings

[Chanwoo Choi]

On 2015년 10월 05일 17:03, MyungJoo Ham wrote:
>>   
>>  This patch adds the support for Device tree bindings of extcon-gpio driver.
>> The extcon-gpio device tree node must include the both 'extcon-id' and
>> 'extcon-gpio' property.
>>
> []
>>
>> Signed-off-by: Chanwoo Choi 
> 
> 
> Except for some beautification issues described below,
> 
> Signed-off-by: MyungJoo Ham 
> 
>> ---
>> This patch is based on following patch[1].
>> [1] https://lkml.org/lkml/2015/10/3/304
>>
>> Changes from v1:
>> - Create the include/dt-bindings/extcon/extcon.h including the identification
>>   of external connector. These definitions are used in dts file.
>> - Fix error if CONFIG_OF is disabled.
>>
>>  .../devicetree/bindings/extcon/extcon-gpio.txt |  38 +++
>>  drivers/extcon/extcon-gpio.c   | 110 
>> -
>>  include/dt-bindings/extcon/extcon.h|  44 +
>>  include/linux/extcon/extcon-gpio.h |   6 +-
>>  4 files changed, 173 insertions(+), 25 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio.txt
>>  create mode 100644 include/dt-bindings/extcon/extcon.h
>>
>> diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt 
>> b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
>> new file mode 100644
>> index ..70c36f729963
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
> []
>> diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
>> index 279ff8f6637d..7f3e24aae0c4 100644
>> --- a/drivers/extcon/extcon-gpio.c
>> +++ b/drivers/extcon/extcon-gpio.c
>> @@ -1,8 +1,8 @@
>>  /*
>>   * extcon_gpio.c - Single-state GPIO extcon driver based on extcon class
>>   *
>> - * Copyright (C) 2008 Google, Inc.
>> - * Author: Mike Lockwood 
>> + * Copyright (C) 2015 Chanwoo Choi , Samsung 
>> Electronics
>> + * Copyright (C) 2008 Mike Lockwood , Google, Inc.
>>   *
>>   * Modified by MyungJoo Ham  to support extcon
>>   * (originally switch class is supported)
> 
> Let's make it in chronological order.
> (may need to "beautify the last two lines as well)
> 
> I.e., 2008-->2012-->2015 or 2015-->2012-->2008.
> Not 2015-->2008-->2012

OK. I'll modify it.

> 
> 
>> @@ -26,12 +26,14 @@
> []
>> diff --git a/include/dt-bindings/extcon/extcon.h 
>> b/include/dt-bindings/extcon/extcon.h
>> new file mode 100644
>> index ..14c7f36b2206
>> --- /dev/null
>> +++ b/include/dt-bindings/extcon/extcon.h
> []
>> diff --git a/include/linux/extcon/extcon-gpio.h 
>> b/include/linux/extcon/extcon-gpio.h
>> index 7cacafb78b09..bcc6d7f7116a 100644
>> --- a/include/linux/extcon/extcon-gpio.h
>> +++ b/include/linux/extcon/extcon-gpio.h
> []
>> @@ -38,7 +38,7 @@ struct gpio_extcon_pdata {
>>  unsigned int extcon_id;
>>  unsigned gpio;
>>  bool gpio_active_low;
>> -unsigned long debounce;
>> +unsigned int debounce;
> 
> What about u32, making it more clear?
> ( > + device_property_read_u32(dev, "debounce-ms", >debounce); )

OK.

Thanks,
Chanwoo Choi

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

Re: [PATCH v2 2/3] iio:adc:palmas: add DT support

[Laxman Dewangan]

On Monday 05 October 2015 11:44 AM, H. Nikolaus Schaller wrote:

From: Marek Belisko 

Code was found at:
https://android.googlesource.com/kernel/tegra/+/a90856a6626d502d42c6e7abccbdf9d730b36270%5E%21/#F1

Signed-off-by: Laxman Dewangan 
[Fixed minor typos + add channels list to documentation]
Signed-off-by: Marek Belisko 
---


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

Re: [PATCH v2 2/3] iio:adc:palmas: add DT support

[Mark Rutland]

On Sun, Oct 04, 2015 at 06:05:59PM +0200, H. Nikolaus Schaller wrote:
> From: Marek Belisko 
> 
> Code was found at:
> https://android.googlesource.com/kernel/tegra/+/a90856a6626d502d42c6e7abccbdf9d730b36270%5E%21/#F1
> 
> Signed-off-by: Laxman Dewangan 
> [Fixed minor typos + add channels list to documentation]
> Signed-off-by: Marek Belisko 
> ---
> .../devicetree/bindings/iio/adc/palmas-gpadc.txt   | 46 +++
> drivers/iio/adc/palmas_gpadc.c | 52 +++---
> 2 files changed, 93 insertions(+), 5 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
> 
> diff --git a/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt 
> b/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
> new file mode 100644
> index 000..2149afe
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
> @@ -0,0 +1,46 @@
> +* Palmas general purpose ADC IP block devicetree bindings
> +
> +Channels list:
> + 0 battery type
> + 1 battery temp NTC (optional current source)
> + 2 GP
> + 3 temp (with ext. diode, optional current source)
> + 4 GP
> + 5 GP
> + 6 VBAT_SENSE
> + 7 VCC_SENSE
> + 8 Backup Battery voltage
> + 9 external charger (VCHG)
> + 10 VBUS
> + 11 DC-DC current probe (how does this work?)
> + 12 internal die temp
> + 13 internal die temp
> + 14 USB ID pin voltage
> + 15 test network
> +
> +Required properties:
> +- compatible : Must be "ti,palmas-gpadc".
> +
> +Optional sub-nodes:
> +ti,channel0-current-microamp: Channel 0 current in uA.
> + Values are rounded to derive 0uA, 5uA, 15uA, 20uA.
> +ti,channel3-current-microamp: Channel 3 current in uA.
> + Valid are rounded to derive 0uA, 10uA, 400uA, 800uA.

It's only possible to configure channels 0 and 3 in this manner?

> +ti,enable-extended-delay: Enable extended delay.

What is this? When would I select it? Why does it belong in the DT
rather than being a runtime option?

> +Example:
> +
> +pmic {
> + compatible = "ti,twl6035-pmic", "ti,palmas-pmic";
> + ...
> + gpadc {
> + compatible = "ti,palmas-gpadc";
> + interrupts = <18 0
> +   16 0
> +   17 0>;
> + ti,channel0-current-microamp = <5>;
> + ti,channel3-current-microamp = <10>;
> + };
> + };
> + ...
> +};

I thought you needed #iio-cells for encoding the channel?

Mark.
--
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 v8 0/10] Add external dma support for Synopsys MSHC

[Shawn Lin]

On 2015/10/5 9:36, Jaehoon Chung wrote:

Hi, Shawn.

On 10/02/2015 06:49 PM, Shawn Lin wrote:

On 2015/10/1 17:14, Jaehoon Chung wrote:

Dear, All.

I will apply patch 01-03 at my repository on today.
But i don't know better how i do about other patches relevant to config file.



Thanks, Jaehoon. :)

I guess it would be acceptable to pick the config changes, already they were 
acked by the soc maintainers, via dw_mmc tree when ulf merge dw_mmc tree into 
his mmc-tree.


Some patches didn't get the maintainer's acked-by.
I will wait for that..until this week. How about?



No problem, take your time. ：）


Best Regards,
Jaehoon Chung





Best Regards,
Jaehoon Chung

On 09/16/2015 03:40 PM, Shawn Lin wrote:

Synopsys DesignWare mobile storage host controller supports three
types of transfer mode: pio, internal dma and external dma. However,
dw_mmc can only supports pio and internal dma now. Thus some platforms
using dw-mshc integrated with generic dma can't work in dma mode. So we
submit this patch to achieve it.

And the config option, CONFIG_MMC_DW_IDMAC, was added by Will Newton
(commit:f95f3850) for the first version of dw_mmc and never be touched since
then. At that time dt-bindings hadn't been introduced into dw_mmc yet means
we should select CONFIG_MMC_DW_IDMAC to enable internal dma mode at compile
time. Nowadays, device-tree helps us to support a variety of boards with one
kernel. That's why we need to remove it and decide the transfer mode by reading
dw_mmc's HCON reg at runtime.

This RFC patch needs lots of ACKs. I know it's hard, but it does need someone
to make the running.

Patch does the following things:
- remove CONFIG_MMC_DW_IDMAC config option
- add bindings for edmac used by synopsys-dw-mshc
at runtime
- add edmac support for synopsys-dw-mshc

Patch is based on next of git://git.linaro.org/people/ulf.hansson/mmc

Test emmc throughput on my platform with edmac support and without edmac 
support(pio only)
iozone -L64 -S32 -azecwI -+n -r4k -r64k -r128k -s1g -i0 -i1 -i2 -f datafile -Rb 
out.xls > /mnt/result.txt
(light cpu loading, Direct IO, fixed line size, all pattern recycle, 1GB data 
in total)
   ___
|   external dma mode   |
|---|
|blksz | Random Read | Random Write | Seq Read   | Seq Write|
|---|
|4kB   |  13953kB/s  |8602kB/s  | 13672kB/s  |  9785kB/s|
|---|
|64kB  |  46058kB/s  |   24794kB/s  | 48058kB/s  | 25418kB/s|
|---|
|128kB |  57026kB/s  |   35117kB/s  | 57375kB/s  | 35183kB/s|
|---|
 VS
   ___
|  pio mode |
|---|
|blksz | Random Read  | Random Write | Seq Read  | Seq Write|
|---|
|4kB   |  11720kB/s   |8644kB/s  | 11549kB/s |  9624kB/s|
|---|
|64kB  |  21869kB/s   |   24414kB/s  | 22031kB/s | 27986kB/s|
|---|
|128kB |  23718kB/s   |   34495kB/s  | 24698kB/s | 34637kB/s|
|---|


Changes in v8:
- remove trans_mode variable
- remove unnecessary dma_ops check
- remove unnecessary comment
- fix coding style based on latest ulf's next
- add Acked-by: Jaehoon Chung 
for HCON's changes

Changes in v7:
- rebased on Ulf's next
- combine condition state
- elaborate more about DMA_INTERFACE
- define some macro for DMA_INERFACE value
- spilt HCON ops' changes into another patch

Changes in v6:
- add trans_mode condition for IDMAC initialization
suggested by Heiko
- re-test my patch on rk3188 platform and update commit msg
- update performance of pio vs edmac in cover letter

Changes in v5:
- add the title of cover letter
- fix typo of comment
- add macro for reading HCON register
- add "Acked-by: Krzysztof Kozlowski " for 
exynos_defconfig patch
- add "Acked-by: Vineet Gupta " for axs10x_defconfig patch
- add "Acked-by: Govindraj Raja " and
"Acked-by: Ralf Baechle " for pistachio_defconfig patch
- add "Acked-by: Joachim Eastwood " for lpc18xx_defconfig 
patch
- add "Acked-by: Wei Xu " for hisi_defconfig patch
- rebase on "https://github.com/jh80chung/dw-mmc.git tags/dw-mmc-for-ulf-v4.2" 
for merging easily

Changes in v4:
- remove "host->trans_mode" and use "host->use_dma" to indicate
transfer mode.
- remove all bt-bindings' 

Re: [PATCH 2/2] leds: rt5033: Add RT5033 Flash led device driver

[Ingi Kim]

Hello Lee Jones,

Thanks for the review.
I'll try to divide this patch and change name and comment.
Then push ver2 patch soon.

On 2015년 10월 05일 16:21, Lee Jones wrote:
> On Fri, 02 Oct 2015, Ingi Kim wrote:
> 
>> This patch adds device driver of Richtek RT5033 PMIC.
>> The driver supports a current regulated output to drive
>> white LEDs for camera flash.
>>
>> Signed-off-by: Ingi Kim 
>> ---
>>  drivers/leds/Kconfig   |   8 ++
>>  drivers/leds/Makefile  |   1 +
>>  drivers/leds/leds-rt5033.c | 222 
>> +
>>  drivers/mfd/rt5033.c   |   3 +
>>  include/linux/mfd/rt5033-private.h |  67 +--
>>  include/linux/mfd/rt5033.h |  27 -
> 
> Please pull the MFD changes out into to separate patch(es).
> 
>>  6 files changed, 317 insertions(+), 11 deletions(-)
>>  create mode 100644 drivers/leds/leds-rt5033.c
> 
> [...]
> 
>> diff --git a/drivers/mfd/rt5033.c b/drivers/mfd/rt5033.c
>> index d60f916..035421c 100644
>> --- a/drivers/mfd/rt5033.c
>> +++ b/drivers/mfd/rt5033.c
>> @@ -47,6 +47,9 @@ static const struct mfd_cell rt5033_devs[] = {
>>  }, {
>>  .name = "rt5033-battery",
>>  .of_compatible = "richtek,rt5033-battery",
>> +}, {
>> +.name = "rt5033-led",
>> +.of_compatible = "richtek,rt5033-led",
>>  },
>>  };
> 
> Needs to be in a patch of its own.
> 
>> diff --git a/include/linux/mfd/rt5033-private.h 
>> b/include/linux/mfd/rt5033-private.h
>> index 1b63fc2..21c3aff 100644
>> --- a/include/linux/mfd/rt5033-private.h
>> +++ b/include/linux/mfd/rt5033-private.h
>> @@ -25,15 +25,15 @@ enum rt5033_reg {
>>  /* Reserved 0x09~0x18 */
>>  RT5033_REG_RT_CTRL1 = 0x19,
>>  /* Reserved 0x1A~0x20 */
>> -RT5033_REG_FLED_FUNCTION1   = 0x21,
>> -RT5033_REG_FLED_FUNCTION2   = 0x22,
>> -RT5033_REG_FLED_STROBE_CTRL1= 0x23,
>> -RT5033_REG_FLED_STROBE_CTRL2= 0x24,
>> -RT5033_REG_FLED_CTRL1   = 0x25,
>> -RT5033_REG_FLED_CTRL2   = 0x26,
>> -RT5033_REG_FLED_CTRL3   = 0x27,
>> -RT5033_REG_FLED_CTRL4   = 0x28,
>> -RT5033_REG_FLED_CTRL5   = 0x29,
>> +RT5033_REG_FL_FUNCTION1 = 0x21,
>> +RT5033_REG_FL_FUNCTION2 = 0x22,
>> +RT5033_REG_FL_STROBE_CTRL1  = 0x23,
>> +RT5033_REG_FL_STROBE_CTRL2  = 0x24,
>> +RT5033_REG_FL_CTRL1 = 0x25,
>> +RT5033_REG_FL_CTRL2 = 0x26,
>> +RT5033_REG_FL_CTRL3 = 0x27,
>> +RT5033_REG_FL_CTRL4 = 0x28,
>> +RT5033_REG_FL_CTRL5 = 0x29,
> 
> Why this change?
> 
> The previous naming convention was better.
> 
>>  /* Reserved 0x2A~0x40 */
>>  RT5033_REG_CTRL = 0x41,
>>  RT5033_REG_BUCK_CTRL= 0x42,
>> @@ -93,6 +93,55 @@ enum rt5033_reg {
>>  #define RT5033_RT_CTRL1_UUG_MASK0x02
>>  #define RT5033_RT_HZ_MASK   0x01
>>  
>> +/* RT5033 FLED Function1 register */
>> +#define RT5033_FL_FLED1_MASK0x94
>> +#define RT5033_FL_STROBE_SEL0x04
>> +#define RT5033_FL_PIN_CTRL  0x10
>> +#define RT5033_FL_RESET 0x80
>> +
>> +/* RT5033 FLED Function2 register */
>> +#define RT5033_FL_FLED2_MASK0x81
>> +#define RT5033_FL_ENFLED0x01
>> +#define RT5033_FL_SREG_STROBE   0x80
>> +
>> +/* RT5033 FLED Strobe Control1 */
>> +#define RT5033_FL_STRBCTRL1_MASK0xFF
>> +#define RT5033_FL_STRBCTRL1_TM_CUR_MAX  0xE0
>> +#define RT5033_FL_STRBCTRL1_FL_CUR_DEF  0x0D
>> +#define RT5033_FL_STRBCTRL1_FL_CUR_MAX  0x1F
>> +
>> +/* RT5033 FLED Strobe Control2 */
>> +#define RT5033_FL_STRBCTRL2_MASK0x3F
>> +#define RT5033_FL_STRBCTRL2_TM_DEF  0x0F
>> +#define RT5033_FL_STRBCTRL2_TM_MAX  0x3F
>> +
>> +/* RT5033 FLED Control1 */
>> +#define RT5033_FL_CTRL1_MASK0xF7
>> +#define RT5033_FL_CTRL1_TORCH_CUR_DEF   0x20
>> +#define RT5033_FL_CTRL1_TORCH_CUR_MAX   0xF0
>> +#define RT5033_FL_CTRL1_LBP_DEF 0x02
>> +#define RT5033_FL_CTRL1_LBP_MAX 0x07
>> +
>> +/* RT5033 FLED Control2 */
>> +#define RT5033_FL_CTRL2_MASK0xFF
>> +#define RT5033_FL_CTRL2_VMID_DEF0x37
>> +#define RT5033_FL_CTRL2_VMID_MAX0x3F
>> +#define RT5033_FL_CTRL2_TRACK_ALIVE 0x40
>> +#define RT5033_FL_CTRL2_MID_TRACK   0x80
>> +
>> +/* RT5033 FLED Control4 */
>> +#define RT5033_FL_CTRL4_MASK0xE0
>> +#define RT5033_FL_CTRL4_RESV0x14
>> +#define RT5033_FL_CTRL4_VTRREG_DEF  0x40
>> +#define RT5033_FL_CTRL4_VTRREG_MAX  0x60
>> +#define RT5033_FL_CTRL4_TRACK_CLK   0x80
>> +
>> +/* RT5033 FLED Control5 */
>> +#define RT5033_FL_CTRL5_MASK0xC0
>> +#define RT5033_FL_CTRL5_RESV0x10
>> +#define RT5033_FL_CTRL5_TA_GOOD 0x40
>> +#define RT5033_FL_CTRL5_TA_EXIST0x80
>> +
>>  /* RT5033 control 

Re: [PATCH v2 1/3] iio:adc: add iio driver for Palmas (twl6035/7) gpadc

[Laxman Dewangan]

On Monday 05 October 2015 11:44 AM, H. Nikolaus Schaller wrote:

This driver code was found as:

https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc

Fixed various compilation issues and test this driver on omap5 evm.

Signed-off-by: Pradeep Goudagunta 
Signed-off-by: H. Nikolaus Schaller 
Signed-off-by: Marek Belisko 



Acked-by: Laxman Dewangan 
--
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/5] firmware: arm_scpi: Extend to support sensors

[Punit Agrawal]

Sudeep Holla  writes:

> On 15/09/15 17:50, Punit Agrawal wrote:
>> ARM System Control Processor (SCP) provides an API to query and use
>> the sensors available in the system. Extend the SCPI driver to support
>>   sensor messages.
>>
>> Signed-off-by: Punit Agrawal 
>> Cc: Sudeep Holla 
>
> Acked-by: Sudeep Holla 

Thanks, Sudeep!

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

[PATCH v4 4/5] mailbox: Add generic mechanism for testing Mailbox Controllers

[Lee Jones]

This particular Client implementation uses shared memory in order
to pass messages between Mailbox users; however, it can be easily
hacked to support any type of Controller.

Signed-off-by: Lee Jones 
---
 drivers/mailbox/Kconfig|   7 +
 drivers/mailbox/Makefile   |   2 +
 drivers/mailbox/mailbox-test.c | 361 +
 3 files changed, 370 insertions(+)
 create mode 100644 drivers/mailbox/mailbox-test.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 2cc4c39..7720bde 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -77,4 +77,11 @@ config STI_MBOX
  Mailbox implementation for STMicroelectonics family chips with
  hardware for interprocessor communication.
 
+config MAILBOX_TEST
+   tristate "Mailbox Test Client"
+   depends on OF
+   help
+ Test client to help with testing new Controller driver
+ implementations.
+
 endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 7cb4766..92435ef 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -2,6 +2,8 @@
 
 obj-$(CONFIG_MAILBOX)  += mailbox.o
 
+obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
+
 obj-$(CONFIG_ARM_MHU)  += arm_mhu.o
 
 obj-$(CONFIG_PL320_MBOX)   += pl320-ipc.o
diff --git a/drivers/mailbox/mailbox-test.c b/drivers/mailbox/mailbox-test.c
new file mode 100644
index 000..cac1ba2
--- /dev/null
+++ b/drivers/mailbox/mailbox-test.c
@@ -0,0 +1,361 @@
+/*
+ * Copyright (C) 2015 ST Microelectronics
+ *
+ * Author: Lee Jones 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MBOX_MAX_SIG_LEN   8
+#define MBOX_MAX_MSG_LEN   128
+#define MBOX_BYTES_PER_LINE16
+#define MBOX_HEXDUMP_LINE_LEN  ((MBOX_BYTES_PER_LINE * 4) + 2)
+#define MBOX_HEXDUMP_MAX_LEN   (MBOX_HEXDUMP_LINE_LEN *\
+(MBOX_MAX_MSG_LEN / MBOX_BYTES_PER_LINE))
+
+static struct dentry *root_debugfs_dir;
+
+struct mbox_test_device {
+   struct device   *dev;
+   void __iomem*mmio;
+   struct mbox_chan*tx_channel;
+   struct mbox_chan*rx_channel;
+   char*rx_buffer;
+   char*signal;
+   char*message;
+   spinlock_t  lock;
+};
+
+static ssize_t mbox_test_signal_write(struct file *filp,
+  const char __user *userbuf,
+  size_t count, loff_t *ppos)
+{
+   struct mbox_test_device *tdev = filp->private_data;
+   int ret;
+
+   if (!tdev->tx_channel) {
+   dev_err(tdev->dev, "Channel cannot do Tx\n");
+   return -EINVAL;
+   }
+
+   if (count > MBOX_MAX_SIG_LEN) {
+   dev_err(tdev->dev,
+   "Signal length %d greater than max allowed %d\n",
+   count, MBOX_MAX_SIG_LEN);
+   return -EINVAL;
+   }
+
+   tdev->signal = kzalloc(MBOX_MAX_SIG_LEN, GFP_KERNEL);
+   if (!tdev->signal)
+   return -ENOMEM;
+
+   ret = copy_from_user(tdev->signal, userbuf, count);
+   if (ret) {
+   kfree(tdev->signal);
+   return -EFAULT;
+   }
+
+   return ret < 0 ? ret : count;
+}
+
+static const struct file_operations mbox_test_signal_ops = {
+   .write  = mbox_test_signal_write,
+   .open   = simple_open,
+   .llseek = generic_file_llseek,
+};
+
+static ssize_t mbox_test_message_write(struct file *filp,
+  const char __user *userbuf,
+  size_t count, loff_t *ppos)
+{
+   struct mbox_test_device *tdev = filp->private_data;
+   void *data;
+   int ret;
+
+   if (!tdev->tx_channel) {
+   dev_err(tdev->dev, "Channel cannot do Tx\n");
+   return -EINVAL;
+   }
+
+   if (count > MBOX_MAX_MSG_LEN) {
+   dev_err(tdev->dev,
+   "Message length %d greater than max allowed %d\n",
+   count, MBOX_MAX_MSG_LEN);
+   return -EINVAL;
+   }
+
+   tdev->message = kzalloc(MBOX_MAX_MSG_LEN, GFP_KERNEL);
+   if (!tdev->message)
+   return -ENOMEM;
+
+   ret = copy_from_user(tdev->message, userbuf, count);
+   if (ret) {
+   ret = -EFAULT;
+   goto out;
+   }
+
+   /*
+* A separate signal is only of use if there is
+* MMIO to subsequently pass the message through
+*/
+   if 

[PATCH v4 2/5] mailbox: Add support for ST's Mailbox IP

[Lee Jones]

ST's platforms currently support a maximum of 5 Mailboxes, one for
each of the supported co-processors situated on the platform.  Each
Mailbox is divided up into 4 instances which consist of 32 channels.
Messages are passed between the application and co-processors using
shared memory areas.  It is the Client's responsibility to manage
these areas.

Signed-off-by: Lee Jones 
---
 drivers/mailbox/Kconfig   |   7 +
 drivers/mailbox/Makefile  |   2 +
 drivers/mailbox/mailbox-sti.c | 516 ++
 3 files changed, 525 insertions(+)
 create mode 100644 drivers/mailbox/mailbox-sti.c

diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index e269f08..2cc4c39 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -70,4 +70,11 @@ config BCM2835_MBOX
  the services of the Videocore. Say Y here if you want to use the
  BCM2835 Mailbox.
 
+config STI_MBOX
+   tristate "STI Mailbox framework support"
+   depends on ARCH_STI && OF
+   help
+ Mailbox implementation for STMicroelectonics family chips with
+ hardware for interprocessor communication.
+
 endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index 8e6d822..7cb4766 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -13,3 +13,5 @@ obj-$(CONFIG_PCC) += pcc.o
 obj-$(CONFIG_ALTERA_MBOX)  += mailbox-altera.o
 
 obj-$(CONFIG_BCM2835_MBOX) += bcm2835-mailbox.o
+
+obj-$(CONFIG_STI_MBOX) += mailbox-sti.o
diff --git a/drivers/mailbox/mailbox-sti.c b/drivers/mailbox/mailbox-sti.c
new file mode 100644
index 000..b1618d2
--- /dev/null
+++ b/drivers/mailbox/mailbox-sti.c
@@ -0,0 +1,516 @@
+/*
+ * STi Mailbox
+ *
+ * Copyright (C) 2015 ST Microelectronics
+ *
+ * Author: Lee Jones  for ST Microelectronics
+ *
+ * Based on the original driver written by;
+ *   Alexandre Torgue, Olivier Lebreton and Loic Pallardy
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "mailbox.h"
+
+#define STI_MBOX_INST_MAX  4  /* RAM saving: Max supported instances */
+#define STI_MBOX_CHAN_MAX  20 /* RAM saving: Max supported channels  */
+
+#define STI_IRQ_VAL_OFFSET 0x04   /* Read interrupt status   */
+#define STI_IRQ_SET_OFFSET 0x24   /* Generate a Tx channel interrupt */
+#define STI_IRQ_CLR_OFFSET 0x44   /* Clear pending Rx interrupts */
+#define STI_ENA_VAL_OFFSET 0x64   /* Read enable status  */
+#define STI_ENA_SET_OFFSET 0x84   /* Enable a channel*/
+#define STI_ENA_CLR_OFFSET 0xa4   /* Disable a channel   */
+
+#define MBOX_BASE(mdev, inst)   ((mdev)->base + (inst * 4))
+
+/**
+ * STi Mailbox device data
+ *
+ * An IP Mailbox is currently composed of 4 instances
+ * Each instance is currently composed of 32 channels
+ * This means that we have 128 channels per Mailbox
+ * A channel an be used for TX or RX
+ *
+ * @dev:   Device to which it is attached
+ * @mbox:  Representation of a communication channel controller
+ * @base:  Base address of the register mapping region
+ * @name:  Name of the mailbox
+ * @enabled:   Local copy of enabled channels
+ * @lock:  Mutex protecting enabled status
+ */
+struct sti_mbox_device {
+   struct device   *dev;
+   struct mbox_controller  *mbox;
+   void __iomem*base;
+   const char  *name;
+   u32 enabled[STI_MBOX_INST_MAX];
+   spinlock_t  lock;
+   booltxonly;
+};
+
+/**
+ * STi Mailbox platform specfic configuration
+ *
+ * @num_inst:  Maximum number of instances in one HW Mailbox
+ * @num_chan:  Maximum number of channel per instance
+ */
+struct sti_mbox_pdata {
+   unsigned intnum_inst;
+   unsigned intnum_chan;
+};
+
+/**
+ * STi Mailbox allocated channel information
+ *
+ * @mdev:  Pointer to parent Mailbox device
+ * @instance:  Instance number channel resides in
+ * @channel:   Channel number pertaining to this container
+ */
+struct sti_channel {
+   struct sti_mbox_device  *mdev;
+   unsigned intinstance;
+   unsigned intchannel;
+};
+
+static inline bool sti_mbox_channel_is_enabled(struct mbox_chan *chan)
+{
+   struct sti_channel *chan_info = chan->con_priv;
+   struct sti_mbox_device *mdev = chan_info->mdev;
+   unsigned int instance = chan_info->instance;
+   unsigned int channel = chan_info->channel;
+
+   return mdev->enabled[instance] & 

[PATCH v4 1/5] mailbox: dt: Supply bindings for ST's Mailbox IP

[Lee Jones]

Signed-off-by: Lee Jones 
---
 .../devicetree/bindings/mailbox/sti-mailbox.txt| 52 ++
 1 file changed, 52 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/sti-mailbox.txt

diff --git a/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt 
b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
new file mode 100644
index 000..9fb4400
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
@@ -0,0 +1,52 @@
+ST Microelectronics Mailbox Driver
+
+Each ST Mailbox IP currently consists of 4 instances of 32 channels.  Messages
+are passed between Application and Remote processors using shared memory.
+
+Controller
+--
+
+Required properties:
+- compatible   : Should be "st,stih407-mailbox"
+- reg  : Offset and length of the device's register set
+- mbox-name: Name of the mailbox
+- #mbox-cells: : Must be 2
+ < instance channel direction>
+   phandle   : Label name of controller
+   instance  : Instance number
+   channel   : Channel number
+
+Optional properties
+- interrupts   : Contains the IRQ line for a Rx mailbox
+- tx-only  : Denotes Mailbox cannot receive messages
+
+Example:
+
+mailbox0: mailbox@0  {
+   compatible  = "st,stih407-mailbox";
+   reg = <0x08f0 0x1000>;
+   interrupts  = ;
+   #mbox-cells = <2>;
+   mbox-name   = "a9";
+};
+
+Client
+--
+
+Required properties:
+- compatible   : Many (See the client docs)
+- reg  : Shared (between Application and Remote) memory address
+- mboxes   : Standard property to specify a Mailbox (See 
./mailbox.txt)
+ Cells must match 'mbox-cells' (See Controller docs 
above)
+
+Optional properties
+- mbox-names   : Name given to channels seen in the 'mboxes' property.
+
+Example:
+
+mailbox_test {
+   compatible  = "mailbox_test";
+   reg = <0x[shared_memory_address], [shared_memory_size]>;
+   mboxes  = < 0 1>, < 2 1>;
+   mbox-names  = "tx", "rx";
+};
-- 
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 v4] QEMU fw_cfg DMA interface documentation

[Marc Marí]

On Mon, 5 Oct 2015 09:20:55 +0100
Stefan Hajnoczi  wrote:

> On Thu, Oct 1, 2015 at 1:15 PM, Marc Marí  wrote:
> > +Additionaly, if the DMA interface is available then a read to the
> > DMA Address +will return 0x51454d5520434647 ("QEMU CFG" in
> > big-endian format).
> 
> What does this mean?
>

https://www.mail-archive.com/qemu-devel@nongnu.org/msg325546.html

Proposed by Kevin O'Connor in v3.

(I could not find this thread in gnu.org or gmane archives. It's
strange).

Thanks
Marc
--
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] ARM: dts: sun4i: USB DRC and voltage-scaling for pcDuino1/2

[Maxime Ripard]

Hi,

On Sun, Oct 04, 2015 at 09:58:45PM +0300, Siarhei Siamashka wrote:
> Hello,
> 
> This brings LinkSprite pcDuino1/2 boards up to date with the latest
> kernel features. And the first patch in this set is a bugfix for the
> PH3/PH6 pins misuse.
> 
> There is currently a single dts file for pcDuino1 and pcDuino2 boards.
> They obviously had been designed to be compatible with each other, but
> have some minor differences, as can be seen when comparing schematics:
> https://s3.amazonaws.com/pcduino/Hardware/PC+Duino_V01-20130128.pdf
> https://s3.amazonaws.com/pcduino/Hardware/v2/pcDuino_v2_sch.pdf

Usually, the way we handle this is simply by including just the other
DT that will only hold those differences.

What are those differences exactly ?

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

[PATCH v4 0/5] Mailbox: Provide support STi based platforms

[Lee Jones]

Hi Jassi,

This should be it.  Exciting times!

ST's platforms currently support a maximum of 5 Mailboxes, one for
each of the supported co-processors situated on the platform.  Each
Mailbox is divided up into 4 instances which consist of 32 channels.
Messages are passed between the application and co-processors using
shared memory areas.

Also included in the set is an example Client which should be generic
enough to use as a testing environment for all Mailbox IPs which use
shared memory or the API to pass messages.  With small changes, it
should also be able to test more extravagant implementations.

v3 -> v4:
 - More protection in MBOX_BASE() MACRO
 - Remove unused tx-only marker

v2 => v3:
 - Controller
   - Shared (DT <=> Device Driver) defines removed
   - Return actual error codes instead of NULL in xlate()
   - Not passing 'direction' configuration via DT anymore
 - Removed all accompanying configuration checking code
 - Test F/W
   - Allow Rx-only and Tx-only controllers to be tested
   - Cater for controllers requiring pre-Tx 'signal' to be sent
   - Supply 'wr-' message debugfs file
 - When written to, will Tx message through Mailbox Framework
 - When read from, will print out a hexdump of Rx'ed message

v1 => v2:
 - New MACRO() to obtain base address for a given instance
 - Move locking into the structure it protects
 - Stop checking for 'ready' state when sending data
 - Don't clear channel data (that belongs to the API)
 - #define register offsets instead of providing via pdata
 - Register driver with module_platform_driver()

Lee Jones (5):
  mailbox: dt: Supply bindings for ST's Mailbox IP
  mailbox: Add support for ST's Mailbox IP
  ARM: STi: stih407-family: Add nodes for Mailbox
  mailbox: Add generic mechanism for testing Mailbox Controllers
  ARM: STi: DT: STiH407: Enable Mailbox testing facility

 .../devicetree/bindings/mailbox/sti-mailbox.txt|  52 +++
 arch/arm/boot/dts/stih407-family.dtsi  |  42 ++
 drivers/mailbox/Kconfig|  14 +
 drivers/mailbox/Makefile   |   4 +
 drivers/mailbox/mailbox-sti.c  | 516 +
 drivers/mailbox/mailbox-test.c | 361 ++
 6 files changed, 989 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mailbox/sti-mailbox.txt
 create mode 100644 drivers/mailbox/mailbox-sti.c
 create mode 100644 drivers/mailbox/mailbox-test.c

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

Info

[WUMT]

You have won the sum of 1,729,500 USD in our online promo. Contact with 
Name, Address, Telephone Number and Occupation for claims.

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

Re: [PATCH v2 5/7] hwrng: st: Add support for ST's HW Random Number Generator

[Lee Jones]

On Mon, 05 Oct 2015, Daniel Thompson wrote:
> On 05/10/15 13:11, Lee Jones wrote:
> >On Mon, 05 Oct 2015, Daniel Thompson wrote:
> >>Late but...
> >
> >That's okay.  Fixup patches can always be submitted.
> >
> >We have forever. :)
> >
> >>On 17/09/15 14:45, Lee Jones wrote:
> >>>diff --git a/drivers/char/hw_random/Makefile 
> >>>b/drivers/char/hw_random/Makefile
> >>>index 055bb01..8bcfb45 100644
> >>>--- a/drivers/char/hw_random/Makefile
> >>>+++ b/drivers/char/hw_random/Makefile
> >>>@@ -30,4 +30,5 @@ obj-$(CONFIG_HW_RANDOM_TPM) += tpm-rng.o
> >>>  obj-$(CONFIG_HW_RANDOM_BCM2835) += bcm2835-rng.o
> >>>  obj-$(CONFIG_HW_RANDOM_IPROC_RNG200) += iproc-rng200.o
> >>>  obj-$(CONFIG_HW_RANDOM_MSM) += msm-rng.o
> >>>+obj-$(CONFIG_HW_RANDOM_ST) += st-rng.o
> >>>  obj-$(CONFIG_HW_RANDOM_XGENE) += xgene-rng.o
> >>>diff --git a/drivers/char/hw_random/st-rng.c 
> >>>b/drivers/char/hw_random/st-rng.c
> >>>new file mode 100644
> >>>index 000..8c8a435
> >>>--- /dev/null
> >>>+++ b/drivers/char/hw_random/st-rng.c
> >>>@@ -0,0 +1,144 @@
> >>>+/*
> >>>+ * ST Random Number Generator Driver ST's Platforms
> >>>+ *
> >>>+ * Author: Pankaj Dev: 
> >>>+ * Lee Jones 
> >>>+ *
> >>>+ * Copyright (C) 2015 STMicroelectronics (R) Limited
> >>>+ *
> >>>+ * 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 
> >>>+
> >>>+/* Registers */
> >>>+#define ST_RNG_STATUS_REG 0x20
> >>>+#define ST_RNG_DATA_REG   0x24
> >>>+
> >>>+/* Registers fields */
> >>>+#define ST_RNG_STATUS_BAD_SEQUENCEBIT(0)
> >>>+#define ST_RNG_STATUS_BAD_ALTERNANCE  BIT(1)
> >>>+#define ST_RNG_STATUS_FIFO_FULL   BIT(5)
> >>>+
> >>>+#define ST_RNG_FIFO_SIZE  8
> >>>+#define ST_RNG_SAMPLE_SIZE2 /* 2 Byte (16bit) samples */
> >>>+
> >>>+/* Samples are available every 0.667us, which we round to 1us */
> >>>+#define ST_RNG_FILL_FIFO_TIMEOUT   (1 * (ST_RNG_FIFO_SIZE / 
> >>>ST_RNG_SAMPLE_SIZE))
> >>>+
> >>>+struct st_rng_data {
> >>>+  void __iomem*base;
> >>>+  struct clk  *clk;
> >>>+  struct hwrngops;
> >>>+};
> >>>+
> >>>+static int st_rng_read(struct hwrng *rng, void *data, size_t max, bool 
> >>>wait)
> >>>+{
> >>>+  struct st_rng_data *ddata = (struct st_rng_data *)rng->priv;
> >>>+  u32 status;
> >>>+  int i;
> >>>+
> >>>+  if (max < sizeof(u16))
> >>>+  return -EINVAL;
> >>>+
> >>>+  /* Wait until FIFO is full - max 4uS*/
> >>>+  for (i = 0; i < ST_RNG_FILL_FIFO_TIMEOUT; i++) {
> >>>+  status = readl_relaxed(ddata->base + ST_RNG_STATUS_REG);
> >>>+  if (status & ST_RNG_STATUS_FIFO_FULL)
> >>>+  break;
> >>>+  udelay(1);
> >>
> >>How much bandwidth does using udelay() cost? I think it could be
> >>>10% compared to a tighter polling loop.
> >
> >Samples are only available every 0.7uS and we only do this for every
> >4.  The maximum it could 'cost' is <1uS.  Do we really want to fuss
> >over that tiny amount of time?  It's an understandable point if we
> >were talking about milliseconds, but a single microsecond?
> 
> This code is called in a tight loop so we're not talking about a
> *single* microsecond! We are are talking about about one microsecond
> in every five[1] and yes, I think we should care about that.
> 
> It takes 2.67uS for the FIFO to come ready so with a polling
> interval of 1uS + loop overhead so I would fully expect on average
> to "waste" 0.5uS each time st_rng_read() is called (in a tight
> loop).
> 
> [1]... point three recurring  ;-)

`time dd if=/dev/hwrng of=/dev/null bs=1 count=10M`

/* Current code, inc delay */
Run 1: real 0m17.996s
Run 2: real 0m17.991s
Run 3: real 0m17.996s
Run 4: real 0m18.000s
Run 5: real 0m18.000s
Total   0m89.983s

/* Tight loop, no delay */
Run 1: real 0m18.011s
Run 2: real 0m17.995s
Run 3: real 0m18.005s
Run 4: real 0m18.020s
Run 5: real 0m17.990s
Total   0m90.021s

(89.983 / 90.021) * 100 = 99.958%

0.042% saving.

Not quite the >10% predicted.  I'd say that's negligible. 

> >>>+  }
> >>>+
> >>>+  if (i == ST_RNG_FILL_FIFO_TIMEOUT)
> >>>+  return 0;
> >>
> >>Isn't a timeout an error condition?
> >
> >Yes, which is why we're returning 0.  In this context 0 == 'no data'.
> >This will be converted to -EAGAIN if the caller did not request
> >NONBLOCKING.
> 
> I took the view that hitting the timeout means the hardware is
> broken. Is it likely that the next time we call it there will be
> data ready? If it is should it be trusted?

>From experience gained whilst testing, I can say that when returning
an error the HNG breaks and the user receives an error.  If instead we
return 0, we get to have another go and random numbers again pour

[PATCH] regulator: max77802: Add input supply properties to DT binding doc

[Javier Martinez Canillas]

The max77802 regulator driver defines the supply name for each regulator
so these can be described in DT but is not mentioned in the binding doc.

Signed-off-by: Javier Martinez Canillas 

---

 .../devicetree/bindings/regulator/max77802.txt | 23 +-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/regulator/max77802.txt 
b/Documentation/devicetree/bindings/regulator/max77802.txt
index 79e5476444f7..b466689c47ea 100644
--- a/Documentation/devicetree/bindings/regulator/max77802.txt
+++ b/Documentation/devicetree/bindings/regulator/max77802.txt
@@ -8,7 +8,26 @@ regulators that can be controlled over I2C.
 
 Following properties should be present in main device node of the MFD chip.
 
-Optional node:
+Optional properties:
+- inb1-supply:  The input supply for BUCK1
+- inb2-supply:  The input supply for BUCK2
+- inb3-supply:  The input supply for BUCK3
+- inb4-supply:  The input supply for BUCK4
+- inb5-supply:  The input supply for BUCK5
+- inb6-supply:  The input supply for BUCK6
+- inb7-supply:  The input supply for BUCK7
+- inb8-supply:  The input supply for BUCK8
+- inb9-supply:  The input supply for BUCK9
+- inb10-supply: The input supply for BUCK10
+- inl1-supply:  The input supply for LDO8 and LDO15
+- inl2-supply:  The input supply for LDO17, LDO27, LDO30 and LDO35
+- inl3-supply:  The input supply for LDO3, LDO5, LDO6 and LDO7
+- inl4-supply:  The input supply for LDO10, LDO11, LDO13 and LDO14
+- inl5-supply:  The input supply for LDO9 and LDO19
+- inl6-supply:  The input supply for LDO4, LDO21, LDO24 and LDO33
+- inl7-supply:  The input supply for LDO18, LDO20, LDO28 and LDO29
+- inl9-supply:  The input supply for LDO12, LDO23, LDO25, LDO26, LDO32 and 
LDO34
+- inl10-supply: The input supply for LDO1 and LDO2
 - regulators : The regulators of max77802 have to be instantiated
   under subnode named "regulators" using the following format.
 
@@ -58,6 +77,8 @@ Example:
#address-cells = <1>;
#size-cells = <0>;
 
+   inb1-supply = <_reg>;
+
regulators {
ldo1_reg: LDO1 {
regulator-name = "vdd_1v0";
-- 
2.4.3

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

Re: [PATCH v2 2/2] ASoC: atmel-i2s: add driver for the new Atmel I2S controller

[Mark Brown]

On Tue, Sep 29, 2015 at 04:09:20PM +0200, Cyrille Pitchen wrote:

> + if (pending & ATMEL_I2SC_INT_RXOR) {
> + mask = ATMEL_I2SC_SR_RXOR;
> +
> + for (ch = 0; ch < ATMEL_I2SC_MAX_TDM_CHANNELS; ++ch)
> + if (sr & ATMEL_I2SC_SR_RXORCH(ch)) {
> + mask |= ATMEL_I2SC_SR_RXORCH(ch);
> + dev_err(dev->dev,
> + "RX overrun on channel %d\n", ch);
> + }
> + regmap_write(dev->regmap, ATMEL_I2SC_SCR, mask);
> + }

Coding style - the for loop needs { } for legibility.

> + if (pending & ATMEL_I2SC_INT_TXUR) {
> + mask = ATMEL_I2SC_SR_TXUR;
> +
> + for (ch = 0; ch < ATMEL_I2SC_MAX_TDM_CHANNELS; ++ch)
> + if (sr & ATMEL_I2SC_SR_TXURCH(ch)) {
> + mask |= ATMEL_I2SC_SR_TXURCH(ch);
> + dev_err(dev->dev,
> + "TX underrun on channel %d\n", ch);
> + }
> + regmap_write(dev->regmap, ATMEL_I2SC_SCR, mask);
> +
> + }
> +
> + return IRQ_HANDLED;

This IRQ_HANDLED should be generated only if one of the interrupts we
know about got handled - there was a check to see if any of the unmasked
bits is set earlier on in the function but that's not quite the same
check.

> +
> +static int atmel_i2s_prepare(struct snd_pcm_substream *substream,
> +  struct snd_soc_dai *dai)
> +{
> + struct atmel_i2s_dev *dev = snd_soc_dai_get_drvdata(dai);
> + bool is_playback = (substream->stream == SNDRV_PCM_STREAM_PLAYBACK);
> + unsigned int rhr, sr = 0;
> +
> + if (is_playback) {
> + regmap_read(dev->regmap, ATMEL_I2SC_SR, );
> + if (sr & ATMEL_I2SC_SR_RXRDY) {
> + dev_dbg(dev->dev, "RXRDY is set\n");
> + regmap_read(dev->regmap, ATMEL_I2SC_RHR, );
> + }
> + }

What's this doing?  It just seems to do two reads and issue a debug
message...

> +static int atmel_i2s_sama5d2_mck_init(struct atmel_i2s_dev *dev,
> +   struct device_node *np)
> +{
> + #define SFR_I2SCLKSEL 0x90U
> + struct regmap *sfr;
> + int id;
> +
> + id = of_alias_get_id(np, "i2s");
> + if (id < 0) {
> + dev_err(dev->dev, "failed to get alias ID\n");
> + return id;
> + }
> + if (id > 1) {
> + dev_err(dev->dev, "invalid I2S controller ID: %d\n", id);
> + return -EINVAL;
> + }

This didn't appear in the DT binding and looks pretty funky - what's
going on here?

> + sfr = syscon_regmap_lookup_by_compatible("atmel,sama5d2-sfr");
> + if (IS_ERR(sfr)) {
> + dev_err(dev->dev, "failed to get SFR syscon\n");
> + return PTR_ERR(sfr);
> + }

This didn't appear in the binding either.

> + /* Get hardware capabilities. */
> + match = of_match_node(atmel_i2s_dt_ids, np);
> + dev->caps = match ? match->data : NULL;

Please don't abuse the ternery operator like this, just write a normal
if statement :/


signature.asc
Description: Digital signature

Re: [PATCH v7 1/2] pwm: Add device tree binding document for R-Car PWM Timer

[Thierry Reding]

On Wed, Sep 30, 2015 at 05:47:52PM +0900, Yoshihiro Shimoda wrote:
> Add binding document for Renesas PWM Timer on R-Car SoCs.
> 
> Signed-off-by: Yoshihiro Shimoda 
> Acked-by: Geert Uytterhoeven 
> Reviewed-by: Simon Horman 
> ---
>  .../devicetree/bindings/pwm/renesas,pwm-rcar.txt   | 27 
> ++
>  1 file changed, 27 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt

Applied, thanks.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH v4 0/2] pwm: Broadcom BCM7038 PWM controller (v4)

[Thierry Reding]

On Mon, Sep 14, 2015 at 04:47:04PM -0700, Florian Fainelli wrote:
> Hi,
> 
> This patch series add PWM support for the Broadcom BCM7xxx
> chips which feature one or more PWM controllers capable of
> output periods from 148ns to ~622ms using a combination of
> variable and fixed frequency settings.
> 
> The controller does not support setting a polarity.
> 
> This is based on Thierry's pwm/next branch.
> 
> Florian Fainelli (2):
>   Documentation: dt: add Broadcom BCM7038 PWM controller binding
>   pwm: Add Broadcom BCM7038 PWM controller support

I've applied both of these patches with a couple of stylistic changes.

Thanks,
Thierry


signature.asc
Description: PGP signature

[PATCH] hwrng: st: dt: Fix trivial typo in node address

[Lee Jones]

DT nodes should not append their addresses with '0x'.

Suggested-by: Stephen Boyd 
Signed-off-by: Lee Jones 
---
 Documentation/devicetree/bindings/rng/st,rng.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/rng/st,rng.txt 
b/Documentation/devicetree/bindings/rng/st,rng.txt
index dbc64e6..35734bc 100644
--- a/Documentation/devicetree/bindings/rng/st,rng.txt
+++ b/Documentation/devicetree/bindings/rng/st,rng.txt
@@ -8,7 +8,7 @@ clocks  : Phandle to device's clock (See: 
../clocks/clock-bindings.txt)
 
 Example:
 
-rng@0xfee8 {
+rng@fee8 {
compatible  = "st,rng";
reg = <0xfee8 0x1000>;
clocks  = <_sysin>;
-- 
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 3/3] mfd: sec-core: Disable buck voltage reset on watchdog falling edge

[Bartlomiej Zolnierkiewicz]

Hi,

On Friday, October 02, 2015 05:25:51 PM Krzysztof Kozlowski wrote:
> The WRSTBI bit (disabled by default but enabled by bootloader), when
> set, is responsible for resetting voltages to default values of
> certain bucks on falling edge of Warm Reset Input pin from AP.
> 
> However on some boards (with S2MPS13) the pin is pulled down so any
> suspend will effectively trigger the reset of bucks supplying the power
> to the little and big cores. In the same time when resuming, these bucks
> must provide voltage greater or equal to voltage before suspend to match
> the frequency chosen by cpufreq. If voltage (default value of voltage
> after reset) is lower than one set by cpufreq before suspend, then
> system will hang during resuming.
> 
> Signed-off-by: Krzysztof Kozlowski 

I tested this (with some additional Exynos5433 patches) and it works
like expected (suspend/resume issue is fixed).

Tested-by: Bartlomiej Zolnierkiewicz 

You could also add:

Reported-by: Bartlomiej Zolnierkiewicz 

(since the issue got narrowed down and reported to you by me :).

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

> ---
>  drivers/mfd/sec-core.c  | 26 ++
>  include/linux/mfd/samsung/core.h|  2 ++
>  include/linux/mfd/samsung/s2mps13.h |  1 +
>  3 files changed, 29 insertions(+)
> 
> diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
> index 589e5efc2d7f..2626fc0b5b8c 100644
> --- a/drivers/mfd/sec-core.c
> +++ b/drivers/mfd/sec-core.c
> @@ -262,6 +262,29 @@ static void sec_pmic_dump_rev(struct sec_pmic_dev 
> *sec_pmic)
>   dev_dbg(sec_pmic->dev, "Revision: 0x%x\n", val);
>  }
>  
> +static void sec_pmic_configure(struct sec_pmic_dev *sec_pmic)
> +{
> + int err;
> +
> + if (sec_pmic->device_type != S2MPS13X)
> + return;
> +
> + if (sec_pmic->pdata->disable_wrstbi) {
> + /*
> +  * If WRSTBI pin is pulled down this feature must be disabled
> +  * because each Suspend to RAM will trigger buck voltage reset
> +  * to default values.
> +  */
> + err = regmap_update_bits(sec_pmic->regmap_pmic,
> +  S2MPS13_REG_WRSTBI,
> +  S2MPS13_REG_WRSTBI_MASK, 0x0);
> + if (err)
> + dev_warn(sec_pmic->dev,
> +  "Cannot initialize WRSTBI config: %d\n",
> +  err);
> + }
> +}
> +
>  #ifdef CONFIG_OF
>  /*
>   * Only the common platform data elements for s5m8767 are parsed here from 
> the
> @@ -289,6 +312,8 @@ static struct sec_platform_data 
> *sec_pmic_i2c_parse_dt_pdata(
>  
>   pd->manual_poweroff = of_property_read_bool(dev->of_node,
>   "samsung,s2mps11-acokb-ground");
> + pd->disable_wrstbi = of_property_read_bool(dev->of_node,
> + 
> "samsung,s2mps11-wrstbi-ground");
>   return pd;
>  }
>  #else
> @@ -434,6 +459,7 @@ static int sec_pmic_probe(struct i2c_client *i2c,
>   goto err_mfd;
>  
>   device_init_wakeup(sec_pmic->dev, sec_pmic->wakeup);
> + sec_pmic_configure(sec_pmic);
>   sec_pmic_dump_rev(sec_pmic);
>  
>   return ret;
> diff --git a/include/linux/mfd/samsung/core.h 
> b/include/linux/mfd/samsung/core.h
> index aa78957e092f..a06098639399 100644
> --- a/include/linux/mfd/samsung/core.h
> +++ b/include/linux/mfd/samsung/core.h
> @@ -134,6 +134,8 @@ struct sec_platform_data {
>   int buck4_init;
>   /* Whether or not manually set PWRHOLD to low during shutdown. */
>   boolmanual_poweroff;
> + /* Disable the WRSTBI (buck voltage warm reset) when probing? */
> + booldisable_wrstbi;
>  };
>  
>  /**
> diff --git a/include/linux/mfd/samsung/s2mps13.h 
> b/include/linux/mfd/samsung/s2mps13.h
> index b1fd675fa36f..239e977ba45d 100644
> --- a/include/linux/mfd/samsung/s2mps13.h
> +++ b/include/linux/mfd/samsung/s2mps13.h
> @@ -184,5 +184,6 @@ enum s2mps13_regulators {
>   * Let's assume that default value will be set.
>   */
>  #define S2MPS13_BUCK_RAMP_DELAY  12500
> +#define S2MPS13_REG_WRSTBI_MASK  BIT(5)
>  
>  #endif /*  __LINUX_MFD_S2MPS13_H */

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

Re: [PATCH v7 2/2] pwm: Add support for R-Car PWM Timer

[Thierry Reding]

On Wed, Sep 30, 2015 at 05:47:53PM +0900, Yoshihiro Shimoda wrote:
> This patch adds support for R-Car SoCs PWM Timer. The PWM timer of
> R-Car H2 has 7 channels. So, we can use the channels if we describe
> device tree nodes.
> 
> Signed-off-by: Yoshihiro Shimoda 
> Reviewed-by: Simon Horman 
> ---
>  drivers/pwm/Kconfig|  11 ++
>  drivers/pwm/Makefile   |   1 +
>  drivers/pwm/pwm-rcar.c | 266 
> +
>  3 files changed, 278 insertions(+)
>  create mode 100644 drivers/pwm/pwm-rcar.c

Applied (with some bikeshedding changes squashed in), thanks.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH v3 13/13] scsi: ufs: Add exynos ufs platform data

[Alim Akhtar]

Hi Rob,

On Mon, Oct 5, 2015 at 7:41 PM, Rob Herring  wrote:
> On Mon, Oct 5, 2015 at 4:06 AM, Arnd Bergmann  wrote:
>> On Monday 05 October 2015 13:44:29 Alim Akhtar wrote:
>>> CCing Rob Herring,
>>>
>>> Hi Arnd,
>>>
>>> On 10/01/2015 04:59 PM, Arnd Bergmann wrote:
>>> > On Thursday 01 October 2015 18:46:34 kbuild test robot wrote:
>>> >> [auto build test results on v4.3-rc3 -- if it's inappropriate base, 
>>> >> please ignore]
>>> >>
>>> >> config: x86_64-allmodconfig (attached as .config)
>>> >> reproduce:
>>> >>  git checkout 6e153e3bf7c68b019e987c5a0ffadebd9c7d4fbb
>>> >>  # save the attached .config to linux build tree
>>> >>  make ARCH=x86_64
>>> >>
>>> >> All error/warnings (new ones prefixed by >>):
>>> >>
>>>  ERROR: "ufs_hba_exynos_ops" [drivers/scsi/ufs/ufshcd-pltfrm.ko] 
>>>  undefined!
>>> >>
>>> >>
>>> >
>>> > Ah, this seems to be a case of layering violation. It would be best to
>>> > restructure the code so that the exynos driver registers a platform_driver
>>> > by itself for the respective DT compatible string, and then calls
>>> > into the common code from its probe function, rather than having the
>>> > generic driver know about the specific backends.
>>> >
>>> > That approach will also make the generic driver more scalable as we
>>> > add further chip-specific variations, and matches what we do in other
>>> > drivers.
>>> >
>>>
>>> Looks like some discussions on ufs variant driver probe method happened
>>> here [1] few months back.
>>> [1]-> https://lkml.org/lkml/2015/6/3/180
>>
>> Hmm, too bad we didn't catch it then, it's much more work to fix now.
>
> What you suggested is what is being implemented[1]. It is not merged
> yet. The core is a library and the platform specific parts create the
> driver.
>
> Rob
>
> [1] https://lkml.org/lkml/2015/9/2/364

Thanks for the pointer...let me have a look. At least now we have
another variant to test it out.

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



-- 
Regards,
Alim
--
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 1/9] Input: goodix - sort includes alphabetically

[Tirdea, Irina]

> -Original Message-
> From: Pavel Machek [mailto:pa...@ucw.cz]
> Sent: 04 October, 2015 22:47
> To: Tirdea, Irina
> Cc: Dmitry Torokhov; Bastien Nocera; Aleksei Mamlin; 
> linux-in...@vger.kernel.org; Mark Rutland; Purdila, Octavian; linux-
> ker...@vger.kernel.org; devicetree@vger.kernel.org
> Subject: Re: [PATCH v5 1/9] Input: goodix - sort includes alphabetically
> 
> On Mon 2015-09-07 17:36:15, Irina Tirdea wrote:
> > Signed-off-by: Irina Tirdea 
> > ---
> >  drivers/input/touchscreen/goodix.c | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> Don't.
> 
> Yes, we sometimes sort includes... to avoid patch rejects.
> 
> This is guaranteed to cause rejects.
> 
> If we do sort them, we use "longest-first" usually.
> 

When using random order, I've been told by reviewers that my ordering
is wrong [1], but I could not figure out what the "right" ordering is in order 
to apply.
I did not find any mention of how to sort includes in  
Documentation/CodingStyle,
but I've seen patches in the kernel that fix random ordering by sorting them
alphabetically [2].

However, I do not feel strongly about this so I can drop this patch.

Thanks,
Irina

[1] https://lkml.org/lkml/2015/5/28/363
[2] https://patchwork.ozlabs.org/patch/408022/

> >
> > diff --git a/drivers/input/touchscreen/goodix.c 
> > b/drivers/input/touchscreen/goodix.c
> > index e36162b..6ae28c5 100644
> > --- a/drivers/input/touchscreen/goodix.c
> > +++ b/drivers/input/touchscreen/goodix.c
> > @@ -14,18 +14,18 @@
> >   * Software Foundation; version 2 of the License.
> >   */
> >
> > -#include 
> > +#include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> > -#include 
> > -#include 
> >  #include 
> > -#include 
> > -#include 
> > +#include 
> > +#include 
> > +#include 
> >  #include 
> > +#include 
> >  #include 
> >
> >  struct goodix_ts_data {
> > --
> > 1.9.1
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/3] iio:adc:palmas: add DT support

[H. Nikolaus Schaller]

Am 05.10.2015 um 13:17 schrieb Mark Rutland :

> On Sun, Oct 04, 2015 at 06:05:59PM +0200, H. Nikolaus Schaller wrote:
>> From: Marek Belisko 
>> 
>> Code was found at:
>> https://android.googlesource.com/kernel/tegra/+/a90856a6626d502d42c6e7abccbdf9d730b36270%5E%21/#F1
>> 
>> Signed-off-by: Laxman Dewangan 
>> [Fixed minor typos + add channels list to documentation]
>> Signed-off-by: Marek Belisko 
>> ---
>> .../devicetree/bindings/iio/adc/palmas-gpadc.txt   | 46 +++
>> drivers/iio/adc/palmas_gpadc.c | 52 
>> +++---
>> 2 files changed, 93 insertions(+), 5 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
>> 
>> diff --git a/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt 
>> b/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
>> new file mode 100644
>> index 000..2149afe
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
>> @@ -0,0 +1,46 @@
>> +* Palmas general purpose ADC IP block devicetree bindings
>> +
>> +Channels list:
>> +0 battery type
>> +1 battery temp NTC (optional current source)
>> +2 GP
>> +3 temp (with ext. diode, optional current source)
>> +4 GP
>> +5 GP
>> +6 VBAT_SENSE
>> +7 VCC_SENSE
>> +8 Backup Battery voltage
>> +9 external charger (VCHG)
>> +10 VBUS
>> +11 DC-DC current probe (how does this work?)
>> +12 internal die temp
>> +13 internal die temp
>> +14 USB ID pin voltage
>> +15 test network
>> +
>> +Required properties:
>> +- compatible : Must be "ti,palmas-gpadc".
>> +
>> +Optional sub-nodes:
>> +ti,channel0-current-microamp: Channel 0 current in uA.
>> +Values are rounded to derive 0uA, 5uA, 15uA, 20uA.
>> +ti,channel3-current-microamp: Channel 3 current in uA.
>> +Valid are rounded to derive 0uA, 10uA, 400uA, 800uA.
> 
> It's only possible to configure channels 0 and 3 in this manner?

Yes. The other channels have no built-in current source, i.e. these
channels are special.

> 
>> +ti,enable-extended-delay: Enable extended delay.
> 
> What is this? When would I select it? Why does it belong in the DT
> rather than being a runtime option?

The chip allows to extend the time window between channel selection
and sampling by 400µs (according to data sheet). But for all channels
and not each one. As far as I understand, this is - depending on hardware
setup - to get more stable ADC readings.

Most channels have a fixed function (e.g. battery voltage, USB VBUS,
temperature NTC) so it can't be arbitrarily chosen and depends on how
the Palmas is embedded (it is a PMIC with a bank of ADCs and not a
general purpose ADC chip).

So I think it is really a hardware dependent parameter and not something
the user should be able to change.

> 
>> +Example:
>> +
>> +pmic {
>> +compatible = "ti,twl6035-pmic", "ti,palmas-pmic";
>> +...
>> +gpadc {
>> +compatible = "ti,palmas-gpadc";
>> +interrupts = <18 0
>> +  16 0
>> +  17 0>;
>> +ti,channel0-current-microamp = <5>;
>> +ti,channel3-current-microamp = <10>;
>> +};
>> +};
>> +...
>> +};
> 
> I thought you needed #iio-cells for encoding the channel?

Yes, we forgot (we don't have a client for it in our setup yet - so did not 
test :)

> 
> Mark.

Thanks,
Nikolaus Schaller

--
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] dma: Add Freescale qDMA engine driver support

[Vinod Koul]

On Fri, Sep 11, 2015 at 01:53:52PM +0800, Yuan Yao wrote:

> +Examples:
> +
> + qdma: qdma@839 {
> + compatible = "fsl,ls-qdma";
> + reg = <0x0 0x838 0x0 0x2>;
> + interrupts = ,
> + ;
> + interrupt-names = "qdma-tx", "qdma-err";
> + big-endian;
> + channels = <1>;
> + };

Binding should be a separate patch

> +FREESCALE qDMA DRIVER
> +M: Yuan Yao 
> +L: linux-arm-ker...@lists.infradead.org

not dmaengine ML ?


> +config FSL_QDMA
> + tristate "Freescale qDMA engine support"
> + select DMA_ENGINE
> + select DMA_VIRTUAL_CHANNELS

No depends on arch, can it work on x86?

> +static int fsl_qdma_alloc_chan_resources(struct dma_chan *chan)
> +{
> + struct fsl_qdma_chan *fsl_chan = to_fsl_qdma_chan(chan);
> +
> + fsl_chan->desc = NULL;
> + return 0;
> +}

why do you need this it seems to do nothing

> +static struct fsl_qdma_desc *fsl_qdma_alloc_desc(struct fsl_qdma_chan 
> *fsl_chan)
> +{
> + struct fsl_qdma_desc *fsl_desc;
> +
> + fsl_desc = kzalloc(sizeof(*fsl_desc), GFP_NOWAIT);
> +

empty line here is not required

> + if (!fsl_desc)
> + return NULL;
> +
> + fsl_desc->qchan = fsl_chan;
> +
> + return fsl_desc;

why not return fsl_desc->qchan ;


> + dma_cap_set(DMA_PRIVATE, fsl_qdma->dma_dev.cap_mask);
> + dma_cap_set(DMA_SLAVE, fsl_qdma->dma_dev.cap_mask);
> + dma_cap_set(DMA_MEMCPY, fsl_qdma->dma_dev.cap_mask);
> +
> + fsl_qdma->dma_dev.dev = >dev;
> + fsl_qdma->dma_dev.device_alloc_chan_resources
> + = fsl_qdma_alloc_chan_resources;
> + fsl_qdma->dma_dev.device_free_chan_resources
> + = fsl_qdma_free_chan_resources;
> + fsl_qdma->dma_dev.device_tx_status = fsl_qdma_tx_status;
> + fsl_qdma->dma_dev.device_prep_dma_memcpy = fsl_qdma_prep_memcpy;
> + fsl_qdma->dma_dev.device_issue_pending = fsl_qdma_issue_pending;

You claim DMA_SLAVE but no prep_ for that?

> +
> +static int __init fsl_qdma_init(void)
> +{
> + return platform_driver_register(_qdma_driver);
> +}
> +subsys_initcall(fsl_qdma_init);
why subsys_init?

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

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

[Bharat Kumar Gogada]

On Thursday 01 October 2015 14:29:21 Bharat Kumar Gogada wrote:
> Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
> 
> Signed-off-by: Bharat Kumar Gogada 
> Signed-off-by: Ravi Kiran Gummaluri 
> ---
> Removed unneccessary comments
> Modified setup_sspl implementation
> Added more details in binding Documentation
> ---
>  .../devicetree/bindings/pci/xilinx-nwl-pcie.txt|   49 +
>  drivers/pci/host/Kconfig   |9 +
>  drivers/pci/host/Makefile  |1 +
>  drivers/pci/host/pcie-xilinx-nwl.c | 1029 
> 
>  4 files changed, 1088 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
>  create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c
> 
> diff --git a/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt 
> b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
> new file mode 100644
> index 000..ed87184
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
> @@ -0,0 +1,49 @@
> +* Xilinx NWL PCIe Root Port Bridge DT description
> +
> +Required properties:
> +- compatible: Should contain "xlnx,nwl-pcie-2.11"
> +- #address-cells: Address representation for root ports, set to <3>
> +- #size-cells: Size representation for root ports, set to <2>
> +- #interrupt-cells: specifies the number of cells needed to encode an
> + interrupt source. The value must be 1.
> +- reg: Should contain Bridge, PCIe Controller registers location,
> + configuration sapce, and length
> +- reg-names: Must include the following entries:
> + "breg": bridge registers
> + "pcireg": PCIe controller registers
> + "cfg": configuration space region
> +- device_type: must be "pci"
> +- interrupts: Should contain NWL PCIe interrupt
> +- interrupt-names: Must include the following entries:
> + "misc": interrupt asserted when miscellaneous is recieved
> + "intx": interrupt that is asserted when an legacy interrupt is received
> + "msi_1, msi_0": interrupt asserted when msi is recieved

The msi and intx interrupts don't really belong here: For intx, please use an 
interrupt-map property as the other host drivers do.

For MSI, the usual answer is that there should be a separate device node for 
the MSI controller, and an msi-parent property in the PCI host.
Our current GIC version does not have separate msi controller, so is it 
necessary to have separate msi node ?

This lets you use the same code for hosts that have a GICv2m or GICv3 that 
comes with its own MSI controller.

> +/**
> + * struct nwl_pcie - PCIe port information
> + *
> + * @dev: Device pointer
> + * @breg_base: IO Mapped Bridge Register Base
> + * @pcireg_base: IO Mapped PCIe controller attributes
> + * @ecam_base: IO Mapped configuration space
> + * @phys_breg_base: Physical Bridge Register Base
> + * @phys_pcie_reg_base: Physical PCIe Controller Attributes
> + * @phys_ecam_base: Physical Configuration Base
> + * @breg_size: Bridge Register space
> + * @pcie_reg_size: PCIe controller attributes space
> + * @ecam_size: PCIe Configuration space
> + * @irq_intx: Legacy interrupt number
> + * @irq_misc: Misc interrupt number
> + * @ecam_value: ECAM value
> + * @last_busno: Last Bus number configured
> + * @link_up: Link status flag
> + * @enable_msi_fifo: Enable MSI FIFO mode
> + * @bus: PCI bus
> + * @msi: MSI interrupt info
> + */
> +struct nwl_pcie {
> + struct device *dev;
> + void __iomem *breg_base;
> + void __iomem *pcireg_base;
> + void __iomem *ecam_base;
> + u32 phys_breg_base;
> + u32 phys_pcie_reg_base;
> + u32 phys_ecam_base;

These should probably be phys_addr_t.

> + * nwl_setup_sspl - Set Slot Power limit
> + *
> + * @pcie: PCIe port information
> + */
> +static int nwl_setup_sspl(struct nwl_pcie *pcie) {
> + unsigned int status;
> + int retval = 0;
> +
> + do {
> + status = nwl_bridge_readl(pcie, TX_PCIE_MSG) & MSG_BUSY_BIT;
> + if (!status) {
> + /*
> +  * Generate the TLP message for a single EP
> +  * [TODO] Add a multi-endpoint code
> +  */
> + nwl_bridge_writel(pcie, 0x0,
> +   TX_PCIE_MSG + TX_PCIE_MSG_CNTL);
> + nwl_bridge_writel(pcie, 0x0,
> +   TX_PCIE_MSG + TX_PCIE_MSG_SPEC_LO);
> + nwl_bridge_writel(pcie, 0x0,
> +   TX_PCIE_MSG + TX_PCIE_MSG_SPEC_HI);
> + nwl_bridge_writel(pcie, 0x0,
> +   TX_PCIE_MSG + TX_PCIE_MSG_DATA);
> + /* Pattern to generate SSLP TLP */
> + nwl_bridge_writel(pcie, PATTRN_SSLP_TLP,
> +   TX_PCIE_MSG + TX_PCIE_MSG_CNTL);
> + 

Re: [PATCH v3 13/13] scsi: ufs: Add exynos ufs platform data

[Arnd Bergmann]

On Monday 05 October 2015 09:11:33 Rob Herring wrote:
> On Mon, Oct 5, 2015 at 4:06 AM, Arnd Bergmann  wrote:
> > On Monday 05 October 2015 13:44:29 Alim Akhtar wrote:
> >>
> >> On 10/01/2015 04:59 PM, Arnd Bergmann wrote:
> >> > On Thursday 01 October 2015 18:46:34 kbuild test robot wrote:
> >> > Ah, this seems to be a case of layering violation. It would be best to
> >> > restructure the code so that the exynos driver registers a 
> >> > platform_driver
> >> > by itself for the respective DT compatible string, and then calls
> >> > into the common code from its probe function, rather than having the
> >> > generic driver know about the specific backends.
> >> >
> >> > That approach will also make the generic driver more scalable as we
> >> > add further chip-specific variations, and matches what we do in other
> >> > drivers.
> >> >
> >>
> >> Looks like some discussions on ufs variant driver probe method happened
> >> here [1] few months back.
> >> [1]-> https://lkml.org/lkml/2015/6/3/180
> >
> > Hmm, too bad we didn't catch it then, it's much more work to fix now.
> 
> What you suggested is what is being implemented[1]. It is not merged
> yet. The core is a library and the platform specific parts create the
> driver.
> 
> Rob
> 
> [1] https://lkml.org/lkml/2015/9/2/364

Ah, good. Sorry for the misunderstanding on my side.

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