Re: [PATCH 3/3] omap3/omap4 hsmmc: Register offset handling
Hi Kishore,
On 8/30/2010 7:48 PM, Kadiyala, Kishore wrote:
OMAP4 not only have newly added hsmmc registers but also
have registers which were there in OMAP3 and which doesn't
have a common offset deviation compared to OMAP3.
For generic handling, OMAP3 and OMAP4 has different array's of
register offset maintained and right one is choosen during run time.
Cc: Tony Lindgrent...@atomide.com
Cc: Adrian Hunteradrian.hun...@nokia.com
Cc: Madhusudhan Chikkaturemadhu...@ti.com
Cc: Andrew Mortona...@linux-foundation.org
Signed-off-by: Kishore Kadiyalakishore.kadiy...@ti.com
---
arch/arm/mach-omap2/devices.c | 30 +++--
arch/arm/mach-omap2/hsmmc.c |6 +
arch/arm/plat-omap/include/plat/mmc.h | 78 ++-
drivers/mmc/host/omap_hsmmc.c | 251 +++--
4 files changed, 218 insertions(+), 147 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2dbb265..03add6e 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -506,6 +506,8 @@ static inline void omap_init_sham(void) { }
#define MMCHS_SYSCONFIG_SWRESET(1 1)
#define MMCHS_SYSSTATUS0x0014
#define MMCHS_SYSSTATUS_RESETDONE (1 0)
+#define OMAP4_MMCHS_SYSCONFIG_SWRESET (1 0)
+#define OMAP4_MMCHS_OFFSET 0x100
static struct platform_device dummy_pdev = {
.dev = {
@@ -528,6 +530,8 @@ static struct platform_device dummy_pdev = {
static void __init omap_hsmmc_reset(void)
{
u32 i, nr_controllers;
+ u32 reg_val = 0;
+ u32 reg_off = 0;
if (cpu_is_omap242x())
return;
@@ -562,9 +566,6 @@ static void __init omap_hsmmc_reset(void)
break;
}
- if (cpu_is_omap44xx())
- base += OMAP4_MMC_REG_OFFSET;
-
dummy_pdev.id = i;
dev_set_name(dummy_pdev.dev, mmci-omap-hs.%d, i);
iclk = clk_get(dev, ick);
@@ -582,9 +583,18 @@ static void __init omap_hsmmc_reset(void)
break;
}
- omap_writel(MMCHS_SYSCONFIG_SWRESET, base + MMCHS_SYSCONFIG);
- v = omap_readl(base + MMCHS_SYSSTATUS);
- while (!(omap_readl(base + MMCHS_SYSSTATUS)
+ if (cpu_is_omap44xx())
+ reg_val = MMCHS_SYSCONFIG_SWRESET;
+ else
+ reg_val = MMCHS_SYSCONFIG_SWRESET;
+ omap_writel(reg_val, base + MMCHS_SYSCONFIG);
+
+ reg_off = MMCHS_SYSSTATUS;
+ if (cpu_is_omap44xx())
+ reg_off += OMAP4_MMCHS_OFFSET;
+ v = omap_readl(base + reg_off);
+
+ while (!(omap_readl(base + reg_off)
MMCHS_SYSSTATUS_RESETDONE))
cpu_relax();
Why does that series not seems to be based on your hwmod migration? The
reset is fully handle by the hwmod framework now.
BTW, when do you have to apply a reset in your case? Do you have the
need for an API accessible by the driver?
I'm asking because for the moment the framework does not expose the
reset API and use it only at init time.
@@ -745,13 +755,13 @@ void __init omap2_init_mmc(struct omap_mmc_platform_data
**mmc_data,
case 3:
if (!cpu_is_omap44xx())
return;
- base = OMAP4_MMC4_BASE + OMAP4_MMC_REG_OFFSET;
+ base = OMAP4_MMC4_BASE;
irq = OMAP44XX_IRQ_MMC4;
break;
case 4:
if (!cpu_is_omap44xx())
return;
- base = OMAP4_MMC5_BASE + OMAP4_MMC_REG_OFFSET;
+ base = OMAP4_MMC5_BASE;
irq = OMAP44XX_IRQ_MMC5;
break;
default:
@@ -762,10 +772,8 @@ void __init omap2_init_mmc(struct omap_mmc_platform_data
**mmc_data,
size = OMAP2420_MMC_SIZE;
name = mmci-omap;
} else if (cpu_is_omap44xx()) {
- if (i 3) {
- base += OMAP4_MMC_REG_OFFSET;
+ if (i 3)
irq += OMAP44XX_IRQ_GIC_START;
- }
size = OMAP4_HSMMC_SIZE;
namee = mmci-omap-hs;
} else {
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index c8f647b..d93b704 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -262,6 +262,12 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
mmc-slots[0].internal_clock = !c-ext_clock;
mmc-dma_mask = 0x;
+ /*
RE: [PATCH 1/1] omap2/3: Update revision identification
-Original Message- From: Premi, Sanjeev Sent: Monday, August 16, 2010 9:23 PM To: linux-omap@vger.kernel.org Cc: Premi, Sanjeev Subject: [PATCH 1/1] omap2/3: Update revision identification The existing definitions for cpu revision used upper nibble in the bits[15:08]. With OMAP3630, definitions use lower nibble. This patch unifies the definitions to start at lower nibble. [1] http://marc.info/?t=12816173915r=1w=2 Signed-off-by: Sanjeev Premi pr...@ti.com --- arch/arm/mach-omap2/id.c | 22 +++- arch/arm/plat-omap/include/plat/cpu.h | 36 Hi Tony, Did you have chance to look at this? (I was away from work; couldn't follow-up earlier). Best regards, Sanjeev [snip]--[snip] -- 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 0/1] omap: fix section mismatch errors
-Original Message- From: Premi, Sanjeev Sent: Monday, August 16, 2010 9:01 PM To: linux-omap@vger.kernel.org Cc: Premi, Sanjeev Subject: [PATCH 0/1] omap: fix section mismatch errors Multiple section mismatches are observed with the latest master. While attempting to fix the ones listed below, I came across more instances. The patch in this series fixes all these issues. Though most of the changes are straight-forward, but for these (for now annotated as ___refdata): 1) arch/arm/plat-omap/cpu-omap.c Variable omap_driver may be required beyond __init lifetime. 2) drivers/mfd/twl-core.c Variable twl_driver is used both in __init and __exit context. There are few more similar errors in some of the modules would submit them separately. WARNING: vmlinux.o(.text+0x187c0): Section mismatch in reference from the function zoom_twl_gpio_setup() to the (unknown reference) .init.data:(unknown) The function zoom_twl_gpio_setup() references the (unknown reference) __initdata (unknown). This is often because zoom_twl_gpio_setup lacks a __initdata annotation or the annotation of (unknown) is wrong. WARNING: vmlinux.o(.text+0x189b0): Section mismatch in reference from the function cm_t35_twl_gpio_setup() to the (unknown reference) .init.data:(unknown) The function cm_t35_twl_gpio_setup() references the (unknown reference) __initdata (unknown). This is often because cm_t35_twl_gpio_setup lacks a __initdata annotation or the annotation of (unknown) is wrong. WARNING: vmlinux.o(.data+0x19e38): Section mismatch in reference from the variable h4_config to the (unknown reference) .init.data:(unknown) The variable h4_config references the (unknown reference) __initdata (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, WARNING: vmlinux.o(.data+0x1a670): Section mismatch in reference from the variable sdp2430_config to the (unknown reference) .init.data:(unknown) The variable sdp2430_config references the (unknown reference) __initdata (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, WARNING: vmlinux.o(.data+0x1ac50): Section mismatch in reference from the variable apollon_config to the (unknown reference) .init.data:(unknown) The variable apollon_config references the (unknown reference) __initdata (unknown) If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, WARNING: vmlinux.o(.data+0x2e378): Section mismatch in reference from the variable omap_driver to the function .init.text:omap_cpu_init() The variable omap_driver references the function __init omap_cpu_init() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, WARNING: vmlinux.o(.data+0x1b9dcc): Section mismatch in reference from the variable twl_driver to the function .init.text:twl_probe() The variable twl_driver references the function __init twl_probe() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console, Sanjeev Premi (1): omap: fix section mismatch errors arch/arm/mach-omap2/board-2430sdp.c |2 +- arch/arm/mach-omap2/board-apollon.c |2 +- arch/arm/mach-omap2/board-cm-t35.c |8 arch/arm/mach-omap2/board-h4.c |2 +- arch/arm/mach-omap2/board-zoom-peripherals.c | 18 +- arch/arm/plat-omap/cpu-omap.c|2 +- drivers/mfd/twl-core.c |2 +- 7 files changed, 18 insertions(+), 18 deletions(-) Hi Tony, Did you look at this as well? Best regards, Sanjeev -- 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] dmtimer: hwmod: add omap2420 database
Tarun,
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of
DebBarma, Tarun Kanti
Sent: Saturday, August 14, 2010 8:44 PM
To: linux-omap@vger.kernel.org
Cc: DebBarma, Tarun Kanti; Basak, Partha; Gopinath, Thara;
Paul Walmsley; Kevin Hilman; Tony Lindgren
Subject: [PATCH] dmtimer: hwmod: add omap2420 database
This patch adds hwmod database for omap2420.
Signed-off-by: Partha Basak p-bas...@ti.com
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 597
1 files changed, 597 insertions(+), 0 deletions(-)
mode change 100644 = 100755
arch/arm/mach-omap2/omap_hwmod_2420_data.c
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
old mode 100644
new mode 100755
index 3cc768e..7f87924
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -15,6 +15,7 @@
#include mach/irqs.h
#include plat/cpu.h
#include plat/dma.h
+#include plat/dmtimer.h
#include omap_hwmod_common_data.h
@@ -121,6 +122,590 @@ static struct omap_hwmod
omap2420_l4_wkup_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2420),
.flags = HWMOD_NO_IDLEST,
};
+/* Timer Common */
+static struct omap_hwmod_class_sysconfig omap2420_timer_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap2420_timer_hwmod_class = {
+ .name = timer,
+ .sysc = omap2420_timer_sysc,
+ .rev = OMAP_TIMER_IP_LEGACY,
Applying only this patch breaks build. Take care to address dependenices
for each patch in the series so that, git bisect works with any patch in the
series.
-Manjunath--
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] ARM: Fix v7wbi_tlb_flags for SMP on UP
On Thu, Sep 02, 2010 at 04:47:46PM -0700, Tony Lindgren wrote: Correction, only boots on SMP hardawre. On UP hardware I still need the following patch. This should fix that properly. arch/arm/Kconfig | 12 arch/arm/include/asm/assembler.h | 20 - arch/arm/include/asm/tlbflush.h | 24 +++- arch/arm/kernel/entry-armv.S |7 +--- arch/arm/kernel/head.S| 34 +++ arch/arm/kernel/vmlinux.lds.S | 11 +++ arch/arm/mach-realview/include/mach/smp.h | 10 +-- arch/arm/mach-s5pv310/include/mach/smp.h |9 +- arch/arm/mach-tegra/include/mach/smp.h| 10 +-- arch/arm/mach-ux500/include/mach/smp.h|9 +- arch/arm/mach-vexpress/include/mach/smp.h |9 +- arch/arm/mm/cache-v7.S| 14 +++--- arch/arm/mm/proc-v6.S | 43 +++-- arch/arm/mm/proc-v7.S | 31 + arch/arm/mm/tlb-v7.S | 33 -- arch/arm/plat-omap/include/plat/smp.h | 12 +--- 16 files changed, 163 insertions(+), 125 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index ab2536c..4575e4a 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1166,6 +1166,18 @@ config SMP If you don't know what to do here, say N. +config SMP_ON_UP + bool Allow booting SMP kernel on uniprocessor systems (EXPERIMENTAL) + depends on SMP !XIP + default y + help + SMP kernels contain instructions which fail on non-SMP processors. + Enabling this option allows the kernel to modify itself to make + these instructions safe. Disabling it allows about 1K of space + savings. + + If you don't know what to do here, say Y. + config HAVE_ARM_SCU bool depends on SMP diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h index 6e8f05c..55974d2 100644 --- a/arch/arm/include/asm/assembler.h +++ b/arch/arm/include/asm/assembler.h @@ -154,16 +154,32 @@ .long b,9001f;\ .popsection +#ifdef CONFIG_SMP +#define SMP(instr...) \ +9998: instr +#define UP(instr...) \ + .pushsection .smpalt.init, a;\ + .word 9998b ;\ + instr ;\ + .popsection +#else +#define SMP(instr...) +#define UP(instr...) instr +#endif + /* * SMP data memory barrier */ .macro smp_dmb #ifdef CONFIG_SMP #if __LINUX_ARM_ARCH__ = 7 - dmb + SMP(dmb) #elif __LINUX_ARM_ARCH__ == 6 - mcr p15, 0, r0, c7, c10, 5 @ dmb + SMP(mcr p15, 0, r0, c7, c10, 5) @ dmb +#else +#error Incompatible SMP platform #endif + UP(nop) #endif .endm diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h index 33b546a..c344c34 100644 --- a/arch/arm/include/asm/tlbflush.h +++ b/arch/arm/include/asm/tlbflush.h @@ -70,6 +70,10 @@ #undef _TLB #undef MULTI_TLB +#ifdef CONFIG_SMP_ON_UP +#define MULTI_TLB 1 +#endif + #define v3_tlb_flags (TLB_V3_FULL | TLB_V3_PAGE) #ifdef CONFIG_CPU_TLB_V3 @@ -185,17 +189,23 @@ # define v6wbi_always_flags(-1UL) #endif -#ifdef CONFIG_SMP -#define v7wbi_tlb_flags (TLB_WB | TLB_DCLEAN | TLB_V7_IS_BTB | \ +#define v7wbi_tlb_flags_smp(TLB_WB | TLB_DCLEAN | TLB_V7_IS_BTB | \ TLB_V7_UIS_FULL | TLB_V7_UIS_PAGE | TLB_V7_UIS_ASID) -#else -#define v7wbi_tlb_flags (TLB_WB | TLB_DCLEAN | TLB_BTB | \ +#define v7wbi_tlb_flags_up (TLB_WB | TLB_DCLEAN | TLB_BTB | \ TLB_V6_U_FULL | TLB_V6_U_PAGE | TLB_V6_U_ASID) -#endif #ifdef CONFIG_CPU_TLB_V7 -# define v7wbi_possible_flags v7wbi_tlb_flags -# define v7wbi_always_flagsv7wbi_tlb_flags + +# ifdef CONFIG_SMP +# define v7wbi_possible_flags v7wbi_tlb_flags_smp +# define v7wbi_always_flags v7wbi_tlb_flags_smp +# elif defined(CONFIG_SMP_ON_UP) +# define v7wbi_possible_flags (v7wbi_tlb_flags_smp | v7wbi_tlb_flags_up) +# define v7wbi_always_flags (v7wbi_tlb_flags_smp v7wbi_tlb_flags_up) +# else +# define v7wbi_possible_flags v7wbi_tlb_flags_up +# define v7wbi_always_flags v7wbi_tlb_flags_up +# endif # ifdef _TLB # define MULTI_TLB 1 # else diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S index bb8e93a..bb2ef60 100644 --- a/arch/arm/kernel/entry-armv.S +++ b/arch/arm/kernel/entry-armv.S @@ -965,11 +965,8 @@ kuser_cmpxchg_fixup: beq 1b rsbsr0, r3, #0 /* beware -- each __kuser slot must be 8 instructions max */ -#ifdef CONFIG_SMP - b __kuser_memory_barrier -#else - usr_ret lr -#endif + SMP(b
Re: [RFC: PATCH] OMAP: hwmod: New API to modify the autoidle bits of sysconfig register
On Tuesday 31 August 2010 09:46 PM, Cousson, Benoit wrote:
On 8/31/2010 4:41 PM, ABRAHAM, KISHON VIJAY wrote:
On Tuesday 31 August 2010 01:43 PM, Felipe Balbi wrote:
On Tue, 31 Aug 2010 10:53:36 +0530, kishona0393...@ti.comwrote:
Though driver shouldn't be using hwmod directly, there is no
corresponding API in omap_device to do the same. So we are planning to
store the omap_hwmod structure in platform_data during
arch_initcall (in the callback to omap_hwmod_for_each_by_class). So
whenever the
AUTOIDLE bits need to be reset or set, we pass the stored
omap_hwmod structure to this API. Currently, the functions that needs
AUTOIDLE
bit to be modified (omap_st_on, omap_st_off) resides in plat-omap.
couldn't your API instead be something like:
int omap_hwmod_set_autoidle(struct device *dev, u8 autoidle)
{
struct omap_hwmod *oh = dev_to_hwmod(dev);
if (!oh)
return -ENODEV;
[...]
return 0;
}
Balbi,
I couldn't find dev_to_hwmod() function. Do you actually mean
implementing dev_to_hwmod() function?
I created this API based on omap_hwmod_set_slave_idlemode()
present in lo (omap_hwmod.c) for changing the smart idle bit
of SYSCONFIG register.
-Kishon
That API does not exist. And since a device can contains several hwmods,
like in your case, this API cannot exist in that form.
The real issue is that we do not want to expose any API relative to PRCM
management to the driver. Even if you hide that behind some pdata, it is
still the driver that will call it.
I know that some IPs like MUSB or McBSP requires some unusual idle mode
change due to HW bugs, but in general, you should try to find a better
way to handle that in the core framework if possible.
Benoit,
I see the trend of using specific flags in hwmod which gets set
in pm_runtime_get_sync() for scenarios like this where auto idle
bits or smart idle bits need to be set/reset at runtime. The problem
in the case of sidetone in MCBSP is that we don't call get_sync or
put_sync for sidetone separately.
There is only two options we can think of for sidetone
1) Always disable autoidle for sidetone (I'm not sure if this will
have some power implications).
2) Use of the above API.
Would be helpful if you can also suggest us some other options as well.
-Kishon
Regards,
Benoit
--
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] ARM: Fix v7wbi_tlb_flags for SMP on UP
On Fri, Sep 03, 2010 at 10:07:34AM +0100, Russell King - ARM Linux wrote: On Thu, Sep 02, 2010 at 04:47:46PM -0700, Tony Lindgren wrote: Correction, only boots on SMP hardawre. On UP hardware I still need the following patch. This should fix that properly. Correction - the order of the config tests was wrong. arch/arm/Kconfig | 12 arch/arm/include/asm/assembler.h | 20 - arch/arm/include/asm/tlbflush.h | 24 +++- arch/arm/kernel/entry-armv.S |7 +--- arch/arm/kernel/head.S| 34 +++ arch/arm/kernel/vmlinux.lds.S | 11 +++ arch/arm/mach-realview/include/mach/smp.h | 10 +-- arch/arm/mach-s5pv310/include/mach/smp.h |9 +- arch/arm/mach-tegra/include/mach/smp.h| 10 +-- arch/arm/mach-ux500/include/mach/smp.h|9 +- arch/arm/mach-vexpress/include/mach/smp.h |9 +- arch/arm/mm/cache-v7.S| 14 +++--- arch/arm/mm/proc-v6.S | 43 +++-- arch/arm/mm/proc-v7.S | 31 + arch/arm/mm/tlb-v7.S | 33 -- arch/arm/plat-omap/include/plat/smp.h | 12 +--- 16 files changed, 163 insertions(+), 125 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index ab2536c..4575e4a 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1166,6 +1166,18 @@ config SMP If you don't know what to do here, say N. +config SMP_ON_UP + bool Allow booting SMP kernel on uniprocessor systems (EXPERIMENTAL) + depends on SMP !XIP + default y + help + SMP kernels contain instructions which fail on non-SMP processors. + Enabling this option allows the kernel to modify itself to make + these instructions safe. Disabling it allows about 1K of space + savings. + + If you don't know what to do here, say Y. + config HAVE_ARM_SCU bool depends on SMP diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h index 6e8f05c..55974d2 100644 --- a/arch/arm/include/asm/assembler.h +++ b/arch/arm/include/asm/assembler.h @@ -154,16 +154,32 @@ .long b,9001f;\ .popsection +#ifdef CONFIG_SMP +#define SMP(instr...) \ +9998: instr +#define UP(instr...) \ + .pushsection .smpalt.init, a;\ + .word 9998b ;\ + instr ;\ + .popsection +#else +#define SMP(instr...) +#define UP(instr...) instr +#endif + /* * SMP data memory barrier */ .macro smp_dmb #ifdef CONFIG_SMP #if __LINUX_ARM_ARCH__ = 7 - dmb + SMP(dmb) #elif __LINUX_ARM_ARCH__ == 6 - mcr p15, 0, r0, c7, c10, 5 @ dmb + SMP(mcr p15, 0, r0, c7, c10, 5) @ dmb +#else +#error Incompatible SMP platform #endif + UP(nop) #endif .endm diff --git a/arch/arm/include/asm/tlbflush.h b/arch/arm/include/asm/tlbflush.h index 33b546a..cf2f018 100644 --- a/arch/arm/include/asm/tlbflush.h +++ b/arch/arm/include/asm/tlbflush.h @@ -70,6 +70,10 @@ #undef _TLB #undef MULTI_TLB +#ifdef CONFIG_SMP_ON_UP +#define MULTI_TLB 1 +#endif + #define v3_tlb_flags (TLB_V3_FULL | TLB_V3_PAGE) #ifdef CONFIG_CPU_TLB_V3 @@ -185,17 +189,23 @@ # define v6wbi_always_flags(-1UL) #endif -#ifdef CONFIG_SMP -#define v7wbi_tlb_flags (TLB_WB | TLB_DCLEAN | TLB_V7_IS_BTB | \ +#define v7wbi_tlb_flags_smp(TLB_WB | TLB_DCLEAN | TLB_V7_IS_BTB | \ TLB_V7_UIS_FULL | TLB_V7_UIS_PAGE | TLB_V7_UIS_ASID) -#else -#define v7wbi_tlb_flags (TLB_WB | TLB_DCLEAN | TLB_BTB | \ +#define v7wbi_tlb_flags_up (TLB_WB | TLB_DCLEAN | TLB_BTB | \ TLB_V6_U_FULL | TLB_V6_U_PAGE | TLB_V6_U_ASID) -#endif #ifdef CONFIG_CPU_TLB_V7 -# define v7wbi_possible_flags v7wbi_tlb_flags -# define v7wbi_always_flagsv7wbi_tlb_flags + +# ifdef CONFIG_SMP_ON_UP +# define v7wbi_possible_flags (v7wbi_tlb_flags_smp | v7wbi_tlb_flags_up) +# define v7wbi_always_flags (v7wbi_tlb_flags_smp v7wbi_tlb_flags_up) +# elif defined(CONFIG_SMP) +# define v7wbi_possible_flags v7wbi_tlb_flags_smp +# define v7wbi_always_flags v7wbi_tlb_flags_smp +# else +# define v7wbi_possible_flags v7wbi_tlb_flags_up +# define v7wbi_always_flags v7wbi_tlb_flags_up +# endif # ifdef _TLB # define MULTI_TLB 1 # else diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S index bb8e93a..bb2ef60 100644 --- a/arch/arm/kernel/entry-armv.S +++ b/arch/arm/kernel/entry-armv.S @@ -965,11 +965,8 @@ kuser_cmpxchg_fixup: beq 1b rsbsr0, r3, #0 /* beware -- each __kuser slot must be 8
RE: [PATCH 8/8 v2] usb : musb: Using runtime pm apis for musb.
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Tuesday, August 31, 2010 8:54 PM
To: Kalliguddi, Hema
Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org;
Basak, Partha; Felipe Balbi; Tony Lindgren; Cousson, Benoit;
Paul Walmsley
Subject: Re: [PATCH 8/8 v2] usb : musb: Using runtime pm apis for musb.
Kalliguddi, Hema hem...@ti.com writes:
static int musb_platform_resume(struct musb *musb)
{
u32 l;
+struct device *dev = musb-controller;
+struct musb_hdrc_platform_data *pdata = dev-platform_data;
+struct platform_device *pdev = to_platform_device(dev);
if (!musb-clock)
return 0;
otg_set_suspend(musb-xceiv, 0);
-
-if (musb-set_clock)
-musb-set_clock(musb-clock, 1);
-else
-clk_enable(musb-clock);
-
-l = musb_readl(musb-mregs, OTG_SYSCONFIG);
-l = ~ENABLEWAKEUP; /* disable wakeup */
-musb_writel(musb-mregs, OTG_SYSCONFIG, l);
-
+pm_runtime_enable(dev);
+pm_runtime_get_sync(dev);
+pdata-enable_wakeup(pdev);
I think you mean -disable_wakeup() here, right?
No I meant enable_wakeup only here. When smart idle/standby
is enabled,
wakeup bit has to be set to generate the s-wakeup when the
devie is in idle
and system is in ret.
OK, I'm confused.
The code being removed just above disables wakeups and the new code
enables wakeups.
The old code was not correct. The wakeup enable make sense only when the smart
idle/smart
Standby is enabled. And with get_sync musb is configured to be in smart
idle/standby mode.
Also, you don't ever call -disable_wakeup() elsewhere in the patch.
You call pdata-enable_wakeup() both in suspend and resume.
Disable_wkaeup is not required now as there is no need of disabling this bit
because with force idle/standby
there is no use of wakeup enable/disable bit.
Anyway again, we need have these APIs if Rajendra is going to post the patch to
enable wkaeup in the
framework if smart idle/standby is enabled.
Kevin
--
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: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver
Dmitry, thanks for the review. Comments inline. Hemanth - Original Message - From: Dmitry Torokhov dmitry.torok...@gmail.com To: Hemanth V heman...@ti.com Cc: linux-in...@vger.kernel.org; linux-ker...@vger.kernel.org; linux-omap@vger.kernel.org Sent: Monday, August 30, 2010 12:19 AM Subject: Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver Hi Hemanth, On Fri, May 21, 2010 at 12:22:57PM +0530, Hemanth V wrote: From: Hemanth V heman...@ti.com Date: Thu, 20 May 2010 20:18:17 +0530 Subject: [PATCH] input: CMA3000 Accelerometer Driver This patch adds support for CMA3000 Tri-axis accelerometer, which supports Motion detect, Measurement and Free fall modes. CMA3000 supports both I2C/SPI bus for communication, currently the driver supports I2C based communication. Driver reports acceleration data through input subsystem and supports sysfs for configuration changes. This is V2 of patch, which fixes open source review comments Signed-off-by: Hemanth V heman...@ti.com Cc: Dmitry Torokhov dmitry.torok...@gmail.com --- Documentation/input/cma3000_d0x.txt | 112 ++ drivers/input/misc/Kconfig |7 + drivers/input/misc/Makefile |1 + drivers/input/misc/cma3000_d0x.c | 633 ++ drivers/input/misc/cma3000_d0x.h | 46 +++ drivers/input/misc/cma3000_d0x_i2c.c | 136 include/linux/i2c/cma3000.h | 60 7 files changed, 995 insertions(+), 0 deletions(-) create mode 100644 Documentation/input/cma3000_d0x.txt create mode 100644 drivers/input/misc/cma3000_d0x.c create mode 100644 drivers/input/misc/cma3000_d0x.h create mode 100644 drivers/input/misc/cma3000_d0x_i2c.c create mode 100644 include/linux/i2c/cma3000.h diff --git a/Documentation/input/cma3000_d0x.txt b/Documentation/input/cma3000_d0x.txt new file mode 100644 index 000..29ab6b7 --- /dev/null +++ b/Documentation/input/cma3000_d0x.txt @@ -0,0 +1,112 @@ +Kernel driver for CMA3000-D0x + + +Supported chips: +* VTI CMA3000-D0x +Datasheet: + CMA3000-D0X Product Family Specification 8281000A.02.pdf + +Author: Hemanth V heman...@ti.com + + +Description +--- +CMA3000 Tri-axis accelerometer supports Motion detect, Measurement and +Free fall modes. + +Motion Detect Mode: Its the low power mode where interrupts are generated only +when motion exceeds the defined thresholds. + +Measurement Mode: This mode is used to read the acceleration data on X,Y,Z +axis and supports 400, 100, 40 Hz sample frequency. + +Free fall Mode: This mode is intented to save system resources. + +Threshold values: Chip supports defining threshold values for above modes +which includes time and g value. Refer product specifications for more details. + +CMA3000 supports both I2C/SPI bus for communication, currently the driver +supports I2C based communication. + +Driver reports acceleration data through input subsystem and supports sysfs +for configuration changes. It generates ABS_MISC event with value 1 when +free fall is detected. + +Platform data need to be configured for initial default values. + +Platform Data +- +fuzz_x: Noise on X Axis + +fuzz_y: Noise on Y Axis + +fuzz_z: Noise on Z Axis + +g_range: G range in milli g i.e 2000 or 8000 + +mode: Default Operating mode + +mdthr: Motion detect threshold value + +mdfftmr: Motion detect and free fall time value + +ffthr: Free fall threshold value + +Input Interface +-- +Input driver version is 1.0.0 +Input device ID: bus 0x18 vendor 0x0 product 0x0 version 0x0 +Input device name: cma3000-acclerometer +Supported events: + Event type 0 (Sync) + Event type 3 (Absolute) +Event code 0 (X) + Value 47 + Min-8000 + Max 8000 + Fuzz 200 +Event code 1 (Y) + Value-28 + Min-8000 + Max 8000 + Fuzz 200 +Event code 2 (Z) + Value905 + Min-8000 + Max 8000 + Fuzz 200 +Event code 40 (Misc) + Value 0 + Min0 + Max1 + Event type 4 (Misc) + +Sysfs entries +- + +mode: + 0: power down mode + 1: 100 Hz Measurement mode + 2: 400 Hz Measurement mode + 3: 40 Hz Measurement mode + 4: Motion Detect mode (default) + 5: 100 Hz Free fall mode + 6: 40 Hz Free fall mode + 7: Power off mode + +grange: + 2000: 2000 mg or 2G Range + 8000: 8000 mg or 8G Range + +mdthr: + X: X * 71mg (8G Range) + X: X * 18mg (2G Range) + +mdfftmr: + X: (X 0x70) * 100 ms (MDTMR) +(X 0x0F) * 2.5 ms (FFTMR 400 Hz) +(X 0x0F) * 10 ms (FFTMR 100 Hz) + +ffthr: + X: (X 2) * 18mg (2G Range) + X: (X 0x0F) * 71 mg (8G Range) diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig index 1cf25ee..043ee8d 100755 --- a/drivers/input/misc/Kconfig +++ b/drivers/input/misc/Kconfig @@ -340,4 +340,11 @@ To compile this driver as a module, choose M here: the module will be called pcap_keys. +config
Re: [PATCH 1/1] crypto: omap-sham: Adjust DMA parameters
On Thu, Sep 02, 2010 at 05:17:35PM +0300, Dmitry Kasatkin wrote: From: Samu Onkalo samu.p.onk...@nokia.com DMA is set to use burst mode also for source channel. It should descrease memory bandwidth needs. DMA synchronization is set to use prefetch mechanism. SHAM block is behind L4 bus and it doesn't have fifo. SHAM block is stalling as long as the new data is available. It takes time to fetch data from memory and transfer it via L4 bus. With prefetch enabled, data is waiting in DMA fifo and SHAM block receives new data block faster. This increases SHA processing speed up to 30 percent depending on the bus / memory load. Signed-off-by: Samu Onkalo samu.p.onk...@nokia.com Signed-off-by: Dmitry Kasatkin dmitry.kasat...@nokia.com Patch applied. Thanks! -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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/6] ARM: Use SMP and UP macros for cacheflush
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Thursday, September 02, 2010 9:50 PM To: Russell King - ARM Linux Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Bryan Wu; Will Deacon Subject: [PATCH 2/6] ARM: Use SMP and UP macros for cacheflush From 16c866489613ef8ea9d28ecf861f5a7ff4d60377 Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Thu, 2 Sep 2010 08:20:02 -0700 Subject: [PATCH 2/6] ARM: Use SMP and UP macros for cacheflush Use SMP and UP macros for cacheflush. Note that __flush_icache_all currently won't work properly on ARMv7 SMP if support for ARMv6 is compiled in. Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/include/asm/cacheflush.h |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h index 4656a24..09a893e 100644 --- a/arch/arm/include/asm/cacheflush.h +++ b/arch/arm/include/asm/cacheflush.h @@ -16,6 +16,7 @@ #include asm/shmparam.h #include asm/cachetype.h #include asm/outercache.h +#include asm/smp_plat.h #define CACHE_COLOUR(vaddr) ((vaddr (SHMLBA - 1)) PAGE_SHIFT) @@ -372,8 +373,10 @@ static inline void __flush_icache_all(void) extern void v6_icache_inval_all(void); v6_icache_inval_all(); #elif defined(CONFIG_SMP) __LINUX_ARM_ARCH__ = 7 - asm(mcrp15, 0, %0, c7, c1, 0 @ invalidate I-cache inner shareable\n - : + asm(\ + SMP(mcr p15, 0, %0, c7, c1, 0 @ inv I-cache inner shareable) \ + UP(mcr p15, 0, %0, c7, c5, 0 @ invalidate I-cache) \ + : \ : r (0)); #else asm(mcrp15, 0, %0, c7, c5, 0 @ invalidate I-cache\n Since UP/SMP both cases are handled, the above patch can be something like this now... diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h index 9792a71..ebdff42 100644 --- a/arch/arm/include/asm/cacheflush.h +++ b/arch/arm/include/asm/cacheflush.h @@ -16,6 +16,7 @@ #include asm/shmparam.h #include asm/cachetype.h #include asm/outercache.h +#include asm/smp_plat.h #define CACHE_COLOUR(vaddr)((vaddr (SHMLBA - 1)) PAGE_SHIFT) @@ -394,13 +395,11 @@ static inline void __flush_icache_all(void) #ifdef CONFIG_ARM_ERRATA_411920 extern void v6_icache_inval_all(void); v6_icache_inval_all(); -#elif defined(CONFIG_SMP) __LINUX_ARM_ARCH__ = 7 - asm(mcrp15, 0, %0, c7, c1, 0 @ invalidate I-cache inner shareable\n - : - : r (0)); #else - asm(mcrp15, 0, %0, c7, c5, 0 @ invalidate I-cache\n - : + asm(\ + SMP(mcr p15, 0, %0, c7, c1, 0 @ inv I-cache inner shareable) \ + UP(mcr p15, 0, %0, c7, c5, 0 @ invalidate I-cache) \ + : \ : r (0)); #endif } -- 1.6.0.4 -- 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/6] ARM: Add inline function smp_on_up() for early init testing
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Tony Lindgren
Sent: Thursday, September 02, 2010 11:13 PM
To: Russell King - ARM Linux
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
Bryan Wu; Will Deacon
Subject: Re: [PATCH 1/6] ARM: Add inline function smp_on_up() for early
init testing
* Russell King - ARM Linux li...@arm.linux.org.uk [100902 10:00]:
On Thu, Sep 02, 2010 at 09:18:47AM -0700, Tony Lindgren wrote:
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -39,4 +39,20 @@ static inline int cache_ops_need_broadcast(void)
#define UP(instr...) _str(instr)
#endif
+static inline int smp_on_up(void)
+{
+#ifdef CONFIG_SMP_ON_UP
+ int smp_on_up;
+
+ asm(\
+ SMP(mov %0, #0) \
+ UP(mov %0, #1) \
+ : =r (smp_on_up));
+
+ return smp_on_up;
+#else
+ return 0;
+#endif
I think this is the wrong approach - rather than a function which tells
us
just if we are a SMP kernel running on UP, why not something which
returns
whether we're running on SMP and use that to eliminate some of these
ifdefs?
Sure. Will has something like this in his patches:
static inline int cpu_is_part_of_mp_system(void)
{
u32 mpidr;
asm volatile(mrc p15, 0, %0, c0, c0, 5 : =r (mpidr));
return (mpidr 31) ? !(mpidr 30) : 0;
}
I guess this register is only available on MP Core extensions.
Regards,
Santosh
--
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 6/6] omap: Fix SMP on UP interrupt handling for multi-omap
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Friday, September 03, 2010 1:00 AM To: Russell King - ARM Linux Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Bryan Wu; Will Deacon Subject: Re: [PATCH 6/6] omap: Fix SMP on UP interrupt handling for multi- omap * Tony Lindgren t...@atomide.com [100902 09:16]: From c04a57fc3b41d886f56ccdc27cf9758de0c95202 Mon Sep 17 00:00:00 2001 From: Tony Lindgren t...@atomide.com Date: Tue, 17 Aug 2010 13:33:23 +0300 Subject: [PATCH 6/6] omap: Fix SMP on UP interrupt handling for multi- omap Fix SMP on UP interrupt handling for multi-omap Here's this one updated to use !smp_cpu() instead of smp_on_up(). Looks like the description and subject needed some refreshing too. As I commented on other patch we should just avoid doing anything When the CPU is not OMAP4. Regards, Santosh -- 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/6] ARM: Add inline function smp_cpu() for early init testing
-Original Message-
From: Will Deacon [mailto:will.dea...@arm.com]
Sent: Friday, September 03, 2010 5:54 PM
To: Shilimkar, Santosh; Tony Lindgren; Russell King - ARM Linux
Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
Bryan Wu
Subject: RE: [PATCH 1/6] ARM: Add inline function smp_cpu() for early init
testing
Santosh,
diff --git a/arch/arm/include/asm/smp_plat.h
b/arch/arm/include/asm/smp_plat.h
index 8db3512..82bc488 100644
--- a/arch/arm/include/asm/smp_plat.h
+++ b/arch/arm/include/asm/smp_plat.h
@@ -39,4 +39,11 @@ static inline int cache_ops_need_broadcast(void)
#define UP(instr...) _str(instr)
#endif
+static inline int smp_cpu(void)
+{
+u32 mpidr;
+asm volatile(mrc p15, 0, %0, c0, c0, 5 : =r (mpidr));
+return (mpidr 31) ? !(mpidr 30) : 0;
+}
+
Will this be called on UP machines ?? if yes, then mpidr register is not
available on those
The multiprocessor affinity register (MPIDR) is defined as part of ARMv7.
ARM recommends that it returns 0 on UP systems. If bit 31 is set, then the
multiprocessing extensions are available.
I might be wrong but didn't find this register on Cortex-A8(ARMv7).
The quirk (as discussed early) is that that 11MPCore has the CPUID
register
at this location in the coprocessor space, with bit 31 set to 0. This
means
that we have to check for it explicitly otherwise we will identify it as a
UP machine.
Will
--
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/3] omap3/omap4 hsmmc: Register offset handling
kishore kadiyala kishorek.kadiy...@gmail.com writes: Hi Benoit snip + while (!(omap_readl(base + reg_off) MMCHS_SYSSTATUS_RESETDONE)) cpu_relax(); Why does that series not seems to be based on your hwmod migration? The reset is fully handle by the hwmod framework now. Agree. But Kevin has suggested to post this patch independent of hwmod. Does this patch has to go in hwmod series ? I suggested that this register conversion patch could be merged before the hwmod conversion as it is independent of that. The hwmod conversion (based on this series) would then just remove the reset from here. Kevin -- 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/3] omap3/omap4 hsmmc: Register offset handling
On 9/3/2010 5:44 PM, Kevin Hilman wrote: kishore kadiyalakishorek.kadiy...@gmail.com writes: Hi Benoit snip + while (!(omap_readl(base + reg_off) MMCHS_SYSSTATUS_RESETDONE)) cpu_relax(); Why does that series not seems to be based on your hwmod migration? The reset is fully handle by the hwmod framework now. Agree. But Kevin has suggested to post this patch independent of hwmod. Does this patch has to go in hwmod series ? I suggested that this register conversion patch could be merged before the hwmod conversion as it is independent of that. OK, I missed that part. I was surprised because the hwmod series was sent before that one. Benoit -- 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 00/11] OMAP: DMA: HWMOD and DMA as platform driver
Kevin, If there are no further comments, can you please stage this patch series on hwmods-omap4 branch? It applies cleanly on current commit(669d24d412380528158ba5d15522c9858f4b81a2). -Manjunath -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of G, Manjunath Kondaiah Sent: Tuesday, August 24, 2010 4:34 PM To: linux-omap@vger.kernel.org Cc: Cousson, Benoit; Kevin Hilman; Shilimkar, Santosh Subject: [PATCH v2 00/11] OMAP: DMA: HWMOD and DMA as platform driver This patch series has review comments incorporated which are received for v1 version. The review comments can be found at: http://www.spinics.net/lists/linux-omap/msg34291.html http://www.spinics.net/lists/linux-omap/msg34292.html http://www.spinics.net/lists/linux-omap/msg34078.html http://www.spinics.net/lists/linux-omap/msg34083.html These changes are tested on following boards: - Zoom3 (OMAP3630) - Beagle(OMAP3530) - OMAP4 SDP (OMAP4430) I don't have omap1 and omap2 boards and appreciate if some one can test these boards and provides feedback. Build tested for both omap1 and omap2 plus boards. This patch series applies on top of: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-om ap-pm.git Branch: pm-wip/hwmods-omap4 commit f6f7f1103b80b4dc0ace8a0314d95d1b1ebca726 Merge: 79d0b02 597e89c Author: Kevin Hilman khil...@ti.com Merge branch 'pm-wip/hwmods' into pm-wip/hwmods-omap4-base The earlier version of the patches can be found at: RFC patches: http://www.spinics.net/lists/linux-omap/index.html#33393 v1 patches: http://www.spinics.net/lists/linux-omap/msg34066.html Patch series summary: = Manjunatha GK (10): OMAP: DMA: Introduce DMA device attributes OMAP2420: DMA: HWMOD: Add hwmod data structures OMAP2430: DMA: HWMOD: Add hwmod data structures OMAP3: DMA: HWMOD: Add hwmod data structures OMAP4: DMA: HWMOD: Add hwmod data structures OMAP1: DMA: Introduce DMA driver as platform driver OMAP2/3/4: DMA: HWMOD: Device registration OMAP: DMA: Convert DMA library into DMA platform Driver OMAP: DMA: Implement generic errata handling OMAP: DMA: Use DMA device attributes Venkatraman S (1): sDMA: descriptor autoloading feature arch/arm/mach-omap1/Makefile |2 +- arch/arm/mach-omap1/dma.c | 451 arch/arm/mach-omap1/include/mach/dma.h | 148 +++ arch/arm/mach-omap2/Makefile |2 +- arch/arm/mach-omap2/dma.c | 1380 + arch/arm/mach-omap2/include/mach/dma.h | 378 +++ arch/arm/mach-omap2/omap_hwmod_2420_data.c | 85 ++ arch/arm/mach-omap2/omap_hwmod_2430_data.c | 85 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 85 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 99 ++ arch/arm/plat-omap/dma.c | 1539 arch/arm/plat-omap/include/plat/dma.h | 222 +--- 12 files changed, 2945 insertions(+), 1531 deletions(-) create mode 100644 arch/arm/mach-omap1/dma.c create mode 100644 arch/arm/mach-omap1/include/mach/dma.h create mode 100644 arch/arm/mach-omap2/dma.c create mode 100644 arch/arm/mach-omap2/include/mach/dma.h Cc: Benoit Cousson b-cous...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Santosh Shilimkar santosh.shilim...@ti.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 -- 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: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver
Hi Hemanth,
On Fri, Sep 03, 2010 at 04:02:11PM +0530, Hemanth V wrote:
Do not like repeated release of resources in main and error path... Can
we do it like:
...
disable_irq();
error = cma3000_set(data, CMA3000_CTRL, ctrl, ctrl);
if (!error) {
/* Settling time delay required after mode change */
msleep(CMA3000_SETDELAY);
}
enable_irq();
out:
mutex_unlock();
return error ? error : count;
I am thinking I can just add the below statement, and should be able to
remove repeated release.
return error ? error : count;
That would make us sleep for CMA3000_SETDELAY even in case of failure...
... But that should be OK.
+
+ if (data-client-irq) {
+ ret = request_threaded_irq(data-client-irq, NULL,
+ cma3000_thread_irq,
+ irqflags | IRQF_ONESHOT,
+ data-client-name, data);
+
+ if (ret 0) {
+ dev_err(data-client-dev,
+ request_threaded_irq failed\n);
+ goto err_op1_failed;
+ }
+ }
What is the utility of the driver when there is no IRQ line?
Not sure I fully understand your comments.
Currently probe would return a failure.
You have a check for data-client-irq != 0 and finish probe() with
success in case it is 0. The question is what is the use of the
device/driver combo in case when data-client-irq == 0?
--
Dmitry
--
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 00/11] OMAP: DMA: HWMOD and DMA as platform driver
Hi Manjunath, On 9/3/2010 6:21 PM, G, Manjunath Kondaiah wrote: Kevin, If there are no further comments, can you please stage this patch series on hwmods-omap4 branch? I just have few minor comments: Could you please keep the original credit for this patch: OMAP4: DMA: HWMOD: Add hwmod data structures You can change as well the subject as suggested by Kevin for all the hwmod data patches with: OMAPX: hwmod data: Add system DMA And quoting Kevin again hwmod should not be capitalized, as it's not an acronym. Thanks, Benoit It applies cleanly on current commit(669d24d412380528158ba5d15522c9858f4b81a2). -Manjunath -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of G, Manjunath Kondaiah Sent: Tuesday, August 24, 2010 4:34 PM To: linux-omap@vger.kernel.org Cc: Cousson, Benoit; Kevin Hilman; Shilimkar, Santosh Subject: [PATCH v2 00/11] OMAP: DMA: HWMOD and DMA as platform driver This patch series has review comments incorporated which are received for v1 version. The review comments can be found at: http://www.spinics.net/lists/linux-omap/msg34291.html http://www.spinics.net/lists/linux-omap/msg34292.html http://www.spinics.net/lists/linux-omap/msg34078.html http://www.spinics.net/lists/linux-omap/msg34083.html These changes are tested on following boards: - Zoom3 (OMAP3630) - Beagle(OMAP3530) - OMAP4 SDP (OMAP4430) I don't have omap1 and omap2 boards and appreciate if some one can test these boards and provides feedback. Build tested for both omap1 and omap2 plus boards. This patch series applies on top of: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-om ap-pm.git Branch: pm-wip/hwmods-omap4 commit f6f7f1103b80b4dc0ace8a0314d95d1b1ebca726 Merge: 79d0b02 597e89c Author: Kevin Hilmankhil...@ti.com Merge branch 'pm-wip/hwmods' into pm-wip/hwmods-omap4-base The earlier version of the patches can be found at: RFC patches: http://www.spinics.net/lists/linux-omap/index.html#33393 v1 patches: http://www.spinics.net/lists/linux-omap/msg34066.html Patch series summary: = Manjunatha GK (10): OMAP: DMA: Introduce DMA device attributes OMAP2420: DMA: HWMOD: Add hwmod data structures OMAP2430: DMA: HWMOD: Add hwmod data structures OMAP3: DMA: HWMOD: Add hwmod data structures OMAP4: DMA: HWMOD: Add hwmod data structures OMAP1: DMA: Introduce DMA driver as platform driver OMAP2/3/4: DMA: HWMOD: Device registration OMAP: DMA: Convert DMA library into DMA platform Driver OMAP: DMA: Implement generic errata handling OMAP: DMA: Use DMA device attributes Venkatraman S (1): sDMA: descriptor autoloading feature arch/arm/mach-omap1/Makefile |2 +- arch/arm/mach-omap1/dma.c | 451 arch/arm/mach-omap1/include/mach/dma.h | 148 +++ arch/arm/mach-omap2/Makefile |2 +- arch/arm/mach-omap2/dma.c | 1380 + arch/arm/mach-omap2/include/mach/dma.h | 378 +++ arch/arm/mach-omap2/omap_hwmod_2420_data.c | 85 ++ arch/arm/mach-omap2/omap_hwmod_2430_data.c | 85 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 85 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 99 ++ arch/arm/plat-omap/dma.c | 1539 arch/arm/plat-omap/include/plat/dma.h | 222 +--- 12 files changed, 2945 insertions(+), 1531 deletions(-) create mode 100644 arch/arm/mach-omap1/dma.c create mode 100644 arch/arm/mach-omap1/include/mach/dma.h create mode 100644 arch/arm/mach-omap2/dma.c create mode 100644 arch/arm/mach-omap2/include/mach/dma.h Cc: Benoit Coussonb-cous...@ti.com Cc: Kevin Hilmankhil...@deeprootsystems.com Cc: Santosh Shilimkarsantosh.shilim...@ti.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 -- 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 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
+ Mark, Liam for regulator questions, thread in archives here: http://marc.info/?l=linux-omapm=128349777617270w=2 Gopinath, Thara th...@ti.com writes: -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, September 02, 2010 4:22 AM To: Gopinath, Thara Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Sripathy, Vishwanath; Sawant, Anand; Cousson, Benoit; thomas.petazz...@free-electrons.com Subject: Re: [PATCH 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver. Thara Gopinath th...@ti.com writes: This patch introduces a user list of devices associated with each voltage domain instance. The user list is implemented using plist structure with priority node populated with the voltage values. This patch also adds an API which will take in a device and requested voltage as parameters, adds the info to the user list and returns back the maximum voltage requested by all the user devices. This can be used anytime to get the voltage that the voltage domain instance can be transitioned into. Signed-off-by: Thara Gopinath th...@ti.com Looking closer at this, keeping track of a list of devices and constraints is what the regulator framework does as well. Before we get too far down this path, we need to start working with Thomas Petazzoni to better understand how we can use the regulator framework for much of the management levels of the voltage layer. I'd rather not re-invent some of the management/constraints management that could be done by the regulator framework. Basically, I think r = regulator_get(dev, voltdm-name) regulator_set_voltage(r, volt) would basially be the equivalent of omap_voltage_add_userreq(voldm, dev, volt); omap_scale_voltage(voltdm, volt) Hello Kevin, Let me startr off by saying that I am not an expert on regulator framework and hence my assessment below could be wrong. I agree probably regulator framework would be the best place for this but then IMO regulator framework needs a lot of changes to support the kind of use-counting we need in the voltage layer. To start with regulator_get keeps the use counting only for enabling or disabling a regulator. It does not have a mechanism of adding the requested voltage to a list and picking out the highest among the added values. Like you, I'm no expert on the regulator framework internals, but it appears to have a pretty thorough system of constraints management that upon first glance seems to be a good fit for what we need. It may need to be extended, but I would rather see us enhance the regulator framework than re-invent the constraints management. regulator_set_voltage could be used to route the call to omap_scale_voltage but then it is just a wrapper. Yes, just a wrapper, but users would be then using a a well defined and well documented API. Kevin -- 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 00/11] OMAP: DMA: HWMOD and DMA as platform driver
G, Manjunath Kondaiah manj...@ti.com writes: If there are no further comments, can you please stage this patch series on hwmods-omap4 branch? I have not yet reviewed this series. I hope to get to it today. Sorry for the lag, but there have been *lots* of PM related patches posted in the last month, and it's hard to do a thorough review and keep up. Kevin It applies cleanly on current commit(669d24d412380528158ba5d15522c9858f4b81a2). -Manjunath -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of G, Manjunath Kondaiah Sent: Tuesday, August 24, 2010 4:34 PM To: linux-omap@vger.kernel.org Cc: Cousson, Benoit; Kevin Hilman; Shilimkar, Santosh Subject: [PATCH v2 00/11] OMAP: DMA: HWMOD and DMA as platform driver This patch series has review comments incorporated which are received for v1 version. The review comments can be found at: http://www.spinics.net/lists/linux-omap/msg34291.html http://www.spinics.net/lists/linux-omap/msg34292.html http://www.spinics.net/lists/linux-omap/msg34078.html http://www.spinics.net/lists/linux-omap/msg34083.html These changes are tested on following boards: - Zoom3 (OMAP3630) - Beagle(OMAP3530) - OMAP4 SDP (OMAP4430) I don't have omap1 and omap2 boards and appreciate if some one can test these boards and provides feedback. Build tested for both omap1 and omap2 plus boards. This patch series applies on top of: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-om ap-pm.git Branch: pm-wip/hwmods-omap4 commit f6f7f1103b80b4dc0ace8a0314d95d1b1ebca726 Merge: 79d0b02 597e89c Author: Kevin Hilman khil...@ti.com Merge branch 'pm-wip/hwmods' into pm-wip/hwmods-omap4-base The earlier version of the patches can be found at: RFC patches: http://www.spinics.net/lists/linux-omap/index.html#33393 v1 patches: http://www.spinics.net/lists/linux-omap/msg34066.html Patch series summary: = Manjunatha GK (10): OMAP: DMA: Introduce DMA device attributes OMAP2420: DMA: HWMOD: Add hwmod data structures OMAP2430: DMA: HWMOD: Add hwmod data structures OMAP3: DMA: HWMOD: Add hwmod data structures OMAP4: DMA: HWMOD: Add hwmod data structures OMAP1: DMA: Introduce DMA driver as platform driver OMAP2/3/4: DMA: HWMOD: Device registration OMAP: DMA: Convert DMA library into DMA platform Driver OMAP: DMA: Implement generic errata handling OMAP: DMA: Use DMA device attributes Venkatraman S (1): sDMA: descriptor autoloading feature arch/arm/mach-omap1/Makefile |2 +- arch/arm/mach-omap1/dma.c | 451 arch/arm/mach-omap1/include/mach/dma.h | 148 +++ arch/arm/mach-omap2/Makefile |2 +- arch/arm/mach-omap2/dma.c | 1380 + arch/arm/mach-omap2/include/mach/dma.h | 378 +++ arch/arm/mach-omap2/omap_hwmod_2420_data.c | 85 ++ arch/arm/mach-omap2/omap_hwmod_2430_data.c | 85 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 85 ++ arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 99 ++ arch/arm/plat-omap/dma.c | 1539 arch/arm/plat-omap/include/plat/dma.h | 222 +--- 12 files changed, 2945 insertions(+), 1531 deletions(-) create mode 100644 arch/arm/mach-omap1/dma.c create mode 100644 arch/arm/mach-omap1/include/mach/dma.h create mode 100644 arch/arm/mach-omap2/dma.c create mode 100644 arch/arm/mach-omap2/include/mach/dma.h Cc: Benoit Cousson b-cous...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Santosh Shilimkar santosh.shilim...@ti.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 -- 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] ARM: Fix v7wbi_tlb_flags for SMP on UP
* Russell King - ARM Linux li...@arm.linux.org.uk [100903 02:02]: On Fri, Sep 03, 2010 at 10:07:34AM +0100, Russell King - ARM Linux wrote: On Thu, Sep 02, 2010 at 04:47:46PM -0700, Tony Lindgren wrote: Correction, only boots on SMP hardawre. On UP hardware I still need the following patch. This should fix that properly. Correction - the order of the config tests was wrong. OK that works now. Looks like your new patch is missing smp_midr.h BTW. 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 00/10] split out emac cpdma and mdio for reuse
Cyril Chemparathy cy...@ti.com writes: [...] Although am3517 (omap) board support code has been updated as needed, emac does not work on this platform. Just to clarify... did EMAC work on AM3517 before this series? Kevin -- 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 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
On Fri, Sep 03, 2010 at 09:41:11AM -0700, Kevin Hilman wrote: Like you, I'm no expert on the regulator framework internals, but it appears to have a pretty thorough system of constraints management that upon first glance seems to be a good fit for what we need. It may need to be extended, but I would rather see us enhance the regulator framework than re-invent the constraints management. This seems reasonable, the only thing I'm wary of with this stuff is adding things to manage anything outside voltages since I'm not convinced that the requirements of different processors for other things are sufficiently well understood to make a simple abstraction. The only thing I can think you might need to do if this is just straight voltage setting is re-add support for multiple consumers setting voltages simultaneously (there was someone from Qualcomm talking about that as well but I didn't see any patches from him) but the API side is all there and the core support ought to be relatively straightforward. -- 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] I2C: Fix for suspend/resume issue in i2c-core
-Original Message-
From: Jean Delvare [mailto:kh...@linux-fr.org]
Sent: Wednesday, September 01, 2010 2:11 PM
To: Rafael J. Wysocki
Cc: Mark Brown; Kevin Hilman; Sripathy, Vishwanath; linux-...@vger.kernel.org;
linux-omap@vger.kernel.org; Basak, Partha; Ben Dooks
Subject: Re: [PATCH] I2C: Fix for suspend/resume issue in i2c-core
On Wed, 1 Sep 2010 01:12:11 +0200, Rafael J. Wysocki wrote:
On Tuesday, August 31, 2010, Mark Brown wrote:
On Mon, Aug 30, 2010 at 11:43:23AM -0700, Kevin Hilman wrote:
Vishwanath BS vishwanath...@ti.com writes:
In current i2c core driver, pm_runtime_set_active call from
i2c_device_pm_resume
is not balanced by pm_runtime_set_suspended call from
i2c_device_pm_suspend.
pm_runtime_set_active called from resume path will increase the
child_count of
the device's parent. However, matching pm_runtime_set_suspended is not
called
in suspend routine because of which child_count of the device's parent
is not balanced, preventing the parent device to idle.
Issue has been fixed by adding pm_runtime_set_suspended call inside
suspend
reoutine which will make sure that child_counts are balanced.
This fix has been tested on OMAP4430.
Signed-off-by: Partha Basak p-bas...@ti.com
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Ben Dooks ben-li...@fluff.org
Also Cc'ing Mark Brown as original author of runtime PM for i2-core.
Also Jean Delvare who maintains the I2C core. To be honest Rafael did
all the actual work here (and has since rewritten the code anyway).
Sorry for the delay.
The fix looks reasonable to me.
I take this as an Acked-by. Patch applied, thanks.
Hi,
We are seeing one more issue even after making this fix. In summary, after
first suspend/resume, CPU Idle no longer works since i2c module is active.
Basically when the system resumed from the suspend, dpm layer (dpm_resume_end)
calls device_resume which intern calls i2c_device_pm_resume (among many other
calls).
i2c_device_pm_resume calls pm_runtime_set_active which brings device to Active
state and increases child_count of it's parent. Since the device is active and
also it's parent child_count is non 0, these modules will prevent corresponding
clock domains to go idle. This will break CPU Idle. This issue happens even if
the module was in idle state before performing suspend/resume. In summary, the
flow is
1. i2c module is idle (let's assume system is idle)
2. system suspend is initiated by user
3. i2c_device_pm_suspend gets called which tries to idle i2c, but it's already
idled.
4. system is suspended
5. system resumed (because of user event/timers)
6. dpm layer will call i2c_device_pm_resume
7. i2c_device_pm_resume will enable i2c device by calling pm_runtime_set_active
So at the end of suspend/resume, a device that was idled before is getting
enabled unnecessarily at the end.
SO I am just wondering is there any real need to call pm_runtime_set_active in
resume and pm_runtime_set_suspened in suspend functions?
I just tried suspend/resume and CPU Idle after removing these calls in i2c and
it seems to function perfectly fine on OMAP4.
Regards
Vishwa
I
---
drivers/i2c/i2c-core.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 6649176..3146bff
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -196,14 +196,22 @@ static int i2c_legacy_resume(struct device *dev)
static int i2c_device_pm_suspend(struct device *dev)
{
const struct dev_pm_ops *pm = dev-driver ? dev-driver-pm :
NULL;
+ int ret;
if (pm_runtime_suspended(dev))
return 0;
if (pm)
- return pm-suspend ? pm-suspend(dev) : 0;
+ ret = pm-suspend ? pm-suspend(dev) : 0;
+ else
+ ret = i2c_legacy_suspend(dev, PMSG_SUSPEND);
- return i2c_legacy_suspend(dev, PMSG_SUSPEND);
+ if (!ret) {
+ pm_runtime_disable(dev);
+ pm_runtime_set_suspended(dev);
+ pm_runtime_enable(dev);
+ }
+ return ret;
}
static int i2c_device_pm_resume(struct device *dev)
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Jean Delvare
--
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 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
Mark Brown broo...@opensource.wolfsonmicro.com writes: On Fri, Sep 03, 2010 at 09:41:11AM -0700, Kevin Hilman wrote: Like you, I'm no expert on the regulator framework internals, but it appears to have a pretty thorough system of constraints management that upon first glance seems to be a good fit for what we need. It may need to be extended, but I would rather see us enhance the regulator framework than re-invent the constraints management. This seems reasonable, the only thing I'm wary of with this stuff is adding things to manage anything outside voltages since I'm not convinced that the requirements of different processors for other things are sufficiently well understood to make a simple abstraction. Mark, thanks for your input. For now, at least on OMAP, we're only thinking of managing voltages for the primary voltage rails on chip. We already have well defined layers for managing our power domains and clockdomains and prefer to keep that as OMAP-internal code, as it's nothing that drivers really need to be aware of. The only thing I can think you might need to do if this is just straight voltage setting is re-add support for multiple consumers setting voltages simultaneously Yeah, that sounds like what we need. re-add? was it there at one point and removed? Any pointers to the old code? (there was someone from Qualcomm talking about that as well but I didn't see any patches from him) but the API side is all there and the core support ought to be relatively straightforward. OK, thanks for the feedback. Kevin -- 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 00/10] split out emac cpdma and mdio for reuse
Hi Kevin, [...] Although am3517 (omap) board support code has been updated as needed, emac does not work on this platform. Just to clarify... did EMAC work on AM3517 before this series? No. It didn't work before this series. To get AM3517 EMAC working, the driver needs another patch to enable the interface clock in addition to the functional clock. Regards Cyril. -- 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 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
On Fri, Sep 03, 2010 at 11:00:31AM -0700, Kevin Hilman wrote: Mark Brown broo...@opensource.wolfsonmicro.com writes: The only thing I can think you might need to do if this is just straight voltage setting is re-add support for multiple consumers setting voltages simultaneously Yeah, that sounds like what we need. re-add? was it there at one point and removed? Any pointers to the old code? It was present in the pre-merge regulator API which you can find in the bowels of: git://opensource.wolfsonmicro.com/linux-2.6-audioplus but was removed to simplify review during the merge. It's fairly simple to do, it's just that there's been no demand. Essentially all that needs doing is that when regulator_set_voltage() is called instead of merging with the machine constraints and applying the setting immediately we store the constraints that are specified in the consumer then iterate over all enabled consumers applying all the constraints that they've set in addition to those from the machine. This results in a configuration which is the lowest possible voltage which satisfies all the constraints that have been supplied and for supplies with only one consumer it gives the same behaviour as we have currently. -- 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 01/13] OMAP: Introduce a user list for each voltage domain instance in the voltage driver.
Gopinath, Thara th...@ti.com writes: [...] I agree probably regulator framework would be the best place for this but then IMO regulator framework needs a lot of changes to support the kind of use-counting we need in the voltage layer. To start with regulator_get keeps the use counting only for enabling or disabling a regulator. It does not have a mechanism of adding the requested voltage to a list and picking out the highest among the added values. regulator_set_voltage could be used to route the call to omap_scale_voltage but then it is just a wrapper. Hi Thara, Based on feedback from regulator folks (and also remembering that we agreed to use the regulator framework as a later phase) let's keep your current approach as an interim solution, but knowing that we will eventually switch to use the regulator framework for handling multiple requests. In the background Thomas and I will continue to research the changes needed in the regulator framework. Thanks, Kevin -- 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 00/10] split out emac cpdma and mdio for reuse
Cyril Chemparathy cy...@ti.com writes: Hi Kevin, [...] Although am3517 (omap) board support code has been updated as needed, emac does not work on this platform. Just to clarify... did EMAC work on AM3517 before this series? No. It didn't work before this series. To get AM3517 EMAC working, the driver needs another patch to enable the interface clock in addition to the functional clock. Thanks for the clarification. Kevin -- 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] ARM: Fix v7wbi_tlb_flags for SMP on UP
On Fri, Sep 03, 2010 at 10:04:03AM -0700, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [100903 02:02]: On Fri, Sep 03, 2010 at 10:07:34AM +0100, Russell King - ARM Linux wrote: On Thu, Sep 02, 2010 at 04:47:46PM -0700, Tony Lindgren wrote: Correction, only boots on SMP hardawre. On UP hardware I still need the following patch. This should fix that properly. Correction - the order of the config tests was wrong. OK that works now. Looks like your new patch is missing smp_midr.h BTW. Damn git. Hate it when keeping patches external to git, even in git diff form. Luckily the file is just sitting around in my tree rather than having been deleted entirely... -- 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 00/11] OMAP: DMA: HWMOD and DMA as platform driver
Manjunatha GK manj...@ti.com writes: This patch series has review comments incorporated which are received for v1 version. The review comments can be found at: http://www.spinics.net/lists/linux-omap/msg34291.html http://www.spinics.net/lists/linux-omap/msg34292.html http://www.spinics.net/lists/linux-omap/msg34078.html http://www.spinics.net/lists/linux-omap/msg34083.html These changes are tested on following boards: - Zoom3 (OMAP3630) - Beagle(OMAP3530) - OMAP4 SDP (OMAP4430) I don't have omap1 and omap2 boards and appreciate if some one can test these boards and provides feedback. Build tested for both omap1 and omap2 plus boards. Your team now has OMAP2 hardware, please test on OMAP2 as well as you're making significant changes that affect code in OMAP2, 3 and 4. Kevin -- 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 10/11] OMAP: DMA: Use DMA device attributes
Manjunatha GK manj...@ti.com writes: Existing DMA API's are using cpu_is_ checks for differenciating omap1 and omap2plus code. This patch replaces cpu_is_ checks with DMA device attributes and also moves API's which are OMAP1 and OMAP2plus specific into respective mach-omap dma driver files. Signed-off-by: Manjunatha GK manj...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Santosh Shilimkar santosh.shilim...@ti.com [...] int omap_request_dma(int dev_id, const char *dev_name, void (*callback)(int lch, u16 ch_status, void *data), void *data, int *dma_ch_out) @@ -754,14 +459,12 @@ int omap_request_dma(int dev_id, const char *dev_name, chan = dma_chan + free_ch; chan-dev_id = dev_id; - pm_runtime_get_sync(ddev-dev); - - if (cpu_class_is_omap1()) - clear_lch_regs(free_ch); - - if (cpu_class_is_omap2()) + if (p-clear_lch_regs) + p-clear_lch_regs(free_ch); + else omap_clear_dma(free_ch); You access HW registers here. + pm_runtime_get_sync(ddev-dev); But don't actually enable HW until here. IOW, you need to have the 'get' before you access the HW. Kevin -- 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 04/11] OMAP3: DMA: HWMOD: Add hwmod data structures
Manjunatha GK manj...@ti.com writes:
This patch adds OMAP3 DMA hwmod structures.
Subject should be something like: OMAP3: hwmod data: add system DMA
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 85
1 files changed, 85 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 5d8eb58..0979c51 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -36,6 +36,7 @@ static struct omap_hwmod omap3xxx_iva_hwmod;
static struct omap_hwmod omap3xxx_l3_main_hwmod;
static struct omap_hwmod omap3xxx_l4_core_hwmod;
static struct omap_hwmod omap3xxx_l4_per_hwmod;
+static struct omap_hwmod omap3xxx_dma_system_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap3xxx_l3_main__l4_core = {
@@ -197,6 +198,89 @@ static struct omap_hwmod omap3xxx_iva_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430)
};
+/* dma_system - L3 */
+static struct omap_hwmod_ocp_if omap3xxx_dma_system__l3 = {
+ .master = omap3xxx_dma_system_hwmod,
+ .slave = omap3xxx_l3_main_hwmod,
+ .clk= l3_div_ck,
This clock dosn't exist in l-o, which I see due to the boot message:
omap_hwmod: dma: cannot clk_get main_clk l3_div_ck
I think you mean core_l3_ick here.
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma attributes */
+static struct omap_dma_dev_attr dma_dev_attr = {
+ .dev_caps = DMA_LINKED_LCH | GLOBAL_PRIORITY |
+ IS_CSSA_32 | IS_CDSA_32 | IS_RW_PRIORIY,
+ .lch_count = OMAP_DMA4_LOGICAL_DMA_CH_COUNT,
+};
+
+static struct omap_hwmod_class_sysconfig omap3xxx_dma_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x002c,
+ .syss_offs = 0x0028,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+SYSC_HAS_MIDLEMODE | SYSC_HAS_CLOCKACTIVITY |
+SYSC_HAS_EMUFREE | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap3xxx_dma_hwmod_class = {
+ .name = dma,
+ .sysc = omap3xxx_dma_sysc,
+};
+
+/* dma_system */
+static struct omap_hwmod_irq_info omap3xxx_dma_system_irqs[] = {
+ { .name = 0, .irq = INT_24XX_SDMA_IRQ0 },
+ { .name = 1, .irq = INT_24XX_SDMA_IRQ1 },
+ { .name = 2, .irq = INT_24XX_SDMA_IRQ2 },
+ { .name = 3, .irq = INT_24XX_SDMA_IRQ3 },
+};
+
+static struct omap_hwmod_addr_space omap3xxx_dma_system_addrs[] = {
+ {
+ .pa_start = 0x48056000,
+ .pa_end = 0x4a0560ff,
+ .flags = ADDR_TYPE_RT
+ },
+};
+
+/* dma_system master ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dma_system_masters[] = {
+ omap3xxx_dma_system__l3,
+};
+
+/* l4_cfg - dma_system */
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__dma_system = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap3xxx_dma_system_hwmod,
+ .clk= l4_div_ck,
This clock doesn't exist in l-o, resulting in the boot message:
omap_hwmod: dma: cannot clk_get interface_clk l4_div_ck
I think you meant core_l4_ick here.
+ .addr = omap3xxx_dma_system_addrs,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_dma_system_addrs),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* dma_system slave ports */
+static struct omap_hwmod_ocp_if *omap3xxx_dma_system_slaves[] = {
+ omap3xxx_l4_core__dma_system,
+};
+
+static struct omap_hwmod omap3xxx_dma_system_hwmod = {
+ .name = dma,
+ .class = omap3xxx_dma_hwmod_class,
+ .mpu_irqs = omap3xxx_dma_system_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap3xxx_dma_system_irqs),
+ .main_clk = l3_div_ck,
+ .slaves = omap3xxx_dma_system_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap3xxx_dma_system_slaves),
+ .masters= omap3xxx_dma_system_masters,
+ .masters_cnt= ARRAY_SIZE(omap3xxx_dma_system_masters),
+ .dev_attr = dma_dev_attr,
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430),
+ .flags = HWMOD_NO_IDLEST,
hmm, I see an ST_DMA bit in CM_IDLEST1_CORE for DMA.
Having this also masks the fact that you haven't filled out the
.prcm.omap2 fields of the hwmod, at least the idlest ones are needed
here.
Kevin
+};
+
static __initdata struct omap_hwmod *omap3xxx_hwmods[] = {
omap3xxx_l3_main_hwmod,
omap3xxx_l4_core_hwmod,
@@
Re: [PATCH v2 07/11] OMAP2/3/4: DMA: HWMOD: Device registration
Manjunatha GK manj...@ti.com writes:
This patch converts omap2/3/4 dma driver into platform
devices through using omap hwmod, omap device and runtime pm
frameworks.
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/dma.c | 134
arch/arm/mach-omap2/include/mach/dma.h | 80 +++
2 files changed, 214 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/dma.c
create mode 100644 arch/arm/mach-omap2/include/mach/dma.h
diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
new file mode 100644
index 000..f369bee
--- /dev/null
+++ b/arch/arm/mach-omap2/dma.c
@@ -0,0 +1,134 @@
+/*
+ * dma.c - OMAP2 specific DMA code
+ *
+ * Copyright (C) 2003 - 2008 Nokia Corporation
+ * Author: Juha Yrjölä juha.yrj...@nokia.com
+ * DMA channel linking for 1610 by Samuel Ortiz samuel.or...@nokia.com
+ * Graphics DMA and LCD DMA graphics tranformations
+ * by Imre Deak imre.d...@nokia.com
+ * OMAP2/3 support Copyright (C) 2004-2007 Texas Instruments, Inc.
+ * Some functions based on earlier dma-omap.c Copyright (C) 2001 RidgeRun,
Inc.
+ *
+ * Copyright (C) 2009 Texas Instruments
+ * Added OMAP4 support - Santosh Shilimkar santosh.shilim...@ti.com
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ * Converted DMA library into platform driver by Manjunatha GK
manj...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/err.h
+#include linux/slab.h
+#include linux/pm_runtime.h
+#include linux/io.h
+#include linux/module.h
+#include linux/init.h
+#include linux/sched.h
+#include linux/spinlock.h
+#include linux/errno.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/device.h
+
+#include plat/irqs.h
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
+#include plat/dma.h
+
+#define dma_read(reg)
\
+({ \
+ u32 __val; \
+ __val = __raw_readl(dma_base + OMAP_DMA4_##reg);\
+ __val; \
+})
+
+#define dma_write(val, reg) \
+({ \
+ __raw_writel((val), dma_base + OMAP_DMA4_##reg);\
+})
I know these are copy paste from the original code, but please convert
into static inline functions.
Also, I don't see dma_write() used in this patch.
+static struct omap_dma_dev_attr *d;
+static void __iomem *dma_base;
+static struct omap_system_dma_plat_info *omap2_pdata;
+static int dma_caps0_status;
+
+static struct omap_device_pm_latency omap2_dma_latency[] = {
+ {
+ .deactivate_func = omap_device_idle_hwmods,
+ .activate_func = omap_device_enable_hwmods,
+ .flags = OMAP_DEVICE_LATENCY_AUTO_ADJUST,
missing indentation
+ },
+};
[...]
Kevin
--
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 08/11] OMAP: DMA: Convert DMA library into DMA platform Driver
Manjunatha GK manj...@ti.com writes:
This patch converts DMA library into DMA platform driver and make use
of platform data provided by HWMOD data base for OMAP2PLUS onwards.
For OMAP1 processors, the DMA driver in mach-omap uses resource structures
for getting platform data.
Also, it enables and uses run time PM API's
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap1/Makefile |2 +-
arch/arm/mach-omap1/include/mach/dma.h | 66 +
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/include/mach/dma.h | 83 +++
arch/arm/plat-omap/dma.c | 244
+---
arch/arm/plat-omap/include/plat/dma.h | 157 ++---
6 files changed, 290 insertions(+), 264 deletions(-)
diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index 9a304d8..b7dfc54 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -3,7 +3,7 @@
#
# Common support
-obj-y := io.o id.o sram.o irq.o mux.o flash.o serial.o devices.o
+obj-y := io.o id.o sram.o irq.o mux.o flash.o serial.o devices.o dma.o
obj-y += clock.o clock_data.o opp_data.o
obj-$(CONFIG_OMAP_MCBSP) += mcbsp.o
diff --git a/arch/arm/mach-omap1/include/mach/dma.h
b/arch/arm/mach-omap1/include/mach/dma.h
index d446cdd..1eb0d31 100644
--- a/arch/arm/mach-omap1/include/mach/dma.h
+++ b/arch/arm/mach-omap1/include/mach/dma.h
@@ -77,4 +77,70 @@
#define OMAP1_DMA_CCR2(n)(0x40 * (n) + 0x24)
#define OMAP1_DMA_LCH_CTRL(n)(0x40 * (n) + 0x2a)
+/* Dummy defines to support multi omap code */
These should not be needed anymore as this is now an OMAP1-specific
header.
+/* Channel specific registers */
+#define OMAP_DMA4_CCR(n) 0
+#define OMAP_DMA4_CSDP(n)0
+#define OMAP_DMA4_CEN(n) 0
+#define OMAP_DMA4_CFN(n) 0
+#define OMAP_DMA4_COLOR(n) 0
+#define OMAP_DMA4_CSSA(n)0
+#define OMAP_DMA4_CSEI(n)0
+#define OMAP_DMA4_CSFI(n)0
+#define OMAP_DMA4_CDSA(n)0
+#define OMAP_DMA4_CDEI(n)0
+#define OMAP_DMA4_CDFI(n)0
+#define OMAP_DMA4_CSR(n) 0
+#define OMAP_DMA4_CICR(n)0
+#define OMAP_DMA4_CLNK_CTRL(n) 0
+#define OMAP_DMA4_CH_BASE(n) 0
+#define OMAP_DMA4_CDAC(n)0
+#define OMAP_DMA4_CSAC(n)0
+
+/* Common registers */
+#define OMAP_DMA4_IRQENABLE_L0 0
+#define OMAP_DMA4_OCP_SYSCONFIG 0
+#define OMAP_DMA4_GCR0
+#define OMAP_DMA4_IRQSTATUS_L0 0
+#define OMAP_DMA4_CAPS_2 0
+#define OMAP_DMA4_CAPS_3 0
+#define OMAP_DMA4_CAPS_4 0
+#define OMAP_DMA4_REVISION 0
+
+#define OMAP_DMA4_CCR2(n)0
+#define OMAP_DMA4_LCH_CTRL(n)0
+#define OMAP_DMA4_COLOR_L(n) 0
+#define OMAP_DMA4_COLOR_U(n) 0
+#define OMAP1_DMA_COLOR(n) 0
+#define OMAP_DMA4_CSSA_U(n) 0
+#define OMAP_DMA4_CSSA_L(n) 0
+#define OMAP1_DMA_CSSA(n)0
+#define OMAP_DMA4_CDSA_U(n) 0
+#define OMAP_DMA4_CDSA_L(n) 0
+#define OMAP1_DMA_CDSA(n)0
+#define OMAP_DMA4_CPC(n) 0
+
+#define OMAP1_DMA_IRQENABLE_L0 0
+#define OMAP1_DMA_IRQENABLE_L0 0
+#define OMAP1_DMA_IRQSTATUS_L0 0
+#define OMAP1_DMA_OCP_SYSCONFIG 0
+#define OMAP_DMA4_HW_ID 0
+#define OMAP_DMA4_CAPS_0_U 0
+#define OMAP_DMA4_CAPS_0_L 0
+#define OMAP_DMA4_CAPS_1_U 0
+#define OMAP_DMA4_CAPS_1_L 0
+#define OMAP_DMA4_GSCR 0
+#define OMAP1_DMA_REVISION 0
+
+struct omap_dma_lch {
+ int next_lch;
+ int dev_id;
+ u16 saved_csr;
+ u16 enabled_irqs;
+ const char *dev_name;
+ void (*callback)(int lch, u16 ch_status, void *data);
+ void *data;
+ long flags;
+};
+
#endif /* __ASM_ARCH_OMAP1_DMA_H */
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 9b44773..6a8b231 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -3,7 +3,7 @@
#
# Common support
-obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o pm.o
+obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer-gp.o pm.o
dma.o
omap-2-3-common = irq.o sdrc.o
hwmod-common = omap_hwmod.o \
diff --git a/arch/arm/mach-omap2/include/mach/dma.h
b/arch/arm/mach-omap2/include/mach/dma.h
index 3eca7d8..22f4b41 100644
--- a/arch/arm/mach-omap2/include/mach/dma.h
+++
Re: [PATCH v2 09/11] OMAP: DMA: Implement generic errata handling
Manjunatha GK manj...@ti.com writes:
This patch introduces generic way of handling all OMAP DMA
errata's which are applicable for OMAP1 and OMAP2PLUS processors.
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap1/dma.c |6
arch/arm/mach-omap2/dma.c | 34 +++
arch/arm/plat-omap/dma.c | 48 ++--
arch/arm/plat-omap/include/plat/dma.h |9 ++
4 files changed, 76 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
index 26ab6e3..615c5f5 100644
--- a/arch/arm/mach-omap1/dma.c
+++ b/arch/arm/mach-omap1/dma.c
@@ -170,6 +170,12 @@ static int __init omap1_system_dma_init(void)
goto exit_device_put;
}
+ /* Errata handling for all omap1 plus processors */
+ pdata-errata = 0;
This isn't needed as you just kzalloc'd pdata.
+ if (cpu_class_is_omap1() !cpu_is_omap15xx())
You don't need cpu_class_is_omap1() as this is OMAP1 specific code.
+ pdata-errata |= OMAP3_3_ERRATUM;
+
d = pdata-dma_attr;
/* Valid attributes for omap1 plus processors */
diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
index f369bee..8832bd1 100644
--- a/arch/arm/mach-omap2/dma.c
+++ b/arch/arm/mach-omap2/dma.c
@@ -80,6 +80,40 @@ static int __init omap2_system_dma_init_dev(struct
omap_hwmod *oh, void *user)
pdata-dma_attr = (struct omap_dma_dev_attr *)oh-dev_attr;
+ /* Handling Errata's for all OMAP2PLUS processors */
+ pdata-errata = 0;
not needed, see above
+ if (cpu_is_omap242x() ||
+ (cpu_is_omap243x() omap_type() = OMAP2430_REV_ES1_0))
+ pdata-errata = DMA_CHAINING_ERRATA;
+
+ /*
+ * Errata: On ES2.0 BUFFERING disable must be set.
+ * This will always fail on ES1.0
+ */
+ if (cpu_is_omap24xx())
+ pdata-errata |= DMA_BUFF_DISABLE_ERRATA;
+
+ /*
+ * Errata: OMAP2: sDMA Channel is not disabled
+ * after a transaction error. So we explicitely
+ * disable the channel
+ */
+ if (cpu_class_is_omap2())
+ pdata-errata |= DMA_CH_DISABLE_ERRATA;
+
+ /* Errata: OMAP3 :
fix multi-line comment style
+ * A bug in ROM code leaves IRQ status for channels 0 and 1 uncleared
+ * after secure sram context save and restore. Hence we need to
+ * manually clear those IRQs to avoid spurious interrupts. This
+ * affects only secure devices.
+ */
+ if (cpu_is_omap34xx() (omap_type() != OMAP2_DEVICE_TYPE_GP))
+ pdata-errata |= DMA_IRQ_STATUS_ERRATA;
+
+ /* Errata3.3: Applicable for all omap2 plus */
+ pdata-errata |= OMAP3_3_ERRATUM;
+
od = omap_device_build(name, 0, oh, pdata, sizeof(*pdata),
omap2_dma_latency, ARRAY_SIZE(omap2_dma_latency), 0);
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 36c3dde..409586a 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -187,6 +187,25 @@ static inline void set_gdma_dev(int req, int dev)
#define set_gdma_dev(req, dev) do {} while (0)
#endif
+static void dma_ocpsysconfig_errata(u32 *sys_cf, bool flag)
Please use (or extend) hwmod layer for modifying device SYSCONFIG.
+{
+ u32 l;
+
+ /*
+ * DMA Errata:
+ * Special programming model needed to disable DMA before end of block
+ */
Please reference Errata#
+ if (!flag) {
+ *sys_cf = dma_read(OCP_SYSCONFIG);
+ l = *sys_cf;
+ /* Middle mode reg set no Standby */
+ l = ~((1 12)|(1 13));
+ dma_write(l, OCP_SYSCONFIG);
+ } else
+ /* put back old value */
+ dma_write(*sys_cf, OCP_SYSCONFIG);
+}
+
/* Omap1 only */
static void clear_lch_regs(int lch)
{
@@ -971,22 +990,16 @@ void omap_start_dma(int lch)
cur_lch = next_lch;
} while (next_lch != -1);
- } else if (cpu_is_omap242x() ||
- (cpu_is_omap243x() omap_type() = OMAP2430_REV_ES1_0)) {
+ }
- /* Errata: Need to write lch even if not using chaining */
+ if (p-errata DMA_CHAINING_ERRATA)
dma_write(lch, CLNK_CTRL(lch));
- }
omap_enable_channel_irq(lch);
l = dma_read(CCR(lch));
- /*
- * Errata: On ES2.0 BUFFERING disable must be set.
- * This will always fail on ES1.0
- */
- if (cpu_is_omap24xx())
+ if (p-errata DMA_BUFF_DISABLE_ERRATA)
l |= OMAP_DMA_CCR_EN;
l |= OMAP_DMA_CCR_EN;
@@ -1660,7
Re: [PATCH v2 00/11] OMAP: DMA: HWMOD and DMA as platform driver
G, Manjunath Kondaiah manj...@ti.com writes: If there are no further comments, can you please stage this patch series on hwmods-omap4 branch? Reviewed. Still a long ways to go..., also I didn't see you address the typo pointed out by Mika Westerberg on PATCH 03/11. Also, testing on omap3430/n900, I noticed an interesting failure during boot. During boot (in the middle of omap3_pm_init(), a DMA interrupt fires and the SPI RX callback is called which faults when accessing it's registers. I did not debug this further, but is something that needs investigation. Also, in the next version, please report how it was tested on the various OMAPs. In particular, what peripherals using DMA were tested. Just a boot test is not sufficient when making major functional changes like this. Drivers using DMA need to be tested as well. Kevin -- 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] I2C: Fix for suspend/resume issue in i2c-core
On Friday, September 03, 2010, Sripathy, Vishwanath wrote: -Original Message- From: Jean Delvare [mailto:kh...@linux-fr.org] Sent: Wednesday, September 01, 2010 2:11 PM To: Rafael J. Wysocki Cc: Mark Brown; Kevin Hilman; Sripathy, Vishwanath; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Basak, Partha; Ben Dooks Subject: Re: [PATCH] I2C: Fix for suspend/resume issue in i2c-core On Wed, 1 Sep 2010 01:12:11 +0200, Rafael J. Wysocki wrote: On Tuesday, August 31, 2010, Mark Brown wrote: On Mon, Aug 30, 2010 at 11:43:23AM -0700, Kevin Hilman wrote: Vishwanath BS vishwanath...@ti.com writes: In current i2c core driver, pm_runtime_set_active call from i2c_device_pm_resume is not balanced by pm_runtime_set_suspended call from i2c_device_pm_suspend. pm_runtime_set_active called from resume path will increase the child_count of the device's parent. However, matching pm_runtime_set_suspended is not called in suspend routine because of which child_count of the device's parent is not balanced, preventing the parent device to idle. Issue has been fixed by adding pm_runtime_set_suspended call inside suspend reoutine which will make sure that child_counts are balanced. This fix has been tested on OMAP4430. Signed-off-by: Partha Basak p-bas...@ti.com Signed-off-by: Vishwanath BS vishwanath...@ti.com Cc: Rafael J. Wysocki r...@sisk.pl Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Ben Dooks ben-li...@fluff.org Also Cc'ing Mark Brown as original author of runtime PM for i2-core. Also Jean Delvare who maintains the I2C core. To be honest Rafael did all the actual work here (and has since rewritten the code anyway). Sorry for the delay. The fix looks reasonable to me. I take this as an Acked-by. Patch applied, thanks. Hi, We are seeing one more issue even after making this fix. In summary, after first suspend/resume, CPU Idle no longer works since i2c module is active. Basically when the system resumed from the suspend, dpm layer (dpm_resume_end) calls device_resume which intern calls i2c_device_pm_resume (among many other calls). i2c_device_pm_resume calls pm_runtime_set_active which brings device to Active state and increases child_count of it's parent. Since the device is active and also it's parent child_count is non 0, these modules will prevent corresponding clock domains to go idle. This will break CPU Idle. This issue happens even if the module was in idle state before performing suspend/resume. In summary, the flow is 1. i2c module is idle (let's assume system is idle) 2. system suspend is initiated by user 3. i2c_device_pm_suspend gets called which tries to idle i2c, but it's already idled. 4. system is suspended 5. system resumed (because of user event/timers) 6. dpm layer will call i2c_device_pm_resume 7. i2c_device_pm_resume will enable i2c device by calling pm_runtime_set_active So at the end of suspend/resume, a device that was idled before is getting enabled unnecessarily at the end. SO I am just wondering is there any real need to call pm_runtime_set_active in resume and pm_runtime_set_suspened in suspend functions? I just tried suspend/resume and CPU Idle after removing these calls in i2c and it seems to function perfectly fine on OMAP4. Your analysis appears to be entirely correct. So, instead of applying the $subject patch it might be better to remove the block that calls pm_runtime_set_active(dev) from i2c_device_pm_resume(). Are there any objections? Rafael -- 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
