date:20150128

The Snow board has a MMC/SDIO wifi chip that is always powered but it
needs a power sequence involving a reset (active low) and an enable
(active high) pins. Both pins are marked as active low since the MMC
simple power sequence driver asserts the pins prior to the card power
up procedure and de-asserts the pins after the card has been powered.

So the reset line will be left de-asserted and the enable pin will be
left asserted.

The chip also needs an external 32kHz reference clock to be operational
that is by the MAX77686 PMIC clock.

Add a simple MMC power sequence provider for the wifi MMC/SDIO slot.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
 arch/arm/boot/dts/exynos5250-snow.dts | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index b9aeec430527..0f7971ba8238 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -229,6 +229,13 @@
power-supply = fet6;
backlight = backlight;
};
+
+   mmc3_pwrseq: mmc3_pwrseq {
+   reset-gpios = gpx0 2 GPIO_ACTIVE_LOW, /* WIFI_RSTn */
+ gpx0 1 GPIO_ACTIVE_LOW; /* WIFI_EN */
+   clocks = max77686 MAX77686_CLK_PMIC;
+   clock-names = ext_clock;
+   };
 };
 
 dp {
@@ -531,17 +538,33 @@
status = okay;
num-slots = 1;
broken-cd;
+   cap-sdio-irq;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
samsung,dw-mshc-ddr-timing = 1 2;
pinctrl-names = default;
-   pinctrl-0 = sd3_clk sd3_cmd sd3_bus4;
+   pinctrl-0 = sd3_clk sd3_cmd sd3_bus4 wifi_en wifi_rst;
bus-width = 4;
cap-sd-highspeed;
+   mmc-pwrseq = mmc3_pwrseq;
 };
 
 pinctrl_0 {
+   wifi_en: wifi-en {
+   samsung,pins = gpx0-1;
+   samsung,pin-function = 1;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
+
+   wifi_rst: wifi-rst {
+   samsung,pins = gpx0-2;
+   samsung,pin-function = 1;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
+
power_key_irq: power-key-irq {
samsung,pins = gpx1-3;
samsung,pin-function = 0xf;
-- 
2.1.3

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

[PATCH v2 4/6] mmc: pwrseq_simple: Add optional reference clock support

Some WLAN chips attached to a SDIO interface, need a reference clock.

Since this is very common, extend the prseq_simple driver to support
an optional clock that is enabled prior the card power up procedure.

Note: the external clock is optional. Thus an error is not returned
if the clock is not found.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---

Changes since v1:
 - Rebase on top of latest changes.
 - Use IS_ERR() instead of checking for NULL to see if the clock exists.
---
 drivers/mmc/core/pwrseq_simple.c | 34 --
 1 file changed, 32 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/core/pwrseq_simple.c b/drivers/mmc/core/pwrseq_simple.c
index e53d3c7e059c..5e34c77efa5e 100644
--- a/drivers/mmc/core/pwrseq_simple.c
+++ b/drivers/mmc/core/pwrseq_simple.c
@@ -7,6 +7,7 @@
  *
  *  Simple MMC power sequence management
  */
+#include linux/clk.h
 #include linux/kernel.h
 #include linux/slab.h
 #include linux/device.h
@@ -20,6 +21,7 @@
 
 struct mmc_pwrseq_simple {
struct mmc_pwrseq pwrseq;
+   struct clk *ext_clk;
int nr_gpios;
struct gpio_desc *reset_gpios[0];
 };
@@ -39,6 +41,9 @@ static void mmc_pwrseq_simple_pre_power_on(struct mmc_host 
*host)
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
 
+   if (!IS_ERR(pwrseq-ext_clk))
+   clk_prepare_enable(pwrseq-ext_clk);
+
mmc_pwrseq_simple_set_gpios_value(pwrseq, 1);
 }
 
@@ -50,6 +55,17 @@ static void mmc_pwrseq_simple_post_power_on(struct mmc_host 
*host)
mmc_pwrseq_simple_set_gpios_value(pwrseq, 0);
 }
 
+static void mmc_pwrseq_simple_power_off(struct mmc_host *host)
+{
+   struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
+   struct mmc_pwrseq_simple, pwrseq);
+
+   mmc_pwrseq_simple_set_gpios_value(pwrseq, 1);
+
+   if (!IS_ERR(pwrseq-ext_clk))
+   clk_disable_unprepare(pwrseq-ext_clk);
+}
+
 static void mmc_pwrseq_simple_free(struct mmc_host *host)
 {
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
@@ -60,6 +76,9 @@ static void mmc_pwrseq_simple_free(struct mmc_host *host)
if (!IS_ERR(pwrseq-reset_gpios[i]))
gpiod_put(pwrseq-reset_gpios[i]);
 
+   if (!IS_ERR(pwrseq-ext_clk))
+   clk_put(pwrseq-ext_clk);
+
kfree(pwrseq);
host-pwrseq = NULL;
 }
@@ -67,7 +86,7 @@ static void mmc_pwrseq_simple_free(struct mmc_host *host)
 static struct mmc_pwrseq_ops mmc_pwrseq_simple_ops = {
.pre_power_on = mmc_pwrseq_simple_pre_power_on,
.post_power_on = mmc_pwrseq_simple_post_power_on,
-   .power_off = mmc_pwrseq_simple_pre_power_on,
+   .power_off = mmc_pwrseq_simple_power_off,
.free = mmc_pwrseq_simple_free,
 };
 
@@ -85,6 +104,14 @@ int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct 
device *dev)
if (!pwrseq)
return -ENOMEM;
 
+   pwrseq-ext_clk = clk_get(dev, ext_clock);
+   if (IS_ERR(pwrseq-ext_clk) 
+   PTR_ERR(pwrseq-ext_clk) != -ENOENT 
+   PTR_ERR(pwrseq-ext_clk) != -ENOSYS) {
+   ret = PTR_ERR(pwrseq-ext_clk);
+   goto free;
+   }
+
for (i = 0; i  nr_gpios; i++) {
pwrseq-reset_gpios[i] = gpiod_get_index(dev, reset, i,
 GPIOD_OUT_HIGH);
@@ -96,7 +123,7 @@ int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct 
device *dev)
while (--i)
gpiod_put(pwrseq-reset_gpios[i]);
 
-   goto free;
+   goto clk_put;
}
}
 
@@ -105,6 +132,9 @@ int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct 
device *dev)
host-pwrseq = pwrseq-pwrseq;
 
return 0;
+clk_put:
+   if (!IS_ERR(pwrseq-ext_clk))
+   clk_put(pwrseq-ext_clk);
 free:
kfree(pwrseq);
return ret;
-- 
2.1.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 net-next v8 0/4] net: Add Keystone NetCP ethernet driver support


On 01/28/2015 01:20 PM, Murali Karicheri wrote:

On 01/28/2015 12:43 PM, Murali Karicheri wrote:

On 01/28/2015 11:49 AM, Murali Karicheri wrote:

On 01/27/2015 05:28 PM, Arnd Bergmann wrote:

On Tuesday 20 January 2015 10:53:36 Murali Karicheri wrote:

On 01/19/2015 03:11 PM, David Miller wrote:

From: Murali Karicherim-kariche...@ti.com
Date: Thu, 15 Jan 2015 19:10:03 -0500


The Network Coprocessor (NetCP) is a hardware accelerator that
processes
Ethernet packets. NetCP has a gigabit Ethernet (GbE) subsystem with
a ethernet
switch sub-module to send and receive packets. NetCP also includes
a packet
accelerator (PA) module to perform packet classification operations
such as
header matching, and packet modification operations such as checksum
generation. NetCP can also optionally include a Security
Accelerator(SA)
capable of performing IPSec operations on ingress/egress packets.

Keystone SoC's also have a 10 Gigabit Ethernet Subsystem (XGbE)
which
includes a 3-port Ethernet switch sub-module capable of 10Gb/s and
1Gb/s rates per Ethernet port.

Both GBE and XGBE network processors supported using common
driver. It
is also designed to handle future variants of NetCP.


Series applied to net-next, thanks.

David,

Thanks a lot for applying this series. This helps us move forward to
work on the next set of patches.


Hi Murali,

Building an ARM 'allmodconfig' kernel now runs into two separate
problems
from your driver:

- you have two module_init() instances in one module, which conflict.

- you have two files that are linked into more than one module, so
building
both TI_CPSW and TI_KEYSTONE_NETCP in the same kernel fails.

The answer to both of these is probably to have separate loadable
modules,
but you might be able to come up with a different solution.

Arnd,

Thanks for letting us know. We will look into this.

How do I reproduce this? Is there a defconfig used for allmodconfig? I
am unable to find one. Any details to reproduce this will be useful.


Ok I think I found it.

I did this with next-next branch and it seems to work. I will make
kernel build to reproduce this.

make ARCH=arm allmodconfig
make uImage;

I am building it now.

Arnd,

I see allmodconfig configure NetCP driver as module. My uImage build
from net-next branch went through fine. I am building modules right now
and should show error as you have pointed out. Let me know if you any
issues on how I am working to reproduce the issue (wrong branch, wrong
/incomplete commands etc. I have my CROSS_COMPILE and ARCH set in my
env). Want to reproduce this so as to make sure my fix is addressing
this. Hope I am on the right track.


Reproduced this. Following errors seen when building the modules.

  LD [M]  drivers/net/ethernet/ti/keystone_netcp.o
drivers/net/ethernet/ti/netcp_ethss.o: In function `init_module':
netcp_ethss.c:(.init.text+0x0): multiple definition of `init_module'
drivers/net/ethernet/ti/netcp_core.o:netcp_core.c:(.init.text+0x0): 
first defined here

drivers/net/ethernet/ti/netcp_ethss.o: In function `cleanup_module':
netcp_ethss.c:(.exit.text+0x0): multiple definition of `cleanup_module'
drivers/net/ethernet/ti/netcp_core.o:netcp_core.c:(.exit.text+0x0): 
first defined here

make[4]: *** [drivers/net/ethernet/ti/keystone_netcp.o] Error 1


BTW, I had to disable cpsw_ale.c to get to build keystone NetCP. I am 
assuming someone from TI is addressing this.


drivers/net/ethernet/ti/cpsw_ale.c: In function ‘cpsw_ale_start’:
drivers/net/ethernet/ti/cpsw_ale.c:759:2: error: ‘KBUILD_MODNAME’ 
undeclared (first use in this function)
drivers/net/ethernet/ti/cpsw_ale.c:759:2: note: each undeclared 
identifier is reported only once for each function it appears in


Murali



Thanks

Murali


Murali

Thanks.

Murali


Arnd












--
Murali Karicheri
Linux Kernel, Texas Instruments
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] mmc: pwrseq: Add support to multiple gpios in pwrseq simple



On 28/01/15 13:35, Ulf Hansson wrote:

On 28 January 2015 at 14:16, Srinivas Kandagatla
srinivas.kandaga...@linaro.org wrote:

This patchset adds support to reset/powerup multiple gpio pins on a given
sdio bus. The use case is simple, on sdio we could have multiple devices
like WLAN, BT which are controlled by there own reset lines. So having
multiple reset is something more useful in such cases.

Without this patch I could not get BT and WLAN working at same time on IFC6410.

Thanks,
srini

Srinivas Kandagatla (2):
   mmc: pwrseq: Add support to control multiple gpios in simple pwrseq
   mmc: pwrseq: Update document with multiple gpios support

  .../devicetree/bindings/mmc/mmc-pwrseq-simple.txt  |  7 ++-
  drivers/mmc/core/pwrseq_simple.c   | 64 +++---
  2 files changed, 49 insertions(+), 22 deletions(-)

--
1.9.1



Hi Srinivas,

I noticed that Javier a few hours ago posted a patchset which
implement the same thing as yours, I guess this is a wanted feature.
:-)

yes.



I am going to review Javier's patchset, would be nice if you could
have a look at it as well.

Sure.. they look very similar..

!!!  Should have sent my patches yesterday :-)


Kind regards
Uffe


--
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/6] Add multiple GPIO and external clock to MMC pwrseq_simple

Hello Ulf,

Many WLAN chips attached to an SDIO interface needs more than one GPIO
for their reset sequence and also an external clock to be operational.

Since this is very common, this series extend the simple MMC power sequence
to support more than one reset GPIO and also an optional external clock.

This is the second version of the series that addressed issues pointed out
by Arend van Spriel and Srinivas Kandagatla.

The series depend on v4 mmc: core: Add support for MMC power sequences:

http://comments.gmane.org/gmane.linux.kernel.mmc/30665

Javier Martinez Canillas (6):
  mmc: pwrseq: Document that simple sequence support more than one GPIO
  mmc: pwrseq_simple: Extend to support more pins
  mmc: pwrseq: Document optional clock for the simple power sequence
  mmc: pwrseq_simple: Add optional reference clock support
  ARM: dts: exynos5250-snow: Enable wifi power-on
  ARM: dts: exynos5250-snow: Add cap-sdio-irq to wifi mmc node

 .../devicetree/bindings/mmc/mmc-pwrseq-simple.txt  | 11 ++-
 arch/arm/boot/dts/exynos5250-snow.dts  | 26 ++-
 drivers/mmc/core/pwrseq_simple.c   | 85 ++
 3 files changed, 103 insertions(+), 19 deletions(-)

Patch #1 extends the simple MMC power sequence DT binding to support more
than one GPIO and patch #2 adds the actual implementation.

In the same way, patch #3 and #4 extend the simple MMC power sequence DT
binding and pwrseq_simple driver to support an optional external clock.

Finally as an example, patch #5 and patch #6 adds support for the wifi
chip in the Exynos5250 Snow that needs all these resources. These two
patches were added to the series only for completeness.

Best regards,
Javier
--
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 4/5] mmc: pwrseq_simple: Add optional reference clock support

Some WLAN chips attached to a SDIO interface, need a reference clock.

Since this is very common, extend the prseq_simple driver to support
an optional clock that is enabled prior the card power up procedure.

Note, the external clock is optional. Thus an error is not returned
if the clock is not found.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
 drivers/mmc/core/pwrseq_simple.c | 33 -
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/core/pwrseq_simple.c b/drivers/mmc/core/pwrseq_simple.c
index 9e51fe1051c5..5ef6db7323f3 100644
--- a/drivers/mmc/core/pwrseq_simple.c
+++ b/drivers/mmc/core/pwrseq_simple.c
@@ -7,6 +7,7 @@
  *
  *  Simple MMC power sequence management
  */
+#include linux/clk.h
 #include linux/kernel.h
 #include linux/slab.h
 #include linux/device.h
@@ -16,12 +17,14 @@
 
 #include linux/mmc/host.h
 
+#include core.h
 #include pwrseq.h
 
 struct mmc_pwrseq_simple {
struct mmc_pwrseq pwrseq;
struct gpio_desc **reset_gpio;
int nr_gpios;
+   struct clk *ext_clk;
 };
 
 static void mmc_pwrseq_simple_pre_power_on(struct mmc_host *host)
@@ -30,6 +33,9 @@ static void mmc_pwrseq_simple_pre_power_on(struct mmc_host 
*host)
struct mmc_pwrseq_simple, pwrseq);
int i;
 
+   if (pwrseq-ext_clk)
+   clk_prepare_enable(pwrseq-ext_clk);
+
for (i = 0; i  pwrseq-nr_gpios; i++)
if (!IS_ERR(pwrseq-reset_gpio[i]))
gpiod_set_value_cansleep(pwrseq-reset_gpio[i], 1);
@@ -46,12 +52,29 @@ static void mmc_pwrseq_simple_post_power_on(struct mmc_host 
*host)
gpiod_set_value_cansleep(pwrseq-reset_gpio[i], 0);
 }
 
+static void mmc_pwrseq_simple_power_off(struct mmc_host *host)
+{
+   struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
+   struct mmc_pwrseq_simple, pwrseq);
+   int i;
+
+   for (i = 0; i  pwrseq-nr_gpios; i++)
+   if (!IS_ERR(pwrseq-reset_gpio[i]))
+   gpiod_set_value_cansleep(pwrseq-reset_gpio[i], 1);
+
+   if (pwrseq-ext_clk)
+   clk_disable_unprepare(pwrseq-ext_clk);
+}
+
 static void mmc_pwrseq_simple_free(struct mmc_host *host)
 {
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
int i;
 
+   if (pwrseq-ext_clk)
+   clk_put(pwrseq-ext_clk);
+
if (pwrseq-nr_gpios  0) {
for (i = 0; i  pwrseq-nr_gpios; i++)
if (!IS_ERR(pwrseq-reset_gpio[i]))
@@ -66,7 +89,7 @@ static void mmc_pwrseq_simple_free(struct mmc_host *host)
 static struct mmc_pwrseq_ops mmc_pwrseq_simple_ops = {
.pre_power_on = mmc_pwrseq_simple_pre_power_on,
.post_power_on = mmc_pwrseq_simple_post_power_on,
-   .power_off = mmc_pwrseq_simple_pre_power_on,
+   .power_off = mmc_pwrseq_simple_power_off,
.free = mmc_pwrseq_simple_free,
 };
 
@@ -97,6 +120,14 @@ int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct 
device *dev)
}
}
 
+   pwrseq-ext_clk = clk_get(dev, ext_clock);
+   if (IS_ERR(pwrseq-ext_clk) 
+   PTR_ERR(pwrseq-ext_clk) != -ENOENT 
+   PTR_ERR(pwrseq-ext_clk) != -ENOSYS) {
+   ret = PTR_ERR(pwrseq-ext_clk);
+   goto free;
+   }
+
pwrseq-pwrseq.ops = mmc_pwrseq_simple_ops;
host-pwrseq = pwrseq-pwrseq;
 
-- 
2.1.3

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

[PATCH v2 5/6] ARM: dts: exynos5250-snow: Enable wifi power-on

The Snow board has a MMC/SDIO wifi chip that is always powered but it
needs a power sequence involving a reset (active low) and an enable
(active high) pins. Both pins are marked as active low since the MMC
simple power sequence driver asserts the pins prior to the card power
up procedure and de-asserts the pins after the card has been powered.

So the reset line will be left de-asserted and the enable pin will be
left asserted.

The chip also needs an external 32kHz reference clock to be operational
that is by the MAX77686 PMIC clock.

Add a simple MMC power sequence provider for the wifi MMC/SDIO slot.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---

Changes since v1:
 - Remove cap-sdio-irq from mmc3 dev node since is a separate change.
   Suggested by Arend van Spriel.
---
 arch/arm/boot/dts/exynos5250-snow.dts | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index b9aeec430527..b78712058903 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -229,6 +229,14 @@
power-supply = fet6;
backlight = backlight;
};
+
+   mmc3_pwrseq: mmc3_pwrseq {
+   compatible = mmc-pwrseq-simple;
+   reset-gpios = gpx0 2 GPIO_ACTIVE_LOW, /* WIFI_RSTn */
+ gpx0 1 GPIO_ACTIVE_LOW; /* WIFI_EN */
+   clocks = max77686 MAX77686_CLK_PMIC;
+   clock-names = ext_clock;
+   };
 };
 
 dp {
@@ -536,12 +544,27 @@
samsung,dw-mshc-sdr-timing = 2 3;
samsung,dw-mshc-ddr-timing = 1 2;
pinctrl-names = default;
-   pinctrl-0 = sd3_clk sd3_cmd sd3_bus4;
+   pinctrl-0 = sd3_clk sd3_cmd sd3_bus4 wifi_en wifi_rst;
bus-width = 4;
cap-sd-highspeed;
+   mmc-pwrseq = mmc3_pwrseq;
 };
 
 pinctrl_0 {
+   wifi_en: wifi-en {
+   samsung,pins = gpx0-1;
+   samsung,pin-function = 1;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
+
+   wifi_rst: wifi-rst {
+   samsung,pins = gpx0-2;
+   samsung,pin-function = 1;
+   samsung,pin-pud = 0;
+   samsung,pin-drv = 0;
+   };
+
power_key_irq: power-key-irq {
samsung,pins = gpx1-3;
samsung,pin-function = 0xf;
-- 
2.1.3

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

Re: [PATCH v7 0/2] watchdog: ImgTec PDC Watchdog Timer Driver

2015-01-28 Thread Ezequiel Garcia



On 01/28/2015 03:57 PM, Guenter Roeck wrote:
 On Wed, Jan 28, 2015 at 03:39:22PM -0300, Ezequiel Garcia wrote:
 On 01/20/2015 10:59 AM, Guenter Roeck wrote:
 On 01/20/2015 03:13 AM, Ezequiel Garcia wrote:
 Hi Wim,

 On 01/06/2015 10:19 AM, Ezequiel Garcia wrote:
 Here's the seventh round for IMG PDC Watchdog driver.
 The series is based on v3.19-rc3.


 Guenter has reviewed both patches. Do you think you can review this
 soonishly and let me know if you have more comments?


 I'll send a pull request to Wim either this or next week.


 Guenter,

 I hate to be so spammy here. Do you still plan to send a pull request?

 Yes. Sorry for the delay.
 

OK, no problem, was just checking.

Thanks a lot for taking care of this!
-- 
Ezequiel
--
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/7] ALSA: pcm: Add snd_interval_ranges() and snd_pcm_hw_constraint_ranges()

2015-01-28 Thread Takashi Iwai

At Wed, 28 Jan 2015 15:16:06 +0100,
Peter Rosin wrote:
 
 From: Peter Rosin p...@axentia.se
 
 Add helper functions to allow drivers to specify several disjoint
 ranges for a variable. In particular, there is a codec (PCM512x) that
 has a hole in its supported range of rates, due to PLL and divider
 restrictions.
 
 This is like snd_pcm_hw_constraint_list(), but for ranges instead of
 points.
 
 Signed-off-by: Peter Rosin p...@axentia.se
 Reviewed-by: Lars-Peter Clausen l...@metafoo.de

Mark, feel free to take my ack if you carry this with other patches
through your tree.
  Reviewed-by: Takashi Iwai ti...@suse.de


thanks,

Takashi

 ---
  include/sound/pcm.h  |   12 +++
  sound/core/pcm_lib.c |   85 
 ++
  2 files changed, 97 insertions(+)
 
 diff --git a/include/sound/pcm.h b/include/sound/pcm.h
 index 1e7f74acc2ec..04fc037e0555 100644
 --- a/include/sound/pcm.h
 +++ b/include/sound/pcm.h
 @@ -275,6 +275,12 @@ struct snd_pcm_hw_constraint_list {
   unsigned int mask;
  };
  
 +struct snd_pcm_hw_constraint_ranges {
 + unsigned int count;
 + const struct snd_interval *ranges;
 + unsigned int mask;
 +};
 +
  struct snd_pcm_hwptr_log;
  
  struct snd_pcm_runtime {
 @@ -910,6 +916,8 @@ void snd_interval_mulkdiv(const struct snd_interval *a, 
 unsigned int k,
 const struct snd_interval *b, struct snd_interval *c);
  int snd_interval_list(struct snd_interval *i, unsigned int count,
 const unsigned int *list, unsigned int mask);
 +int snd_interval_ranges(struct snd_interval *i, unsigned int count,
 + const struct snd_interval *list, unsigned int mask);
  int snd_interval_ratnum(struct snd_interval *i,
   unsigned int rats_count, struct snd_ratnum *rats,
   unsigned int *nump, unsigned int *denp);
 @@ -934,6 +942,10 @@ int snd_pcm_hw_constraint_list(struct snd_pcm_runtime 
 *runtime,
  unsigned int cond,
  snd_pcm_hw_param_t var,
  const struct snd_pcm_hw_constraint_list *l);
 +int snd_pcm_hw_constraint_ranges(struct snd_pcm_runtime *runtime,
 +  unsigned int cond,
 +  snd_pcm_hw_param_t var,
 +  const struct snd_pcm_hw_constraint_ranges *r);
  int snd_pcm_hw_constraint_ratnums(struct snd_pcm_runtime *runtime, 
 unsigned int cond,
 snd_pcm_hw_param_t var,
 diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c
 index ec9e7866177f..446c00bd908b 100644
 --- a/sound/core/pcm_lib.c
 +++ b/sound/core/pcm_lib.c
 @@ -1015,6 +1015,60 @@ int snd_interval_list(struct snd_interval *i, unsigned 
 int count,
  
  EXPORT_SYMBOL(snd_interval_list);
  
 +/**
 + * snd_interval_ranges - refine the interval value from the list of ranges
 + * @i: the interval value to refine
 + * @count: the number of elements in the list of ranges
 + * @ranges: the ranges list
 + * @mask: the bit-mask to evaluate
 + *
 + * Refines the interval value from the list of ranges.
 + * When mask is non-zero, only the elements corresponding to bit 1 are
 + * evaluated.
 + *
 + * Return: Positive if the value is changed, zero if it's not changed, or a
 + * negative error code.
 + */
 +int snd_interval_ranges(struct snd_interval *i, unsigned int count,
 + const struct snd_interval *ranges, unsigned int mask)
 +{
 + unsigned int k;
 + struct snd_interval range_union;
 + struct snd_interval range;
 +
 + if (!count) {
 + snd_interval_none(i);
 + return -EINVAL;
 + }
 + snd_interval_any(range_union);
 + range_union.min = UINT_MAX;
 + range_union.max = 0;
 + for (k = 0; k  count; k++) {
 + if (mask  !(mask  (1  k)))
 + continue;
 + snd_interval_copy(range, ranges[k]);
 + if (snd_interval_refine(range, i)  0)
 + continue;
 + if (snd_interval_empty(range))
 + continue;
 +
 + if (range.min  range_union.min) {
 + range_union.min = range.min;
 + range_union.openmin = 1;
 + }
 + if (range.min == range_union.min  !range.openmin)
 + range_union.openmin = 0;
 + if (range.max  range_union.max) {
 + range_union.max = range.max;
 + range_union.openmax = 1;
 + }
 + if (range.max == range_union.max  !range.openmax)
 + range_union.openmax = 0;
 + }
 + return snd_interval_refine(i, range_union);
 +}
 +EXPORT_SYMBOL(snd_interval_ranges);
 +
  static int snd_interval_step(struct snd_interval *i, unsigned int step)
  {
   unsigned int n;
 @@ -1221,6 +1275,37 @@ int snd_pcm_hw_constraint_list(struct

[PATCH 3/5] mmc: pwrseq: Document optional clock for the simple power sequence

Some WLAN chips attached to a SDIO interface, need an external clock
to be operational. Since this is very common, extend the simple MMC
power sequence DT binding to support an optional clock.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
 Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt 
b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
index 9a77deb164c7..6b5c10d1144c 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
@@ -11,6 +11,10 @@ Optional properties:
 - reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are 
asserted
at initialization and prior we start the power up procedure of the card.
Will be de-asserted right after the power has been provided to the card.
+- clocks : Must contain an entry for the entry in clock-names.
+  See ../clocks/clock-bindings.txt for details.
+- clock-names : Must include the following entry:
+  ext_clock (External clock provided to the card).
 
 Example:
 
-- 
2.1.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 3/3] ARM: dts: add property for maximum ADC clock frequencies

2015-01-28 Thread Jonathan Cameron

On 20/01/15 16:02, Stefan Agner wrote:
 The ADC clock frequency is limited depending on modes used. Add
 device tree property which allow to set the mode used and the
 maximum frequency ratings for the instance. These allows to
 set the ADC clock to a frequency which is within specification
 according to the actual mode used.
 
 Signed-off-by: Stefan Agner ste...@agner.ch
This should have been sent to the devicetree list and maintainers
in the first place.  Now cc'd.
 ---
  Documentation/devicetree/bindings/iio/adc/vf610-adc.txt | 9 +
  arch/arm/boot/dts/vfxxx.dtsi| 4 
  2 files changed, 13 insertions(+)
 
 diff --git a/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt 
 b/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt
 index 1a4a43d..3eb40e2 100644
 --- a/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt
 +++ b/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt
 @@ -11,6 +11,13 @@ Required properties:
  - clock-names: Must contain adc, matching entry in the clocks property.
  - vref-supply: The regulator supply ADC reference voltage.
  
 +Recommended properties:
 +- fsl,adck-max-frequency: Maximum frequencies according to datasheets 
 operating
 +  requirements. Three values are required, depending on conversion mode:
 +  - Frequency in normal mode (ADLPC=0, ADHSC=0)
 +  - Frequency in high-speed mode (ADLPC=0, ADHSC=1)
 +  - Frequency in low-power mode (ADLPC=1, ADHSC=0)
 +
  Example:
  adc0: adc@4003b000 {
   compatible = fsl,vf610-adc;
 @@ -18,5 +25,7 @@ adc0: adc@4003b000 {
   interrupts = 0 53 0x04;
   clocks = clks VF610_CLK_ADC0;
   clock-names = adc;
 + fsl,adck-max-frequency = 3000, 4000,
 + 2000;
   vref-supply = reg_vcc_3v3_mcu;
  };
 diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
 index 505969a..7584e0a 100644
 --- a/arch/arm/boot/dts/vfxxx.dtsi
 +++ b/arch/arm/boot/dts/vfxxx.dtsi
 @@ -182,6 +182,8 @@
   clocks = clks VF610_CLK_ADC0;
   clock-names = adc;
   status = disabled;
 + fsl,adck-max-frequency = 3000, 4000,
 + 2000;
   };
  
   wdog@4003e000 {
 @@ -361,6 +363,8 @@
   clocks = clks VF610_CLK_ADC1;
   clock-names = adc;
   status = disabled;
 + fsl,adck-max-frequency = 3000, 4000,
 + 2000;
   };
  
   esdhc1: esdhc@400b2000 {
 

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

[PATCH 0/5] Add multiple GPIO and external clock to MMC pwrseq_simple

Hello Ulf,

Many WLAN chips attached to an SDIO interface needs more than one GPIO
for their reset sequence and also need an external clock to be operational.

Since this is very common, this series extend the simple MMC power sequence
to support more than one reset GPIO and also an optional external clock.

The series depend on v4 mmc: core: Add support for MMC power sequences:

http://comments.gmane.org/gmane.linux.kernel.mmc/30665

Javier Martinez Canillas (5):
  mmc: pwrseq: Document that simple sequence support more than one GPIO
  mmc: pwrseq_simple: Extend to support more pins
  mmc: pwrseq: Document optional clock for the simple power sequence
  mmc: pwrseq_simple: Add optional reference clock support
  ARM: dts: exynos5250-snow: Enable wifi power-on

 .../devicetree/bindings/mmc/mmc-pwrseq-simple.txt  | 10 ++-
 arch/arm/boot/dts/exynos5250-snow.dts  | 25 ++-
 drivers/mmc/core/pwrseq_simple.c   | 85 ++
 3 files changed, 103 insertions(+), 17 deletions(-)

Patch #1 extends the simple MMC power sequence DT binding to support more
than one GPIO and patch #2 adds the actual implementation.

In the same way, patch #3 and #4 extend the simple MMC power sequence DT
binding and pwrseq_simple driver to support an optional external clock.

Finally as an example, patch #5 adds support for the wifi chip in the
Exynos5250 Snow that is attached to a SDIO interface and needs all these.

Best regards,
Javier

--
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 4/7] mmc: sdhci-pxav3: Modify clock settings for the SDR50 and DDR50 modes

On 23 January 2015 at 17:46, Gregory CLEMENT
gregory.clem...@free-electrons.com wrote:
 From: Marcin Wojtas m...@semihalf.com

 According to erratum 'FE-2946959' both SDR50 and DDR50 modes require
 specific clock adjustments in SDIO3 Configuration register.

 This commit add the support of this register and for SDR50 or DDR50
 mode use it as suggested by the erratum:
 - Set the SDIO3 Clock Inv field in SDIO3 Configuration register to not
 inverted.
 - Set the Sample FeedBack Clock field to 0x1

 [gregory.clem...@free-electrons.com: port from 3.10]

 Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
 ---
  drivers/mmc/host/sdhci-pxav3.c | 60 
 --
  1 file changed, 52 insertions(+), 8 deletions(-)

 diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
 index cf017fc39143..a3ebb4404849 100644
 --- a/drivers/mmc/host/sdhci-pxav3.c
 +++ b/drivers/mmc/host/sdhci-pxav3.c
 @@ -62,6 +62,7 @@ struct sdhci_pxa {
 struct clk *clk_core;
 struct clk *clk_io;
 u8  power_mode;
 +   void __iomem *sdio3_conf_reg;
  };

  /*
 @@ -72,6 +73,14 @@ struct sdhci_pxa {
  #define SDHCI_WINDOW_BASE(i)   (0x84 + ((i)  3))
  #define SDHCI_MAX_WIN_NUM  8

 +/*
 + * Fields below belong to SDIO3 Configuration Register (third register
 + * region for the Armada 38x flavor)
 + */
 +
 +#define SDIO3_CONF_CLK_INV BIT(0)
 +#define SDIO3_CONF_SD_FB_CLK   BIT(2)
 +
  static int mv_conf_mbus_windows(struct platform_device *pdev,
 const struct mbus_dram_target_info *dram)
  {
 @@ -122,16 +131,31 @@ static int armada_38x_quirks(struct platform_device 
 *pdev,
  struct sdhci_host *host)
  {
 struct device_node *np = pdev-dev.of_node;
 +   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
 +   struct sdhci_pxa *pxa = pltfm_host-priv;
 +   struct resource *res;

 host-quirks |= SDHCI_QUIRK_MISSING_CAPS;
 -   /*
 -* According to erratum 'FE-2946959' both SDR50 and DDR50
 -* modes require specific clock adjustments in SDIO3
 -* Configuration register, if the adjustment is not done,
 -* remove them from the capabilities.
 -*/
 -   host-caps1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
 -   host-caps1 = ~(SDHCI_SUPPORT_SDR50 | SDHCI_SUPPORT_DDR50);
 +   res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
 +  conf-sdio3);
 +   if (res) {
 +   pxa-sdio3_conf_reg = devm_ioremap_resource(pdev-dev, res);
 +   if (IS_ERR(pxa-sdio3_conf_reg))
 +   return PTR_ERR(pxa-sdio3_conf_reg);
 +   } else {
 +   /*
 +* According to erratum 'FE-2946959' both SDR50 and DDR50
 +* modes require specific clock adjustments in SDIO3
 +* Configuration register, if the adjustment is not done,
 +* remove them from the capabilities.
 +*/
 +   host-caps1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
 +   host-caps1 = ~(SDHCI_SUPPORT_SDR50 | SDHCI_SUPPORT_DDR50);
 +
 +   dev_warn(pdev-dev, conf-sdio3 register not found\n);
 +   dev_warn(pdev-dev, disabling SDR50 and DDR50 modes\n);
 +   dev_warn(pdev-dev, consider updating your dtb\n);

One dev_warn() should be enough. Also I don't think checkpatch
complains about long lines for dev_warn().

 +   }

 /*
  * According to erratum 'ERR-7878951' Armada 38x SDHCI
 @@ -226,6 +250,8 @@ static void pxav3_gen_init_74_clocks(struct sdhci_host 
 *host, u8 power_mode)

  static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int 
 uhs)
  {
 +   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
 +   struct sdhci_pxa *pxa = pltfm_host-priv;
 u16 ctrl_2;

 /*
 @@ -255,6 +281,24 @@ static void pxav3_set_uhs_signaling(struct sdhci_host 
 *host, unsigned int uhs)
 break;
 }

 +   /*
 +* Update SDIO3 Configuration register according to erratum
 +* FE-2946959
 +*/
 +   if (pxa-sdio3_conf_reg) {
 +   u8 reg_val  = readb(pxa-sdio3_conf_reg);
 +
 +   if (uhs == MMC_TIMING_UHS_SDR50 ||
 +   uhs == MMC_TIMING_UHS_DDR50) {
 +   reg_val = ~SDIO3_CONF_CLK_INV;
 +   reg_val |= SDIO3_CONF_SD_FB_CLK;
 +   } else {
 +   reg_val |= SDIO3_CONF_CLK_INV;
 +   reg_val = ~SDIO3_CONF_SD_FB_CLK;
 +   }
 +   writeb(reg_val, pxa-sdio3_conf_reg);
 +   }
 +
 sdhci_writew(host, ctrl_2, SDHCI_HOST_CONTROL2);
 dev_dbg(mmc_dev(host-mmc),
 %s uhs = %d, ctrl_2 = %04X\n,
 --
 2.1.0


Kind regards
Uffe
--
To unsubscribe from this list: send the line unsubscribe devicetree

[PATCH 2/3] clocksource: versatile: adapt for Versatile AB and PB boards

The same 24MHz counter is also present on Versatile AB and PB boards, so
add the compatible string for them.

Signed-off-by: Rob Herring r...@kernel.org
Cc: Liviu Dudau liviu.du...@arm.com
Cc: Sudeep Holla sudeep.ho...@arm.com
Cc: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Cc: Daniel Lezcano daniel.lezc...@linaro.org
Cc: Thomas Gleixner t...@linutronix.de
---
 drivers/clocksource/versatile.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/versatile.c b/drivers/clocksource/versatile.c
index 2798e74..0a26d3d 100644
--- a/drivers/clocksource/versatile.c
+++ b/drivers/clocksource/versatile.c
@@ -36,5 +36,7 @@ static void __init versatile_sched_clock_init(struct 
device_node *node)
 
sched_clock_register(versatile_sys_24mhz_read, 32, 2400);
 }
-CLOCKSOURCE_OF_DECLARE(versatile, arm,vexpress-sysreg,
+CLOCKSOURCE_OF_DECLARE(vexpress, arm,vexpress-sysreg,
+  versatile_sched_clock_init);
+CLOCKSOURCE_OF_DECLARE(versatile, arm,versatile-sysreg,
   versatile_sched_clock_init);
-- 
2.1.0

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

[PATCH v2 6/6] ARM: dts: exynos5250-snow: Add cap-sdio-irq to wifi mmc node

Enabling SDIO IRQ signalling for the wifi MMC/SDIO slot
doubles the transmission transfer rate.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---

Changes since v1: None, new patch.
---
 arch/arm/boot/dts/exynos5250-snow.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index b78712058903..909edc3448d3 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -539,6 +539,7 @@
status = okay;
num-slots = 1;
broken-cd;
+   cap-sdio-irq;
card-detect-delay = 200;
samsung,dw-mshc-ciu-div = 3;
samsung,dw-mshc-sdr-timing = 2 3;
-- 
2.1.3

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

[PATCH 1/5] mmc: pwrseq: Document that simple sequence support more than one GPIO

Many SDIO/MMC attached WLAN chips need more than one ping for their reset
sequence. Extend the pwrseq_simple binding to support more than one pin.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
 Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt 
b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
index da333d9ed94c..9a77deb164c7 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
@@ -8,9 +8,9 @@ Required properties:
 - compatible : contains mmc-pwrseq-simple.
 
 Optional properties:
-- reset-gpios : contains a GPIO specifier. The reset GPIO is asserted at
-   initialization and prior we start the power up procedure of the card. It
-   will be de-asserted right after the power has been provided to the card.
+- reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are 
asserted
+   at initialization and prior we start the power up procedure of the card.
+   Will be de-asserted right after the power has been provided to the card.
 
 Example:
 
-- 
2.1.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 v4 1/6] of: iommu: add ptr to OF node arg to of_iommu_configure()

2015-01-28 Thread Will Deacon

On Wed, Jan 28, 2015 at 12:23:03PM +, Laurent Pinchart wrote:
 On Wednesday 28 January 2015 11:33:00 Will Deacon wrote:
  On Mon, Jan 26, 2015 at 06:49:01PM +, Murali Karicheri wrote:
   On 01/25/2015 08:32 AM, Laurent Pinchart wrote:
   On Friday 23 January 2015 17:32:34 Murali Karicheri wrote:
   Function of_iommu_configure() is called from of_dma_configure() to
   setup iommu ops using DT property. This API is currently used for
   platform devices for which DMA configuration (including iommu ops)
   may come from device's parent. To extend this functionality for PCI
   devices, this API need to take a parent node ptr as an argument
   instead of assuming device's parent. This is needed since for PCI, the
   dma configuration may be defined in the DT node of the root bus
   bridge's parent device. Currently only dma-range is used for PCI and
   iommu is not supported. So return error if the device is PCI.
   
   Cc: Joerg Roedelj...@8bytes.org
   Cc: Grant Likelygrant.lik...@linaro.org
   Cc: Rob Herringrobh...@kernel.org
   Cc: Bjorn Helgaasbhelg...@google.com
   Cc: Will Deaconwill.dea...@arm.com
   Cc: Russell Kingli...@arm.linux.org.uk
   Cc: Arnd Bergmanna...@arndb.de
   Cc: Suravee Suthikulpanitsuravee.suthikulpa...@amd.com
   
   Signed-off-by: Murali Karicherim-kariche...@ti.com
   ---
   
 drivers/iommu/of_iommu.c |   10 --
 drivers/of/platform.c|2 +-
 include/linux/of_iommu.h |6 --
 3 files changed, 13 insertions(+), 5 deletions(-)
   
   diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
   index af1dc6a..439235b 100644
   --- a/drivers/iommu/of_iommu.c
   +++ b/drivers/iommu/of_iommu.c
   @@ -133,19 +133,25 @@ struct iommu_ops *of_iommu_get_ops(struct
   device_node *np)
   return ops;
}
   
   -struct iommu_ops *of_iommu_configure(struct device *dev)
   +struct iommu_ops *of_iommu_configure(struct device *dev,
   +struct device_node *iommu_np)
{
   struct of_phandle_args iommu_spec;
   struct device_node *np;
   struct iommu_ops *ops = NULL;
   int idx = 0;
   
   +   if (dev_is_pci(dev)) {
   +   dev_err(dev, iommu is currently not supported for 
   PCI\n);
   +   return NULL;
   +   }
   +
   /*
* We don't currently walk up the tree looking for a parent 
   IOMMU.
* See the `Notes:' section of
* Documentation/devicetree/bindings/iommu/iommu.txt
*/
   
   Wouldn't it be better to fix this rather than passing the device node
   pointer to the function ? The solution would be more generic.
   
   Will Deacon (Copied here) is working on this as we alteady discussed in
   this thread. So it will be addressed by him in another series.
  
  Well, working on this equates to has it somewhere near the bottom of
  a very long list :)
 
 What's your opinion on this patch then, do you think adding the iommu_np 
 argument makes sense as a temporary hack, or should we instead walk up the 
 tree looking for an iommus attribute in parent nodes ? I don't expect that to 
 be insanely difficult to code.

If walking up the tree is useful, then I think we should do that and update
the Documentation to reflect the new behaviour. The only reason that I
didn't code that in of_iommu_configure originally is because I didn't want
to go against the binding spec for the initial version, especially as we
didn't have a reason to look at parent nodes.

The only thing to double-check is that we don't break any existing users
of the binding with this change, but I don't think that we do.

Will
--
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/7] ASoC: pcm512x: Change register default to match actual content after reset

Hi Mark,

First of all, thanks for taking the rest of the series!

Mark Brown wrote:
 On Wed, Jan 28, 2015 at 03:16:08PM +0100, Peter Rosin wrote:
 
  @@ -78,7 +78,7 @@ static const struct reg_default
 pcm512x_reg_defaults[] = {
  { PCM512x_DIGITAL_VOLUME_2,  0x30 },
  { PCM512x_DIGITAL_VOLUME_3,  0x30 },
  { PCM512x_DIGITAL_MUTE_1,0x22 },
  -   { PCM512x_DIGITAL_MUTE_2,0x00 },
  +   { PCM512x_DIGITAL_MUTE_2,0x02 },
 
 The datasheet claims these have undefined values as reserved bits - what
 would be a more robust change here would be to remove the register
 default entirely so that we take the value the hardware has, giving
 robustness against any hardware revisions.  Of course the device has rather a
 lot of such reserved bits which is unfortunate.

Given the incompleteness of the datasheets this might be safest; a lot
of the reserved areas appear to have undocumented functions. But it
works as is of course, so it is not high priority... I don't know what happens
when this particular bit is cleared, but it doesn't change anything for the
pcm5142 that I am able to detect. So, no real problem with dropping 3/7.

Cheers,
Peter

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

Re: [PATCH 1/2] mmc: dw_mmc-exynos: add support for controlling emmc reset pin

On 28 January 2015 at 13:41, Tobias Jakobi liquid.a...@gmx.net wrote:
 Hello!

 Jaehoon Chung wrote:
 mmc core supported to hw_reset function.
 So i think we can use it. It's called at only initial time to clear the 
 previous status.
 But i think it can be called at reboot time. (it needs to implement codes.)
 how about?
 I don't think that's going the work. The problem here is that depending
 on the board configuration, the eMMC might carry the bootloader. If the
 eMMC subsystem is not properly reset _during_ reboot, the board won't
 even start since no bootloader is found. So we don't even reach the
 point where the kernel does anything.

I guess it depends on what's being done during the reboot sequence.

The most proper thing would be to let the boot loader control the GPIO
to trigger the HW reset, but that would mean the boot loader need to
know about board specific configurations, such as which GPIO pin. So
maybe SOC vendors need to state what GPIO pin to use and don't leave
that as a configurable option.

From kernel perspective, the best we can do is to the GPIO, when doing
a controlled reset (soft reset, or whatever we call it), but I am not
sure where that should be done? Is there a guarantee that the mmc bus'
-shutdown() callback gets called in this sequence?

Moreover, adding the reset GPIO as part of the initialization
procedure in the mmc core, gives us other benefits and it won't hurt.
So no matter, I think it's worth to proceed and discuss Marek's
proposal.

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

[PATCH 1/3] dt/bindings: Add binding for Versatile system registers

Add binding for Versatile board system registers found in the FPGA of the
Versatile/AB and Versatile/PB boards.

Signed-off-by: Rob Herring r...@kernel.org
Cc: Pawel Moll pawel.m...@arm.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Ian Campbell ijc+devicet...@hellion.org.uk
Cc: Kumar Gala ga...@codeaurora.org
Cc: devicetree@vger.kernel.org
---
 Documentation/devicetree/bindings/arm/versatile-sysreg.txt | 10 ++
 1 file changed, 10 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/versatile-sysreg.txt

diff --git a/Documentation/devicetree/bindings/arm/versatile-sysreg.txt 
b/Documentation/devicetree/bindings/arm/versatile-sysreg.txt
new file mode 100644
index 000..a4f1526
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/versatile-sysreg.txt
@@ -0,0 +1,10 @@
+ARM Versatile system registers
+--
+
+This is a system control registers block, providing multiple low level
+platform functions like board detection and identification, software
+interrupt generation, MMC and NOR Flash control etc.
+
+Required node properties:
+- compatible value : = arm,versatile-sysreg, syscon
+- reg : physical base address and the size of the registers window
-- 
2.1.0

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

Re: [PATCH 1/7] ARM: vf610: add second DSPI instance

2015-01-28 Thread Stefan Agner

On 2015-01-27 11:57, Bhuvanchandra DV wrote:
 Acked-by: Stefan Agner ste...@agner.ch
 Signed-off-by: Bhuvanchandra DV bhuvanchandra...@toradex.com
 ---
  arch/arm/boot/dts/vf500.dtsi |  4 
  arch/arm/boot/dts/vfxxx.dtsi | 11 +++
  2 files changed, 15 insertions(+)
 
 diff --git a/arch/arm/boot/dts/vf500.dtsi b/arch/arm/boot/dts/vf500.dtsi
 index 1dbf8d2..f5f807c 100644
 --- a/arch/arm/boot/dts/vf500.dtsi
 +++ b/arch/arm/boot/dts/vf500.dtsi
 @@ -66,6 +66,10 @@
   interrupts = GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH;
  };
  
 +dspi1 {
 + interrupts = GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH;
 +};
 +
  edma0 {
   interrupts = GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH,
   GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH;
 diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
 index a29c7ce..789744b 100644
 --- a/arch/arm/boot/dts/vfxxx.dtsi
 +++ b/arch/arm/boot/dts/vfxxx.dtsi
 @@ -139,6 +139,17 @@
   status = disabled;
   };
  
 + dspi1: dspi1@4002d000 {
 + #address-cells = 1;
 + #size-cells = 0;
 + compatible = fsl,vf610-dspi;
 + reg = 0x4002d000 0x1000;
 + clocks = clks VF610_CLK_DSPI1;
 + clock-names = dspi;
 + spi-num-chipselects = 5;
 + status = disabled;
 + };
 +
   sai2: sai@40031000 {
   compatible = fsl,vf610-sai;
   reg = 0x40031000 0x1000;


Acked-by: Stefan Agner ste...@agner.ch

Shawn, this will conflict with the pending MSCM driver patchset. I
probably have to resend the MSCM patchset anyway, also, the fix would be
trivial anyway.

--
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 1/2] ARM: zynq: Remove bogus value from 'bias-disable' property

2015-01-28 Thread Michal Simek

On 01/27/2015 01:38 AM, Andreas Färber wrote:
 Am 26.01.2015 um 20:49 schrieb Soren Brinkmann:
 In one pinctrl node, a 'bias-disable' property is erroneously assigned a
 value.

 Fixes: ARM: zynq: DT: Add pinctrl information
 Signed-off-by: Soren Brinkmann soren.brinkm...@xilinx.com
 
 Reviewed-by: Andreas Färber afaer...@suse.de
 
 Andreas
 

Applied both.

Thanks,
Michal



signature.asc
Description: OpenPGP digital signature

Re: Reading /sys with side effects (was Re: [PATCH 1/2] Documentation: leds: Add description of LED Flash class extension)

2015-01-28 Thread Jacek Anaszewski


Hi Pavel,

On 01/27/2015 11:37 PM, Pavel Machek wrote:

Hi!


+   - flash_fault - list of flash faults that may have occurred:
+   * led-over-voltage - flash controller voltage to the flash LED
+   has exceededthe limit specific to the flash controller
+   * flash-timeout-exceeded - the flash strobe was still on when
+   the timeout set by the user has expired; not all flash
+   controllers may set this in all such conditions
+   * controller-over-temperature - the flash controller has
+   overheated
+   * controller-short-circuit - the short circuit protection
+   of the flash controller has been triggered
+   * led-power-supply-over-current - current in the LED power
+   supply has exceeded the limit specific to the flash
+   controller
+   * indicator-led-fault - the flash controller has detected
+   a short or open circuit condition on the indicator LED
+   * led-under-voltage - flash controller voltage to the flash
+   LED has been below the minimum limit specific to
+   the flash
+   * controller-under-voltage - the input voltage of the flash
+   controller is below the limit under which strobing the
+   flash at full current will not be possible. The 
condition
+   persists until this flag is no longer set
+   * led-over-temperature - the temperature of the LED has exceeded
+   its allowed upper limit
+
+   Flash faults are cleared, if possible, by reading the attribute.


That's bad. Now you can no longer present flash_fault file as readable
to non-root users, and grep -ri foo /sys will interfere with your
camera application.

Bad interface, just fix it.


In my opinion it isn't crucial for the user to be aware of the
fact that some non-persistent fault happened right after strobing the
flash (e.g. over temperature).

I cannot see anything harmful in the situation when someone does grep
on /sys and clears non-persistent fault on a flash LED device.

Also, not all devices may be able to report the faults that happened
earlier but are not valid at the time of I2C readout. In that case the
user will never now that the fault has ever occurred, unless they read
the flash_fault attribute at the proper moment.

In this case we cannot enforce consistent policy for all devices.

Please describe the use case when clearing the fault on read can be
harmful, if you have any.

Moreover, I don't see your reply to Sakari's message [1], where he
considers the problem from several perspectives.

[1] http://www.spinics.net/lists/linux-leds/msg02653.html

--
Best Regards,
Jacek Anaszewski
--
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/4] mmc: pwrseq: Document DT bindings for the simple MMC power sequence

Hello Ulf,

On Mon, Jan 19, 2015 at 10:13 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
 To support SOCs which specifies specific MMC power sequences, document
 some MMC DT bindings to be able to describe these hardwares.

 Let's also document bindings for a simple MMC power sequence provider,
 which purpose is to support a set of common properties between various
 SOCs.

 In this initial step, let's also document a top level description of
 the MMC power sequence and describe the compatible string used for the
 simple MMC power sequence provider.

 The simple MMC power sequence provider will initially support a reset
 GPIO. From several earlier posted patches, it's clear that such
 hardware exists. Especially some WLAN chips which are attached to an
 SDIO interface may use a GPIO reset.

 Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
 ---

Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk

Best regards,
Javier
--
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/6] soc: qcom: gsbi: Add support for ADM CRCI muxing

2015-01-28 Thread Stanimir Varbanov

Hi Andy,

On 01/28/2015 12:10 AM, Andy Gross wrote:
 This patch adds automatic configuration for the ADM CRCI muxing required to
 support DMA operations for GSBI clients.  The GSBI mode and instance determine
 the correct TCSR ADM CRCI MUX value that must be programmed so that the DMA
 works properly.
 
 Signed-off-by: Andy Gross agr...@codeaurora.org
 ---
  .../devicetree/bindings/soc/qcom/qcom,gsbi.txt |   17 ++-
  drivers/soc/qcom/Kconfig   |1 +
  drivers/soc/qcom/qcom_gsbi.c   |  148 
 +++-
  3 files changed, 158 insertions(+), 8 deletions(-)
 

snip

 diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
 index 7bd2c94..32f20be 100644
 --- a/drivers/soc/qcom/Kconfig
 +++ b/drivers/soc/qcom/Kconfig
 @@ -4,6 +4,7 @@
  config QCOM_GSBI
  tristate QCOM General Serial Bus Interface
  depends on ARCH_QCOM
 + select MFD_SYSCON

Wrong indentation? In fact the original Kconfig entry has spaces instead
of tabs, could you prepare a cleanup patch for this.

  help
Say y here to enable GSBI support.  The GSBI provides control
functions for connecting the underlying serial UART, SPI, and I2C

snip

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

Re: [PATCH v4 3/6] of: fix size when dma-range is not used

2015-01-28 Thread Robin Murphy


On 28/01/15 11:05, Catalin Marinas wrote:

On Tue, Jan 27, 2015 at 06:55:15PM +, Murali Karicheri wrote:

On 01/27/2015 06:27 AM, Robin Murphy wrote:

On 23/01/15 22:32, Murali Karicheri wrote:

Fix the dma-range size when the DT attribute is missing. i.e set size to
dev-coherent_dma_mask + 1 instead of dev-coherent_dma_mask. To detect
overflow when mask is set to max of u64, add a check, log error and
return.
Some platform use mask format for size in DTS. So add a work around to
catch this and fix.

Cc: Joerg Roedel j...@8bytes.org
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring robh...@kernel.org
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Will Deacon will.dea...@arm.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Arnd Bergmann a...@arndb.de
Cc: Suravee Suthikulpanit suravee.suthikulpa...@amd.com

Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
drivers/of/device.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/of/device.c b/drivers/of/device.c
index 2de320d..0a5ff54 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -105,12 +105,24 @@ void of_dma_configure(struct device *dev, struct
device_node *np)
ret = of_dma_get_range(np, dma_addr, paddr, size);
if (ret  0) {
dma_addr = offset = 0;
- size = dev-coherent_dma_mask;
+ size = dev-coherent_dma_mask + 1;
} else {
offset = PFN_DOWN(paddr - dma_addr);
+ /*
+ * Add a work around to treat the size as mask + 1 in case
+ * it is defined in DT as a mask.
+ */
+ if (size  1)
+ size = size + 1;
dev_dbg(dev, dma_pfn_offset(%#08lx)\n, offset);
}

+ /* if size is 0, we have an overflow of u64 */
+ if (!size) {
+ dev_err(dev, invalid size\n);
+ return;
+ }
+


This seems potentially fragile to dodgy DTs given that we might also be
using size to make a mask later. Would it make sense to double-up a
sanity check as mask-format detection? Something like:

if is_power_of_2(size)
// use size
else if is_power_of_2(size + 1)
// use size + 1
else
// cry


How about having the logic like this?

ret = of_dma_get_range(np, dma_addr, paddr, size);
if (ret  0) {
dma_addr = offset = 0;
size = dev-coherent_dma_mask + 1;
} else {
offset = PFN_DOWN(paddr - dma_addr);
dev_dbg(dev, dma_pfn_offset(%#08lx)\n, offset);
}

if (is_power_of_2(size + 1))
size = size + 1;
else if (!is_power_of_2(size))
{
dev_err(dev, invalid size\n);
return;
}


In of_dma_configure(), we currently assume that the default coherent
mask is 32-bit. In this thread:

http://article.gmane.org/gmane.linux.kernel/1835096

we talked about setting the coherent mask based on size automatically.
I'm not sure about the size but I think we can assume is 32-bit mask + 1
if it is not specified in the DT. Instead of just assuming a default
mask, let's assume a default size and create the mask based on this
(untested):

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 5b33c6a21807..9ff8d1286b44 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -170,10 +170,10 @@ static void of_dma_configure(struct device *dev)
struct iommu_ops *iommu;

/*
-* Set default dma-mask to 32 bit. Drivers are expected to setup
-* the correct supported dma_mask.
+* Set default size to cover the 32-bit. Drivers are expected to setup
+* the correct size and dma_mask.
 */
-   dev-coherent_dma_mask = DMA_BIT_MASK(32);
+   size = 1ULL  32;

/*
 * Set it to coherent_dma_mask by default if the architecture
@@ -185,13 +185,24 @@ static void of_dma_configure(struct device *dev)
ret = of_dma_get_range(dev-of_node, dma_addr, paddr, size);
if (ret  0) {
dma_addr = offset = 0;
-   size = dev-coherent_dma_mask;
} else {
offset = PFN_DOWN(paddr - dma_addr);
dev_dbg(dev, dma_pfn_offset(%#08lx)\n, dev-dma_pfn_offset);
}
dev-dma_pfn_offset = offset;

+   /*
+* Workaround for DTs setting the size to a mask or 0.
+*/
+   if (is_power_of_2(size + 1))
+   size += 1;


In fact, since the ilog2 below ends up effectively rounding down, we 
might as well do away with this check as well and just add 1 
unconditionally. The only time it makes any difference is when we want 
it to anyway!


I like this approach, it ends up looking a lot neater.

Robin.


+
+   /*
+* Coherent DMA masks larger than 32-bit must be explicitly set by the
+* driver.
+*/
+   dev-coherent_dma_mask = min(DMA_BIT_MASK(32), 
DMA_BIT_MASK(ilog2(size)));
+
coherent = of_dma_is_coherent(dev-of_node);
dev_dbg(dev, device is%sdma coherent\n,
coherent ?   :  not );




--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message

RE: [PATCH v5] can: Convert to runtime_pm

2015-01-28 Thread Appana Durga Kedareswara Rao

Hi Marc,

 -Original Message-
 From: Marc Kleine-Budde [mailto:m...@pengutronix.de]
 Sent: Wednesday, January 28, 2015 8:16 PM
 To: Appana Durga Kedareswara Rao; w...@grandegger.com; Michal Simek;
 Soren Brinkmann; grant.lik...@linaro.org; robh...@kernel.org
 Cc: linux-...@vger.kernel.org; net...@vger.kernel.org; linux-arm-
 ker...@lists.infradead.org; linux-ker...@vger.kernel.org;
 devicetree@vger.kernel.org; Appana Durga Kedareswara Rao
 Subject: Re: [PATCH v5] can: Convert to runtime_pm

 On 01/12/2015 04:04 PM, Kedareswara rao Appana wrote:
  Instead of enabling/disabling clocks at several locations in the
  driver, Use the runtime_pm framework. This consolidates the actions
  for runtime PM In the appropriate callbacks and makes the driver more
 readable and mantainable.

  Signed-off-by: Soren Brinkmann soren.brinkm...@xilinx.com
  Signed-off-by: Kedareswara rao Appana appa...@xilinx.com
  ---
  Changes for v5:
   - Updated with the review comments.
 Updated the remove fuction to use runtime_pm.
  Chnages for v4:
   - Updated with the review comments.
  Changes for v3:
- Converted the driver to use runtime_pm.
  Changes for v2:
- Removed the struct platform_device* from suspend/resume
  as suggest by Lothar.

 Any plans to submit a v6?

I was on vacation till yesterday just came to office today only. Will look into 
it and will send v6 at the earliest.

Regards,
Kedar.

 Marc
 --
 Pengutronix e.K.  | Marc Kleine-Budde   |
 Industrial Linux Solutions| Phone: +49-231-2826-924 |
 Vertretung West/Dortmund  | Fax:   +49-5121-206917- |
 Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.

Re: [PATCH v5 3/8] of: fix size when dma-range is not used


On 01/28/2015 06:21 AM, Robin Murphy wrote:

Hi Murali,

[sorry, missed replying to yesterday's version]

On 27/01/15 21:00, Murali Karicheri wrote:

Fix the dma-range size when the DT attribute is missing. i.e set size to
dev-coherent_dma_mask + 1 instead of dev-coherent_dma_mask. Also add
code to check invalid values of size configured in DT and log error.

Cc: Joerg Roedel j...@8bytes.org
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring robh...@kernel.org
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Will Deacon will.dea...@arm.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Arnd Bergmann a...@arndb.de
Cc: Suravee Suthikulpanit suravee.suthikulpa...@amd.com

Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
drivers/of/device.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/of/device.c b/drivers/of/device.c
index 2de320d..17504f4 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -105,12 +105,19 @@ void of_dma_configure(struct device *dev, struct
device_node *np)
ret = of_dma_get_range(np, dma_addr, paddr, size);
if (ret  0) {
dma_addr = offset = 0;
- size = dev-coherent_dma_mask;
+ size = dev-coherent_dma_mask + 1;
} else {
offset = PFN_DOWN(paddr - dma_addr);
dev_dbg(dev, dma_pfn_offset(%#08lx)\n, offset);
}

+ if (is_power_of_2(size + 1))
+ size = size + 1;
+ else if (!is_power_of_2(size)) {
+ dev_err(dev, invalid size\n);
+ return;
+ }
+


Couldn't these checks go into the else path above? We don't need to
check the non-DT case, because we know we've just set it to something
sensible.

Robin,

Sure it can. I was doing flip/flop on the choice and thought it doesn' 
matter either way. Please also repond to Catalin's comment if you have 
any issues so that I can avoid additional spin on this patch.


Thanks

Murali


Robin.


dev-dma_pfn_offset = offset;

coherent = of_dma_is_coherent(np);







--
Murali Karicheri
Linux Kernel, Texas Instruments
--
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/6] mmc: pwrseq: Document optional clock for the simple power sequence

Some WLAN chips attached to a SDIO interface, need an external clock
to be operational. Since this is very common, extend the simple MMC
power sequence DT binding to support an optional clock.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---

Changes since v1: None.
---
 Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt 
b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
index eaae652213ae..a462c50f19a8 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
@@ -12,6 +12,10 @@ Optional properties:
at initialization and prior we start the power up procedure of the card.
They will be de-asserted right after the power has been provided to the
card.
+- clocks : Must contain an entry for the entry in clock-names.
+  See ../clocks/clock-bindings.txt for details.
+- clock-names : Must include the following entry:
+  ext_clock (External clock provided to the card).
 
 Example:
 
-- 
2.1.3

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

[PATCH v2 1/6] mmc: pwrseq: Document that simple sequence support more than one GPIO

Many SDIO/MMC attached WLAN chips need more than one ping for their reset
sequence. Extend the pwrseq_simple binding to support more than one pin.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---

Changes since v1:
 - Make the explanation clearer by adding an explicit they.
   Suggested by Srinivas Kandagatla.
---
 Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt 
b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
index da333d9ed94c..eaae652213ae 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
@@ -8,9 +8,10 @@ Required properties:
 - compatible : contains mmc-pwrseq-simple.
 
 Optional properties:
-- reset-gpios : contains a GPIO specifier. The reset GPIO is asserted at
-   initialization and prior we start the power up procedure of the card. It
-   will be de-asserted right after the power has been provided to the card.
+- reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are 
asserted
+   at initialization and prior we start the power up procedure of the card.
+   They will be de-asserted right after the power has been provided to the
+   card.
 
 Example:
 
-- 
2.1.3

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

[PATCH 2/5] mmc: pwrseq_simple: Extend to support more pins

Many WLAN attached to a SDIO/MMC interface, needs more than one pin for
their reset sequence. For example, is very common for chips to have two
pins: one for reset and one for power enable.

This patch adds support for more reset pins to the pwrseq_simple driver
and instead hardcoding a fixed number, it uses the of_gpio_named_count()
since the MMC power sequence is only built when CONFIG_OF is enabled.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
 drivers/mmc/core/pwrseq_simple.c | 54 ++--
 1 file changed, 41 insertions(+), 13 deletions(-)

diff --git a/drivers/mmc/core/pwrseq_simple.c b/drivers/mmc/core/pwrseq_simple.c
index 0958c696137f..9e51fe1051c5 100644
--- a/drivers/mmc/core/pwrseq_simple.c
+++ b/drivers/mmc/core/pwrseq_simple.c
@@ -11,6 +11,7 @@
 #include linux/slab.h
 #include linux/device.h
 #include linux/err.h
+#include linux/of_gpio.h
 #include linux/gpio/consumer.h
 
 #include linux/mmc/host.h
@@ -19,34 +20,44 @@
 
 struct mmc_pwrseq_simple {
struct mmc_pwrseq pwrseq;
-   struct gpio_desc *reset_gpio;
+   struct gpio_desc **reset_gpio;
+   int nr_gpios;
 };
 
 static void mmc_pwrseq_simple_pre_power_on(struct mmc_host *host)
 {
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
+   int i;
 
-   if (!IS_ERR(pwrseq-reset_gpio))
-   gpiod_set_value_cansleep(pwrseq-reset_gpio, 1);
+   for (i = 0; i  pwrseq-nr_gpios; i++)
+   if (!IS_ERR(pwrseq-reset_gpio[i]))
+   gpiod_set_value_cansleep(pwrseq-reset_gpio[i], 1);
 }
 
 static void mmc_pwrseq_simple_post_power_on(struct mmc_host *host)
 {
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
+   int i;
 
-   if (!IS_ERR(pwrseq-reset_gpio))
-   gpiod_set_value_cansleep(pwrseq-reset_gpio, 0);
+   for (i = 0; i  pwrseq-nr_gpios; i++)
+   if (!IS_ERR(pwrseq-reset_gpio[i]))
+   gpiod_set_value_cansleep(pwrseq-reset_gpio[i], 0);
 }
 
 static void mmc_pwrseq_simple_free(struct mmc_host *host)
 {
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
+   int i;
 
-   if (!IS_ERR(pwrseq-reset_gpio))
-   gpiod_put(pwrseq-reset_gpio);
+   if (pwrseq-nr_gpios  0) {
+   for (i = 0; i  pwrseq-nr_gpios; i++)
+   if (!IS_ERR(pwrseq-reset_gpio[i]))
+   gpiod_put(pwrseq-reset_gpio[i]);
+   kfree(pwrseq-reset_gpio);
+   }
 
kfree(pwrseq);
host-pwrseq = NULL;
@@ -63,17 +74,27 @@ int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct 
device *dev)
 {
struct mmc_pwrseq_simple *pwrseq;
int ret = 0;
+   int i;
 
pwrseq = kzalloc(sizeof(struct mmc_pwrseq_simple), GFP_KERNEL);
if (!pwrseq)
return -ENOMEM;
 
-   pwrseq-reset_gpio = gpiod_get_index(dev, reset, 0, GPIOD_OUT_HIGH);
-   if (IS_ERR(pwrseq-reset_gpio) 
-   PTR_ERR(pwrseq-reset_gpio) != -ENOENT 
-   PTR_ERR(pwrseq-reset_gpio) != -ENOSYS) {
-   ret = PTR_ERR(pwrseq-reset_gpio);
-   goto free;
+   pwrseq-nr_gpios = of_gpio_named_count(dev-of_node, reset-gpios);
+   if (pwrseq-nr_gpios  0) {
+   pwrseq-reset_gpio = kzalloc(sizeof(struct gpio_desc *) *
+pwrseq-nr_gpios, GFP_KERNEL);
+
+   for (i = 0; i  pwrseq-nr_gpios; i++) {
+   pwrseq-reset_gpio[i] = gpiod_get_index(dev, reset, i,
+   GPIOD_OUT_HIGH);
+   if (IS_ERR(pwrseq-reset_gpio[i]) 
+   PTR_ERR(pwrseq-reset_gpio[i]) != -ENOENT 
+   PTR_ERR(pwrseq-reset_gpio[i]) != -ENOSYS) {
+   ret = PTR_ERR(pwrseq-reset_gpio[i]);
+   goto free;
+   }
+   }
}
 
pwrseq-pwrseq.ops = mmc_pwrseq_simple_ops;
@@ -81,6 +102,13 @@ int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct 
device *dev)
 
return 0;
 free:
+   if (pwrseq-nr_gpios  0) {
+   for (i = 0; i  pwrseq-nr_gpios; i++)
+   if (!IS_ERR_OR_NULL(pwrseq-reset_gpio[i]))
+   gpiod_put(pwrseq-reset_gpio[i]);
+   kfree(pwrseq-reset_gpio);
+   }
+
kfree(pwrseq);
return ret;
 }
-- 
2.1.3

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

[PATCH v2 2/6] mmc: pwrseq_simple: Extend to support more pins

Many WLAN attached to a SDIO/MMC interface, needs more than one pin for
their reset sequence. For example, is very common for chips to have two
pins: one for reset and one for power enable.

This patch adds support for more reset pins to the pwrseq_simple driver
and instead hardcoding a fixed number, it uses the of_gpio_named_count()
since the MMC power sequence is only built when CONFIG_OF is enabled.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---

Changes since v1:
 - Many code cleanups suggested by Srinivas Kandagatla
* Rename reset_gpio array to reset_gpios.
* Use a zero length array for reset_gpios to avoid a kmalloc.
* Refactor GPIO assert and de-ssert logic into a common function.
* Simplify gpiod_put logic in case of gpiod_get error.
---
 drivers/mmc/core/pwrseq_simple.c | 55 +---
 1 file changed, 40 insertions(+), 15 deletions(-)

diff --git a/drivers/mmc/core/pwrseq_simple.c b/drivers/mmc/core/pwrseq_simple.c
index 0958c696137f..e53d3c7e059c 100644
--- a/drivers/mmc/core/pwrseq_simple.c
+++ b/drivers/mmc/core/pwrseq_simple.c
@@ -11,6 +11,7 @@
 #include linux/slab.h
 #include linux/device.h
 #include linux/err.h
+#include linux/of_gpio.h
 #include linux/gpio/consumer.h
 
 #include linux/mmc/host.h
@@ -19,16 +20,26 @@
 
 struct mmc_pwrseq_simple {
struct mmc_pwrseq pwrseq;
-   struct gpio_desc *reset_gpio;
+   int nr_gpios;
+   struct gpio_desc *reset_gpios[0];
 };
 
+static void mmc_pwrseq_simple_set_gpios_value(struct mmc_pwrseq_simple *pwrseq,
+ int value)
+{
+   int i;
+
+   for (i = 0; i  pwrseq-nr_gpios; i++)
+   if (!IS_ERR(pwrseq-reset_gpios[i]))
+   gpiod_set_value_cansleep(pwrseq-reset_gpios[i], value);
+}
+
 static void mmc_pwrseq_simple_pre_power_on(struct mmc_host *host)
 {
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
 
-   if (!IS_ERR(pwrseq-reset_gpio))
-   gpiod_set_value_cansleep(pwrseq-reset_gpio, 1);
+   mmc_pwrseq_simple_set_gpios_value(pwrseq, 1);
 }
 
 static void mmc_pwrseq_simple_post_power_on(struct mmc_host *host)
@@ -36,17 +47,18 @@ static void mmc_pwrseq_simple_post_power_on(struct mmc_host 
*host)
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
 
-   if (!IS_ERR(pwrseq-reset_gpio))
-   gpiod_set_value_cansleep(pwrseq-reset_gpio, 0);
+   mmc_pwrseq_simple_set_gpios_value(pwrseq, 0);
 }
 
 static void mmc_pwrseq_simple_free(struct mmc_host *host)
 {
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
+   int i;
 
-   if (!IS_ERR(pwrseq-reset_gpio))
-   gpiod_put(pwrseq-reset_gpio);
+   for (i = 0; i  pwrseq-nr_gpios; i++)
+   if (!IS_ERR(pwrseq-reset_gpios[i]))
+   gpiod_put(pwrseq-reset_gpios[i]);
 
kfree(pwrseq);
host-pwrseq = NULL;
@@ -62,20 +74,33 @@ static struct mmc_pwrseq_ops mmc_pwrseq_simple_ops = {
 int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct device *dev)
 {
struct mmc_pwrseq_simple *pwrseq;
-   int ret = 0;
+   int i, nr_gpios, ret = 0;
 
-   pwrseq = kzalloc(sizeof(struct mmc_pwrseq_simple), GFP_KERNEL);
+   nr_gpios = of_gpio_named_count(dev-of_node, reset-gpios);
+   if (nr_gpios  0)
+   nr_gpios = 0;
+
+   pwrseq = kzalloc(sizeof(struct mmc_pwrseq_simple) + nr_gpios *
+sizeof(struct gpio_desc *), GFP_KERNEL);
if (!pwrseq)
return -ENOMEM;
 
-   pwrseq-reset_gpio = gpiod_get_index(dev, reset, 0, GPIOD_OUT_HIGH);
-   if (IS_ERR(pwrseq-reset_gpio) 
-   PTR_ERR(pwrseq-reset_gpio) != -ENOENT 
-   PTR_ERR(pwrseq-reset_gpio) != -ENOSYS) {
-   ret = PTR_ERR(pwrseq-reset_gpio);
-   goto free;
+   for (i = 0; i  nr_gpios; i++) {
+   pwrseq-reset_gpios[i] = gpiod_get_index(dev, reset, i,
+GPIOD_OUT_HIGH);
+   if (IS_ERR(pwrseq-reset_gpios[i]) 
+   PTR_ERR(pwrseq-reset_gpios[i]) != -ENOENT 
+   PTR_ERR(pwrseq-reset_gpios[i]) != -ENOSYS) {
+   ret = PTR_ERR(pwrseq-reset_gpios[i]);
+
+   while (--i)
+   gpiod_put(pwrseq-reset_gpios[i]);
+
+   goto free;
+   }
}
 
+   pwrseq-nr_gpios = nr_gpios;
pwrseq-pwrseq.ops = mmc_pwrseq_simple_ops;
host-pwrseq = pwrseq-pwrseq;
 
-- 
2.1.3

--
To unsubscribe from this list: send the line

[RFC v2 12/14] NFC: nci: Change NCI state machine to LISTEN_ACTIVE and ignore parameters in rf_intf_activated_ntf

When receiving a intf_activated notification, if the rf interface is
NCI_RF_INTERFACE_NFCEE_DIRECT, we need to ignore the next parameters and
change the NCI state machine to NCI_LISTEN_ACTIVE.

Signed-off-by: Christophe Ricard christophe-h.ric...@st.com
---
 net/nfc/nci/ntf.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/net/nfc/nci/ntf.c b/net/nfc/nci/ntf.c
index 4cdb95d..19eaf52 100644
--- a/net/nfc/nci/ntf.c
+++ b/net/nfc/nci/ntf.c
@@ -545,6 +545,13 @@ static void nci_rf_intf_activated_ntf_packet(struct 
nci_dev *ndev,
pr_debug(rf_tech_specific_params_len %d\n,
 ntf.rf_tech_specific_params_len);
 
+   /* If this contains a value of 0x00 (NFCEE Direct RF
+* Interface) then all following parameters SHALL contain a
+* value of 0 and SHALL be ignored.
+*/
+   if (ntf.rf_interface == NCI_RF_INTERFACE_NFCEE_DIRECT)
+   goto listen;
+
if (ntf.rf_tech_specific_params_len  0) {
switch (ntf.activation_rf_tech_and_mode) {
case NCI_NFC_A_PASSIVE_POLL_MODE:
@@ -660,6 +667,7 @@ exit:
nci_req_complete(ndev, err);
}
} else {
+listen:
/* Listen mode */
atomic_set(ndev-state, NCI_LISTEN_ACTIVE);
if (err == NCI_STATUS_OK 
-- 
2.1.0

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

Re: [PATCH/RFC v10 04/19] dt-binding: mfd: max77693: Add DT binding related macros

2015-01-28 Thread Sakari Ailus

Hi Jacek,

On Tue, Jan 20, 2015 at 01:53:05PM +0100, Jacek Anaszewski wrote:
 On 01/20/2015 12:12 PM, Lee Jones wrote:
 On Fri, 09 Jan 2015, Jacek Anaszewski wrote:
 
 Add macros for max77693 led part related binding.
 
 Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 Cc: Lee Jones lee.jo...@linaro.org
 Cc: Chanwoo Choi cw00.c...@samsung.com
 ---
   include/dt-bindings/mfd/max77693.h |   21 +
   1 file changed, 21 insertions(+)
   create mode 100644 include/dt-bindings/mfd/max77693.h
 
 diff --git a/include/dt-bindings/mfd/max77693.h 
 b/include/dt-bindings/mfd/max77693.h
 new file mode 100644
 index 000..f53e197
 --- /dev/null
 +++ b/include/dt-bindings/mfd/max77693.h
 @@ -0,0 +1,21 @@
 +/*
 + * This header provides macros for MAX77693 device binding
 + *
 + * Copyright (C) 2014, Samsung Electronics Co., Ltd.
 + *
 + * Author: Jacek Anaszewski j.anaszew...@samsung.com
 + */
 +
 +#ifndef __DT_BINDINGS_MAX77693_H__
 +#define __DT_BINDINGS_MAX77693_H
 +
 +/* External trigger type */
 +#define MAX77693_LED_TRIG_TYPE_EDGE0
 +#define MAX77693_LED_TRIG_TYPE_LEVEL   1
 +
 +/* Boost modes */
 +#define MAX77693_LED_BOOST_OFF 0
 +#define MAX77693_LED_BOOST_ADAPTIVE1
 +#define MAX77693_LED_BOOST_FIXED   2
 +
 +#endif /* __DT_BINDINGS_MAX77693_H */
 
 These look fairly generic.  Do generic LED defines already exist?  If
 not, can they?
 
 I am not entirely sure that they are generic. Different devices
 may define different trigger types for low current LEDs and flash
 LEDs. Boost modes could also have different semantics.
 
 Regardless of the above we can consider renaming the file to
 include/dt-bindings/leds/max77693.h
 
 Bryan - what is your opinion?

At least trigger type can be chosen for lm3555 (as3645a) as well. I'm not
sure about boost mode.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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] mmc: pwrseq: Add support to control multiple gpios in simple pwrseq

This patch adds support to reset/powerup multiple gpio pins on a given
sdio bus. The use case is simple, on sdio we could have multiple devices
like WLAN, BT which are controlled by there own reset lines. So having
multiple reset is something more useful in such cases.

Without this patch I could not get BT and WLAN working at same time on IFC6410.

Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
 drivers/mmc/core/pwrseq_simple.c | 64 
 1 file changed, 45 insertions(+), 19 deletions(-)

diff --git a/drivers/mmc/core/pwrseq_simple.c b/drivers/mmc/core/pwrseq_simple.c
index 0958c69..bb9aadd 100644
--- a/drivers/mmc/core/pwrseq_simple.c
+++ b/drivers/mmc/core/pwrseq_simple.c
@@ -10,6 +10,7 @@
 #include linux/kernel.h
 #include linux/slab.h
 #include linux/device.h
+#include linux/of.h
 #include linux/err.h
 #include linux/gpio/consumer.h
 
@@ -19,34 +20,44 @@
 
 struct mmc_pwrseq_simple {
struct mmc_pwrseq pwrseq;
-   struct gpio_desc *reset_gpio;
+   int ngpios;
+   struct gpio_desc *reset_gpios[0];
 };
 
-static void mmc_pwrseq_simple_pre_power_on(struct mmc_host *host)
+static void __mmc_pwrseq_simple_pre_post_power_on_off(struct mmc_host *host,
+ bool on)
 {
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
+   int i;
 
-   if (!IS_ERR(pwrseq-reset_gpio))
-   gpiod_set_value_cansleep(pwrseq-reset_gpio, 1);
+   if (!IS_ERR(pwrseq-reset_gpios)) {
+   for (i = 0; i  pwrseq-ngpios; i++)
+   gpiod_set_value_cansleep(pwrseq-reset_gpios[i],
+on ? : 0);
+   }
 }
 
-static void mmc_pwrseq_simple_post_power_on(struct mmc_host *host)
+static void mmc_pwrseq_simple_pre_power_on(struct mmc_host *host)
 {
-   struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
-   struct mmc_pwrseq_simple, pwrseq);
+   __mmc_pwrseq_simple_pre_post_power_on_off(host, true);
+}
 
-   if (!IS_ERR(pwrseq-reset_gpio))
-   gpiod_set_value_cansleep(pwrseq-reset_gpio, 0);
+static void mmc_pwrseq_simple_post_power_on(struct mmc_host *host)
+{
+   __mmc_pwrseq_simple_pre_post_power_on_off(host, false);
 }
 
 static void mmc_pwrseq_simple_free(struct mmc_host *host)
 {
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
+   int i;
 
-   if (!IS_ERR(pwrseq-reset_gpio))
-   gpiod_put(pwrseq-reset_gpio);
+   if (!IS_ERR(pwrseq-reset_gpios)) {
+   for (i = 0; i  pwrseq-ngpios; i++)
+   gpiod_put(pwrseq-reset_gpios[i]);
+   }
 
kfree(pwrseq);
host-pwrseq = NULL;
@@ -62,20 +73,35 @@ static struct mmc_pwrseq_ops mmc_pwrseq_simple_ops = {
 int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct device *dev)
 {
struct mmc_pwrseq_simple *pwrseq;
-   int ret = 0;
+   int ngpios, i, ret = 0;
+
+   ngpios = of_count_phandle_with_args(dev-of_node,
+   reset-gpios, #gpio-cells);
 
-   pwrseq = kzalloc(sizeof(struct mmc_pwrseq_simple), GFP_KERNEL);
+   if (!ngpios)
+   return -ENOENT;
+
+   pwrseq = kzalloc(sizeof(struct mmc_pwrseq_simple) +
+ngpios * sizeof(struct gpio_desc *), GFP_KERNEL);
if (!pwrseq)
return -ENOMEM;
 
-   pwrseq-reset_gpio = gpiod_get_index(dev, reset, 0, GPIOD_OUT_HIGH);
-   if (IS_ERR(pwrseq-reset_gpio) 
-   PTR_ERR(pwrseq-reset_gpio) != -ENOENT 
-   PTR_ERR(pwrseq-reset_gpio) != -ENOSYS) {
-   ret = PTR_ERR(pwrseq-reset_gpio);
-   goto free;
+   for (i = 0; i  ngpios; i++) {
+   pwrseq-reset_gpios[i] = gpiod_get_index(dev, reset,
+i, GPIOD_OUT_HIGH);
+   if (IS_ERR(pwrseq-reset_gpios[i]) 
+   PTR_ERR(pwrseq-reset_gpios[i]) != -ENOENT 
+   PTR_ERR(pwrseq-reset_gpios[i]) != -ENOSYS) {
+   ret = PTR_ERR(pwrseq-reset_gpios[i]);
+
+   while (--i)
+   gpiod_put(pwrseq-reset_gpios[i]);
+
+   goto free;
+   }
}
 
+   pwrseq-ngpios = ngpios;
pwrseq-pwrseq.ops = mmc_pwrseq_simple_ops;
host-pwrseq = pwrseq-pwrseq;
 
-- 
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 1/6] of: iommu: add ptr to OF node arg to of_iommu_configure()


On 01/28/2015 08:32 AM, Will Deacon wrote:

On Wed, Jan 28, 2015 at 01:15:10PM +, Laurent Pinchart wrote:

On Wednesday 28 January 2015 12:29:42 Will Deacon wrote:

On Wed, Jan 28, 2015 at 12:23:03PM +, Laurent Pinchart wrote:

On Wednesday 28 January 2015 11:33:00 Will Deacon wrote:

On Mon, Jan 26, 2015 at 06:49:01PM +, Murali Karicheri wrote:

On 01/25/2015 08:32 AM, Laurent Pinchart wrote:

On Friday 23 January 2015 17:32:34 Murali Karicheri wrote:

Function of_iommu_configure() is called from of_dma_configure() to
setup iommu ops using DT property. This API is currently used for
platform devices for which DMA configuration (including iommu ops)
may come from device's parent. To extend this functionality for PCI
devices, this API need to take a parent node ptr as an argument
instead of assuming device's parent. This is needed since for PCI,
the dma configuration may be defined in the DT node of the root bus
bridge's parent device. Currently only dma-range is used for PCI and
iommu is not supported. So return error if the device is PCI.

Cc: Joerg Roedelj...@8bytes.org
Cc: Grant Likelygrant.lik...@linaro.org
Cc: Rob Herringrobh...@kernel.org
Cc: Bjorn Helgaasbhelg...@google.com
Cc: Will Deaconwill.dea...@arm.com
Cc: Russell Kingli...@arm.linux.org.uk
Cc: Arnd Bergmanna...@arndb.de
Cc: Suravee Suthikulpanitsuravee.suthikulpa...@amd.com

Signed-off-by: Murali Karicherim-kariche...@ti.com
---

   drivers/iommu/of_iommu.c |   10 --
   drivers/of/platform.c|2 +-
   include/linux/of_iommu.h |6 --
   3 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index af1dc6a..439235b 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -133,19 +133,25 @@ struct iommu_ops *of_iommu_get_ops(struct
device_node *np)
return ops;
  }

-struct iommu_ops *of_iommu_configure(struct device *dev)
+struct iommu_ops *of_iommu_configure(struct device *dev,
+struct device_node *iommu_np)
  {
struct of_phandle_args iommu_spec;
struct device_node *np;
struct iommu_ops *ops = NULL;
int idx = 0;

+   if (dev_is_pci(dev)) {
+   dev_err(dev, iommu is currently not supported for PCI\n);
+   return NULL;
+   }
+
/*
 * We don't currently walk up the tree looking for a parent
 IOMMU.
 * See the `Notes:' section of
 * Documentation/devicetree/bindings/iommu/iommu.txt
 */


Wouldn't it be better to fix this rather than passing the device node
pointer to the function ? The solution would be more generic.


Will Deacon (Copied here) is working on this as we alteady discussed
in this thread. So it will be addressed by him in another series.


Well, working on this equates to has it somewhere near the bottom of
a very long list :)


What's your opinion on this patch then, do you think adding the iommu_np
argument makes sense as a temporary hack, or should we instead walk up the
tree looking for an iommus attribute in parent nodes ? I don't expect that
to be insanely difficult to code.


If walking up the tree is useful, then I think we should do that and update
the Documentation to reflect the new behaviour.


If I understand Murali's patch set right (please correct me if that's not the
case) the PCI code walks up the DT nodes hierarchy to the parent node that
contains the iommus attribute and passes a pointer to that node to this
function. It's thus a PCI-specific solution. As a temporary hack that's OK I
suppose, but if implementing it right straight away isn't difficult that would
be better.


It looks to me like the code walks the PCI topology to get the DT node for
the host controller, and passes *that* to of_dma_configure. That sounds
like the right thing to do to me, especially since the PCI topology is
likely not encoded in the device-tree. So actually, it is passing the
first parent node afaict.


Laurent, Will,

I don't have an IOMMU hardware to do more work on this. My patch series 
has been on this list for long and it is also increasing in scope :(


I would suggest a follow up patch to this from someone (probably Will) 
and my patch goes as is with out further update. Hope this is reasonable.


Murali

The part I'm more interested in is the mapping of RequesterID (PCI dma
alias) to IOMMU ID when we transition from the PCI topology to the DT
topology. Currently, it seems to be 1:1 on the platforms I have, but I
doubt this will always be the case.

Will



--
Murali Karicheri
Linux Kernel, Texas Instruments
--
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 1/6] of: iommu: add ptr to OF node arg to of_iommu_configure()

2015-01-28 Thread Laurent Pinchart

Hi Will,

On Wednesday 28 January 2015 11:33:00 Will Deacon wrote:
 On Mon, Jan 26, 2015 at 06:49:01PM +, Murali Karicheri wrote:
  On 01/25/2015 08:32 AM, Laurent Pinchart wrote:
  On Friday 23 January 2015 17:32:34 Murali Karicheri wrote:
  Function of_iommu_configure() is called from of_dma_configure() to
  setup iommu ops using DT property. This API is currently used for
  platform devices for which DMA configuration (including iommu ops)
  may come from device's parent. To extend this functionality for PCI
  devices, this API need to take a parent node ptr as an argument
  instead of assuming device's parent. This is needed since for PCI, the
  dma configuration may be defined in the DT node of the root bus
  bridge's parent device. Currently only dma-range is used for PCI and
  iommu is not supported. So return error if the device is PCI.
  
  Cc: Joerg Roedelj...@8bytes.org
  Cc: Grant Likelygrant.lik...@linaro.org
  Cc: Rob Herringrobh...@kernel.org
  Cc: Bjorn Helgaasbhelg...@google.com
  Cc: Will Deaconwill.dea...@arm.com
  Cc: Russell Kingli...@arm.linux.org.uk
  Cc: Arnd Bergmanna...@arndb.de
  Cc: Suravee Suthikulpanitsuravee.suthikulpa...@amd.com
  
  Signed-off-by: Murali Karicherim-kariche...@ti.com
  ---
  
drivers/iommu/of_iommu.c |   10 --
drivers/of/platform.c|2 +-
include/linux/of_iommu.h |6 --
3 files changed, 13 insertions(+), 5 deletions(-)
  
  diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
  index af1dc6a..439235b 100644
  --- a/drivers/iommu/of_iommu.c
  +++ b/drivers/iommu/of_iommu.c
  @@ -133,19 +133,25 @@ struct iommu_ops *of_iommu_get_ops(struct
  device_node *np)
return ops;
   }
  
  -struct iommu_ops *of_iommu_configure(struct device *dev)
  +struct iommu_ops *of_iommu_configure(struct device *dev,
  +  struct device_node *iommu_np)
   {
struct of_phandle_args iommu_spec;
struct device_node *np;
struct iommu_ops *ops = NULL;
int idx = 0;
  
  + if (dev_is_pci(dev)) {
  + dev_err(dev, iommu is currently not supported for PCI\n);
  + return NULL;
  + }
  +
/*
 * We don't currently walk up the tree looking for a parent 
  IOMMU.
 * See the `Notes:' section of
 * Documentation/devicetree/bindings/iommu/iommu.txt
 */
  
  Wouldn't it be better to fix this rather than passing the device node
  pointer to the function ? The solution would be more generic.
  
  Laurent,
  
  Will Deacon (Copied here) is working on this as we alteady discussed in
  this thread. So it will be addressed by him in another series.
 
 Well, working on this equates to has it somewhere near the bottom of
 a very long list :)

What's your opinion on this patch then, do you think adding the iommu_np 
argument makes sense as a temporary hack, or should we instead walk up the 
tree looking for an iommus attribute in parent nodes ? I don't expect that to 
be insanely difficult to code.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 2/5] mmc: pwrseq_simple: Extend to support more pins


Hi Javier,

You are in a lead of 3 hrs from me..
Surprisingly I send very much same patch just few Mins ago :-)
May be we can merge goods in both :-)

On 28/01/15 10:10, Javier Martinez Canillas wrote:

Many WLAN attached to a SDIO/MMC interface, needs more than one pin for
their reset sequence. For example, is very common for chips to have two
pins: one for reset and one for power enable.

This patch adds support for more reset pins to the pwrseq_simple driver
and instead hardcoding a fixed number, it uses the of_gpio_named_count()
since the MMC power sequence is only built when CONFIG_OF is enabled.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
  drivers/mmc/core/pwrseq_simple.c | 54 ++--
  1 file changed, 41 insertions(+), 13 deletions(-)

diff --git a/drivers/mmc/core/pwrseq_simple.c b/drivers/mmc/core/pwrseq_simple.c
index 0958c696137f..9e51fe1051c5 100644
--- a/drivers/mmc/core/pwrseq_simple.c
+++ b/drivers/mmc/core/pwrseq_simple.c
@@ -11,6 +11,7 @@
  #include linux/slab.h
  #include linux/device.h
  #include linux/err.h
+#include linux/of_gpio.h
  #include linux/gpio/consumer.h

  #include linux/mmc/host.h
@@ -19,34 +20,44 @@

  struct mmc_pwrseq_simple {
struct mmc_pwrseq pwrseq;
-   struct gpio_desc *reset_gpio;
+   struct gpio_desc **reset_gpio;


May be renaming it to reset_gpios makes more sense..

If you make this struct gpio_desc *reset_gpios[0]; You can aviod an 
extra kmalloc and free ..




+   int nr_gpios;
  };

  static void mmc_pwrseq_simple_pre_power_on(struct mmc_host *host)
  {


[...

struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
+   int i;

-   if (!IS_ERR(pwrseq-reset_gpio))
-   gpiod_set_value_cansleep(pwrseq-reset_gpio, 1);
+   for (i = 0; i  pwrseq-nr_gpios; i++)
+   if (!IS_ERR(pwrseq-reset_gpio[i]))
+   gpiod_set_value_cansleep(pwrseq-reset_gpio[i], 1);


...]


  }

  static void mmc_pwrseq_simple_post_power_on(struct mmc_host *host)
  {


[...


struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
+   int i;

-   if (!IS_ERR(pwrseq-reset_gpio))
-   gpiod_set_value_cansleep(pwrseq-reset_gpio, 0);
+   for (i = 0; i  pwrseq-nr_gpios; i++)
+   if (!IS_ERR(pwrseq-reset_gpio[i]))
+   gpiod_set_value_cansleep(pwrseq-reset_gpio[i], 0);

...]

Now that we have more code in mmc_pwrseq_simple_post_power_on() and 
mmc_pwrseq_simple_pre_power_on(), Just move most of them into a common 
function like:


static void __mmc_pwrseq_simple_power_on_off(struct mmc_host *host,
  bool on)
{
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
int i;

if (!IS_ERR(pwrseq-reset_gpios)) {
for (i = 0; i  pwrseq-ngpios; i++)
gpiod_set_value_cansleep(pwrseq-reset_gpios[i],
 on ? : 0);
}
}

static void mmc_pwrseq_simple_pre_power_on(struct mmc_host *host)
{
__mmc_pwrseq_simple_power_on_off(host, true);
}

static void mmc_pwrseq_simple_post_power_on(struct mmc_host *host)
{
__mmc_pwrseq_simple_power_on_off(host, false);
}



  }

  static void mmc_pwrseq_simple_free(struct mmc_host *host)
  {
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
+   int i;

-   if (!IS_ERR(pwrseq-reset_gpio))
-   gpiod_put(pwrseq-reset_gpio);
+   if (pwrseq-nr_gpios  0) {
+   for (i = 0; i  pwrseq-nr_gpios; i++)
+   if (!IS_ERR(pwrseq-reset_gpio[i]))
+   gpiod_put(pwrseq-reset_gpio[i]);
+   kfree(pwrseq-reset_gpio);
+   }

kfree(pwrseq);
host-pwrseq = NULL;
@@ -63,17 +74,27 @@ int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct 
device *dev)
  {
struct mmc_pwrseq_simple *pwrseq;
int ret = 0;
+   int i;

pwrseq = kzalloc(sizeof(struct mmc_pwrseq_simple), GFP_KERNEL);
if (!pwrseq)
return -ENOMEM;

-   pwrseq-reset_gpio = gpiod_get_index(dev, reset, 0, GPIOD_OUT_HIGH);
-   if (IS_ERR(pwrseq-reset_gpio) 
-   PTR_ERR(pwrseq-reset_gpio) != -ENOENT 
-   PTR_ERR(pwrseq-reset_gpio) != -ENOSYS) {
-   ret = PTR_ERR(pwrseq-reset_gpio);
-   goto free;
+   pwrseq-nr_gpios = of_gpio_named_count(dev-of_node, reset-gpios);
+   if (pwrseq-nr_gpios  0) {


What happens if there are no gpios? This fuction should return -ENOENT 
and should not even try to allocate

[PATCH 0/3] Versatile AB/PB clocksource support

The Versatile clocksource driver can also be used on Versatile AB and PB 
platforms, not just Versatile Express. This series adds support for 
those boards.

I've split this off from the rest of the Versatile DT and 
multi-platform support as I'm not going to get it in place for 3.20. 
This part is fairly trivial and is ready to go.

Daniel, Can you please take the whole series.

Rob

Rob Herring (3):
  dt/bindings: Add binding for Versatile system registers
  clocksource: versatile: adapt for Versatile AB and PB boards
  dts: versatile: add sysregs node

 Documentation/devicetree/bindings/arm/versatile-sysreg.txt | 10 ++
 arch/arm/boot/dts/versatile-ab.dts |  5 +
 drivers/clocksource/versatile.c|  4 +++-
 3 files changed, 18 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/arm/versatile-sysreg.txt

-- 
2.1.0

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

Re: [PATCH v2 1/7] extcon: usb-gpio: Introduce gpio usb extcon driver

2015-01-28 Thread Roger Quadros

Chanwoo,

On 28/01/15 04:19, Chanwoo Choi wrote:
 Hi Roger,
 
 On 01/28/2015 12:38 AM, Roger Quadros wrote:
 Chanwoo,

 On 27/01/15 03:54, Chanwoo Choi wrote:
 Hi Roger,

 On 01/27/2015 01:27 AM, Roger Quadros wrote:
 Hi Chanwoo,

 All your comments are valid. Need some clarification on one comment.

 On 26/01/15 15:56, Chanwoo Choi wrote:
 Hi Roger,

 This patch looks good to me. But I add some comment.
 If you modify some comment, I'll apply this patch on 3.21 queue.

 On Mon, Jan 26, 2015 at 9:15 PM, Roger Quadros rog...@ti.com wrote:
 This driver observes the USB ID pin connected over a GPIO and
 updates the USB cable extcon states accordingly.

 The existing GPIO extcon driver is not suitable for this purpose
 as it needs to be taught to understand USB cable states and it
 can't handle more than one cable per instance.

 For the USB case we need to handle 2 cable states.
 1) USB (attach/detach)
 2) USB-Host (attach/detach)

 This driver can be easily updated in the future to handle VBUS
 events in case it happens to be available on GPIO for any platform.

 Signed-off-by: Roger Quadros rog...@ti.com
 ---
  .../devicetree/bindings/extcon/extcon-usb-gpio.txt |  20 ++
  drivers/extcon/Kconfig |   7 +
  drivers/extcon/Makefile|   1 +
  drivers/extcon/extcon-usb-gpio.c   | 214 
 +
  4 files changed, 242 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
  create mode 100644 drivers/extcon/extcon-usb-gpio.c


 snip

 +
 +static int usb_extcon_probe(struct platform_device *pdev)
 +{
 +   struct device *dev = pdev-dev;
 +   struct device_node *np = dev-of_node;
 +   struct usb_extcon_info *info;
 +   int ret;
 +
 +   if (!np)
 +   return -EINVAL;
 +
 +   info = devm_kzalloc(pdev-dev, sizeof(*info), GFP_KERNEL);
 +   if (!info)
 +   return -ENOMEM;
 +
 +   info-dev = dev;
 +   info-id_gpiod = devm_gpiod_get(pdev-dev, id);
 +   if (IS_ERR(info-id_gpiod)) {
 +   dev_err(dev, failed to get ID GPIO\n);
 +   return PTR_ERR(info-id_gpiod);
 +   }
 +
 +   ret = gpiod_set_debounce(info-id_gpiod,
 +USB_GPIO_DEBOUNCE_MS * 1000);
 +   if (ret  0)
 +   info-debounce_jiffies = 
 msecs_to_jiffies(USB_GPIO_DEBOUNCE_MS);
 +
 +   INIT_DELAYED_WORK(info-wq_detcable, usb_extcon_detect_cable);
 +
 +   info-id_irq = gpiod_to_irq(info-id_gpiod);
 +   if (info-id_irq  0) {
 +   dev_err(dev, failed to get ID IRQ\n);
 +   return info-id_irq;
 +   }
 +
 +   ret = devm_request_threaded_irq(dev, info-id_irq, NULL,
 +   usb_irq_handler,
 +   IRQF_SHARED | IRQF_ONESHOT |
 +   IRQF_NO_SUSPEND,
 +   pdev-name, info);

 use of IRQF_NO_SUSPEND is not recommended to be used together with 
 IRQF_SHARED so
 I'll remove IRQF_SHARED from here if we decide to stick with 
 IRQF_NO_SUSPEND.
 More on this below.

 +   if (ret  0) {
 +   dev_err(dev, failed to request handler for ID IRQ\n);
 +   return ret;
 +   }
 +
 +   info-edev = devm_extcon_dev_allocate(dev, usb_extcon_cable);
 +   if (IS_ERR(info-edev)) {
 +   dev_err(dev, failed to allocate extcon device\n);
 +   return -ENOMEM;
 +   }
 +
 +   ret = devm_extcon_dev_register(dev, info-edev);
 +   if (ret  0) {
 +   dev_err(dev, failed to register extcon device\n);
 +   return ret;
 +   }
 +
 +   platform_set_drvdata(pdev, info);

 I prefer to execute the device_init_wakeup() function as following
 for suspend/resume function:
 device_init_wakeup(pdev-dev, 1);

 +
 +   /* Perform initial detection */
 +   usb_extcon_detect_cable(info-wq_detcable.work);
 +
 +   return 0;
 +}
 +
 +static int usb_extcon_remove(struct platform_device *pdev)
 +{
 +   struct usb_extcon_info *info = platform_get_drvdata(pdev);
 +
 +   cancel_delayed_work_sync(info-wq_detcable);

 Need to add blank line.

 +   return 0;
 +}
 +
 +#ifdef CONFIG_PM_SLEEP
 +static int usb_extcon_suspend(struct device *dev)
 +{
 +   struct usb_extcon_info *info = dev_get_drvdata(dev);
 +
 +   enable_irq_wake(info-id_irq);

 I prefer to use device_may_wakeup() function for whether
 executing enable_irq_wake() or not. Also, The disable_irq()
 in the suspend function would prevent us from discarding interrupt
 before wakeup from suspend completely.


 I need more clarification here.

 If we are going to use enable_irq_wake() here then what is the point of 
 IRQF_NO_SUSPEND?

 From Documentation/power/suspend-and-interrupts.txt I see that interrupts 
 marked
 as IRQF_NO_SUSPEND should not be configured for system wakeup using

[PATCH 3/3] dts: versatile: add sysregs node

The Versatile boards have the same sysregs as other ARM Ltd boards. Add
the nodes in order to enable support for 24MHz counter as sched_clock.

This is a minimal node definition as the existing sub node definition
used on VExpress has some issues raised by Linus W.

Signed-off-by: Rob Herring r...@kernel.org
Cc: Russell King li...@arm.linux.org.uk
Cc: Linus Walleij linus.wall...@linaro.org
Cc: devicetree@vger.kernel.org
---
 arch/arm/boot/dts/versatile-ab.dts | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/versatile-ab.dts 
b/arch/arm/boot/dts/versatile-ab.dts
index 27d0d9c..01f4019 100644
--- a/arch/arm/boot/dts/versatile-ab.dts
+++ b/arch/arm/boot/dts/versatile-ab.dts
@@ -252,6 +252,11 @@
#size-cells = 1;
ranges = 0 0x1000 0x1;
 
+   sysreg@0 {
+   compatible = arm,versatile-sysreg, syscon;
+   reg = 0x0 0x1000;
+   };
+
aaci@4000 {
compatible = arm,primecell;
reg = 0x4000 0x1000;
-- 
2.1.0

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

Re: [PATCH v2 1/7] mmc: sdhci-pxav3: Fix SDR50 and DDR50 capabilities for the Armada 38x flavor

On 23 January 2015 at 11:56, Gregory CLEMENT
gregory.clem...@free-electrons.com wrote:
 According to erratum 'FE-2946959' both SDR50 and DDR50 modes require
 specific clock adjustments in SDIO3 Configuration register. However,
 this register was not part of the device tree binding. Even if the
 binding can (and will) be extended we still need handling the case
 where this register was not available. In this case we use the
 SDHCI_QUIRK_MISSING_CAPS quirk remove them from the capabilities.

 This commit is based on the work done by Marcin Wojtasm...@semihalf.com

 Fixes: 5491ce3f79ee (mmc: sdhci-pxav3: add support for the Armada 38x SDHCI 
 controller)
 Cc: sta...@vger.kernel.org # v3.15+
 Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
 Signed-off-by: Marcin Wojtas m...@semihalf.com
 ---
  drivers/mmc/host/sdhci-pxav3.c | 18 ++
  1 file changed, 18 insertions(+)

 diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
 index ca3424e7ef71..7b07325b4fba 100644
 --- a/drivers/mmc/host/sdhci-pxav3.c
 +++ b/drivers/mmc/host/sdhci-pxav3.c
 @@ -118,6 +118,20 @@ static int mv_conf_mbus_windows(struct platform_device 
 *pdev,
 return 0;
  }

 +static int armada_38x_quirks(struct sdhci_host *host)

Seems like this function can be void instead of always returning 0.

 +{
 +   host-quirks |= SDHCI_QUIRK_MISSING_CAPS;
 +   /*
 +* According to erratum 'FE-2946959' both SDR50 and DDR50
 +* modes require specific clock adjustments in SDIO3
 +* Configuration register, if the adjustment is not done,
 +* remove them from the capabilities.
 +*/
 +   host-caps1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
 +   host-caps1 = ~(SDHCI_SUPPORT_SDR50 | SDHCI_SUPPORT_DDR50);
 +   return 0;
 +}
 +
  static void pxav3_reset(struct sdhci_host *host, u8 mask)
  {
 struct platform_device *pdev = to_platform_device(mmc_dev(host-mmc));
 @@ -319,6 +333,9 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
 clk_prepare_enable(pxa-clk_core);

 if (of_device_is_compatible(np, marvell,armada-380-sdhci)) {
 +   ret = armada_38x_quirks(host);
 +   if (ret  0)
 +   goto err_quirks;
 ret = mv_conf_mbus_windows(pdev, mv_mbus_dram_info());
 if (ret  0)
 goto err_mbus_win;
 @@ -400,6 +417,7 @@ err_mbus_win:
 if (!IS_ERR(pxa-clk_core))
 clk_disable_unprepare(pxa-clk_core);
  err_clk_get:
 +err_quirks:
 sdhci_pltfm_free(pdev);
 return ret;
  }
 --
 2.1.0


Kind regards
Uffe
--
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/7] extcon: usb-gpio: Introduce gpio usb extcon driver

2015-01-28 Thread Roger Quadros

This driver observes the USB ID pin connected over a GPIO and
updates the USB cable extcon states accordingly.

The existing GPIO extcon driver is not suitable for this purpose
as it needs to be taught to understand USB cable states and it
can't handle more than one cable per instance.

For the USB case we need to handle 2 cable states.
1) USB (attach/detach)
2) USB-Host (attach/detach)

This driver can be easily updated in the future to handle VBUS
events in case it happens to be available on GPIO for any platform.

Signed-off-by: Roger Quadros rog...@ti.com
---
v3:
- removed IRQF_NO_SUSPEND flag. Added IRQF_TRIGGER_RISING and
  IRQF_TRIGGER_FALLING
- Added disable_irq() to suspend() and enable_irq() to resume()

 .../devicetree/bindings/extcon/extcon-usb-gpio.txt |  18 ++
 drivers/extcon/Kconfig |   7 +
 drivers/extcon/Makefile|   1 +
 drivers/extcon/extcon-usb-gpio.c   | 233 +
 4 files changed, 259 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
 create mode 100644 drivers/extcon/extcon-usb-gpio.c

diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt 
b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
new file mode 100644
index 000..85fe6b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
@@ -0,0 +1,18 @@
+USB GPIO Extcon device
+
+This is a virtual device used to generate USB cable states from the USB ID pin
+connected to a GPIO pin.
+
+Required properties:
+- compatible: Should be linux,extcon-usb-gpio
+- id-gpio: gpio for USB ID pin. See gpio binding.
+
+Example:
+   extcon_usb1 {
+   compatible = linux,extcon-usb-gpio;
+   id-gpio = gpio6 1 GPIO_ACTIVE_HIGH;
+   }
+
+   omap_dwc3_1 {
+   extcon = extcon_usb1;
+   };
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index 6a1f7de..fd11536 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -93,4 +93,11 @@ config EXTCON_SM5502
  Silicon Mitus SM5502. The SM5502 is a USB port accessory
  detector and switch.
 
+config EXTCON_USB_GPIO
+   tristate USB GPIO extcon support
+   select GPIOLIB
+   help
+ Say Y here to enable GPIO based USB cable detection extcon support.
+ Used typically if GPIO is used for USB ID pin detection.
+
 endif # MULTISTATE_SWITCH
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 0370b42..6a08a98 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_EXTCON_MAX8997)  += extcon-max8997.o
 obj-$(CONFIG_EXTCON_PALMAS)+= extcon-palmas.o
 obj-$(CONFIG_EXTCON_RT8973A)   += extcon-rt8973a.o
 obj-$(CONFIG_EXTCON_SM5502)+= extcon-sm5502.o
+obj-$(CONFIG_EXTCON_USB_GPIO)  += extcon-usb-gpio.o
diff --git a/drivers/extcon/extcon-usb-gpio.c b/drivers/extcon/extcon-usb-gpio.c
new file mode 100644
index 000..99a58b2
--- /dev/null
+++ b/drivers/extcon/extcon-usb-gpio.c
@@ -0,0 +1,233 @@
+/**
+ * drivers/extcon/extcon-usb-gpio.c - USB GPIO extcon driver
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Roger Quadros rog...@ti.com
+ *
+ * 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 linux/extcon.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_gpio.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/workqueue.h
+
+#define USB_GPIO_DEBOUNCE_MS   20  /* ms */
+
+struct usb_extcon_info {
+   struct device *dev;
+   struct extcon_dev *edev;
+
+   struct gpio_desc *id_gpiod;
+   int id_irq;
+   bool id_irqwake;/* ID wakeup enabled flag */
+
+   unsigned long debounce_jiffies;
+   struct delayed_work wq_detcable;
+};
+
+/* List of detectable cables */
+enum {
+   EXTCON_CABLE_USB = 0,
+   EXTCON_CABLE_USB_HOST,
+
+   EXTCON_CABLE_END,
+};
+
+static const char *usb_extcon_cable[] = {
+   [EXTCON_CABLE_USB] = USB,
+   [EXTCON_CABLE_USB_HOST] = USB-Host,
+   NULL,
+};
+
+static void usb_extcon_detect_cable(struct work_struct *work)
+{
+   int id;
+   struct usb_extcon_info *info = container_of(to_delayed_work(work),
+   struct usb_extcon_info,
+   wq_detcable);
+
+   /* check ID and update cable state */
+   id =

Re: [PATCH v4 1/6] of: iommu: add ptr to OF node arg to of_iommu_configure()

2015-01-28 Thread Will Deacon

On Wed, Jan 28, 2015 at 01:15:10PM +, Laurent Pinchart wrote:
 On Wednesday 28 January 2015 12:29:42 Will Deacon wrote:
  On Wed, Jan 28, 2015 at 12:23:03PM +, Laurent Pinchart wrote:
   On Wednesday 28 January 2015 11:33:00 Will Deacon wrote:
   On Mon, Jan 26, 2015 at 06:49:01PM +, Murali Karicheri wrote:
   On 01/25/2015 08:32 AM, Laurent Pinchart wrote:
   On Friday 23 January 2015 17:32:34 Murali Karicheri wrote:
   Function of_iommu_configure() is called from of_dma_configure() to
   setup iommu ops using DT property. This API is currently used for
   platform devices for which DMA configuration (including iommu ops)
   may come from device's parent. To extend this functionality for PCI
   devices, this API need to take a parent node ptr as an argument
   instead of assuming device's parent. This is needed since for PCI,
   the dma configuration may be defined in the DT node of the root bus
   bridge's parent device. Currently only dma-range is used for PCI and
   iommu is not supported. So return error if the device is PCI.
   
   Cc: Joerg Roedelj...@8bytes.org
   Cc: Grant Likelygrant.lik...@linaro.org
   Cc: Rob Herringrobh...@kernel.org
   Cc: Bjorn Helgaasbhelg...@google.com
   Cc: Will Deaconwill.dea...@arm.com
   Cc: Russell Kingli...@arm.linux.org.uk
   Cc: Arnd Bergmanna...@arndb.de
   Cc: Suravee Suthikulpanitsuravee.suthikulpa...@amd.com
   
   Signed-off-by: Murali Karicherim-kariche...@ti.com
   ---
   
 drivers/iommu/of_iommu.c |   10 --
 drivers/of/platform.c|2 +-
 include/linux/of_iommu.h |6 --
 3 files changed, 13 insertions(+), 5 deletions(-)
   
   diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
   index af1dc6a..439235b 100644
   --- a/drivers/iommu/of_iommu.c
   +++ b/drivers/iommu/of_iommu.c
   @@ -133,19 +133,25 @@ struct iommu_ops *of_iommu_get_ops(struct
   device_node *np)
 return ops;
}
   
   -struct iommu_ops *of_iommu_configure(struct device *dev)
   +struct iommu_ops *of_iommu_configure(struct device *dev,
   +  struct device_node *iommu_np)
{
 struct of_phandle_args iommu_spec;
 struct device_node *np;
 struct iommu_ops *ops = NULL;
 int idx = 0;
   
   + if (dev_is_pci(dev)) {
   + dev_err(dev, iommu is currently not supported for 
   PCI\n);
   + return NULL;
   + }
   +
 /*
  * We don't currently walk up the tree looking for a parent
  IOMMU.
  * See the `Notes:' section of
  * Documentation/devicetree/bindings/iommu/iommu.txt
  */
   
   Wouldn't it be better to fix this rather than passing the device node
   pointer to the function ? The solution would be more generic.
   
   Will Deacon (Copied here) is working on this as we alteady discussed
   in this thread. So it will be addressed by him in another series.
   
   Well, working on this equates to has it somewhere near the bottom of
   a very long list :)
   
   What's your opinion on this patch then, do you think adding the iommu_np
   argument makes sense as a temporary hack, or should we instead walk up the
   tree looking for an iommus attribute in parent nodes ? I don't expect that
   to be insanely difficult to code.
  
  If walking up the tree is useful, then I think we should do that and update
  the Documentation to reflect the new behaviour.
 
 If I understand Murali's patch set right (please correct me if that's not the 
 case) the PCI code walks up the DT nodes hierarchy to the parent node that 
 contains the iommus attribute and passes a pointer to that node to this 
 function. It's thus a PCI-specific solution. As a temporary hack that's OK I 
 suppose, but if implementing it right straight away isn't difficult that 
 would 
 be better.

It looks to me like the code walks the PCI topology to get the DT node for
the host controller, and passes *that* to of_dma_configure. That sounds
like the right thing to do to me, especially since the PCI topology is
likely not encoded in the device-tree. So actually, it is passing the
first parent node afaict.

The part I'm more interested in is the mapping of RequesterID (PCI dma
alias) to IOMMU ID when we transition from the PCI topology to the DT
topology. Currently, it seems to be 1:1 on the platforms I have, but I
doubt this will always be the case.

Will
--
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 v9 2/2] tty/serial: Add Spreadtrum sc9836-uart driver support

2015-01-28 Thread Baruch Siach

Hi Lyra Zhang,

On Wed, Jan 28, 2015 at 04:46:33PM +0800, Lyra Zhang wrote:
 On Wed, Jan 28, 2015 at 2:12 PM, Baruch Siach bar...@tkos.co.il wrote:
  On Wed, Jan 28, 2015 at 10:47:41AM +0800, Chunyan Zhang wrote:
  + if (uart_handle_sysrq_char(port, ch))
  + continue;
 
  My comment[1] on a previous version of this patch still stands.
  uart_handle_sysrq_char is a NOP when SUPPORT_SYSRQ is not defined.
 
 yes, there are two definitions in serial_core.h, and it returns 0 when
 SUPPORT_SYSRQ is not defined.
 so, I think my code behavior does not hurt, right?

Right. I just wanted to point out that you can easily define SUPPORT_SYSRQ as 
appropriate like many other serial drivers do to get sysrq support.

baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
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

[RFC v2 13/14] NFC: st21nfcb: Add support for HCI event transaction

The event transaction notifies the Device Host that an action is required
to manage a specific Secure Element application.

Signed-off-by: Christophe Ricard christophe-h.ric...@st.com
---
 drivers/nfc/st21nfcb/st21nfcb_se.c | 23 ++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/nfc/st21nfcb/st21nfcb_se.c 
b/drivers/nfc/st21nfcb/st21nfcb_se.c
index cf65368..6868043 100644
--- a/drivers/nfc/st21nfcb/st21nfcb_se.c
+++ b/drivers/nfc/st21nfcb/st21nfcb_se.c
@@ -287,14 +287,35 @@ static int 
st21nfcb_hci_connectivity_event_received(struct st21nfcb_hci_dev *hde
struct sk_buff *skb)
 {
int r = 0;
+   struct device *dev = hdev-ndev-nfc_dev-dev;
+   struct nfc_evt_transaction *transaction;
 
pr_debug(connectivity gate event: %x\n, event);
 
switch (event) {
case ST21NFCB_EVT_CONNECTIVITY:
+
break;
case ST21NFCB_EVT_TRANSACTION:
-   break;
+   if (skb-len  NFC_MIN_AID_LENGTH + 2 
+   skb-data[0] != NFC_EVT_TRANSACTION_AID_TAG)
+   return -EPROTO;
+
+   transaction = (struct nfc_evt_transaction *)devm_kzalloc(dev,
+   skb-len - 2, GFP_KERNEL);
+
+   transaction-aid_len = skb-data[1];
+   memcpy(transaction-aid, skb-data[2], skb-data[1]);
+
+   if (skb-data[transaction-aid_len + 2] !=
+   NFC_EVT_TRANSACTION_PARAMS_TAG)
+   return -EPROTO;
+
+   transaction-params_len = skb-data[transaction-aid_len + 3];
+   memcpy(transaction-params, skb-data +
+  transaction-aid_len + 4, transaction-params_len);
+
+   r = nfc_se_transaction(hdev-ndev-nfc_dev, host, transaction);
default:
return 1;
}
-- 
2.1.0

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

Re: [PATCH 1/5] mmc: pwrseq: Document that simple sequence support more than one GPIO




On 28/01/15 10:10, Javier Martinez Canillas wrote:

Many SDIO/MMC attached WLAN chips need more than one ping for their reset
sequence. Extend the pwrseq_simple binding to support more than one pin.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
  Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt 
b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
index da333d9ed94c..9a77deb164c7 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
@@ -8,9 +8,9 @@ Required properties:
  - compatible : contains mmc-pwrseq-simple.

  Optional properties:
-- reset-gpios : contains a GPIO specifier. The reset GPIO is asserted at
-   initialization and prior we start the power up procedure of the card. It
-   will be de-asserted right after the power has been provided to the card.
+- reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are 
asserted
+   at initialization and prior we start the power up procedure of the card.
+   Will be de-asserted right after the power has been provided to the card.

Makes sense if you add They before last sentence.


  Example:



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

Re: [PATCH 2/5] mmc: pwrseq_simple: Extend to support more pins




On 28/01/15 16:13, Javier Martinez Canillas wrote:

Hello Srinivas,

Thanks a lot for your feedback.

On 01/28/2015 03:01 PM, Srinivas Kandagatla wrote:

Hi Javier,

You are in a lead of 3 hrs from me..
Surprisingly I send very much same patch just few Mins ago :-)


:-)

I didn't find the posted patch you are referring too though, did you cc
linux-mmc?


May be we can merge goods in both :-)



Sure, I want $subject to be generic enough to be useful for other platforms.


On 28/01/15 10:10, Javier Martinez Canillas wrote:

Many WLAN attached to a SDIO/MMC interface, needs more than one pin for
their reset sequence. For example, is very common for chips to have two
pins: one for reset and one for power enable.

This patch adds support for more reset pins to the pwrseq_simple driver
and instead hardcoding a fixed number, it uses the of_gpio_named_count()
since the MMC power sequence is only built when CONFIG_OF is enabled.

Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
   drivers/mmc/core/pwrseq_simple.c | 54 
++--
   1 file changed, 41 insertions(+), 13 deletions(-)

diff --git a/drivers/mmc/core/pwrseq_simple.c b/drivers/mmc/core/pwrseq_simple.c
index 0958c696137f..9e51fe1051c5 100644
--- a/drivers/mmc/core/pwrseq_simple.c
+++ b/drivers/mmc/core/pwrseq_simple.c
@@ -11,6 +11,7 @@
   #include linux/slab.h
   #include linux/device.h
   #include linux/err.h
+#include linux/of_gpio.h
   #include linux/gpio/consumer.h

   #include linux/mmc/host.h
@@ -19,34 +20,44 @@

   struct mmc_pwrseq_simple {
struct mmc_pwrseq pwrseq;
-   struct gpio_desc *reset_gpio;
+   struct gpio_desc **reset_gpio;


May be renaming it to reset_gpios makes more sense..



Ok


If you make this struct gpio_desc *reset_gpios[0]; You can aviod an
extra kmalloc and free ..




That's a very good idea, thanks.


+   int nr_gpios;
   };

   static void mmc_pwrseq_simple_pre_power_on(struct mmc_host *host)
   {


[...

struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
+   int i;

-   if (!IS_ERR(pwrseq-reset_gpio))
-   gpiod_set_value_cansleep(pwrseq-reset_gpio, 1);
+   for (i = 0; i  pwrseq-nr_gpios; i++)
+   if (!IS_ERR(pwrseq-reset_gpio[i]))
+   gpiod_set_value_cansleep(pwrseq-reset_gpio[i], 1);


...]


   }

   static void mmc_pwrseq_simple_post_power_on(struct mmc_host *host)
   {


[...


struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
+   int i;

-   if (!IS_ERR(pwrseq-reset_gpio))
-   gpiod_set_value_cansleep(pwrseq-reset_gpio, 0);
+   for (i = 0; i  pwrseq-nr_gpios; i++)
+   if (!IS_ERR(pwrseq-reset_gpio[i]))
+   gpiod_set_value_cansleep(pwrseq-reset_gpio[i], 0);

...]

Now that we have more code in mmc_pwrseq_simple_post_power_on() and
mmc_pwrseq_simple_pre_power_on(), Just move most of them into a common
function like:

static void __mmc_pwrseq_simple_power_on_off(struct mmc_host *host,
  bool on)
{
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
int i;

if (!IS_ERR(pwrseq-reset_gpios)) {
for (i = 0; i  pwrseq-ngpios; i++)
gpiod_set_value_cansleep(pwrseq-reset_gpios[i],
 on ? : 0);
}
}

static void mmc_pwrseq_simple_pre_power_on(struct mmc_host *host)
{
__mmc_pwrseq_simple_power_on_off(host, true);
}

static void mmc_pwrseq_simple_post_power_on(struct mmc_host *host)
{
__mmc_pwrseq_simple_power_on_off(host, false);
}




Sure, will do.


   }

   static void mmc_pwrseq_simple_free(struct mmc_host *host)
   {
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
+   int i;

-   if (!IS_ERR(pwrseq-reset_gpio))
-   gpiod_put(pwrseq-reset_gpio);
+   if (pwrseq-nr_gpios  0) {
+   for (i = 0; i  pwrseq-nr_gpios; i++)
+   if (!IS_ERR(pwrseq-reset_gpio[i]))
+   gpiod_put(pwrseq-reset_gpio[i]);
+   kfree(pwrseq-reset_gpio);
+   }

kfree(pwrseq);
host-pwrseq = NULL;
@@ -63,17 +74,27 @@ int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct 
device *dev)
   {
struct mmc_pwrseq_simple *pwrseq;
int ret = 0;
+   int i;

pwrseq = kzalloc(sizeof(struct mmc_pwrseq_simple), GFP_KERNEL);
if (!pwrseq)
return -ENOMEM;

-   pwrseq-reset_gpio = gpiod_get_index(dev, reset, 0, GPIOD_OUT_HIGH);
-   if (IS_ERR(pwrseq-reset_gpio) 
-

[RFC v2 00/14] Secure Element support for NCI based NFC controller, st21nfcb integration and EVT_TRANSACTION

Hi Samuel,

This is a pre-send with an update including your comments on patch #20.
Patch #27 is not yet modified. I hope to send something for review tonight.


I have to introduce dynnamic conn_id management has described in the NCI
specification. Only RF static conn_id was supported so far. I have tried to
do a minimun changeset in order to bring all the necessary NCI functions in
order to operate with a secure element with ST21NFCB NFC controller. Besides the
standard NCI commands, the HCI commands are sent following a proprietary
implementation.

Miscellaneous
-
I am also routing the HCI event TRANSACTION up to user space. It may help to 
understand
the necessity to reference every pipe with a tuple {gate, host}. This for 
example allows
to keep the host information generating this particular event.

Open Questions:
---
Both integration may have little gap in their card emulation behavior.
For example:
- ST21NFCA will have card emulation active as soon as we activate a secure 
element.
- ST21NFCB will have card emulation active according to the selected polling 
mode.
When do you expect to have card emulation to be active ?

When an application is running, it might be necessary to signals to the under 
layers
that it has finished to operate with a particular secure element. The goal here 
is to release
a secure element without deactivating it. For example to allow automatic sleep 
mode.
With my current implementation,
- With ST21NFCB, enable_se/disable_se may fit this request as both secure 
element are kept activated.
- With ST21NFCA, enable_se/disable_se does not fit this requirement as i am 
completely deactivating 
the secure element.
I am not sure if the SE activation should not be done in the discovery_se 
without any deactivation
until the device remove function(?).


Any feedback are welcome.

Best Regards
Christophe

Christophe Ricard (14):
  NFC: nci: Add dynamic conn_id NCI concept.
  NFC: nci: Make nci_request available for nfc driver
  NFC: nci: Add NCI NFCEE constant
  NFC: nci: Add nci_nfcee_discover handler command/response/notification
  NFC: nci: Add nci_nfcee_mode_set handler command/response
  NFC: nci: Add nci_core_conn_create handler command/response
  NFC: nci: Add nci_core_conn_close handler command/response
  NFC: st21nfcb: Add HCI protocol over NCI protocol support
  NFC: st21nfcb: Adding support for secure element
  NFC: Forward NFC_EVT_TRANSACTION up to user space
  NFC: nci: Add support RF_NFCEE_ACTION_NTF
  NFC: nci: Change NCI state machine to LISTEN_ACTIVE and ignore
parameters in rf_intf_activated_ntf
  NFC: st21nfcb: Add support for HCI event transaction
  NFC: st21nfca: Add support for HCI event transaction

 drivers/nfc/st21nfca/st21nfca_se.c   |  21 +
 drivers/nfc/st21nfcb/Makefile|   2 +-
 drivers/nfc/st21nfcb/st21nfcb.c  |   8 +-
 drivers/nfc/st21nfcb/st21nfcb.h  |   2 +
 drivers/nfc/st21nfcb/st21nfcb_hci_core.c | 823 +++
 drivers/nfc/st21nfcb/st21nfcb_hci_core.h | 134 +
 drivers/nfc/st21nfcb/st21nfcb_se.c   | 631 
 drivers/nfc/st21nfcb/st21nfcb_se.h   |  59 +++
 include/net/nfc/nci.h|  95 
 include/net/nfc/nci_core.h   |  41 +-
 include/net/nfc/nfc.h|  27 +
 include/uapi/linux/nfc.h |   1 +
 net/nfc/core.c   |  21 +
 net/nfc/nci/core.c   | 121 -
 net/nfc/nci/data.c   |  72 ++-
 net/nfc/nci/ntf.c|  93 +++-
 net/nfc/nci/rsp.c| 100 +++-
 net/nfc/netlink.c|  47 ++
 net/nfc/nfc.h|   2 +
 19 files changed, 2255 insertions(+), 45 deletions(-)
 create mode 100644 drivers/nfc/st21nfcb/st21nfcb_hci_core.c
 create mode 100644 drivers/nfc/st21nfcb/st21nfcb_hci_core.h
 create mode 100644 drivers/nfc/st21nfcb/st21nfcb_se.c
 create mode 100644 drivers/nfc/st21nfcb/st21nfcb_se.h

-- 
2.1.0

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

[RFC v2 05/14] NFC: nci: Add nci_nfcee_mode_set handler command/response

Add nci_nfcee_mode_set handler according to NFC Forum NCI specification.
It is necessary for example for secure element handling.

Signed-off-by: Christophe Ricard christophe-h.ric...@st.com
---
 include/net/nfc/nci.h  |  9 +
 include/net/nfc/nci_core.h |  1 +
 net/nfc/nci/core.c | 21 +
 net/nfc/nci/rsp.c  | 13 +
 4 files changed, 44 insertions(+)

diff --git a/include/net/nfc/nci.h b/include/net/nfc/nci.h
index 6d99e8f..230f227 100644
--- a/include/net/nfc/nci.h
+++ b/include/net/nfc/nci.h
@@ -284,6 +284,14 @@ struct nci_nfcee_discover_cmd {
__u8discovery_action;
 } __packed;
 
+#define NCI_OP_NFCEE_MODE_SET_CMD nci_opcode_pack(NCI_GID_NFCEE_MGMT, 0x01)
+#define NCI_NFCEE_DISABLE  0x00
+#define NCI_NFCEE_ENABLE   0x01
+struct nci_nfcee_mode_set_cmd {
+   __u8nfcee_id;
+   __u8nfcee_mode;
+} __packed;
+
 /* --- */
 /*  NCI Responses  */
 /* --- */
@@ -333,6 +341,7 @@ struct nci_nfcee_discover_rsp {
__u8num_nfcee;
 } __packed;
 
+#define NCI_OP_NFCEE_MODE_SET_RSP nci_opcode_pack(NCI_GID_NFCEE_MGMT, 0x01)
 /* --- */
 /*  NCI Notifications  */
 /* --- */
diff --git a/include/net/nfc/nci_core.h b/include/net/nfc/nci_core.h
index c492266..2f7ffa2 100644
--- a/include/net/nfc/nci_core.h
+++ b/include/net/nfc/nci_core.h
@@ -185,6 +185,7 @@ int nci_recv_frame(struct nci_dev *ndev, struct sk_buff 
*skb);
 int nci_set_config(struct nci_dev *ndev, __u8 id, size_t len, __u8 *val);
 
 int nci_nfcee_discover(struct nci_dev *ndev, u8 action);
+int nci_nfcee_mode_set(struct nci_dev *ndev, u8 nfcee_id, u8 nfcee_mode);
 
 static inline struct sk_buff *nci_skb_alloc(struct nci_dev *ndev,
unsigned int len,
diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index d8cb395..8741a45 100644
--- a/net/nfc/nci/core.c
+++ b/net/nfc/nci/core.c
@@ -473,6 +473,27 @@ int nci_nfcee_discover(struct nci_dev *ndev, u8 action)
 }
 EXPORT_SYMBOL(nci_nfcee_discover);
 
+static void nci_nfcee_mode_set_req(struct nci_dev *ndev, unsigned long opt)
+{
+   struct nci_nfcee_mode_set_cmd *cmd =
+   (struct nci_nfcee_mode_set_cmd *)opt;
+
+   nci_send_cmd(ndev, NCI_OP_NFCEE_MODE_SET_CMD,
+sizeof(struct nci_nfcee_mode_set_cmd), cmd);
+}
+
+int nci_nfcee_mode_set(struct nci_dev *ndev, u8 nfcee_id, u8 nfcee_mode)
+{
+   struct nci_nfcee_mode_set_cmd cmd;
+
+   cmd.nfcee_id = nfcee_id;
+   cmd.nfcee_mode = nfcee_mode;
+
+   return nci_request(ndev, nci_nfcee_mode_set_req, (unsigned long)cmd,
+  msecs_to_jiffies(NCI_CMD_TIMEOUT));
+}
+EXPORT_SYMBOL(nci_nfcee_mode_set);
+
 static int nci_set_local_general_bytes(struct nfc_dev *nfc_dev)
 {
struct nci_dev *ndev = nfc_get_drvdata(nfc_dev);
diff --git a/net/nfc/nci/rsp.c b/net/nfc/nci/rsp.c
index 2e549bd..1fb5b71 100644
--- a/net/nfc/nci/rsp.c
+++ b/net/nfc/nci/rsp.c
@@ -215,6 +215,15 @@ static void nci_nfcee_discover_rsp_packet(struct nci_dev 
*ndev,
nci_req_complete(ndev, discover_rsp-status);
 }
 
+static void nci_nfcee_mode_set_rsp_packet(struct nci_dev *ndev,
+ struct sk_buff *skb)
+{
+   __u8 status = skb-data[0];
+
+   pr_debug(status 0x%x\n, status);
+   nci_req_complete(ndev, status);
+}
+
 void nci_rsp_packet(struct nci_dev *ndev, struct sk_buff *skb)
 {
__u16 rsp_opcode = nci_opcode(skb-data);
@@ -264,6 +273,10 @@ void nci_rsp_packet(struct nci_dev *ndev, struct sk_buff 
*skb)
nci_nfcee_discover_rsp_packet(ndev, skb);
break;
 
+   case NCI_OP_NFCEE_MODE_SET_RSP:
+   nci_nfcee_mode_set_rsp_packet(ndev, skb);
+   break;
+
default:
pr_err(unknown rsp opcode 0x%x\n, rsp_opcode);
break;
-- 
2.1.0

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

[RFC v2 14/14] NFC: st21nfca: Add support for HCI event transaction

The event transaction notifies the Device Host that an action is required
to manage a specific Secure Element application.

Signed-off-by: Christophe Ricard christophe-h.ric...@st.com
---
 drivers/nfc/st21nfca/st21nfca_se.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/nfc/st21nfca/st21nfca_se.c 
b/drivers/nfc/st21nfca/st21nfca_se.c
index 9b93d39..bd13cac 100644
--- a/drivers/nfc/st21nfca/st21nfca_se.c
+++ b/drivers/nfc/st21nfca/st21nfca_se.c
@@ -301,6 +301,8 @@ int st21nfca_connectivity_event_received(struct nfc_hci_dev 
*hdev, u8 host,
u8 event, struct sk_buff *skb)
 {
int r = 0;
+   struct device *dev = hdev-ndev-dev;
+   struct nfc_evt_transaction *transaction;
 
pr_debug(connectivity gate event: %x\n, event);
 
@@ -308,6 +310,25 @@ int st21nfca_connectivity_event_received(struct 
nfc_hci_dev *hdev, u8 host,
case ST21NFCA_EVT_CONNECTIVITY:
break;
case ST21NFCA_EVT_TRANSACTION:
+   if (skb-len  NFC_MIN_AID_LENGTH + 2 
+   skb-data[0] != NFC_EVT_TRANSACTION_AID_TAG)
+   return -EPROTO;
+
+   transaction = (struct nfc_evt_transaction *)devm_kzalloc(dev,
+  skb-len - 2, GFP_KERNEL);
+
+   transaction-aid_len = skb-data[1];
+   memcpy(transaction-aid, skb-data[2], skb-data[1]);
+
+   if (skb-data[transaction-aid_len + 2] !=
+   NFC_EVT_TRANSACTION_PARAMS_TAG)
+   return -EPROTO;
+
+   transaction-params_len = skb-data[transaction-aid_len + 3];
+   memcpy(transaction-params, skb-data +
+  transaction-aid_len + 4, transaction-params_len);
+
+   r = nfc_se_transaction(hdev-ndev, host, transaction);
break;
default:
return 1;
-- 
2.1.0

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

[RFC v2 07/14] NFC: nci: Add nci_core_conn_close handler command/response

Add nci_core_conn_close handler according to NFC Forum NCI specification.
It is necessary for example for secure element handling.

Signed-off-by: Christophe Ricard christophe-h.ric...@st.com
---
 include/net/nfc/nci.h  |  5 +
 include/net/nfc/nci_core.h |  1 +
 net/nfc/nci/core.c | 14 ++
 net/nfc/nci/rsp.c  | 13 +
 4 files changed, 33 insertions(+)

diff --git a/include/net/nfc/nci.h b/include/net/nfc/nci.h
index b8ff50c..deac78b 100644
--- a/include/net/nfc/nci.h
+++ b/include/net/nfc/nci.h
@@ -260,6 +260,9 @@ struct nci_core_conn_create_cmd {
__u8number_destination_params;
struct core_conn_create_dest_spec_params params;
 } __packed;
+
+#define NCI_OP_CORE_CONN_CLOSE_CMD nci_opcode_pack(NCI_GID_CORE, 0x05)
+
 #define NCI_OP_RF_DISCOVER_MAP_CMD nci_opcode_pack(NCI_GID_RF_MGMT, 0x00)
 struct disc_map_config {
__u8rf_protocol;
@@ -352,6 +355,8 @@ struct nci_core_conn_create_rsp {
__u8conn_id;
 } __packed;
 
+#define NCI_OP_CORE_CONN_CLOSE_RSP nci_opcode_pack(NCI_GID_CORE, 0x05)
+
 #define NCI_OP_RF_DISCOVER_MAP_RSP nci_opcode_pack(NCI_GID_RF_MGMT, 0x00)
 
 #define NCI_OP_RF_DISCOVER_RSP nci_opcode_pack(NCI_GID_RF_MGMT, 0x03)
diff --git a/include/net/nfc/nci_core.h b/include/net/nfc/nci_core.h
index 600cf30..e29a130 100644
--- a/include/net/nfc/nci_core.h
+++ b/include/net/nfc/nci_core.h
@@ -188,6 +188,7 @@ int nci_nfcee_discover(struct nci_dev *ndev, u8 action);
 int nci_nfcee_mode_set(struct nci_dev *ndev, u8 nfcee_id, u8 nfcee_mode);
 int nci_core_conn_create(struct nci_dev *ndev,
 struct core_conn_create_dest_spec_params *params);
+int nci_core_conn_close(struct nci_dev *ndev, u8 conn_id);
 
 static inline struct sk_buff *nci_skb_alloc(struct nci_dev *ndev,
unsigned int len,
diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index 61648b4..d47f565 100644
--- a/net/nfc/nci/core.c
+++ b/net/nfc/nci/core.c
@@ -518,6 +518,20 @@ int nci_core_conn_create(struct nci_dev *ndev,
 }
 EXPORT_SYMBOL(nci_core_conn_create);
 
+static void nci_core_conn_close_req(struct nci_dev *ndev, unsigned long opt)
+{
+   __u8 conn_id = opt;
+
+   nci_send_cmd(ndev, NCI_OP_CORE_CONN_CLOSE_CMD, 1, conn_id);
+}
+
+int nci_core_conn_close(struct nci_dev *ndev, u8 conn_id)
+{
+   return nci_request(ndev, nci_core_conn_close_req, conn_id,
+   msecs_to_jiffies(NCI_CMD_TIMEOUT));
+}
+EXPORT_SYMBOL(nci_core_conn_close);
+
 static int nci_set_local_general_bytes(struct nfc_dev *nfc_dev)
 {
struct nci_dev *ndev = nfc_get_drvdata(nfc_dev);
diff --git a/net/nfc/nci/rsp.c b/net/nfc/nci/rsp.c
index ddb0008..c07cd8e 100644
--- a/net/nfc/nci/rsp.c
+++ b/net/nfc/nci/rsp.c
@@ -251,6 +251,15 @@ exit:
nci_req_complete(ndev, status);
 }
 
+static void nci_core_conn_close_rsp_packet(struct nci_dev *ndev,
+  struct sk_buff *skb)
+{
+   __u8 status = skb-data[0];
+
+   pr_debug(status 0x%x\n, status);
+   nci_req_complete(ndev, status);
+}
+
 void nci_rsp_packet(struct nci_dev *ndev, struct sk_buff *skb)
 {
__u16 rsp_opcode = nci_opcode(skb-data);
@@ -284,6 +293,10 @@ void nci_rsp_packet(struct nci_dev *ndev, struct sk_buff 
*skb)
nci_core_conn_create_rsp_packet(ndev, skb);
break;
 
+   case NCI_OP_CORE_CONN_CLOSE_RSP:
+   nci_core_conn_close_rsp_packet(ndev, skb);
+   break;
+
case NCI_OP_RF_DISCOVER_MAP_RSP:
nci_rf_disc_map_rsp_packet(ndev, skb);
break;
-- 
2.1.0

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

Re: Aw: [PATCH v5 3/4] tpm/st33zp24/spi: Add st33zp24 spi phy

2015-01-28 Thread RICARD Christophe


Hi Peter,

A TPM command can be up to 2048 byte, A TPM response can be up to 1024 byte.
Between command and response, there are latency byte (up to 15 usually 
on st33zp24 2 are enough).


Overall when sending a command and expecting an answer we need in worst 
case:
2048 (for the TPM command) + 1024 (for the TPM answer).  We need some 
latency byte before the answer is available (max 15).

We have 2048 + 1024 + 15.

I will go for a define making the code more readable together with a 
comment.


Best Regards
Christophe
Le 28/01/2015 17:48, Peter Huewe a écrit :

Hi Christophe,

sorry to be nitty picky but I still don't get this calculation


+ /* max tpm tx buffer(TPM_BUFSIZE) + max tpm rx buffer(TPM_BUFSIZE / 2)
+ * + MAX_SPI_LATENCY.
+ */
+ phy-spi_xfer.tx_buf = devm_kmalloc(dev-dev, (TPM_BUFSIZE +
+ (TPM_BUFSIZE / 2) + MAX_SPI_LATENCY),
+ GFP_KERNEL);
+ if (!phy-spi_xfer.tx_buf)
+ return -ENOMEM;
+
+ phy-spi_xfer.rx_buf = devm_kmalloc(dev-dev, (TPM_BUFSIZE +
+ (TPM_BUFSIZE / 2) + MAX_SPI_LATENCY),
+ GFP_KERNEL);
+ if (!phy-spi_xfer.rx_buf)
+ return -ENOMEM;
  


and the comment
+ /* max tpm tx buffer(TPM_BUFSIZE) + max tpm rx buffer(TPM_BUFSIZE / 2)
+ * + MAX_SPI_LATENCY.
does not help either.



Why do you define TPM_BUFSIZE as 2048, add TPM_BUFSIZE/2 and something called 
MAX_SPI_LATENCY to it to use it as your buffer size?
Latency is for me something timing related.

Since you use this TPM_BUFSIZE only in these two lines I'd be happy with either
define which has this magical 2048+2014+15
or (maybe better) add a reasonable comment describing the meaning of this 
strange calculation.


Thanks,
Peter


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

[PATCH v5 5/5] iio: common: ssp_sensors: Add sensorhub gyroscope sensor

This patch adds gyroscope iio driver which uses sensorhub as data
provider.

Signed-off-by: Karol Wrona k.wr...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/iio/gyro/Makefile  |2 +
 drivers/iio/gyro/ssp_gyro_sensor.c |  168 
 2 files changed, 170 insertions(+)
 create mode 100644 drivers/iio/gyro/ssp_gyro_sensor.c

diff --git a/drivers/iio/gyro/Makefile b/drivers/iio/gyro/Makefile
index 36a3877..f46341b 100644
--- a/drivers/iio/gyro/Makefile
+++ b/drivers/iio/gyro/Makefile
@@ -16,6 +16,8 @@ itg3200-y   := itg3200_core.o
 itg3200-$(CONFIG_IIO_BUFFER) += itg3200_buffer.o
 obj-$(CONFIG_ITG3200)   += itg3200.o
 
+obj-$(CONFIG_IIO_SSP_SENSORS_COMMONS) += ssp_gyro_sensor.o
+
 obj-$(CONFIG_IIO_ST_GYRO_3AXIS) += st_gyro.o
 st_gyro-y := st_gyro_core.o
 st_gyro-$(CONFIG_IIO_BUFFER) += st_gyro_buffer.o
diff --git a/drivers/iio/gyro/ssp_gyro_sensor.c 
b/drivers/iio/gyro/ssp_gyro_sensor.c
new file mode 100644
index 000..0a8afdd
--- /dev/null
+++ b/drivers/iio/gyro/ssp_gyro_sensor.c
@@ -0,0 +1,168 @@
+/*
+ *  Copyright (C) 2014, Samsung Electronics Co. Ltd. All Rights Reserved.
+ *
+ *  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 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 linux/iio/common/ssp_sensors.h
+#include linux/iio/iio.h
+#include linux/iio/kfifo_buf.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include ../common/ssp_sensors/ssp_iio_sensor.h
+
+#define SSP_CHANNEL_COUNT 3
+
+#define SSP_GYROSCOPE_NAME ssp-gyroscope
+static const char ssp_gyro_name[] = SSP_GYROSCOPE_NAME;
+
+enum ssp_gyro_3d_channel {
+   SSP_CHANNEL_SCAN_INDEX_X,
+   SSP_CHANNEL_SCAN_INDEX_Y,
+   SSP_CHANNEL_SCAN_INDEX_Z,
+   SSP_CHANNEL_SCAN_INDEX_TIME,
+};
+
+static int ssp_gyro_read_raw(struct iio_dev *indio_dev,
+struct iio_chan_spec const *chan, int *val,
+int *val2, long mask)
+{
+   u32 t;
+   struct ssp_data *data = dev_get_drvdata(indio_dev-dev.parent-parent);
+
+   switch (mask) {
+   case IIO_CHAN_INFO_SAMP_FREQ:
+   t = ssp_get_sensor_delay(data, SSP_GYROSCOPE_SENSOR);
+   ssp_convert_to_freq(t, val, val2);
+   return IIO_VAL_INT_PLUS_MICRO;
+   default:
+   break;
+   }
+
+   return -EINVAL;
+}
+
+static int ssp_gyro_write_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan, int val,
+ int val2, long mask)
+{
+   int ret;
+   struct ssp_data *data = dev_get_drvdata(indio_dev-dev.parent-parent);
+
+   switch (mask) {
+   case IIO_CHAN_INFO_SAMP_FREQ:
+   ret = ssp_convert_to_time(val, val2);
+   ret = ssp_change_delay(data, SSP_GYROSCOPE_SENSOR, ret);
+   if (ret  0)
+   dev_err(indio_dev-dev, gyro sensor enable fail\n);
+
+   return ret;
+   default:
+   break;
+   }
+
+   return -EINVAL;
+}
+
+static struct iio_info ssp_gyro_iio_info = {
+   .read_raw = ssp_gyro_read_raw,
+   .write_raw = ssp_gyro_write_raw,
+};
+
+static const unsigned long ssp_gyro_scan_mask[] = { 0x07, 0, };
+
+static const struct iio_chan_spec ssp_gyro_channels[] = {
+   SSP_CHANNEL_AG(IIO_ANGL_VEL, IIO_MOD_X, SSP_CHANNEL_SCAN_INDEX_X),
+   SSP_CHANNEL_AG(IIO_ANGL_VEL, IIO_MOD_Y, SSP_CHANNEL_SCAN_INDEX_Y),
+   SSP_CHANNEL_AG(IIO_ANGL_VEL, IIO_MOD_Z, SSP_CHANNEL_SCAN_INDEX_Z),
+   SSP_CHAN_TIMESTAMP(SSP_CHANNEL_SCAN_INDEX_TIME),
+};
+
+static int ssp_process_gyro_data(struct iio_dev *indio_dev, void *buf,
+int64_t timestamp)
+{
+   return ssp_common_process_data(indio_dev, buf, SSP_GYROSCOPE_SIZE,
+  timestamp);
+}
+
+static const struct iio_buffer_setup_ops ssp_gyro_buffer_ops = {
+   .postenable = ssp_common_buffer_postenable,
+   .postdisable = ssp_common_buffer_postdisable,
+};
+
+static int ssp_gyro_probe(struct platform_device *pdev)
+{
+   int ret;
+   struct iio_dev *indio_dev;
+   struct ssp_sensor_data *spd;
+   struct iio_buffer *buffer;
+
+   indio_dev = devm_iio_device_alloc(pdev-dev, sizeof(*spd));
+   if (!indio_dev)
+   return -ENOMEM;
+
+   spd = iio_priv(indio_dev);
+
+   spd-process_data = ssp_process_gyro_data;
+   spd-type = SSP_GYROSCOPE_SENSOR;
+
+   indio_dev-name = ssp_gyro_name;
+

[RFC v2 03/14] NFC: nci: Add NCI NFCEE constant

Add NFCEE NCI constant for:
- NFCEE Interface/Protocols
- Destination type
- Destination-specific parameters type
- NFCEE Discovery Action

Signed-off-by: Christophe Ricard christophe-h.ric...@st.com
---
 include/net/nfc/nci.h | 48 
 1 file changed, 48 insertions(+)

diff --git a/include/net/nfc/nci.h b/include/net/nfc/nci.h
index e7257a4..6d99e8f 100644
--- a/include/net/nfc/nci.h
+++ b/include/net/nfc/nci.h
@@ -62,6 +62,25 @@
 #define NCI_STATUS_NFCEE_PROTOCOL_ERROR0xc2
 #define NCI_STATUS_NFCEE_TIMEOUT_ERROR 0xc3
 
+/* NFCEE Interface/Protocols */
+#define NCI_NFCEE_INTERFACE_APDU   0x00
+#define NCI_NFCEE_INTERFACE_HCI_ACCESS 0x01
+#define NCI_NFCEE_INTERFACE_TYPE3_CMD_SET  0x02
+#define NCI_NFCEE_INTERFACE_TRANSPARENT0x03
+
+/* Destination type */
+#define NCI_DESTINATION_NFCC_LOOPBACK  0x01
+#define NCI_DESTINATION_REMOTE_NFC_ENDPOINT0x02
+#define NCI_DESTINATION_NFCEE  0x03
+
+/* Destination-specific parameters type */
+#define NCI_DESTINATION_SPECIFIC_PARAM_RF_TYPE 0x00
+#define NCI_DESTINATION_SPECIFIC_PARAM_NFCEE_TYPE  0x01
+
+/* NFCEE Discovery Action */
+#define NCI_NFCEE_DISCOVERY_ACTION_DISABLE 0x00
+#define NCI_NFCEE_DISCOVERY_ACTION_ENABLE  0x01
+
 /* NCI RF Technology and Mode */
 #define NCI_NFC_A_PASSIVE_POLL_MODE0x00
 #define NCI_NFC_B_PASSIVE_POLL_MODE0x01
@@ -260,6 +279,11 @@ struct nci_rf_deactivate_cmd {
__u8type;
 } __packed;
 
+#define NCI_OP_NFCEE_DISCOVER_CMD nci_opcode_pack(NCI_GID_NFCEE_MGMT, 0x00)
+struct nci_nfcee_discover_cmd {
+   __u8discovery_action;
+} __packed;
+
 /* --- */
 /*  NCI Responses  */
 /* --- */
@@ -303,6 +327,12 @@ struct nci_core_set_config_rsp {
 
 #define NCI_OP_RF_DEACTIVATE_RSP   nci_opcode_pack(NCI_GID_RF_MGMT, 0x06)
 
+#define NCI_OP_NFCEE_DISCOVER_RSP nci_opcode_pack(NCI_GID_NFCEE_MGMT, 0x00)
+struct nci_nfcee_discover_rsp {
+   __u8status;
+   __u8num_nfcee;
+} __packed;
+
 /* --- */
 /*  NCI Notifications  */
 /* --- */
@@ -430,4 +460,22 @@ struct nci_rf_deactivate_ntf {
__u8reason;
 } __packed;
 
+#define NCI_OP_NFCEE_DISCOVER_NTF nci_opcode_pack(NCI_GID_NFCEE_MGMT, 0x00)
+struct nci_nfcee_supported_protocol {
+   __u8num_protocol;
+   __u8supported_protocol[0];
+} __packed;
+
+struct nci_nfcee_information_tlv {
+   __u8num_tlv;
+   __u8information_tlv[0];
+} __packed;
+
+struct nci_nfcee_discover_ntf {
+   __u8nfcee_id;
+   __u8nfcee_status;
+   struct nci_nfcee_supported_protocol supported_protocols;
+   struct nci_nfcee_information_tlvinformation_tlv;
+} __packed;
+
 #endif /* __NCI_H */
-- 
2.1.0

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

[RFC v2 02/14] NFC: nci: Make nci_request available for nfc driver

NFC drivers may need to send raw data over NCI. Make this function
available in the NCI core framework.

Signed-off-by: Christophe Ricard christophe-h.ric...@st.com
---
 include/net/nfc/nci_core.h | 3 +++
 net/nfc/nci/core.c | 8 
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/include/net/nfc/nci_core.h b/include/net/nfc/nci_core.h
index 161e4c4..6cc3ffc 100644
--- a/include/net/nfc/nci_core.h
+++ b/include/net/nfc/nci_core.h
@@ -218,6 +218,9 @@ int nci_send_data(struct nci_dev *ndev, __u8 conn_id, 
struct sk_buff *skb);
 void nci_data_exchange_complete(struct nci_dev *ndev, struct sk_buff *skb,
__u8 conn_id, int err);
 void nci_clear_target_list(struct nci_dev *ndev);
+int nci_request(struct nci_dev *ndev,
+   void (*req)(struct nci_dev *ndev, unsigned long opt),
+   unsigned long opt, __u32 timeout);
 
 /* - NCI requests - */
 #define NCI_REQ_DONE   0
diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index c29f3ce..fa07299 100644
--- a/net/nfc/nci/core.c
+++ b/net/nfc/nci/core.c
@@ -109,10 +109,9 @@ static int __nci_request(struct nci_dev *ndev,
return rc;
 }
 
-static inline int nci_request(struct nci_dev *ndev,
- void (*req)(struct nci_dev *ndev,
- unsigned long opt),
- unsigned long opt, __u32 timeout)
+inline int nci_request(struct nci_dev *ndev,
+   void (*req)(struct nci_dev *ndev, unsigned long opt),
+   unsigned long opt, __u32 timeout)
 {
int rc;
 
@@ -126,6 +125,7 @@ static inline int nci_request(struct nci_dev *ndev,
 
return rc;
 }
+EXPORT_SYMBOL_GPL(nci_request);
 
 static void nci_reset_req(struct nci_dev *ndev, unsigned long opt)
 {
-- 
2.1.0

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

[RFC v2 11/14] NFC: nci: Add support RF_NFCEE_ACTION_NTF

RF NFCEE Action is the mechanism used to indicate that an action involving one 
of the NFCEEs
in the device has occurred that may be of interest to the DH.

This may happen for example when doing an RF Transaction with a payment reader.

Signed-off-by: Christophe Ricard christophe-h.ric...@st.com
---
 include/net/nfc/nci.h |  8 
 net/nfc/nci/ntf.c | 11 +++
 2 files changed, 19 insertions(+)

diff --git a/include/net/nfc/nci.h b/include/net/nfc/nci.h
index deac78b..6c1beb2 100644
--- a/include/net/nfc/nci.h
+++ b/include/net/nfc/nci.h
@@ -499,6 +499,14 @@ struct nci_rf_deactivate_ntf {
__u8reason;
 } __packed;
 
+#define NCI_OP_RF_NFCEE_ACTION_NTF nci_opcode_pack(NCI_GID_RF_MGMT, 0x09)
+struct nci_rf_nfcee_action_ntf {
+   __u8 nfcee_id;
+   __u8 trigger;
+   __u8 supported_data_length;
+   __u8 supported_data[0];
+} __packed;
+
 #define NCI_OP_NFCEE_DISCOVER_NTF nci_opcode_pack(NCI_GID_NFCEE_MGMT, 0x00)
 struct nci_nfcee_supported_protocol {
__u8num_protocol;
diff --git a/net/nfc/nci/ntf.c b/net/nfc/nci/ntf.c
index a1ca2b4..4cdb95d 100644
--- a/net/nfc/nci/ntf.c
+++ b/net/nfc/nci/ntf.c
@@ -749,6 +749,12 @@ exit:
nci_req_complete(ndev, status);
 }
 
+static void nci_nfcee_action_ntf_packet(struct nci_dev *ndev,
+   struct sk_buff *skb)
+{
+   pr_debug(\n);
+}
+
 void nci_ntf_packet(struct nci_dev *ndev, struct sk_buff *skb)
 {
__u16 ntf_opcode = nci_opcode(skb-data);
@@ -790,6 +796,11 @@ void nci_ntf_packet(struct nci_dev *ndev, struct sk_buff 
*skb)
case NCI_OP_NFCEE_DISCOVER_NTF:
nci_nfcee_discover_ntf_packet(ndev, skb);
break;
+
+   case NCI_OP_RF_NFCEE_ACTION_NTF:
+   nci_nfcee_action_ntf_packet(ndev, skb);
+   break;
+
default:
pr_err(unknown ntf opcode 0x%x\n, ntf_opcode);
break;
-- 
2.1.0

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

[RFC v2 01/14] NFC: nci: Add dynamic conn_id NCI concept.

The current NCI core only support static conn_id for RF communication.
For other NFC features such as Secure Element communication, we may need
additional conn_id.

In order to address each conn_id dynamically including statics one such as
NCI_STATIC_RF_CONN_ID, we introduce 2 tables referring to conn_id context
by conn_id or by ID (RF Discovery ID or NFCEE ID).

Signed-off-by: Christophe Ricard christophe-h.ric...@st.com
---
 include/net/nfc/nci_core.h | 30 ++-
 net/nfc/nci/core.c | 37 +++-
 net/nfc/nci/data.c | 72 --
 net/nfc/nci/ntf.c  | 45 +++--
 net/nfc/nci/rsp.c  | 22 +-
 5 files changed, 167 insertions(+), 39 deletions(-)

diff --git a/include/net/nfc/nci_core.h b/include/net/nfc/nci_core.h
index 9e51bb4..161e4c4 100644
--- a/include/net/nfc/nci_core.h
+++ b/include/net/nfc/nci_core.h
@@ -82,6 +82,23 @@ struct nci_ops {
 
 #define NCI_MAX_SUPPORTED_RF_INTERFACES4
 #define NCI_MAX_DISCOVERED_TARGETS 10
+#define NCI_MAX_NUM_NFCEE   255
+#define NCI_MAX_CONN_ID7
+
+struct nci_conn_info {
+   struct list_head list;
+   __u8id; /* can be an RF Discovery ID or an NFCEE ID */
+   __u8conn_id;
+   __u8max_pkt_payload_len;
+
+   atomic_t credits_cnt;
+   __u8 initial_num_credits;
+
+   data_exchange_cb_t  data_exchange_cb;
+   void *data_exchange_cb_context;
+
+   struct sk_buff *rx_skb;
+};
 
 /* NCI Core structures */
 struct nci_dev {
@@ -95,7 +112,9 @@ struct nci_dev {
unsigned long   flags;
 
atomic_tcmd_cnt;
-   atomic_tcredits_cnt;
+   __u8cur_conn_id;
+
+   struct list_headconn_info_list;
 
struct timer_list   cmd_timer;
struct timer_list   data_timer;
@@ -141,13 +160,10 @@ struct nci_dev {
__u8manufact_id;
__u32   manufact_specific_info;
 
-   /* received during NCI_OP_RF_INTF_ACTIVATED_NTF */
-   __u8max_data_pkt_payload_size;
-   __u8initial_num_credits;
+   /* Save RF Discovery ID or NFCEE ID under conn_create */
+   __u8cur_id;
 
/* stored during nci_data_exchange */
-   data_exchange_cb_t  data_exchange_cb;
-   void*data_exchange_cb_context;
struct sk_buff  *rx_data_reassembly;
 
/* stored during intf_activated_ntf */
@@ -200,7 +216,7 @@ void nci_rx_data_packet(struct nci_dev *ndev, struct 
sk_buff *skb);
 int nci_send_cmd(struct nci_dev *ndev, __u16 opcode, __u8 plen, void *payload);
 int nci_send_data(struct nci_dev *ndev, __u8 conn_id, struct sk_buff *skb);
 void nci_data_exchange_complete(struct nci_dev *ndev, struct sk_buff *skb,
-   int err);
+   __u8 conn_id, int err);
 void nci_clear_target_list(struct nci_dev *ndev);
 
 /* - NCI requests - */
diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index 51feb5e..c29f3ce 100644
--- a/net/nfc/nci/core.c
+++ b/net/nfc/nci/core.c
@@ -712,6 +712,12 @@ static int nci_transceive(struct nfc_dev *nfc_dev, struct 
nfc_target *target,
 {
struct nci_dev *ndev = nfc_get_drvdata(nfc_dev);
int rc;
+   struct nci_conn_info*conn_info;
+
+   list_for_each_entry(conn_info, ndev-conn_info_list, list) {
+   if (conn_info-conn_id == NCI_STATIC_RF_CONN_ID)
+   break;
+   }
 
pr_debug(target_idx %d, len %d\n, target-idx, skb-len);
 
@@ -724,8 +730,8 @@ static int nci_transceive(struct nfc_dev *nfc_dev, struct 
nfc_target *target,
return -EBUSY;
 
/* store cb and context to be used on receiving data */
-   ndev-data_exchange_cb = cb;
-   ndev-data_exchange_cb_context = cb_context;
+   conn_info-data_exchange_cb = cb;
+   conn_info-data_exchange_cb_context = cb_context;
 
rc = nci_send_data(ndev, NCI_STATIC_RF_CONN_ID, skb);
if (rc)
@@ -913,6 +919,7 @@ int nci_register_device(struct nci_dev *ndev)
(unsigned long) ndev);
 
mutex_init(ndev-req_lock);
+   INIT_LIST_HEAD(ndev-conn_info_list);
 
rc = nfc_register_device(ndev-nfc_dev);
if (rc)
@@ -938,12 +945,20 @@ EXPORT_SYMBOL(nci_register_device);
  */
 void nci_unregister_device(struct nci_dev *ndev)
 {
+   struct nci_conn_info*conn_info, *n;
+
nci_close_device(ndev);
 
destroy_workqueue(ndev-cmd_wq);
destroy_workqueue(ndev-rx_wq);
destroy_workqueue(ndev-tx_wq);
 
+   list_for_each_entry_safe(conn_info, n, ndev-conn_info_list, list) {
+list_del(conn_info-list);
+   /* conn_info is allocated with devm_kzalloc */
+}
+
+

[PATCH 2/2] mmc: pwrseq: Update document with multiple gpios support

This patch updates the text and examples the mmc pwrseq document with multiple
gpios support. Typical example is WLAN and BT chips on SDIO bus.

Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
 Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt 
b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
index da333d9..1a86efa 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt
@@ -8,13 +8,14 @@ Required properties:
 - compatible : contains mmc-pwrseq-simple.
 
 Optional properties:
-- reset-gpios : contains a GPIO specifier. The reset GPIO is asserted at
-   initialization and prior we start the power up procedure of the card. It
+- reset-gpios : contains list of GPIO specifiers. The reset GPIOs are asserted 
at
+   initialization and prior we start the power up procedure of the card. 
They
will be de-asserted right after the power has been provided to the card.
 
 Example:
 
sdhci0_pwrseq {
compatible = mmc-pwrseq-simple;
-   reset-gpios = gpio1 12 0;
+   /* WLAN and BT reset */
+   reset-gpios = gpio1 12 0, gpio1 14 0;
}
-- 
1.9.1

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

Re: [PATCH 0/2] mmc: pwrseq: Add support to multiple gpios in pwrseq simple

On 28 January 2015 at 14:16, Srinivas Kandagatla
srinivas.kandaga...@linaro.org wrote:
 This patchset adds support to reset/powerup multiple gpio pins on a given
 sdio bus. The use case is simple, on sdio we could have multiple devices
 like WLAN, BT which are controlled by there own reset lines. So having
 multiple reset is something more useful in such cases.

 Without this patch I could not get BT and WLAN working at same time on 
 IFC6410.

 Thanks,
 srini

 Srinivas Kandagatla (2):
   mmc: pwrseq: Add support to control multiple gpios in simple pwrseq
   mmc: pwrseq: Update document with multiple gpios support

  .../devicetree/bindings/mmc/mmc-pwrseq-simple.txt  |  7 ++-
  drivers/mmc/core/pwrseq_simple.c   | 64 
 +++---
  2 files changed, 49 insertions(+), 22 deletions(-)

 --
 1.9.1


Hi Srinivas,

I noticed that Javier a few hours ago posted a patchset which
implement the same thing as yours, I guess this is a wanted feature.
:-)

I am going to review Javier's patchset, would be nice if you could
have a look at it as well.

Kind regards
Uffe
--
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: Aw: [PATCH v5 3/4] tpm/st33zp24/spi: Add st33zp24 spi phy

2015-01-28 Thread Jason Gunthorpe

On Wed, Jan 28, 2015 at 08:13:33PM +0100, RICARD Christophe wrote:
 Hi Peter,
 
 A TPM command can be up to 2048 byte, A TPM response can be up to 1024 byte.
 Between command and response, there are latency byte (up to 15
 usually on st33zp24 2 are enough).
 
 Overall when sending a command and expecting an answer we need in
 worst case:
 2048 (for the TPM command) + 1024 (for the TPM answer).  We need
 some latency byte before the answer is available (max 15).
 We have 2048 + 1024 + 15.
 
 I will go for a define making the code more readable together with a
 comment.

You can probably just make these static arrays inside your priv
structure and drop these independent allocations:

 + phy-spi_xfer.tx_buf = devm_kmalloc(dev-dev, (TPM_BUFSIZE +
 + (TPM_BUFSIZE / 2) + MAX_SPI_LATENCY),
 + GFP_KERNEL);

Jason
--
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 RESEND v3 2/3] irqchip: vf610-mscm: dt-bindings: add MSCM bindings

2015-01-28 Thread Stefan Agner

On 2015-01-26 15:18, Stefan Agner wrote:
On 2015-01-26 14:36, Mark Rutland wrote:
On Thu, Jan 15, 2015 at 08:04:05AM +, Stefan Agner wrote:
Add binding documentation for Miscellaneous System Control Module
found in Freescale Vybrid SoC's.

Signed-off-by: Stefan Agner ste...@agner.ch
---
.../bindings/arm/freescale/fsl,vf610-mscm.txt | 19
+++
1 file changed, 19 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt

diff --git
a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt
b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt
new file mode 100644
index 000..e051b88
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm.txt
@@ -0,0 +1,19 @@
+Freescale Vybrid Miscellaneous System Control Module
+
+The MSCM IP contains Access Control and TrustZone Security hardware,
+CPU Configuration registers and Interrupt Router control.
+
+Required properties:
+- compatible : fsl,vf610-mscm, syscon

I'm a little concerned by this also being a syscon. What other devices
need to refer to this block as a syscon?

The block offers several functionality. I'm happy we can discuss this
here a bit more in depth, since I'm really not sure if the current
solution is the best solution...

Due to the general rule to not split hardware modules, I hesitated to
make different nodes out of it. However, this module has some quite
distinct sub-modules, hence I guess it would be also feasible to do so:

0x40001000-0x4000105C - Processor information e.g. which processor ID is
the accessing processor (processor identity), cache size etc...
0x40001800-0x40001820 - CPU2CPU directed interrupt generation/clear
registers...
0x40001880-0x4000195E - the actual interrupt router
0x40001C00-0x40001DDC - ACTZS TrustZone registers...

This driver accesses the first and the third block. The first block is
necessary since the driver needs to know which CPU ID it is running on
to actually program the interrupt router (Note: this is a heterogeneous
multiprocessing system. This are actually treated as two independent UP
systems, considering that Linux can also run on the Cortex-M4).

Hence, the syscon definition which would allow to access other areas as
needed, especially the processor information might be needed by any
other peripheral (driver) which needs to know what CPU it is running on.
What do you think?

OTH, we could as well split it up in three or even four nodes. The MSCM
interrupt router part just needs to access the the MSCM processor
information part somehow (syscon?)...

Fwiw, in our downstream kernel, the CPU2CPU interrupts are used for
Freescales messaging system (MCC). I hacked a special interface in that
early version of this driver, to export this functionality. But then I
guess such a functionality should not affect the device tree
bindings...?
http://git.toradex.com/cgit/linux-toradex.git/commit/?h=toradex_vf_3.18-nextid=6f0bbad6b805cf2014eec54531dbe4ddb4867a91

For detailed information, the module is documented in the public
reference manual, chapter 64.
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=VF6xxfpsp=1tab=Documentation_Tab

The MSCM module described as individual sub-modules would look something
like this:

mscm_cpucfg: cpucfg@40001000 {
compatible = fsl,vf610-mscm-cpucfg, syscon;
reg = 0x40001000 0x800;
};

mscm_ir: interrupt-controller@40001800 {
compatible = fsl,vf610-mscm-ir;
reg = 0x40001800 0x400;
fsl,cpucfg = mscm_cpucfg;
interrupt-controller;
#interrupt-cells = 2;
interrupt-parent = intc;
};

With this layout, only the CPU information part would be syscon, whereas
the MSCM interrupt router driver would be its first user. The TrustZone
registers are left out for now...

What do you think? Advice appreciated.

--
Stefan

+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Two cells, interrupt number and flags (IRQ type)

What numbers and flags are valid?

The first cell is the hardware interrupt ID according to the MSCM
interrupt router. The flags gets passed to the GIC interrupt controller
only, hence those are the one which are supported by the GIC controller.

Will add that information, thx.

--
Stefan

Mark.

+- reg : the register range of the MSCM module
+
+Example:
+ mscm: mscm@40001000 {
+ compatible = fsl,vf610-mscm, syscon;
+ interrupt-controller;
+ #interrupt-cells = 2;
+ interrupt-parent = intc;
+ reg = 0x40001000 0x1000;
+ }
--
2.2.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

Re: [PATCH v4 3/6] of: fix size when dma-range is not used

2015-01-28 Thread Catalin Marinas

On Tue, Jan 27, 2015 at 06:55:15PM +, Murali Karicheri wrote:
 On 01/27/2015 06:27 AM, Robin Murphy wrote:
  On 23/01/15 22:32, Murali Karicheri wrote:
  Fix the dma-range size when the DT attribute is missing. i.e set size to
  dev-coherent_dma_mask + 1 instead of dev-coherent_dma_mask. To detect
  overflow when mask is set to max of u64, add a check, log error and
  return.
  Some platform use mask format for size in DTS. So add a work around to
  catch this and fix.
 
  Cc: Joerg Roedel j...@8bytes.org
  Cc: Grant Likely grant.lik...@linaro.org
  Cc: Rob Herring robh...@kernel.org
  Cc: Bjorn Helgaas bhelg...@google.com
  Cc: Will Deacon will.dea...@arm.com
  Cc: Russell King li...@arm.linux.org.uk
  Cc: Arnd Bergmann a...@arndb.de
  Cc: Suravee Suthikulpanit suravee.suthikulpa...@amd.com
 
  Signed-off-by: Murali Karicheri m-kariche...@ti.com
  ---
  drivers/of/device.c | 14 +-
  1 file changed, 13 insertions(+), 1 deletion(-)
 
  diff --git a/drivers/of/device.c b/drivers/of/device.c
  index 2de320d..0a5ff54 100644
  --- a/drivers/of/device.c
  +++ b/drivers/of/device.c
  @@ -105,12 +105,24 @@ void of_dma_configure(struct device *dev, struct
  device_node *np)
  ret = of_dma_get_range(np, dma_addr, paddr, size);
  if (ret  0) {
  dma_addr = offset = 0;
  - size = dev-coherent_dma_mask;
  + size = dev-coherent_dma_mask + 1;
  } else {
  offset = PFN_DOWN(paddr - dma_addr);
  + /*
  + * Add a work around to treat the size as mask + 1 in case
  + * it is defined in DT as a mask.
  + */
  + if (size  1)
  + size = size + 1;
  dev_dbg(dev, dma_pfn_offset(%#08lx)\n, offset);
  }
 
  + /* if size is 0, we have an overflow of u64 */
  + if (!size) {
  + dev_err(dev, invalid size\n);
  + return;
  + }
  +
 
  This seems potentially fragile to dodgy DTs given that we might also be
  using size to make a mask later. Would it make sense to double-up a
  sanity check as mask-format detection? Something like:
 
  if is_power_of_2(size)
  // use size
  else if is_power_of_2(size + 1)
  // use size + 1
  else
  // cry
 
 How about having the logic like this?
 
   ret = of_dma_get_range(np, dma_addr, paddr, size);
   if (ret  0) {
   dma_addr = offset = 0;
   size = dev-coherent_dma_mask + 1;
   } else {
   offset = PFN_DOWN(paddr - dma_addr);
   dev_dbg(dev, dma_pfn_offset(%#08lx)\n, offset);
   }
 
   if (is_power_of_2(size + 1))
   size = size + 1;
   else if (!is_power_of_2(size))
   {
   dev_err(dev, invalid size\n);
   return;
   }

In of_dma_configure(), we currently assume that the default coherent
mask is 32-bit. In this thread:

http://article.gmane.org/gmane.linux.kernel/1835096

we talked about setting the coherent mask based on size automatically.
I'm not sure about the size but I think we can assume is 32-bit mask + 1
if it is not specified in the DT. Instead of just assuming a default
mask, let's assume a default size and create the mask based on this
(untested):

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 5b33c6a21807..9ff8d1286b44 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -170,10 +170,10 @@ static void of_dma_configure(struct device *dev)
struct iommu_ops *iommu;
 
/*
-* Set default dma-mask to 32 bit. Drivers are expected to setup
-* the correct supported dma_mask.
+* Set default size to cover the 32-bit. Drivers are expected to setup
+* the correct size and dma_mask.
 */
-   dev-coherent_dma_mask = DMA_BIT_MASK(32);
+   size = 1ULL  32;
 
/*
 * Set it to coherent_dma_mask by default if the architecture
@@ -185,13 +185,24 @@ static void of_dma_configure(struct device *dev)
ret = of_dma_get_range(dev-of_node, dma_addr, paddr, size);
if (ret  0) {
dma_addr = offset = 0;
-   size = dev-coherent_dma_mask;
} else {
offset = PFN_DOWN(paddr - dma_addr);
dev_dbg(dev, dma_pfn_offset(%#08lx)\n, dev-dma_pfn_offset);
}
dev-dma_pfn_offset = offset;
 
+   /*
+* Workaround for DTs setting the size to a mask or 0.
+*/
+   if (is_power_of_2(size + 1))
+   size += 1;
+
+   /*
+* Coherent DMA masks larger than 32-bit must be explicitly set by the
+* driver.
+*/
+   dev-coherent_dma_mask = min(DMA_BIT_MASK(32), 
DMA_BIT_MASK(ilog2(size)));
+
coherent = of_dma_is_coherent(dev-of_node);
dev_dbg(dev, device is%sdma coherent\n,
coherent ?   :  not );

-- 
Catalin
--
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/7] ARM: vf-colibri: add SPI support and enable MCP2515 CAN

2015-01-28 Thread Stefan Agner

On 2015-01-27 11:57, Bhuvanchandra DV wrote:
 MCP2515 CAN controller is available on Colibri Evaluation board.
 Hence enable MCP2515 CAN.
 
 Signed-off-by: Bhuvanchandra DV bhuvanchandra...@toradex.com
 ---
  arch/arm/boot/dts/vf-colibri-eval-v3.dtsi | 31 
 +++
  arch/arm/boot/dts/vf-colibri.dtsi | 15 +++
  2 files changed, 46 insertions(+)
 
 diff --git a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
 b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
 index 36cafbf..69364b0 100644
 --- a/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
 +++ b/arch/arm/boot/dts/vf-colibri-eval-v3.dtsi
 @@ -12,6 +12,12 @@
   bootargs = console=ttyLP0,115200;
   };
  
 + clk16m: clk16m {
 + compatible = fixed-clock;
 + #clock-cells = 0;
 + clock-frequency = 1600;
 + };
 +
   regulators {
   compatible = simple-bus;
   #address-cells = 1;
 @@ -47,6 +53,21 @@
   status  = okay;
  };
  
 +dspi1 {
 + status = okay;
 +
 + can2: mcp2515@0 {


The device tree usage website states (devicetree.org): nodes are named
according to what kind of device it represents...

You can use the label to specify the type, e.g. I would suggest to use
something like:


mcp2515can: can@0 {
...




 + compatible = microchip,mcp2515;
 + pinctrl-names = default;
 + pinctrl-0 = pinctrl_can_int;
 + reg = 0;
 + clocks = clk16m;
 + spi-max-frequency = 1000;
 + interrupt-parent = gpio2;

The interrupt line of the MCP2515 is connected to SODIMM 73, which is
PORT1[11] on Vybrid. My recent renaming of the GPIO's has been merged
already:
https://lkml.org/lkml/2015/1/16/419

Hence, this should be updated to gpio1.


 + interrupts = 11 GPIO_ACTIVE_LOW;
 + };
 +};
 +
  esdhc1 {
   pinctrl-names = default;
   pinctrl-0 = pinctrl_esdhc1;
 @@ -94,3 +115,13 @@
  usbh1 {
   vbus-supply = usbh_vbus_reg;
  };
 +
 +iomuxc {
 + vf610-colibri {
 + pinctrl_can_int: can_int {
 + fsl,pins = 
 + VF610_PAD_PTB21__GPIO_430x22ed
 + ;
 + };
 + };
 +};
 diff --git a/arch/arm/boot/dts/vf-colibri.dtsi
 b/arch/arm/boot/dts/vf-colibri.dtsi
 index 5c2b732..fbef082 100644
 --- a/arch/arm/boot/dts/vf-colibri.dtsi
 +++ b/arch/arm/boot/dts/vf-colibri.dtsi
 @@ -23,6 +23,12 @@
   status = okay;
  };
  
 +dspi1 {
 + bus-num = 1;
 + pinctrl-names = default;
 + pinctrl-0 = pinctrl_dspi1;
 +};
 +
  edma0 {
   status = okay;
  };
 @@ -107,6 +113,15 @@
   ;
   };
  
 + pinctrl_dspi1: dspi1grp {
 + fsl,pins = 
 + VF610_PAD_PTD5__DSPI1_CS0   0x33e2
 + VF610_PAD_PTD6__DSPI1_SIN   0x33e1
 + VF610_PAD_PTD7__DSPI1_SOUT  0x33e2
 + VF610_PAD_PTD8__DSPI1_SCK   0x33e2
 + ;
 + };
 +
   pinctrl_esdhc1: esdhc1grp {
   fsl,pins = 
   VF610_PAD_PTA24__ESDHC1_CLK 0x31ef


The rest looks good, thx.

--
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 5/5] ARM: dts: exynos5250-snow: Enable wifi power-on

2015-01-28 Thread Arend van Spriel


On 01/28/15 11:10, Javier Martinez Canillas wrote:

The Snow board has a MMC/SDIO wifi chip that is always powered but it
needs a power sequence involving a reset (active low) and an enable
(active high) pins. Both pins are marked as active low since the MMC
simple power sequence driver asserts the pins prior to the card power
up procedure and de-asserts the pins after the card has been powered.

So the reset line will be left de-asserted and the enable pin will be
left asserted.

The chip also needs an external 32kHz reference clock to be operational
that is by the MAX77686 PMIC clock.

Add a simple MMC power sequence provider for the wifi MMC/SDIO slot.

Signed-off-by: Javier Martinez Canillasjavier.marti...@collabora.co.uk
---
  arch/arm/boot/dts/exynos5250-snow.dts | 25 -
  1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5250-snow.dts 
b/arch/arm/boot/dts/exynos5250-snow.dts
index b9aeec430527..0f7971ba8238 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -229,6 +229,13 @@
power-supply =fet6;
backlight =backlight;
};
+
+   mmc3_pwrseq: mmc3_pwrseq {
+   reset-gpios =gpx0 2 GPIO_ACTIVE_LOW, /* WIFI_RSTn */
+   gpx0 1 GPIO_ACTIVE_LOW; /* WIFI_EN */
+   clocks =max77686 MAX77686_CLK_PMIC;
+   clock-names = ext_clock;
+   };
  };

  dp {
@@ -531,17 +538,33 @@
status = okay;
num-slots =1;
broken-cd;
+   cap-sdio-irq;


This seems like an unrelated change, right?

Regards,
Arend


card-detect-delay =200;
samsung,dw-mshc-ciu-div =3;
samsung,dw-mshc-sdr-timing =2 3;
samsung,dw-mshc-ddr-timing =1 2;
pinctrl-names = default;
-   pinctrl-0 =sd3_clksd3_cmdsd3_bus4;
+   pinctrl-0 =sd3_clksd3_cmdsd3_bus4wifi_enwifi_rst;
bus-width =4;
cap-sd-highspeed;
+   mmc-pwrseq =mmc3_pwrseq;
  };

  pinctrl_0 {
+   wifi_en: wifi-en {
+   samsung,pins = gpx0-1;
+   samsung,pin-function =1;
+   samsung,pin-pud =0;
+   samsung,pin-drv =0;
+   };
+
+   wifi_rst: wifi-rst {
+   samsung,pins = gpx0-2;
+   samsung,pin-function =1;
+   samsung,pin-pud =0;
+   samsung,pin-drv =0;
+   };
+
power_key_irq: power-key-irq {
samsung,pins = gpx1-3;
samsung,pin-function =0xf;


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

Re: [PATCH v5 2/5] dt-bindings: Add pinctrl bindings for mt65xx/mt81xx.

2015-01-28 Thread Sascha Hauer

On Wed, Jan 21, 2015 at 01:28:14PM +0800, Hongzhou Yang wrote:
 From: Hongzhou Yang hongzhou.y...@mediatek.com
 
 Add devicetree bindings for Mediatek SoC pinctrl driver.
 
 Signed-off-by: Hongzhou Yang hongzhou.y...@mediatek.com

This basically follows the pinmux binding I suggested as generic pinmux
binding for per-pin type controllers, so:

Acked-by: Sascha Hauer s.ha...@pengutronix.de

Sascha


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

Re: [PATCH v5 2/5] dt-bindings: Add pinctrl bindings for mt65xx/mt81xx.

2015-01-28 Thread Sascha Hauer

On Tue, Jan 27, 2015 at 03:19:01PM +0100, Linus Walleij wrote:
 On Wed, Jan 21, 2015 at 6:28 AM, Hongzhou Yang
 hongzhou.y...@mediatek.com wrote:
 
  From: Hongzhou Yang hongzhou.y...@mediatek.com
 
  Add devicetree bindings for Mediatek SoC pinctrl driver.
 
  Signed-off-by: Hongzhou Yang hongzhou.y...@mediatek.com
 
 Sascha can you ACK this binding?

Just did that.

 If you confirm it will cover also your usecase I'm gonna be happy
 with this...

\o/

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line unsubscribe 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] mmc: dw_mmc-exynos: add support for controlling emmc reset pin

2015-01-28 Thread Tobias Jakobi

Ulf Hansson wrote:
 On 28 January 2015 at 13:41, Tobias Jakobi liquid.a...@gmx.net wrote:
 Hello!

 Jaehoon Chung wrote:
 mmc core supported to hw_reset function.
 So i think we can use it. It's called at only initial time to clear the 
 previous status.
 But i think it can be called at reboot time. (it needs to implement codes.)
 how about?
 I don't think that's going the work. The problem here is that depending
 on the board configuration, the eMMC might carry the bootloader. If the
 eMMC subsystem is not properly reset _during_ reboot, the board won't
 even start since no bootloader is found. So we don't even reach the
 point where the kernel does anything.
 
 I guess it depends on what's being done during the reboot sequence.
 
 The most proper thing would be to let the boot loader control the GPIO
 to trigger the HW reset, but that would mean the boot loader need to
 know about board specific configurations, such as which GPIO pin. So
 maybe SOC vendors need to state what GPIO pin to use and don't leave
 that as a configurable option.
Not the bootloader, but the iROM code would have to do this, and as far
as I know the iROM can't be modified. Or am I missing something here?


With best wishes,
Tobias

--
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 net-next v8 0/4] net: Add Keystone NetCP ethernet driver support

2015-01-28 Thread Arnd Bergmann

On Wednesday 28 January 2015 15:43:57 Murali Karicheri wrote:
  this. Hope I am on the right track.
 
 Reproduced this. Following errors seen when building the modules.
 
LD [M]  drivers/net/ethernet/ti/keystone_netcp.o
 drivers/net/ethernet/ti/netcp_ethss.o: In function `init_module':
 netcp_ethss.c:(.init.text+0x0): multiple definition of `init_module'
 drivers/net/ethernet/ti/netcp_core.o:netcp_core.c:(.init.text+0x0): 
 first defined here
 drivers/net/ethernet/ti/netcp_ethss.o: In function `cleanup_module':
 netcp_ethss.c:(.exit.text+0x0): multiple definition of `cleanup_module'
 drivers/net/ethernet/ti/netcp_core.o:netcp_core.c:(.exit.text+0x0): 
 first defined here
 make[4]: *** [drivers/net/ethernet/ti/keystone_netcp.o] Error 1

 BTW, I had to disable cpsw_ale.c to get to build keystone NetCP. I am 
 assuming someone from TI is addressing this.
 
 drivers/net/ethernet/ti/cpsw_ale.c: In function ‘cpsw_ale_start’:
 drivers/net/ethernet/ti/cpsw_ale.c:759:2: error: ‘KBUILD_MODNAME’ 
 undeclared (first use in this function)
 drivers/net/ethernet/ti/cpsw_ale.c:759:2: note: each undeclared 
 identifier is reported only once for each function it appears in

I think both problems are nontrivial to fix. The first one is obviously
that there are multiple init_module functions in one module. You have
to either split the driver into multiple loadable modules with at most
one init_module/cleanup_module pair each, or call one of the functions
from the other one in the right order.

The second problem is where I got stuck myself: cpsw_ale.c (also cpts.c)
is getting linked into both modules, which is not allowed: It is
impossible for the kernel to compile these if one driver is a module
and the other one is not, and any use of KBUILD_MODNAME fails because
it is unclear what the modname is if the file is compiled once to
be linked into two drivers.

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] drivers: of: fix resources freeing in of_pci_get_host_bridge_resources()

2015-01-28 Thread Bjorn Helgaas

On Tue, Jan 27, 2015 at 06:01:45PM +, Lorenzo Pieralisi wrote:
 In the function of_pci_get_host_bridge_resources() if the parsing of
 ranges fails, previously allocated resources inclusive of bus_range
 are not freed and are not expected to be freed by the function caller
 on error return.
 
 This patch fixes the issues by adding code that properly frees resources
 and bus_range before exiting the function with an error return value.
 
 Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
 Acked-by: Liviu Dudau liviu.du...@arm.com
 Cc: Arnd Bergmann a...@arndb.de
 Cc: Bjorn Helgaas bhelg...@google.com
 Cc: Rob Herring robh...@kernel.org

Applied to pci/host-generic for v3.20, thanks!

 ---
  drivers/of/of_pci.c | 4 
  1 file changed, 4 insertions(+)
 
 diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
 index 88471d3..60dc36c 100644
 --- a/drivers/of/of_pci.c
 +++ b/drivers/of/of_pci.c
 @@ -140,6 +140,7 @@ int of_pci_get_host_bridge_resources(struct device_node 
 *dev,
   unsigned char busno, unsigned char bus_max,
   struct list_head *resources, resource_size_t *io_base)
  {
 + struct pci_host_bridge_window *window;
   struct resource *res;
   struct resource *bus_range;
   struct of_pci_range range;
 @@ -225,7 +226,10 @@ int of_pci_get_host_bridge_resources(struct device_node 
 *dev,
  conversion_failed:
   kfree(res);
  parse_failed:
 + list_for_each_entry(window, resources, list)
 + kfree(window-res);
   pci_free_resource_list(resources);
 + kfree(bus_range);
   return err;
  }
  EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
 -- 
 2.2.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 v2 0/8] ARM: Conexant Digicolor CX92755 SoC support

2015-01-28 Thread Paul Bolle

On Thu, 2015-01-08 at 23:46 +0100, Arnd Bergmann wrote:
 Once there are no more review comments, please submit the first three
 patches to a...@kernel.org, and send the other patches as separate
 series to the respective maintainers for irqchip and clocksource.

I found this message while looking into CONFIG_ARCH_DIGICOLOR. That
Kconfig macro entered linux-next in next-20150128. But there's no
Kconfig symbol ARCH_DIGICOLOR yet in linux-next.

As you might be aware I try to check each linux-next release for Kconfig
oddities. One of the oddities I tend _not_ to report are things like
this. That is, SoC's, MFD's, or whatever, were specific drivers can get
merged before the core functionality. In this case the irqchip driver
got merged into linux-next while the core ARCH_DIGICOLOR code is still
pending. And you happen to be involved with quite a bit of code in areas
like that. 

Pre-merges like this appear unavoidable (ie, other workflows would be
more trouble for the people involved). But what would be a good moment
to still raise an issue like this? Just to make sure things don't fall
through the cracks. As in: this driver got merged into mainline but do
you know you can't yet build it?. Perhaps with each -rc1?


Paul Bolle

--
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 1/6] of: iommu: add ptr to OF node arg to of_iommu_configure()

2015-01-28 Thread Laurent Pinchart

On Wednesday 28 January 2015 12:29:42 Will Deacon wrote:
 On Wed, Jan 28, 2015 at 12:23:03PM +, Laurent Pinchart wrote:
  On Wednesday 28 January 2015 11:33:00 Will Deacon wrote:
  On Mon, Jan 26, 2015 at 06:49:01PM +, Murali Karicheri wrote:
  On 01/25/2015 08:32 AM, Laurent Pinchart wrote:
  On Friday 23 January 2015 17:32:34 Murali Karicheri wrote:
  Function of_iommu_configure() is called from of_dma_configure() to
  setup iommu ops using DT property. This API is currently used for
  platform devices for which DMA configuration (including iommu ops)
  may come from device's parent. To extend this functionality for PCI
  devices, this API need to take a parent node ptr as an argument
  instead of assuming device's parent. This is needed since for PCI,
  the dma configuration may be defined in the DT node of the root bus
  bridge's parent device. Currently only dma-range is used for PCI and
  iommu is not supported. So return error if the device is PCI.
  
  Cc: Joerg Roedelj...@8bytes.org
  Cc: Grant Likelygrant.lik...@linaro.org
  Cc: Rob Herringrobh...@kernel.org
  Cc: Bjorn Helgaasbhelg...@google.com
  Cc: Will Deaconwill.dea...@arm.com
  Cc: Russell Kingli...@arm.linux.org.uk
  Cc: Arnd Bergmanna...@arndb.de
  Cc: Suravee Suthikulpanitsuravee.suthikulpa...@amd.com
  
  Signed-off-by: Murali Karicherim-kariche...@ti.com
  ---
  
drivers/iommu/of_iommu.c |   10 --
drivers/of/platform.c|2 +-
include/linux/of_iommu.h |6 --
3 files changed, 13 insertions(+), 5 deletions(-)
  
  diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
  index af1dc6a..439235b 100644
  --- a/drivers/iommu/of_iommu.c
  +++ b/drivers/iommu/of_iommu.c
  @@ -133,19 +133,25 @@ struct iommu_ops *of_iommu_get_ops(struct
  device_node *np)
  return ops;
   }
  
  -struct iommu_ops *of_iommu_configure(struct device *dev)
  +struct iommu_ops *of_iommu_configure(struct device *dev,
  +struct device_node *iommu_np)
   {
  struct of_phandle_args iommu_spec;
  struct device_node *np;
  struct iommu_ops *ops = NULL;
  int idx = 0;
  
  +   if (dev_is_pci(dev)) {
  +   dev_err(dev, iommu is currently not supported for 
  PCI\n);
  +   return NULL;
  +   }
  +
  /*
   * We don't currently walk up the tree looking for a parent
   IOMMU.
   * See the `Notes:' section of
   * Documentation/devicetree/bindings/iommu/iommu.txt
   */
  
  Wouldn't it be better to fix this rather than passing the device node
  pointer to the function ? The solution would be more generic.
  
  Will Deacon (Copied here) is working on this as we alteady discussed
  in this thread. So it will be addressed by him in another series.
  
  Well, working on this equates to has it somewhere near the bottom of
  a very long list :)
  
  What's your opinion on this patch then, do you think adding the iommu_np
  argument makes sense as a temporary hack, or should we instead walk up the
  tree looking for an iommus attribute in parent nodes ? I don't expect that
  to be insanely difficult to code.
 
 If walking up the tree is useful, then I think we should do that and update
 the Documentation to reflect the new behaviour.

If I understand Murali's patch set right (please correct me if that's not the 
case) the PCI code walks up the DT nodes hierarchy to the parent node that 
contains the iommus attribute and passes a pointer to that node to this 
function. It's thus a PCI-specific solution. As a temporary hack that's OK I 
suppose, but if implementing it right straight away isn't difficult that would 
be better.

 The only reason that I didn't code that in of_iommu_configure originally is
 because I didn't want to go against the binding spec for the initial
 version, especially as we didn't have a reason to look at parent nodes.
 
 The only thing to double-check is that we don't break any existing users
 of the binding with this change, but I don't think that we do.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v2] thermal: Fix examples in DT documentation




On 28/01/15 17:29, Eduardo Valentin wrote:

Looks like there are still occurencies of adc-dummy after your patch.
But I am amending myself, no need to resend.


Thanks for fixing.. :-)

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

Re: [PATCH] ARM: shmobile: henninger: rename board to Porter

2015-01-28 Thread Sergei Shtylyov


Hello.

On 1/25/2015 10:30 PM, Geert Uytterhoeven wrote:


Renesas has made some changes to the Henninger low cost board hardware and at
the same time decided to  rename the board  to Porter.



Which changes?


  I don't have a list ready, sorry. One thing I know is that HDMI chip is 
different (the same as on Koelsch now); we don't support it yet...



They're not reflected in the new DTS?


   Not yet.


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



---
This patch is against 'renesas-devel-20150123-v3.19-rc5' tag of Simon Horman's
'renesas.git' repo.

  arch/arm/boot/dts/Makefile |  2 +-
  .../arm/boot/dts/{r8a7791-henninger.dts = r8a7791-porter.dts} | 10 +-
  2 files changed, 6 insertions(+), 6 deletions(-)
  rename arch/arm/boot/dts/{r8a7791-henninger.dts = r8a7791-porter.dts} (96%)



You forgot to update Documentation/devicetree/bindings/arm/shmobile.txt


   No wonder -- I had no idea it is listed there...


Gr{oetje,eeting}s,



 Geert


WBR, Sergei

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

Delays, clocks, timers, hrtimers, etc

2015-01-28 Thread Mason


Hello,

I am swimming in a sea of confusion, and am hoping someone would toss
me a life-jacket (of enlightenment). Please forgive me if some of my
questions are poorly asked or appear in seemingly random order.

Working on a Cortex A9 based SoC, I set out to clean up the platform
specific timer code, by using as much generic framework as possible.
(Right now, there's a lot of redundant code in the mach dir.)


Q1. the {n,u,m}delay function family

arch/arm/include/asm/delay.h mentions
Delay routines, using a pre-computed loops_per_second value.
*BUT* if the frequency changes dynamically (thanks to cpufreq)
the loops_per_second value cannot be pre-computed, as it would
change dynamically too, right?

Looking at arch/arm/lib/delay.c it seems the default implementation
is a busy loop (in delay-loop.S) which looks up loops_per_jiffy
in the prolog to determine the number of times to loop, right?

http://lxr.free-electrons.com/source/arch/arm/lib/delay-loop.S

(Side issue, why is the loop unrolled in __loop_delay? What is the
point of unrolling a busy loop? This is commented code however.)

What happens if loops_per_jiffy changes while one core is in the
busy loop? It seems we might exit the loop too early, which could
break some drivers with some weird heisenbug, no?

Also, is the update of loops_per_jiffy atomic? Is it possible that
if one core reads it while another updates it, we get garbage?

I suppose this is one reason why the default functions are overridden
by register_current_timer_delay(arch_delay_timer) right? I think the
property of a timer is that its frequency doesn't change, even if the
CPU's frequency changes? So we are still busy looping, but we are
checking the actual time spent in the loop, whatever the cpufreq?

Reference
https://www.kernel.org/doc/Documentation/timers/timers-howto.txt


Q2. Cortex A9 global and private timers

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0407f/CIHGECHJ.html

(What are private timers used for?)

In my platform-specific code, there is a config option to choose between

1) the ARM global timer
2) a platform-specific timer (timer0)

I noticed that there is generic code to support the global timer in
drivers/clocksource/arm_global_timer.c

config ARM_GLOBAL_TIMER
bool
select CLKSRC_OF if OF
help
  This options enables support for the ARM global timer unit

config CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
bool
depends on ARM_GLOBAL_TIMER
default y
help
 Use ARM global timer clock source as sched_clock

I was thinking it would be better to use the standard option (ARM global 
timer)
as it is officially supported in the vanilla kernel. So less code to write and
to debug, and it has likely received more testing. Why would one rely on
platform-specific timers then?

Are high-resolution timers supported with the global timer?


Q3. Using the generic global timer implementation

So, how do I use that implementation?
(Is someone other than STMicro using it?)

I see:

static void __init global_timer_of_register(struct device_node *np)
CLOCKSOURCE_OF_DECLARE(arm_gt, arm,cortex-a9-global-timer, 
global_timer_of_register);

OF stands for open firmware, yes?
So is this related to device tree?

http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/arm/global_timer.txt

This file makes no sense to me.

- interrupts : One interrupt to each core
interrupts = 1 13 0xf01;
what are 1 13 0xf01 ??

- clocks : Should be phandle to a clock.
clocks = arm_periph_clk;

For my (old) 3.14 kernel, I found this:

/*
 * ARM Peripheral clock for timers
 */
arm_periph_clk: arm_periph_clk {
  #clock-cells = 0;
  compatible = fixed-clock;
  clock-frequency = 6;
};

But it looks like the definitions have moved around since then?

This device tree concept is too much to swallow in a single serving.
Please tell me if I'm going down the correct rabbit hole, and I'll
do some LWN readings to try to wrap my mind around the concept.


Anyway, if anyone can help me out on some of these topics, I'd be
eternally grateful.

Regards.
--
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 v1 2/2] arm64: dts: Add the arasan sdhc nodes in apm-storm.dtsi.

2015-01-28 Thread Suman Tripathi

On Wednesday 28 January 2015 09:53:25 Suman Tripathi wrote:

 I added the iommus in the IOMMU AHBC patch. Anything wrong in that ?
 In the next version Also I will remove the IOMMU hacks from arasan
 driver

Hmm, I guess you have a required ordering between the patches either
way, which makes it hard to merge in a way that is bisectable.

You are correct that you should not merge a patch with the iommu
reference before adding the iommu device node, because it would
otherwise break building the mmc tree.

One more point is the binding for IOMMU needs to be in the same patch
in which the IOMMU support is added. So to provide the binding info of
the master node we require the sdhc nodes to be merged first.

Usually, the right answer is to merged the dts changes through the
arm-soc tree, and then you can just add the node for the sdhc device
after the one for the iommu device.

On Wed, Jan 28, 2015 at 6:16 PM, Arnd Bergmann a...@arndb.de wrote:
 On Wednesday 28 January 2015 09:53:25 Suman Tripathi wrote:

 I added the iommus in the IOMMU AHBC patch. Anything wrong in that ?
 In the next version Also I will remove the IOMMU hacks from arasan
 driver

 Hmm, I guess you have a required ordering between the patches either
 way, which makes it hard to merge in a way that is bisectable.

 You are correct that you should not merge a patch with the iommu
 reference before adding the iommu device node, because it would
 otherwise break building the mmc tree.

 Usually, the right answer is to merged the dts changes through the
 arm-soc tree, and then you can just add the node for the sdhc device
 after the one for the iommu device.

 Arnd



-- 
Thanks,
with regards,
Suman Tripathi
--
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

[RFC v2 04/14] NFC: nci: Add nci_nfcee_discover handler command/response/notification

Add nci_nfcee_discover handler according to NFC Forum NCI specification.
It is necessary for example for secure element handling.

Signed-off-by: Christophe Ricard christophe-h.ric...@st.com
---
 include/net/nfc/nci_core.h |  4 
 net/nfc/nci/core.c | 17 +
 net/nfc/nci/ntf.c  | 29 +
 net/nfc/nci/rsp.c  | 21 +
 4 files changed, 71 insertions(+)

diff --git a/include/net/nfc/nci_core.h b/include/net/nfc/nci_core.h
index 6cc3ffc..c492266 100644
--- a/include/net/nfc/nci_core.h
+++ b/include/net/nfc/nci_core.h
@@ -100,6 +100,8 @@ struct nci_conn_info {
struct sk_buff *rx_skb;
 };
 
+#define NCI_INVALID_CONN_ID 0x80
+
 /* NCI Core structures */
 struct nci_dev {
struct nfc_dev  *nfc_dev;
@@ -182,6 +184,8 @@ void nci_unregister_device(struct nci_dev *ndev);
 int nci_recv_frame(struct nci_dev *ndev, struct sk_buff *skb);
 int nci_set_config(struct nci_dev *ndev, __u8 id, size_t len, __u8 *val);
 
+int nci_nfcee_discover(struct nci_dev *ndev, u8 action);
+
 static inline struct sk_buff *nci_skb_alloc(struct nci_dev *ndev,
unsigned int len,
gfp_t how)
diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index fa07299..d8cb395 100644
--- a/net/nfc/nci/core.c
+++ b/net/nfc/nci/core.c
@@ -456,6 +456,23 @@ int nci_set_config(struct nci_dev *ndev, __u8 id, size_t 
len, __u8 *val)
 }
 EXPORT_SYMBOL(nci_set_config);
 
+static void nci_nfcee_discover_req(struct nci_dev *ndev, unsigned long opt)
+{
+   struct nci_nfcee_discover_cmd cmd;
+   __u8 action = opt;
+
+   cmd.discovery_action = action;
+
+   nci_send_cmd(ndev, NCI_OP_NFCEE_DISCOVER_CMD, 1, cmd);
+}
+
+int nci_nfcee_discover(struct nci_dev *ndev, u8 action)
+{
+   return nci_request(ndev, nci_nfcee_discover_req, action,
+   msecs_to_jiffies(NCI_CMD_TIMEOUT));
+}
+EXPORT_SYMBOL(nci_nfcee_discover);
+
 static int nci_set_local_general_bytes(struct nfc_dev *nfc_dev)
 {
struct nci_dev *ndev = nfc_get_drvdata(nfc_dev);
diff --git a/net/nfc/nci/ntf.c b/net/nfc/nci/ntf.c
index fe2be18..a1ca2b4 100644
--- a/net/nfc/nci/ntf.c
+++ b/net/nfc/nci/ntf.c
@@ -723,6 +723,32 @@ static void nci_rf_deactivate_ntf_packet(struct nci_dev 
*ndev,
nci_req_complete(ndev, NCI_STATUS_OK);
 }
 
+static void nci_nfcee_discover_ntf_packet(struct nci_dev *ndev,
+ struct sk_buff *skb)
+{
+   u8 status = NCI_STATUS_OK;
+   struct nci_conn_info*conn_info;
+   struct nci_nfcee_discover_ntf   *nfcee_ntf =
+   (struct nci_nfcee_discover_ntf *)skb-data;
+
+   pr_debug(\n);
+
+   conn_info = devm_kzalloc(ndev-nfc_dev-dev,
+sizeof(struct nci_conn_info), GFP_KERNEL);
+   if (!conn_info) {
+   status = NCI_STATUS_REJECTED;
+   goto exit;
+   }
+
+   conn_info-id = nfcee_ntf-nfcee_id;
+   conn_info-conn_id = NCI_INVALID_CONN_ID;
+
+   ndev-conn_info_by_id[conn_info-id] = conn_info;
+
+exit:
+   nci_req_complete(ndev, status);
+}
+
 void nci_ntf_packet(struct nci_dev *ndev, struct sk_buff *skb)
 {
__u16 ntf_opcode = nci_opcode(skb-data);
@@ -761,6 +787,9 @@ void nci_ntf_packet(struct nci_dev *ndev, struct sk_buff 
*skb)
nci_rf_deactivate_ntf_packet(ndev, skb);
break;
 
+   case NCI_OP_NFCEE_DISCOVER_NTF:
+   nci_nfcee_discover_ntf_packet(ndev, skb);
+   break;
default:
pr_err(unknown ntf opcode 0x%x\n, ntf_opcode);
break;
diff --git a/net/nfc/nci/rsp.c b/net/nfc/nci/rsp.c
index 595934c..2e549bd 100644
--- a/net/nfc/nci/rsp.c
+++ b/net/nfc/nci/rsp.c
@@ -198,6 +198,23 @@ static void nci_rf_deactivate_rsp_packet(struct nci_dev 
*ndev,
}
 }
 
+static void nci_nfcee_discover_rsp_packet(struct nci_dev *ndev,
+ struct sk_buff *skb)
+{
+   struct nci_nfcee_discover_rsp *discover_rsp;
+
+   if (skb-len != 2) {
+   nci_req_complete(ndev, NCI_STATUS_NFCEE_PROTOCOL_ERROR);
+   return;
+   }
+
+   discover_rsp = (struct nci_nfcee_discover_rsp *)skb-data;
+
+   if (discover_rsp-status != NCI_STATUS_OK ||
+   discover_rsp-num_nfcee == 0)
+   nci_req_complete(ndev, discover_rsp-status);
+}
+
 void nci_rsp_packet(struct nci_dev *ndev, struct sk_buff *skb)
 {
__u16 rsp_opcode = nci_opcode(skb-data);
@@ -243,6 +260,10 @@ void nci_rsp_packet(struct nci_dev *ndev, struct sk_buff 
*skb)
nci_rf_deactivate_rsp_packet(ndev, skb);
break;
 
+   case NCI_OP_NFCEE_DISCOVER_RSP:
+   nci_nfcee_discover_rsp_packet(ndev, skb);
+   break;
+
default:
pr_err(unknown rsp opcode 0x%x\n, rsp_opcode);

Re: [PATCH v5 3/8] of: fix size when dma-range is not used

2015-01-28 Thread Robin Murphy


Hi Murali,

[sorry, missed replying to yesterday's version]

On 27/01/15 21:00, Murali Karicheri wrote:

Fix the dma-range size when the DT attribute is missing. i.e  set size to
dev-coherent_dma_mask + 1 instead of dev-coherent_dma_mask. Also add
code to check invalid values of size configured in DT and log error.

Cc: Joerg Roedel j...@8bytes.org
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring robh...@kernel.org
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Will Deacon will.dea...@arm.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Arnd Bergmann a...@arndb.de
Cc: Suravee Suthikulpanit suravee.suthikulpa...@amd.com

Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
  drivers/of/device.c |9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/of/device.c b/drivers/of/device.c
index 2de320d..17504f4 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -105,12 +105,19 @@ void of_dma_configure(struct device *dev, struct 
device_node *np)
ret = of_dma_get_range(np, dma_addr, paddr, size);
if (ret  0) {
dma_addr = offset = 0;
-   size = dev-coherent_dma_mask;
+   size = dev-coherent_dma_mask + 1;
} else {
offset = PFN_DOWN(paddr - dma_addr);
dev_dbg(dev, dma_pfn_offset(%#08lx)\n, offset);
}

+   if (is_power_of_2(size + 1))
+   size = size + 1;
+   else if (!is_power_of_2(size)) {
+   dev_err(dev, invalid size\n);
+   return;
+   }
+


Couldn't these checks go into the else path above? We don't need to 
check the non-DT case, because we know we've just set it to something 
sensible.


Robin.


dev-dma_pfn_offset = offset;

coherent = of_dma_is_coherent(np);




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

[PATCH v5 0/5] iio: Add sensorhub driver

Hello,

This patchset adds support for sensorhub.  It is an external mcu which
manages and collects data from several sensors i.e. on Galaxy Gear 2 watch.

It contains:
- spi driver for sensorhub device
- DT binding for the device
- IIO common utils for ssp sensors (iio kfifo setup helpers, pre/post callbacks)
- IIO accelerometer driver
- IIO gyroscope driver

For now the driver supports traditional sensors but new ones types are
intended to be used.

The patchset depends on INDIO_BUFFER_SOFTWARE adding patch.

From v1:
  - Adopted to new stm32fwu v5
  - Fixed sensors' data process callbacks
  - Fixed comments style

From v2:
  - Fixes after Hartmut Knaack review
  - Sensorhub driver was moved from misc to iio after the discussion with Arnd
and Jonathan
  - Firmware upgrade is not supported in this patchset. I hope it will be
applied when it will find its own place in the tree.

From v3:
  - change buffer allocation manner for iio devices buffers
  - centralize irq buffer
  - style fixes
  - sensors' devices as mfd cells
  - remove iio_buffer_register from the sensorhub drivers
  - fix DT binding and remove optional attributes

From v4:
  - fix Kconfig - missing MFD_CORE dependency
  - rebase on next-20150128
  - remove THIS_MODULE usage in sensors' drivers as not needed


Thanks,
Karol


Karol Wrona (5):
  iio: common: ssp_sensors: Add sensorhub driver
  iio: sensorhub: Add sensorhub bindings
  iio: common: ssp_sensors: Add sensorhub iio commons
  iio: common: ssp_sensors: Add sensorhub accelerometer sensor
  iio: common: ssp_sensors: Add sensorhub gyroscope sensor

 .../devicetree/bindings/iio/sensorhub.txt  |   25 +
 drivers/iio/accel/Makefile |1 +
 drivers/iio/accel/ssp_accel_sensor.c   |  169 +
 drivers/iio/common/Kconfig |1 +
 drivers/iio/common/Makefile|1 +
 drivers/iio/common/ssp_sensors/Kconfig |   26 +
 drivers/iio/common/ssp_sensors/Makefile|8 +
 drivers/iio/common/ssp_sensors/ssp.h   |  257 +++
 drivers/iio/common/ssp_sensors/ssp_dev.c   |  712 
 drivers/iio/common/ssp_sensors/ssp_iio.c   |  107 +++
 drivers/iio/common/ssp_sensors/ssp_iio_sensor.h|   70 ++
 drivers/iio/common/ssp_sensors/ssp_spi.c   |  608 +
 drivers/iio/gyro/Makefile  |2 +
 drivers/iio/gyro/ssp_gyro_sensor.c |  168 +
 include/linux/iio/common/ssp_sensors.h |   82 +++
 15 files changed, 2237 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/sensorhub.txt
 create mode 100644 drivers/iio/accel/ssp_accel_sensor.c
 create mode 100644 drivers/iio/common/ssp_sensors/Kconfig
 create mode 100644 drivers/iio/common/ssp_sensors/Makefile
 create mode 100644 drivers/iio/common/ssp_sensors/ssp.h
 create mode 100644 drivers/iio/common/ssp_sensors/ssp_dev.c
 create mode 100644 drivers/iio/common/ssp_sensors/ssp_iio.c
 create mode 100644 drivers/iio/common/ssp_sensors/ssp_iio_sensor.h
 create mode 100644 drivers/iio/common/ssp_sensors/ssp_spi.c
 create mode 100644 drivers/iio/gyro/ssp_gyro_sensor.c
 create mode 100644 include/linux/iio/common/ssp_sensors.h

-- 
1.7.9.5

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

Re: [PATCH V4 1/4] mmc: core: Initial support for MMC power sequences

On 28 January 2015 at 11:17, Javier Martinez Canillas
jav...@dowhile0.org wrote:
 Hello Ulf,

 On Mon, Jan 19, 2015 at 10:13 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
 System on chip designs may specify a specific MMC power sequence. To
 successfully detect an (e)MMC/SD/SDIO card, that power sequence must
 be followed while initializing the card.

 To be able to handle these SOC specific power sequences, let's add a
 MMC power sequence interface. It provides the following functions to
 help the mmc core to deal with these power sequences.

 mmc_pwrseq_alloc() - Invoked from mmc_of_parse(), to initialize data.
 mmc_pwrseq_pre_power_on()- Invoked in the beginning of mmc_power_up().
 mmc_pwrseq_post_power_on()- Invoked at the end in mmc_power_up().
 mmc_pwrseq_power_off()- Invoked from mmc_power_off().
 mmc_pwrseq_free() - Invoked from mmc_free_host(), to free data.

 Each MMC power sequence provider will be responsible to implement a set
 of callbacks. These callbacks mirrors the functions above.

 This patch adds the skeleton, following patches will extend the core of
 the MMC power sequence and add support for a specific simple MMC power
 sequence.

 Do note, since the mmc_pwrseq_alloc() is invoked from mmc_of_parse(),
 host drivers needs to make use of this API to enable the support for
 MMC power sequences. Moreover the MMC power sequence support depends on
 CONFIG_OF.

 Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
 ---

 Patch looks good to me and I could successfully get the SDIO wlan chip
 in the Snow Chromebook after extending the pwrseq_simple driver so on
 Exynos5250 Snow Chromebook:

By extending you mean?


 Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk

 Best regards,
 Javier

Thanks for testing and reviewing! I have applied your tags to the patches.

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

[PATCH v2 6/7] ASoC: pcm512x: Avoid the PLL for the DAC clock, if possible

From: Peter Rosin p...@axentia.se

The PLL introduces jitter, which in turn introduces noice if used
to clock the DAC. Thus, avoid the PLL output, and use the PLL input
to drive the DAC clock, if possible.

This is described for the PCM5142/PCM5242 chips in the answers to the
forum post PCM5142/PCM5242 DAC clock source at the TI E2E community
pages (1).

(1) http://e2e.ti.com/support/data_converters/audio_converters/f/64/t/389994

Signed-off-by: Peter Rosin p...@axentia.se
---
 sound/soc/codecs/pcm512x.c |  119 ++--
 sound/soc/codecs/pcm512x.h |4 +-
 2 files changed, 96 insertions(+), 27 deletions(-)

diff --git a/sound/soc/codecs/pcm512x.c b/sound/soc/codecs/pcm512x.c
index f0c7ec2a2f31..d46d6cdb6b87 100644
--- a/sound/soc/codecs/pcm512x.c
+++ b/sound/soc/codecs/pcm512x.c
@@ -105,6 +105,7 @@ static const struct reg_default pcm512x_reg_defaults[] = {
{ PCM512x_VCOM_CTRL_2,   0x01 },
{ PCM512x_BCLK_LRCLK_CFG,0x00 },
{ PCM512x_MASTER_MODE,   0x7c },
+   { PCM512x_GPIO_DACIN,0x00 },
{ PCM512x_GPIO_PLLIN,0x00 },
{ PCM512x_SYNCHRONIZE,   0x10 },
{ PCM512x_PLL_COEFF_0,   0x00 },
@@ -138,6 +139,7 @@ static bool pcm512x_readable(struct device *dev, unsigned 
int reg)
case PCM512x_MASTER_MODE:
case PCM512x_PLL_REF:
case PCM512x_DAC_REF:
+   case PCM512x_GPIO_DACIN:
case PCM512x_GPIO_PLLIN:
case PCM512x_SYNCHRONIZE:
case PCM512x_PLL_COEFF_0:
@@ -659,6 +661,37 @@ done:
return 0;
 }
 
+static unsigned long pcm512x_pllin_dac_rate(struct snd_soc_dai *dai,
+   unsigned long osr_rate,
+   unsigned long pllin_rate)
+{
+   struct snd_soc_codec *codec = dai-codec;
+   struct pcm512x_priv *pcm512x = snd_soc_codec_get_drvdata(codec);
+   unsigned long dac_rate;
+
+   if (!pcm512x-pll_out)
+   return 0; /* no PLL to bypass, force SCK as DAC input */
+
+   if (pllin_rate % osr_rate)
+   return 0; /* futile, quit early */
+
+   /* run DAC no faster than 6144000 Hz */
+   for (dac_rate = rounddown(6144000, osr_rate);
+dac_rate;
+dac_rate -= osr_rate) {
+
+   if (pllin_rate / dac_rate  128)
+   return 0; /* DAC divider would be too big */
+
+   if (!(pllin_rate % dac_rate))
+   return dac_rate;
+
+   dac_rate -= osr_rate;
+   }
+
+   return 0;
+}
+
 static int pcm512x_set_dividers(struct snd_soc_dai *dai,
struct snd_pcm_hw_params *params)
 {
@@ -672,6 +705,7 @@ static int pcm512x_set_dividers(struct snd_soc_dai *dai,
unsigned long bclk_rate;
unsigned long sample_rate;
unsigned long osr_rate;
+   unsigned long dacsrc_rate;
int bclk_div;
int lrclk_div;
int dsp_div;
@@ -679,11 +713,10 @@ static int pcm512x_set_dividers(struct snd_soc_dai *dai,
unsigned long dac_rate;
int ncp_div;
int osr_div;
-   unsigned long dac_mul;
-   unsigned long sck_mul;
int ret;
int idac;
int fssp;
+   int gpio;
 
lrclk_div = snd_soc_params_to_frame_size(params);
if (lrclk_div == 0) {
@@ -772,31 +805,72 @@ static int pcm512x_set_dividers(struct snd_soc_dai *dai,
/* run DSP no faster than 50 MHz */
dsp_div = mck_rate  5000 ? 2 : 1;
 
-   /* run DAC no faster than 6144000 Hz */
-   dac_mul = 6144000 / osr_rate;
-   sck_mul = sck_rate / osr_rate;
-   for (; dac_mul; dac_mul--) {
-   if (!(sck_mul % dac_mul))
-   break;
-   }
-   if (!dac_mul) {
-   dev_err(dev, Failed to find DAC rate\n);
-   return -EINVAL;
-   }
+   dac_rate = pcm512x_pllin_dac_rate(dai, osr_rate, pllin_rate);
+   if (dac_rate) {
+   /* the desired clock rate is compatible with the pll input
+* clock, so use that clock as dac input instead of the pll
+* output clock since the pll will introduce jitter and thus
+* noise.
+*/
+   dev_dbg(dev, using pll input as dac input\n);
+   ret = regmap_update_bits(pcm512x-regmap, PCM512x_DAC_REF,
+PCM512x_SDAC, PCM512x_SDAC_GPIO);
+   if (ret != 0) {
+   dev_err(codec-dev,
+   Failed to set gpio as dacref: %d\n, ret);
+   return ret;
+   }
 
-   dac_rate = dac_mul * osr_rate;
-   dev_dbg(dev, dac_rate %lu sample_rate %lu\n, dac_rate, sample_rate);
+   gpio = PCM512x_GREF_GPIO1 + pcm512x-pll_in - 1;
+   ret = regmap_update_bits(pcm512x-regmap, PCM512x_GPIO_DACIN,
+

[PATCH v5 2/5] iio: sensorhub: Add sensorhub bindings

Add sensorhub bindings for sensorhub on Galaxy Gear 2.

Signed-off-by: Karol Wrona k.wr...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
 .../devicetree/bindings/iio/sensorhub.txt  |   25 
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/sensorhub.txt

diff --git a/Documentation/devicetree/bindings/iio/sensorhub.txt 
b/Documentation/devicetree/bindings/iio/sensorhub.txt
new file mode 100644
index 000..8d57571
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/sensorhub.txt
@@ -0,0 +1,25 @@
+Samsung Sensorhub driver
+
+Sensorhub is a MCU which manages several sensors and also plays the role
+of a virtual sensor device.
+
+Required properties:
+- compatible: samsung,sensorhub-rinato or samsung,sensorhub-thermostat
+- spi-max-frequency: max SPI clock frequency
+- interrupt-parent: interrupt parent
+- interrupts: communication interrupt
+- ap-mcu-gpios: [out] ap to sensorhub line - used during communication
+- mcu-ap-gpios: [in] sensorhub to ap - used during communication
+- mcu-reset-gpios: [out] sensorhub reset
+
+Example:
+
+   shub_spi: shub {
+   compatible = samsung,sensorhub-rinato;
+   spi-max-frequency = 500;
+   interrupt-parent = gpx0;
+   interrupts = 2 0;
+   ap-mcu-gpios = gpx0 0 0;
+   mcu-ap-gpios = gpx0 4 0;
+   mcu-reset-gpios = gpx0 5 0;
+   };
-- 
1.7.9.5

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

[PATCH v2 5/7] ASoC: pcm512x: Support mastering BCLK/LRCLK using the PLL

From: Peter Rosin p...@axentia.se

Using the PLL in master mode requires using an external connection
between one of the GPIO pins (configured as PLL/4 output) and the
SCK pin. It also requires the external clock to be fed to some other
GPIO pin instead of the SCK pin.

This is described for the PCM5122 chip in the answers to the forum post
PCM5122 DAC as I2S master troubles with PLL mode at the TI E2E
community pages (1). The clocking functionality is also much better
described in the datasheet for the chip PCM5242, which seems to be
register compatible with PCM512x and PCM514x (which both have severely
lacking datasheets).

(1) http://e2e.ti.com/support/data_converters/audio_converters/f/64/t/267830

Signed-off-by: Peter Rosin p...@axentia.se
---
 .../devicetree/bindings/sound/pcm512x.txt  |   25 +-
 sound/soc/codecs/pcm512x.c |  458 +++-
 sound/soc/codecs/pcm512x.h |   44 +-
 3 files changed, 501 insertions(+), 26 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/pcm512x.txt 
b/Documentation/devicetree/bindings/sound/pcm512x.txt
index 98e0d34915e8..3aae3b41bd8e 100644
--- a/Documentation/devicetree/bindings/sound/pcm512x.txt
+++ b/Documentation/devicetree/bindings/sound/pcm512x.txt
@@ -17,9 +17,16 @@ Required properties:
 Optional properties:
 
   - clocks : A clock specifier for the clock connected as SCLK.  If this
-is absent the device will be configured to clock from BCLK.
+is absent the device will be configured to clock from BCLK.  If pll-in
+and pll-out are specified in addition to a clock, the device is
+configured to accept clock input on a specified gpio pin.
 
-Example:
+  - pll-in, pll-out : gpio pins used to connect the pll using 1
+through 6.  The device will be configured for clock input on the
+given pll-in pin and PLL output on the given pll-out pin.  An
+external connection from the pll-out pin to the SCLK pin is assumed.
+
+Examples:
 
pcm5122: pcm5122@4c {
compatible = ti,pcm5122;
@@ -29,3 +36,17 @@ Example:
DVDD-supply = reg_1v8;
CPVDD-supply = reg_3v3;
};
+
+
+   pcm5142: pcm5142@4c {
+   compatible = ti,pcm5142;
+   reg = 0x4c;
+
+   AVDD-supply = reg_3v3_analog;
+   DVDD-supply = reg_1v8;
+   CPVDD-supply = reg_3v3;
+
+   clocks = sck;
+   pll-in = 3;
+   pll-out = 6;
+   };
diff --git a/sound/soc/codecs/pcm512x.c b/sound/soc/codecs/pcm512x.c
index 124388809d48..f0c7ec2a2f31 100644
--- a/sound/soc/codecs/pcm512x.c
+++ b/sound/soc/codecs/pcm512x.c
@@ -21,6 +21,7 @@
 #include linux/pm_runtime.h
 #include linux/regmap.h
 #include linux/regulator/consumer.h
+#include linux/gcd.h
 #include sound/soc.h
 #include sound/soc-dapm.h
 #include sound/pcm_params.h
@@ -28,6 +29,11 @@
 
 #include pcm512x.h
 
+#define DIV_ROUND_DOWN_ULL(ll, d) \
+   ({ unsigned long long _tmp = (ll); do_div(_tmp, d); _tmp; })
+#define DIV_ROUND_CLOSEST_ULL(ll, d) \
+   ({ unsigned long long _tmp = (ll)+(d)/2; do_div(_tmp, d); _tmp; })
+
 #define PCM512x_NUM_SUPPLIES 3
 static const char * const pcm512x_supply_names[PCM512x_NUM_SUPPLIES] = {
AVDD,
@@ -41,6 +47,13 @@ struct pcm512x_priv {
struct regulator_bulk_data supplies[PCM512x_NUM_SUPPLIES];
struct notifier_block supply_nb[PCM512x_NUM_SUPPLIES];
int fmt;
+   int pll_in;
+   int pll_out;
+   int pll_r;
+   int pll_j;
+   int pll_d;
+   int pll_p;
+   unsigned long real_pll;
 };
 
 /*
@@ -92,7 +105,13 @@ static const struct reg_default pcm512x_reg_defaults[] = {
{ PCM512x_VCOM_CTRL_2,   0x01 },
{ PCM512x_BCLK_LRCLK_CFG,0x00 },
{ PCM512x_MASTER_MODE,   0x7c },
+   { PCM512x_GPIO_PLLIN,0x00 },
{ PCM512x_SYNCHRONIZE,   0x10 },
+   { PCM512x_PLL_COEFF_0,   0x00 },
+   { PCM512x_PLL_COEFF_1,   0x00 },
+   { PCM512x_PLL_COEFF_2,   0x00 },
+   { PCM512x_PLL_COEFF_3,   0x00 },
+   { PCM512x_PLL_COEFF_4,   0x00 },
{ PCM512x_DSP_CLKDIV,0x00 },
{ PCM512x_DAC_CLKDIV,0x00 },
{ PCM512x_NCP_CLKDIV,0x00 },
@@ -119,6 +138,7 @@ static bool pcm512x_readable(struct device *dev, unsigned 
int reg)
case PCM512x_MASTER_MODE:
case PCM512x_PLL_REF:
case PCM512x_DAC_REF:
+   case PCM512x_GPIO_PLLIN:
case PCM512x_SYNCHRONIZE:
case PCM512x_PLL_COEFF_0:
case PCM512x_PLL_COEFF_1:
@@ -160,6 +180,7 @@ static bool pcm512x_readable(struct device *dev, unsigned 
int reg)
case PCM512x_RATE_DET_2:
case PCM512x_RATE_DET_3:
case PCM512x_RATE_DET_4:
+   case PCM512x_CLOCK_STATUS:
case PCM512x_ANALOG_MUTE_DET:
case PCM512x_GPIN:
case PCM512x_DIGITAL_MUTE_DET:
@@ -171,6 +192,8 @@ static bool

[RFC v2 10/14] NFC: Forward NFC_EVT_TRANSACTION up to user space

NFC_EVT_TRANSACTION is not managed so far.

Forward event information up to user space in order to tell an application
that some user action(s) are needed.

Forwarded information are:
- SE host generating the event
- Application IDentifier doing the operation
- Applications parameters

Signed-off-by: Christophe Ricard christophe-h.ric...@st.com
---
 include/net/nfc/nfc.h| 27 +++
 include/uapi/linux/nfc.h |  1 +
 net/nfc/core.c   | 21 +
 net/nfc/netlink.c| 47 +++
 net/nfc/nfc.h|  2 ++
 5 files changed, 98 insertions(+)

diff --git a/include/net/nfc/nfc.h b/include/net/nfc/nfc.h
index 12adb81..73190e6 100644
--- a/include/net/nfc/nfc.h
+++ b/include/net/nfc/nfc.h
@@ -135,6 +135,31 @@ struct nfc_se {
u16 state;
 };
 
+/**
+ * nfc_evt_transaction - A struct for NFC secure element event transaction.
+ *
+ * @aid: The application identifier triggering the event
+ *
+ * @aid_len: The application identifier length [5:16]
+ *
+ * @params: The application parameters transmitted during the transaction
+ *
+ * @params_len: The applications parameters length [0:255]
+ *
+ */
+#define NFC_MIN_AID_LENGTH 5
+#defineNFC_MAX_AID_LENGTH  16
+#define NFC_MAX_PARAMS_LENGTH  255
+
+#define NFC_EVT_TRANSACTION_AID_TAG0x81
+#define NFC_EVT_TRANSACTION_PARAMS_TAG 0x82
+struct nfc_evt_transaction {
+   u32 aid_len;
+   u8 aid[NFC_MAX_AID_LENGTH];
+   u8 params_len;
+   u8 params[NFC_MAX_PARAMS_LENGTH];
+} __packed;
+
 struct nfc_genl_data {
u32 poll_req_portid;
struct mutex genl_data_mutex;
@@ -262,6 +287,8 @@ int nfc_tm_data_received(struct nfc_dev *dev, struct 
sk_buff *skb);
 
 void nfc_driver_failure(struct nfc_dev *dev, int err);
 
+int nfc_se_transaction(struct nfc_dev *dev, u8 se_idx,
+  struct nfc_evt_transaction *evt_transaction);
 int nfc_add_se(struct nfc_dev *dev, u32 se_idx, u16 type);
 int nfc_remove_se(struct nfc_dev *dev, u32 se_idx);
 struct nfc_se *nfc_find_se(struct nfc_dev *dev, u32 se_idx);
diff --git a/include/uapi/linux/nfc.h b/include/uapi/linux/nfc.h
index 8119255..c1e2e63 100644
--- a/include/uapi/linux/nfc.h
+++ b/include/uapi/linux/nfc.h
@@ -183,6 +183,7 @@ enum nfc_attrs {
NFC_ATTR_SE_APDU,
NFC_ATTR_TARGET_ISO15693_DSFID,
NFC_ATTR_TARGET_ISO15693_UID,
+   NFC_ATTR_SE_PARAMS,
 /* private: internal use only */
__NFC_ATTR_AFTER_LAST
 };
diff --git a/net/nfc/core.c b/net/nfc/core.c
index 7f1b635..cff3f16 100644
--- a/net/nfc/core.c
+++ b/net/nfc/core.c
@@ -932,6 +932,27 @@ int nfc_remove_se(struct nfc_dev *dev, u32 se_idx)
 }
 EXPORT_SYMBOL(nfc_remove_se);
 
+int nfc_se_transaction(struct nfc_dev *dev, u8 se_idx,
+  struct nfc_evt_transaction *evt_transaction)
+{
+   int rc;
+
+   pr_debug(transaction: %x\n, se_idx);
+
+   device_lock(dev-dev);
+
+   if (!evt_transaction) {
+   rc = -EPROTO;
+   goto out;
+   }
+
+   rc = nfc_genl_se_transaction(dev, se_idx, evt_transaction);
+out:
+   device_unlock(dev-dev);
+   return rc;
+}
+EXPORT_SYMBOL(nfc_se_transaction);
+
 static void nfc_release(struct device *d)
 {
struct nfc_dev *dev = to_nfc_dev(d);
diff --git a/net/nfc/netlink.c b/net/nfc/netlink.c
index be387e6..14a2d11 100644
--- a/net/nfc/netlink.c
+++ b/net/nfc/netlink.c
@@ -497,6 +497,53 @@ free_msg:
return -EMSGSIZE;
 }
 
+int nfc_genl_se_transaction(struct nfc_dev *dev, u8 se_idx,
+   struct nfc_evt_transaction *evt_transaction)
+{
+   struct nfc_se *se;
+   struct sk_buff *msg;
+   void *hdr;
+
+   msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
+   if (!msg)
+   return -ENOMEM;
+
+   hdr = genlmsg_put(msg, 0, 0, nfc_genl_family, 0,
+ NFC_EVENT_SE_TRANSACTION);
+   if (!hdr)
+   goto free_msg;
+
+   se = nfc_find_se(dev, se_idx);
+   if (!se)
+   goto free_msg;
+
+   if (nla_put_u32(msg, NFC_ATTR_DEVICE_INDEX, dev-idx) ||
+   nla_put_u32(msg, NFC_ATTR_SE_INDEX, se_idx) ||
+   nla_put_u8(msg, NFC_ATTR_SE_TYPE, se-type) ||
+   nla_put(msg, NFC_ATTR_SE_AID, evt_transaction-aid_len,
+   evt_transaction-aid) ||
+   nla_put(msg, NFC_ATTR_SE_PARAMS, evt_transaction-params_len,
+   evt_transaction-params))
+   goto nla_put_failure;
+
+   /* evt_transaction is no more used */
+   devm_kfree(dev-dev, evt_transaction);
+
+   genlmsg_end(msg, hdr);
+
+   genlmsg_multicast(nfc_genl_family, msg, 0, 0, GFP_KERNEL);
+
+   return 0;
+
+nla_put_failure:
+   genlmsg_cancel(msg, hdr);
+free_msg:
+   /* evt_transaction is no more used */
+   devm_kfree(dev-dev, evt_transaction);
+   nlmsg_free(msg);
+   return -EMSGSIZE;
+}
+
 static int

Re: [PATCH net-next v8 0/4] net: Add Keystone NetCP ethernet driver support


On 01/28/2015 11:49 AM, Murali Karicheri wrote:

On 01/27/2015 05:28 PM, Arnd Bergmann wrote:

On Tuesday 20 January 2015 10:53:36 Murali Karicheri wrote:

On 01/19/2015 03:11 PM, David Miller wrote:

From: Murali Karicherim-kariche...@ti.com
Date: Thu, 15 Jan 2015 19:10:03 -0500


The Network Coprocessor (NetCP) is a hardware accelerator that
processes
Ethernet packets. NetCP has a gigabit Ethernet (GbE) subsystem with
a ethernet
switch sub-module to send and receive packets. NetCP also includes
a packet
accelerator (PA) module to perform packet classification operations
such as
header matching, and packet modification operations such as checksum
generation. NetCP can also optionally include a Security
Accelerator(SA)
capable of performing IPSec operations on ingress/egress packets.

Keystone SoC's also have a 10 Gigabit Ethernet Subsystem (XGbE) which
includes a 3-port Ethernet switch sub-module capable of 10Gb/s and
1Gb/s rates per Ethernet port.

Both GBE and XGBE network processors supported using common driver. It
is also designed to handle future variants of NetCP.


Series applied to net-next, thanks.

David,

Thanks a lot for applying this series. This helps us move forward to
work on the next set of patches.


Hi Murali,

Building an ARM 'allmodconfig' kernel now runs into two separate problems
from your driver:

- you have two module_init() instances in one module, which conflict.

- you have two files that are linked into more than one module, so
building
both TI_CPSW and TI_KEYSTONE_NETCP in the same kernel fails.

The answer to both of these is probably to have separate loadable
modules,
but you might be able to come up with a different solution.

Arnd,

Thanks for letting us know. We will look into this.

How do I reproduce this? Is there a defconfig used for allmodconfig? I
am unable to find one. Any details to reproduce this will be useful.


Ok I think I found it.

I did this with next-next branch and it seems to work. I will make 
kernel build to reproduce this.


make ARCH=arm allmodconfig
make uImage;

I am building it now.

Murali

Thanks.

Murali


Arnd






--
Murali Karicheri
Linux Kernel, Texas Instruments
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 3/6] of: fix size when dma-range is not used


On 01/28/2015 10:45 AM, Rob Herring wrote:

On Wed, Jan 28, 2015 at 5:05 AM, Catalin Marinas
catalin.mari...@arm.com  wrote:

On Tue, Jan 27, 2015 at 06:55:15PM +, Murali Karicheri wrote:

On 01/27/2015 06:27 AM, Robin Murphy wrote:

On 23/01/15 22:32, Murali Karicheri wrote:

Fix the dma-range size when the DT attribute is missing. i.e set size to
dev-coherent_dma_mask + 1 instead of dev-coherent_dma_mask. To detect
overflow when mask is set to max of u64, add a check, log error and
return.
Some platform use mask format for size in DTS. So add a work around to
catch this and fix.

Cc: Joerg Roedelj...@8bytes.org
Cc: Grant Likelygrant.lik...@linaro.org
Cc: Rob Herringrobh...@kernel.org
Cc: Bjorn Helgaasbhelg...@google.com
Cc: Will Deaconwill.dea...@arm.com
Cc: Russell Kingli...@arm.linux.org.uk
Cc: Arnd Bergmanna...@arndb.de
Cc: Suravee Suthikulpanitsuravee.suthikulpa...@amd.com

Signed-off-by: Murali Karicherim-kariche...@ti.com
---
drivers/of/device.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/of/device.c b/drivers/of/device.c
index 2de320d..0a5ff54 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -105,12 +105,24 @@ void of_dma_configure(struct device *dev, struct
device_node *np)
ret = of_dma_get_range(np,dma_addr,paddr,size);
if (ret  0) {
dma_addr = offset = 0;
- size = dev-coherent_dma_mask;
+ size = dev-coherent_dma_mask + 1;
} else {
offset = PFN_DOWN(paddr - dma_addr);
+ /*
+ * Add a work around to treat the size as mask + 1 in case
+ * it is defined in DT as a mask.
+ */
+ if (size  1)
+ size = size + 1;
dev_dbg(dev, dma_pfn_offset(%#08lx)\n, offset);
}

+ /* if size is 0, we have an overflow of u64 */
+ if (!size) {
+ dev_err(dev, invalid size\n);
+ return;
+ }
+


This seems potentially fragile to dodgy DTs given that we might also be
using size to make a mask later. Would it make sense to double-up a
sanity check as mask-format detection? Something like:

if is_power_of_2(size)
// use size
else if is_power_of_2(size + 1)
// use size + 1
else
// cry


How about having the logic like this?

   ret = of_dma_get_range(np,dma_addr,paddr,size);
   if (ret  0) {
   dma_addr = offset = 0;
   size = dev-coherent_dma_mask + 1;
   } else {
   offset = PFN_DOWN(paddr - dma_addr);
   dev_dbg(dev, dma_pfn_offset(%#08lx)\n, offset);
   }

   if (is_power_of_2(size + 1))
   size = size + 1;
   else if (!is_power_of_2(size))
   {
   dev_err(dev, invalid size\n);
   return;
   }


In of_dma_configure(), we currently assume that the default coherent
mask is 32-bit. In this thread:

http://article.gmane.org/gmane.linux.kernel/1835096

we talked about setting the coherent mask based on size automatically.
I'm not sure about the size but I think we can assume is 32-bit mask + 1
if it is not specified in the DT. Instead of just assuming a default
mask, let's assume a default size and create the mask based on this
(untested):

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 5b33c6a21807..9ff8d1286b44 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -170,10 +170,10 @@ static void of_dma_configure(struct device *dev)
 struct iommu_ops *iommu;

 /*
-* Set default dma-mask to 32 bit. Drivers are expected to setup
-* the correct supported dma_mask.
+* Set default size to cover the 32-bit. Drivers are expected to setup
+* the correct size and dma_mask.
  */
-   dev-coherent_dma_mask = DMA_BIT_MASK(32);
+   size = 1ULL  32;

 /*
  * Set it to coherent_dma_mask by default if the architecture
@@ -185,13 +185,24 @@ static void of_dma_configure(struct device *dev)
 ret = of_dma_get_range(dev-of_node,dma_addr,paddr,size);
 if (ret  0) {
 dma_addr = offset = 0;
-   size = dev-coherent_dma_mask;


Are we assuming dma_addr, paddr and size are not touched on error? If
so, we can get rid of this clause entirely.
Checking the code for of_dma_get_range() I see paddr is modified on 
error case, but is used only for success case in this function. dma_addr 
and size are not modified. So setting dma_addr and offset to zero before 
hand like size might work as below


dma_addr = offset = 0;
size = 1ULL   32;

ret = of_dma_get_range(dev-of_node,dma_addr,paddr,size);
if (!ret) {
offset = PFN_DOWN(paddr - dma_addr);
}

.. rest of the code.

Murali





 } else {
 offset = PFN_DOWN(paddr - dma_addr);
 dev_dbg(dev, dma_pfn_offset(%#08lx)\n, dev-dma_pfn_offset);
 }
 dev-dma_pfn_offset = offset;

+   /*
+* Workaround for DTs setting the size to a mask or 0.
+*/
+   if (is_power_of_2(size + 1))
+   size += 1;


As I mentioned, I think power of 2 is too restrictive (from a DT
perspective even though the kernel may

[PATCH v5 4/5] iio: common: ssp_sensors: Add sensorhub accelerometer sensor

This patch adds accelerometer iio driver which uses sensorhub as data
provider.

Signed-off-by: Karol Wrona k.wr...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/iio/accel/Makefile   |1 +
 drivers/iio/accel/ssp_accel_sensor.c |  169 ++
 2 files changed, 170 insertions(+)
 create mode 100644 drivers/iio/accel/ssp_accel_sensor.c

diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
index de5b9cb..69c64b6 100644
--- a/drivers/iio/accel/Makefile
+++ b/drivers/iio/accel/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_KXCJK1013) += kxcjk-1013.o
 obj-$(CONFIG_KXSD9)+= kxsd9.o
 obj-$(CONFIG_MMA8452)  += mma8452.o
 obj-$(CONFIG_MMA9551)  += mma9551.o
+obj-$(CONFIG_IIO_SSP_SENSORS_COMMONS) += ssp_accel_sensor.o
 
 obj-$(CONFIG_IIO_ST_ACCEL_3AXIS) += st_accel.o
 st_accel-y := st_accel_core.o
diff --git a/drivers/iio/accel/ssp_accel_sensor.c 
b/drivers/iio/accel/ssp_accel_sensor.c
new file mode 100644
index 000..4ae05fc
--- /dev/null
+++ b/drivers/iio/accel/ssp_accel_sensor.c
@@ -0,0 +1,169 @@
+/*
+ *  Copyright (C) 2014, Samsung Electronics Co. Ltd. All Rights Reserved.
+ *
+ *  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 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 linux/iio/common/ssp_sensors.h
+#include linux/iio/iio.h
+#include linux/iio/kfifo_buf.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include ../common/ssp_sensors/ssp_iio_sensor.h
+
+#define SSP_CHANNEL_COUNT 3
+
+#define SSP_ACCEL_NAME ssp-accelerometer
+static const char ssp_accel_device_name[] = SSP_ACCEL_NAME;
+
+enum ssp_accel_3d_channel {
+   SSP_CHANNEL_SCAN_INDEX_X,
+   SSP_CHANNEL_SCAN_INDEX_Y,
+   SSP_CHANNEL_SCAN_INDEX_Z,
+   SSP_CHANNEL_SCAN_INDEX_TIME,
+};
+
+static int ssp_accel_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,  int *val,
+ int *val2, long mask)
+{
+   u32 t;
+   struct ssp_data *data = dev_get_drvdata(indio_dev-dev.parent-parent);
+
+   switch (mask) {
+   case IIO_CHAN_INFO_SAMP_FREQ:
+   t = ssp_get_sensor_delay(data, SSP_ACCELEROMETER_SENSOR);
+   ssp_convert_to_freq(t, val, val2);
+   return IIO_VAL_INT_PLUS_MICRO;
+   default:
+   break;
+   }
+
+   return -EINVAL;
+}
+
+static int ssp_accel_write_raw(struct iio_dev *indio_dev,
+  struct iio_chan_spec const *chan, int val,
+  int val2, long mask)
+{
+   int ret;
+   struct ssp_data *data = dev_get_drvdata(indio_dev-dev.parent-parent);
+
+   switch (mask) {
+   case IIO_CHAN_INFO_SAMP_FREQ:
+   ret = ssp_convert_to_time(val, val2);
+   ret = ssp_change_delay(data, SSP_ACCELEROMETER_SENSOR, ret);
+   if (ret  0)
+   dev_err(indio_dev-dev, accel sensor enable fail\n);
+
+   return ret;
+   default:
+   break;
+   }
+
+   return -EINVAL;
+}
+
+static struct iio_info ssp_accel_iio_info = {
+   .read_raw = ssp_accel_read_raw,
+   .write_raw = ssp_accel_write_raw,
+};
+
+static const unsigned long ssp_accel_scan_mask[] = { 0x7, 0, };
+
+static const struct iio_chan_spec ssp_acc_channels[] = {
+   SSP_CHANNEL_AG(IIO_ACCEL, IIO_MOD_X, SSP_CHANNEL_SCAN_INDEX_X),
+   SSP_CHANNEL_AG(IIO_ACCEL, IIO_MOD_Y, SSP_CHANNEL_SCAN_INDEX_Y),
+   SSP_CHANNEL_AG(IIO_ACCEL, IIO_MOD_Z, SSP_CHANNEL_SCAN_INDEX_Z),
+   SSP_CHAN_TIMESTAMP(SSP_CHANNEL_SCAN_INDEX_TIME),
+};
+
+static int ssp_process_accel_data(struct iio_dev *indio_dev, void *buf,
+ int64_t timestamp)
+{
+   return ssp_common_process_data(indio_dev, buf, SSP_ACCELEROMETER_SIZE,
+  timestamp);
+}
+
+static const struct iio_buffer_setup_ops ssp_accel_buffer_ops = {
+   .postenable = ssp_common_buffer_postenable,
+   .postdisable = ssp_common_buffer_postdisable,
+};
+
+static int ssp_accel_probe(struct platform_device *pdev)
+{
+   int ret;
+   struct iio_dev *indio_dev;
+   struct ssp_sensor_data *spd;
+   struct iio_buffer *buffer;
+
+   indio_dev = devm_iio_device_alloc(pdev-dev, sizeof(*spd));
+   if (!indio_dev)
+   return -ENOMEM;
+
+   spd = iio_priv(indio_dev);
+
+   spd-process_data = ssp_process_accel_data;
+   spd-type = SSP_ACCELEROMETER_SENSOR;
+
+   indio_dev-name =

[PATCH v5 1/5] iio: common: ssp_sensors: Add sensorhub driver

Sensorhub  is MCU dedicated to collect data and manage several sensors.
Sensorhub is a spi device which provides a layer for IIO devices. It provides
some data parsing and common mechanism for sensorhub sensors.

Adds common sensorhub library for sensorhub driver and iio drivers
which uses sensorhub MCU to communicate with sensors.

Signed-off-by: Karol Wrona k.wr...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/iio/common/Kconfig   |1 +
 drivers/iio/common/Makefile  |1 +
 drivers/iio/common/ssp_sensors/Kconfig   |   26 ++
 drivers/iio/common/ssp_sensors/Makefile  |8 +
 drivers/iio/common/ssp_sensors/ssp.h |  257 +++
 drivers/iio/common/ssp_sensors/ssp_dev.c |  712 ++
 drivers/iio/common/ssp_sensors/ssp_spi.c |  608 +
 include/linux/iio/common/ssp_sensors.h   |   82 
 8 files changed, 1695 insertions(+)
 create mode 100644 drivers/iio/common/ssp_sensors/Kconfig
 create mode 100644 drivers/iio/common/ssp_sensors/Makefile
 create mode 100644 drivers/iio/common/ssp_sensors/ssp.h
 create mode 100644 drivers/iio/common/ssp_sensors/ssp_dev.c
 create mode 100644 drivers/iio/common/ssp_sensors/ssp_spi.c
 create mode 100644 include/linux/iio/common/ssp_sensors.h

diff --git a/drivers/iio/common/Kconfig b/drivers/iio/common/Kconfig
index 0b6e97d..790f106 100644
--- a/drivers/iio/common/Kconfig
+++ b/drivers/iio/common/Kconfig
@@ -3,4 +3,5 @@
 #
 
 source drivers/iio/common/hid-sensors/Kconfig
+source drivers/iio/common/ssp_sensors/Kconfig
 source drivers/iio/common/st_sensors/Kconfig
diff --git a/drivers/iio/common/Makefile b/drivers/iio/common/Makefile
index 3112df0..b1e4d9c 100644
--- a/drivers/iio/common/Makefile
+++ b/drivers/iio/common/Makefile
@@ -8,4 +8,5 @@
 
 # When adding new entries keep the list in alphabetical order
 obj-y += hid-sensors/
+obj-y += ssp_sensors/
 obj-y += st_sensors/
diff --git a/drivers/iio/common/ssp_sensors/Kconfig 
b/drivers/iio/common/ssp_sensors/Kconfig
new file mode 100644
index 000..0ea4faf
--- /dev/null
+++ b/drivers/iio/common/ssp_sensors/Kconfig
@@ -0,0 +1,26 @@
+#
+# SSP sensor drivers and commons configuration
+#
+menu SSP Sensor Common
+
+config IIO_SSP_SENSORS_COMMONS
+   tristate Commons for all SSP Sensor IIO drivers
+   depends on IIO_SSP_SENSORHUB
+   select IIO_BUFFER
+   select IIO_KFIFO_BUF
+   help
+ Say yes here to build commons for SSP sensors.
+ To compile this as a module, choose M here: the module
+ will be called ssp_iio.
+
+config IIO_SSP_SENSORHUB
+   tristate Samsung Sensorhub driver
+   depends on SPI
+   select MFD_CORE
+   help
+ SSP driver for sensorhub.
+ If you say yes here you get ssp support for sensorhub.
+ To compile this driver as a module, choose M here: the
+ module will be called sensorhub.
+
+endmenu
diff --git a/drivers/iio/common/ssp_sensors/Makefile 
b/drivers/iio/common/ssp_sensors/Makefile
new file mode 100644
index 000..1e0389e
--- /dev/null
+++ b/drivers/iio/common/ssp_sensors/Makefile
@@ -0,0 +1,8 @@
+#
+# Makefile for SSP sensor drivers and commons.
+#
+
+sensorhub-objs := ssp_dev.o ssp_spi.o
+obj-$(CONFIG_IIO_SSP_SENSORHUB)+= sensorhub.o
+
+obj-$(CONFIG_IIO_SSP_SENSORS_COMMONS)  += ssp_iio.o
diff --git a/drivers/iio/common/ssp_sensors/ssp.h 
b/drivers/iio/common/ssp_sensors/ssp.h
new file mode 100644
index 000..b910e91
--- /dev/null
+++ b/drivers/iio/common/ssp_sensors/ssp.h
@@ -0,0 +1,257 @@
+/*
+ *  Copyright (C) 2014, Samsung Electronics Co. Ltd. All Rights Reserved.
+ *
+ *  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 program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ */
+
+#ifndef __SSP_SENSORHUB_H__
+#define __SSP_SENSORHUB_H__
+
+#include linux/delay.h
+#include linux/gpio.h
+#include linux/iio/common/ssp_sensors.h
+#include linux/iio/iio.h
+#include linux/spi/spi.h
+
+#define SSP_DEVICE_ID  0x55
+
+#ifdef SSP_DBG
+#define ssp_dbg(format, ...) pr_info([SSP] format, ##__VA_ARGS__)
+#else
+#define ssp_dbg(format, ...)
+#endif
+
+#define SSP_SW_RESET_TIME  3000
+/* Sensor polling in ms */
+#define SSP_DEFAULT_POLLING_DELAY  200
+#define SSP_DEFAULT_RETRIES3
+#define SSP_DATA_PACKET_SIZE   960
+#define SSP_HEADER_BUFFER_SIZE 4
+
+enum {
+   SSP_KERNEL_BINARY = 0,
+   SSP_KERNEL_CRASHED_BINARY,
+};
+
+enum {
+   SSP_INITIALIZATION_STATE = 0,
+   SSP_NO_SENSOR_STATE,
+

Re: [PATCH v4 1/6] of: iommu: add ptr to OF node arg to of_iommu_configure()

2015-01-28 Thread Will Deacon

On Mon, Jan 26, 2015 at 06:49:01PM +, Murali Karicheri wrote:
 On 01/25/2015 08:32 AM, Laurent Pinchart wrote:
  Hi Murali,
 
  Thank you for the patch.
 
  On Friday 23 January 2015 17:32:34 Murali Karicheri wrote:
  Function of_iommu_configure() is called from of_dma_configure() to
  setup iommu ops using DT property. This API is currently used for
  platform devices for which DMA configuration (including iommu ops)
  may come from device's parent. To extend this functionality for PCI
  devices, this API need to take a parent node ptr as an argument
  instead of assuming device's parent. This is needed since for PCI, the
  dma configuration may be defined in the DT node of the root bus bridge's
  parent device. Currently only dma-range is used for PCI and iommu is not
  supported. So return error if the device is PCI.
 
  Cc: Joerg Roedelj...@8bytes.org
  Cc: Grant Likelygrant.lik...@linaro.org
  Cc: Rob Herringrobh...@kernel.org
  Cc: Bjorn Helgaasbhelg...@google.com
  Cc: Will Deaconwill.dea...@arm.com
  Cc: Russell Kingli...@arm.linux.org.uk
  Cc: Arnd Bergmanna...@arndb.de
  Cc: Suravee Suthikulpanitsuravee.suthikulpa...@amd.com
 
  Signed-off-by: Murali Karicherim-kariche...@ti.com
  ---
drivers/iommu/of_iommu.c |   10 --
drivers/of/platform.c|2 +-
include/linux/of_iommu.h |6 --
3 files changed, 13 insertions(+), 5 deletions(-)
 
  diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
  index af1dc6a..439235b 100644
  --- a/drivers/iommu/of_iommu.c
  +++ b/drivers/iommu/of_iommu.c
  @@ -133,19 +133,25 @@ struct iommu_ops *of_iommu_get_ops(struct device_node
  *np) return ops;
}
 
  -struct iommu_ops *of_iommu_configure(struct device *dev)
  +struct iommu_ops *of_iommu_configure(struct device *dev,
  +   struct device_node *iommu_np)
{
 struct of_phandle_args iommu_spec;
 struct device_node *np;
 struct iommu_ops *ops = NULL;
 int idx = 0;
 
  +  if (dev_is_pci(dev)) {
  +  dev_err(dev, iommu is currently not supported for PCI\n);
  +  return NULL;
  +  }
  +
 /*
  * We don't currently walk up the tree looking for a parent IOMMU.
  * See the `Notes:' section of
  * Documentation/devicetree/bindings/iommu/iommu.txt
  */
  Wouldn't it be better to fix this rather than passing the device node 
  pointer
  to the function ? The solution would be more generic.
 Laurent,
 
 Will Deacon (Copied here) is working on this as we alteady discussed in 
 this thread. So it will be
 addressed by him in another series.

Well, working on this equates to has it somewhere near the bottom of
a very long list :)

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

[RFC v2 06/14] NFC: nci: Add nci_core_conn_create handler command/response

Add nci_core_conn_create handler according to NFC Forum NCI specification.
It is necessary for example for secure element handling.

Signed-off-by: Christophe Ricard christophe-h.ric...@st.com
---
 include/net/nfc/nci.h  | 25 +
 include/net/nfc/nci_core.h |  2 ++
 net/nfc/nci/core.c | 24 
 net/nfc/nci/rsp.c  | 31 +++
 4 files changed, 82 insertions(+)

diff --git a/include/net/nfc/nci.h b/include/net/nfc/nci.h
index 230f227..b8ff50c 100644
--- a/include/net/nfc/nci.h
+++ b/include/net/nfc/nci.h
@@ -243,6 +243,23 @@ struct nci_core_set_config_cmd {
struct  set_config_param param; /* support 1 param per cmd is enough */
 } __packed;
 
+#define NCI_OP_CORE_CONN_CREATE_CMDnci_opcode_pack(NCI_GID_CORE, 0x04)
+struct dest_spec_params {
+   __u8id;
+   __u8protocol;
+} __packed;
+
+struct core_conn_create_dest_spec_params {
+   __u8type;
+   __u8length;
+   struct dest_spec_params value;
+} __packed;
+
+struct nci_core_conn_create_cmd {
+   __u8destination_type;
+   __u8number_destination_params;
+   struct core_conn_create_dest_spec_params params;
+} __packed;
 #define NCI_OP_RF_DISCOVER_MAP_CMD nci_opcode_pack(NCI_GID_RF_MGMT, 0x00)
 struct disc_map_config {
__u8rf_protocol;
@@ -327,6 +344,14 @@ struct nci_core_set_config_rsp {
__u8params_id[0];   /* variable size array */
 } __packed;
 
+#define NCI_OP_CORE_CONN_CREATE_RSPnci_opcode_pack(NCI_GID_CORE, 0x04)
+struct nci_core_conn_create_rsp {
+   __u8status;
+   __u8max_ctrl_pkt_payload_len;
+   __u8credits;
+   __u8conn_id;
+} __packed;
+
 #define NCI_OP_RF_DISCOVER_MAP_RSP nci_opcode_pack(NCI_GID_RF_MGMT, 0x00)
 
 #define NCI_OP_RF_DISCOVER_RSP nci_opcode_pack(NCI_GID_RF_MGMT, 0x03)
diff --git a/include/net/nfc/nci_core.h b/include/net/nfc/nci_core.h
index 2f7ffa2..600cf30 100644
--- a/include/net/nfc/nci_core.h
+++ b/include/net/nfc/nci_core.h
@@ -186,6 +186,8 @@ int nci_set_config(struct nci_dev *ndev, __u8 id, size_t 
len, __u8 *val);
 
 int nci_nfcee_discover(struct nci_dev *ndev, u8 action);
 int nci_nfcee_mode_set(struct nci_dev *ndev, u8 nfcee_id, u8 nfcee_mode);
+int nci_core_conn_create(struct nci_dev *ndev,
+struct core_conn_create_dest_spec_params *params);
 
 static inline struct sk_buff *nci_skb_alloc(struct nci_dev *ndev,
unsigned int len,
diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index 8741a45..61648b4 100644
--- a/net/nfc/nci/core.c
+++ b/net/nfc/nci/core.c
@@ -494,6 +494,30 @@ int nci_nfcee_mode_set(struct nci_dev *ndev, u8 nfcee_id, 
u8 nfcee_mode)
 }
 EXPORT_SYMBOL(nci_nfcee_mode_set);
 
+static void nci_core_conn_create_req(struct nci_dev *ndev, unsigned long opt)
+{
+   struct nci_core_conn_create_cmd cmd;
+   struct core_conn_create_dest_spec_params *params =
+   (struct core_conn_create_dest_spec_params *)opt;
+
+   cmd.destination_type = NCI_DESTINATION_NFCEE;
+   cmd.number_destination_params = 1;
+   memcpy(cmd.params.type, params,
+  sizeof(struct core_conn_create_dest_spec_params));
+   nci_send_cmd(ndev, NCI_OP_CORE_CONN_CREATE_CMD,
+sizeof(struct nci_core_conn_create_cmd), cmd);
+}
+
+int nci_core_conn_create(struct nci_dev *ndev,
+struct core_conn_create_dest_spec_params *params)
+{
+   ndev-cur_id = params-value.id;
+   return nci_request(ndev, nci_core_conn_create_req,
+   (unsigned long)params,
+   msecs_to_jiffies(NCI_CMD_TIMEOUT));
+}
+EXPORT_SYMBOL(nci_core_conn_create);
+
 static int nci_set_local_general_bytes(struct nfc_dev *nfc_dev)
 {
struct nci_dev *ndev = nfc_get_drvdata(nfc_dev);
diff --git a/net/nfc/nci/rsp.c b/net/nfc/nci/rsp.c
index 1fb5b71..ddb0008 100644
--- a/net/nfc/nci/rsp.c
+++ b/net/nfc/nci/rsp.c
@@ -224,6 +224,33 @@ static void nci_nfcee_mode_set_rsp_packet(struct nci_dev 
*ndev,
nci_req_complete(ndev, status);
 }
 
+static void nci_core_conn_create_rsp_packet(struct nci_dev *ndev,
+   struct sk_buff *skb)
+{
+   __u8 status = skb-data[0];
+   struct nci_conn_info *conn_info;
+   struct nci_core_conn_create_rsp *rsp;
+
+   pr_debug(status 0x%x\n, status);
+
+   if (status == NCI_STATUS_OK) {
+   rsp = (struct nci_core_conn_create_rsp *)skb-data;
+   conn_info = ndev-conn_info_by_id[ndev-cur_id];
+   if (!conn_info) {
+   status = NCI_STATUS_REJECTED;
+   goto exit;
+   }
+
+   conn_info-conn_id = rsp-conn_id;
+   ndev-conn_info_by_conn_id[conn_info-conn_id] = conn_info;
+   conn_info-max_pkt_payload_len = rsp-max_ctrl_pkt_payload_len;
+

Re: [PATCH v3 3/4] ARM: digicolor: add minimal device tree description

2015-01-28 Thread Baruch Siach

Hi Olof,

On Tue, Jan 27, 2015 at 03:01:41PM -0800, Olof Johansson wrote:
 On Wed, Jan 14, 2015 at 10:40:32AM +0200, Baruch Siach wrote:
  cx92755.dtsi describes CX92755 on chip peripherals. conexant_equinox.dts
  describes the Equinox evaluation board for the CX92755 SoC.
  
  Acked-by: Arnd Bergmann a...@arndb.de
  Signed-off-by: Baruch Siach bar...@tkos.co.il
  ---
   arch/arm/boot/dts/Makefile |   1 +
   arch/arm/boot/dts/conexant_equinox.dts |  74 +++
   arch/arm/boot/dts/cx92755.dtsi | 107 
  +
   3 files changed, 182 insertions(+)
   create mode 100644 arch/arm/boot/dts/conexant_equinox.dts
   create mode 100644 arch/arm/boot/dts/cx92755.dtsi
  
  diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
  index 91bd5bd62857..fbeb65eaddda 100644
  --- a/arch/arm/boot/dts/Makefile
  +++ b/arch/arm/boot/dts/Makefile
  @@ -75,6 +75,7 @@ dtb-$(CONFIG_ARCH_BRCMSTB) += \
  bcm7445-bcm97445svmb.dtb
   dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
  da850-evm.dtb
  +dtb-$(CONFIG_ARCH_DIGICOLOR) += conexant_equinox.dtb
   dtb-$(CONFIG_ARCH_EFM32) += efm32gg-dk3750.dtb
   dtb-$(CONFIG_ARCH_EXYNOS) += exynos3250-monk.dtb \
  exynos3250-rinato.dtb \
  diff --git a/arch/arm/boot/dts/conexant_equinox.dts 
  b/arch/arm/boot/dts/conexant_equinox.dts
  new file mode 100644
  index ..f33bf5635d47
  --- /dev/null
  +++ b/arch/arm/boot/dts/conexant_equinox.dts
 
 To segment the namespace a bit, we ask that you prefix your dts files with the
 platform. What would be a suitable prefix here? conexant? digicolor?

I think we should use the actual SoC name, that is cx92755, just like the 
.dtsi file is named. I'll resend this patch with the name change and a few 
more incremental changes needed by the interrupt controller and timer drivers.

Thanks,
baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
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

[RFC v2 08/14] NFC: st21nfcb: Add HCI protocol over NCI protocol support

Some st21nfcb features are only available through HCI commands. Those
HCI commands can be address over NCI by sending data using a dynamic
conn_id. This is useful for example for Secure Element communication.

The HCI core brings the minimal HCI functions required to communicate with
a secure element.

Signed-off-by: Christophe Ricard christophe-h.ric...@st.com
---
 drivers/nfc/st21nfcb/Makefile|   2 +-
 drivers/nfc/st21nfcb/st21nfcb_hci_core.c | 823 +++
 drivers/nfc/st21nfcb/st21nfcb_hci_core.h | 134 +
 3 files changed, 958 insertions(+), 1 deletion(-)
 create mode 100644 drivers/nfc/st21nfcb/st21nfcb_hci_core.c
 create mode 100644 drivers/nfc/st21nfcb/st21nfcb_hci_core.h

diff --git a/drivers/nfc/st21nfcb/Makefile b/drivers/nfc/st21nfcb/Makefile
index f4d835d..974c2e9 100644
--- a/drivers/nfc/st21nfcb/Makefile
+++ b/drivers/nfc/st21nfcb/Makefile
@@ -2,7 +2,7 @@
 # Makefile for ST21NFCB NCI based NFC driver
 #
 
-st21nfcb_nci-objs = ndlc.o st21nfcb.o
+st21nfcb_nci-objs = ndlc.o st21nfcb.o st21nfcb_hci_core.o
 obj-$(CONFIG_NFC_ST21NFCB) += st21nfcb_nci.o
 
 st21nfcb_i2c-objs = i2c.o
diff --git a/drivers/nfc/st21nfcb/st21nfcb_hci_core.c 
b/drivers/nfc/st21nfcb/st21nfcb_hci_core.c
new file mode 100644
index 000..ba48dce
--- /dev/null
+++ b/drivers/nfc/st21nfcb/st21nfcb_hci_core.c
@@ -0,0 +1,823 @@
+/*
+ * NCI based Driver for STMicroelectronics NFC Chip
+ *
+ * Copyright (C) 2014  STMicroelectronics SAS. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/nfc.h
+#include net/nfc/nci.h
+#include net/nfc/nci_core.h
+
+#include st21nfcb_hci_core.h
+
+struct nci_data {
+   u8  conn_id;
+   u8  pipe;
+   u8  cmd;
+   const u8*data;
+   u32 data_len;
+} __packed;
+
+struct st21nfcb_hci_create_pipe_params {
+   u8 src_gate;
+   u8 dest_host;
+   u8 dest_gate;
+} __packed;
+
+struct st21nfcb_hci_create_pipe_resp {
+   u8 src_host;
+   u8 src_gate;
+   u8 dest_host;
+   u8 dest_gate;
+   u8 pipe;
+} __packed;
+
+struct st21nfcb_hci_delete_pipe_noti {
+   u8 pipe;
+} __packed;
+
+struct st21nfcb_hci_all_pipe_cleared_noti {
+   u8 host;
+} __packed;
+
+struct st21nfcb_hcp_message {
+   u8 header;  /* type -cmd,evt,rsp- + instruction */
+   u8 data[];
+} __packed;
+
+struct st21nfcb_hcp_packet {
+   u8 header;  /* cbit+pipe */
+   struct st21nfcb_hcp_message message;
+} __packed;
+
+
+#define ST21NFCB_HCI_ANY_SET_PARAMETER 0x01
+#define ST21NFCB_HCI_ANY_GET_PARAMETER 0x02
+#define ST21NFCB_HCI_ANY_CLOSE_PIPE0x04
+
+#define ST21NFCB_HFP_NO_CHAINING   0x80
+
+#define NCI_NFCEE_ID_HCI   0x80
+
+#define ST21NFCB_EVT_HOT_PLUG  0x03
+
+#define ST21NFCB_HCI_ADMIN_PARAM_SESSION_IDENTITY   0x01
+
+/* HCP headers */
+#define ST21NFCB_HCI_HCP_PACKET_HEADER_LEN 1
+#define ST21NFCB_HCI_HCP_MESSAGE_HEADER_LEN1
+#define ST21NFCB_HCI_HCP_HEADER_LEN2
+
+/* HCP types */
+#define ST21NFCB_HCI_HCP_COMMAND   0x00
+#define ST21NFCB_HCI_HCP_EVENT 0x01
+#define ST21NFCB_HCI_HCP_RESPONSE  0x02
+
+#define ST21NFCB_HCI_ADM_NOTIFY_PIPE_CREATED 0x12
+#define ST21NFCB_HCI_ADM_NOTIFY_PIPE_DELETED 0x13
+#define ST21NFCB_HCI_ADM_NOTIFY_ALL_PIPE_CLEARED 0x15
+
+#define ST21NFCB_HCI_FRAGMENT  0x7f
+#define ST21NFCB_HCP_HEADER(type, instr) type)  0x03)  6) |\
+  ((instr)  0x3f))
+
+#define ST21NFCB_HCP_MSG_GET_TYPE(header) ((header  0xc0)  6)
+#define ST21NFCB_HCP_MSG_GET_CMD(header)  (header  0x3f)
+#define ST21NFCB_HCP_MSG_GET_PIPE(header) (header  0x7f)
+
+#define ST21NFCB_NUM_DEVICES   256
+
+static DECLARE_BITMAP(dev_mask, ST21NFCB_NUM_DEVICES);
+
+static void st21nfcb_hci_data_received_cb(void *context,
+ struct sk_buff *skb, int err);
+
+static void st21nfcb_hci_reset_pipes(struct st21nfcb_hci_dev *hdev)
+{
+   int i;
+
+   for (i = 0; i  ST21NFCB_HCI_MAX_PIPES; i++) {
+   hdev-pipes[i].gate = ST21NFCB_HCI_INVALID_GATE;
+   hdev-pipes[i].host = ST21NFCB_HCI_INVALID_HOST;
+   }
+   memset(hdev-gate2pipe, ST21NFCB_HCI_INVALID_PIPE,
+  sizeof(hdev-gate2pipe));
+}
+
+static void st21nfcb_hci_reset_pipes_per_host(struct

[PATCH v5 3/5] iio: common: ssp_sensors: Add sensorhub iio commons

This patch adds common library for sensorhub iio drivers.

Signed-off-by: Karol Wrona k.wr...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/iio/common/ssp_sensors/ssp_iio.c|  107 +++
 drivers/iio/common/ssp_sensors/ssp_iio_sensor.h |   70 +++
 2 files changed, 177 insertions(+)
 create mode 100644 drivers/iio/common/ssp_sensors/ssp_iio.c
 create mode 100644 drivers/iio/common/ssp_sensors/ssp_iio_sensor.h

diff --git a/drivers/iio/common/ssp_sensors/ssp_iio.c 
b/drivers/iio/common/ssp_sensors/ssp_iio.c
new file mode 100644
index 000..a3ae165
--- /dev/null
+++ b/drivers/iio/common/ssp_sensors/ssp_iio.c
@@ -0,0 +1,107 @@
+/*
+ *  Copyright (C) 2014, Samsung Electronics Co. Ltd. All Rights Reserved.
+ *
+ *  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 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 linux/iio/common/ssp_sensors.h
+#include linux/iio/kfifo_buf.h
+#include linux/module.h
+#include linux/slab.h
+#include ssp_iio_sensor.h
+
+/**
+ * ssp_common_buffer_postenable() - generic postenable callback for ssp buffer
+ *
+ * @indio_dev: iio device
+ *
+ * Returns 0 or negative value in case of error
+ */
+int ssp_common_buffer_postenable(struct iio_dev *indio_dev)
+{
+   struct ssp_sensor_data *spd = iio_priv(indio_dev);
+   struct ssp_data *data = dev_get_drvdata(indio_dev-dev.parent-parent);
+
+   /* the allocation is made in post because scan size is known in this
+* moment
+* */
+   spd-buffer = kmalloc(indio_dev-scan_bytes, GFP_KERNEL | GFP_DMA);
+   if (!spd-buffer)
+   return -ENOMEM;
+
+   return ssp_enable_sensor(data, spd-type,
+ssp_get_sensor_delay(data, spd-type));
+}
+EXPORT_SYMBOL(ssp_common_buffer_postenable);
+
+/**
+ * ssp_common_buffer_postdisable() - generic postdisable callback for ssp 
buffer
+ *
+ * @indio_dev: iio device
+ *
+ * Returns 0 or negative value in case of error
+ */
+int ssp_common_buffer_postdisable(struct iio_dev *indio_dev)
+{
+   int ret;
+   struct ssp_sensor_data *spd = iio_priv(indio_dev);
+   struct ssp_data *data = dev_get_drvdata(indio_dev-dev.parent-parent);
+
+   ret = ssp_disable_sensor(data, spd-type);
+   if (ret  0)
+   return ret;
+
+   kfree(spd-buffer);
+
+   return ret;
+}
+EXPORT_SYMBOL(ssp_common_buffer_postdisable);
+
+/**
+ * ssp_common_process_data() - Common process data callback for ssp sensors
+ *
+ * @indio_dev: iio device
+ * @buf:   source buffer
+ * @len:   sensor data length
+ * @timestamp: system timestamp
+ *
+ * Returns 0 or negative value in case of error
+ */
+int ssp_common_process_data(struct iio_dev *indio_dev, void *buf,
+   unsigned int len, int64_t timestamp)
+{
+   __le32 time;
+   int64_t calculated_time;
+   struct ssp_sensor_data *spd = iio_priv(indio_dev);
+
+   if (indio_dev-scan_bytes == 0)
+   return 0;
+
+   /*
+* it always sends full set of samples, remember about available masks
+*/
+   memcpy(spd-buffer, buf, len);
+
+   if (indio_dev-scan_timestamp) {
+   memcpy(time, ((char *)buf)[len], SSP_TIME_SIZE);
+   calculated_time =
+   timestamp + (int64_t)le32_to_cpu(time) * 100;
+   }
+
+   return iio_push_to_buffers_with_timestamp(indio_dev, spd-buffer,
+ calculated_time);
+}
+EXPORT_SYMBOL(ssp_common_process_data);
+
+MODULE_AUTHOR(Karol Wrona k.wr...@samsung.com);
+MODULE_DESCRIPTION(Samsung sensorhub commons);
+MODULE_LICENSE(GPL);
diff --git a/drivers/iio/common/ssp_sensors/ssp_iio_sensor.h 
b/drivers/iio/common/ssp_sensors/ssp_iio_sensor.h
new file mode 100644
index 000..dda267c
--- /dev/null
+++ b/drivers/iio/common/ssp_sensors/ssp_iio_sensor.h
@@ -0,0 +1,70 @@
+#ifndef __SSP_IIO_SENSOR_H__
+#define __SSP_IIO_SENSOR_H__
+
+#define SSP_CHANNEL_AG(_type, _mod, _index) \
+{ \
+   .type = _type,\
+   .modified = 1,\
+   .channel2 = _mod,\
+   .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SAMP_FREQ),\
+   .scan_index = _index,\
+   .scan_type = {\
+   .sign = 's',\
+   .realbits = 16,\
+   .storagebits = 16,\
+   .shift = 0,\
+   .endianness = IIO_LE,\
+   },\
+}
+
+/* It

[RFC v2 09/14] NFC: st21nfcb: Adding support for secure element

st21nfcb has 3 SWP lines and can support up to 3 secure elements (UICC/eSE and 
µSD in the future).

Some st21nfcb firmware does not support the nci command 
nci_nfcee_mode_set(NCI_NFCEE_DISABLE).
For this reason, we assume 2 secures elements are always present (UICC and eSE).
They will be added to the SE list once successfully activated. They will
be available only after running through enable_se handler or when the poll
in listen mode is started.

During initialization, the white_list will be always set assuming both
UICC  eSE are present.

On ese activation, the atr is retrieved to calculate a command exchange
timeout according to the first atr(TB) value.

The se_io will allow to transfer data over SWP. 2 kind of event may appear
after a data is sent over:
- ST21NFCB_EVT_TRANSMIT_DATA when receiving an apdu answer
- ST21NFCB_EVT_WTX_REQUEST when the secure element needs more time than
expected to compute a command. If this timeout expired, a first recovery
tentative consist to send a simple software reset command. If this
tentative still fail, a second recovery tentative consist to send a
hardware reset.
This function is only relevant for eSE like secure element.

Like st21nfca, we do reference pipe with a tuple (gate, host) in order to
keep the host information when receiving secure element event
(ex: EVT_TRANSACTION).

Signed-off-by: Christophe Ricard christophe-h.ric...@st.com
---
 drivers/nfc/st21nfcb/Makefile  |   2 +-
 drivers/nfc/st21nfcb/st21nfcb.c|   8 +-
 drivers/nfc/st21nfcb/st21nfcb.h|   2 +
 drivers/nfc/st21nfcb/st21nfcb_se.c | 610 +
 drivers/nfc/st21nfcb/st21nfcb_se.h |  59 
 5 files changed, 679 insertions(+), 2 deletions(-)
 create mode 100644 drivers/nfc/st21nfcb/st21nfcb_se.c
 create mode 100644 drivers/nfc/st21nfcb/st21nfcb_se.h

diff --git a/drivers/nfc/st21nfcb/Makefile b/drivers/nfc/st21nfcb/Makefile
index 974c2e9..2f452d7 100644
--- a/drivers/nfc/st21nfcb/Makefile
+++ b/drivers/nfc/st21nfcb/Makefile
@@ -2,7 +2,7 @@
 # Makefile for ST21NFCB NCI based NFC driver
 #
 
-st21nfcb_nci-objs = ndlc.o st21nfcb.o st21nfcb_hci_core.o
+st21nfcb_nci-objs = ndlc.o st21nfcb.o st21nfcb_hci_core.o st21nfcb_se.o
 obj-$(CONFIG_NFC_ST21NFCB) += st21nfcb_nci.o
 
 st21nfcb_i2c-objs = i2c.o
diff --git a/drivers/nfc/st21nfcb/st21nfcb.c b/drivers/nfc/st21nfcb/st21nfcb.c
index ea63d58..d2b60eb 100644
--- a/drivers/nfc/st21nfcb/st21nfcb.c
+++ b/drivers/nfc/st21nfcb/st21nfcb.c
@@ -22,6 +22,7 @@
 #include net/nfc/nci_core.h
 
 #include st21nfcb.h
+#include st21nfcb_se.h
 
 #define DRIVER_DESC NCI NFC driver for ST21NFCB
 
@@ -78,6 +79,10 @@ static struct nci_ops st21nfcb_nci_ops = {
.close = st21nfcb_nci_close,
.send = st21nfcb_nci_send,
.get_rfprotocol = st21nfcb_nci_get_rfprotocol,
+   .discover_se = st21nfcb_nci_discover_se,
+   .enable_se = st21nfcb_nci_enable_se,
+   .disable_se = st21nfcb_nci_disable_se,
+   .se_io = st21nfcb_nci_se_io,
 };
 
 int st21nfcb_nci_probe(struct llt_ndlc *ndlc, int phy_headroom,
@@ -114,9 +119,10 @@ int st21nfcb_nci_probe(struct llt_ndlc *ndlc, int 
phy_headroom,
if (r) {
pr_err(Cannot register nfc device to nci core\n);
nci_free_device(ndlc-ndev);
+   return r;
}
 
-   return r;
+   return st21nfcb_se_init(ndlc-ndev);
 }
 EXPORT_SYMBOL_GPL(st21nfcb_nci_probe);
 
diff --git a/drivers/nfc/st21nfcb/st21nfcb.h b/drivers/nfc/st21nfcb/st21nfcb.h
index ea58a56..5ef8a58 100644
--- a/drivers/nfc/st21nfcb/st21nfcb.h
+++ b/drivers/nfc/st21nfcb/st21nfcb.h
@@ -19,6 +19,7 @@
 #ifndef __LOCAL_ST21NFCB_H_
 #define __LOCAL_ST21NFCB_H_
 
+#include st21nfcb_se.h
 #include ndlc.h
 
 /* Define private flags: */
@@ -27,6 +28,7 @@
 struct st21nfcb_nci_info {
struct llt_ndlc *ndlc;
unsigned long flags;
+   struct st21nfcb_se_info se_info;
 };
 
 void st21nfcb_nci_remove(struct nci_dev *ndev);
diff --git a/drivers/nfc/st21nfcb/st21nfcb_se.c 
b/drivers/nfc/st21nfcb/st21nfcb_se.c
new file mode 100644
index 000..cf65368
--- /dev/null
+++ b/drivers/nfc/st21nfcb/st21nfcb_se.c
@@ -0,0 +1,610 @@
+/*
+ * NCI based Driver for STMicroelectronics NFC Chip
+ *
+ * Copyright (C) 2014  STMicroelectronics SAS. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/nfc.h
+#include net/nfc/nci.h
+#include

Re: [PATCH v7 0/2] watchdog: ImgTec PDC Watchdog Timer Driver

2015-01-28 Thread Ezequiel Garcia

On 01/20/2015 10:59 AM, Guenter Roeck wrote:
 On 01/20/2015 03:13 AM, Ezequiel Garcia wrote:
 Hi Wim,

 On 01/06/2015 10:19 AM, Ezequiel Garcia wrote:
 Here's the seventh round for IMG PDC Watchdog driver.
 The series is based on v3.19-rc3.


 Guenter has reviewed both patches. Do you think you can review this
 soonishly and let me know if you have more comments?

 
 I'll send a pull request to Wim either this or next week.
 

Guenter,

I hate to be so spammy here. Do you still plan to send a pull request?

Next week is -rc7, so I'm wondering if there's any way we can be on time
for v3.20.
-- 
Ezequiel
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] ARM: zynq: Remove bogus value from 'bias-disable' property

2015-01-28 Thread Sören Brinkmann

On Wed, 2015-01-28 at 03:21PM +0100, Michal Simek wrote:
 On 01/27/2015 01:38 AM, Andreas Färber wrote:
  Am 26.01.2015 um 20:49 schrieb Soren Brinkmann:
  In one pinctrl node, a 'bias-disable' property is erroneously assigned a
  value.
 
  Fixes: ARM: zynq: DT: Add pinctrl information
  Signed-off-by: Soren Brinkmann soren.brinkm...@xilinx.com
  
  Reviewed-by: Andreas Färber afaer...@suse.de
  
  Andreas
  
 
 Applied both.

Thanks. Given how the branch looks now, you could squash 'ARM: zynq: DT:
Remove bogus value from 'bias-disable' property' and 'ARM: zynq: DT: Add
pinctrl information to USB nodes' into 'ARM: zynq: DT: Add pinctrl
information'. Then we have it all in one patch and spare everybody the
intermittent, partly broken commits.

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

[PATCH v2 3/7] ASoC: pcm512x: Change register default to match actual content after reset