Re: [PATCH 0/8] memory: emif: miscellaneous bug fixes for EMIF driver

2013-03-16 Thread Lokesh Vutla 

On Friday 15 March 2013 11:38 PM, Greg KH wrote:

On Mon, Mar 11, 2013 at 10:35:57AM +0530, Lokesh Vutla wrote:

This series resolves a few minor issues for EMIF driver.

Tested all patches on OMAP4430-sdp.
Patch : memory: emif: setup LP settings on freq update
is tested on a local tree, since freq update cannot be
tested on mainline.


Can you please resend these with all of the requested changes made, and
acks added?

Ok ill send V2 with necessary changes and acks added..
Thanks,
Lokesh


thanks,

greg k-h



--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/8] memory: emif: miscellaneous bug fixes for EMIF driver

2013-03-16 Thread Lokesh Vutla 
This series resolves a few minor issues for EMIF driver.

Tested all patches on OMAP4430-sdp.
Patch : memory: emif: setup LP settings on freq update
is tested on a local tree, since freq update cannot be
tested on mainline.

Ambresh K (1):
  memory: emif: setup LP settings on freq update

Grygorii Strashko (1):
  memory: emif: errata i743: Prohibit usage of Power-Down mode

Lokesh Vutla (2):
  memory: emif: Fix the lpmode timeout calculation
  memory: emif: Load the correct custom config values from dt

Nishanth Menon (3):
  memory: emif: handle overflow for timing for LP mode
  memory: emif: Handle devices which are not rated for 85C
  memory: emif: use restart if power_off not present when out of spec

Oleksandr Dmytryshyn (1):
  memory: emif: Fix the incorrect 'size' parameter in memcpy

 drivers/memory/emif.c   |  129 +++
 include/linux/platform_data/emif_plat.h |1 +
 2 files changed, 114 insertions(+), 16 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/8] memory: emif: Fix the incorrect 'size' parameter in memcpy

2013-03-16 Thread Lokesh Vutla 
From: Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com

The issue was that only the first timings table was added to the
emif platform data at the emif driver registration. All other
timings tables was filled with zeros. Now all emif timings table
are added to the platform data.

Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
Changes since V1: Updated $subject

 drivers/memory/emif.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 8db74e4..d27111e 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -1468,7 +1468,7 @@ static struct emif_data *__init_or_module 
get_device_details(
if (pd-timings) {
temp = devm_kzalloc(dev, size, GFP_KERNEL);
if (temp) {
-   memcpy(temp, pd-timings, sizeof(*pd-timings));
+   memcpy(temp, pd-timings, size);
pd-timings = temp;
} else {
dev_warn(dev, %s:%d: allocation error\n, __func__,
-- 
1.7.9.5

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

[PATCH V2 7/8] memory: emif: errata i743: Prohibit usage of Power-Down mode

2013-03-16 Thread Lokesh Vutla 
From: Grygorii Strashko grygorii.stras...@ti.com

ERRATA DESCRIPTION :
The EMIF supports power-down state for low power. The EMIF
automatically puts the SDRAM into power-down after the memory is
not accessed for a defined number of cycles and the
EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE bit field is set to 0x4.
As the EMIF supports automatic output impedance calibration, a ZQ
calibration long command is issued every time it exits active
power-down and precharge power-down modes. The EMIF waits and
blocks any other command during this calibration.
The EMIF does not allow selective disabling of ZQ calibration upon
exit of power-down mode. Due to very short periods of power-down
cycles, ZQ calibration overhead creates bandwidth issues and
increases overall system power consumption. On the other hand,
issuing ZQ calibration long commands when exiting self-refresh is
still required.

WORKAROUND :
Because there is no power consumption benefit of the power-down due
to the calibration and there is a performance risk, the guideline
is to not allow power-down state and, therefore, to not have set
the EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE bit field to 0x4.

This is applicable only for EMIF4D IP used in OMAP4 Soc's.

Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
Signed-off-by: Vitaly Chernooky vitaly.cherno...@ti.com
Signed-off-by: Oleksandr Dmytryshyn oleksandr.dmytrys...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
Changes since V1: 
Updated the change log and fixed a typo in a comment.

 drivers/memory/emif.c |   35 +++
 1 file changed, 35 insertions(+)

diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index d27111e..9b27c2b 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -257,6 +257,41 @@ static void set_lpmode(struct emif_data *emif, u8 lpmode)
u32 temp;
void __iomem *base = emif-base;
 
+   /*
+* Workaround for errata i743 - LPDDR2 Power-Down State is Not
+* Efficient
+*
+* i743 DESCRIPTION:
+* The EMIF supports power-down state for low power. The EMIF
+* automatically puts the SDRAM into power-down after the memory is
+* not accessed for a defined number of cycles and the
+* EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE bit field is set to 0x4.
+* As the EMIF supports automatic output impedance calibration, a ZQ
+* calibration long command is issued every time it exits active
+* power-down and precharge power-down modes. The EMIF waits and
+* blocks any other command during this calibration.
+* The EMIF does not allow selective disabling of ZQ calibration upon
+* exit of power-down mode. Due to very short periods of power-down
+* cycles, ZQ calibration overhead creates bandwidth issues and
+* increases overall system power consumption. On the other hand,
+* issuing ZQ calibration long commands when exiting self-refresh is
+* still required.
+*
+* WORKAROUND
+* Because there is no power consumption benefit of the power-down due
+* to the calibration and there is a performance risk, the guideline
+* is to not allow power-down state and, therefore, to not have set
+* the EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE bit field to 0x4.
+*/
+   if ((emif-plat_data-ip_rev == EMIF_4D) 
+   (EMIF_LP_MODE_PWR_DN == lpmode)) {
+   WARN_ONCE(1,
+ REG_LP_MODE = LP_MODE_PWR_DN(4) is prohibited by
+ erratum i743 switch to LP_MODE_SELF_REFRESH(2)\n);
+   /* rollback LP_MODE to Self-refresh mode */
+   lpmode = EMIF_LP_MODE_SELF_REFRESH;
+   }
+
temp = readl(base + EMIF_POWER_MANAGEMENT_CONTROL);
temp = ~LP_MODE_MASK;
temp |= (lpmode  LP_MODE_SHIFT);
-- 
1.7.9.5

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

[PATCH V2 8/8] memory: emif: Load the correct custom config values from dt

2013-03-16 Thread Lokesh Vutla 
of_get_property returns value in Big Endian format.
Before using this value it should be converted to little endian
using be32_to_cpup().
Custom configs of emif are read from dt using of_get_property,
but these are not converted to litte endian format.
Correcting the same here.

Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
Changes since V1: No changes

 drivers/memory/emif.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 9b27c2b..475174a 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -1263,7 +1263,7 @@ static void __init_or_module of_get_custom_configs(struct 
device_node *np_emif,
 {
struct emif_custom_configs  *cust_cfgs = NULL;
int len;
-   const int   *lpmode, *poll_intvl;
+   const __be32*lpmode, *poll_intvl;
 
lpmode = of_get_property(np_emif, low-power-mode, len);
poll_intvl = of_get_property(np_emif, temp-alert-poll-interval, len);
@@ -1277,7 +1277,7 @@ static void __init_or_module of_get_custom_configs(struct 
device_node *np_emif,
 
if (lpmode) {
cust_cfgs-mask |= EMIF_CUSTOM_CONFIG_LPMODE;
-   cust_cfgs-lpmode = *lpmode;
+   cust_cfgs-lpmode = be32_to_cpup(lpmode);
of_property_read_u32(np_emif,
low-power-mode-timeout-performance,
cust_cfgs-lpmode_timeout_performance);
@@ -1292,7 +1292,8 @@ static void __init_or_module of_get_custom_configs(struct 
device_node *np_emif,
if (poll_intvl) {
cust_cfgs-mask |=
EMIF_CUSTOM_CONFIG_TEMP_ALERT_POLL_INTERVAL;
-   cust_cfgs-temp_alert_poll_interval_ms = *poll_intvl;
+   cust_cfgs-temp_alert_poll_interval_ms =
+   be32_to_cpup(poll_intvl);
}
 
if (of_find_property(np_emif, extended-temp-part, len))
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/8] memory: emif: handle overflow for timing for LP mode

2013-03-16 Thread Lokesh Vutla 
From: Nishanth Menon n...@ti.com

In case the custom timings provide values which overflow
the maximum possible field value, warn and use maximum
permissible value.

Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
Changes since V1: No changes

 drivers/memory/emif.c |   36 
 1 file changed, 28 insertions(+), 8 deletions(-)

diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 5f3b7ed..e513889 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -715,6 +715,8 @@ static u32 get_pwr_mgmt_ctrl(u32 freq, struct emif_data 
*emif, u32 ip_rev)
u32 timeout_perf= EMIF_LP_MODE_TIMEOUT_PERFORMANCE;
u32 timeout_pwr = EMIF_LP_MODE_TIMEOUT_POWER;
u32 freq_threshold  = EMIF_LP_MODE_FREQ_THRESHOLD;
+   u32 mask;
+   u8 shift;
 
struct emif_custom_configs *cust_cfgs = emif-plat_data-custom_configs;
 
@@ -743,27 +745,45 @@ static u32 get_pwr_mgmt_ctrl(u32 freq, struct emif_data 
*emif, u32 ip_rev)
 
switch (lpmode) {
case EMIF_LP_MODE_CLOCK_STOP:
-   pwr_mgmt_ctrl = (timeout  CS_TIM_SHIFT) |
-   SR_TIM_MASK | PD_TIM_MASK;
+   shift = CS_TIM_SHIFT;
+   mask = CS_TIM_MASK;
break;
case EMIF_LP_MODE_SELF_REFRESH:
/* Workaround for errata i735 */
if (timeout  6)
timeout = 6;
 
-   pwr_mgmt_ctrl = (timeout  SR_TIM_SHIFT) |
-   CS_TIM_MASK | PD_TIM_MASK;
+   shift = SR_TIM_SHIFT;
+   mask = SR_TIM_MASK;
break;
case EMIF_LP_MODE_PWR_DN:
-   pwr_mgmt_ctrl = (timeout  PD_TIM_SHIFT) |
-   CS_TIM_MASK | SR_TIM_MASK;
+   shift = PD_TIM_SHIFT;
+   mask = PD_TIM_MASK;
break;
case EMIF_LP_MODE_DISABLE:
default:
-   pwr_mgmt_ctrl = CS_TIM_MASK |
-   PD_TIM_MASK | SR_TIM_MASK;
+   mask = 0;
+   shift = 0;
+   break;
+   }
+   /* Round to maximum in case of overflow, BUT warn! */
+   if (lpmode != EMIF_LP_MODE_DISABLE  timeout  mask  shift) {
+   pr_err(TIMEOUT Overflow - lpmode=%d perf=%d pwr=%d freq=%d\n,
+  lpmode,
+  timeout_perf,
+  timeout_pwr,
+  freq_threshold);
+   WARN(1, timeout=0x%02x greater than 0x%02x. Using max\n,
+timeout, mask  shift);
+   timeout = mask  shift;
}
 
+   /* Setup required timing */
+   pwr_mgmt_ctrl = (timeout  shift)  mask;
+   /* setup a default mask for rest of the modes */
+   pwr_mgmt_ctrl |= (SR_TIM_MASK | CS_TIM_MASK | PD_TIM_MASK) 
+ ~mask;
+
/* No CS_TIM in EMIF_4D5 */
if (ip_rev == EMIF_4D5)
pwr_mgmt_ctrl = ~CS_TIM_MASK;
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/8] memory: emif: use restart if power_off not present when out of spec

2013-03-16 Thread Lokesh Vutla 
From: Nishanth Menon n...@ti.com

Some machine or kernel variants might have missed implementation
of power off handlers. We DONOT want to let the system be in
out of spec state in this condition. So, WARN and attempt
a machine restart in the hopes of clearing the out-of-spec
temperature condition.

NOTE: This is not the safest option, but safer than leaving the
system in unstable conditions.

Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
Changes since V1:
Added a new extra line before if condition.

 drivers/memory/emif.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 827eb3b..8db74e4 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -25,6 +25,7 @@
 #include linux/module.h
 #include linux/list.h
 #include linux/spinlock.h
+#include linux/pm.h
 #include memory/jedec_ddr.h
 #include emif.h
 #include of_memory.h
@@ -1015,7 +1016,14 @@ static irqreturn_t emif_threaded_isr(int irq, void 
*dev_id)
 
if (emif-temperature_level == SDRAM_TEMP_VERY_HIGH_SHUTDOWN) {
dev_emerg(emif-dev, SDRAM temperature exceeds operating 
limit.. Needs shut down!!!\n);
-   kernel_power_off();
+
+   /* If we have Power OFF ability, use it, else try restarting */
+   if (pm_power_off) {
+   kernel_power_off();
+   } else {
+   WARN(1, FIXME: NO pm_power_off!!! trying restart\n);
+   kernel_restart(SDRAM Over-temp Emergency restart);
+   }
return IRQ_HANDLED;
}
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/8] memory: emif: Handle devices which are not rated for 85C

2013-03-16 Thread Lokesh Vutla 
From: Nishanth Menon n...@ti.com

As per JESD209-2E specification for LPDDR2,
  http://www.jedec.org/standards-documents/results/jesd209-2E
Table 73, LPDDR2 memories come in two flavors - Standard and
Extended. The Standard types can operate from -25C to +85C
However, beyond that and upto +105C can only be supported by
Extended types.

Unfortunately, it seems there is no info in MR0(device info) or
MR[1,2](device feature) for run time detection of this capability
as far as seen on the spec. Hence, we provide a custom_config
flag to be populated by platforms which have these extended
type memories.

For the Standard memories, we need to consider MR4 notifications
of temperature triggers 85C as equivalent to thermal shutdown
events (equivalent to Spec specified thermal shutdown events for
extended parts).

Reported-by: Richard Woodruff r-woodru...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
Changes since V1: No changes

 drivers/memory/emif.c   |   27 +++
 include/linux/platform_data/emif_plat.h |1 +
 2 files changed, 28 insertions(+)

diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index e513889..827eb3b 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -918,6 +918,7 @@ static irqreturn_t handle_temp_alert(void __iomem *base, 
struct emif_data *emif)
 {
u32 old_temp_level;
irqreturn_t ret = IRQ_HANDLED;
+   struct emif_custom_configs *custom_configs;
 
spin_lock_irqsave(emif_lock, irq_state);
old_temp_level = emif-temperature_level;
@@ -930,6 +931,29 @@ static irqreturn_t handle_temp_alert(void __iomem *base, 
struct emif_data *emif)
goto out;
}
 
+   custom_configs = emif-plat_data-custom_configs;
+
+   /*
+* IF we detect higher than nominal rating from DDR sensor
+* on an unsupported DDR part, shutdown system
+*/
+   if (custom_configs  !(custom_configs-mask 
+   EMIF_CUSTOM_CONFIG_EXTENDED_TEMP_PART)) {
+   if (emif-temperature_level = SDRAM_TEMP_HIGH_DERATE_REFRESH) {
+   dev_err(emif-dev,
+   %s:NOT Extended temperature capable memory.
+   Converting MR4=0x%02x as shutdown event\n,
+   __func__, emif-temperature_level);
+   /*
+* Temperature far too high - do kernel_power_off()
+* from thread context
+*/
+   emif-temperature_level = SDRAM_TEMP_VERY_HIGH_SHUTDOWN;
+   ret = IRQ_WAKE_THREAD;
+   goto out;
+   }
+   }
+
if (emif-temperature_level  old_temp_level ||
emif-temperature_level == SDRAM_TEMP_VERY_HIGH_SHUTDOWN) {
/*
@@ -1228,6 +1252,9 @@ static void __init_or_module of_get_custom_configs(struct 
device_node *np_emif,
cust_cfgs-temp_alert_poll_interval_ms = *poll_intvl;
}
 
+   if (of_find_property(np_emif, extended-temp-part, len))
+   cust_cfgs-mask |= EMIF_CUSTOM_CONFIG_EXTENDED_TEMP_PART;
+
if (!is_custom_config_valid(cust_cfgs, emif-dev)) {
devm_kfree(emif-dev, cust_cfgs);
return;
diff --git a/include/linux/platform_data/emif_plat.h 
b/include/linux/platform_data/emif_plat.h
index 03378ca..5c19a2a 100644
--- a/include/linux/platform_data/emif_plat.h
+++ b/include/linux/platform_data/emif_plat.h
@@ -40,6 +40,7 @@
 /* Custom config requests */
 #define EMIF_CUSTOM_CONFIG_LPMODE  0x0001
 #define EMIF_CUSTOM_CONFIG_TEMP_ALERT_POLL_INTERVAL0x0002
+#define EMIF_CUSTOM_CONFIG_EXTENDED_TEMP_PART  0x0004
 
 #ifndef __ASSEMBLY__
 /**
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/8] memory: emif: Fix the lpmode timeout calculation

2013-03-16 Thread Lokesh Vutla 
The driver tries to round up the specified timeout cycles to
the next power of 2 value. This should be done defore updating
timeout variable.
Correcting this here.

Reported-by: Nishanth Menon n...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
Changes since V1: 
Updated Changelog and $subject
Added a comment describing timeout calculation.

 drivers/memory/emif.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index df08736..508763c 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -728,13 +728,17 @@ static u32 get_pwr_mgmt_ctrl(u32 freq, struct emif_data 
*emif, u32 ip_rev)
/* Timeout based on DDR frequency */
timeout = freq = freq_threshold ? timeout_perf : timeout_pwr;
 
-   /* The value to be set in register is log2(timeout) - 3 */
+   /*
+* The value to be set in register is log2(timeout) - 3
+* if timeout  16 load 0 in register
+* if timeout is not a power of 2, round to next highest power of 2
+*/
if (timeout  16) {
timeout = 0;
} else {
-   timeout = __fls(timeout) - 3;
if (timeout  (timeout - 1))
-   timeout++;
+   timeout = 1;
+   timeout = __fls(timeout) - 3;
}
 
switch (lpmode) {
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/8] memory: emif: setup LP settings on freq update

2013-03-16 Thread Lokesh Vutla 
From: Ambresh K ambr...@ti.com

Program the power management shadow register on freq update
Else the concept of threshold frequencies dont really matter
as the system always uses the performance mode timing for LP
which is programmed in at init time.

Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Ambresh K ambr...@ti.com
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
Changes since V1: No changes

 drivers/memory/emif.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 508763c..5f3b7ed 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -819,6 +819,8 @@ static void setup_registers(struct emif_data *emif, struct 
emif_regs *regs)
 
writel(regs-sdram_tim2_shdw, base + EMIF_SDRAM_TIMING_2_SHDW);
writel(regs-phy_ctrl_1_shdw, base + EMIF_DDR_PHY_CTRL_1_SHDW);
+   writel(regs-pwr_mgmt_ctrl_shdw,
+  base + EMIF_POWER_MANAGEMENT_CTRL_SHDW);
 
/* Settings specific for EMIF4D5 */
if (emif-plat_data-ip_rev != EMIF_4D5)
-- 
1.7.9.5

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

Re: [net PATCH 1/1] drivers: net: ethernet: ti: davinci_emac: fix usage of cpdma_check_free_tx_desc()

2013-03-16 Thread Prabhakar Lad 
Hi Mugunthan

Thanks for the patch!

On Fri, Mar 15, 2013 at 7:40 PM, Mugunthan V N mugunthan...@ti.com wrote:
 Fix which was done in the following commit in cpsw driver has
 to be taken forward to davinci emac driver as well.

 commit d35162f89b8f00537d7b240b76d2d0e8b8d29aa0
 Author: Daniel Mack zon...@gmail.com
 Date:   Tue Mar 12 06:31:19 2013 +

 net: ethernet: cpsw: fix usage of cpdma_check_free_tx_desc()

 Commit fae50823d0 (net: ethernet: davinci_cpdma: Add boundary for rx
 and tx descriptors) introduced a function to check the current
 allocation state of tx packets. The return value is taken into account
 to stop the netqork queue on the adapter in case there are no free
 slots.

 However, cpdma_check_free_tx_desc() returns 'true' if there is room in
 the bitmap, not 'false', so the usage of the function is wrong.

 Reported-by: Prabhakar Lad prabhakar.cse...@gmail.com
 Signed-off-by: Mugunthan V N mugunthan...@ti.com

 Tested-by: Lad, Prabhakar prabhakar.cse...@gmail.com

Cheers,
--Prabhakar Lad
http://www.linkedin.com/pub/prabhakar-lad/19/92b/955

 ---
  drivers/net/ethernet/ti/davinci_emac.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/net/ethernet/ti/davinci_emac.c 
 b/drivers/net/ethernet/ti/davinci_emac.c
 index 52c0536..ae1b77a 100644
 --- a/drivers/net/ethernet/ti/davinci_emac.c
 +++ b/drivers/net/ethernet/ti/davinci_emac.c
 @@ -1102,7 +1102,7 @@ static int emac_dev_xmit(struct sk_buff *skb, struct 
 net_device *ndev)
 /* If there is no more tx desc left free then we need to
  * tell the kernel to stop sending us tx frames.
  */
 -   if (unlikely(cpdma_check_free_tx_desc(priv-txchan)))
 +   if (unlikely(!cpdma_check_free_tx_desc(priv-txchan)))
 netif_stop_queue(ndev);

 return NETDEV_TX_OK;
 --
 1.7.9.5

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

Re: [PATCH 22/50] staging: omap-thermal: rewrite omap_bandgap_adc_to_mcelsius on kernel coding style

2013-03-16 Thread Dan Carpenter 
On Fri, Mar 15, 2013 at 09:00:10AM -0400, Eduardo Valentin wrote:
 Follow Documentation/CodingStyle while doing  omap_bandgap_adc_to_mcelsius.

Someone should probably fix CodingStyle to be more clear.  That's
not what was intended at all...  :/

regards,
dan carpenter

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

Re: [PATCH 25/50] staging: omap-thermal: rewrite omap_bandgap_mcelsius_to_adc on kernel coding style

2013-03-16 Thread Dan Carpenter 
On Fri, Mar 15, 2013 at 09:00:13AM -0400, Eduardo Valentin wrote:
 Follow Documentation/CodingStyle while doing omap_bandgap_mcelsius_to_adc
 

I have the same response for all these bunny hop patches.

When you're reading the code and you see a goto then you assume that
it's there for a reason so it's misleading when it doesn't do
anything.  It's simpler if the code is simple.

regards,
dan carpenter

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

Re: [PATCH 33/50] staging: omap-thermal: refactor APIs handling threshold values

2013-03-16 Thread Dan Carpenter 
On Fri, Mar 15, 2013 at 09:00:21AM -0400, Eduardo Valentin wrote:
   if (ret) {
   dev_err(bg_ptr-dev, failed to read thot\n);
 - return -EIO;
 + ret = -EIO;
 + goto exit;
   }
  
 - *thot = temp;
 + *val = temp;
  
 +exit:
   return 0;
  }


The bunny hop has introduced a bug and this always returns success.

regards,
dan carpenter

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

Re: [PATCH 47/50] staging: omap-thermal: switch mutex to spinlock inside omap-bandgap

2013-03-16 Thread Dan Carpenter 
On Fri, Mar 15, 2013 at 09:00:35AM -0400, Eduardo Valentin wrote:
 Because there is a need to lock inside IRQ handler, this patch
 changes the locking mechanism inside the omap-bandgap.[c,h] to
 spinlocks. Now this lock is used to protect omap_bandgap struct
 during APIs exposed (possibly used in sysfs handling functions)
 and inside the ALERT IRQ handler.
 
 Because there are registers shared among the sensors, this lock
 is global, not per sensor.
 
 Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
 ---
  drivers/staging/omap-thermal/TODO   |1 -
  drivers/staging/omap-thermal/omap-bandgap.c |   18 ++
  drivers/staging/omap-thermal/omap-bandgap.h |4 ++--
  3 files changed, 12 insertions(+), 11 deletions(-)
 
 diff --git a/drivers/staging/omap-thermal/TODO 
 b/drivers/staging/omap-thermal/TODO
 index 77b761b..0f24e9b 100644
 --- a/drivers/staging/omap-thermal/TODO
 +++ b/drivers/staging/omap-thermal/TODO
 @@ -1,7 +1,6 @@
  List of TODOs (by Eduardo Valentin)
  
  on omap-bandgap.c:
 -- Rework locking
  - Improve driver code by adding usage of regmap-mmio
  - Test every exposed API to userland
  - Add support to hwmon
 diff --git a/drivers/staging/omap-thermal/omap-bandgap.c 
 b/drivers/staging/omap-thermal/omap-bandgap.c
 index 4b631fd..846ced6 100644
 --- a/drivers/staging/omap-thermal/omap-bandgap.c
 +++ b/drivers/staging/omap-thermal/omap-bandgap.c
 @@ -33,7 +33,7 @@
  #include linux/platform_device.h
  #include linux/err.h
  #include linux/types.h
 -#include linux/mutex.h
 +#include linux/spinlock.h
  #include linux/reboot.h
  #include linux/of_device.h
  #include linux/of_platform.h
 @@ -170,6 +170,7 @@ static irqreturn_t omap_bandgap_talert_irq_handler(int 
 irq, void *data)
   u32 t_hot = 0, t_cold = 0, ctrl;
   int i;
  
 + spin_lock(bg_ptr-lock);
   for (i = 0; i  bg_ptr-conf-sensor_count; i++) {
   tsr = bg_ptr-conf-sensors[i].registers;
   ctrl = omap_bandgap_readl(bg_ptr, tsr-bgap_status);
 @@ -208,6 +209,7 @@ static irqreturn_t omap_bandgap_talert_irq_handler(int 
 irq, void *data)
   if (bg_ptr-conf-report_temperature)
   bg_ptr-conf-report_temperature(bg_ptr, i);
   }
 + spin_unlock(bg_ptr-lock);
  
   return IRQ_HANDLED;
  }
 @@ -502,9 +504,9 @@ int _omap_bandgap_write_threshold(struct omap_bandgap 
 *bg_ptr, int id, int val,
   if (ret  0)
   goto exit;
  
 - mutex_lock(bg_ptr-bg_mutex);
 + spin_lock(bg_ptr-lock);

These need to disable interrupts because we take the spin lock in
the IRQ handler.

regards,
dan carpenter


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

Re: [PATCH 00/50] staging: omap-thermal: several code refactoring

2013-03-16 Thread Dan Carpenter 
I've reviewed this set.

I hate to make people redo whole patchset sets, and I hate
re-reviewing code.  Obviously, I don't really like the bunny hop
patches and I'm trying to discourage that going forward.  ;P  But
I wouldn't say it's a Redo the whole thing kind of problem.

Could just resend patch 33 and 47?  You should probably be able to
redo those without changing the rest.

regards,
dan carpenter

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

Re: Getting kernel uImage build issue on omap2+

2013-03-16 Thread Javier Martinez Canillas 
On Sat, Mar 16, 2013 at 5:44 AM, Anil Kumar anilk...@gmail.com wrote:
 Hi,

 I am getting kernel uImage build issue on omap2+ log[1]

 Taken kernel branch for_3.10/dts from
 https://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git

 Taking reference from
 https://kernel.googlesource.com/pub/scm/linux/kernel/git/tmlind/linux-omap/+/omap-for-v3.9/multiplatform-enable-signed-v2

 Am I missing some thing ?

 [1]
 anil@anil-laptop:~/Anil/omap3/bcousson$  mkimage -A arm -O linux -T
 kernel -C none -a 0x80008000 -e 0x80008000 -n Linux -d
 zImage-omap2plus uImage-omap2plus
 mkimage: Can't open zImage-omap2plus: No such file or directory
 anil@anil-laptop:~/Anil/omap3/bcousson$

 Thanks,
 Anil


Hi Anil,

It seems that Tony's email assumed that you generated a bunch of
zImages for different platforms and then naming them zImage-$platform.

e.g:

$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- omap2plus_defconfig
$ make -j 4 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- zImage modules
zImage-omap2plus
$ cp cp arch/arm/boot/zImage zImage-omap2plus

and then you can use the command in [1]:

$  mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e
0x80008000 -n Linux -d zImage-omap2plus uImage-omap2plus

anyways, the problem is that zImage-omap2plus does not exist and you
have to use the zImage generated by make zImage. What I usually do
is just:

$ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e
0x80008000 -n Linux -d arch/arm/boot/zImage uImage-omap2plus

and then copy uImage-omap2plus as uImage on either my board MMC/SD or
Flash memory.

Also, if you find this inconvenient, you can add CONFIG_CMD_BOOTZ to
your board header config file in U-Boot so it can boot a zImage
directly instead of an uImage. Not sure when did was introduced on
U-Boot but should be available on any decent-ish version.

Hope it helps,
Javier
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/6] OF: Introduce Device Tree resolve support.

2013-03-16 Thread Grant Likely 
On Wed, 23 Jan 2013 12:58:02 +0200, Pantelis Antoniou 
pa...@antoniou-consulting.com wrote:
 Hi David,
 
 On Jan 23, 2013, at 6:40 AM, David Gibson wrote:
  Ok.  Nonetheless it's not hard to avoid a recursive approach here.
 
 How can I find the maximum phandle value of a subtree without using recursion.
 Note that the whole function is just 6 lines long.

It's a failure in the existing kernel DT data structures. We need a hash
lookup for the phandles to eliminate the search entirely. Then you'd be
able to allocated new phandles on the fly easily and resolve phandles
without searching the whole tree (which has always been horrible).

That said, I'd like to punt on the whole phandle resolution thing. The
DT overlay support can be merged without the phandle resolution support
if the core rejects any overlays with phandle collisions.

g.
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/6] OF: Export all DT proc update functions

2013-03-16 Thread Grant Likely 
On Fri,  4 Jan 2013 21:31:07 +0200, Pantelis Antoniou 
pa...@antoniou-consulting.com wrote:
 There are other users for the proc DT functions.
 Export them.
 
 Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com

Actually, I cannot find the user of this patch. Why is it needed?

g.
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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/6] OF: Export all DT proc update functions

2013-03-16 Thread Grant Likely 
On Fri,  4 Jan 2013 21:31:07 +0200, Pantelis Antoniou 
pa...@antoniou-consulting.com wrote:
 There are other users for the proc DT functions.
 Export them.
 
 Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com

Hi Pantelis.

Patches 1  2 look good. No comments there.

This patch bothers me. The manipulation of the proc entries is part and
parcel of adding and removing nodes. The real problem seems to be that
the node addition/removal APIs need to be made usable by the overlay
code.

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

Re: Getting kernel uImage build issue on omap2+

2013-03-16 Thread Anil Kumar 
Hi Javier,

On Sat, Mar 16, 2013 at 2:53 PM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
 On Sat, Mar 16, 2013 at 5:44 AM, Anil Kumar anilk...@gmail.com wrote:
 Hi,

 I am getting kernel uImage build issue on omap2+ log[1]

 Taken kernel branch for_3.10/dts from
 https://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git

 Taking reference from
 https://kernel.googlesource.com/pub/scm/linux/kernel/git/tmlind/linux-omap/+/omap-for-v3.9/multiplatform-enable-signed-v2

 Am I missing some thing ?

 [1]
 anil@anil-laptop:~/Anil/omap3/bcousson$  mkimage -A arm -O linux -T
 kernel -C none -a 0x80008000 -e 0x80008000 -n Linux -d
 zImage-omap2plus uImage-omap2plus
 mkimage: Can't open zImage-omap2plus: No such file or directory
 anil@anil-laptop:~/Anil/omap3/bcousson$

 Thanks,
 Anil


 Hi Anil,

 It seems that Tony's email assumed that you generated a bunch of
 zImages for different platforms and then naming them zImage-$platform.

 e.g:

 $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- omap2plus_defconfig
 $ make -j 4 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- zImage modules
 zImage-omap2plus
 $ cp cp arch/arm/boot/zImage zImage-omap2plus

 and then you can use the command in [1]:

 $  mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e
 0x80008000 -n Linux -d zImage-omap2plus uImage-omap2plus

 anyways, the problem is that zImage-omap2plus does not exist and you
 have to use the zImage generated by make zImage. What I usually do
 is just:

 $ mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e
 0x80008000 -n Linux -d arch/arm/boot/zImage uImage-omap2plus

 and then copy uImage-omap2plus as uImage on either my board MMC/SD or
 Flash memory.

Thanks, It solved the issue
Anil
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 07/50] staging: omap-thermal: introduce RMW_BITS macro

2013-03-16 Thread Eduardo Valentin 

Hello Dan,

On 15-03-2013 17:09, Dan Carpenter wrote:

On Fri, Mar 15, 2013 at 08:59:55AM -0400, Eduardo Valentin wrote:

This patch introduce a macro to read, update, write bitfields.
It will be specific to bandgap data structures.

Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
  drivers/staging/omap-thermal/omap-bandgap.c |  178 +++
  1 files changed, 46 insertions(+), 132 deletions(-)

diff --git a/drivers/staging/omap-thermal/omap-bandgap.c 
b/drivers/staging/omap-thermal/omap-bandgap.c
index 9f2d7cc..1c1b905 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -52,25 +52,29 @@ static void omap_bandgap_writel(struct omap_bandgap 
*bg_ptr, u32 val, u32 reg)
writel(val, bg_ptr-base + reg);
  }

+/* update bits, value will be shifted */
+#define RMW_BITS(bg_ptr, id, reg, mask, val)   \
+do {   \
+   struct temp_sensor_registers *t;\
+   u32 r;  \
+   \
+   t = bg_ptr-conf-sensors[(id)].registers;\
+   r = omap_bandgap_readl(bg_ptr, t-reg);  \
+   r = ~t-mask;   \
+   r |= (val)  __ffs(t-mask);  \
+   omap_bandgap_writel(bg_ptr, r, t-reg);  \
+} while (0)
+
  static int omap_bandgap_power(struct omap_bandgap *bg_ptr, bool on)
  {
-   struct temp_sensor_registers *tsr;
int i;
-   u32 ctrl;

if (!OMAP_BANDGAP_HAS(bg_ptr, POWER_SWITCH))
return 0;

-   for (i = 0; i  bg_ptr-conf-sensor_count; i++) {
-   tsr = bg_ptr-conf-sensors[i].registers;
-   ctrl = omap_bandgap_readl(bg_ptr, tsr-temp_sensor_ctrl);
-   ctrl = ~tsr-bgap_tempsoff_mask;
+   for (i = 0; i  bg_ptr-conf-sensor_count; i++)
/* active on 0 */
-   ctrl |= !on  __ffs(tsr-bgap_tempsoff_mask);
-
-   /* write BGAP_TEMPSOFF should be reset to 0 */
-   omap_bandgap_writel(bg_ptr, ctrl, tsr-temp_sensor_ctrl);
-   }
+   RMW_BITS(bg_ptr, i, temp_sensor_ctrl, bgap_tempsoff_mask, !on);

return 0;
  }
@@ -78,15 +82,13 @@ static int omap_bandgap_power(struct omap_bandgap *bg_ptr, 
bool on)
  static u32 omap_bandgap_read_temp(struct omap_bandgap *bg_ptr, int id)
  {


This patch is fine and it makes it cleaner than before.

But that said, I don't care for the RMW_BITS() very much as a long
term thing.  If we just used pointers instead of passing the offset
into the bg_ptr-conf-sensors[] array then everything would be a
lot cleaner.

In other words, instead of this:

static u32 omap_bandgap_read_temp(struct omap_bandgap *bg_ptr, int id)

We would have:

static u32 omap_bandgap_read_temp(struct omap_bandgap *bg_ptr,
  struct temp_sensor_registers *tsr)


I see. That will require a change in the whole driver though. If you 
see, the driver as of today uses the former approach, not only for 
read_temp or rmw_bits.




If you have the pointer then it's easy write RMW_BITS() as a
function.

static void rmw_bits(struct omap_bandgap *bg_ptr, u32 reg, u32 mask, u32 val)
{
u32 r;

r = omap_bandgap_readl(bg_ptr, reg);
r = ~mask;
r |= val  __ffs(mask);
omap_bandgap_writel(bg_ptr, r, reg);
}

It's called like:

rmw_bits(bg_ptr, tsr-bgap_mask_ctrl, tsr-mask_freeze_mask, 1);


This is nice, but it will require fetching tsr from .conf before every 
call o rmw_bits. And for that you need the sensor index.




regards,
dan carpenter


Thanks for your time reviewing this patch and suggesting improvements.








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

Re: [PATCH 09/50] staging: omap-thermal: make a omap_bandgap_power with only one exit point

2013-03-16 Thread Eduardo Valentin 

Hey Dan,

On 15-03-2013 17:22, Dan Carpenter wrote:

On Fri, Mar 15, 2013 at 08:59:57AM -0400, Eduardo Valentin wrote:

Change the way the omap_bandgap_power is written so that it has only
one exit entry (Documentation/CodingStyle).



It's only if there is an unlock or something that you should do
this.  Otherwise the pointless bunny hop is misleading and annoying.


Well, if that is the case the Chapter 7 needs to be rewritten, don't you 
think? The way it is stated, it is clear that it is a design decision to 
use it for keeping only one exit point (quoting):


Albeit deprecated by some people, the equivalent of the goto statement is
used frequently by compilers in form of the unconditional jump instruction.

The goto statement comes in handy when a function exits from multiple
locations and some common work such as cleanup has to be done.

The rationale is:

- unconditional statements are easier to understand and follow
- nesting is reduced
- errors by not updating individual exit points when making
modifications are prevented
- saves the compiler work to optimize redundant code away ;)

I believe this patch falls into at least three of the above rationale.




regards,
dan carpenter





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

Re: [PATCH 47/50] staging: omap-thermal: switch mutex to spinlock inside omap-bandgap

2013-03-16 Thread Eduardo Valentin 

On 16-03-2013 04:59, Dan Carpenter wrote:

On Fri, Mar 15, 2013 at 09:00:35AM -0400, Eduardo Valentin wrote:

Because there is a need to lock inside IRQ handler, this patch
changes the locking mechanism inside the omap-bandgap.[c,h] to
spinlocks. Now this lock is used to protect omap_bandgap struct
during APIs exposed (possibly used in sysfs handling functions)
and inside the ALERT IRQ handler.

Because there are registers shared among the sensors, this lock
is global, not per sensor.

Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
  drivers/staging/omap-thermal/TODO   |1 -
  drivers/staging/omap-thermal/omap-bandgap.c |   18 ++
  drivers/staging/omap-thermal/omap-bandgap.h |4 ++--
  3 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/omap-thermal/TODO 
b/drivers/staging/omap-thermal/TODO
index 77b761b..0f24e9b 100644
--- a/drivers/staging/omap-thermal/TODO
+++ b/drivers/staging/omap-thermal/TODO
@@ -1,7 +1,6 @@
  List of TODOs (by Eduardo Valentin)

  on omap-bandgap.c:
-- Rework locking
  - Improve driver code by adding usage of regmap-mmio
  - Test every exposed API to userland
  - Add support to hwmon
diff --git a/drivers/staging/omap-thermal/omap-bandgap.c 
b/drivers/staging/omap-thermal/omap-bandgap.c
index 4b631fd..846ced6 100644
--- a/drivers/staging/omap-thermal/omap-bandgap.c
+++ b/drivers/staging/omap-thermal/omap-bandgap.c
@@ -33,7 +33,7 @@
  #include linux/platform_device.h
  #include linux/err.h
  #include linux/types.h
-#include linux/mutex.h
+#include linux/spinlock.h
  #include linux/reboot.h
  #include linux/of_device.h
  #include linux/of_platform.h
@@ -170,6 +170,7 @@ static irqreturn_t omap_bandgap_talert_irq_handler(int irq, 
void *data)
u32 t_hot = 0, t_cold = 0, ctrl;
int i;

+   spin_lock(bg_ptr-lock);
for (i = 0; i  bg_ptr-conf-sensor_count; i++) {
tsr = bg_ptr-conf-sensors[i].registers;
ctrl = omap_bandgap_readl(bg_ptr, tsr-bgap_status);
@@ -208,6 +209,7 @@ static irqreturn_t omap_bandgap_talert_irq_handler(int irq, 
void *data)
if (bg_ptr-conf-report_temperature)
bg_ptr-conf-report_temperature(bg_ptr, i);
}
+   spin_unlock(bg_ptr-lock);

return IRQ_HANDLED;
  }
@@ -502,9 +504,9 @@ int _omap_bandgap_write_threshold(struct omap_bandgap 
*bg_ptr, int id, int val,
if (ret  0)
goto exit;

-   mutex_lock(bg_ptr-bg_mutex);
+   spin_lock(bg_ptr-lock);


These need to disable interrupts because we take the spin lock in
the IRQ handler.


This IRQ gets masked at the IRQ controller level when served (ONE_SHOT). 
Not sure if your comment is applicable in this case..




regards,
dan carpenter






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

Re: [PATCH 00/50] staging: omap-thermal: several code refactoring

2013-03-16 Thread Eduardo Valentin 

Hello Dan,

On 16-03-2013 05:05, Dan Carpenter wrote:

I've reviewed this set.

I hate to make people redo whole patchset sets, and I hate
re-reviewing code.  Obviously, I don't really like the bunny hop
patches and I'm trying to discourage that going forward.  ;P  But
I wouldn't say it's a Redo the whole thing kind of problem.

Could just resend patch 33 and 47?  You should probably be able to
redo those without changing the rest.


I could of course change them if the comment is better clarified. As I 
mentioned as reply to one of your comments, those changes are following 
what is suggested in CodingStyle file.


I can of course send a diff on top of 33, to fix the introduce bug.

For 47, I'm not sure the comment is fully applicable.



regards,
dan carpenter





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

Re: [PATCH 33/50] staging: omap-thermal: refactor APIs handling threshold values

2013-03-16 Thread Eduardo Valentin 

On 16-03-2013 04:39, Dan Carpenter wrote:

On Fri, Mar 15, 2013 at 09:00:21AM -0400, Eduardo Valentin wrote:

if (ret) {
dev_err(bg_ptr-dev, failed to read thot\n);
-   return -EIO;
+   ret = -EIO;
+   goto exit;
}

-   *thot = temp;
+   *val = temp;

+exit:
return 0;
  }



The bunny hop has introduced a bug and this always returns success.


What was the bug introduced?

I will send a patch to fix the return value.



regards,
dan carpenter





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

Re: [PATCH 09/50] staging: omap-thermal: make a omap_bandgap_power with only one exit point

2013-03-16 Thread Dan Carpenter 
On Sat, Mar 16, 2013 at 08:39:11AM -0400, Eduardo Valentin wrote:
 Hey Dan,
 
 On 15-03-2013 17:22, Dan Carpenter wrote:
 On Fri, Mar 15, 2013 at 08:59:57AM -0400, Eduardo Valentin wrote:
 Change the way the omap_bandgap_power is written so that it has only
 one exit entry (Documentation/CodingStyle).
 
 
 It's only if there is an unlock or something that you should do
 this.  Otherwise the pointless bunny hop is misleading and annoying.
 
 Well, if that is the case the Chapter 7 needs to be rewritten, don't
 you think? The way it is stated, it is clear that it is a design
 decision to use it for keeping only one exit point (quoting):
 
 Albeit deprecated by some people, the equivalent of the goto statement is
 used frequently by compilers in form of the unconditional jump instruction.
 
 The goto statement comes in handy when a function exits from multiple
 locations and some common work such as cleanup has to be done.
 
 The rationale is:
 
 - unconditional statements are easier to understand and follow
 - nesting is reduced
 - errors by not updating individual exit points when making
 modifications are prevented
 - saves the compiler work to optimize redundant code away ;)
 
 I believe this patch falls into at least three of the above rationale.

There isn't any cleanup work done.  That's what I was explaining
about.  When I see a goto I expect cleanup work to be done, but in
this case it was misleading.

Where you would do the one exit point is when there is cleanup:

ret = function_one();
if (ret)
goto unlock;

ret = function_two();
if (ret)
goto unlock;


That's better than:
ret = function_one();
if (ret) {
mutex_unlock();
return ret;
}

ret = function_two();
if (ret) {
mutex_unlock();
return ret;
}

On the one hand, I think the documentation should be updated because
obviously people get confused by it.  But on the other hand, to me
the documentation is already pretty clear.  There is no style
guideline that says every function should only have a single return.
That would be silly.

regards,
dan carpenter

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

Re: [PATCH 33/50] staging: omap-thermal: refactor APIs handling threshold values

2013-03-16 Thread Dan Carpenter 
On Sat, Mar 16, 2013 at 08:49:20AM -0400, Eduardo Valentin wrote:
 On 16-03-2013 04:39, Dan Carpenter wrote:
 On Fri, Mar 15, 2013 at 09:00:21AM -0400, Eduardo Valentin wrote:
 if (ret) {
 dev_err(bg_ptr-dev, failed to read thot\n);
 -   return -EIO;
 +   ret = -EIO;
 +   goto exit;
 }
 
 -   *thot = temp;
 +   *val = temp;
 
 +exit:
 return 0;
   }
 
 
 The bunny hop has introduced a bug and this always returns success.
 
 What was the bug introduced?
 
 I will send a patch to fix the return value.

Returning the wrong value *is* the bug.

regards,
dan carpenter

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

Re: [PATCH 07/50] staging: omap-thermal: introduce RMW_BITS macro

2013-03-16 Thread Dan Carpenter 
On Sat, Mar 16, 2013 at 08:36:51AM -0400, Eduardo Valentin wrote:
 But that said, I don't care for the RMW_BITS() very much as a long
 term thing.  If we just used pointers instead of passing the offset
 into the bg_ptr-conf-sensors[] array then everything would be a
 lot cleaner.
 
 In other words, instead of this:
 
 static u32 omap_bandgap_read_temp(struct omap_bandgap *bg_ptr, int id)
 
 We would have:
 
 static u32 omap_bandgap_read_temp(struct omap_bandgap *bg_ptr,
struct temp_sensor_registers *tsr)
 
 I see. That will require a change in the whole driver though. If you
 see, the driver as of today uses the former approach, not only for
 read_temp or rmw_bits.

Yep.

 
 
 If you have the pointer then it's easy write RMW_BITS() as a
 function.
 
 static void rmw_bits(struct omap_bandgap *bg_ptr, u32 reg, u32 mask, u32 val)
 {
  u32 r;
 
  r = omap_bandgap_readl(bg_ptr, reg);
  r = ~mask;
  r |= val  __ffs(mask);
  omap_bandgap_writel(bg_ptr, r, reg);
 }
 
 It's called like:
 
  rmw_bits(bg_ptr, tsr-bgap_mask_ctrl, tsr-mask_freeze_mask, 1);
 
 This is nice, but it will require fetching tsr from .conf before
 every call o rmw_bits. And for that you need the sensor index.
 

No.  I'm suggesting that you re-write the driver to pass the tsr
pointer directly instead of the index.

regards,
dan carpenter

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

Re: [PATCH 47/50] staging: omap-thermal: switch mutex to spinlock inside omap-bandgap

2013-03-16 Thread Dan Carpenter 
On Sat, Mar 16, 2013 at 08:41:30AM -0400, Eduardo Valentin wrote:
 On 16-03-2013 04:59, Dan Carpenter wrote:
 On Fri, Mar 15, 2013 at 09:00:35AM -0400, Eduardo Valentin wrote:
 @@ -502,9 +504,9 @@ int _omap_bandgap_write_threshold(struct omap_bandgap 
 *bg_ptr, int id, int val,
 if (ret  0)
 goto exit;
 
 -   mutex_lock(bg_ptr-bg_mutex);
 +   spin_lock(bg_ptr-lock);
 
 These need to disable interrupts because we take the spin lock in
 the IRQ handler.
 
 This IRQ gets masked at the IRQ controller level when served
 (ONE_SHOT). Not sure if your comment is applicable in this case..

Yes.  It still applies.  We need to disable IRQs from the current
CPU while we are holding a spin_lock which they will need.

regards,
dan carpenter

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

Re: [PATCH 00/50] staging: omap-thermal: several code refactoring

2013-03-16 Thread Greg KH 
On Sat, Mar 16, 2013 at 08:46:03AM -0400, Eduardo Valentin wrote:
 Hello Dan,
 
 On 16-03-2013 05:05, Dan Carpenter wrote:
 I've reviewed this set.
 
 I hate to make people redo whole patchset sets, and I hate
 re-reviewing code.  Obviously, I don't really like the bunny hop
 patches and I'm trying to discourage that going forward.  ;P  But
 I wouldn't say it's a Redo the whole thing kind of problem.
 
 Could just resend patch 33 and 47?  You should probably be able to
 redo those without changing the rest.
 
 I could of course change them if the comment is better clarified. As
 I mentioned as reply to one of your comments, those changes are
 following what is suggested in CodingStyle file.
 
 I can of course send a diff on top of 33, to fix the introduce bug.
 
 For 47, I'm not sure the comment is fully applicable.

As I've taken all of these already (sorry Dan, I was fast and I didn't
review them as well as you did), you will have to just send incremental
patches on top of the whole series in order for me to be able to apply
them.

thanks,

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

commit 6797b4f causes boot hangs with nfsroot

2013-03-16 Thread Paul Walmsley 

Hi Jon,

Looks like commit 6797b4fe0e554ce71f47038fd929c9ca929a9f3c (ARM: OMAP2+: 
Prevent potential crash if GPMC probe fails) causes hangs on boot.  I 
suspect it may only occur when the root filesystem is on NFS over 
GPMC-based Ethernet.

Here's the current state of affairs at v3.9-rc1 on the two boards that 
show the problem:

http://www.pwsan.com/omap/testlogs/test_v3.9-rc1/20130312100243/boot/2430sdp/2430sdp_log.txt
http://www.pwsan.com/omap/testlogs/test_v3.9-rc1/20130312100243/boot/37xxevm/37xxevm_log.txt

and here are the bootlogs after reverting 6797b4f:

http://www.pwsan.com/omap/testlogs/trace_boot_hang_3.9-rc/20130316132833/boot/2430sdp/2430sdp_log.txt
http://www.pwsan.com/omap/testlogs/trace_boot_hang_3.9-rc/20130316132833/boot/37xxevm/37xxevm_log.txt

... where the boards at least boot to userspace.  I don't know what's up 
with the NFS-related lock problems.  Those look like yet another bug that 
is presumably not OMAP-specific :-(

Care to take a look at the commit 6797b4f bug?


- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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 02/18] ARM: OMAP2+: Add variable to store number of GPMC waitpins

2013-03-16 Thread Ezequiel Garcia 
Hi Jon,

On Fri, Mar 15, 2013 at 10:21:00AM -0500, Jon Hunter wrote:
 The GPMC has wait-pin signals that can be assigned to a chip-select
 to monitor the ready signal of an external device. Add a variable to
 indicate the total number of wait-pins for a given device. This will
 allow us to detect if the wait-pin being selected is valid or not.
 
 When booting with device-tree read the number of wait-pins from the
 device-tree blob. When device-tree is not used set the number of
 wait-pins to 4 which is valid for OMAP2-5 devices. Newer devices
 that have less wait-pins (such as AM335x) only support booting with
 device-tree and so hard-coding the wait-pin number when not using
 device-tree is fine.
 
 Signed-off-by: Jon Hunter jon-hun...@ti.com
 ---
  arch/arm/mach-omap2/gpmc.c |   16 
  1 file changed, 16 insertions(+)
 
 diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
 index ef655d9..88a261c 100644
 --- a/arch/arm/mach-omap2/gpmc.c
 +++ b/arch/arm/mach-omap2/gpmc.c
 @@ -108,6 +108,8 @@
  #define  GPMC_HAS_WR_ACCESS  0x1
  #define  GPMC_HAS_WR_DATA_MUX_BUS0x2
  
 +#define GPMC_NR_WAITPINS 4
 +
  /* XXX: Only NAND irq has been considered,currently these are the only ones 
 used
   */
  #define  GPMC_NR_IRQ 2
 @@ -153,6 +155,7 @@ static struct resourcegpmc_cs_mem[GPMC_CS_NUM];
  static DEFINE_SPINLOCK(gpmc_mem_lock);
  /* Define chip-selects as reserved by default until probe completes */
  static unsigned int gpmc_cs_map = ((1  GPMC_CS_NUM) - 1);
 +static unsigned int gpmc_nr_waitpins;
  static struct device *gpmc_dev;
  static int gpmc_irq;
  static resource_size_t phys_base, mem_size;
 @@ -1297,6 +1300,13 @@ static int gpmc_probe_dt(struct platform_device *pdev)
   if (!of_id)
   return 0;
  
 + ret = of_property_read_u32(pdev-dev.of_node, gpmc,num-waitpins,
 +gpmc_nr_waitpins);
 + if (ret  0) {
 + pr_err(%s: number of wait pins not found!\n, __func__);
 + return ret;
 + }
 +
   for_each_node_by_name(child, nand) {
   ret = gpmc_probe_nand_child(pdev, child);
   if (ret  0) {
 @@ -1372,6 +1382,12 @@ static int gpmc_probe(struct platform_device *pdev)
   if (gpmc_setup_irq()  0)
   dev_warn(gpmc_dev, gpmc_setup_irq failed\n);
  
 + /* Now the GPMC is initialised, unreserve the chip-selects */
 + gpmc_cs_map = 0;

The above seems to be a remanent of another patch.
I think you already sent that one, right?

-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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] ARM: dts: add minimal DT support for DevKit8000.

2013-03-16 Thread Anil Kumar 
Hi Benoit,

On Thu, Mar 7, 2013 at 12:21 PM, Benoit Cousson b-cous...@ti.com wrote:
 Hi,

 On 03/06/2013 06:53 PM, Tony Lindgren wrote:
 * Anil Kumar anilk...@gmail.com [130305 18:40]:
 Hi Tony,

 From: linux-arm-kernel [mailto:linux-arm-kernel-
 boun...@lists.infradead.org] On Behalf Of Anil Kumar
 Sent: Wednesday, February 27, 2013 8:03 AM
 To: devicetree-disc...@lists.ozlabs.org; linux-omap@vger.kernel.org;
 linux-ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
 Cc: li...@arm.linux.org.uk; Cousson, Benoit; Tony Lindgren; Grant
 Likely; Anil Kumar; tho...@tomweber.eu
 Subject: Re: FW: [PATCH V4] ARM: dts: add minimal DT support for
 DevKit8000.

 Hi,

 DevKit8000 is a beagle board clone from Timll, sold by
 armkits.com. The DevKit8000 has RS232 serial port, LCD, DVI-D,
 S-Video, Ethernet, SD/MMC, keyboard, camera, SPI, I2C, USB and
 JTAG interface.

 This patch adds the basic DT support for devkit8000. At this time,
 Information
 of twl4030 (PMIC), MMC1, I2C1 and leds are added.

 Signed-off-by: Anil Kumar anilk...@gmail.com
 Tested-by: Thomas Weber tho...@tomweber.eu

 Gentle Ping. As there are no review comments on this patch,
 Could you please pull this patch ?

 Gentle Ping.

 This patch also got Reviewed-by: Manish Badarkhe badarkhe.man...@gmail.com
 and as patch ARM: dts: omap3-devkit8000: Enable audio support  has 
 already got
 Acked-by: Peter Ujfalusi peter.ujfal...@ti.com but it is on the
 top of this patch.
 So, Could you please pull this patch in one of your omap branch? or
 you want me to
 do rebase this patch on top of v3.9-rc1 ?

 Let's wait for Benoit to queue it as he has a bunch of .dts changes already
 applied. Too bad we missed v3.9 merge window for those, but hopefully
 we can get them queued early for v3.10.

 Yep, sorry for having missed 3.9, I was a little bit sick at the wrong
 moment :-(

 I'm starting queuing the pending patches, and should have enough to push
 to you just after Linaro Connect.

I think you missed below patch which is needed for gpmc nand to work fine.

Jon Hunter:-
  ARM: OMAP2+: Fix-up gpmc merge error

I have re based my changes on top of your repository to make pull
easier for you.
I hope you will pull these changes for 3.10.

The following changes since Commit a7f7881de9c0b58de3b3aea8f01a8aef906d4ade

are available in the git repository at:

git://gitorious.org/devkit8000-for_3-10/devkit8000-for_3-10.git
branch for_3.10/dts

for you to fetch changes up to Commit 975abc8b2e7ec4ff7324d726c9775958945ccc5e

Anil Kumar:
ARM: dts: add minimal DT support for DevKit8000
ARM: dts: omap3-devkit8000: Enable audio support
ARM: dts: omap3-devkit8000: add nand dt node

Thanks,
Anil
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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 10/18] ARM: OMAP2+: Add function to read GPMC settings from device-tree

2013-03-16 Thread Ezequiel Garcia 
Hi Jon,

I have some tiny nitpicks...

On Fri, Mar 15, 2013 at 10:21:08AM -0500, Jon Hunter wrote:
 Adds a function to read the various GPMC chip-select settings from
 device-tree and store them in the gpmc_settings structure.
 
 Update the GPMC device-tree binding documentation to describe these
 options.
 
 Signed-off-by: Jon Hunter jon-hun...@ti.com
 ---
  Documentation/devicetree/bindings/bus/ti-gpmc.txt |   23 ++
  arch/arm/mach-omap2/gpmc.c|   49 
 +
  arch/arm/mach-omap2/gpmc.h|2 +
  3 files changed, 74 insertions(+)
 
 diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt 
 b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
 index 5ddb2e9..6fde1cf 100644
 --- a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
 +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
 @@ -65,6 +65,29 @@ The following are only applicable to OMAP3+ and AM335x:
   - gpmc,wr-access
   - gpmc,wr-data-mux-bus
  
 +GPMC chip-select settings properties for child nodes. All are optional.
 +
 +- gpmc,burst-length  Page/burst length. Must be 4, 8 or 16.
 +- gpmc,burst-wrapEnables wrap bursting
 +- gpmc,burst-readEnables read page/burst mode
 +- gpmc,burst-write   Enables write page/burst mode
 +- gpmc,device-nand   Device is NAND
 +- gpmc,device-width  Total width of device(s) connected to a GPMC
 + chip-select in bytes. The GPMC supports 8-bit
 + and 16-bit devices and so this property must be
 + 1 or 2.
 +- gpmc,mux-add-data  Address and data multiplexing configuration.
 + Valid values are 1 for address-address-data
 + multiplexing mode and 2 for address-data
 + multiplexing mode.
 +- gpmc,sync-read Enables synchronous read. Defaults to asynchronous
 + is this is not set.
 +- gpmc,sync-writeEnables synchronous writes. Defaults to asynchronous
 + is this is not set.
 +- gpmc,wait-pin  Wait-pin used by client. Must be less than
 + gpmc,num-waitpins.
 +- gpmc,wait-on-read  Enables wait monitoring on reads.
 +- gpmc,wait-on-write Enables wait monitoring on writes.
  
  Example for an AM33xx board:
  
 diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
 index 3ec1937..1e7eef3 100644
 --- a/arch/arm/mach-omap2/gpmc.c
 +++ b/arch/arm/mach-omap2/gpmc.c
 @@ -1190,6 +1190,55 @@ static struct of_device_id gpmc_dt_ids[] = {
  };
  MODULE_DEVICE_TABLE(of, gpmc_dt_ids);
  
 +/**
 + * gpmc_read_settings_dt - read gpmc settings from device-tree
 + * @np:  pointer to device-tree node for a gpmc child device
 + * @p:   pointer to gpmc settings structure
 + *
 + * Reads the GPMC settings for a GPMC child device from device-tree and
 + * stores them in the GPMC settings structure passed. The GPMC settings
 + * structure is initialise to zero by this function and so any previously

s/initialise/initialized ?

 + * stored settings will be clearer.

s/clearer/cleared ?

I'm not an english native speaker,
so please bare with me if I'm wrong on these...

-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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 00/18] ARM: OMAP2+: GPMC clean-up and DT update

2013-03-16 Thread Ezequiel Garcia 
On Fri, Mar 15, 2013 at 10:20:58AM -0500, Jon Hunter wrote:
 While adding device-tree support for NOR memories, it became apparent
 that there is no common way for configuring various GPMC settings for
 devices that interface to the GPMC. These settings include bus-width,
 synchronous/asynchronous mode, burst settings, wait monitoring etc.
 Therefore, to simplify the GPMC code and add device-tree support for
 NOR, it was first necessary to consolidate how these settings are
 programmed.
 
 Series based upon Mark Jackson's patch [1] and Ezequiel Garcia GPMC
 clean-up series [2]. Entire series available here [3].
 
 V3 changes:
 - Rebased on RMK's IS_ERR_VALUE() patch and removed usage of
   IS_ERR_VALUE() from series.
 - Fixed BUG in NAND code introduced in V2 by making gpmc_settings
   structure a local variable (I forgot to initialise structure to zero).
 - Added fix from Javier to correct return value from gpmc_probe_nor().
 
 V2 changes:
 - Made gpmc_settings structure local in gpmc_nand_init().
 - Use resource_size() API in probe_nor().
 - Add kernel-doc for gpmc_cs_program_settings() function.
 - Use of_platform_device_create() to register NOR devices in probe_nor().
 - Add support for GPMC address-address-data multiplexing which required
   changing GPMC DT property gpmc,mux-add-data to store a 32-bit value
   and changing mux_add_data member of gpmc_settings to be a 32-bit type
   instead of bool.
 - Add detection for incorrect GPMC chip-select base addresses.
 - Cleaned-up code in gpmc_mem_init() and changed gpmc_mem_init() so that
   it would not return an error when the GPMC driver is being probed.
 
 V1 changes:
 - Clean-up/simplification of ONENAND initialisation code.
 - Add a new GPMC structure to unify storage of various GPMC settings
   (that are non-timing related) for client devices and add a new
   function to program these settings in a common way.
 - Migrate initialisation code for existing flash, usb and networking
   devices to use the new structure and function for GPMC settings.
 - Add device-tree support for NOR flash memories.
 - Add additional GPMC timing parameters to GPMC device-tree binding.
 - Update GPMC NAND and ONENAND device-tree support to retrieve GPMC
   settings from device-tree.
 
 Testing includes:
 - Boot testing on OMAP2420 H4, OMAP3430 SDP and OMAP4430 SDP with
   and without device-tree present.
 - OMAP2420 H4 board has NOR flash and OMAP3430 SDP has NOR, NAND
   and ONENAND flash. So verified that flash is detected on boot
   as expected. Note additional patches [4] are required for OMAP2420
   H4 and OMAP3430 SDP dts files in order to enable flash memory
   support.
 - All of the above boards use GPMC for interfacing to a networking
   chip and so verified that networking is working wit this series.
   However, please note that networking is not currently supported
   on these boards when booting with DT and so networking is only
   tested without DT.
 
 [1] http://permalink.gmane.org/gmane.linux.ports.arm.omap/94765
 [2] http://comments.gmane.org/gmane.linux.ports.arm.omap/93784
 [3] https://github.com/jonhunter/linux/tree/omap-gpmc-for-v3.10
 [4] https://github.com/jonhunter/linux/tree/omap-dt-for-v3.10
 
 Javier Martinez Canillas (1):
   ARM: OMAP2+: return -ENODEV if GPMC child device creation fails
 
 Jon Hunter (17):
   ARM: OMAP2+: Simplify code configuring ONENAND devices
   ARM: OMAP2+: Add variable to store number of GPMC waitpins
   ARM: OMAP2+: Add structure for storing GPMC settings
   ARM: OMAP2+: Add function for configuring GPMC settings
   ARM: OMAP2+: Convert ONENAND to use gpmc_cs_program_settings()
   ARM: OMAP2+: Convert NAND to use gpmc_cs_program_settings()
   ARM: OMAP2+: Convert SMC91x to use gpmc_cs_program_settings()
   ARM: OMAP2+: Convert TUSB to use gpmc_cs_program_settings()
   ARM: OMAP2+: Don't configure of chip-select options in
 gpmc_cs_configure()
   ARM: OMAP2+: Add function to read GPMC settings from device-tree
   ARM: OMAP2+: Add device-tree support for NOR flash
   ARM: OMAP2+: Add additional GPMC timing parameters
   ARM: OMAP2+: Convert NAND to retrieve GPMC settings from DT
   ARM: OMAP2+: Convert ONENAND to retrieve GPMC settings from DT
   ARM: OMAP2+: Detect incorrectly aligned GPMC base address
   ARM: OMAP2+: Remove unnecesssary GPMC definitions and variable
   ARM: OMAP2+: Allow GPMC probe to complete even if CS mapping fails
 
  Documentation/devicetree/bindings/bus/ti-gpmc.txt  |   48 +-
  Documentation/devicetree/bindings/mtd/gpmc-nor.txt |   98 
  .../devicetree/bindings/mtd/gpmc-onenand.txt   |3 +
  arch/arm/mach-omap2/gpmc-nand.c|   39 +-
  arch/arm/mach-omap2/gpmc-onenand.c |  110 ++--
  arch/arm/mach-omap2/gpmc-smc91x.c  |   30 +-
  arch/arm/mach-omap2/gpmc.c |  524 
 +++-
  arch/arm/mach-omap2/gpmc.h |   37 +-
  arch/arm/mach-omap2/usb-tusb6010.c |   62