Re: [RFC PATCH 3/3] ARM: dts: add MCT property use-cp15-phys-counter for exynos5422-odroidxu3

2015-07-27 Thread Krzysztof Kozlowski 
On 28.07.2015 06:28, Alexey Klimov wrote:
 Speedup MCT operation on odroid-xu3 dev board by using
 coprocessor 64-bit counter instead of reading same counter
 located in mmio region.
 
 Tested on Odroid-xu3.
 
 Signed-off-by: Alexey Klimov klimov.li...@gmail.com
 ---
  arch/arm/boot/dts/exynos5422-odroidxu3.dts | 4 

Please do this in Odroid XU3 common DTSI:
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi

  1 file changed, 4 insertions(+)
 
 diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts 
 b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
 index 78e6a50..b7f6c8f 100644
 --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
 +++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
 @@ -18,6 +18,10 @@
   compatible = hardkernel,odroid-xu3, samsung,exynos5800, 
 samsung,exynos5;
  };
  
 +mct {
 + use-cp15-phys-counter;
 +};
 +

Put the node in alphabetical position.

Best regards,
Krzysztof

  i2c_0 {
   status = okay;
  
 

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] cpufreq-dt: add turbo modes support

2015-07-27 Thread Bartlomiej Zolnierkiewicz 

Hi,

On Monday, July 27, 2015 02:07:54 PM Viresh Kumar wrote:
 On 09-07-15, 17:43, Bartlomiej Zolnierkiewicz wrote:
  diff --git a/include/linux/cpufreq-dt.h b/include/linux/cpufreq-dt.h
  index 0414009..483ca1b 100644
  --- a/include/linux/cpufreq-dt.h
  +++ b/include/linux/cpufreq-dt.h
  @@ -17,6 +17,7 @@ struct cpufreq_dt_platform_data {
   * clock.
   */
  bool independent_clocks;
  +   bool boost_supported;
   };
 
 I am planning to kill this structure soon, don't add anything to it.
 We should be doing this based on DT.

This change was in the original patch posted in April:
https://lkml.org/lkml/2015/4/10/646

your review from a month ago didn't contain this request:
https://lkml.org/lkml/2015/6/22/667

and now (after nearly 4 months) you are telling me that
I should change this because you are planning to do some
more changes in the future.

Could we please keep it as it is for now and change it
later (after independent_clocks configuration will get
ported to use device tree)?

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

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

Re: [PATCH v2 2/7] cpufreq: opp: fix handling of turbo modes

2015-07-27 Thread Viresh Kumar 
On 27-07-15, 13:14, Bartlomiej Zolnierkiewicz wrote:
 Sorry but you don't seem to understand the issue.

:)

No, I did. I understand that if someone uses opp bindings today with
some entries as turbo OPPs, cpufreq will use them as normal
frequencies. And that may harm the board.

BUT, opp-v2 code isn't ready to be used yet. And platforms should see
what all is implemented before trying to use them.

All I was saying is, this isn't a FIX as we haven't introduced the
feature yet. Otherwise I had no issues with the patch.

-- 
viresh
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] cpufreq-dt: add turbo modes support

2015-07-27 Thread Bartlomiej Zolnierkiewicz 
On Monday, July 27, 2015 05:03:40 PM Viresh Kumar wrote:
 On 27-07-15, 13:01, Bartlomiej Zolnierkiewicz wrote:
 
 First of all, please don't be angry :).. We can discuss and get things
 sorted out ...

OK :)

  This change was in the original patch posted in April:
  https://lkml.org/lkml/2015/4/10/646
 
 Yeah, and I already apologized for missing the request :)
 
  your review from a month ago didn't contain this request:
  https://lkml.org/lkml/2015/6/22/667
 
 Your patch inserted almost 116 lines and most of the stuff was around
 adding new bindings to get things working with cpufreq-dt driver.
 
 And so I replied to the most important stuff, i.e. don't add new
 bindings, we will sort it out with opp-v2.
 
 And frankly that wasn't the time where we could have discussed how
 exactly we are going to use it. Ofcourse we should get it via DT,
 platform data is just not required.
 
 So, me not NAK ing this approach was fine as it wasn't about keeping
 this data in the platform data part.
 
  and now (after nearly 4 months) you are telling me that
 
 I will say a month, as we discarded most of that patch recently :)
 
  I should change this because you are planning to do some
  more changes in the future.
 
 Its not about me doing some changes. But the whole point of doing the
 opp-v2 thing was to get rid of such platform data things..
 
 Just that your work is competing with opp-v2 code :)
 
  Could we please keep it as it is for now and change it
  later (after independent_clocks configuration will get
  ported to use device tree)?
 
 I thought we can get your work to a better shape, with all credit to
 you. But if you have some dependency on this for 4.3, then I don't
 mind killing this structure after you have polluted it a bit more :)

Thank you.  This is exactly the case here (I would like to get
Exynos4x12 conversion to use cpufreq-dt + exynos-cpufreq removal
in v4.3 if possible and adding new DT bindings will most likely
slow down the process considerably).

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

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

Re: [PATCH v2 2/7] cpufreq: opp: fix handling of turbo modes

2015-07-27 Thread Bartlomiej Zolnierkiewicz 

Hi,

On Monday, July 27, 2015 04:05:21 PM Viresh Kumar wrote:
 On 27-07-15, 12:24, Bartlomiej Zolnierkiewicz wrote:
  Have you read my explanation of the issue?
  
  With your OPP-v2 patches cpufreq-dt picks turbo frequencies and uses
  them as normal ones.
  
  (More at: http://www.spinics.net/lists/arm-kernel/msg430397.html)
 
 Yes I did. I understand that the turbo frequencies are not considered
 as such by OPP/cpufreq core and it requires your changes to get it
 working.

Sorry but you don't seem to understand the issue.

The problem is that without my patch and with your OPP-v2 patches
turbo frequencies get picked by OPP/cpufreq core and then by cpufreq-dt.
This happens without enabling any boost  thermal etc. support for
turbo frequencies.

 But its not an issue or bug we are fixing, the problem is that the
 code for opp-v2 isn't complete yet and your patches is putting things
 in place. So, we are still doing the bring up here and not fixing a
 bug really.

I consider the possibility to use turbo frequencies without explicitly
enabling boost support to be a buggy behavior.  While it is unlikely
that somebody defines turbo frequencies in their dts file in the near
future (except Exynos ones) it costs as nearly nothing to prevent
such behavior now.

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

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] cpufreq-dt: add turbo modes support

2015-07-27 Thread Viresh Kumar 
On 27-07-15, 13:58, Bartlomiej Zolnierkiewicz wrote:
 Thank you.  This is exactly the case here (I would like to get
 Exynos4x12 conversion to use cpufreq-dt + exynos-cpufreq removal
 in v4.3 if possible and adding new DT bindings will most likely
 slow down the process considerably).

Heh, I never asked you to add new DT bindings, I said we can solve it
with DT. We already have turbo properties in DT.

-- 
viresh
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] cpufreq-dt: add turbo modes support

2015-07-27 Thread Viresh Kumar 
On 27-07-15, 13:01, Bartlomiej Zolnierkiewicz wrote:

First of all, please don't be angry :).. We can discuss and get things
sorted out ...

 This change was in the original patch posted in April:
 https://lkml.org/lkml/2015/4/10/646

Yeah, and I already apologized for missing the request :)

 your review from a month ago didn't contain this request:
 https://lkml.org/lkml/2015/6/22/667

Your patch inserted almost 116 lines and most of the stuff was around
adding new bindings to get things working with cpufreq-dt driver.

And so I replied to the most important stuff, i.e. don't add new
bindings, we will sort it out with opp-v2.

And frankly that wasn't the time where we could have discussed how
exactly we are going to use it. Ofcourse we should get it via DT,
platform data is just not required.

So, me not NAK ing this approach was fine as it wasn't about keeping
this data in the platform data part.

 and now (after nearly 4 months) you are telling me that

I will say a month, as we discarded most of that patch recently :)

 I should change this because you are planning to do some
 more changes in the future.

Its not about me doing some changes. But the whole point of doing the
opp-v2 thing was to get rid of such platform data things..

Just that your work is competing with opp-v2 code :)

 Could we please keep it as it is for now and change it
 later (after independent_clocks configuration will get
 ported to use device tree)?

I thought we can get your work to a better shape, with all credit to
you. But if you have some dependency on this for 4.3, then I don't
mind killing this structure after you have polluted it a bit more :)

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

Re: [PATCH v2 2/7] cpufreq: opp: fix handling of turbo modes

2015-07-27 Thread Bartlomiej Zolnierkiewicz 
On Monday, July 27, 2015 05:06:41 PM Viresh Kumar wrote:
 On 27-07-15, 13:14, Bartlomiej Zolnierkiewicz wrote:
  Sorry but you don't seem to understand the issue.
 
 :)
 
 No, I did. I understand that if someone uses opp bindings today with
 some entries as turbo OPPs, cpufreq will use them as normal
 frequencies. And that may harm the board.
 
 BUT, opp-v2 code isn't ready to be used yet. And platforms should see
 what all is implemented before trying to use them.

OK.

 All I was saying is, this isn't a FIX as we haven't introduced the
 feature yet. Otherwise I had no issues with the patch.

I will update the description for the next patchset revision.

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

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

[PATCH 08/12] ARM: SAMSUNG: local irq-uart header in mach-s3c64xx

2015-07-27 Thread Kukjin Kim 

This patch moves irq-uart header file into mach-s3c64xx.

Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Signed-off-by: Kukjin Kim kg...@kernel.org
---
 arch/arm/mach-s3c64xx/common.c  | 2 +-
 arch/arm/{plat-samsung/include/plat = mach-s3c64xx}/irq-uart.h | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)
 rename arch/arm/{plat-samsung/include/plat = mach-s3c64xx}/irq-uart.h (90%)

diff --git a/arch/arm/mach-s3c64xx/common.c b/arch/arm/mach-s3c64xx/common.c
index 16547f2..316df5a 100644
--- a/arch/arm/mach-s3c64xx/common.c
+++ b/arch/arm/mach-s3c64xx/common.c
@@ -48,12 +48,12 @@
 #include plat/devs.h
 #include plat/pm.h
 #include plat/gpio-cfg.h
-#include plat/irq-uart.h
 #include plat/pwm-core.h
 #include plat/regs-irqtype.h
 #include plat/watchdog-reset.h
 
 #include common.h
+#include irq-uart.h
 
 /* External clock frequency */
 static unsigned long xtal_f = 1200, xusbxti_f = 4800;
diff --git a/arch/arm/plat-samsung/include/plat/irq-uart.h 
b/arch/arm/mach-s3c64xx/irq-uart.h
similarity index 90%
rename from arch/arm/plat-samsung/include/plat/irq-uart.h
rename to arch/arm/mach-s3c64xx/irq-uart.h
index a9331e4..4b29613 100644
--- a/arch/arm/plat-samsung/include/plat/irq-uart.h
+++ b/arch/arm/mach-s3c64xx/irq-uart.h
@@ -1,5 +1,4 @@
-/* arch/arm/plat-samsung/include/plat/irq-uart.h
- *
+/*
  * Copyright (c) 2010 Simtec Electronics
  * Ben Dooks b...@simtec.co.uk
  *
-- 
2.0.0

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

[PATCH 10/12] ARM: SAMSUNG: local onenand-core header in mach-s3c64xx

2015-07-27 Thread Kukjin Kim 

This patch moves onenand-core header file into mach-s3c64xx.

Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Signed-off-by: Kukjin Kim kg...@kernel.org
---
 arch/arm/{plat-samsung/include/plat = mach-s3c64xx}/onenand-core.h | 2 --
 arch/arm/mach-s3c64xx/s3c6400.c | 2 +-
 arch/arm/mach-s3c64xx/s3c6410.c | 2 +-
 3 files changed, 2 insertions(+), 4 deletions(-)
 rename arch/arm/{plat-samsung/include/plat = mach-s3c64xx}/onenand-core.h 
(95%)

diff --git a/arch/arm/plat-samsung/include/plat/onenand-core.h 
b/arch/arm/mach-s3c64xx/onenand-core.h
similarity index 95%
rename from arch/arm/plat-samsung/include/plat/onenand-core.h
rename to arch/arm/mach-s3c64xx/onenand-core.h
index 7701cb7..925eb13 100644
--- a/arch/arm/plat-samsung/include/plat/onenand-core.h
+++ b/arch/arm/mach-s3c64xx/onenand-core.h
@@ -1,6 +1,4 @@
 /*
- * linux/arch/arm/plat-samsung/onenand-core.h
- *
  *  Copyright (c) 2010 Samsung Electronics
  *  Kyungmin Park kyungmin.p...@samsung.com
  *  Marek Szyprowski m.szyprow...@samsung.com
diff --git a/arch/arm/mach-s3c64xx/s3c6400.c b/arch/arm/mach-s3c64xx/s3c6400.c
index 1ce48c5..33273ab 100644
--- a/arch/arm/mach-s3c64xx/s3c6400.c
+++ b/arch/arm/mach-s3c64xx/s3c6400.c
@@ -41,9 +41,9 @@
 #include plat/devs.h
 #include plat/sdhci.h
 #include plat/iic-core.h
-#include plat/onenand-core.h
 
 #include common.h
+#include onenand-core.h
 
 void __init s3c6400_map_io(void)
 {
diff --git a/arch/arm/mach-s3c64xx/s3c6410.c b/arch/arm/mach-s3c64xx/s3c6410.c
index 5081f08..eadc48d 100644
--- a/arch/arm/mach-s3c64xx/s3c6410.c
+++ b/arch/arm/mach-s3c64xx/s3c6410.c
@@ -43,10 +43,10 @@
 #include plat/sdhci.h
 #include plat/adc-core.h
 #include plat/iic-core.h
-#include plat/onenand-core.h
 
 #include ata-core.h
 #include common.h
+#include onenand-core.h
 
 void __init s3c6410_map_io(void)
 {
-- 
2.0.0

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

[PATCH 09/12] ARM: SAMSUNG: local keypad header in mach-s3c64xx

2015-07-27 Thread Kukjin Kim 

This patch moves keypad header file into mach-s3c64xx.

Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Signed-off-by: Kukjin Kim kg...@kernel.org
---
 arch/arm/{plat-samsung/include/plat = mach-s3c64xx}/keypad.h | 0
 arch/arm/mach-s3c64xx/mach-crag6410.c | 2 +-
 arch/arm/mach-s3c64xx/mach-smdk6410.c | 2 +-
 arch/arm/mach-s3c64xx/setup-keypad.c  | 3 ++-
 4 files changed, 4 insertions(+), 3 deletions(-)
 rename arch/arm/{plat-samsung/include/plat = mach-s3c64xx}/keypad.h (100%)

diff --git a/arch/arm/plat-samsung/include/plat/keypad.h 
b/arch/arm/mach-s3c64xx/keypad.h
similarity index 100%
rename from arch/arm/plat-samsung/include/plat/keypad.h
rename to arch/arm/mach-s3c64xx/keypad.h
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c 
b/arch/arm/mach-s3c64xx/mach-crag6410.c
index 65c426b..098c144 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
@@ -57,7 +57,6 @@
 #include plat/gpio-cfg.h
 #include linux/platform_data/spi-s3c64xx.h
 
-#include plat/keypad.h
 #include plat/devs.h
 #include plat/cpu.h
 #include plat/adc.h
@@ -67,6 +66,7 @@
 
 #include common.h
 #include crag6410.h
+#include keypad.h
 #include regs-gpio-memport.h
 #include regs-modem.h
 #include regs-sys.h
diff --git a/arch/arm/mach-s3c64xx/mach-smdk6410.c 
b/arch/arm/mach-s3c64xx/mach-smdk6410.c
index d590b88..4bb8b8b 100644
--- a/arch/arm/mach-s3c64xx/mach-smdk6410.c
+++ b/arch/arm/mach-s3c64xx/mach-smdk6410.c
@@ -67,11 +67,11 @@
 #include plat/cpu.h
 #include plat/adc.h
 #include linux/platform_data/touchscreen-s3c2410.h
-#include plat/keypad.h
 #include plat/samsung-time.h
 
 #include backlight.h
 #include common.h
+#include keypad.h
 #include regs-modem.h
 #include regs-srom.h
 #include regs-sys.h
diff --git a/arch/arm/mach-s3c64xx/setup-keypad.c 
b/arch/arm/mach-s3c64xx/setup-keypad.c
index 6ad9a89..128a803 100644
--- a/arch/arm/mach-s3c64xx/setup-keypad.c
+++ b/arch/arm/mach-s3c64xx/setup-keypad.c
@@ -12,9 +12,10 @@
 
 #include linux/gpio.h
 #include plat/gpio-cfg.h
-#include plat/keypad.h
 #include mach/gpio-samsung.h
 
+#include keypad.h
+
 void samsung_keypad_cfg_gpio(unsigned int rows, unsigned int cols)
 {
/* Set all the necessary GPK pins to special-function 3: KP_ROW[x] */
-- 
2.0.0

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

[PATCH 07/12] ARM: SAMSUNG: local backlight header in mach-s3c64xx

2015-07-27 Thread Kukjin Kim 

This patch moves backlight header file into mach-s3c64xx.

Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Signed-off-by: Kukjin Kim kg...@kernel.org
---
 arch/arm/{plat-samsung/include/plat = mach-s3c64xx}/backlight.h | 3 +--
 arch/arm/mach-s3c64xx/dev-backlight.c| 3 ++-
 arch/arm/mach-s3c64xx/mach-smdk6410.c| 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)
 rename arch/arm/{plat-samsung/include/plat = mach-s3c64xx}/backlight.h (92%)

diff --git a/arch/arm/plat-samsung/include/plat/backlight.h 
b/arch/arm/mach-s3c64xx/backlight.h
similarity index 92%
rename from arch/arm/plat-samsung/include/plat/backlight.h
rename to arch/arm/mach-s3c64xx/backlight.h
index ad530c7..8dcacac 100644
--- a/arch/arm/plat-samsung/include/plat/backlight.h
+++ b/arch/arm/mach-s3c64xx/backlight.h
@@ -1,5 +1,4 @@
-/* linux/arch/arm/plat-samsung/include/plat/backlight.h
- *
+/*
  * Copyright (c) 2011 Samsung Electronics Co., Ltd.
  *  http://www.samsung.com
  *
diff --git a/arch/arm/mach-s3c64xx/dev-backlight.c 
b/arch/arm/mach-s3c64xx/dev-backlight.c
index 62f4648..38c323e 100644
--- a/arch/arm/mach-s3c64xx/dev-backlight.c
+++ b/arch/arm/mach-s3c64xx/dev-backlight.c
@@ -17,7 +17,8 @@
 
 #include plat/devs.h
 #include plat/gpio-cfg.h
-#include plat/backlight.h
+
+#include backlight.h
 
 struct samsung_bl_drvdata {
struct platform_pwm_backlight_data plat_data;
diff --git a/arch/arm/mach-s3c64xx/mach-smdk6410.c 
b/arch/arm/mach-s3c64xx/mach-smdk6410.c
index b7447a9..d590b88 100644
--- a/arch/arm/mach-s3c64xx/mach-smdk6410.c
+++ b/arch/arm/mach-s3c64xx/mach-smdk6410.c
@@ -68,9 +68,9 @@
 #include plat/adc.h
 #include linux/platform_data/touchscreen-s3c2410.h
 #include plat/keypad.h
-#include plat/backlight.h
 #include plat/samsung-time.h
 
+#include backlight.h
 #include common.h
 #include regs-modem.h
 #include regs-srom.h
-- 
2.0.0

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

[PATCH 11/12] ARM: SAMSUNG: local watchdog-reset header in mach-s3c64xx

2015-07-27 Thread Kukjin Kim 

This patch moves watchdog-reset header file into mach-s3c64xx.

Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Signed-off-by: Kukjin Kim kg...@kernel.org
---
 arch/arm/mach-s3c64xx/common.c| 2 +-
 arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c   | 3 +--
 arch/arm/{plat-samsung/include/plat = mach-s3c64xx}/watchdog-reset.h | 3 +--
 3 files changed, 3 insertions(+), 5 deletions(-)
 rename arch/arm/{plat-samsung/include/plat = mach-s3c64xx}/watchdog-reset.h 
(91%)

diff --git a/arch/arm/mach-s3c64xx/common.c b/arch/arm/mach-s3c64xx/common.c
index 316df5a..4a9621b 100644
--- a/arch/arm/mach-s3c64xx/common.c
+++ b/arch/arm/mach-s3c64xx/common.c
@@ -50,10 +50,10 @@
 #include plat/gpio-cfg.h
 #include plat/pwm-core.h
 #include plat/regs-irqtype.h
-#include plat/watchdog-reset.h
 
 #include common.h
 #include irq-uart.h
+#include watchdog-reset.h
 
 /* External clock frequency */
 static unsigned long xtal_f = 1200, xusbxti_f = 4800;
diff --git a/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c 
b/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
index 2fddf38..ead3766 100644
--- a/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
+++ b/arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c
@@ -15,11 +15,10 @@
 #include asm/system_misc.h
 
 #include plat/cpu.h
-#include plat/watchdog-reset.h
-
 #include mach/map.h
 
 #include common.h
+#include watchdog-reset.h
 
 /*
  * IO mapping for shared system controller IP.
diff --git a/arch/arm/plat-samsung/include/plat/watchdog-reset.h 
b/arch/arm/mach-s3c64xx/watchdog-reset.h
similarity index 91%
rename from arch/arm/plat-samsung/include/plat/watchdog-reset.h
rename to arch/arm/mach-s3c64xx/watchdog-reset.h
index 0386b8f..42707df 100644
--- a/arch/arm/plat-samsung/include/plat/watchdog-reset.h
+++ b/arch/arm/mach-s3c64xx/watchdog-reset.h
@@ -1,5 +1,4 @@
-/* arch/arm/plat-s3c/include/plat/watchdog-reset.h
- *
+/*
  * Copyright (c) 2008 Simtec Electronics
  * Ben Dooks b...@simtec.co.uk
  *
-- 
2.0.0

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

[PATCH 01/12] ARM: SAMSUNG: local regs-srom header in mach-exynos

2015-07-27 Thread Kukjin Kim 

This patch moves regs-srom header file into mach-exynos.

c: Krzysztof Kozlowski k.kozlow...@samsung.com
Signed-off-by: Kukjin Kim kg...@kernel.org
---
 arch/arm/{plat-samsung/include/plat = mach-exynos}/regs-srom.h | 3 +--
 arch/arm/mach-exynos/suspend.c  | 4 ++--
 2 files changed, 3 insertions(+), 4 deletions(-)
 rename arch/arm/{plat-samsung/include/plat = mach-exynos}/regs-srom.h (96%)

diff --git a/arch/arm/plat-samsung/include/plat/regs-srom.h 
b/arch/arm/mach-exynos/regs-srom.h
similarity index 96%
rename from arch/arm/plat-samsung/include/plat/regs-srom.h
rename to arch/arm/mach-exynos/regs-srom.h
index 9b6729c..5c4d442 100644
--- a/arch/arm/plat-samsung/include/plat/regs-srom.h
+++ b/arch/arm/mach-exynos/regs-srom.h
@@ -1,5 +1,4 @@
-/* linux/arch/arm/plat-samsung/include/plat/regs-srom.h
- *
+/*
  * Copyright (c) 2010 Samsung Electronics Co., Ltd.
  * http://www.samsung.com
  *
diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index c506f8e..e00eb39 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -32,11 +32,11 @@
 #include asm/suspend.h
 
 #include plat/pm-common.h
-#include plat/regs-srom.h
 
 #include common.h
-#include regs-pmu.h
 #include exynos-pmu.h
+#include regs-pmu.h
+#include regs-srom.h
 
 #define REG_TABLE_END (-1U)
 
-- 
2.0.0

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

[PATCH 05/12] ARM: SAMSUNG: local regs-usb-hsotg-phy header in mach-s3c64xx

2015-07-27 Thread Kukjin Kim 

This patch moves regs-usb-hsotg-phy header file into mach-s3c64xx.

Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Signed-off-by: Kukjin Kim kg...@kernel.org
---
 .../{plat-samsung/include/plat = mach-s3c64xx}/regs-usb-hsotg-phy.h   | 3 +--
 arch/arm/mach-s3c64xx/setup-usb-phy.c  | 2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)
 rename arch/arm/{plat-samsung/include/plat = 
mach-s3c64xx}/regs-usb-hsotg-phy.h (96%)

diff --git a/arch/arm/plat-samsung/include/plat/regs-usb-hsotg-phy.h 
b/arch/arm/mach-s3c64xx/regs-usb-hsotg-phy.h
similarity index 96%
rename from arch/arm/plat-samsung/include/plat/regs-usb-hsotg-phy.h
rename to arch/arm/mach-s3c64xx/regs-usb-hsotg-phy.h
index fcf2796..eae3c31 100644
--- a/arch/arm/plat-samsung/include/plat/regs-usb-hsotg-phy.h
+++ b/arch/arm/mach-s3c64xx/regs-usb-hsotg-phy.h
@@ -1,5 +1,4 @@
-/* arch/arm/plat-s3c/include/plat/regs-usb-hsotg-phy.h
- *
+/*
  * Copyright 2008 Openmoko, Inc.
  * Copyright 2008 Simtec Electronics
  *  http://armlinux.simtec.co.uk/
diff --git a/arch/arm/mach-s3c64xx/setup-usb-phy.c 
b/arch/arm/mach-s3c64xx/setup-usb-phy.c
index ca960bd..2b17b7f 100644
--- a/arch/arm/mach-s3c64xx/setup-usb-phy.c
+++ b/arch/arm/mach-s3c64xx/setup-usb-phy.c
@@ -16,10 +16,10 @@
 #include linux/platform_device.h
 #include mach/map.h
 #include plat/cpu.h
-#include plat/regs-usb-hsotg-phy.h
 #include plat/usb-phy.h
 
 #include regs-sys.h
+#include regs-usb-hsotg-phy.h
 
 static int s3c_usb_otgphy_init(struct platform_device *pdev)
 {
-- 
2.0.0

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

[PATCH 02/12] ARM: SAMSUNG: local fb-core header in mach-s3c24xx

2015-07-27 Thread Kukjin Kim 

This patch moves fb-core header file into mach-s3c24xx.

Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Signed-off-by: Kukjin Kim kg...@kernel.org
---
 arch/arm/{plat-samsung/include/plat = mach-s3c24xx}/fb-core.h | 2 --
 arch/arm/mach-s3c24xx/s3c2416.c| 2 +-
 arch/arm/mach-s3c24xx/s3c2443.c| 3 ++-
 3 files changed, 3 insertions(+), 4 deletions(-)
 rename arch/arm/{plat-samsung/include/plat = mach-s3c24xx}/fb-core.h (93%)

diff --git a/arch/arm/plat-samsung/include/plat/fb-core.h 
b/arch/arm/mach-s3c24xx/fb-core.h
similarity index 93%
rename from arch/arm/plat-samsung/include/plat/fb-core.h
rename to arch/arm/mach-s3c24xx/fb-core.h
index bca383e..103bdba 100644
--- a/arch/arm/plat-samsung/include/plat/fb-core.h
+++ b/arch/arm/mach-s3c24xx/fb-core.h
@@ -1,6 +1,4 @@
 /*
- * arch/arm/plat-samsung/include/plat/fb-core.h
- *
  * Copyright 2010 Samsung Electronics Co., Ltd.
  * Pawel Osciak p.osc...@samsung.com
  *
diff --git a/arch/arm/mach-s3c24xx/s3c2416.c b/arch/arm/mach-s3c24xx/s3c2416.c
index 3f8ca2a..b911851 100644
--- a/arch/arm/mach-s3c24xx/s3c2416.c
+++ b/arch/arm/mach-s3c24xx/s3c2416.c
@@ -59,12 +59,12 @@
 #include plat/pm.h
 
 #include plat/iic-core.h
-#include plat/fb-core.h
 #include plat/nand-core.h
 #include plat/adc-core.h
 #include plat/spi-core.h
 
 #include common.h
+#include fb-core.h
 
 static struct map_desc s3c2416_iodesc[] __initdata = {
IODESC_ENT(WATCHDOG),
diff --git a/arch/arm/mach-s3c24xx/s3c2443.c b/arch/arm/mach-s3c24xx/s3c2443.c
index 87b6b89..91dd964 100644
--- a/arch/arm/mach-s3c24xx/s3c2443.c
+++ b/arch/arm/mach-s3c24xx/s3c2443.c
@@ -41,11 +41,12 @@
 #include plat/gpio-cfg-helpers.h
 #include plat/devs.h
 #include plat/cpu.h
-#include plat/fb-core.h
 #include plat/nand-core.h
 #include plat/adc-core.h
 #include plat/spi-core.h
 
+#include fb-core.h
+
 static struct map_desc s3c2443_iodesc[] __initdata = {
IODESC_ENT(WATCHDOG),
IODESC_ENT(CLKPWR),
-- 
2.0.0

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

[PATCH 04/12] ARM: SAMSUNG: local spi-core header in mach-s3c24xx

2015-07-27 Thread Kukjin Kim 

This patch moves spi-core header file into mach-s3c24xx.

Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Signed-off-by: Kukjin Kim kg...@kernel.org
---
 arch/arm/mach-s3c24xx/s3c2416.c | 2 +-
 arch/arm/mach-s3c24xx/s3c2443.c | 2 +-
 arch/arm/{plat-samsung/include/plat = mach-s3c24xx}/spi-core.h | 0
 3 files changed, 2 insertions(+), 2 deletions(-)
 rename arch/arm/{plat-samsung/include/plat = mach-s3c24xx}/spi-core.h (100%)

diff --git a/arch/arm/mach-s3c24xx/s3c2416.c b/arch/arm/mach-s3c24xx/s3c2416.c
index 2469b27..621b864 100644
--- a/arch/arm/mach-s3c24xx/s3c2416.c
+++ b/arch/arm/mach-s3c24xx/s3c2416.c
@@ -60,11 +60,11 @@
 
 #include plat/iic-core.h
 #include plat/adc-core.h
-#include plat/spi-core.h
 
 #include common.h
 #include fb-core.h
 #include nand-core.h
+#include spi-core.h
 
 static struct map_desc s3c2416_iodesc[] __initdata = {
IODESC_ENT(WATCHDOG),
diff --git a/arch/arm/mach-s3c24xx/s3c2443.c b/arch/arm/mach-s3c24xx/s3c2443.c
index 5269d08..b559d37 100644
--- a/arch/arm/mach-s3c24xx/s3c2443.c
+++ b/arch/arm/mach-s3c24xx/s3c2443.c
@@ -42,10 +42,10 @@
 #include plat/devs.h
 #include plat/cpu.h
 #include plat/adc-core.h
-#include plat/spi-core.h
 
 #include fb-core.h
 #include nand-core.h
+#include spi-core.h
 
 static struct map_desc s3c2443_iodesc[] __initdata = {
IODESC_ENT(WATCHDOG),
diff --git a/arch/arm/plat-samsung/include/plat/spi-core.h 
b/arch/arm/mach-s3c24xx/spi-core.h
similarity index 100%
rename from arch/arm/plat-samsung/include/plat/spi-core.h
rename to arch/arm/mach-s3c24xx/spi-core.h
-- 
2.0.0

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

[PATCH 06/12] ARM: SAMSUNG: local ata-core header in mach-s3c64xx

2015-07-27 Thread Kukjin Kim 

This patch moves ata-core header file into mach-s3c64xx.

Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Signed-off-by: Kukjin Kim kg...@kernel.org
---
 arch/arm/{plat-samsung/include/plat = mach-s3c64xx}/ata-core.h | 3 +--
 arch/arm/mach-s3c64xx/s3c6410.c | 2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)
 rename arch/arm/{plat-samsung/include/plat = mach-s3c64xx}/ata-core.h (92%)

diff --git a/arch/arm/plat-samsung/include/plat/ata-core.h 
b/arch/arm/mach-s3c64xx/ata-core.h
similarity index 92%
rename from arch/arm/plat-samsung/include/plat/ata-core.h
rename to arch/arm/mach-s3c64xx/ata-core.h
index f5a4ec7..5951f24 100644
--- a/arch/arm/plat-samsung/include/plat/ata-core.h
+++ b/arch/arm/mach-s3c64xx/ata-core.h
@@ -1,5 +1,4 @@
-/* linux/arch/arm/plat-samsung/include/plat/ata-core.h
- *
+/*
  * Copyright (c) 2010 Samsung Electronics Co., Ltd.
  * http://www.samsung.com
  *
diff --git a/arch/arm/mach-s3c64xx/s3c6410.c b/arch/arm/mach-s3c64xx/s3c6410.c
index b2a7930..5081f08 100644
--- a/arch/arm/mach-s3c64xx/s3c6410.c
+++ b/arch/arm/mach-s3c64xx/s3c6410.c
@@ -41,11 +41,11 @@
 #include plat/cpu.h
 #include plat/devs.h
 #include plat/sdhci.h
-#include plat/ata-core.h
 #include plat/adc-core.h
 #include plat/iic-core.h
 #include plat/onenand-core.h
 
+#include ata-core.h
 #include common.h
 
 void __init s3c6410_map_io(void)
-- 
2.0.0

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

[PATCH 03/12] ARM: SAMSUNG: local nand-core header in mach-s3c24xx

2015-07-27 Thread Kukjin Kim 

This patch moves nand-core header file into mach-s3c24xx.

Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Signed-off-by: Kukjin Kim kg...@kernel.org
---
 arch/arm/{plat-samsung/include/plat = mach-s3c24xx}/nand-core.h | 3 +--
 arch/arm/mach-s3c24xx/s3c2412.c  | 2 +-
 arch/arm/mach-s3c24xx/s3c2416.c  | 2 +-
 arch/arm/mach-s3c24xx/s3c2443.c  | 2 +-
 arch/arm/mach-s3c24xx/s3c244x.c  | 2 +-
 5 files changed, 5 insertions(+), 6 deletions(-)
 rename arch/arm/{plat-samsung/include/plat = mach-s3c24xx}/nand-core.h (93%)

diff --git a/arch/arm/plat-samsung/include/plat/nand-core.h 
b/arch/arm/mach-s3c24xx/nand-core.h
similarity index 93%
rename from arch/arm/plat-samsung/include/plat/nand-core.h
rename to arch/arm/mach-s3c24xx/nand-core.h
index 6de2078..7e811fe 100644
--- a/arch/arm/plat-samsung/include/plat/nand-core.h
+++ b/arch/arm/mach-s3c24xx/nand-core.h
@@ -1,5 +1,4 @@
-/* arch/arm/plat-samsung/include/plat/nand-core.h
- *
+/*
  * Copyright (c) 2010 Samsung Electronics Co., Ltd.
  * http://www.samsung.com/
  *
diff --git a/arch/arm/mach-s3c24xx/s3c2412.c b/arch/arm/mach-s3c24xx/s3c2412.c
index 64a1360..fb5ee8d 100644
--- a/arch/arm/mach-s3c24xx/s3c2412.c
+++ b/arch/arm/mach-s3c24xx/s3c2412.c
@@ -40,11 +40,11 @@
 #include plat/cpu.h
 #include plat/cpu-freq.h
 #include plat/devs.h
-#include plat/nand-core.h
 #include plat/pm.h
 #include plat/regs-spi.h
 
 #include common.h
+#include nand-core.h
 #include regs-dsc.h
 #include s3c2412-power.h
 
diff --git a/arch/arm/mach-s3c24xx/s3c2416.c b/arch/arm/mach-s3c24xx/s3c2416.c
index b911851..2469b27 100644
--- a/arch/arm/mach-s3c24xx/s3c2416.c
+++ b/arch/arm/mach-s3c24xx/s3c2416.c
@@ -59,12 +59,12 @@
 #include plat/pm.h
 
 #include plat/iic-core.h
-#include plat/nand-core.h
 #include plat/adc-core.h
 #include plat/spi-core.h
 
 #include common.h
 #include fb-core.h
+#include nand-core.h
 
 static struct map_desc s3c2416_iodesc[] __initdata = {
IODESC_ENT(WATCHDOG),
diff --git a/arch/arm/mach-s3c24xx/s3c2443.c b/arch/arm/mach-s3c24xx/s3c2443.c
index 91dd964..5269d08 100644
--- a/arch/arm/mach-s3c24xx/s3c2443.c
+++ b/arch/arm/mach-s3c24xx/s3c2443.c
@@ -41,11 +41,11 @@
 #include plat/gpio-cfg-helpers.h
 #include plat/devs.h
 #include plat/cpu.h
-#include plat/nand-core.h
 #include plat/adc-core.h
 #include plat/spi-core.h
 
 #include fb-core.h
+#include nand-core.h
 
 static struct map_desc s3c2443_iodesc[] __initdata = {
IODESC_ENT(WATCHDOG),
diff --git a/arch/arm/mach-s3c24xx/s3c244x.c b/arch/arm/mach-s3c24xx/s3c244x.c
index b141195..31fd273 100644
--- a/arch/arm/mach-s3c24xx/s3c244x.c
+++ b/arch/arm/mach-s3c24xx/s3c244x.c
@@ -41,9 +41,9 @@
 #include plat/devs.h
 #include plat/cpu.h
 #include plat/pm.h
-#include plat/nand-core.h
 
 #include common.h
+#include nand-core.h
 #include regs-dsc.h
 
 static struct map_desc s3c244x_iodesc[] __initdata = {
-- 
2.0.0

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

[PATCH 12/12] ARM: SAMSUNG: remove keypad-core header in plat-samsung

2015-07-27 Thread Kukjin Kim 

Since keypad-core header is not used, this patch removes it.

Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: Joonyoung Shim jy0922.s...@samsung.com
Signed-off-by: Kukjin Kim kg...@kernel.org
---
 arch/arm/plat-samsung/include/plat/keypad-core.h | 31 
 1 file changed, 31 deletions(-)
 delete mode 100644 arch/arm/plat-samsung/include/plat/keypad-core.h

diff --git a/arch/arm/plat-samsung/include/plat/keypad-core.h 
b/arch/arm/plat-samsung/include/plat/keypad-core.h
deleted file mode 100644
index d513e1b..000
--- a/arch/arm/plat-samsung/include/plat/keypad-core.h
+++ /dev/null
@@ -1,31 +0,0 @@
-/*
- * linux/arch/arm/plat-samsung/include/plat/keypad-core.h
- *
- * Copyright (C) 2010 Samsung Electronics Co.Ltd   
- * Author: Joonyoung Shim jy0922.s...@samsung.com
- *
- * Samsung keypad controller core function
- *
- *  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.
- *
- */
-
-#ifndef __ASM_ARCH_KEYPAD_CORE_H
-#define __ASM_ARCH_KEYPAD_CORE_H
-
-/* These function are only for use with the core support code, such as
- * the cpu specific initialisation code
- */
-
-/* re-define device name depending on support. */
-static inline void samsung_keypad_setname(char *name)
-{
-#ifdef CONFIG_SAMSUNG_DEV_KEYPAD
-   samsung_device_keypad.name = name;
-#endif
-}
-
-#endif /* __ASM_ARCH_KEYPAD_CORE_H */
-- 
2.0.0

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

Re: [PATCH 08/11] MTD: m25p80: Add option to limit SPI transfer size.

2015-07-27 Thread Marek Vasut 
On Monday, July 27, 2015 at 11:46:25 AM, Michal Suchanek wrote:
 On 24 July 2015 at 10:34, Marek Vasut ma...@denx.de wrote:
  On Thursday, July 23, 2015 at 07:03:47 PM, Michal Suchanek wrote:
  
  Hi!
  
  [...]
  
   It's probably slower to set up DMA for 2-byte commands but it might
   work nonetheless.
   
   It is, the overhead will be considerable. It might help the stability
   though. I'm really looking forward to the results!
   
   Hello,
   
   this does not quite work.
   
   My test with spidev:
   
   # ./spinor /dev/spidev1.0
   Sending 9f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   Received 00 ff c8 60 16 c8 60 16 c8 60 16 c8 60 16 c8 60
   Sending 90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   Received 00 ff ff ff ff c8 15 c8 15 c8 15 c8 15 c8 15 c8
   Sending 9f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
   Received 00 ff c8 60 16 c8 60 16 c8 60 16 c8 60 16 c8 60
   
   I receive correct ID but spi-nor complains it does not know ID 00 c8
   60. IIRC garbage should be sent only at the time command is
   transferred so only one byte of garbage should be received. Also the
   garbage tends to be the last state of the data output - all 0 or all
   1.
   So it seems using DMA for all transfers including 1-byte commands
   results in (some?) received data getting an extra 00 prefix.
   
   
   I also managed to lock up the controller completely since there is
   some error passing the SPI speed somewhere :(
   
   [ 1352.977530] spidev spi1.0: setup mode 0, 8 bits/w, 8000 Hz max
   -- 0 [ 1352.977540] spidev spi1.0: spi mode 0
   [ 1352.977576] spidev spi1.0: setup mode 0, 8 bits/w, 8000 Hz max
   -- 0 [ 1352.977582] spidev spi1.0: msb first
   [ 1352.977614] spidev spi1.0: setup mode 0, 8 bits/w, 8000 Hz max
   -- 0 [ 1352.977620] spidev spi1.0: 0 bits per word
   [ 1352.977652] spidev spi1.0: setup mode 0, 8 bits/w, 2690588672 Hz
   max -- 0 [ 1352.977726] spi_master spi1: s3c64xx_spi_config:
   clk_from_cmu 1 src_clk sclk_spi1 mode bpw 8
   [ 1352.977753] spi_master spi1: spi1.0 s3c64xx_spi_transfer_one: xfer
   bpw 8 speed -1604378624
   [ 1352.977760] spi_master spi1: s3c64xx_spi_config: clk_from_cmu 1
   src_clk sclk_spi1 mode bpw 8
   [ 1352.977781] spi_master spi1: spi1.0 s3c64xx_spi_transfer_one: using
   dma [ 1352.977797] dma-pl330 121b.pdma: setting up request on
   thread 1
  
  Hmm, on a second thought it probably works as expected more or less.
  
  The nonsensical value was passed from application and there is no
  guard against that.
  
  Since I don't do PIO the controller remains locked up indefinitely.
  
  I have to admit, I don't quite understand the above. I also don't quite
  know what your spidev test does. Can you possibly just bind a regular
  SPI NOR driver and run mtdtests to see if it is stable ?
 
 Ok, so here is some summary.
 
 I have a NOR flash attached to a s3c64xx SPI controller with 64byte
 fifo and a pl330 dma controller.
 
 Normally DMA controller is used for transfers that do not fit into the
 FIFO.
 
 I tried adding the flash memory ID to the spi-nor driver table and
 adding a DT node for it.
 
 The flash is rated at 120MHz so I used that speed but the ID was
 bit-shifted and identification failed. There is DT property
 samsung,spi-feedback-delay for addressing this and at 120MHz it must
 be 2 or 3 on this board. 40MHz works with default value 0.
 
 The next step after identification worked was to try reading the flash
 content. For this the DMA controller is used because data is
 transferred in blocks larger than 64 bytes. When reading the whole 4MB
 flash the transfer failed silently. I got a 4MB file of all ones or
 all zeroes.
 
 It turns out that
 
  - the pl330 locks up when transfering large amount of data.
 Specifically, the maximum power of 2 sized transfer at 120MHz is 128
 bytes and 64k at 40MHz. Transferring more than this results in the
 pl330 locking up and never signalling completion of the transfer.

Hypothesis:
I think this might just be that the controller didn't catch all the
inbound clock ticks and thus counted less inbound data than it was
set up to receive. The controller thus waits for more data.

 Data
 is left in FIFO which causes subsequent commands to fail since garbage
 is returned instead of command reply. Also subsequent read may cause
 I/O error or or return an empty page depending on the garbage around.

So the driver for the DMA controller might need to be augmented to handle
this case -- add a timeout and in case DMA times out, drain the FIFO to
make sure subsequent transfers do not fail.

 - the I/O errors are not checked in spi-nor at all which leads to
 silent data corruption.
 
 On a suggestion that this may improve reliability I changed the
 s3c64xx driver to use DMA for all transfers. This caused
 identification to fail in spin-nor because the ID was prefixed with
 extra 00  byte. Testing with spidev confirmed that everything is
 prefixed with extra 00.

The determinism of this is in fact

Re: [PATCH v2 06/13] irqchip: kill off set_irq_flags usage

2015-07-27 Thread Rob Herring 
On Sat, Jul 25, 2015 at 8:34 AM, Gregory CLEMENT
gregory.clem...@free-electrons.com wrote:
 Hi Rob,

 On 12/07/2015 16:26, Rob Herring wrote:
 set_irq_flags is ARM specific with custom flags which have genirq
 equivalents. Convert drivers to use the genirq interfaces directly, so we
 can kill off set_irq_flags. The translation of flags is as follows:

 IRQF_VALID - !IRQ_NOREQUEST
 IRQF_PROBE - !IRQ_NOPROBE
 IRQF_NOAUTOEN - IRQ_NOAUTOEN

 For IRQs managed by an irqdomain, the irqdomain core code handles clearing
 and setting IRQ_NOREQUEST already, so there is no need to do this in
 .map() functions and we can simply remove the set_irq_flags calls. Some
 users also set IRQ_NOPROBE and this has been maintained although it is not
 clear that is really needed. There appears to be a great deal of blind
 copy and paste of this code.

 Signed-off-by: Rob Herring r...@kernel.org
 Cc: Thomas Gleixner t...@linutronix.de
 Cc: Jason Cooper ja...@lakedaemon.net
 Cc: Kukjin Kim kg...@kernel.org
 Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
 Cc: Stephen Warren swar...@wwwdotorg.org
 Cc: Lee Jones l...@kernel.org
 Cc: Alexander Shiyan shc_w...@mail.ru
 Cc: Maxime Ripard maxime.rip...@free-electrons.com
 Cc: linux-arm-ker...@lists.infradead.org
 Cc: linux-samsung-soc@vger.kernel.org
 Cc: linux-rpi-ker...@lists.infradead.org
 ---
 v2:
 - Fix build error on clps711x

 [...]

 diff --git a/drivers/irqchip/irq-armada-370-xp.c 
 b/drivers/irqchip/irq-armada-370-xp.c
 index 0d3b0fe..b8bf8b0 100644
 --- a/drivers/irqchip/irq-armada-370-xp.c
 +++ b/drivers/irqchip/irq-armada-370-xp.c
 @@ -201,7 +201,6 @@ static int armada_370_xp_msi_map(struct irq_domain 
 *domain, unsigned int virq,
  {
   irq_set_chip_and_handler(virq, armada_370_xp_msi_irq_chip,
handle_simple_irq);
 - set_irq_flags(virq, IRQF_VALID);

 OK


   return 0;
  }
 @@ -318,7 +317,7 @@ static int armada_370_xp_mpic_irq_map(struct irq_domain 
 *h,
   irq_set_chip_and_handler(virq, armada_370_xp_irq_chip,
   handle_level_irq);
   }
 - set_irq_flags(virq, IRQF_VALID | IRQF_PROBE);
 + irq_set_noprobe(virq);

 I think it should be irq_set_probe(virq), I don't see why you inverted the 
 probe flag.

Yes, this translation and similar ones are messed up. I've gone back
thru and fixed these.

However, it is questionable whether you really want to enable probing
on these lines or care either way.

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

[RFC PATCH 0/3] clocksource: exynos_mct: allow mct to use 64-bit counter from coprocessor

2015-07-27 Thread Alexey Klimov 
Hi all,

year(s) ago it was discovered that MCT timer and ARM architectured
timer
are the same hardware with different interface. Here [1].

I followed mail-list discussions about removing MCT and using arch
timer for Exynos5-based SoCs but things aren't moving at least latest
upstream kernel on odroid-xu3 will use MCT as default timers.
Maybe the reason are some power-management related things that very
specific to Samsung. I don't know.


Idea of this draft patchset comes from Doug patches when he tried to
optimize read of 64-bit counter located in mmio. [2]
Why not using cp15 counter instead if possible?

Previous numbers for 100 gettimeofday() calls from userspace
are about 1 ms. With this patches we have 0.5 ms or even better.
So twice as fast.

Just as matter of interest i tried to perform 200 sched_yield()
calls from userspace. I see around 20% speedup with patches applied.

I tried to use hackbench but it's hard to feel the difference, maybe
speedup is 0.5% but with bad fluctuation.

Everything is tested on odroid-xu3.
Looks like Cortex-A9 based Samsung SoCs (odroid-u2, odroid-x) don't
have arch timer.

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014
-May/256943.html
[2] https://lkml.org/lkml/2014/6/20/431



Current code created with such assumptions: 
-- don't want to insert huge refactoring in MCT code;
-- target platform only ARMv7 Exynos5-based SoC that works in 32-bit
mode so i don't want to build described functionality on ARM64.
Currently i'm trying to patch odroid-xu3 DT only.
-- firmware on odroid-xu3 is broken and secondary cores start
in SVC mode instead of HYP mode. Maybe i can remove check for hyp mode;
-- in addition instead of DT property I may parse PFR regs and find
Generic Timer Extension there.

I hope you are not getting bored reading to me. Current code is a
little bit draft so comments and ideas are welcome.

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

[RFC PATCH 1/3] clocksource: exynos_mct: allow mct to read counter from coprocessor

2015-07-27 Thread Alexey Klimov 
It was discovered that 64-bit mmio MCT counter holds
the same value as ARM arch timer 64-bit physical counter.
Even more: arch timer and MCT are same underlying hardware
timer.

Patch adds code to MCT to allow it to read 64-bit counter
from coprocessor cp15 registers since it's way more
faster than reading the same counter from MCT mmio region.

That functionality triggers only if special property
use-cp15-phys-counter is present in device tree,
only on 32-bit ARMv7 systems and only if HYP mode is
available.

Idea of rewriting accessors is taken from arm_arch_timer.c.

By default MCT will read counter from mmio since it's
guaranteed to work.

Signed-off-by: Alexey Klimov klimov.li...@gmail.com
---
 drivers/clocksource/exynos_mct.c | 77 ++--
 1 file changed, 67 insertions(+), 10 deletions(-)

diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 9064ff7..039b41c 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -26,6 +26,9 @@
 #include linux/clocksource.h
 #include linux/sched_clock.h
 
+#include asm/arch_timer.h/* for cp15 physical arch timer counter */
+#include asm/virt.h  /* for checking HYP mode */
+
 #define EXYNOS4_MCTREG(x)  (x)
 #define EXYNOS4_MCT_G_CNT_LEXYNOS4_MCTREG(0x100)
 #define EXYNOS4_MCT_G_CNT_UEXYNOS4_MCTREG(0x104)
@@ -82,6 +85,17 @@ static unsigned long clk_rate;
 static unsigned int mct_int_type;
 static int mct_irqs[MCT_NR_IRQS];
 
+static u32 notrace __exynos4_read_count_32(void);
+static u64 __exynos4_read_count_64(void);
+
+/*
+ * Default to __exynos4_read_count_{32,64} functions that reads counter from
+ * MCT mmio region and this method is guaranteed
+ * to exist (if MCT was successfully initialized).
+ */
+u32 (*exynos4_read_count_32)(void) = __exynos4_read_count_32;
+u64 (*exynos4_read_count_64)(void) = __exynos4_read_count_64;
+
 struct mct_clock_event_device {
struct clock_event_device evt;
unsigned long base;
@@ -163,16 +177,16 @@ static void exynos4_mct_frc_start(void)
 }
 
 /**
- * exynos4_read_count_64 - Read all 64-bits of the global counter
+ * __exynos4_read_count_64 - Read all 64-bits of the global counter
  *
- * This will read all 64-bits of the global counter taking care to make sure
- * that the upper and lower half match.  Note that reading the MCT can be quite
- * slow (hundreds of nanoseconds) so you should use the 32-bit (lower half
- * only) version when possible.
+ * This will read all 64-bits of the global counter from MCT mmio region
+ * taking care to make sure that the upper and lower half match.
+ * Note that reading the MCT can be quite slow (hundreds of nanoseconds)
+ * so you should use the 32-bit (lower half only) version when possible.
  *
  * Returns the number of cycles in the global counter.
  */
-static u64 exynos4_read_count_64(void)
+static u64 __exynos4_read_count_64(void)
 {
unsigned int lo, hi;
u32 hi2 = readl_relaxed(reg_base + EXYNOS4_MCT_G_CNT_U);
@@ -187,18 +201,45 @@ static u64 exynos4_read_count_64(void)
 }
 
 /**
- * exynos4_read_count_32 - Read the lower 32-bits of the global counter
+ * __exynos4_read_cp15_count_64 - Read all 64-bits of the global counter
+ * from coprocessor regisers.
  *
- * This will read just the lower 32-bits of the global counter.  This is marked
- * as notrace so it can be used by the scheduler clock.
+ * Note that reading here is faster than reading from MCT mmio region.
+ *
+ * Returns the number of cycles in the global counter.
+ */
+static u64 __exynos4_read_cp15_count_64(void)
+{
+   return arch_counter_get_cntpct();
+}
+
+/**
+ * __exynos4_read_count_32 - Read the lower 32-bits of the global counter
+ *
+ * This will read just the lower 32-bits of the global counter from
+ * MCT mmio region.
+ * This is marked as notrace so it can be used by the scheduler clock.
  *
  * Returns the number of cycles in the global counter (lower 32 bits).
  */
-static u32 notrace exynos4_read_count_32(void)
+static u32 notrace __exynos4_read_count_32(void)
 {
return readl_relaxed(reg_base + EXYNOS4_MCT_G_CNT_L);
 }
 
+/**
+ * __exynos4_read_cp15_count_32 - Read the lower 32-bits of the global counter
+ *
+ * This will read global counter from coprocessor regisers.
+ * This is marked as notrace so it can be used by the scheduler clock.
+ *
+ * Returns the number of cycles in the global counter (lower 32 bits).
+ */
+static u32 notrace __exynos4_read_cp15_count_32(void)
+{
+   return arch_counter_get_cntpct();
+}
+
 static cycle_t exynos4_frc_read(struct clocksource *cs)
 {
return exynos4_read_count_32();
@@ -599,6 +640,22 @@ static void __init mct_init_dt(struct device_node *np, 
unsigned int int_type)
for (i = MCT_L0_IRQ; i  nr_irqs; i++)
mct_irqs[i] = irq_of_parse_and_map(np, i);
 
+   /*
+* If use-cp15-phys-counter property is present in device tree
+* then use CP15

[RFC PATCH 3/3] ARM: dts: add MCT property use-cp15-phys-counter for exynos5422-odroidxu3

2015-07-27 Thread Alexey Klimov 
Speedup MCT operation on odroid-xu3 dev board by using
coprocessor 64-bit counter instead of reading same counter
located in mmio region.

Tested on Odroid-xu3.

Signed-off-by: Alexey Klimov klimov.li...@gmail.com
---
 arch/arm/boot/dts/exynos5422-odroidxu3.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts 
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index 78e6a50..b7f6c8f 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -18,6 +18,10 @@
compatible = hardkernel,odroid-xu3, samsung,exynos5800, 
samsung,exynos5;
 };
 
+mct {
+   use-cp15-phys-counter;
+};
+
 i2c_0 {
status = okay;
 
-- 
2.1.4

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

[RFC PATCH 2/3] documentation: dt: mct: add desc of optional property use-cp15-phys-counter

2015-07-27 Thread Alexey Klimov 
Signed-off-by: Alexey Klimov klimov.li...@gmail.com
---
 .../devicetree/bindings/timer/samsung,exynos4210-mct.txt   | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt 
b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
index 167d5da..c7f6354 100644
--- a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
+++ b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
@@ -36,6 +36,16 @@ Required properties:
   interrupt might be specified, meaning that all local timers use the same
   per processor interrupt.
 
+Optional properties:
+
+- use-cp15-phys-counter : set to advise mct clocksource driver to use ARM
+  arch timer 64-bit counter as main counter. Access to this coprocessor
+  counter is faster than access to same counter in mct mmio region.
+  It was discovered that mct and ARM arch timer are same underlying hardware
+  on some SoCs.
+  Only supported for Exynos5-based 32-bit systems which follow the ARMv7
+  architecture.
+
 Example 1: In this example, the IP contains two local timers, using separate
   interrupts, so two local timer interrupts have been specified,
   in addition to four global timer interrupts.
-- 
2.1.4

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

Re: [PATCH 08/11] MTD: m25p80: Add option to limit SPI transfer size.

2015-07-27 Thread Michal Suchanek 
On 27 July 2015 at 19:43, Marek Vasut ma...@denx.de wrote:
 On Monday, July 27, 2015 at 11:46:25 AM, Michal Suchanek wrote:
 On 24 July 2015 at 10:34, Marek Vasut ma...@denx.de wrote:
  On Thursday, July 23, 2015 at 07:03:47 PM, Michal Suchanek wrote:
 
 Ok, so here is some summary.

 I have a NOR flash attached to a s3c64xx SPI controller with 64byte
 fifo and a pl330 dma controller.

 Normally DMA controller is used for transfers that do not fit into the
 FIFO.

 I tried adding the flash memory ID to the spi-nor driver table and
 adding a DT node for it.

 The flash is rated at 120MHz so I used that speed but the ID was
 bit-shifted and identification failed. There is DT property
 samsung,spi-feedback-delay for addressing this and at 120MHz it must
 be 2 or 3 on this board. 40MHz works with default value 0.

 The next step after identification worked was to try reading the flash
 content. For this the DMA controller is used because data is
 transferred in blocks larger than 64 bytes. When reading the whole 4MB
 flash the transfer failed silently. I got a 4MB file of all ones or
 all zeroes.

 It turns out that

  - the pl330 locks up when transfering large amount of data.
 Specifically, the maximum power of 2 sized transfer at 120MHz is 128
 bytes and 64k at 40MHz. Transferring more than this results in the
 pl330 locking up and never signalling completion of the transfer.

 Hypothesis:
 I think this might just be that the controller didn't catch all the
 inbound clock ticks and thus counted less inbound data than it was
 set up to receive. The controller thus waits for more data.

The flash chip can transfer data as long as you keep the clock going,
especially when you transfer 64k off a 4M flash.

The read command is bound just by stopping the clock. There is always
more data to be had.


 Data
 is left in FIFO which causes subsequent commands to fail since garbage
 is returned instead of command reply. Also subsequent read may cause
 I/O error or or return an empty page depending on the garbage around.

 So the driver for the DMA controller might need to be augmented to handle
 this case -- add a timeout and in case DMA times out, drain the FIFO to
 make sure subsequent transfers do not fail.

There is no way to add timeout in the DMA driver since it does not
know the SPI clock.

The timeout is handled by the SPI driver and it should be possible to
augment it to drain the FIFO when DMA fails so long as FIFO level is
readable somewhere.


 - the I/O errors are not checked in spi-nor at all which leads to
 silent data corruption.

 On a suggestion that this may improve reliability I changed the
 s3c64xx driver to use DMA for all transfers. This caused
 identification to fail in spin-nor because the ID was prefixed with
 extra 00  byte. Testing with spidev confirmed that everything is
 prefixed with extra 00.

 The determinism of this is in fact excellent news.

 Also when the DMA controller locked up no
 transfers were possible anymore. When DMA was not used for sending
 commands the controller would recover on next command. I made the
 option to always use DMA configurable and it turns out that the
 returned data is prefixed with 00 only when no transfer without DMA
 was ever made. Loading the spi-nor driver with the dma-only option off
 and then with dma-only option on results in correct operation. Only
 loading the dma-only driver first causes the 00 prefix.

 Can we conclude that the PIO codepath somehow programs a register somewhere
 which gets rid of this 0x00 prefix ? If so, this should then also be part
 of the DMA codepath, or even better, this should be set in probe() somewhere.

Yes, it looks like it.

Thanks

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

[PATCH v3] ARM: kill off set_irq_flags usage

2015-07-27 Thread Rob Herring 
set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:

IRQF_VALID - !IRQ_NOREQUEST
IRQF_PROBE - !IRQ_NOPROBE
IRQF_NOAUTOEN - IRQ_NOAUTOEN

For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also modify IRQ_NOPROBE and this has been maintained although it
is not clear that is really needed. There appears to be a great deal of
blind copy and paste of this code.

Signed-off-by: Rob Herring r...@kernel.org
Cc: Russell King li...@arm.linux.org.uk
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
Cc: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Cc: Gregory Clement gregory.clem...@free-electrons.com
Acked-by: Hans Ulli Kroll ulli.kr...@googlemail.com
Acked-by: Shawn Guo shawn...@kernel.org
Cc: Sascha Hauer ker...@pengutronix.de
Cc: Imre Kaloz ka...@openwrt.org
Acked-by: Krzysztof Halasa khal...@piap.pl
Cc: Greg Ungerer g...@uclinux.org
Cc: Roland Stigge sti...@antcom.de
Cc: Tony Lindgren t...@atomide.com
Cc: Daniel Mack dan...@zonque.org
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Robert Jarzmik robert.jarz...@free.fr
Cc: Simtec Linux Team li...@simtec.co.uk
Cc: Kukjin Kim kg...@kernel.org
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Acked-by: Wan ZongShun mcuos@gmail.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-o...@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Tested-by: Kevin Hilman khil...@linaro.org
---
Thomas asked that this be merged thru subsystem trees instead of arm-soc,
so please apply just this patch to your tree.

Rob

 arch/arm/common/it8152.c |  2 +-
 arch/arm/common/locomo.c |  2 +-
 arch/arm/common/sa.c |  4 ++--
 arch/arm/mach-davinci/cp_intc.c  |  2 +-
 arch/arm/mach-dove/irq.c |  2 +-
 arch/arm/mach-ebsa110/core.c |  2 +-
 arch/arm/mach-footbridge/common.c|  2 +-
 arch/arm/mach-footbridge/isa-irq.c   |  8 
 arch/arm/mach-gemini/gpio.c  |  2 +-
 arch/arm/mach-gemini/irq.c   |  2 +-
 arch/arm/mach-imx/3ds_debugboard.c   |  2 +-
 arch/arm/mach-imx/mach-mx31ads.c |  2 +-
 arch/arm/mach-iop13xx/irq.c  |  2 +-
 arch/arm/mach-iop32x/irq.c   |  2 +-
 arch/arm/mach-iop33x/irq.c   |  2 +-
 arch/arm/mach-ixp4xx/common.c|  2 +-
 arch/arm/mach-ks8695/irq.c   |  2 +-
 arch/arm/mach-lpc32xx/irq.c  |  2 +-
 arch/arm/mach-netx/generic.c |  2 +-
 arch/arm/mach-omap1/fpga.c   |  2 +-
 arch/arm/mach-omap1/irq.c|  2 +-
 arch/arm/mach-pxa/balloon3.c |  2 +-
 arch/arm/mach-pxa/irq.c  |  1 -
 arch/arm/mach-pxa/lpd270.c   |  2 +-
 arch/arm/mach-pxa/pcm990-baseboard.c |  2 +-
 arch/arm/mach-pxa/pxa3xx.c   |  2 +-
 arch/arm/mach-pxa/viper.c|  2 +-
 arch/arm/mach-pxa/zeus.c |  2 +-
 arch/arm/mach-rpc/ecard.c|  2 +-
 arch/arm/mach-rpc/irq.c  | 16 
 arch/arm/mach-s3c24xx/bast-irq.c |  2 +-
 arch/arm/mach-s3c64xx/common.c   |  2 +-
 arch/arm/mach-sa1100/neponset.c  |  4 ++--
 arch/arm/mach-w90x900/irq.c  |  2 +-
 drivers/irqchip/irq-sa11x0.c |  1 -
 35 files changed, 45 insertions(+), 47 deletions(-)

diff --git a/arch/arm/common/it8152.c b/arch/arm/common/it8152.c
index 5114b68..96dabcb 100644
--- a/arch/arm/common/it8152.c
+++ b/arch/arm/common/it8152.c
@@ -91,7 +91,7 @@ void it8152_init_irq(void)
for (irq = IT8152_IRQ(0); irq = IT8152_LAST_IRQ; irq++) {
irq_set_chip_and_handler(irq, it8152_irq_chip,
 handle_level_irq);
-   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+   irq_clear_status_flags(irq, IRQ_NOREQUEST | IRQ_NOPROBE);
}
 }

diff --git a/arch/arm/common/locomo.c b/arch/arm/common/locomo.c
index b55c362..339fc41 100644
--- a/arch/arm/common/locomo.c
+++ b/arch/arm/common/locomo.c
@@ -205,7 +205,7 @@ static void locomo_setup_irq(struct locomo *lchip)
for ( ; irq = lchip-irq_base + 3; irq++) {
irq_set_chip_and_handler(irq, locomo_chip, handle_level_irq);
irq_set_chip_data(irq, lchip);
-   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+   irq_clear_status_flags(irq, IRQ_NOREQUEST | IRQ_NOPROBE);
}
 }

diff --git a/arch/arm/common/sa.c b/arch/arm/common/sa.c
index 93ee70d..680374d 100644
--- a/arch/arm/common/sa.c
+++ b/arch/arm/common/sa.c
@@ -486,7 +486,7 @@ static int sa_setup_irq(struct sa *sachip, unsigned 
irq_base)
irq_set_chip_and_handler(irq, sa_low_chip,

[PATCH v3] irqchip: kill off set_irq_flags usage

2015-07-27 Thread Rob Herring 
set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:

IRQF_VALID - !IRQ_NOREQUEST
IRQF_PROBE - !IRQ_NOPROBE
IRQF_NOAUTOEN - IRQ_NOAUTOEN

For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also modify IRQ_NOPROBE and this has been maintained although it
is not clear that is really needed. There appears to be a great deal of
blind copy and paste of this code.

Signed-off-by: Rob Herring r...@kernel.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Kukjin Kim kg...@kernel.org
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Lee Jones l...@kernel.org
Cc: Alexander Shiyan shc_w...@mail.ru
Cc: Maxime Ripard maxime.rip...@free-electrons.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-rpi-ker...@lists.infradead.org
---
Thomas asked that this be merged thru subsystem trees instead of arm-soc,
so please apply this to your tree.

Rob

 drivers/irqchip/exynos-combiner.c |  2 +-
 drivers/irqchip/irq-armada-370-xp.c   |  3 +--
 drivers/irqchip/irq-bcm2835.c |  2 +-
 drivers/irqchip/irq-clps711x.c|  6 +++---
 drivers/irqchip/irq-gic-v3.c  |  5 ++---
 drivers/irqchip/irq-gic.c |  4 ++--
 drivers/irqchip/irq-hip04.c   |  4 ++--
 drivers/irqchip/irq-keystone.c|  2 +-
 drivers/irqchip/irq-mmp.c |  3 ---
 drivers/irqchip/irq-mxs.c |  1 -
 drivers/irqchip/irq-renesas-intc-irqpin.c |  1 -
 drivers/irqchip/irq-renesas-irqc.c|  1 -
 drivers/irqchip/irq-s3c24xx.c | 14 ++
 drivers/irqchip/irq-sun4i.c   |  2 +-
 drivers/irqchip/irq-versatile-fpga.c  |  2 +-
 drivers/irqchip/irq-vic.c |  2 +-
 drivers/irqchip/irq-vt8500.c  |  1 -
 drivers/irqchip/spear-shirq.c |  1 -
 18 files changed, 18 insertions(+), 38 deletions(-)

diff --git a/drivers/irqchip/exynos-combiner.c 
b/drivers/irqchip/exynos-combiner.c
index 5c82e3b..a62cfd3 100644
--- a/drivers/irqchip/exynos-combiner.c
+++ b/drivers/irqchip/exynos-combiner.c
@@ -165,7 +165,7 @@ static int combiner_irq_domain_map(struct irq_domain *d, 
unsigned int irq,

irq_set_chip_and_handler(irq, combiner_chip, handle_level_irq);
irq_set_chip_data(irq, combiner_data[hw  3]);
-   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+   irq_set_probe(irq);

return 0;
 }
diff --git a/drivers/irqchip/irq-armada-370-xp.c 
b/drivers/irqchip/irq-armada-370-xp.c
index 0d3b0fe..017f881 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -201,7 +201,6 @@ static int armada_370_xp_msi_map(struct irq_domain *domain, 
unsigned int virq,
 {
irq_set_chip_and_handler(virq, armada_370_xp_msi_irq_chip,
 handle_simple_irq);
-   set_irq_flags(virq, IRQF_VALID);

return 0;
 }
@@ -318,7 +317,7 @@ static int armada_370_xp_mpic_irq_map(struct irq_domain *h,
irq_set_chip_and_handler(virq, armada_370_xp_irq_chip,
handle_level_irq);
}
-   set_irq_flags(virq, IRQF_VALID | IRQF_PROBE);
+   irq_set_probe(virq);

return 0;
 }
diff --git a/drivers/irqchip/irq-bcm2835.c b/drivers/irqchip/irq-bcm2835.c
index e68c3b6..9c4ba16 100644
--- a/drivers/irqchip/irq-bcm2835.c
+++ b/drivers/irqchip/irq-bcm2835.c
@@ -165,7 +165,7 @@ static int __init armctrl_of_init(struct device_node *node,
BUG_ON(irq = 0);
irq_set_chip_and_handler(irq, armctrl_chip,
handle_level_irq);
-   set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
+   irq_set_probe(irq);
}
}

diff --git a/drivers/irqchip/irq-clps711x.c b/drivers/irqchip/irq-clps711x.c
index 33127f1..2e74e81 100644
--- a/drivers/irqchip/irq-clps711x.c
+++ b/drivers/irqchip/irq-clps711x.c
@@ -133,14 +133,14 @@ static int __init clps711x_intc_irq_map(struct irq_domain 
*h, unsigned int virq,
irq_hw_number_t hw)
 {
irq_flow_handler_t handler = handle_level_irq;
-   unsigned int flags = IRQF_VALID | IRQF_PROBE;
+   unsigned int flags = 0;

if (!clps711x_irqs[hw].flags)
return 0;

if (clps711x_irqs[hw].flags  CLPS711X_FLAG_FIQ) {
handler = handle_bad_irq;
-   flags |= IRQF_NOAUTOEN;
+   flags |= IRQ_NOAUTOEN;
} else if (clps711x_irqs[hw].eoi) {
handler = handle_fasteoi_irq;

[PATCH v3] pinctrl: kill off set_irq_flags usage

2015-07-27 Thread Rob Herring 
set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:

IRQF_VALID - !IRQ_NOREQUEST
IRQF_PROBE - !IRQ_NOPROBE
IRQF_NOAUTOEN - IRQ_NOAUTOEN

For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also modify IRQ_NOPROBE and this has been maintained although it
is not clear that is really needed. There appears to be a great deal of
blind copy and paste of this code.

Signed-off-by: Rob Herring r...@kernel.org
Acked-by: Linus Walleij linus.wall...@linaro.org
Cc: Stephen Warren swar...@wwwdotorg.org
Cc: Lee Jones l...@kernel.org
Cc: Matthias Brugger matthias@gmail.com
Cc: Tomasz Figa tomasz.f...@gmail.com
Cc: Thomas Abraham thomas.abra...@linaro.org
Cc: Kukjin Kim kg...@kernel.org
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: linux-g...@vger.kernel.org
Cc: linux-rpi-ker...@lists.infradead.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
---
Thomas asked that this be merged thru subsystem trees instead of arm-soc,
so please apply this to your tree.

Rob

 drivers/pinctrl/bcm/pinctrl-bcm2835.c | 1 -
 drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 2 --
 drivers/pinctrl/pinctrl-single.c  | 5 -
 drivers/pinctrl/samsung/pinctrl-exynos.c  | 1 -
 drivers/pinctrl/samsung/pinctrl-exynos5440.c  | 1 -
 drivers/pinctrl/samsung/pinctrl-s3c24xx.c | 2 --
 drivers/pinctrl/samsung/pinctrl-s3c64xx.c | 2 --
 7 files changed, 14 deletions(-)

diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c 
b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index 6177315..29e2203 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -989,7 +989,6 @@ static int bcm2835_pinctrl_probe(struct platform_device 
*pdev)
irq_set_chip_and_handler(irq, bcm2835_gpio_irq_chip,
handle_level_irq);
irq_set_chip_data(irq, pc);
-   set_irq_flags(irq, IRQF_VALID);
}

for (i = 0; i  BCM2835_NUM_BANKS; i++) {
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c 
b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index ad1ea16..661677c 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -1348,11 +1348,9 @@ int mtk_pctrl_init(struct platform_device *pdev,
irq_set_chip_and_handler(virq, mtk_pinctrl_irq_chip,
handle_level_irq);
irq_set_chip_data(virq, pctl);
-   set_irq_flags(virq, IRQF_VALID);
};

irq_set_chained_handler_and_data(irq, mtk_eint_irq_handler, pctl);
-   set_irq_flags(irq, IRQF_VALID);
return 0;

 chip_error:
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index 0b8d480..123a9ff 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1716,12 +1716,7 @@ static int pcs_irqdomain_map(struct irq_domain *d, 
unsigned int irq,
irq_set_chip_data(irq, pcs_soc);
irq_set_chip_and_handler(irq, pcs-chip,
 handle_level_irq);
-
-#ifdef CONFIG_ARM
-   set_irq_flags(irq, IRQF_VALID);
-#else
irq_set_noprobe(irq);
-#endif

return 0;
 }
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index b18dabb..0e8add9 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -256,7 +256,6 @@ static int exynos_eint_irq_map(struct irq_domain *h, 
unsigned int virq,
irq_set_chip_data(virq, b);
irq_set_chip_and_handler(virq, b-irq_chip-chip,
handle_level_irq);
-   set_irq_flags(virq, IRQF_VALID);
return 0;
 }

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos5440.c 
b/drivers/pinctrl/samsung/pinctrl-exynos5440.c
index f5619fb..e7d1c9e 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos5440.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos5440.c
@@ -929,7 +929,6 @@ static int exynos5440_gpio_irq_map(struct irq_domain *h, 
unsigned int virq,
irq_set_chip_data(virq, d);
irq_set_chip_and_handler(virq, exynos5440_gpio_irq_chip,
handle_level_irq);
-   set_irq_flags(virq, IRQF_VALID);
return 0;
 }

diff --git a/drivers/pinctrl/samsung/pinctrl-s3c24xx.c 
b/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
index 01b43db..f218be7 100644
--- a/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
+++ b/drivers/pinctrl/samsung/pinctrl-s3c24xx.c
@@ -437,7 +437,6 @@ static int s3c24xx_gpf_irq_map(struct irq_domain *h, 
unsigned int virq,

Re: [PATCH v2] ARM: dts: Add SPI CS on exynos5250-snow

2015-07-27 Thread Javier Martinez Canillas 
Hello Michal,

The patch looks good to me, just one small comment below.

On Mon, Jul 27, 2015 at 10:11 PM, Michal Suchanek hramr...@gmail.com wrote:
 Although there is only one choice of chipselect it is necessary to
 specify it. The driver cannot claim the gpio otherwise.

 Signed-off-by: Michal Suchanek hramr...@gmail.com

 --
 v2
  - don't move unrelated line
 ---
  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 b7f4122..62be08a 100644
 --- a/arch/arm/boot/dts/exynos5250-snow.dts
 +++ b/arch/arm/boot/dts/exynos5250-snow.dts
 @@ -688,6 +688,7 @@
 status = okay;
 samsung,spi-src-clk = 0;
 num-cs = 1;
 +   cs-gpios = gpa2 5 0;

NIT: this should be GPIO_ACTIVE_HIGH instead of 0 but maybe Kukjin or
Krzysztof can fixup when applying it?

  };

  usbdrd_dwc3 {
 --

Acked-by: Javier Martinez Canillas jav...@osg.samsung.com

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

Re: [PATCH v2] ARM: dts: Add SPI CS on exynos5250-snow

2015-07-27 Thread Krzysztof Kozlowski 
On 28.07.2015 06:24, Javier Martinez Canillas wrote:
 Hello Michal,
 
 The patch looks good to me, just one small comment below.
 
 On Mon, Jul 27, 2015 at 10:11 PM, Michal Suchanek hramr...@gmail.com wrote:
 Although there is only one choice of chipselect it is necessary to
 specify it. The driver cannot claim the gpio otherwise.

 Signed-off-by: Michal Suchanek hramr...@gmail.com

 --
 v2
  - don't move unrelated line
 ---
  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 b7f4122..62be08a 100644
 --- a/arch/arm/boot/dts/exynos5250-snow.dts
 +++ b/arch/arm/boot/dts/exynos5250-snow.dts
 @@ -688,6 +688,7 @@
 status = okay;
 samsung,spi-src-clk = 0;
 num-cs = 1;
 +   cs-gpios = gpa2 5 0;
 
 NIT: this should be GPIO_ACTIVE_HIGH instead of 0 but maybe Kukjin or
 Krzysztof can fixup when applying it?
 
  };

  usbdrd_dwc3 {
 --
 
 Acked-by: Javier Martinez Canillas jav...@osg.samsung.com

Yes, the GPIO_ACTIVE_HIGH would be better. Can you re-spin the patch
with this change and respective Acks? Including mine ack:
Acked-by: Krzysztof Kozlowski k.kozlow...@samsung.com

Best regards,
Krzysztof


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

Re: [PATCH 01/12] ARM: SAMSUNG: local regs-srom header in mach-exynos

2015-07-27 Thread Krzysztof Kozlowski 
On 27.07.2015 23:57, Kukjin Kim wrote:
 
 This patch moves regs-srom header file into mach-exynos.

Hi,

Minor nits:
1. Could you trim it and remove unnecessary empty line before description?
2. Could you answer in commit message: Why? Why are you moving the headers?


 
 c: Krzysztof Kozlowski k.kozlow...@samsung.com

Malformed Cc: tag.

Best regards,
Krzysztof

 Signed-off-by: Kukjin Kim kg...@kernel.org
 ---
  arch/arm/{plat-samsung/include/plat = mach-exynos}/regs-srom.h | 3 +--
  arch/arm/mach-exynos/suspend.c  | 4 ++--
  2 files changed, 3 insertions(+), 4 deletions(-)
  rename arch/arm/{plat-samsung/include/plat = mach-exynos}/regs-srom.h (96%)
 
 diff --git a/arch/arm/plat-samsung/include/plat/regs-srom.h 
 b/arch/arm/mach-exynos/regs-srom.h
 similarity index 96%
 rename from arch/arm/plat-samsung/include/plat/regs-srom.h
 rename to arch/arm/mach-exynos/regs-srom.h
 index 9b6729c..5c4d442 100644
 --- a/arch/arm/plat-samsung/include/plat/regs-srom.h
 +++ b/arch/arm/mach-exynos/regs-srom.h
 @@ -1,5 +1,4 @@
 -/* linux/arch/arm/plat-samsung/include/plat/regs-srom.h
 - *
 +/*
   * Copyright (c) 2010 Samsung Electronics Co., Ltd.
   *   http://www.samsung.com
   *
 diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
 index c506f8e..e00eb39 100644
 --- a/arch/arm/mach-exynos/suspend.c
 +++ b/arch/arm/mach-exynos/suspend.c
 @@ -32,11 +32,11 @@
  #include asm/suspend.h
  
  #include plat/pm-common.h
 -#include plat/regs-srom.h
  
  #include common.h
 -#include regs-pmu.h
  #include exynos-pmu.h
 +#include regs-pmu.h
 +#include regs-srom.h
  
  #define REG_TABLE_END (-1U)
  
 

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

Re: [PATCH v2 2/7] cpufreq: opp: fix handling of turbo modes

2015-07-27 Thread Bartlomiej Zolnierkiewicz 

Hi,

On Monday, July 27, 2015 02:05:31 PM Viresh Kumar wrote:
 $subject is a bit wrong, we aren't fixing any issue here. We are
 supporting a new feature and so it should be like:

Have you read my explanation of the issue?

With your OPP-v2 patches cpufreq-dt picks turbo frequencies and uses
them as normal ones.

(More at: http://www.spinics.net/lists/arm-kernel/msg430397.html)

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

 cpufreq: Mark boost frequencies based on OPP's turbo mode
 
 On 09-07-15, 17:43, Bartlomiej Zolnierkiewicz wrote:
  Turbo modes should be marked with CPUFREQ_BOOST_FREQ flag in
  the frequency table entry.
  
  Cc: Tomasz Figa tomasz.f...@gmail.com
  Cc: Michael Turquette mturque...@baylibre.com
  Cc: Javier Martinez Canillas jav...@dowhile0.org
  Cc: Thomas Abraham thomas...@samsung.com
  Cc: Viresh Kumar viresh.ku...@linaro.org
  Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
  ---
   drivers/cpufreq/cpufreq_opp.c | 2 ++
   1 file changed, 2 insertions(+)
  
  diff --git a/drivers/cpufreq/cpufreq_opp.c b/drivers/cpufreq/cpufreq_opp.c
  index 773bcde..f0cf502 100644
  --- a/drivers/cpufreq/cpufreq_opp.c
  +++ b/drivers/cpufreq/cpufreq_opp.c
  @@ -75,6 +75,8 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
  }
  freq_table[i].driver_data = i;
  freq_table[i].frequency = rate / 1000;
  +   if (dev_pm_opp_get_turbo_mode_setting(opp) == true)
  +   freq_table[i].flags |= CPUFREQ_BOOST_FREQ;
  }
   
  freq_table[i].driver_data = i;
 
 Rest look fine.

--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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/4] mfd: max77686: Don't suggest in binding to use a deprecated property

2015-07-27 Thread Javier Martinez Canillas 
Hello Mark,

On 07/20/2015 12:12 PM, Javier Martinez Canillas wrote:
 Hello Lee,
 
 Thanks a lot for your feedback.
 
 On 07/20/2015 10:10 AM, Lee Jones wrote:
 On Fri, 17 Jul 2015, Javier Martinez Canillas wrote:

 The regulator-compatible property from the regulator DT binding was
 deprecated. But the max77686 DT binding doc still suggest to use it
 instead of the regulator node name's which is the correct approach.

 Signed-off-by: Javier Martinez Canillas jav...@osg.samsung.com
 Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com

 By convention shouldn't this be buck@1, or something?

 Need Mark to look at this.

 
 That's a very good question, the ePAPR doc says:
 
 The unit-address must match the first address specified in the reg property
 of the node. If the node has no reg property, the @ and unit-address must be
 omitted and the node-name alone differentiates the node from other nodes at
 the same level in the tree
 
 This PMIC uses a single I2C address for all the regulators and these are
 controlled by writing to different I2C register addresses. So the regulator
 nodes don't have a reg property in this case.
 
 By looking at other regulators bindings, besides the generic regulator.txt
 and fixed-regulator.txt DT bindings, there are only 5 (out of 40) that use
 the node-name@unit-address convention mentioned in the ePAPR document.
 
 AFAICT all these are for regulators that are actually in different addresses
 but I could be wrong so let's see what Mark says.
 

Any opinions on this?

thanks a lot and best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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/4] mfd: max77686: Don't suggest in binding to use a deprecated property

2015-07-27 Thread Mark Brown 
On Mon, Jul 27, 2015 at 12:28:07PM +0200, Javier Martinez Canillas wrote:
 On 07/20/2015 12:12 PM, Javier Martinez Canillas wrote:

  This PMIC uses a single I2C address for all the regulators and these are
  controlled by writing to different I2C register addresses. So the regulator
  nodes don't have a reg property in this case.

  By looking at other regulators bindings, besides the generic regulator.txt
  and fixed-regulator.txt DT bindings, there are only 5 (out of 40) that use
  the node-name@unit-address convention mentioned in the ePAPR document.

  AFAICT all these are for regulators that are actually in different addresses
  but I could be wrong so let's see what Mark says.

 Any opinions on this?

I just don't care, this is just syntactic noise which has no practical
meaning as far as I can tell.


signature.asc
Description: Digital signature

Re: [PATCH v2 1/4] mfd: max77686: Don't suggest in binding to use a deprecated property

2015-07-27 Thread Javier Martinez Canillas 
Hello Mark,

On 07/27/2015 12:33 PM, Mark Brown wrote:
 On Mon, Jul 27, 2015 at 12:28:07PM +0200, Javier Martinez Canillas wrote:
 On 07/20/2015 12:12 PM, Javier Martinez Canillas wrote:
 
 This PMIC uses a single I2C address for all the regulators and these are
 controlled by writing to different I2C register addresses. So the regulator
 nodes don't have a reg property in this case.
 
 By looking at other regulators bindings, besides the generic regulator.txt
 and fixed-regulator.txt DT bindings, there are only 5 (out of 40) that use
 the node-name@unit-address convention mentioned in the ePAPR document.
 
 AFAICT all these are for regulators that are actually in different addresses
 but I could be wrong so let's see what Mark says.
 
 Any opinions on this?
 
 I just don't care, this is just syntactic noise which has no practical
 meaning as far as I can tell.


thanks, I'll then leave the regulator's node name as is in the patch
since that is consistent with the rest of the regulator DT bindings.

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

Re: [PATCH v2 2/7] cpufreq: opp: fix handling of turbo modes

2015-07-27 Thread Viresh Kumar 
$subject is a bit wrong, we aren't fixing any issue here. We are
supporting a new feature and so it should be like:

cpufreq: Mark boost frequencies based on OPP's turbo mode

On 09-07-15, 17:43, Bartlomiej Zolnierkiewicz wrote:
 Turbo modes should be marked with CPUFREQ_BOOST_FREQ flag in
 the frequency table entry.
 
 Cc: Tomasz Figa tomasz.f...@gmail.com
 Cc: Michael Turquette mturque...@baylibre.com
 Cc: Javier Martinez Canillas jav...@dowhile0.org
 Cc: Thomas Abraham thomas...@samsung.com
 Cc: Viresh Kumar viresh.ku...@linaro.org
 Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
 ---
  drivers/cpufreq/cpufreq_opp.c | 2 ++
  1 file changed, 2 insertions(+)
 
 diff --git a/drivers/cpufreq/cpufreq_opp.c b/drivers/cpufreq/cpufreq_opp.c
 index 773bcde..f0cf502 100644
 --- a/drivers/cpufreq/cpufreq_opp.c
 +++ b/drivers/cpufreq/cpufreq_opp.c
 @@ -75,6 +75,8 @@ int dev_pm_opp_init_cpufreq_table(struct device *dev,
   }
   freq_table[i].driver_data = i;
   freq_table[i].frequency = rate / 1000;
 + if (dev_pm_opp_get_turbo_mode_setting(opp) == true)
 + freq_table[i].flags |= CPUFREQ_BOOST_FREQ;
   }
  
   freq_table[i].driver_data = i;

Rest look fine.

-- 
viresh
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] opp: add dev_pm_opp_get_turbo_mode_setting() helper

2015-07-27 Thread Viresh Kumar 
On 09-07-15, 17:43, Bartlomiej Zolnierkiewicz wrote:
 +bool dev_pm_opp_get_turbo_mode_setting(struct dev_pm_opp *opp)

This should be named dev_pm_opp_is_turbo().

-- 
viresh
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] cpufreq-dt: add turbo modes support

2015-07-27 Thread Viresh Kumar 
On 09-07-15, 17:43, Bartlomiej Zolnierkiewicz wrote:
 diff --git a/include/linux/cpufreq-dt.h b/include/linux/cpufreq-dt.h
 index 0414009..483ca1b 100644
 --- a/include/linux/cpufreq-dt.h
 +++ b/include/linux/cpufreq-dt.h
 @@ -17,6 +17,7 @@ struct cpufreq_dt_platform_data {
* clock.
*/
   bool independent_clocks;
 + bool boost_supported;
  };

I am planning to kill this structure soon, don't add anything to it.
We should be doing this based on DT.

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

Re: [PATCH 08/11] MTD: m25p80: Add option to limit SPI transfer size.

2015-07-27 Thread Michal Suchanek 
On 24 July 2015 at 10:34, Marek Vasut ma...@denx.de wrote:
 On Thursday, July 23, 2015 at 07:03:47 PM, Michal Suchanek wrote:

 Hi!

 [...]

  It's probably slower to set up DMA for 2-byte commands but it might
  work nonetheless.
 
  It is, the overhead will be considerable. It might help the stability
  though. I'm really looking forward to the results!
 
  Hello,
 
  this does not quite work.
 
  My test with spidev:
 
  # ./spinor /dev/spidev1.0
  Sending 9f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  Received 00 ff c8 60 16 c8 60 16 c8 60 16 c8 60 16 c8 60
  Sending 90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  Received 00 ff ff ff ff c8 15 c8 15 c8 15 c8 15 c8 15 c8
  Sending 9f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  Received 00 ff c8 60 16 c8 60 16 c8 60 16 c8 60 16 c8 60
 
  I receive correct ID but spi-nor complains it does not know ID 00 c8 60.
  IIRC garbage should be sent only at the time command is transferred so
  only one byte of garbage should be received. Also the garbage tends to
  be the last state of the data output - all 0 or all 1.
  So it seems using DMA for all transfers including 1-byte commands
  results in (some?) received data getting an extra 00 prefix.
 
 
  I also managed to lock up the controller completely since there is
  some error passing the SPI speed somewhere :(
 
  [ 1352.977530] spidev spi1.0: setup mode 0, 8 bits/w, 8000 Hz max --
  0 [ 1352.977540] spidev spi1.0: spi mode 0
  [ 1352.977576] spidev spi1.0: setup mode 0, 8 bits/w, 8000 Hz max --
  0 [ 1352.977582] spidev spi1.0: msb first
  [ 1352.977614] spidev spi1.0: setup mode 0, 8 bits/w, 8000 Hz max --
  0 [ 1352.977620] spidev spi1.0: 0 bits per word
  [ 1352.977652] spidev spi1.0: setup mode 0, 8 bits/w, 2690588672 Hz max
  -- 0 [ 1352.977726] spi_master spi1: s3c64xx_spi_config: clk_from_cmu 1
  src_clk sclk_spi1 mode bpw 8
  [ 1352.977753] spi_master spi1: spi1.0 s3c64xx_spi_transfer_one: xfer
  bpw 8 speed -1604378624
  [ 1352.977760] spi_master spi1: s3c64xx_spi_config: clk_from_cmu 1
  src_clk sclk_spi1 mode bpw 8
  [ 1352.977781] spi_master spi1: spi1.0 s3c64xx_spi_transfer_one: using
  dma [ 1352.977797] dma-pl330 121b.pdma: setting up request on thread
  1

 Hmm, on a second thought it probably works as expected more or less.

 The nonsensical value was passed from application and there is no
 guard against that.

 Since I don't do PIO the controller remains locked up indefinitely.

 I have to admit, I don't quite understand the above. I also don't quite know
 what your spidev test does. Can you possibly just bind a regular SPI NOR 
 driver
 and run mtdtests to see if it is stable ?

Ok, so here is some summary.

I have a NOR flash attached to a s3c64xx SPI controller with 64byte
fifo and a pl330 dma controller.

Normally DMA controller is used for transfers that do not fit into the FIFO.

I tried adding the flash memory ID to the spi-nor driver table and
adding a DT node for it.

The flash is rated at 120MHz so I used that speed but the ID was
bit-shifted and identification failed. There is DT property
samsung,spi-feedback-delay for addressing this and at 120MHz it must
be 2 or 3 on this board. 40MHz works with default value 0.

The next step after identification worked was to try reading the flash
content. For this the DMA controller is used because data is
transferred in blocks larger than 64 bytes. When reading the whole 4MB
flash the transfer failed silently. I got a 4MB file of all ones or
all zeroes.

It turns out that

 - the pl330 locks up when transfering large amount of data.
Specifically, the maximum power of 2 sized transfer at 120MHz is 128
bytes and 64k at 40MHz. Transferring more than this results in the
pl330 locking up and never signalling completion of the transfer. Data
is left in FIFO which causes subsequent commands to fail since garbage
is returned instead of command reply. Also subsequent read may cause
I/O error or or return an empty page depending on the garbage around.

- the I/O errors are not checked in spi-nor at all which leads to
silent data corruption.

On a suggestion that this may improve reliability I changed the
s3c64xx driver to use DMA for all transfers. This caused
identification to fail in spin-nor because the ID was prefixed with
extra 00  byte. Testing with spidev confirmed that everything is
prefixed with extra 00. Also when the DMA controller locked up no
transfers were possible anymore. When DMA was not used for sending
commands the controller would recover on next command. I made the
option to always use DMA configurable and it turns out that the
returned data is prefixed with 00 only when no transfer without DMA
was ever made. Loading the spi-nor driver with the dma-only option off
and then with dma-only option on results in correct operation. Only
loading the dma-only driver first causes the 00 prefix.

Thanks

Michal
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message