date:20151015

Re: [PATCH] OMAPDSS: DISPC: Remove boolean comparisons

2015-10-15 Thread Laurent Pinchart

Hi Luis,

Thank you for the patch.

On Thursday 15 October 2015 13:29:38 Luis de Bethencourt wrote:
> Boolean tests do not need explicit comparison to true or false.
> 
> Signed-off-by: Luis de Bethencourt 

Acked-by: Laurent Pinchart 

> ---
>  drivers/video/fbdev/omap2/dss/dispc-compat.c | 6 +++---
>  drivers/video/fbdev/omap2/dss/dispc.c| 6 +++---
>  drivers/video/fbdev/omap2/dss/manager.c  | 2 +-
>  3 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/video/fbdev/omap2/dss/dispc-compat.c
> b/drivers/video/fbdev/omap2/dss/dispc-compat.c index 633c461..0918b3b
> 100644
> --- a/drivers/video/fbdev/omap2/dss/dispc-compat.c
> +++ b/drivers/video/fbdev/omap2/dss/dispc-compat.c
> @@ -476,7 +476,7 @@ static void dispc_mgr_disable_lcd_out(enum omap_channel
> channel) int r;
>   u32 irq;
> 
> - if (dispc_mgr_is_enabled(channel) == false)
> + if (!dispc_mgr_is_enabled(channel))
>   return;
> 
>   /*
> @@ -524,7 +524,7 @@ static void dispc_mgr_enable_digit_out(void)
>   int r;
>   u32 irq_mask;
> 
> - if (dispc_mgr_is_enabled(OMAP_DSS_CHANNEL_DIGIT) == true)
> + if (dispc_mgr_is_enabled(OMAP_DSS_CHANNEL_DIGIT))
>   return;
> 
>   /*
> @@ -562,7 +562,7 @@ static void dispc_mgr_disable_digit_out(void)
>   u32 irq_mask;
>   int num_irqs;
> 
> - if (dispc_mgr_is_enabled(OMAP_DSS_CHANNEL_DIGIT) == false)
> + if (!dispc_mgr_is_enabled(OMAP_DSS_CHANNEL_DIGIT))
>   return;
> 
>   /*
> diff --git a/drivers/video/fbdev/omap2/dss/dispc.c
> b/drivers/video/fbdev/omap2/dss/dispc.c index be716c9..43b0367 100644
> --- a/drivers/video/fbdev/omap2/dss/dispc.c
> +++ b/drivers/video/fbdev/omap2/dss/dispc.c
> @@ -571,7 +571,7 @@ EXPORT_SYMBOL(dispc_mgr_go_busy);
> 
>  void dispc_mgr_go(enum omap_channel channel)
>  {
> - WARN_ON(dispc_mgr_is_enabled(channel) == false);
> + WARN_ON(!dispc_mgr_is_enabled(channel));
>   WARN_ON(dispc_mgr_go_busy(channel));
> 
>   DSSDBG("GO %s\n", mgr_desc[channel].name);
> @@ -3220,7 +3220,7 @@ void dispc_mgr_set_timings(enum omap_channel channel,
> 
>   DSSDBG("hsync %luHz, vsync %luHz\n", ht, vt);
>   } else {
> - if (t.interlace == true)
> + if (t.interlace)
>   t.y_res /= 2;
>   }
> 
> @@ -3237,7 +3237,7 @@ static void dispc_mgr_set_lcd_divisor(enum
> omap_channel channel, u16 lck_div, dispc_write_reg(DISPC_DIVISORo(channel),
>   FLD_VAL(lck_div, 23, 16) | FLD_VAL(pck_div, 7, 0));
> 
> - if (dss_has_feature(FEAT_CORE_CLK_DIV) == false &&
> + if (!dss_has_feature(FEAT_CORE_CLK_DIV) &&
>   channel == OMAP_DSS_CHANNEL_LCD)
>   dispc.core_clk_rate = dispc_fclk_rate() / lck_div;
>  }
> diff --git a/drivers/video/fbdev/omap2/dss/manager.c
> b/drivers/video/fbdev/omap2/dss/manager.c index 1aac9b4..08a67f4 100644
> --- a/drivers/video/fbdev/omap2/dss/manager.c
> +++ b/drivers/video/fbdev/omap2/dss/manager.c
> @@ -210,7 +210,7 @@ static int dss_mgr_check_lcd_config(struct
> omap_overlay_manager *mgr, return -EINVAL;
> 
>   /* fifohandcheck should be used only with stallmode */
> - if (stallmode == false && fifohandcheck == true)
> + if (!stallmode && fifohandcheck)
>   return -EINVAL;
> 
>   /*

-- 
Regards,

Laurent Pinchart

--
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] OMAPDSS: DISPC: Remove boolean comparisons

2015-10-15 Thread Luis de Bethencourt

Boolean tests do not need explicit comparison to true or false.

Signed-off-by: Luis de Bethencourt 
---
 drivers/video/fbdev/omap2/dss/dispc-compat.c | 6 +++---
 drivers/video/fbdev/omap2/dss/dispc.c| 6 +++---
 drivers/video/fbdev/omap2/dss/manager.c  | 2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/video/fbdev/omap2/dss/dispc-compat.c 
b/drivers/video/fbdev/omap2/dss/dispc-compat.c
index 633c461..0918b3b 100644
--- a/drivers/video/fbdev/omap2/dss/dispc-compat.c
+++ b/drivers/video/fbdev/omap2/dss/dispc-compat.c
@@ -476,7 +476,7 @@ static void dispc_mgr_disable_lcd_out(enum omap_channel 
channel)
int r;
u32 irq;
 
-   if (dispc_mgr_is_enabled(channel) == false)
+   if (!dispc_mgr_is_enabled(channel))
return;
 
/*
@@ -524,7 +524,7 @@ static void dispc_mgr_enable_digit_out(void)
int r;
u32 irq_mask;
 
-   if (dispc_mgr_is_enabled(OMAP_DSS_CHANNEL_DIGIT) == true)
+   if (dispc_mgr_is_enabled(OMAP_DSS_CHANNEL_DIGIT))
return;
 
/*
@@ -562,7 +562,7 @@ static void dispc_mgr_disable_digit_out(void)
u32 irq_mask;
int num_irqs;
 
-   if (dispc_mgr_is_enabled(OMAP_DSS_CHANNEL_DIGIT) == false)
+   if (!dispc_mgr_is_enabled(OMAP_DSS_CHANNEL_DIGIT))
return;
 
/*
diff --git a/drivers/video/fbdev/omap2/dss/dispc.c 
b/drivers/video/fbdev/omap2/dss/dispc.c
index be716c9..43b0367 100644
--- a/drivers/video/fbdev/omap2/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/dss/dispc.c
@@ -571,7 +571,7 @@ EXPORT_SYMBOL(dispc_mgr_go_busy);
 
 void dispc_mgr_go(enum omap_channel channel)
 {
-   WARN_ON(dispc_mgr_is_enabled(channel) == false);
+   WARN_ON(!dispc_mgr_is_enabled(channel));
WARN_ON(dispc_mgr_go_busy(channel));
 
DSSDBG("GO %s\n", mgr_desc[channel].name);
@@ -3220,7 +3220,7 @@ void dispc_mgr_set_timings(enum omap_channel channel,
 
DSSDBG("hsync %luHz, vsync %luHz\n", ht, vt);
} else {
-   if (t.interlace == true)
+   if (t.interlace)
t.y_res /= 2;
}
 
@@ -3237,7 +3237,7 @@ static void dispc_mgr_set_lcd_divisor(enum omap_channel 
channel, u16 lck_div,
dispc_write_reg(DISPC_DIVISORo(channel),
FLD_VAL(lck_div, 23, 16) | FLD_VAL(pck_div, 7, 0));
 
-   if (dss_has_feature(FEAT_CORE_CLK_DIV) == false &&
+   if (!dss_has_feature(FEAT_CORE_CLK_DIV) &&
channel == OMAP_DSS_CHANNEL_LCD)
dispc.core_clk_rate = dispc_fclk_rate() / lck_div;
 }
diff --git a/drivers/video/fbdev/omap2/dss/manager.c 
b/drivers/video/fbdev/omap2/dss/manager.c
index 1aac9b4..08a67f4 100644
--- a/drivers/video/fbdev/omap2/dss/manager.c
+++ b/drivers/video/fbdev/omap2/dss/manager.c
@@ -210,7 +210,7 @@ static int dss_mgr_check_lcd_config(struct 
omap_overlay_manager *mgr,
return -EINVAL;
 
/* fifohandcheck should be used only with stallmode */
-   if (stallmode == false && fifohandcheck == true)
+   if (!stallmode && fifohandcheck)
return -EINVAL;
 
/*
-- 
2.5.1

--
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/3] ARM: OMAP2+: remove custom abort handler for t410

2015-10-15 Thread Lucas Stach

This is not needed anymore. Handling a potentially pending imprecise external
abort left behind by the bootloader is now done in a slightly safer way inside
the common ARM startup code.

Signed-off-by: Lucas Stach 
Acked-by: Tony Lindgren 
---
 arch/arm/mach-omap2/pdata-quirks.c | 29 -
 1 file changed, 29 deletions(-)

diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index ea56397599c2..3a2bc2a88db4 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -24,9 +24,6 @@
 #include 
 #include 
 
-#include 
-#include 
-
 #include "common.h"
 #include "common-board-devices.h"
 #include "dss-common.h"
@@ -385,29 +382,6 @@ static void __init omap3_pandora_legacy_init(void)
 }
 #endif /* CONFIG_ARCH_OMAP3 */
 
-#ifdef CONFIG_SOC_TI81XX
-static int fault_fixed_up;
-
-static int t410_abort_handler(unsigned long addr, unsigned int fsr,
- struct pt_regs *regs)
-{
-   if ((fsr == 0x406 || fsr == 0xc06) && !fault_fixed_up) {
-   pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x 
ignored.\n",
-   addr, fsr);
-   fault_fixed_up = 1;
-   return 0;
-   }
-
-   return 1;
-}
-
-static void __init t410_abort_init(void)
-{
-   hook_fault_code(16 + 6, t410_abort_handler, SIGBUS, BUS_OBJERR,
-   "imprecise external abort");
-}
-#endif
-
 #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
 static struct iommu_platform_data omap4_iommu_pdata = {
.reset_name = "mmu_cache",
@@ -536,9 +510,6 @@ static struct pdata_init pdata_quirks[] __initdata = {
{ "openpandora,omap3-pandora-600mhz", omap3_pandora_legacy_init, },
{ "openpandora,omap3-pandora-1ghz", omap3_pandora_legacy_init, },
 #endif
-#ifdef CONFIG_SOC_TI81XX
-   { "hp,t410", t410_abort_init, },
-#endif
 #ifdef CONFIG_SOC_OMAP5
{ "ti,omap5-uevm", omap5_uevm_legacy_init, },
 #endif
-- 
2.6.1

--
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/3] ARM: handle imprecise aborts from firmware in common code

2015-10-15 Thread Lucas Stach

This series implements the handling of a pending imprecise abort left behind
by the bootloader/firmware running before Linux in the common ARM startup code.

It turns pending imprecise aborts that may signal during the first unmasking
of such aborts on the boot CPU into a non-faulting event and warns the user
that the firmware of the machine might be buggy.

Handling this in the common code makes sure that we only ignore already pending
aborts and not those that may happen later during system boot/usage. It also
allows to remove the custom fault handler from the 3 architectures that are
known to have bad firmware/bootloaders.

V2 adapts patch 1 to suggestions from Russell and Hauke and drops former
patch 3 (ARM: mvebu: remove the workaround imprecise abort fault handler)
as it has already been applied.

Regards,
Lucas

Lucas Stach (3):
  ARM: catch pending imprecise abort on unmask
  ARM: OMAP2+: remove custom abort handler for t410
  ARM: BCM5301X: remove workaround imprecise abort fault handler

 arch/arm/mach-bcm/bcm_5301x.c  | 35 ---
 arch/arm/mach-omap2/pdata-quirks.c | 29 -
 arch/arm/mm/fault.c| 22 ++
 arch/arm/mm/fault.h|  1 +
 arch/arm/mm/mmu.c  |  3 ++-
 5 files changed, 25 insertions(+), 65 deletions(-)

-- 
2.6.1

--
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/3] ARM: BCM5301X: remove workaround imprecise abort fault handler

2015-10-15 Thread Lucas Stach

This is not needed anymore. Handling a potentially pending imprecise external
abort left behind by the bootloader is now done in a slightly safer way inside
the common ARM startup code.

Signed-off-by: Lucas Stach 
Acked-by: Hauke Mehrtens 
---
 arch/arm/mach-bcm/bcm_5301x.c | 35 ---
 1 file changed, 35 deletions(-)

diff --git a/arch/arm/mach-bcm/bcm_5301x.c b/arch/arm/mach-bcm/bcm_5301x.c
index 5478fe6bcce6..c8830a2b0d60 100644
--- a/arch/arm/mach-bcm/bcm_5301x.c
+++ b/arch/arm/mach-bcm/bcm_5301x.c
@@ -9,40 +9,6 @@
 #include 
 
 #include 
-#include 
-#include 
-
-
-static bool first_fault = true;
-
-static int bcm5301x_abort_handler(unsigned long addr, unsigned int fsr,
-struct pt_regs *regs)
-{
-   if ((fsr == 0x1406 || fsr == 0x1c06) && first_fault) {
-   first_fault = false;
-
-   /*
-* These faults with codes 0x1406 (BCM4709) or 0x1c06 happens
-* for no good reason, possibly left over from the CFE boot
-* loader.
-*/
-   pr_warn("External imprecise Data abort at addr=%#lx, fsr=%#x 
ignored.\n",
-   addr, fsr);
-
-   /* Returning non-zero causes fault display and panic */
-   return 0;
-   }
-
-   /* Others should cause a fault */
-   return 1;
-}
-
-static void __init bcm5301x_init_early(void)
-{
-   /* Install our hook */
-   hook_fault_code(16 + 6, bcm5301x_abort_handler, SIGBUS, BUS_OBJERR,
-   "imprecise external abort");
-}
 
 static const char *const bcm5301x_dt_compat[] __initconst = {
"brcm,bcm4708",
@@ -52,6 +18,5 @@ static const char *const bcm5301x_dt_compat[] __initconst = {
 DT_MACHINE_START(BCM5301X, "BCM5301X")
.l2c_aux_val= 0,
.l2c_aux_mask   = ~0,
-   .init_early = bcm5301x_init_early,
.dt_compat  = bcm5301x_dt_compat,
 MACHINE_END
-- 
2.6.1

--
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/3] ARM: catch pending imprecise abort on unmask

2015-10-15 Thread Lucas Stach

Install a non-faulting handler just before unmasking imprecise aborts
and switch back to the regular one after unmasking is done.

This catches any pending imprecise abort that the firmware/bootloader
may have left behind that would normally crash the kernel at that point.
As there are apparently a lot of bootlaoders out there that do such a
thing it makes sense to handle it in the common startup code.

Signed-off-by: Lucas Stach 
---
v2:
- move temporary fault handler swapping into fault.c to hide it from
  other parts of the kernel
- print FSR, when warning user about bad firmware/bootloader
---
 arch/arm/mm/fault.c | 22 ++
 arch/arm/mm/fault.h |  1 +
 arch/arm/mm/mmu.c   |  3 ++-
 3 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index 0d629b8f973f..daafcf121ce0 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -593,6 +593,28 @@ do_PrefetchAbort(unsigned long addr, unsigned int ifsr, 
struct pt_regs *regs)
arm_notify_die("", regs, , ifsr, 0);
 }
 
+/*
+ * Abort handler to be used only during first unmasking of asynchronous aborts
+ * on the boot CPU. This makes sure that the machine will not die if the
+ * firmware/bootloader left an imprecise abort pending for us to trip over.
+ */
+static int __init early_abort_handler(unsigned long addr, unsigned int fsr,
+ struct pt_regs *regs)
+{
+   pr_warn("Hit pending asynchronous external abort (FSR=0x%08x) during "
+   "first unmask, this is most likely caused by a "
+   "firmware/bootloader bug.\n", fsr);
+
+   return 0;
+}
+
+void __init early_abt_enable(void)
+{
+   fsr_info[22].fn = early_abort_handler;
+   local_abt_enable();
+   fsr_info[22].fn = do_bad;
+}
+
 #ifndef CONFIG_ARM_LPAE
 static int __init exceptions_init(void)
 {
diff --git a/arch/arm/mm/fault.h b/arch/arm/mm/fault.h
index cf08bdfbe0d6..05ec5e0df32d 100644
--- a/arch/arm/mm/fault.h
+++ b/arch/arm/mm/fault.h
@@ -24,5 +24,6 @@ static inline int fsr_fs(unsigned int fsr)
 
 void do_bad_area(unsigned long addr, unsigned int fsr, struct pt_regs *regs);
 unsigned long search_exception_table(unsigned long addr);
+void early_abt_enable(void);
 
 #endif /* __ARCH_ARM_FAULT_H */
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index f65a6f344b6d..4867f5daf82c 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 
+#include "fault.h"
 #include "mm.h"
 #include "tcm.h"
 
@@ -1365,7 +1366,7 @@ static void __init devicemaps_init(const struct 
machine_desc *mdesc)
flush_cache_all();
 
/* Enable asynchronous aborts */
-   local_abt_enable();
+   early_abt_enable();
 }
 
 static void __init kmap_init(void)
-- 
2.6.1

--
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/4] ARM: mvebu: remove the workaround imprecise abort fault handler

2015-10-15 Thread Gregory CLEMENT

Hi Lucas,
 
 On mer., oct. 14 2015, Thomas Petazzoni  
wrote:

> Lucas,
>
> On Wed, 14 Oct 2015 16:48:32 +0200, Lucas Stach wrote:
>> This is not needed anymore. Handling a potentially pending imprecise external
>> abort left behind by the bootloader is now done in a slightly safer way 
>> inside
>> the common ARM startup code.
>> 
>> Signed-off-by: Lucas Stach 

As pointed by Thomas the code is no longer needed. So even if the rest
of tour series is not merged, I still applied on mvebu/cleanup.

I also amended the commit log to emphasize that the Armada 375 Z1 was
not support anymore.

Thanks,

Gregory

>> ---
>>  arch/arm/mach-mvebu/board-v7.c | 35 ---
>>  1 file changed, 35 deletions(-)
>
> Reviewed-by: Thomas Petazzoni 
>
> In fact this code is anyway no longer needed, since this workaround was
> only needed for the Armada 375 Z1 stepping, which we no longer support
> in mainline anyway.
>
> Thanks!
>
> Thomas
> -- 
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
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 v5 00/24] dmaengine/ARM: Merge the edma drivers into one

2015-10-15 Thread Peter Ujfalusi

On 10/14/2015 05:31 PM, Vinod Koul wrote:
> On Wed, Oct 14, 2015 at 02:42:42PM +0300, Peter Ujfalusi wrote:
>> Hi,
>>
>> Cover letter:
>>
>> with this series the edma two driver setup will be changed to have only one
>> driver to support eDMA3. The legacy edma interface will be removed and eDMA 
>> can
>> only be used via dmaengine API from this point on.
>> In order to do the merge the following improvements has been done:
>> - One driver instance per eDMA:
>>  - Any number of eDMA instances are supported (both legacy and DT boot)
>> - Not relying on global variables, arrays, etc
>> - Code simplification and optimizations in several places
>>
>> This change will also help us to do bigger changes in the eDMA driver since,
>> since now we have only one driver to work with.
> 
> I have applied this now. I got a conlfict on 3rd one while applying and also
> I got conflict while merging to next
> 
> Pls verify all is well!

Thanks Vinod,

It looks fine.
It is strange since I'm working on top of linux-next as well. The following
commit caused the conflict:
ddfe4d0cce78 dmaengine: edma: remove redundant conditions

I have it in my linux-next, but for some reason it is missing from your
topic/edma, so the series applied with conflicts there and when merging on top
of linux-next there were again conflict.

Thank you,
Péter
--
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] twl4030_charger: add missing iio dependency

2015-10-15 Thread Sebastian Reichel

This driver fails to link without CONFIG_IIO, since
there are no stubs for the iio_channels functions.

Signed-off-by: Sebastian Reichel 
---
 drivers/power/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 9e68853217ca..cb0ae666dc68 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -313,7 +313,7 @@ config CHARGER_MAX8903
 
 config CHARGER_TWL4030
tristate "OMAP TWL4030 BCI charger driver"
-   depends on TWL4030_CORE
+   depends on IIO && TWL4030_CORE
help
  Say Y here to enable support for TWL4030 Battery Charge Interface.
 
-- 
2.6.1

--
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 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

2015-10-15 Thread Roger Quadros

On 14/10/15 23:03, Franklin S Cooper Jr. wrote:
> 
> 
> On 10/14/2015 01:13 PM, Tony Lindgren wrote:
>> * Franklin S Cooper Jr.  [151014 09:27]:
>>>
>>> On 10/14/2015 11:18 AM, Tony Lindgren wrote:
 * Franklin S Cooper Jr.  [151014 07:37]:
> On 10/14/2015 09:11 AM, Roger Quadros wrote:
>> On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
>>> On 10/14/2015 06:52 AM, Roger Quadros wrote:
 Franklin,

 On 14/10/15 14:36, Roger Quadros wrote:
> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>> Switch from dma_request_channel to allow passing dma channel
>> information from DT rather than hardcoding a value.
>>
>> Signed-off-by: Franklin S Cooper Jr 
> Acked-by: Roger Quadros 
>
>> ---
>>  drivers/mtd/nand/omap2.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>> index d0f2620..957c32f 100644
>> --- a/drivers/mtd/nand/omap2.c
>> +++ b/drivers/mtd/nand/omap2.c
>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct 
>> platform_device *pdev)
>>  dma_cap_zero(mask);
>>  dma_cap_set(DMA_SLAVE, mask);
>>  sig = OMAP24XX_DMA_GPMC;
>> -info->dma = dma_request_channel(mask, 
>> omap_dma_filter_fn, );
>> +info->dma = dma_request_slave_channel_compat(mask,
>> +omap_dma_filter_fn, , pdev->dev.parent, 
>> "rxtx");
>> +
 Just discovered that you are using the parent device node.

 How about moving the dma bindings to the nand node instead and using
 pdev->dev here?
>>> Roger,
>>>
>>> From what I can tell the interrupt number and the dma channel will 
>>> always be
>>> the same no matter what. Doesn't matter if you have multiple nands or a
>>> combination of nands and nors. Since that is the case I think it just 
>>> makes
>>> sense to leave it in the gpmc parent node and define it once.
>> Is prefetch/writepost dma used for NOR or any other GPMC peripheral
>> or only for NAND?
> The dma seems tied to the prefetch. From what I can tell the prefetch is 
> only
> used by nand.
>> Let's also get Tony's inputs on this.
> Sure.
 Hmm so what would keep other devices from using the prefetch
>>> Looking at the TRM any references to the prefetch are always with respect to
>>> NAND.
>>>
>>> I also see the below mentioned in the TRM.
>>> Pre-fetch and write posting engine associated with system DMA to get full 
>>> performance from NAND
>>> device with minimum impact on NOR/SRAM concurrent access.
>> OK up to you guys to figure out if it may be usable in a generic way then :)
> Ok I just got clarification from hw folks. DMA for GPMC can be used for any 
> of the
> various modes. But the prefetch is specific to NAND.

In that case the dma information must be in the GPMC node.

cheers,
-roger
--
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] ARM: DRA7: hwmod: Remove elm address space from hwmod data

2015-10-15 Thread Paul Walmsley

On Wed, 14 Oct 2015, Franklin S Cooper Jr. wrote:

> 
> 
> On 10/14/2015 01:58 AM, Roger Quadros wrote:
> > On 13/10/15 16:44, Franklin S Cooper Jr wrote:
> >> ELM address information is provided by device tree. No longer need
> >> to include this information within hwmod.
> >>
> >> Signed-off-by: Franklin S Cooper Jr 
> > Acked-by: Roger Quadros 
> >
> > Franklin,
> >
> > Can you please do the same for gpmc_addr as well?
> >
> > And looks like elm_addr needs to be removed from
> > omap_hwmod_33xx_43xx_interconnect_data.c and omap_hwmod_44xx_data.c as 
> > well, no?
> Sure I'll combine the 335x and 44x elm removal with this patch and then 
> create a separate patch for the gpmc version.

OK, holding off on this until you update the patch.


- 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 00/11] ARM: OMAP/DTS: dra7/72-evm/beagle-x15: Audio support

2015-10-15 Thread Peter Ujfalusi

Tony,

On 10/12/2015 11:57 PM, Tony Lindgren wrote:
> * Tony Lindgren  [150914 09:32]:
>> * Peter Ujfalusi  [150914 01:54]:
>>> Hi Tony,
>>>
>>> On 08/24/2015 10:19 AM, Peter Ujfalusi wrote:
 Hi,

 this series will enable analog audio (via onboard aic310x codec) for 
 dra7-evm,
 dra72-evm and am57xx-beagle-x15 boards.
 In these board McASP3 is connected to the codec and for the McASP3 we 
 needed to
 have the DMA crossbar in place since the request lines are not mapped by
 default.
>>>
>>> Did you had a chance to look at this series?
>>
>> Looks OK to me, will look at it more once we have the fixes merged.
>>
>> Paul may have comments on the hwmod chage, looks like you forgot
>> to Cc him on it. Can you please resend that one with Paul in Cc?
> 
> Applying all the dts changes into omap-for-v4.3/dt thanks. Paul
> can pick up the hwmod change then after reviewing it.

Thanks for taking the DTS patches, however if Paul agrees with the way I think 
we can handle the McASP in DRA7xx then the patch which adds the mcasp3 node to 
dra7.dtsi needs to be replaced by:

>From b6733f9ca96a997fab3d0455783e875dd9ae032b Mon Sep 17 00:00:00 2001
From: Peter Ujfalusi 
Date: Tue, 24 Feb 2015 15:12:59 +0200
Subject: [PATCH v2 03/12] ARM: DTS: dra7: Add McASP3 node

Signed-off-by: Peter Ujfalusi 
---
 arch/arm/boot/dts/dra7.dtsi | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 8fedddc35999..cde0a3cbf262 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1404,6 +1404,21 @@
status = "disabled";
};
 
+   mcasp3: mcasp@48468000 {
+   compatible = "ti,dra7-mcasp-audio";
+   ti,hwmods = "mcasp3";
+   reg = <0x48468000 0x2000>;
+   reg-names = "mpu";
+   interrupts = ,
+;
+   interrupt-names = "tx", "rx";
+   dmas = <_xbar 133>, <_xbar 132>;
+   dma-names = "tx", "rx";
+   clocks = <_aux_gfclk_mux>, <_ahclkx_mux>;
+   clock-names = "fck", "ahclkx";
+   status = "disabled";
+   };
+
crossbar_mpu: crossbar@4a002a48 {
compatible = "ti,irq-crossbar";
reg = <0x4a002a48 0x130>;
-- 
2.6.1




-- 
Péter
--
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 1/4] ARM: catch pending imprecise abort on unmask

2015-10-15 Thread Russell King - ARM Linux

On Wed, Oct 14, 2015 at 04:48:30PM +0200, Lucas Stach wrote:
> Install a non-faulting handler just before unmasking imprecise aborts
> and switch back to the regular one after unmasking is done.
> 
> This catches any pending imprecise abort that the firmware/bootloader
> may have left behind that would normally crash the kernel at that point.
> As there are apparently a lot of bootlaoders out there that do such a
> thing it makes sense to handle it in the common startup code.
> 
> Signed-off-by: Lucas Stach 
> ---
>  arch/arm/mm/fault.c | 15 +++
>  arch/arm/mm/fault.h |  2 ++
>  arch/arm/mm/mmu.c   | 19 ++-
>  3 files changed, 35 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
> index 0d629b8f973f..519f694ec9db 100644
> --- a/arch/arm/mm/fault.c
> +++ b/arch/arm/mm/fault.c
> @@ -538,6 +538,21 @@ hook_fault_code(int nr, int (*fn)(unsigned long, 
> unsigned int, struct pt_regs *)
>   fsr_info[nr].name = name;
>  }
>  
> +void * __init
> +swap_fault_function(int nr,
> + int (*fn)(unsigned long, unsigned int, struct pt_regs *))
> +{
> + void *old_fn;
> +
> + if (nr < 0 || nr >= ARRAY_SIZE(fsr_info))
> + BUG();
> +
> + old_fn = fsr_info[nr].fn;
> + fsr_info[nr].fn = fn;
> +
> + return old_fn;
> +}
> +

Please move the abort enable and handler into fault.c - I don't want this
exposed to the rest of the kernel as people will get the impression that
they can make use of this, even though it's not in arch/arm/include/, as
a way to hook and then subsequently unhook a handler.

Thanks.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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] twl4030_charger: add missing iio dependency

2015-10-15 Thread Belisko Marek

Hi,

On Thu, Oct 15, 2015 at 11:11 AM, Sebastian Reichel  wrote:
> This driver fails to link without CONFIG_IIO, since
> there are no stubs for the iio_channels functions.
>
> Signed-off-by: Sebastian Reichel 
> ---
>  drivers/power/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index 9e68853217ca..cb0ae666dc68 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -313,7 +313,7 @@ config CHARGER_MAX8903
>
>  config CHARGER_TWL4030
> tristate "OMAP TWL4030 BCI charger driver"
> -   depends on TWL4030_CORE
> +   depends on IIO && TWL4030_CORE
> help
>   Say Y here to enable support for TWL4030 Battery Charge Interface.
>
> --
> 2.6.1
>
Acked-by: Marek Belisko 

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.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] twl4030_charger: add missing iio dependency

2015-10-15 Thread H. Nikolaus Schaller

Acked-by: Nikolaus Schaller 

BR,
Nikolaus

Am 15.10.2015 um 11:11 schrieb Sebastian Reichel :

> This driver fails to link without CONFIG_IIO, since
> there are no stubs for the iio_channels functions.
> 
> Signed-off-by: Sebastian Reichel 
> ---
> drivers/power/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index 9e68853217ca..cb0ae666dc68 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -313,7 +313,7 @@ config CHARGER_MAX8903
> 
> config CHARGER_TWL4030
>   tristate "OMAP TWL4030 BCI charger driver"
> - depends on TWL4030_CORE
> + depends on IIO && TWL4030_CORE
>   help
> Say Y here to enable support for TWL4030 Battery Charge Interface.
> 
> -- 
> 2.6.1
> 

--
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] ARM: OMAP2+: Fix oops with LPAE and more than 2GB of memory

2015-10-15 Thread Lokesh Vutla

Hi Tony,

On Wednesday 14 October 2015 09:32 PM, Tony Lindgren wrote:
> * Lokesh Vutla  [151013 20:53]:
>> Hi Tony,
>>
>> On Wednesday 14 October 2015 04:43 AM, Tony Lindgren wrote:
>>> On boards with more than 2GB of RAM booting goes wrong with things not 
>>> working
>>> and we're getting lots of l3 warnings:
>>>
>>> WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147 
>>> l3_interrupt_handler+0x260/0x384()
>>> 4400.ocp:L3 Custom Error: MASTER MMC6 TARGET DMM1 (Idle): Data Access 
>>> in User mode during Functional access
>>> ...
>>> [] (scsi_add_host_with_dma) from [] 
>>> (ata_scsi_add_hosts+0x5c/0x18c)
>>> [] (ata_scsi_add_hosts) from [] 
>>> (ata_host_register+0x150/0x2cc)
>>> [] (ata_host_register) from [] 
>>> (ata_host_activate+0xd4/0x124)
>>> [] (ata_host_activate) from [] 
>>> (ahci_host_activate+0x5c/0x194)
>>> [] (ahci_host_activate) from [] 
>>> (ahci_platform_init_host+0x1f0/0x3f0)
>>> [] (ahci_platform_init_host) from [] 
>>> (ahci_probe+0x70/0x98)
>>> [] (ahci_probe) from [] (platform_drv_probe+0x54/0xb4)
>>>
>>> Let's fix the issue by enabling ZONE_DMA for LPAE.
>>
>> May I know on which platform you have reproduced this?
> 
> This is on the 4GB version of isee igepv5 GEP0050-RB10
> 
> https://isee.biz/products/igep-processor-boards/igepv5-omap5432
> 
>> Just wondering what other changes you made for booting a OMAP5+ based
>> board with more than 2GB.
> 
> Just the minimal dts changes I posted yesterday to use shared dtsi file
> for omap5-uevm variants. Then boot with something like this in the kernel
> cmdline:
> 
> mem=2032M@0x8000 mem=2048M@0x3
Is it the upper 2GB memory starts from 0x3__? Looking at the
Table 4-4. "AXI Access memory map" in TRM, it tells it starts from
0x2__.(or am I missing something?)

Any chance you tried doing memtest for all this memory?

IIUC, It is not allowed to use the mix of L3 address mapping and MA
physical address mapping. TRM specifies that
"It is expected that the OS uses either the lower 2-GiB space and the
lower aliased address of emif(a) and (b), or the continuous 8-GiB space
and the upper aliasing of the emif(a) and (b) for all EMIF accesses."

I tried a similar 4GB setup and observed few stuff:
- Need to have ARM_PV_FIXUP enabled something similar that is done in
Keystone inorder to shift to higher address space.[1] [2]
- All the peripherals other than MPU, can access only 2GB. So we need to
restrict the DMA and need an addresses translation. Along with this
patch [3] [4] are needed.

[1]
https://git.ti.com/~lokesh/ti-linux-kernel/lokesh-ti-linux-kernel/commit/be7d2d7e18f473e6078cd7c0b25ec3c58f40736b
[2]
https://git.ti.com/~lokesh/ti-linux-kernel/lokesh-ti-linux-kernel/commit/dd0a564ee565405bec5e9f58f0c97fb6714110ac
[3]
https://git.ti.com/~lokesh/ti-linux-kernel/lokesh-ti-linux-kernel/commit/985ed401e04926cb88b23646271dc96900abc50d
[4]
https://git.ti.com/~lokesh/ti-linux-kernel/lokesh-ti-linux-kernel/commit/c1f7568c4cc6f3146b7137783bd403967aabd0d8

Please correct me if I am wrong.

Thanks and regards,
Lokesh
--
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] ARM: OMAP2+: Fix oops with LPAE and more than 2GB of memory

2015-10-15 Thread Tony Lindgren

* Lokesh Vutla  [151015 01:02]:
> Hi Tony,
> 
> On Wednesday 14 October 2015 09:32 PM, Tony Lindgren wrote:
> > * Lokesh Vutla  [151013 20:53]:
> >> Hi Tony,
> >>
> >> On Wednesday 14 October 2015 04:43 AM, Tony Lindgren wrote:
> >>> On boards with more than 2GB of RAM booting goes wrong with things not 
> >>> working
> >>> and we're getting lots of l3 warnings:
> >>>
> >>> WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147 
> >>> l3_interrupt_handler+0x260/0x384()
> >>> 4400.ocp:L3 Custom Error: MASTER MMC6 TARGET DMM1 (Idle): Data Access 
> >>> in User mode during Functional access
> >>> ...
> >>> [] (scsi_add_host_with_dma) from [] 
> >>> (ata_scsi_add_hosts+0x5c/0x18c)
> >>> [] (ata_scsi_add_hosts) from [] 
> >>> (ata_host_register+0x150/0x2cc)
> >>> [] (ata_host_register) from [] 
> >>> (ata_host_activate+0xd4/0x124)
> >>> [] (ata_host_activate) from [] 
> >>> (ahci_host_activate+0x5c/0x194)
> >>> [] (ahci_host_activate) from [] 
> >>> (ahci_platform_init_host+0x1f0/0x3f0)
> >>> [] (ahci_platform_init_host) from [] 
> >>> (ahci_probe+0x70/0x98)
> >>> [] (ahci_probe) from [] (platform_drv_probe+0x54/0xb4)
> >>>
> >>> Let's fix the issue by enabling ZONE_DMA for LPAE.
> >>
> >> May I know on which platform you have reproduced this?
> > 
> > This is on the 4GB version of isee igepv5 GEP0050-RB10
> > 
> > https://isee.biz/products/igep-processor-boards/igepv5-omap5432
> > 
> >> Just wondering what other changes you made for booting a OMAP5+ based
> >> board with more than 2GB.
> > 
> > Just the minimal dts changes I posted yesterday to use shared dtsi file
> > for omap5-uevm variants. Then boot with something like this in the kernel
> > cmdline:
> > 
> > mem=2032M@0x8000 mem=2048M@0x3
> Is it the upper 2GB memory starts from 0x3__? Looking at the
> Table 4-4. "AXI Access memory map" in TRM, it tells it starts from
> 0x2__.(or am I missing something?)
> 
> Any chance you tried doing memtest for all this memory?

Seems to work just fine, it's been up since I posted $subject patch., I tried
a kernel compile on it already earlier and just started memtester 3900M which
seems to only capable of testing 2924MB though.

> IIUC, It is not allowed to use the mix of L3 address mapping and MA
> physical address mapping. TRM specifies that
> "It is expected that the OS uses either the lower 2-GiB space and the
> lower aliased address of emif(a) and (b), or the continuous 8-GiB space
> and the upper aliasing of the emif(a) and (b) for all EMIF accesses."

I think that depends on the chip selects that can be used. The above
is probably for the case where all 8GB was to be used.

> I tried a similar 4GB setup and observed few stuff:
> - Need to have ARM_PV_FIXUP enabled something similar that is done in
> Keystone inorder to shift to higher address space.[1] [2]

Seems that's optional for 4GB.. But probably a must for 8GB :)

> - All the peripherals other than MPU, can access only 2GB. So we need to
> restrict the DMA and need an addresses translation. Along with this
> patch [3] [4] are needed.

Yes there's no memory accessible beyond 2GB for the DMA hardware. I'll
post an updated patch with the 2GB limit for dma_zone_size after some
more tests.

For the dma-ranges, looks like I have not hit that one yet. Which drivers
did you run into problems without that?

Regards,

Tony

> [1]
> https://git.ti.com/~lokesh/ti-linux-kernel/lokesh-ti-linux-kernel/commit/be7d2d7e18f473e6078cd7c0b25ec3c58f40736b
> [2]
> https://git.ti.com/~lokesh/ti-linux-kernel/lokesh-ti-linux-kernel/commit/dd0a564ee565405bec5e9f58f0c97fb6714110ac
> [3]
> https://git.ti.com/~lokesh/ti-linux-kernel/lokesh-ti-linux-kernel/commit/985ed401e04926cb88b23646271dc96900abc50d
> [4]
> https://git.ti.com/~lokesh/ti-linux-kernel/lokesh-ti-linux-kernel/commit/c1f7568c4cc6f3146b7137783bd403967aabd0d8

--
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/11] ARM: OMAP/DTS: dra7/72-evm/beagle-x15: Audio support

2015-10-15 Thread Tony Lindgren

* Peter Ujfalusi  [151015 00:13]:
> Tony,
> 
> On 10/12/2015 11:57 PM, Tony Lindgren wrote:
> > * Tony Lindgren  [150914 09:32]:
> >> * Peter Ujfalusi  [150914 01:54]:
> >>> Hi Tony,
> >>>
> >>> On 08/24/2015 10:19 AM, Peter Ujfalusi wrote:
>  Hi,
> 
>  this series will enable analog audio (via onboard aic310x codec) for 
>  dra7-evm,
>  dra72-evm and am57xx-beagle-x15 boards.
>  In these board McASP3 is connected to the codec and for the McASP3 we 
>  needed to
>  have the DMA crossbar in place since the request lines are not mapped by
>  default.
> >>>
> >>> Did you had a chance to look at this series?
> >>
> >> Looks OK to me, will look at it more once we have the fixes merged.
> >>
> >> Paul may have comments on the hwmod chage, looks like you forgot
> >> to Cc him on it. Can you please resend that one with Paul in Cc?
> > 
> > Applying all the dts changes into omap-for-v4.3/dt thanks. Paul
> > can pick up the hwmod change then after reviewing it.
> 
> Thanks for taking the DTS patches, however if Paul agrees with the way I 
> think we can handle the McASP in DRA7xx then the patch which adds the mcasp3 
> node to dra7.dtsi needs to be replaced by:

Oh OK so the clocks may change. Well please send a follow up patch on
that then.

BTW, we should not set status = "disabled" in the SoC specific dtsi files.
The internal devices are there and we're better off having a struct device
created for them. If someobdy really wants to "disable" some internal device
for yet to be seen good reason, it should be done in the board specific dts
file.

Regards,

Tony

> From b6733f9ca96a997fab3d0455783e875dd9ae032b Mon Sep 17 00:00:00 2001
> From: Peter Ujfalusi 
> Date: Tue, 24 Feb 2015 15:12:59 +0200
> Subject: [PATCH v2 03/12] ARM: DTS: dra7: Add McASP3 node
> 
> Signed-off-by: Peter Ujfalusi 
> ---
>  arch/arm/boot/dts/dra7.dtsi | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index 8fedddc35999..cde0a3cbf262 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -1404,6 +1404,21 @@
>   status = "disabled";
>   };
>  
> + mcasp3: mcasp@48468000 {
> + compatible = "ti,dra7-mcasp-audio";
> + ti,hwmods = "mcasp3";
> + reg = <0x48468000 0x2000>;
> + reg-names = "mpu";
> + interrupts = ,
> +  ;
> + interrupt-names = "tx", "rx";
> + dmas = <_xbar 133>, <_xbar 132>;
> + dma-names = "tx", "rx";
> + clocks = <_aux_gfclk_mux>, <_ahclkx_mux>;
> + clock-names = "fck", "ahclkx";
> + status = "disabled";
> + };
> +
>   crossbar_mpu: crossbar@4a002a48 {
>   compatible = "ti,irq-crossbar";
>   reg = <0x4a002a48 0x130>;
> -- 
> 2.6.1
> 
> 
> 
> 
> -- 
> Péter
--
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: [GIT PULL] omap fixes against v4.3-rc5

2015-10-15 Thread Arnd Bergmann

On Wednesday 14 October 2015 13:03:36 Tony Lindgren wrote:
> Fixes for omap against v4.3-rc5:
> 
> - Regulator fix for beagle-x15 to fix HDMI without a SD card being
>   inserted
> 
> - GPMC fix for showing proper timings and to allow enabling debug
>   options that somehow was unselectable earlier
> 
> - Add minimal documentation for new MMC1 dependency on
>   REGULATOR_PBIAS as it may not be obvious for people with
>   targeted .config files
> 

Pulled into fixes, thanks!

Arnd
--
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] ARM: OMAP2+: Fix oops with LPAE and more than 2GB of memory

2015-10-15 Thread Lokesh Vutla

+Richard

On Thursday 15 October 2015 07:35 PM, Tony Lindgren wrote:
> * Lokesh Vutla  [151015 01:02]:
>> Hi Tony,
>>
>> On Wednesday 14 October 2015 09:32 PM, Tony Lindgren wrote:
>>> * Lokesh Vutla  [151013 20:53]:
 Hi Tony,

 On Wednesday 14 October 2015 04:43 AM, Tony Lindgren wrote:
> On boards with more than 2GB of RAM booting goes wrong with things not 
> working
> and we're getting lots of l3 warnings:
>
> WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147 
> l3_interrupt_handler+0x260/0x384()
> 4400.ocp:L3 Custom Error: MASTER MMC6 TARGET DMM1 (Idle): Data Access 
> in User mode during Functional access
> ...
> [] (scsi_add_host_with_dma) from [] 
> (ata_scsi_add_hosts+0x5c/0x18c)
> [] (ata_scsi_add_hosts) from [] 
> (ata_host_register+0x150/0x2cc)
> [] (ata_host_register) from [] 
> (ata_host_activate+0xd4/0x124)
> [] (ata_host_activate) from [] 
> (ahci_host_activate+0x5c/0x194)
> [] (ahci_host_activate) from [] 
> (ahci_platform_init_host+0x1f0/0x3f0)
> [] (ahci_platform_init_host) from [] 
> (ahci_probe+0x70/0x98)
> [] (ahci_probe) from [] (platform_drv_probe+0x54/0xb4)
>
> Let's fix the issue by enabling ZONE_DMA for LPAE.

 May I know on which platform you have reproduced this?
>>>
>>> This is on the 4GB version of isee igepv5 GEP0050-RB10
>>>
>>> https://isee.biz/products/igep-processor-boards/igepv5-omap5432
>>>
 Just wondering what other changes you made for booting a OMAP5+ based
 board with more than 2GB.
>>>
>>> Just the minimal dts changes I posted yesterday to use shared dtsi file
>>> for omap5-uevm variants. Then boot with something like this in the kernel
>>> cmdline:
>>>
>>> mem=2032M@0x8000 mem=2048M@0x3
>> Is it the upper 2GB memory starts from 0x3__? Looking at the
>> Table 4-4. "AXI Access memory map" in TRM, it tells it starts from
>> 0x2__.(or am I missing something?)
>>
>> Any chance you tried doing memtest for all this memory?
> 
> Seems to work just fine, it's been up since I posted $subject patch., I tried
> a kernel compile on it already earlier and just started memtester 3900M which
> seems to only capable of testing 2924MB though.
> 
>> IIUC, It is not allowed to use the mix of L3 address mapping and MA
>> physical address mapping. TRM specifies that
>> "It is expected that the OS uses either the lower 2-GiB space and the
>> lower aliased address of emif(a) and (b), or the continuous 8-GiB space
>> and the upper aliasing of the emif(a) and (b) for all EMIF accesses."
> 
> I think that depends on the chip selects that can be used. The above
> is probably for the case where all 8GB was to be used.

Richard, Do you agree with this?

> 
>> I tried a similar 4GB setup and observed few stuff:
>> - Need to have ARM_PV_FIXUP enabled something similar that is done in
>> Keystone inorder to shift to higher address space.[1] [2]
> 
> Seems that's optional for 4GB.. But probably a must for 8GB :)
> 
>> - All the peripherals other than MPU, can access only 2GB. So we need to
>> restrict the DMA and need an addresses translation. Along with this
>> patch [3] [4] are needed.
> 
> Yes there's no memory accessible beyond 2GB for the DMA hardware. I'll
> post an updated patch with the 2GB limit for dma_zone_size after some
> more tests.
> 
> For the dma-ranges, looks like I have not hit that one yet. Which drivers
> did you run into problems without that?

This is needed only when you completely shift to higher address space.

> 
> Regards,
> 
> Tony
> 
>> [1]
>> https://git.ti.com/~lokesh/ti-linux-kernel/lokesh-ti-linux-kernel/commit/be7d2d7e18f473e6078cd7c0b25ec3c58f40736b
>> [2]
>> https://git.ti.com/~lokesh/ti-linux-kernel/lokesh-ti-linux-kernel/commit/dd0a564ee565405bec5e9f58f0c97fb6714110ac
>> [3]
>> https://git.ti.com/~lokesh/ti-linux-kernel/lokesh-ti-linux-kernel/commit/985ed401e04926cb88b23646271dc96900abc50d
>> [4]
>> https://git.ti.com/~lokesh/ti-linux-kernel/lokesh-ti-linux-kernel/commit/c1f7568c4cc6f3146b7137783bd403967aabd0d8
> 
--
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 v2 1/3] ARM: catch pending imprecise abort on unmask

2015-10-15 Thread Russell King - ARM Linux

On Thu, Oct 15, 2015 at 12:32:20PM +0200, Lucas Stach wrote:
> Install a non-faulting handler just before unmasking imprecise aborts
> and switch back to the regular one after unmasking is done.
> 
> This catches any pending imprecise abort that the firmware/bootloader
> may have left behind that would normally crash the kernel at that point.
> As there are apparently a lot of bootlaoders out there that do such a
> thing it makes sense to handle it in the common startup code.
> 
> Signed-off-by: Lucas Stach 

Much better.  Please feel free to add it to the patch system, thanks.

I think, given that the original seems to be breaking platforms, this
patch needs to go into -rc kernels, right?

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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 v2 1/3] ARM: catch pending imprecise abort on unmask

2015-10-15 Thread Tony Lindgren

* Russell King - ARM Linux  [151015 08:37]:
> On Thu, Oct 15, 2015 at 12:32:20PM +0200, Lucas Stach wrote:
> > Install a non-faulting handler just before unmasking imprecise aborts
> > and switch back to the regular one after unmasking is done.
> > 
> > This catches any pending imprecise abort that the firmware/bootloader
> > may have left behind that would normally crash the kernel at that point.
> > As there are apparently a lot of bootlaoders out there that do such a
> > thing it makes sense to handle it in the common startup code.
> > 
> > Signed-off-by: Lucas Stach 
> 
> Much better.  Please feel free to add it to the patch system, thanks.
> 
> I think, given that the original seems to be breaking platforms, this
> patch needs to go into -rc kernels, right?

Hmm do we still see a trace where the issue happened though with this
one?

What I though wes something pending from the bootloader, turned out
to be a bogus SRAM init code that I was able to easily fix with the
trace.

Regards,

Tony
--
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 v2 1/3] ARM: catch pending imprecise abort on unmask

2015-10-15 Thread Russell King - ARM Linux

On Thu, Oct 15, 2015 at 08:39:15AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux  [151015 08:37]:
> > On Thu, Oct 15, 2015 at 12:32:20PM +0200, Lucas Stach wrote:
> > > Install a non-faulting handler just before unmasking imprecise aborts
> > > and switch back to the regular one after unmasking is done.
> > > 
> > > This catches any pending imprecise abort that the firmware/bootloader
> > > may have left behind that would normally crash the kernel at that point.
> > > As there are apparently a lot of bootlaoders out there that do such a
> > > thing it makes sense to handle it in the common startup code.
> > > 
> > > Signed-off-by: Lucas Stach 
> > 
> > Much better.  Please feel free to add it to the patch system, thanks.
> > 
> > I think, given that the original seems to be breaking platforms, this
> > patch needs to go into -rc kernels, right?
> 
> Hmm do we still see a trace where the issue happened though with this
> one?

That's not the intention of this specific patch.

This is solely to detect the bootloader induced imprecise exception,
nothing more.  A backtrace for that won't be useful in any shape or
form - in fact, the backtrace will be well known (it'll be from the
site where the imprecise exceptions are unmasked.)

Any imprecise exception which happens after this will be handled in
the normal way: it'll raise a kernel oops, and that will have all the
details that a kernel oops normally has.

The difference is, rather than the boot loader provoking the kernel to
oops at this point, we're able to report the event and continue on.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
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: [GIT PULL 2/2] omap device tree changes for v4.4

2015-10-15 Thread Arnd Bergmann

On Wednesday 14 October 2015 14:38:59 Tony Lindgren wrote:
> Device tree changes for omaps for v4.4 merge window:
> 
> - DCAN sleep pins for am437x-gp-evm
> 
> - A series of changes to add audio support for dra7
> 
> - Add support for gpio keys and LEDs on dra7
> 
> - Regulator clean-up for am335x-wega
> 
> - A series of changes to enable IOMMUs and mailboxes for dra7
>   accelerators
> 
> - Add support for am335x-bonegreen
> 
> - Fix up GPIO flags where 0 was used instead of GPIO_ACTIVE_HIGH
> 
> - Fix omap3-lilly-am33x IRQ level flag
> 
> - Remove duplicate uart2 pinmux for igep and fix indentation and
>   update igep to use pinctrl macros for the register offsets
> 
> - Fix MMC cd-gpios usage

Pulled into next/dt, thanks!

> Note that this branch is against v4.3-rc4 as that contains critical
> MMC related fixes to boot with MMC working on most omaps.

While we are lucky this time as I based the branch on -rc4 anyway,
a nicer way to do this would be to ensure that a fix you want
to base on is based an older -rc, and then you base your own branch
on top of that fix, to minimize the number of back-merged patches.

Arnd

--
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: [GIT PULL 1/2] omap clean-up for v4.4

2015-10-15 Thread Arnd Bergmann

On Wednesday 14 October 2015 14:38:58 Tony Lindgren wrote:
> Clean-up for omaps for v4.4 merge window:
> 
> - Remove legacy omap3 ISP code as the driver is DT only
> 
> - Remove VoiceBlue board support as it's been unused over
>   10 years now
> 
> - Remove unused polarity control macros for TWL
> 
> - Remove two unneeded semicolons
> 
> - Remove unused core dpll code for reprogramming the rates

Nice!
 
> Note that this branch is against v4.3-rc4 as that contains critical
> MMC related fixes to boot with MMC working on most omaps.

That is fine, we had a late start and everything is based on -rc4 this
time.

Applied to next/cleanup.

Arnd
--
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: [GIT PULL 2/2] omap device tree changes for v4.4

2015-10-15 Thread Tony Lindgren

* Arnd Bergmann  [151015 13:40]:
> On Wednesday 14 October 2015 14:38:59 Tony Lindgren wrote:
> 
> > Note that this branch is against v4.3-rc4 as that contains critical
> > MMC related fixes to boot with MMC working on most omaps.
> 
> While we are lucky this time as I based the branch on -rc4 anyway,
> a nicer way to do this would be to ensure that a fix you want
> to base on is based an older -rc, and then you base your own branch
> on top of that fix, to minimize the number of back-merged patches.

Sure that would be doable too at the cost of a few extra merges.

Regards,

Tony
--
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 v2 1/3] ARM: catch pending imprecise abort on unmask

2015-10-15 Thread Tony Lindgren

* Russell King - ARM Linux  [151015 09:11]:
> On Thu, Oct 15, 2015 at 08:39:15AM -0700, Tony Lindgren wrote:
> > * Russell King - ARM Linux  [151015 08:37]:
> > > On Thu, Oct 15, 2015 at 12:32:20PM +0200, Lucas Stach wrote:
> > > > Install a non-faulting handler just before unmasking imprecise aborts
> > > > and switch back to the regular one after unmasking is done.
> > > > 
> > > > This catches any pending imprecise abort that the firmware/bootloader
> > > > may have left behind that would normally crash the kernel at that point.
> > > > As there are apparently a lot of bootlaoders out there that do such a
> > > > thing it makes sense to handle it in the common startup code.
> > > > 
> > > > Signed-off-by: Lucas Stach 
> > > 
> > > Much better.  Please feel free to add it to the patch system, thanks.
> > > 
> > > I think, given that the original seems to be breaking platforms, this
> > > patch needs to go into -rc kernels, right?
> > 
> > Hmm do we still see a trace where the issue happened though with this
> > one?
> 
> That's not the intention of this specific patch.
> 
> This is solely to detect the bootloader induced imprecise exception,
> nothing more.  A backtrace for that won't be useful in any shape or
> form - in fact, the backtrace will be well known (it'll be from the
> site where the imprecise exceptions are unmasked.)
> 
> Any imprecise exception which happens after this will be handled in
> the normal way: it'll raise a kernel oops, and that will have all the
> details that a kernel oops normally has.

OK makes sense.

> The difference is, rather than the boot loader provoking the kernel to
> oops at this point, we're able to report the event and continue on.

OK

Tony
--
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 2/2] gpio: omap: convert to use generic irq handler

2015-10-15 Thread Grygorii Strashko


Hi Thomas,

On 10/13/2015 09:33 PM, Thomas Gleixner wrote:

Grygorii,

On Tue, 13 Oct 2015, Grygorii Strashko wrote:

I'd very appreciate for any advice of how to better proceed with your request.
  - I can try to apply and re-send only patches marked by '*'
  - I can prepare branch with all above patches


Please provide a branch on top of 4.1.10 which contains the whole
lot. I have a look at it and decide then how to go from there.


I've prepared branch linux-4.1.10-ti-gpio:
in g...@git.ti.com:~gragst/ti-linux-kernel/gragsts-ti-linux-kernel.git

based on top of
 git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
 branch : linux-4.1.y
 commit : 27f1b7f Linux 4.1.10


Also, I've tried to merge it in linux-4.1.y-rt and found that merge can 
be done without merge conflicts if below patch is reverted:

"
   Revert "gpio: omap: use raw locks for locking"
   This reverts commit 26dc4f70eb09ff7d36b1e6cd720e65b3c69098ae
"

--
regards,
-grygorii
--
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 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

2015-10-15 Thread Franklin S Cooper Jr.



On 10/15/2015 02:35 AM, Roger Quadros wrote:
> On 14/10/15 23:03, Franklin S Cooper Jr. wrote:
>>
>> On 10/14/2015 01:13 PM, Tony Lindgren wrote:
>>> * Franklin S Cooper Jr.  [151014 09:27]:
 On 10/14/2015 11:18 AM, Tony Lindgren wrote:
> * Franklin S Cooper Jr.  [151014 07:37]:
>> On 10/14/2015 09:11 AM, Roger Quadros wrote:
>>> On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
 On 10/14/2015 06:52 AM, Roger Quadros wrote:
> Franklin,
>
> On 14/10/15 14:36, Roger Quadros wrote:
>> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>>> Switch from dma_request_channel to allow passing dma channel
>>> information from DT rather than hardcoding a value.
>>>
>>> Signed-off-by: Franklin S Cooper Jr 
>> Acked-by: Roger Quadros 
>>
>>> ---
>>>  drivers/mtd/nand/omap2.c | 4 +++-
>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>> index d0f2620..957c32f 100644
>>> --- a/drivers/mtd/nand/omap2.c
>>> +++ b/drivers/mtd/nand/omap2.c
>>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct 
>>> platform_device *pdev)
>>> dma_cap_zero(mask);
>>> dma_cap_set(DMA_SLAVE, mask);
>>> sig = OMAP24XX_DMA_GPMC;
>>> -   info->dma = dma_request_channel(mask, 
>>> omap_dma_filter_fn, );
>>> +   info->dma = dma_request_slave_channel_compat(mask,
>>> +   omap_dma_filter_fn, , pdev->dev.parent, 
>>> "rxtx");
>>> +
> Just discovered that you are using the parent device node.
>
> How about moving the dma bindings to the nand node instead and using
> pdev->dev here?
 Roger,

 From what I can tell the interrupt number and the dma channel will 
 always be
 the same no matter what. Doesn't matter if you have multiple nands or a
 combination of nands and nors. Since that is the case I think it just 
 makes
 sense to leave it in the gpmc parent node and define it once.
>>> Is prefetch/writepost dma used for NOR or any other GPMC peripheral
>>> or only for NAND?
>> The dma seems tied to the prefetch. From what I can tell the prefetch is 
>> only
>> used by nand.
>>> Let's also get Tony's inputs on this.
>> Sure.
> Hmm so what would keep other devices from using the prefetch
 Looking at the TRM any references to the prefetch are always with respect 
 to
 NAND.

 I also see the below mentioned in the TRM.
 Pre-fetch and write posting engine associated with system DMA to get full 
 performance from NAND
 device with minimum impact on NOR/SRAM concurrent access.
>>> OK up to you guys to figure out if it may be usable in a generic way then :)
>> Ok I just got clarification from hw folks. DMA for GPMC can be used for any 
>> of the
>> various modes. But the prefetch is specific to NAND.
> In that case the dma information must be in the GPMC node.
Ok I'll be sending a v2 patchset soon but I'll be leaving this as is.
>
> cheers,
> -roger

--
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 2/2 v2] ARM: DRA7/335x/437x: hwmod: Remove gpmc address space from hwmod data

2015-10-15 Thread Franklin S Cooper Jr

GPMC address information is provided by device tree. No longer need
to include this information within hwmod.

Signed-off-by: Franklin S Cooper Jr 
---
Version 2 changes:
None

 arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c | 10 --
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c| 10 --
 2 files changed, 20 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c 
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
index 9ba431c..1c210cb 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
@@ -275,20 +275,10 @@ struct omap_hwmod_ocp_if am33xx_epwmss2__ehrpwm2 = {
 };
 
 /* l3s cfg -> gpmc */
-static struct omap_hwmod_addr_space am33xx_gpmc_addr_space[] = {
-   {
-   .pa_start   = 0x5000,
-   .pa_end = 0x5000 + SZ_8K - 1,
-   .flags  = ADDR_TYPE_RT,
-   },
-   { }
-};
-
 struct omap_hwmod_ocp_if am33xx_l3_s__gpmc = {
.master = _l3_s_hwmod,
.slave  = _gpmc_hwmod,
.clk= "l3s_gclk",
-   .addr   = am33xx_gpmc_addr_space,
.user   = OCP_USER_MPU,
 };
 
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index ad2cc7a..7bf106a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -2638,21 +2638,11 @@ static struct omap_hwmod_ocp_if dra7xx_l4_per1__gpio8 = 
{
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
-static struct omap_hwmod_addr_space dra7xx_gpmc_addrs[] = {
-   {
-   .pa_start   = 0x5000,
-   .pa_end = 0x53ff,
-   .flags  = ADDR_TYPE_RT
-   },
-   { }
-};
-
 /* l3_main_1 -> gpmc */
 static struct omap_hwmod_ocp_if dra7xx_l3_main_1__gpmc = {
.master = _l3_main_1_hwmod,
.slave  = _gpmc_hwmod,
.clk= "l3_iclk_div",
-   .addr   = dra7xx_gpmc_addrs,
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
-- 
2.6.1

--
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/5] mtd: nand: Fix support for NAND DMA prefetch

2015-10-15 Thread Franklin S Cooper Jr

NAND DMA prefetch has been broken for awhile and seems to have only
worked for SDMA based devices

This patchset fixes DMA prefetch to work on both EDMA and SDMA devices

Test on:
am335x gp evm
am437x gp evm
am37x gp evm

This patchset depends on Roger Quadros recent v4 GPMC/NAND patchset
https://github.com/rogerq/linux.git
branch: for-v4.4/gpmc-v4

Franklin S Cooper Jr (5):
  mtd: nand: omap2: Support parsing dma channel information from DT
  mtd: nand: omap2: Start dma request before enabling prefetch
  mtd: nand: omap2: Fix high memory dma prefetch transfer
  ARM: dts: am437x/am33xx/omap/dm816x: Add gpmc dma channel
  ARM: OMAP2+: Update GPMC and NAND DT binding documentation

 .../bindings/memory-controllers/omap-gpmc.txt  |  7 +-
 .../devicetree/bindings/mtd/gpmc-nand.txt  |  2 ++
 arch/arm/boot/dts/am33xx.dtsi  |  2 ++
 arch/arm/boot/dts/am4372.dtsi  |  2 ++
 arch/arm/boot/dts/dm816x.dtsi  |  2 ++
 arch/arm/boot/dts/omap3.dtsi   |  2 ++
 arch/arm/boot/dts/omap4.dtsi   |  2 ++
 arch/arm/boot/dts/omap5.dtsi   |  2 ++
 drivers/mtd/nand/omap2.c   | 27 +-
 9 files changed, 31 insertions(+), 17 deletions(-)

-- 
2.6.1

--
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/5] mtd: nand: omap2: Fix high memory dma prefetch transfer

2015-10-15 Thread Franklin S Cooper Jr

Based on DMA documentation and testing using high memory buffer when
doing dma transfers can lead to various issues including kernel
panics.

To workaround this simply use cpu copy. The amount of high memory
buffers used are very uncommon so no noticeable performance hit should
be seen.

Signed-off-by: Franklin S Cooper Jr 
---
V2 Changes:
None

 drivers/mtd/nand/omap2.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 1f58420..0d2cbb0 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -479,17 +479,8 @@ static inline int omap_nand_dma_transfer(struct mtd_info 
*mtd, void *addr,
int ret;
u32 val;
 
-   if (addr >= high_memory) {
-   struct page *p1;
-
-   if (((size_t)addr & PAGE_MASK) !=
-   ((size_t)(addr + len - 1) & PAGE_MASK))
-   goto out_copy;
-   p1 = vmalloc_to_page(addr);
-   if (!p1)
-   goto out_copy;
-   addr = page_address(p1) + ((size_t)addr & ~PAGE_MASK);
-   }
+   if (addr >= high_memory)
+   goto out_copy;
 
sg_init_one(, addr, len);
n = dma_map_sg(info->dma->device->dev, , 1, dir);
@@ -546,6 +537,7 @@ out_copy:
else
is_write == 0 ? omap_read_buf8(mtd, (u_char *) addr, len)
: omap_write_buf8(mtd, (u_char *) addr, len);
+
return 0;
 }
 
-- 
2.6.1

--
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/5] mtd: nand: omap2: Start dma request before enabling prefetch

2015-10-15 Thread Franklin S Cooper Jr

The prefetch engine sends a dma request once a FIFO threshold has
been met. No other requests are received until the previous request
is handled.

Starting an edma transfer (dma_async_issue_pending) results in any
previous event for the dma channel to be cleared. Therefore, starting
the prefetch engine before initiating the dma transfer may result in
the prefetch triggering a dma request but instead of it being handled
it can end up being cleared. This will result in a hang since the code
will continue to wait for the dma request to complete.

By initiating the dma request before enabling the prefetch engine this
race condition is avoided and no dma request are missed/cleared.

Signed-off-by: Franklin S Cooper Jr 
---
V2 Changes:
Moved comment

 drivers/mtd/nand/omap2.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 957c32f..1f58420 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -509,6 +509,11 @@ static inline int omap_nand_dma_transfer(struct mtd_info 
*mtd, void *addr,
tx->callback_param = >comp;
dmaengine_submit(tx);
 
+   init_completion(>comp);
+
+   /* setup and start DMA using dma_addr */
+   dma_async_issue_pending(info->dma);
+
/*  configure and start prefetch transfer */
ret = omap_prefetch_enable(info->gpmc_cs,
PREFETCH_FIFOTHRESHOLD_MAX, 0x1, len, is_write, info);
@@ -516,10 +521,6 @@ static inline int omap_nand_dma_transfer(struct mtd_info 
*mtd, void *addr,
/* PFPW engine is busy, use cpu copy method */
goto out_copy_unmap;
 
-   init_completion(>comp);
-   dma_async_issue_pending(info->dma);
-
-   /* setup and start DMA using dma_addr */
wait_for_completion(>comp);
tim = 0;
limit = (loops_per_jiffy * msecs_to_jiffies(OMAP_NAND_TIMEOUT_MS));
-- 
2.6.1

--
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/5] ARM: dts: am437x/am33xx/omap/dm816x: Add gpmc dma channel

2015-10-15 Thread Franklin S Cooper Jr

Add dma channel information to the gpmc. Although not enabled by
default this will allow prefetch-dma to be used.

Signed-off-by: Franklin S Cooper Jr 
---
V2 Changes:
Added DMA entry for OMAP4 and OMAP5

 arch/arm/boot/dts/am33xx.dtsi | 2 ++
 arch/arm/boot/dts/am4372.dtsi | 2 ++
 arch/arm/boot/dts/dm816x.dtsi | 2 ++
 arch/arm/boot/dts/omap3.dtsi  | 2 ++
 arch/arm/boot/dts/omap4.dtsi  | 2 ++
 arch/arm/boot/dts/omap5.dtsi  | 2 ++
 6 files changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index e065f21..f2d8eed 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -819,6 +819,8 @@
ti,no-idle-on-init;
reg = <0x5000 0x2000>;
interrupts = <100>;
+   dmas = < 52>;
+   dma-names = "rxtx";
gpmc,num-cs = <7>;
gpmc,num-waitpins = <2>;
#address-cells = <2>;
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index ec8b7a3..c02061b 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -841,6 +841,8 @@
gpmc: gpmc@5000 {
compatible = "ti,am3352-gpmc";
ti,hwmods = "gpmc";
+   dmas = < 52>;
+   dma-names = "rxtx";
clocks = <_gclk>;
clock-names = "fck";
reg = <0x5000 0x2000>;
diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
index 68fb444..d2e5d31 100644
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -180,6 +180,8 @@
#address-cells = <2>;
#size-cells = <1>;
interrupts = <100>;
+   dmas = < 52>;
+   dma-names = "rxtx";
gpmc,num-cs = <6>;
gpmc,num-waitpins = <2>;
gpio-controller;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 7f212b6..9dbbcf6 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -717,6 +717,8 @@
ti,hwmods = "gpmc";
reg = <0x6e00 0x02d0>;
interrupts = <20>;
+   dmas = < 4>;
+   dma-names = "rxtx";
gpmc,num-cs = <8>;
gpmc,num-waitpins = <4>;
#address-cells = <2>;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 5a206c1..32b65be 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -354,6 +354,8 @@
#address-cells = <2>;
#size-cells = <1>;
interrupts = ;
+   dmas = < 4>;
+   dma-names = "rxtx";
gpmc,num-cs = <8>;
gpmc,num-waitpins = <4>;
ti,hwmods = "gpmc";
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 4c04389..ca3c17f 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -391,6 +391,8 @@
#address-cells = <2>;
#size-cells = <1>;
interrupts = ;
+   dmas = < 4>;
+   dma-names = "rxtx";
gpmc,num-cs = <8>;
gpmc,num-waitpins = <4>;
ti,hwmods = "gpmc";
-- 
2.6.1

--
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 1/2 v2] ARM: DRA7/335x/437x/OMAP4: hwmod: Remove elm address space from hwmod data

2015-10-15 Thread Franklin S Cooper Jr

ELM address information is provided by device tree. No longer need
to include this information within hwmod.

Signed-off-by: Franklin S Cooper Jr 
---
Version 2 changes:
Removing elm addr entries also for 335x,437x and omap4 hwmod

 arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c | 10 --
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c   | 10 --
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c| 10 --
 3 files changed, 30 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c 
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
index 8f5989d..9ba431c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c
@@ -152,20 +152,10 @@ struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
.user   = OCP_USER_MPU,
 };
 
-static struct omap_hwmod_addr_space am33xx_elm_addr_space[] = {
-   {
-   .pa_start   = 0x4808,
-   .pa_end = 0x4808 + SZ_8K - 1,
-   .flags  = ADDR_TYPE_RT
-   },
-   { }
-};
-
 struct omap_hwmod_ocp_if am33xx_l4_ls__elm = {
.master = _l4_ls_hwmod,
.slave  = _elm_hwmod,
.clk= "l4ls_gclk",
-   .addr   = am33xx_elm_addr_space,
.user   = OCP_USER_MPU,
 };
 
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 43eebf2..8f13f4a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -3915,21 +3915,11 @@ static struct omap_hwmod_ocp_if 
omap44xx_l4_per__dss_venc = {
.user   = OCP_USER_MPU,
 };
 
-static struct omap_hwmod_addr_space omap44xx_elm_addrs[] = {
-   {
-   .pa_start   = 0x48078000,
-   .pa_end = 0x48078fff,
-   .flags  = ADDR_TYPE_RT
-   },
-   { }
-};
-
 /* l4_per -> elm */
 static struct omap_hwmod_ocp_if omap44xx_l4_per__elm = {
.master = _l4_per_hwmod,
.slave  = _elm_hwmod,
.clk= "l4_div_ck",
-   .addr   = omap44xx_elm_addrs,
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 562247b..ad2cc7a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -2566,21 +2566,11 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__hdmi 
= {
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
-static struct omap_hwmod_addr_space dra7xx_elm_addrs[] = {
-   {
-   .pa_start   = 0x48078000,
-   .pa_end = 0x48078fff,
-   .flags  = ADDR_TYPE_RT
-   },
-   { }
-};
-
 /* l4_per1 -> elm */
 static struct omap_hwmod_ocp_if dra7xx_l4_per1__elm = {
.master = _l4_per1_hwmod,
.slave  = _elm_hwmod,
.clk= "l3_iclk_div",
-   .addr   = dra7xx_elm_addrs,
.user   = OCP_USER_MPU | OCP_USER_SDMA,
 };
 
-- 
2.6.1

--
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/5] ARM: OMAP2+: Update GPMC and NAND DT binding documentation

2015-10-15 Thread Franklin S Cooper Jr

Add additional details to the GPMC NAND documentation to clarify
what is needed to enable NAND DMA prefetch.

Signed-off-by: Franklin S Cooper Jr 
---
V2 Changes:
Replace nand and Nand with NAND
Specify the value dma-names should be set to

 Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt | 7 ++-
 Documentation/devicetree/bindings/mtd/gpmc-nand.txt| 2 ++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt 
b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
index 704be93..afae4b3 100644
--- a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
@@ -33,6 +33,10 @@ Required properties:
As this will change in the future, filling correct
values here is a requirement.
 
+GPMC DMA information.
+ - dmasGPMC NAND prefetch dma channel
+ - dma-names   Must be set to "rxtx"
+
 Timing properties for child nodes. All are optional and default to 0.
 
  - gpmc,sync-clk-ps:   Minimum clock period for synchronous mode, in 
picoseconds
@@ -119,7 +123,8 @@ Example for an AM33xx board:
ti,hwmods = "gpmc";
reg = <0x5000 0x2000>;
interrupts = <100>;
-
+   dmas = < 52>;
+   dma-names = "rxtx";
gpmc,num-cs = <8>;
gpmc,num-waitpins = <2>;
#address-cells = <2>;
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt 
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index 253e6de..4b0c240 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -61,6 +61,8 @@ Example for an AM33xx board:
ti,hwmods = "gpmc";
reg = <0x5000 0x36c>;
interrupts = <100>;
+   dmas = < 52>;
+   dma-names = "rxtx";
gpmc,num-cs = <8>;
gpmc,num-waitpins = <2>;
#address-cells = <2>;
-- 
2.6.1

--
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/5] ARM: OMAP2+: Update gpmc and nand DT binding documentation

2015-10-15 Thread Franklin S Cooper Jr.



On 10/14/2015 06:50 AM, Roger Quadros wrote:
> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>> Add additional details to the gpmc and nand documentation to clarify
>> what is needed to enable nand dma prefetch.
>>
>> Signed-off-by: Franklin S Cooper Jr 
>> ---
>>  Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt | 7 
>> ++-
>>  Documentation/devicetree/bindings/mtd/gpmc-nand.txt| 2 ++
>>  2 files changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt 
>> b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
>> index 704be93..b1e2802 100644
>> --- a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
>> +++ b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
>> @@ -33,6 +33,10 @@ Required properties:
>>  As this will change in the future, filling correct
>>  values here is a requirement.
>>  
>> +GPMC DMA information. Required only when GPMC nand prefetch is enabled.
>> + - dmas GPMC nand prefetch dma channel
> s/nand/NAND
>
>> + - dma-namesDMA channel name use as a reference within the 
>> Nand driver
> s/Nand/NAND
>
> This is inevitably going to be "rxtx". So why not say that it should be "rxtx"
I'll fix all three of these
>
> Should these bindings go in bindings/mtd/gpmc-nand.txt instead?
>
>> +
>>  Timing properties for child nodes. All are optional and default to 0.
>>  
>>   - gpmc,sync-clk-ps:Minimum clock period for synchronous mode, in 
>> picoseconds
>> @@ -119,7 +123,8 @@ Example for an AM33xx board:
>>  ti,hwmods = "gpmc";
>>  reg = <0x5000 0x2000>;
>>  interrupts = <100>;
>> -
>> +dmas = < 52>;
>> +dma-names = "rxtx";
> Why not define these in the NAND node instead of gpmc node?
Since we decided that the dma entry will stay in the GPMC node I'll leave these 
as is.
>
>>  gpmc,num-cs = <8>;
>>  gpmc,num-waitpins = <2>;
>>  #address-cells = <2>;
>> diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt 
>> b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
>> index 253e6de..4b0c240 100644
>> --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
>> +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
>> @@ -61,6 +61,8 @@ Example for an AM33xx board:
>>  ti,hwmods = "gpmc";
>>  reg = <0x5000 0x36c>;
>>  interrupts = <100>;
>> +dmas = < 52>;
>> +dma-names = "rxtx";
>>  gpmc,num-cs = <8>;
>>  gpmc,num-waitpins = <2>;
>>  #address-cells = <2>;
>>
> cheers,
> -roger

--
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/5] mtd: nand: omap2: Support parsing dma channel information from DT

2015-10-15 Thread Franklin S Cooper Jr

Switch from dma_request_channel to allow passing dma channel
information from DT rather than hardcoding a value.

Signed-off-by: Franklin S Cooper Jr 
---
V2 Changes:
None

 drivers/mtd/nand/omap2.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index d0f2620..957c32f 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device *pdev)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
sig = OMAP24XX_DMA_GPMC;
-   info->dma = dma_request_channel(mask, omap_dma_filter_fn, );
+   info->dma = dma_request_slave_channel_compat(mask,
+   omap_dma_filter_fn, , pdev->dev.parent, "rxtx");
+
if (!info->dma) {
dev_err(>dev, "DMA engine request failed\n");
err = -ENXIO;
-- 
2.6.1

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

38 matches

Mail list logo