Re: [PATCH 10/10] OMAPDSS: HDMI: Implement DSS driver interface for audio
On Tue, 2012-04-24 at 23:48 -0500, Ricardo Neri wrote: On 04/23/2012 08:01 AM, Tomi Valkeinen wrote: On Wed, 2012-03-28 at 16:38 -0600, Ricardo Neri wrote: Implement the DSS device driver audio support interface in the HDMI panel driver and generic driver. The implementation relies on the IP-specific functions that are defined at DSS probe time. A HW-safe spinlock is used to protect the audio functions. This is because What is a HW-safe spinlock? Sorry, I meant a spinlock that disables the HW irqs when held:hardirq-safe. the audio functions may be called while holding a lock; in such case, the panel's driver mutex is not suitable. Functions should be used to set registers and should not wait for any other event. Are you sure this is the only option? What lock is being held? For instance, ALSA calls the start audio function while holding a hardirq-safe readlock. Hence, when reaching the HDMI panel start function, a lock is held and irqs are disabled. Using a mutex, that might sleep, is not correct; nor it is using an hardirq-unsafe spinlock. Otherwise, deadlocks and/or inverse lock ordering may arise. This situation was signaled by lockdep. IMHO, as the DSS device driver does not know who is going to use it (at least the audio part), it should not assume that no locks are held when its functions are called. While a spinlock may be ok for now, quite often enabling/disabling things do not happen immediately,and it's much easier to do the wait synchronously. I don't understand this comment. To me, holding a lock until the enabling function returns is synchronous. Would you please clarify? I meant that quite often when enabling things on hardware it takes time until the HW is actually up and running. Perhaps a regulator needs to be started, or such. And it's usually simpler to wait for the HW to be up synchronously in the enable function, instead of some kind of asynchronous mechanism. And if a function waits synchronously, a mutex is better than spinlock. And in that sense it's often better to define (define meaning, adding a comment, or just mentally taking note about it) that the functions in the API may sleep, so that the driver is free to do what is best for the case, and it's also future-proof in a way that you can easily add function calls that sleep to the functions in the future. But you are also right in your previous comment, it's better to define functions so that they never sleep, as that gives the callers the freedom to call the funcs in atomic context. Perhaps we can have audio_start() that never sleeps, it just enables a few bits that start the audio. But how about audio_enable()? Is it possible that on some OMAP version it would need to enable a regulator, or set a gpio that's in an external i2c controlled mux chip, or such? If so, we need to make sure it's not currently called in an atomic context, because it would break if the function will sleep in the future. And with make sure I just mean that we check the code and keep it in mind. Or perhaps adding a comment in the header, that says audio_enable may sleep, other audio functions do not sleep or such. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v2] ASoC: omap-pcm: Free dma buffers in case of error.
On 04/25/2012 05:02 AM, Oleg Matcovschi wrote: Change-Id: I4ba9de0de4681332539246ccc5e11a7a8fb32e79 Signed-off-by: Oleg Matcovschi oleg.matcovs...@ti.com --- v1: initial revision v2: resending patch including maintainers sound/soc/omap/omap-pcm.c |4 1 files changed, 4 insertions(+), 0 deletions(-) Acked-by: Jarkko Nikula jarkko.nik...@bitmer.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 v9 11/25] gpio/omap: cleanup omap_gpio_mod_init function
On Wed, Apr 25, 2012 at 10:04 AM, DebBarma, Tarun Kanti tarun.ka...@ti.com wrote: On Tue, Apr 24, 2012 at 9:34 PM, Tony Lindgren t...@atomide.com wrote: * DebBarma, Tarun Kanti tarun.ka...@ti.com [120424 08:40]: Hi Janusz, On Tue, Apr 24, 2012 at 12:24 AM, DebBarma, Tarun Kanti tarun.ka...@ti.com wrote: On Sat, Apr 21, 2012 at 7:33 PM, Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote: On Thursday 02 of February 2012 23:00:37 Tarun Kanti DebBarma wrote: With register offsets now defined for respective OMAP versions we can get rid of cpu_class_* checks. This function now has common initialization code for all OMAP versions... Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com Signed-off-by: Charulatha V ch...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Tony Lindgren t...@atomide.com Sorry for being so late with my comment for chanes already present in mainline, but this patch breaks GPIO on Amstrad Delta at least, and I have neither enough spare time nor enough experience with non OMAP1 machines to provide a solution myself. Yes, I looked at the omap_gpio_mod_init() and OMAP1 configurations are overwritten. Also looks like there is issue in making distinction between omap15xx and omap16xx. I will post a patch and you can help me testing it in OMAP1 platform. Thanks for pointing this out. ... Here is the patch, with attachment as well. I have just tested on OMAP4 platform. Testing on other OMAP2+ platforms is pending. In the meantime can you please validate on OMAP1 platform and confirm? Thanks. -- Tarun From: Tarun Kanti DebBarma tarun.ka...@ti.com Date: Tue, 24 Apr 2012 20:34:32 +0530 Subject: [PATCH] gpio/omap: fix omap1 register overwrite in omap_gpio_mod_init Initialization of irqenable, irqstatus registers is the common operation done in this function for all OMAP platforms, viz. OMAP1, OMAP2+. The latter _gpio_rmw()'s to irqenable register was overwriting the correctly programmed OMAP1 value at the beginning. As a result, even though it worked on OMAP2+ platforms it was breaking OMAP1 functionality. Sounds like the original patch was never tested on omap1? That's right, only bootup test was done on OMAP1710-SDP. On closer observation it is found that the first _gpio_rmw() which is supposedly done to take care of OMAP1 platform is generic enough and takes care of OMAP2+ platform as well. Therefore remove the latter _gpio_rmw() to irqenable as they are redundant. Also, changing the sequence and logic of initializing the irqstatus. Please mention also the breaking commit here and get this fix merged as a regression as soon as it's tested for the current -rc series. Sure, I will do that! Looks like it is regression on 3.4 as well so CC stable when you post the patch. 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
[PATCH 1/2 v4] ARM: OMAP2+: omap_hwmod: Add api to enable/disable module level wakeup events
From: Govindraj.R govindraj.r...@ti.com
On 24xx/34xx/36xx Module level wakeup events are enabled/disabled using
PM_WKEN1_CORE/PM_WKEN_PER regs.
Add api to control the module level wakeup mechanism from info provided from
hwmod data.
omap_hwmod_enable/disable_wakeup is used from serial.c which should
configure PM_WKEN register to enable or disable the module level wakeup.
Cc: Tero Kristo t-kri...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 23 +++
arch/arm/mach-omap2/prm2xxx_3xxx.c | 16
arch/arm/mach-omap2/prm2xxx_3xxx.h |9 +
3 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 2c27fdb..25f306b 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -382,6 +382,27 @@ static int _set_module_autoidle(struct omap_hwmod *oh, u8
autoidle,
}
/**
+ * _enable_module_level_wakeup - enable/disable module level wakeup on hwmod.
+ * @oh: struct omap_hwmod *
+ * @set_wake: bool value indicating to set (true) or clear (false) module level
+ * wakeup enable
+ *
+ * Set or clear the module level wakeup capability the
+ * hwmod @oh. This function configures th PM_WKEN reg bits if they
+ * are available from hwmod. No return value
+ */
+static void _enable_module_level_wakeup(struct omap_hwmod *oh, bool set_wake)
+{
+ if (oh-prcm.omap2.module_offs oh-prcm.omap2.prcm_reg_id
+ oh-prcm.omap2.idlest_idle_bit)
+ omap2_prm_enable_prcm_module_wakeup(
+ oh-prcm.omap2.module_offs,
+ oh-prcm.omap2.prcm_reg_id,
+ oh-prcm.omap2.idlest_idle_bit,
+ set_wake);
+}
+
+/**
* _set_idle_ioring_wakeup - enable/disable IO pad wakeup on hwmod idle for mux
* @oh: struct omap_hwmod *
* @set_wake: bool value indicating to set (true) or clear (false) wakeup
enable
@@ -2471,6 +2492,7 @@ int omap_hwmod_enable_wakeup(struct omap_hwmod *oh)
_write_sysconfig(v, oh);
}
+ _enable_module_level_wakeup(oh, true);
_set_idle_ioring_wakeup(oh, true);
spin_unlock_irqrestore(oh-_lock, flags);
@@ -2504,6 +2526,7 @@ int omap_hwmod_disable_wakeup(struct omap_hwmod *oh)
_write_sysconfig(v, oh);
}
+ _enable_module_level_wakeup(oh, false);
_set_idle_ioring_wakeup(oh, false);
spin_unlock_irqrestore(oh-_lock, flags);
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 9ce7654..85a753e 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -28,6 +28,10 @@
#include prm-regbits-24xx.h
#include prm-regbits-34xx.h
+static const u8 pm_wken_offs[] = {
+ PM_WKEN1, OMAP24XX_PM_WKEN2
+};
+
static const struct omap_prcm_irq omap3_prcm_irqs[] = {
OMAP_PRCM_IRQ(wkup, 0, 0),
OMAP_PRCM_IRQ(io, 9, 1),
@@ -91,6 +95,18 @@ u32 omap2_prm_clear_mod_reg_bits(u32 bits, s16 module, s16
idx)
return omap2_prm_rmw_mod_reg_bits(bits, 0x0, module, idx);
}
+void omap2_prm_enable_prcm_module_wakeup(s16 prcm_mod, u8 prm_reg_id,
+ u8 prm_reg_shift, bool set_wake)
+{
+ if (prm_reg_id (prm_reg_id = ARRAY_SIZE(pm_wken_offs))) {
+ if (set_wake)
+ omap2_prm_set_mod_reg_bits(1 prm_reg_shift,
+ prcm_mod, pm_wken_offs[prm_reg_id - 1]);
+ else
+ omap2_prm_clear_mod_reg_bits(1 prm_reg_shift,
+ prcm_mod, pm_wken_offs[prm_reg_id - 1]);
+ }
+}
/**
* omap2_prm_is_hardreset_asserted - read the HW reset line state of
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.h
b/arch/arm/mach-omap2/prm2xxx_3xxx.h
index 70ac2a1..49a185a 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.h
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.h
@@ -289,6 +289,13 @@ static inline int omap2_prm_deassert_hardreset(s16
prm_mod, u8 rst_shift,
not suppose to be used on omap4\n);
return 0;
}
+static inline void omap2_prm_enable_prcm_module_wakeup(s16 prcm_mod,
+ u8 prm_reg_id, u8 prm_reg_shift, bool set_wake)
+{
+ WARN(1, prm: omap2xxx/omap3xxx specific function and
+ not suppose to be used on omap4\n);
+ return 0;
+}
#else
/* Power/reset management domain register get/set */
extern u32 omap2_prm_read_mod_reg(s16 module, u16 idx);
@@ -297,6 +304,8 @@ extern u32 omap2_prm_rmw_mod_reg_bits(u32 mask, u32 bits,
s16 module, s16 idx);
extern u32 omap2_prm_set_mod_reg_bits(u32
Re: [PATCH 05/19] ARM: OMAP4: PM: Add SAR backup support towards device OFF
On Tue, 2012-04-24 at 09:35 -0700, Tony Lindgren wrote:
* Tero Kristo t-kri...@ti.com [120420 02:39]:
+
+static int omap4_sar_not_accessible(void)
+{
+ u32 usbhost_state, usbtll_state;
+
+ /*
+* Make sure that USB host and TLL modules are not
+* enabled before attempting to save the context
+* registers, otherwise this will trigger an exception.
+*/
+ usbhost_state = omap4_cminst_read_inst_reg(OMAP4430_CM2_PARTITION,
+ OMAP4430_CM2_L3INIT_INST,
+
OMAP4_CM_L3INIT_USB_HOST_CLKCTRL_OFFSET)
+(OMAP4430_STBYST_MASK | OMAP4430_IDLEST_MASK);
+
+ usbtll_state = omap4_cminst_read_inst_reg(OMAP4430_CM2_PARTITION,
+ OMAP4430_CM2_L3INIT_INST,
+
OMAP4_CM_L3INIT_USB_TLL_CLKCTRL_OFFSET)
+OMAP4430_IDLEST_MASK;
Formatting here looks bad, maybe just do it in separate steps:
usbhost_state = omap4_cminst...
usbhost_state = OMAP4430_STBYST_MASK | OMAP4430_IDLEST_MASK;
...
+ /*
+* Not supported on ES1.0 silicon
+*/
+ if (omap_rev() == OMAP4430_REV_ES1_0) {
+ WARN_ONCE(1, omap4: SAR backup not supported on ES1.0 ..\n);
+ return -ENODEV;
+ }
Everytime there's SoC/hardware revision detection in a non __init function,
something is most likely wrong.
+void omap4_sar_overwrite(void)
+{
+ u32 val = 0;
+ u32 offset = 0;
+
+ if (cpu_is_omap446x())
+ offset = 0x04;
Here too.
+static int __init omap4_sar_ram_init(void)
+{
+ /*
+* To avoid code running on other OMAPs in
+* multi-omap builds
+*/
+ if (!cpu_is_omap44xx())
+ return -ENODEV;
You should configure things here instead by setting function
pointers or variables.
Regards,
Tony
Okay, I can drop rest of these from this patch, most of them do not
exist in the final code (removed by later patches for autogeneration), I
just left this here for historical reasons.
-Tero
--
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 12/19] ARM: OMAP4: PM: update ROM return address for OSWR and OFF
On Tue, 2012-04-24 at 09:39 -0700, Tony Lindgren wrote:
* Tero Kristo t-kri...@ti.com [120420 02:39]:
@@ -384,6 +386,17 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned
int power_state)
set_cpu_next_pwrst(wakeup_cpu, PWRDM_POWER_ON);
if (omap4_mpuss_read_prev_context_state()) {
+ /*
+* Dummy dispatcher call after OSWR and OFF
+* Restore the right return Kernel address (with MMU on) for
+* subsequent calls to secure ROM. Otherwise the return address
+* will be to a PA return address and the system will hang.
+*/
+ if (omap_type() != OMAP2_DEVICE_TYPE_GP)
+ omap_secure_dispatcher(OMAP4_PPA_SERVICE_0,
+ FLAG_START_CRITICAL,
+ 0, 0, 0, 0, 0);
+
restore_ivahd_tesla_regs();
restore_l3instr_regs();
This SoC test here too should be only done once during init.
You sure about this one? I will end up creating a variable omap_is_gp or
such, which looks somewhat silly and is going to be a duplicate (it will
not provide any extra value in addition to the existing omap_type()
check.) Also, similar checks are used elsewhere in the kernel, look at
omap-wakeupgen.c, pm34xx.c, pm44xx.c, control.c for example. Should all
of these be replaced? Well, most of these are related to secure context
saving so maybe the mechanism behind these should be changed somehow
globally.
-Tero
--
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 15/19] ARM: OMAP4430: PM: workaround for DDR corruption on second CS
On Tue, 2012-04-24 at 13:22 -0500, Jon Hunter wrote:
Hi Tero,
On 04/20/2012 04:33 AM, Tero Kristo wrote:
From: Santosh Shilimkar santosh.shilim...@ti.com
Work around for Errata ID: i632 LPDDR2 Corruption After OFF Mode
Transition When CS1 Is Used On EMIF which impacts OMAP443x silicon
The issue occurs when EMIF_SDRAM_CONFIG is restored first before
EMIF_SDRAM_CONFIG_2 is not yet restored, the register configuration
is not set properly, we apply the required workaround allowing
the restore sequence to work properly.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
[t-kri...@ti.com: moved workaround from omap-sar.c to pm44xx.c]
Signed-off-by: Tero Kristo t-kri...@ti.com
---
.../include/mach/ctrl_module_wkup_44xx.h |2 +
arch/arm/mach-omap2/pm44xx.c | 24
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
b/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
index a0af9ba..b763a79 100644
--- a/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
+++ b/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
@@ -28,6 +28,8 @@
#define OMAP4_CTRL_MODULE_WKUP_IP_REVISION 0x
#define OMAP4_CTRL_MODULE_WKUP_IP_HWINFO 0x0004
#define OMAP4_CTRL_MODULE_WKUP_IP_SYSCONFIG0x0010
+#define OMAP4_CTRL_SECURE_EMIF1_SDRAM_CONFIG2_REG 0x0114
+#define OMAP4_CTRL_SECURE_EMIF2_SDRAM_CONFIG2_REG 0x011c
#define OMAP4_CTRL_MODULE_WKUP_CONF_DEBUG_SEL_TST_00x0460
#define OMAP4_CTRL_MODULE_WKUP_CONF_DEBUG_SEL_TST_10x0464
#define OMAP4_CTRL_MODULE_WKUP_CONF_DEBUG_SEL_TST_20x0468
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 0472921..d4d18d9 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -17,6 +17,9 @@
#include linux/err.h
#include linux/slab.h
#include asm/system_misc.h
+#include linux/io.h
+
+#include mach/ctrl_module_wkup_44xx.h
#include common.h
#include clockdomain.h
@@ -215,6 +218,27 @@ static int __init omap4_pm_init(void)
pr_err(Power Management for TI OMAP4.\n);
+ /*
+* Work around for OMAP443x Errata i632: LPDDR2 Corruption After OFF
+* Mode Transition When CS1 Is Used On EMIF:
+* Overwrite EMIF1/EMIF2
+* SECURE_EMIF1_SDRAM_CONFIG2_REG
+* SECURE_EMIF2_SDRAM_CONFIG2_REG
+*/
+ if (cpu_is_omap443x()) {
+ void __iomem *secure_ctrl_mod;
+
+ secure_ctrl_mod = ioremap(OMAP4_CTRL_MODULE_WKUP, SZ_4K);
+ BUG_ON(!secure_ctrl_mod);
+
+ __raw_writel(0x10, secure_ctrl_mod +
+OMAP4_CTRL_SECURE_EMIF1_SDRAM_CONFIG2_REG);
+ __raw_writel(0x10, secure_ctrl_mod +
+OMAP4_CTRL_SECURE_EMIF2_SDRAM_CONFIG2_REG);
According to the erratum description the above registers are used to
restore the EMIFx_SDRAM_CONFIG2 registers. So although the value 0x10,
maybe the value being used for EMIFx_SDRAM_CONFIG2 registers, shouldn't
we read the EMIFx_SDRAM_CONFIG2 registers and store them in the above
registers?
This might be a good idea, however, this patch might be tagged as TEMP
until the EMIF driver is in place, this fix should rather be located
there. I'll take a look at this if I can change the implementation a
bit.
-Tero
--
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 08/19] ARM: OMAP4: PM: Add device-off support
On Tue, 2012-04-24 at 12:46 -0500, Jon Hunter wrote:
Hi Tero,
On 04/20/2012 04:33 AM, Tero Kristo wrote:
This patch adds device off support to OMAP4 device type.
OFF mode is disabled by default, however, there are two ways to enable
OFF mode:
a) In the board file, call omap4_pm_off_mode_enable(1)
b) Enable OFF mode using the debugfs entry
echo 1/sys/kernel/debug/pm_debug/enable_off_mode
(conversely echo '0' will disable it as well).
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
[t-kri...@ti.com: largely re-structured the code]
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 24 ++-
arch/arm/mach-omap2/omap-wakeupgen.c | 47 +++-
arch/arm/mach-omap2/pm-debug.c| 17 +--
arch/arm/mach-omap2/pm.h | 28 ++--
arch/arm/mach-omap2/pm44xx.c | 45 +++
arch/arm/mach-omap2/prm44xx.c | 66
+
6 files changed, 214 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index e02c082..b9a2cc7 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -60,6 +60,7 @@
#include prcm44xx.h
#include prm44xx.h
#include prm-regbits-44xx.h
+#include cm44xx.h
#ifdef CONFIG_SMP
@@ -232,6 +233,7 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
{
unsigned int save_state = 0;
unsigned int wakeup_cpu;
+ int ret;
if (omap_rev() == OMAP4430_REV_ES1_0)
return -ENXIO;
@@ -263,9 +265,21 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned
int power_state)
* In MPUSS OSWR or device OFF, interrupt controller contest is lost.
*/
mpuss_clear_prev_logic_pwrst();
- if ((pwrdm_read_next_pwrst(mpuss_pd) == PWRDM_POWER_RET)
- (pwrdm_read_logic_retst(mpuss_pd) == PWRDM_POWER_OFF))
+ if (omap4_device_next_state_off()) {
+ /* Save the device context to SAR RAM */
+ ret = omap_sar_save();
+ if (ret)
+ return ret;
Is it safe to simply return here? I was not sure if we need to call
pwrdm_post_transition, given that we have already called
pwrdm_pre_transition on entry.
Hmm, thats a good point, I'll change the patch slightly. Anyway,
currently the potential solo pwrdm_pre_transition() will not break
anything, but in future it would, as we are planning to control AUTO_RET
feature through the pwrdm_pre / pwrdm_post calls.
-Tero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V3 2/3] ARM: OMAP3+: clockdomain33xx: Add clockdomain data and respective operations
On Wed, Apr 25, 2012 at 05:52:26, Paul Walmsley wrote:
Hello Vaibhav, Afzal, Vaibhav,
A few questions while reviewing this patch:
On Tue, 3 Apr 2012, Vaibhav Hiremath wrote:
AM33XX PRCM module consist of, various clockdomains, in all
total we have 18 clockdomains available, with following
controlling options,
- NO Sleep: sleep transition can not be initiated,
- SW Sleep: sw forced sleep transition,
- SW Wakeup: sw forced wakeup transition,
- HW Auto: transitions are based upon hw conditions.
This patch adds all available clockdomain data, respective
clockdomain operations for AM33XX family of device, and also
integrates it into existing OMAP framework.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
...
+static struct clockdomain l4ls_am33xx_clkdm = {
+ .name = l4ls_clkdm,
+ .pwrdm = { .name = per_pwrdm },
+ .cm_inst= AM33XX_CM_PER_MOD,
+ .clkdm_offs = AM33XX_CM_PER_L4LS_CLKSTCTRL_OFFSET,
+ .clktrctrl_mask = AM33XX_CLKTRCTRL_MASK,
+ .flags = (CLKDM_CAN_SWSUP | CLKDM_NO_AUTODEPS),
It looks to me like we don't need the .clktrctrl_mask field, since
according to the clockdomains code, the CLKTRCTRL field is at the same bit
shift for each clockdomain.
Yeah, we actually don't need it, probably I added for completeness.
I will remove it in next version.
Also, since we're not defining any autodeps for the AM335x platform, we
shouldn't need the CLKDM_NO_AUTODEPS flag either? Since no autodeps are
defined, the default will be to not set any autodeps.
This is required to avoid few pr_debug, if you don't provide it.
For example, without this flag set, you will get,
pr_debug(clockdomain: hardware cannot set/clear sleep
dependency affecting %s from %s\n, clkdm1-name,
clkdm2-name);
Refer to the file omap_hwmod.c, function, _enable(), the call sequence is,
_enable() = _add_initiator_dep() = clkdm_add_sleepdep() =leads to warning
Another question is about the CLKTRCTRL bitfields. According to
_AM335x ARM Cortex-A8 Microprocessors (MPUs) Technical Reference
Manual_ Rev. D (SPRUH73D), most of the clockdomains support NO_SLEEP mode
(i.e., CLKTRCTRL = 0x0). That means that technically, we should also set
the CLKDM_CAN_DISABLE_AUTO flag. Unless the documentation is incorrect
here? In another section (Table 8-9 Clock Transition Mode Settings),
it claims that CLKTRCTRL = 0 is not supported...
It is not supported, and should be considered as documentation issue.
Also, a question about the L4_WKUP clockdomain:
+static struct clockdomain l4_wkup_am33xx_clkdm = {
+ .name = l4_wkup_clkdm,
+ .pwrdm = { .name = wkup_pwrdm },
+ .cm_inst= AM33XX_CM_WKUP_MOD,
+ .clkdm_offs = AM33XX_CM_WKUP_CLKSTCTRL_OFFSET,
+ .clktrctrl_mask = AM33XX_CLKTRCTRL_MASK,
+ .flags = (CLKDM_CAN_SWSUP | CLKDM_NO_AUTODEPS),
+};
Table 8-89 CM_WKUP_CLKSTCTRL Register Field Descriptions of SPRUH73D
claims that this clockdomain supports hardware-supervised automatic
clockdomain transitions. Again this conflicts with Table 8-9. Is this a
documentation bug, or should we update the patch?
Ditto, should be considered as doc issue. I have already raised all this
documentation issues, and should get fixed.
Thanks,
Vaibhav
- 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 10/19] ARM: OMAP4: PM: Work-around for ROM code BUG of IVAHD/TESLA
On Tue, 2012-04-24 at 12:50 -0500, Jon Hunter wrote:
Hi Tero,
On 04/20/2012 04:33 AM, Tero Kristo wrote:
From: Santosh Shilimkar santosh.shilim...@ti.com
The ROM BUG is when MPU Domain OFF wake up sequence that can compromise
IVA and Tesla execution.
At wakeup from MPU OFF on HS device only (not GP device), when
restoring the Secure RAM, the ROM Code reconfigures the clocks the
same way it is done at Cold Reset.
The IVAHD Clocks and Power Domain settings are:
IVAHD_CM2 IVAHD_CLKCTRL_MODULE_MODE = DISABLE
IVAHD_CM2 SL2_CLKCTRL_MODULE_MODE = DISABLE
IVAHD_CM2 SL2_CLKSTCTRL_CLKTRCTRL = HW_AUTO
IVAHD_PRM IVAHD_PWRSTCTRL_POWERSTATE = OFF
The TESLA Clocks and Power Domain settings are:
TESLA_CM1 TESLA_CLKCTRL_MODULE_MODE = DISABLE
TESLA_CM1 TESLA_CLKSTCTRL_CLKTRCTRL = HW_AUTO
TESLA_PRM TESLA_PWRSTCTRL_POWERSTATE = OFF
This patch fixes the low power OFF mode code so that the these
registers are saved and restore across MPU OFF state.
Also because of this limitation, MPU OFF alone is not targeted without
device OFF to avoid IVAHD and TESLA execution impact
You may wish to state which devices is impacted by this in the changelog.
Okay.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
[t-kri...@ti.com: added omap4 pm errata support]
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 53
+
arch/arm/mach-omap2/pm.h |2 +
arch/arm/mach-omap2/pm44xx.c |9 +
3 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index b9a2cc7..208d4a4 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -52,6 +52,7 @@
#include plat/omap44xx.h
+#include iomap.h
#include common.h
#include omap4-sar-layout.h
#include pm.h
@@ -76,6 +77,24 @@ static DEFINE_PER_CPU(struct omap4_cpu_pm_info,
omap4_pm_info);
static struct powerdomain *mpuss_pd;
static void __iomem *sar_base;
+struct reg_tuple {
+ void __iomem *addr;
+ u32 val;
+};
+
+static struct reg_tuple tesla_reg[] = {
+ {.addr = OMAP4430_CM_TESLA_CLKSTCTRL},
+ {.addr = OMAP4430_CM_TESLA_TESLA_CLKCTRL},
+ {.addr = OMAP4430_PM_TESLA_PWRSTCTRL},
+};
+
+static struct reg_tuple ivahd_reg[] = {
+ {.addr = OMAP4430_CM_IVAHD_CLKSTCTRL},
+ {.addr = OMAP4430_CM_IVAHD_IVAHD_CLKCTRL},
+ {.addr = OMAP4430_CM_IVAHD_SL2_CLKCTRL},
+ {.addr = OMAP4430_PM_IVAHD_PWRSTCTRL}
+};
+
/*
* Program the wakeup routine address for the CPU0 and CPU1
* used for OFF or DORMANT wakeup.
@@ -215,6 +234,34 @@ static void save_l2x0_context(void)
{}
#endif
+static inline void save_ivahd_tesla_regs(void)
+{
+ int i;
+
+ if (!IS_PM44XX_ERRATUM(PM_OMAP4_ROM_IVAHD_TESLA_ERRATUM))
+ return;
+
+ for (i = 0; i ARRAY_SIZE(tesla_reg); i++)
+ tesla_reg[i].val = __raw_readl(tesla_reg[i].addr);
+
+ for (i = 0; i ARRAY_SIZE(ivahd_reg); i++)
+ ivahd_reg[i].val = __raw_readl(ivahd_reg[i].addr);
+}
+
+static inline void restore_ivahd_tesla_regs(void)
+{
+ int i;
+
+ if (!IS_PM44XX_ERRATUM(PM_OMAP4_ROM_IVAHD_TESLA_ERRATUM))
+ return;
+
+ for (i = 0; i ARRAY_SIZE(tesla_reg); i++)
+ __raw_writel(tesla_reg[i].val, tesla_reg[i].addr);
+
+ for (i = 0; i ARRAY_SIZE(ivahd_reg); i++)
+ __raw_writel(ivahd_reg[i].val, ivahd_reg[i].addr);
+}
+
/**
* omap4_enter_lowpower: OMAP4 MPUSS Low Power Entry Function
* The purpose of this function is to manage low power programming
@@ -273,11 +320,14 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned
int power_state)
omap_sar_overwrite();
omap4_cm_prepare_off();
omap4_dpll_prepare_off();
+ save_ivahd_tesla_regs();
save_state = 3;
} else if ((pwrdm_read_next_pwrst(mpuss_pd) == PWRDM_POWER_RET)
(pwrdm_read_logic_retst(mpuss_pd) == PWRDM_POWER_OFF)) {
+ save_ivahd_tesla_regs();
save_state = 2;
} else if (pwrdm_read_next_pwrst(mpuss_pd) == PWRDM_POWER_OFF) {
+ save_ivahd_tesla_regs();
save_state = 3;
}
@@ -302,6 +352,9 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int
power_state)
wakeup_cpu = smp_processor_id();
set_cpu_next_pwrst(wakeup_cpu, PWRDM_POWER_ON);
+ if (omap4_mpuss_read_prev_context_state())
+ restore_ivahd_tesla_regs();
+
if (omap4_device_prev_state_off()) {
omap4_dpll_resume_off();
omap4_cm_resume_off();
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
Re: [PATCH 11/19] ARM: OMAP4: PM: save/restore CM L3INSTR registers when MPU hits OSWR/OFF mode
On Tue, 2012-04-24 at 12:57 -0500, Jon Hunter wrote: Hi Tero, On 04/20/2012 04:33 AM, Tero Kristo wrote: From: Rajendra Nayak rna...@ti.com On HS devices on the way out of MPU OSWR and OFF ROM code wrongly overwrites the CM L3INSTR registers. So to avoid this, save them and restore on the way out from MPU OSWR/OFF. This appears to be an errata. So, it would be good to state explicitly here that all revisions of all omap4 devices are impacted by this errata. The code implies this but for documentation purposes it would be worth stating. Okay, I'll add some extra beef here. -Tero -- 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/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
On Mon, 2012-04-23 at 11:09 -0500, Jon Hunter wrote:
Hi Tero,
On 04/20/2012 04:33 AM, Tero Kristo wrote:
[...]
+/**
+ * omap4_dpll_print_reg - dump out a single DPLL register value
+ * @dpll_reg: register to dump
+ * @name: name of the register
+ * @tuple: content of the register
+ *
+ * Helper dump function to print out a DPLL register value in case
+ * of restore failures.
+ */
+static void omap4_dpll_print_reg(struct omap4_dpll_regs *dpll_reg, char
*name,
+struct dpll_reg *tuple)
+{
+ if (tuple-offset)
+ pr_warn(%s - Address offset = 0x%08x, value=0x%08x\n, name,
+ tuple-offset, tuple-val);
Minor nit-pick here ...
1. Offset is 16-bits and so we can just have offset = 0x%04x
2. Consider dropping Address from Address offset
3. Can we be consistent in our spaces for offset = and value=?
+}
+
+/*
+ * omap4_dpll_dump_regs - dump out DPLL registers
+ * @dpll_reg: DPLL to dump
+ *
+ * Dump out the contents of the registers for a DPLL. Called if a
+ * restore for DPLL fails to lock.
+ */
+static void omap4_dpll_dump_regs(struct omap4_dpll_regs *dpll_reg)
+{
+ pr_warn(%s: Unable to lock dpll %s[part=%x inst=%x]:\n,
+ __func__, dpll_reg-name, dpll_reg-mod_partition,
+ dpll_reg-mod_inst);
+ omap4_dpll_print_reg(dpll_reg, clksel, dpll_reg-clksel);
+ omap4_dpll_print_reg(dpll_reg, div_m2, dpll_reg-div_m2);
+ omap4_dpll_print_reg(dpll_reg, div_m3, dpll_reg-div_m3);
+ omap4_dpll_print_reg(dpll_reg, div_m4, dpll_reg-div_m4);
+ omap4_dpll_print_reg(dpll_reg, div_m5, dpll_reg-div_m5);
+ omap4_dpll_print_reg(dpll_reg, div_m6, dpll_reg-div_m6);
+ omap4_dpll_print_reg(dpll_reg, div_m7, dpll_reg-div_m7);
+ omap4_dpll_print_reg(dpll_reg, clkdcoldo, dpll_reg-clkdcoldo);
+ omap4_dpll_print_reg(dpll_reg, clkmode, dpll_reg-clkmode);
+ omap4_dpll_print_reg(dpll_reg, autoidle, dpll_reg-autoidle);
+ if (dpll_reg-idlest.offset)
+ pr_warn(idlest - Address offset = 0x%08x, before val=0x%08x
+after = 0x%08x\n, dpll_reg-idlest.offset,
+ dpll_reg-idlest.val,
+ omap4_dpll_read_reg(dpll_reg, dpll_reg-idlest));
Nit-pick ...
1. Same comments as above
2. Consider dropping Address offset altogether here as we print
idlest the offset should be implied.
3. Also can we be consistent in our naming of before val and after?
For example, val before = and val now = .
Okay, I'll modify both prints slightly. Question though, do we want
these prints in the kernel in the first place? At least Tony has been
frowning upon register dumps in the kernel and this falls into that
category. What we could do is just to print the warning but drop the
register dumps out.
-Tero
--
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 0/6] twl4030: Various fixes for charing-from-USB
Following are a collection of patches that I've need using for a while to make sure the charge-from-usb on my GTA04 works. Hopefully I've included the right people in the recipient list :-) The issues are: - charge the backup battery as well as the main battery - charge from a charger which ties ID to ground via a resistor - charge while device is suspended, or when no gadget module is loaded (i.e. when the USB side thinks the phy should be powered down). Questions and comments more welcome. Thanks, NeilBrown --- NeilBrown (6): twl4030-usb: Don't report EVENT_ID when there is VBUS. twl4030-usb: Don't power down phy when it is in-use by charger. twl4030_charger: Allow charger to control the regulator that feeds it. twl4030_charger: allow charging whenever VBUS is present. twl4030_charger: add backup-battery charging. twl4030_charger: Fix some typos drivers/mfd/twl-core.c |9 ++-- drivers/power/twl4030_charger.c | 86 +++ drivers/usb/otg/twl4030-usb.c | 27 include/linux/i2c/twl.h |2 + 4 files changed, 102 insertions(+), 22 deletions(-) -- Signature -- 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/6] twl4030_charger: Fix some typos
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/power/twl4030_charger.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index fdad850..3e6e991 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -103,7 +103,7 @@ static int twl4030_bci_read(u8 reg, u8 *val)
static int twl4030_clear_set_boot_bci(u8 clear, u8 set)
{
- return twl4030_clear_set(TWL4030_MODULE_PM_MASTER, 0,
+ return twl4030_clear_set(TWL4030_MODULE_PM_MASTER, clear,
TWL4030_CONFIG_DONE | TWL4030_BCIAUTOWEN | set,
TWL4030_PM_MASTER_BOOT_BCI);
}
@@ -151,14 +151,14 @@ static int twl4030_bci_have_vbus(struct twl4030_bci *bci)
}
/*
- * Enable/Disable USB Charge funtionality.
+ * Enable/Disable USB Charge functionality.
*/
static int twl4030_charger_enable_usb(struct twl4030_bci *bci, bool enable)
{
int ret;
if (enable) {
- /* Check for USB charger conneted */
+ /* Check for USB charger connected */
if (!twl4030_bci_have_vbus(bci))
return -ENODEV;
--
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/6] twl4030_charger: add backup-battery charging.
This allows a voltage and current (bb_uvolts and bb_uamps)
to be specified in the platform_data, and charging of the backup
battery will be enabled with those specification.
As it is not possible to monitor the backup battery at all
there is no new device created to represent it.
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/power/twl4030_charger.c | 59 +++
include/linux/i2c/twl.h |2 +
2 files changed, 61 insertions(+)
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index 3e6e991..0511610 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -28,6 +28,7 @@
#define TWL4030_BCIVBUS0x0c
#define TWL4030_BCIMFSTS4 0x10
#define TWL4030_BCICTL10x23
+#define TWL4030_BB_CFG 0x12
#define TWL4030_BCIAUTOWEN BIT(5)
#define TWL4030_CONFIG_DONEBIT(4)
@@ -37,6 +38,17 @@
#define TWL4030_USBFASTMCHGBIT(2)
#define TWL4030_STS_VBUS BIT(7)
#define TWL4030_STS_USB_ID BIT(2)
+#define TWL4030_BBCHEN BIT(4)
+#define TWL4030_BBSEL_MASK 0b1100
+#define TWL4030_BBSEL_2V5 0b
+#define TWL4030_BBSEL_3V0 0b0100
+#define TWL4030_BBSEL_3V1 0b1000
+#define TWL4030_BBSEL_3V2 0b1100
+#define TWL4030_BBISEL_MASK0b11
+#define TWL4030_BBISEL_25uA0b00
+#define TWL4030_BBISEL_150uA 0b01
+#define TWL4030_BBISEL_500uA 0b10
+#define TWL4030_BBISEL_1000uA 0b11
/* BCI interrupts */
#define TWL4030_WOVF BIT(0) /* Watchdog overflow */
@@ -202,6 +214,49 @@ static int twl4030_charger_enable_ac(bool enable)
}
/*
+ * Enable/Disable charging of Backup Battery.
+ */
+static int twl4030_charger_enable_backup(int uvolt, int uamp)
+{
+ int ret;
+ u8 flags;
+
+ if (uvolt 250 ||
+ uamp 25) {
+ /* disable charging of backup battery */
+ ret = twl4030_clear_set(TWL4030_MODULE_PM_RECEIVER,
+ TWL4030_BBCHEN, 0, TWL4030_BB_CFG);
+ return ret;
+ }
+
+ flags = TWL4030_BBCHEN;
+ if (uvolt = 320)
+ flags |= TWL4030_BBSEL_3V2;
+ else if (uvolt = 310)
+ flags |= TWL4030_BBSEL_3V1;
+ else if (uvolt = 300)
+ flags |= TWL4030_BBSEL_3V0;
+ else
+ flags |= TWL4030_BBSEL_2V5;
+
+ if (uamp = 1000)
+ flags |= TWL4030_BBISEL_1000uA;
+ else if (uamp = 500)
+ flags |= TWL4030_BBISEL_500uA;
+ else if (uamp = 150)
+ flags |= TWL4030_BBISEL_150uA;
+ else
+ flags |= TWL4030_BBISEL_25uA;
+
+ ret = twl4030_clear_set(TWL4030_MODULE_PM_RECEIVER,
+ TWL4030_BBSEL_MASK | TWL4030_BBISEL_MASK,
+ flags,
+ TWL4030_BB_CFG);
+
+ return ret;
+}
+
+/*
* TWL4030 CHG_PRES (AC charger presence) events
*/
static irqreturn_t twl4030_charger_interrupt(int irq, void *arg)
@@ -424,6 +479,7 @@ static enum power_supply_property twl4030_charger_props[] =
{
static int __init twl4030_bci_probe(struct platform_device *pdev)
{
struct twl4030_bci *bci;
+ struct twl4030_bci_platform_data *pdata = pdev-dev.platform_data;
int ret;
u32 reg;
@@ -503,6 +559,8 @@ static int __init twl4030_bci_probe(struct platform_device
*pdev)
twl4030_charger_enable_ac(true);
twl4030_charger_enable_usb(bci, true);
+ twl4030_charger_enable_backup(pdata-bb_uvolt,
+ pdata-bb_uamp);
return 0;
@@ -531,6 +589,7 @@ static int __exit twl4030_bci_remove(struct platform_device
*pdev)
twl4030_charger_enable_ac(false);
twl4030_charger_enable_usb(bci, false);
+ twl4030_charger_enable_backup(0, 0);
/* mask interrupts */
twl_i2c_write_u8(TWL4030_MODULE_INTERRUPTS, 0xff,
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index 1f90de0..b526031 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -557,6 +557,8 @@ struct twl4030_clock_init_data {
struct twl4030_bci_platform_data {
int *battery_tmp_tbl;
unsigned int tblsize;
+ int bb_uvolt; /* voltage to charge backup battery */
+ int bb_uamp;/* current for backup battery charging */
};
/* TWL4030_GPIO_MAX (18) GPIOs, with interrupts */
--
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 3/6] twl4030_charger: allow charging whenever VBUS is present.
We currently refuse to charge if the USB ID pin is grounded, even though VBUS might be present. However some chargers do pull the ID pin low through a resistor which might be as low as 47Kohm (openmoko charger). The documentation is unclear but some experimental evidence suggests that when the charge pump provides VBUS that doesn't get reflected in HW_CONDITIONS, so we should be safe to ignore the ID pin. Signed-off-by: NeilBrown ne...@suse.de --- drivers/power/twl4030_charger.c |6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c index 0511610..684662a 100644 --- a/drivers/power/twl4030_charger.c +++ b/drivers/power/twl4030_charger.c @@ -155,11 +155,7 @@ static int twl4030_bci_have_vbus(struct twl4030_bci *bci) dev_dbg(bci-dev, check_vbus: HW_CONDITIONS %02x\n, hwsts); - /* in case we also have STS_USB_ID, VBUS is driven by TWL itself */ - if ((hwsts TWL4030_STS_VBUS) !(hwsts TWL4030_STS_USB_ID)) - return 1; - - return 0; + return (hwsts TWL4030_STS_VBUS); } /* -- 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 4/6] twl4030_charger: Allow charger to control the regulator that feeds it.
The charger needs usb3v1 to be running, so add a new consumer to
keep it running.
This allows the charger to draw current even when the USB driver has
powered down.
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/mfd/twl-core.c |9 +
drivers/power/twl4030_charger.c | 15 +++
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 7c2267e..4cbf285 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -723,8 +723,9 @@ add_children(struct twl4030_platform_data *pdata, unsigned
irq_base,
static struct regulator_consumer_supply usb1v8 = {
.supply = usb1v8,
};
- static struct regulator_consumer_supply usb3v1 = {
- .supply = usb3v1,
+ static struct regulator_consumer_supply usb3v1[] = {
+ { .supply = usb3v1 },
+ { .supply = bci3v1 },
};
/* First add the regulators so that they can be used by transceiver */
@@ -752,7 +753,7 @@ add_children(struct twl4030_platform_data *pdata, unsigned
irq_base,
return PTR_ERR(child);
child = add_regulator_linked(TWL4030_REG_VUSB3V1,
- usb_fixed, usb3v1, 1,
+ usb_fixed, usb3v1, 2,
features);
if (IS_ERR(child))
return PTR_ERR(child);
@@ -773,7 +774,7 @@ add_children(struct twl4030_platform_data *pdata, unsigned
irq_base,
if (twl_has_regulator() child) {
usb1v5.dev_name = dev_name(child);
usb1v8.dev_name = dev_name(child);
- usb3v1.dev_name = dev_name(child);
+ usb3v1[0].dev_name = dev_name(child);
}
}
if (twl_has_usb() pdata-usb twl_class_is_6030()) {
diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index 684662a..d9d8e4a 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -21,6 +21,7 @@
#include linux/power_supply.h
#include linux/notifier.h
#include linux/usb/otg.h
+#include linux/regulator/machine.h
#define TWL4030_BCIMSTATEC 0x02
#define TWL4030_BCIICHG0x08
@@ -86,6 +87,8 @@ struct twl4030_bci {
struct work_struct work;
int irq_chg;
int irq_bci;
+ struct regulator*usb_reg;
+ int usb_enabled;
unsigned long event;
};
@@ -179,6 +182,12 @@ static int twl4030_charger_enable_usb(struct twl4030_bci
*bci, bool enable)
return -EACCES;
}
+ /* Need to keep regulator on */
+ if (!bci-usb_enabled) {
+ regulator_enable(bci-usb_reg);
+ bci-usb_enabled = 1;
+ }
+
/* forcing the field BCIAUTOUSB (BOOT_BCI[1]) to 1 */
ret = twl4030_clear_set_boot_bci(0, TWL4030_BCIAUTOUSB);
if (ret 0)
@@ -189,6 +198,10 @@ static int twl4030_charger_enable_usb(struct twl4030_bci
*bci, bool enable)
TWL4030_USBFASTMCHG, TWL4030_BCIMFSTS4);
} else {
ret = twl4030_clear_set_boot_bci(TWL4030_BCIAUTOUSB, 0);
+ if (bci-usb_enabled) {
+ regulator_disable(bci-usb_reg);
+ bci-usb_enabled = 0;
+ }
}
return ret;
@@ -507,6 +520,8 @@ static int __init twl4030_bci_probe(struct platform_device
*pdev)
bci-usb.num_properties = ARRAY_SIZE(twl4030_charger_props);
bci-usb.get_property = twl4030_bci_get_property;
+ bci-usb_reg = regulator_get(bci-dev, bci3v1);
+
ret = power_supply_register(pdev-dev, bci-usb);
if (ret) {
dev_err(pdev-dev, failed to register usb: %d\n, ret);
--
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 5/6] twl4030-usb: Don't power down phy when it is in-use by charger.
The USB phy is used both for data transfer and to charge the battery.
If the charger it active it will hold a reference to
usb3v1. In that case we don't want to power-down the phy.
This allows charging to continue while the device is suspended.
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/usb/otg/twl4030-usb.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index c4a86da..bd8fe9b 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -388,10 +388,16 @@ static void twl4030_phy_power(struct twl4030_usb *twl,
int on)
(PHY_CLK_CTRL_CLOCKGATING_EN |
PHY_CLK_CTRL_CLK32K_EN));
} else {
- __twl4030_phy_power(twl, 0);
regulator_disable(twl-usb1v5);
regulator_disable(twl-usb1v8);
regulator_disable(twl-usb3v1);
+ if (!regulator_is_enabled(twl-usb3v1))
+ /* no-one else is requesting this
+* so it is OK to power-down the
+* phy. Sometimes a charger might
+* hold the regulator active.
+*/
+ __twl4030_phy_power(twl, 0);
}
}
--
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 6/6] twl4030-usb: Don't report EVENT_ID when there is VBUS.
Some USB chargers tie the ID pin low via various resistors.
So they can cause VBUS to be high and ID to be low.
The 'A' end of an OTG cable never receives VBUS, it only ever generates it.
So if we see VBUS and are not generating it, this must be a charger,
not the A end of an OTG cable, so in that case, ignore the fact that
ID is low.
This assumes that VBUS_PRES isn't asserted when the charge pump is
providing VBUS. The document isn't clear on this and some experiments
suggest that it isn't.
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/usb/otg/twl4030-usb.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index bd8fe9b..990400f 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -268,15 +268,16 @@ static enum usb_phy_events twl4030_usb_linkstat(struct
twl4030_usb *twl)
STS_HW_CONDITIONS);
if (status 0)
dev_err(twl-dev, USB link status err %d\n, status);
- else if (status (BIT(7) | BIT(2))) {
- if (status (BIT(7)))
-twl-vbus_supplied = true;
-
- if (status BIT(2))
- linkstat = USB_EVENT_ID;
- else
- linkstat = USB_EVENT_VBUS;
- } else
+ else if (status (BIT(7))) {
+ /* We have VBUS so ignore ID_PRES - it is only meaningful
+* as an indicator of an A plug when there is no
+* VBUS.
+*/
+ twl-vbus_supplied = true;
+ linkstat = USB_EVENT_VBUS;
+ } else if (status BIT(2))
+ linkstat = USB_EVENT_ID;
+ else
linkstat = USB_EVENT_NONE;
dev_dbg(twl-dev, HW_CONDITIONS 0x%02x/%d; link %d\n,
--
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: [RESEND PATCH 1/2] ARM: OMAP2+: nand: Make board_onenand_init() visible to board code
2012/4/4 Javier Martinez Canillas jav...@dowhile0.org:
board_onenand_init() and board_nand_init() initialization functions are
used to initialize OneNAND and NAND memories respectively. But only
board_nand_init() was visible to be used from board code. This patch makes
possible to initialize a OneNAND flash memory within platform code.
Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org
---
arch/arm/mach-omap2/board-flash.c | 4 ++--
arch/arm/mach-omap2/board-flash.h | 11 +++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 0349fd2..70a81f9 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -87,7 +87,7 @@ static struct omap_onenand_platform_data board_onenand_data
= {
.dma_channel = -1, /* disable DMA in OMAP OneNAND driver */
};
-static void
+void
__init board_onenand_init(struct mtd_partition *onenand_parts,
u8 nr_parts, u8 cs)
{
@@ -98,7 +98,7 @@ __init board_onenand_init(struct mtd_partition
*onenand_parts,
gpmc_onenand_init(board_onenand_data);
}
#else
-static void
+void
__init board_onenand_init(struct mtd_partition *nor_parts, u8 nr_parts, u8
cs)
{
}
diff --git a/arch/arm/mach-omap2/board-flash.h
b/arch/arm/mach-omap2/board-flash.h
index d25503a..c44b70d 100644
--- a/arch/arm/mach-omap2/board-flash.h
+++ b/arch/arm/mach-omap2/board-flash.h
@@ -47,3 +47,14 @@ static inline void board_nand_init(struct mtd_partition
*nand_parts,
{
}
#endif
+
+#if defined(CONFIG_MTD_ONENAND_OMAP2) || \
+ defined(CONFIG_MTD_ONENAND_OMAP2_MODULE)
+extern void board_onenand_init(struct mtd_partition *nand_parts,
+ u8 nr_parts, u8 cs);
+#else
+static inline void board_onenand_init(struct mtd_partition *nand_parts,
+ u8 nr_parts, u8 cs)
+{
+}
+#endif
--
1.7.7.6
Seems good to me.
Tony, as this is a fix ,may be included ?
Acked-by: Enric Balletbo i Serra eballe...@gmail.com
Tested-by: Enric Balletbo i Serra eballe...@gmail.com
Cheers,
Enric
--
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 15/19] ARM: OMAP4430: PM: workaround for DDR corruption on second CS
On Wed, Apr 25, 2012 at 12:56 PM, Tero Kristo t-kri...@ti.com wrote:
On Tue, 2012-04-24 at 13:22 -0500, Jon Hunter wrote:
Hi Tero,
On 04/20/2012 04:33 AM, Tero Kristo wrote:
From: Santosh Shilimkar santosh.shilim...@ti.com
Work around for Errata ID: i632 LPDDR2 Corruption After OFF Mode
Transition When CS1 Is Used On EMIF which impacts OMAP443x silicon
The issue occurs when EMIF_SDRAM_CONFIG is restored first before
EMIF_SDRAM_CONFIG_2 is not yet restored, the register configuration
is not set properly, we apply the required workaround allowing
the restore sequence to work properly.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
[t-kri...@ti.com: moved workaround from omap-sar.c to pm44xx.c]
Signed-off-by: Tero Kristo t-kri...@ti.com
---
.../include/mach/ctrl_module_wkup_44xx.h | 2 +
arch/arm/mach-omap2/pm44xx.c | 24
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
b/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
index a0af9ba..b763a79 100644
--- a/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
+++ b/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
@@ -28,6 +28,8 @@
#define OMAP4_CTRL_MODULE_WKUP_IP_REVISION 0x
#define OMAP4_CTRL_MODULE_WKUP_IP_HWINFO 0x0004
#define OMAP4_CTRL_MODULE_WKUP_IP_SYSCONFIG 0x0010
+#define OMAP4_CTRL_SECURE_EMIF1_SDRAM_CONFIG2_REG 0x0114
+#define OMAP4_CTRL_SECURE_EMIF2_SDRAM_CONFIG2_REG 0x011c
#define OMAP4_CTRL_MODULE_WKUP_CONF_DEBUG_SEL_TST_0 0x0460
#define OMAP4_CTRL_MODULE_WKUP_CONF_DEBUG_SEL_TST_1 0x0464
#define OMAP4_CTRL_MODULE_WKUP_CONF_DEBUG_SEL_TST_2 0x0468
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 0472921..d4d18d9 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -17,6 +17,9 @@
#include linux/err.h
#include linux/slab.h
#include asm/system_misc.h
+#include linux/io.h
+
+#include mach/ctrl_module_wkup_44xx.h
#include common.h
#include clockdomain.h
@@ -215,6 +218,27 @@ static int __init omap4_pm_init(void)
pr_err(Power Management for TI OMAP4.\n);
+ /*
+ * Work around for OMAP443x Errata i632: LPDDR2 Corruption After OFF
+ * Mode Transition When CS1 Is Used On EMIF:
+ * Overwrite EMIF1/EMIF2
+ * SECURE_EMIF1_SDRAM_CONFIG2_REG
+ * SECURE_EMIF2_SDRAM_CONFIG2_REG
+ */
+ if (cpu_is_omap443x()) {
+ void __iomem *secure_ctrl_mod;
+
+ secure_ctrl_mod = ioremap(OMAP4_CTRL_MODULE_WKUP, SZ_4K);
+ BUG_ON(!secure_ctrl_mod);
+
+ __raw_writel(0x10, secure_ctrl_mod +
+ OMAP4_CTRL_SECURE_EMIF1_SDRAM_CONFIG2_REG);
+ __raw_writel(0x10, secure_ctrl_mod +
+ OMAP4_CTRL_SECURE_EMIF2_SDRAM_CONFIG2_REG);
According to the erratum description the above registers are used to
restore the EMIFx_SDRAM_CONFIG2 registers. So although the value 0x10,
maybe the value being used for EMIFx_SDRAM_CONFIG2 registers, shouldn't
we read the EMIFx_SDRAM_CONFIG2 registers and store them in the above
registers?
This might be a good idea, however, this patch might be tagged as TEMP
until the EMIF driver is in place, this fix should rather be located
there. I'll take a look at this if I can change the implementation a
bit.
This patch doesn't have any dependency with EMIF driver since it's more of
SAR restore BUG. If the dependency is from the regsister macro etc point
of view, PM code can to the mapping and since it is needed only once
in the init. EMIF driver is unware of SAR restore phase and that was the
purpose of the DMA bases SAR restore design.
Hope this clarifies.
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: [RESEND PATCH 2/2] OMAP3: igep0020: Add support for Micron NAND Flash storage memory
2012/4/4 Javier Martinez Canillas jav...@dowhile0.org:
IGEP-based boards can have two different flash memories, a OneNAND or
a NAND device. The boot configuration pins (sys_boot) are used to
specify which memory is available.
Also, this patch removes unnecesary code for registering the OneNAND.
Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org
---
arch/arm/mach-omap2/board-igep0020.c | 75
++
1 files changed, 31 insertions(+), 44 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 930c0d3..4af615a 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -24,6 +24,8 @@
#include linux/i2c/twl.h
#include linux/mmc/host.h
+#include linux/mtd/nand.h
+
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -39,6 +41,8 @@
#include hsmmc.h
#include sdram-numonyx-m65kam.h
#include common-board-devices.h
+#include board-flash.h
+#include control.h
#define IGEP2_SMSC911X_CS 5
#define IGEP2_SMSC911X_GPIO 176
@@ -60,6 +64,10 @@
#define IGEP3_GPIO_LED1_RED 16
#define IGEP3_GPIO_USBH_NRESET 183
+#define IGEP_SYSBOOT_MASK 0x1f
+#define IGEP_SYSBOOT_NAND 0x0f
+#define IGEP_SYSBOOT_ONENAND 0x10
+
/*
* IGEP2 Hardware Revision Table
*
@@ -110,8 +118,10 @@ static void __init igep2_get_revision(void)
gpio_free(IGEP2_GPIO_LED1_RED);
}
-#if defined(CONFIG_MTD_ONENAND_OMAP2) || \
- defined(CONFIG_MTD_ONENAND_OMAP2_MODULE)
+#if defined(CONFIG_MTD_ONENAND_OMAP2) || \
+ defined(CONFIG_MTD_ONENAND_OMAP2_MODULE) || \
+ defined(CONFIG_MTD_NAND_OMAP2) || \
+ defined(CONFIG_MTD_NAND_OMAP2_MODULE)
#define ONENAND_MAP 0x2000
@@ -123,7 +133,7 @@ static void __init igep2_get_revision(void)
* So MTD regards it as 4KiB page size and 256KiB block size 64*(2*2048)
*/
-static struct mtd_partition igep_onenand_partitions[] = {
+static struct mtd_partition igep_flash_partitions[] = {
{
.name = X-Loader,
.offset = 0,
@@ -151,50 +161,27 @@ static struct mtd_partition igep_onenand_partitions[] =
{
},
};
-static struct omap_onenand_platform_data igep_onenand_data = {
- .parts = igep_onenand_partitions,
- .nr_parts = ARRAY_SIZE(igep_onenand_partitions),
- .dma_channel = -1, /* disable DMA in OMAP OneNAND driver */
-};
-
-static struct platform_device igep_onenand_device = {
- .name = omap2-onenand,
- .id = -1,
- .dev = {
- .platform_data = igep_onenand_data,
- },
-};
+static inline u32 igep_get_sysboot_value(void)
+{
+ return omap_ctrl_readl(OMAP343X_CONTROL_STATUS) IGEP_SYSBOOT_MASK;
+}
static void __init igep_flash_init(void)
{
- u8 cs = 0;
- u8 onenandcs = GPMC_CS_NUM + 1;
-
- for (cs = 0; cs GPMC_CS_NUM; cs++) {
- u32 ret;
- ret = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
-
- /* Check if NAND/oneNAND is configured */
- if ((ret 0xC00) == 0x800)
- /* NAND found */
- pr_err(IGEP: Unsupported NAND found\n);
- else {
- ret = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG7);
- if ((ret 0x3F) == (ONENAND_MAP 24))
- /* ONENAND found */
- onenandcs = cs;
- }
- }
-
- if (onenandcs GPMC_CS_NUM) {
- pr_err(IGEP: Unable to find configuration in GPMC\n);
- return;
- }
-
- igep_onenand_data.cs = onenandcs;
-
- if (platform_device_register(igep_onenand_device) 0)
- pr_err(IGEP: Unable to register OneNAND device\n);
+ u32 mux;
+ mux = igep_get_sysboot_value();
+
+ if (mux == IGEP_SYSBOOT_NAND) {
+ pr_info(IGEP: initializing NAND memory device\n);
+ board_nand_init(igep_flash_partitions,
+ ARRAY_SIZE(igep_flash_partitions),
+ 0, NAND_BUSWIDTH_16);
+ } else if (mux == IGEP_SYSBOOT_ONENAND) {
+ pr_info(IGEP: initializing OneNAND memory device\n);
+ board_onenand_init(igep_flash_partitions,
+ ARRAY_SIZE(igep_flash_partitions), 0);
+ } else
+ pr_err(IGEP: Flash: unsupported sysboot sequence found\n);
}
#else
--
1.7.7.6
Seems good to me.
Tony, as this is a fix ,may be included ?
Acked-by: Enric Balletbo i Serra eballe...@gmail.com
Tested-by: Enric Balletbo i Serra eballe...@gmail.com
Cheers,
Enric
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
Re: [PATCH 6/6] twl4030-usb: Don't report EVENT_ID when there is VBUS.
Hi, On Wed, Apr 25, 2012 at 05:33:11PM +1000, NeilBrown wrote: Some USB chargers tie the ID pin low via various resistors. So they can cause VBUS to be high and ID to be low. The 'A' end of an OTG cable never receives VBUS, it only ever generates it. this isn't entirely true. Have you considered Accessory Charger Adapters ? So if we see VBUS and are not generating it, this must be a charger, not the A end of an OTG cable, so in that case, ignore the fact that ID is low. wrong. -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] ASoC: omap-pcm: Free dma buffers in case of error.
On Tue, Apr 24, 2012 at 07:02:02PM -0700, Oleg Matcovschi wrote: Change-Id: I4ba9de0de4681332539246ccc5e11a7a8fb32e79 Signed-off-by: Oleg Matcovschi oleg.matcovs...@ti.com Don't include Change-Ids in upstream submissions, they only make sense within whatever private development tree you are using. Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com signature.asc Description: Digital signature
Re: [PATCH-V3 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data
Hi Vaibhav, On 4/25/2012 7:48 AM, Hiremath, Vaibhav wrote: On Wed, Apr 25, 2012 at 06:33:26, Paul Walmsley wrote: Hello Vaibhav, Afzal, Vaibhav, On Tue, 3 Apr 2012, Vaibhav Hiremath wrote: AM33XX clock implementation is different than any existing OMAP family of devices. Although DPLL module is similar to OMAP4 device, but the usage is very much different than OMAP4. AM33XX has different peripheral set and each module gets integrated to the clock framework differently than OMAP family of devices. This patch adds full Clock tree data for AM33XX family of devices and also integrates it into existing OMAP framework. What do you think about the possibility of removing all of the leaf clocks that have AM33XX_MODULEMODE_SWCTRL as their .enable_bit, assuming there are no .fixed_div or .clksel* fields associated with the clocks? In theory, I don't think they are needed. The drivers should be using runtime PM, and that should enable and disable the module via the hwmod code, rather than the clock code. Of course some clocks would still be needed for the main_clk fields for the hwmods, but the hwmods should be able to use the leaf clock's parent clocks for that. That would save quite a few lines of data. And I think Benoît is planning to do that for OMAP4+. What do you think? Paul, Yes, theoretically it is possible to do it. But it will also break some of the existing things, like, 1. DebugFS clock interface I believe, with this change, you will not have all the leaf nodes as part of clock tree, so they will not be populated in /debug/clock/ 2. Enable and disable of the module is one part, but what about, changing the rate of the clock (followparent_recalc)? With the proper and complete clock tree, you can traverse the clock and driver code doesn't need to know about parent. Driver can simply call clk_set_rate() on leaf clock, and clock tree will handle it. If at all we take this path, we have to build the clk node runtime (on-the-fly), AND/OR add new pm_runtime_set_rate() api. Not at all. You just have to get the fck of that hwmod and use the clock API. Are you available on IRC chat anytime? We can discuss on this and align quickly. I am available on linux-omap irc channel (with the name = hvaibhav) That will not change anything, the point is that MODULEMODE_SWCTRL is uses for module control, not for clock directly, and that's why it is handled by the hwmod. That will just replace the main_clk from the hwmod with the parent of the current modulemode nodes. Only the enable/disable part will be handled, if that node used to have a div, then the parent will handle that. Today this module mode clock node is just a duplication of the hwmod node. By removing it, you will reduce the size of the data and have a much mode accurate representation of the reality. Using the clock tree to handle these nodes was a hack we had to do because the hwmod fmwk was not ready when OMAP4 was introduced and because most drivers were not using pm_runtime. 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-V4 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param
On Tue, Apr 24, 2012 at 21:50:16, Tony Lindgren wrote:
Thanks Tony for review comments, my response in-lined below -
Hi,
* Vaibhav Hiremath hvaib...@ti.com [120424 02:54]:
Current OMAP code supports couple of clocksource options based
on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz).
So there can be 3 options -
1. 32KHz sync-timer
2. Sys_clock based (e.g 13/19.2/26/38.4 MHz) gptimer
3. 32KHz based gptimer.
The optional gptimer based clocksource was added so that it can
give the high precision than sync-timer, so expected usage was 2
and not 3.
Unfortunately option 2, clocksource doesn't meet the requirement of
free-running clock as per clocksource need. It stops in low power states
when sys_clock is cut. That makes gptimer based clocksource option
useless for OMAP2/3/4 devices with sys_clock as a clock input.
Option 3 will still work but it is no better than 32K sync-timer
based clocksource.
For some cases sys clock based timer is still valid if you don't
care about PM. In that case deeper idle states need to be disabled,
not the timer as discussed earlier. Please update the comments accordingly.
Ok, I will add below statement,
Also, in order to use option 2, deeper idle stated MUST be disabled.
So ideally we can kill the gptimer based clocksource option but there
are some OMAP based derivative SoCs like AM33XX which doesn't have
32K sync-timer hardware IP and need to fallback on 32KHz based gptimer
clocksource.
Maybe just say: We must support both sync timer and gptimer based
clocksource as some AM33XX hardware does not have the sync timer.
Ok, I can change the description accordingly.
Considering above, make sync-timer and gptimer clocksource runtime
selectable so that both OMAP and AM continue to use the same code.
Also, in order to precisely configure/setup sched_clock for given
clocksource, decision has to be made early enough in boot sequence.
So, the solution is,
Use kernel parameter (clocksource=) to override
Maybe say: Use standard kernel parameter (clocksource=)...
Ditto, I will change the description accordingly.
--- a/arch/arm/mach-omap1/timer32k.c
+++ b/arch/arm/mach-omap1/timer32k.c
@@ -71,6 +71,7 @@
/* 16xx specific defines */
#define OMAP1_32K_TIMER_BASE 0xfffb9000
+#define OMAP1_32KSYNC_TIMER_BASE 0xfffbc400
#define OMAP1_32K_TIMER_CR 0x08
#define OMAP1_32K_TIMER_TVR0x00
#define OMAP1_32K_TIMER_TCR0x04
@@ -184,7 +185,10 @@ static __init void omap_init_32k_timer(void)
*/
bool __init omap_32k_timer_init(void)
{
- omap_init_clocksource_32k();
+ u32 pbase;
+
+ pbase = cpu_is_omap16xx() ? OMAP1_32KSYNC_TIMER_BASE : NULL;
+ omap_init_clocksource_32k(pbase, SZ_1K);
omap_init_32k_timer();
return true;
Has this patch been tested on omap1?
I do not have omap1 board with me, so I can not test it. If somebody can
provide some help here, that would be really great?
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -510,3 +540,28 @@ static int __init omap2_dm_timer_init(void)
return 0;
}
arch_initcall(omap2_dm_timer_init);
+
+/**
+ * omap2_override_clocksource - clocksource override with user
configuration
+ *
+ * Allows user to override default clocksource, using kernel parameter
+ * clocksource=gp timer
+ *
+ * Note that, here we are using same standard kernel parameter
clocksource=,
+ * and not introducing any OMAP specific interface.
+ */
+static int __init omap2_override_clocksource(char *str)
+{
+ if (!str)
+ return 0;
+ /*
+* For OMAP architecture, we only have two options
+*- sync_32k (default)
+*- gp timer
+*/
+ if (!strcmp(str, gp timer))
+ use_gptimer_clksrc = true;
+
+ return 0;
+}
+early_param(clocksource, omap2_override_clocksource);
Should say For omap2plus architectures and should say three options.
If the sys clock based timer is not currently supported, please mention
that in the comments.
gp timer above is nothing but, sys_clock based gptimer option only. May be I
should add the source in bracket or something?
Like,
*- sync_32k (default)
*- gp timer (sys_clock)
Thanks,
Vaibhav
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/RFT 1/3] ARM: OMAP2+: powerdomain: allow pre/post transtion to be per pwrdm
On Tue, Apr 24, 2012 at 7:53 PM, Kevin Hilman khil...@ti.com wrote:
Iteration over all power domains in the idle path is unnecessary since
only power domains that are transitioning need to be accounted for.
Also PRCM register accesses are known to be expensive, so the
additional latency added to the idle path is signficiant.
In order allow the pre/post transitions to be isolated and called
per-pwrdm, change the API so passing in a specific power domain will
trigger the pre/post transtion accounting for only that specific power
domain. Passing NULL means iterating over all power domains as is
current behavior.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 4 ++--
arch/arm/mach-omap2/pm34xx.c | 4 ++--
arch/arm/mach-omap2/powerdomain.c | 16
arch/arm/mach-omap2/powerdomain.h | 4 ++--
4 files changed, 18 insertions(+), 10 deletions(-)
[...]
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 96ad3dbe..0baf8c3 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -991,15 +991,23 @@ int pwrdm_clkdm_state_switch(struct clockdomain *clkdm)
return -EINVAL;
}
-int pwrdm_pre_transition(void)
+int pwrdm_pre_transition(struct powerdomain *pwrdm)
{
- pwrdm_for_each(_pwrdm_pre_transition_cb, NULL);
+ if (pwrdm)
+ _pwrdm_pre_transition_cb(pwrdm, NULL);
+ else
+ pwrdm_for_each(_pwrdm_pre_transition_cb, NULL);
+
return 0;
}
Minor nit. Noticed couple of whitespace errors in the patch.
---
ERROR: trailing whitespace
#82: FILE: arch/arm/mach-omap2/powerdomain.c:996:
+^Iif (pwrdm) $
ERROR: trailing whitespace
#84: FILE: arch/arm/mach-omap2/powerdomain.c:998:
+^Ielse $
total: 2 errors, 0 warnings, 69 lines checked
---
Updated patch below with that fixed.
Regards
Santosh
From 2782503adcf91142d2aee4bafe29989095ece3ba Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@ti.com
Date: Wed, 25 Apr 2012 14:05:21 +0530
Subject: [PATCH 1/1] ARM: OMAP2+: powerdomain: allow pre/post transtion to be
per pwrdm
Iteration over all power domains in the idle path is unnecessary since
only power domains that are transitioning need to be accounted for.
Also PRCM register accesses are known to be expensive, so the
additional latency added to the idle path is signficiant.
In order allow the pre/post transitions to be isolated and called
per-pwrdm, change the API so passing in a specific power domain will
trigger the pre/post transtion accounting for only that specific power
domain. Passing NULL means iterating over all power domains as is
current behavior.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/omap-mpuss-lowpower.c |4 ++--
arch/arm/mach-omap2/pm34xx.c |4 ++--
arch/arm/mach-omap2/powerdomain.c | 16
arch/arm/mach-omap2/powerdomain.h |4 ++--
4 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 13670aa..e35a86b 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -255,7 +255,7 @@ int omap4_enter_lowpower(unsigned int cpu,
unsigned int power_state)
return -ENXIO;
}
- pwrdm_pre_transition();
+ pwrdm_pre_transition(NULL);
/*
* Check MPUSS next state and save interrupt controller if needed.
@@ -287,7 +287,7 @@ int omap4_enter_lowpower(unsigned int cpu,
unsigned int power_state)
wakeup_cpu = smp_processor_id();
set_cpu_next_pwrst(wakeup_cpu, PWRDM_POWER_ON);
- pwrdm_post_transition();
+ pwrdm_post_transition(NULL);
return 0;
}
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 703bd10..2451b90 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -307,7 +307,7 @@ void omap_sram_idle(void)
omap3_enable_io_chain();
}
- pwrdm_pre_transition();
+ pwrdm_pre_transition(NULL);
/* PER */
if (per_next_state PWRDM_POWER_ON) {
@@ -372,7 +372,7 @@ void omap_sram_idle(void)
}
omap3_intc_resume_idle();
- pwrdm_post_transition();
+ pwrdm_post_transition(NULL);
/* PER */
if (per_next_state PWRDM_POWER_ON) {
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 96ad3dbe..bb6780d 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -991,15 +991,23 @@ int pwrdm_clkdm_state_switch(struct clockdomain *clkdm)
return -EINVAL;
}
-int pwrdm_pre_transition(void)
+int pwrdm_pre_transition(struct powerdomain *pwrdm)
{
- pwrdm_for_each(_pwrdm_pre_transition_cb, NULL);
+ if (pwrdm)
+
Re: [PATCH 2/3] IRQ: allow check_wakeup_irqs to notice level-triggered interrupts.
On Wed, 25 Apr 2012, NeilBrown wrote:
Level triggered interrupts do not cause IRQS_PENDING to be set, so
check_wakeup_irqs ignores them.
They don't need to set IRQS_PENDING as the level stays high which
shows that they must be pending. However if such an interrupt fired
during late suspend, it will have been masked so the fact that it
is still asserted will not cause the suspend to abort.
So if any wakeup interrupt is masked, unmask it when checking wakeup
irqs. If the interrupt is asserted, suspend will abort.
Signed-off-by: NeilBrown ne...@suse.de
---
kernel/irq/pm.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/irq/pm.c b/kernel/irq/pm.c
index 15e53b1..0d26206 100644
--- a/kernel/irq/pm.c
+++ b/kernel/irq/pm.c
@@ -106,6 +106,12 @@ int check_wakeup_irqs(void)
if (irqd_is_wakeup_set(desc-irq_data)) {
if (desc-istate IRQS_PENDING)
return -EBUSY;
+ if (irqd_irq_masked(desc-irq_data))
+ /* Probably a level interrupt
+ * which fired recently and was
+ * masked
+ */
+ unmask_irq(desc);
Oh no. We don't unmask unconditionally. What about an interrupt which
is disabled, has no handler . ? That needs more thought.
Thanks,
tglx
--
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] ASoC: omap-pcm: Free dma buffers in case of error.
On 04/25/2012 05:02 AM, Oleg Matcovschi wrote: Change-Id: I4ba9de0de4681332539246ccc5e11a7a8fb32e79 Signed-off-by: Oleg Matcovschi oleg.matcovs...@ti.com --- v1: initial revision v2: resending patch including maintainers sound/soc/omap/omap-pcm.c |4 1 files changed, 4 insertions(+), 0 deletions(-) Acked-by: Peter Ujfalusi peter.ujfal...@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
Re: [PATCH 2/3] IRQ: allow check_wakeup_irqs to notice level-triggered interrupts.
On Wed, 25 Apr 2012 10:50:15 +0200 (CEST) Thomas Gleixner
t...@linutronix.de wrote:
On Wed, 25 Apr 2012, NeilBrown wrote:
Level triggered interrupts do not cause IRQS_PENDING to be set, so
check_wakeup_irqs ignores them.
They don't need to set IRQS_PENDING as the level stays high which
shows that they must be pending. However if such an interrupt fired
during late suspend, it will have been masked so the fact that it
is still asserted will not cause the suspend to abort.
So if any wakeup interrupt is masked, unmask it when checking wakeup
irqs. If the interrupt is asserted, suspend will abort.
Signed-off-by: NeilBrown ne...@suse.de
---
kernel/irq/pm.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/irq/pm.c b/kernel/irq/pm.c
index 15e53b1..0d26206 100644
--- a/kernel/irq/pm.c
+++ b/kernel/irq/pm.c
@@ -106,6 +106,12 @@ int check_wakeup_irqs(void)
if (irqd_is_wakeup_set(desc-irq_data)) {
if (desc-istate IRQS_PENDING)
return -EBUSY;
+ if (irqd_irq_masked(desc-irq_data))
+ /* Probably a level interrupt
+* which fired recently and was
+* masked
+*/
+ unmask_irq(desc);
Oh no. We don't unmask unconditionally. What about an interrupt which
is disabled, has no handler . ? That needs more thought.
If there is no handler, then irqd_is_wakeup_set() should fail should it not?
For disabled: would it be OK to check desc-depth?
Something like:
if (desc-depth == 1 (desc-state IRQS_SUSPENDED)
irqd_irq_masked(desc-irq_data))
unmask_irq(desc);
??
Thanks,
NeilBrown
signature.asc
Description: PGP signature
RE: [PATCH-V3 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data
On Wed, Apr 25, 2012 at 14:10:49, Cousson, Benoit wrote: Hi Vaibhav, On 4/25/2012 7:48 AM, Hiremath, Vaibhav wrote: On Wed, Apr 25, 2012 at 06:33:26, Paul Walmsley wrote: Hello Vaibhav, Afzal, Vaibhav, On Tue, 3 Apr 2012, Vaibhav Hiremath wrote: AM33XX clock implementation is different than any existing OMAP family of devices. Although DPLL module is similar to OMAP4 device, but the usage is very much different than OMAP4. AM33XX has different peripheral set and each module gets integrated to the clock framework differently than OMAP family of devices. This patch adds full Clock tree data for AM33XX family of devices and also integrates it into existing OMAP framework. What do you think about the possibility of removing all of the leaf clocks that have AM33XX_MODULEMODE_SWCTRL as their .enable_bit, assuming there are no .fixed_div or .clksel* fields associated with the clocks? In theory, I don't think they are needed. The drivers should be using runtime PM, and that should enable and disable the module via the hwmod code, rather than the clock code. Of course some clocks would still be needed for the main_clk fields for the hwmods, but the hwmods should be able to use the leaf clock's parent clocks for that. That would save quite a few lines of data. And I think Benoît is planning to do that for OMAP4+. What do you think? Paul, Yes, theoretically it is possible to do it. But it will also break some of the existing things, like, 1. DebugFS clock interface I believe, with this change, you will not have all the leaf nodes as part of clock tree, so they will not be populated in /debug/clock/ 2. Enable and disable of the module is one part, but what about, changing the rate of the clock (followparent_recalc)? With the proper and complete clock tree, you can traverse the clock and driver code doesn't need to know about parent. Driver can simply call clk_set_rate() on leaf clock, and clock tree will handle it. If at all we take this path, we have to build the clk node runtime (on-the-fly), AND/OR add new pm_runtime_set_rate() api. Not at all. You just have to get the fck of that hwmod and use the clock API. Are you available on IRC chat anytime? We can discuss on this and align quickly. I am available on linux-omap irc channel (with the name = hvaibhav) That will not change anything, the point is that MODULEMODE_SWCTRL is uses for module control, not for clock directly, and that's why it is handled by the hwmod. That will just replace the main_clk from the hwmod with the parent of the current modulemode nodes. Only the enable/disable part will be handled, if that node used to have a div, then the parent will handle that. Today this module mode clock node is just a duplication of the hwmod node. By removing it, you will reduce the size of the data and have a much mode accurate representation of the reality. Using the clock tree to handle these nodes was a hack we had to do because the hwmod fmwk was not ready when OMAP4 was introduced and because most drivers were not using pm_runtime. Benoit, I completely understand what are trying to explain here, and I completely agree with you on the fact that, MODULEMODE_SWCTRL is for module control and is clock node is just a duplication. Module enable and disable is one part, and I am not at all referring to this. My point is, more from other piece of code which are dependent on clocktree. In order to have proper and complete debugfs representation of all the clocks, somebody has to maintain the information of leaf clocks to parent relation, Isn't it? For example, take OMAP44xx dss_dss_clk clock, OR any clock with followparent_recalc field, the question I am raising here is, How would I know the rate of this clock in driver? Say for example, I want to configure my internal divider based on input rate? OR I want to change the rate of dss_clk itself? OR Looking at debugfs, would I get the rate of dss_clk? OR Will I have dss_clk present in /debug/clock/? OR Are we expecting user to know parent of such leaf clocks? OR Are we planning to export hwmod-main_clk (which is parent clk here) to User in debugfs or something? Thanks, Vaibhav 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 -- 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] twl4030-usb: Don't report EVENT_ID when there is VBUS.
On Wed, 25 Apr 2012 11:05:27 +0300 Felipe Balbi ba...@ti.com wrote: Hi, On Wed, Apr 25, 2012 at 05:33:11PM +1000, NeilBrown wrote: Some USB chargers tie the ID pin low via various resistors. So they can cause VBUS to be high and ID to be low. The 'A' end of an OTG cable never receives VBUS, it only ever generates it. this isn't entirely true. Have you considered Accessory Charger Adapters ? I confess that I probably did get lost amid the maze of twisty standards - all different. Looking at http://en.wikipedia.org/wiki/USB_On-The-Go it seems that a USB Accessory Charger Adapter can present 3 states including: A charger and a B-device are attached. The OTG device is allowed to charge and enter host mode. which would mean that the TWL4030 would see that A end of an OTG cable, and VBUS asserted. However that appears to be selected if the ID resistance is 36.5Kohms, while others are selected for 68Kohm and 124Kohm. But the twl4030 cannot detect that distinction. The cut-offs are Ground, 102K, 200K, 440K, Floating so it seems this is a standard that post-dates TWL4030. It also seems to be specific to OTG Micro plugs, and I have an OTG Mini plug (does TWL4030 support Micro plugs? Does it care?) So if we see VBUS and are not generating it, this must be a charger, not the A end of an OTG cable, so in that case, ignore the fact that ID is low. wrong. That may well be. However we need some way to tell twl4030_charger.c either USB_EVENT_VBUS or USB_EVENT_CHARGER when a charger is plugged in. I guess we could just punt to user-space: provide all the measurements through sysfs and allow user-space to enable the charger and select the desired current? Or should this just go in the too-hard basket for now? Thanks, NeilBrown signature.asc Description: PGP signature
Re: [PATCH 0/6] twl4030: Various fixes for charing-from-USB
On Wed, Apr 25, 2012 at 10:33 AM, NeilBrown ne...@suse.de wrote: Following are a collection of patches that I've need using for a while to make sure the charge-from-usb on my GTA04 works. Hopefully I've included the right people in the recipient list :-) You missed the power supply maintainers - ./scripts/get_maintainer.pl is usually good at finding the right people, although their MAINTAINERS entry could be better I guess.. -- Gražvydas -- 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] twl4030_charger: allow charging whenever VBUS is present.
On Wed, Apr 25, 2012 at 10:33 AM, NeilBrown ne...@suse.de wrote: We currently refuse to charge if the USB ID pin is grounded, even though VBUS might be present. However some chargers do pull the ID pin low through a resistor which might be as low as 47Kohm (openmoko charger). The documentation is unclear but some experimental evidence suggests that when the charge pump provides VBUS that doesn't get reflected in HW_CONDITIONS, so we should be safe to ignore the ID pin. On pandora I see the opposite, STS_VBUS is set regardless of who drives it, so this will break pandora.. Signed-off-by: NeilBrown ne...@suse.de --- drivers/power/twl4030_charger.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c index 0511610..684662a 100644 --- a/drivers/power/twl4030_charger.c +++ b/drivers/power/twl4030_charger.c @@ -155,11 +155,7 @@ static int twl4030_bci_have_vbus(struct twl4030_bci *bci) dev_dbg(bci-dev, check_vbus: HW_CONDITIONS %02x\n, hwsts); - /* in case we also have STS_USB_ID, VBUS is driven by TWL itself */ - if ((hwsts TWL4030_STS_VBUS) !(hwsts TWL4030_STS_USB_ID)) - return 1; - - return 0; + return (hwsts TWL4030_STS_VBUS); } /* -- Gražvydas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V3 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data
On 4/25/2012 12:20 PM, Hiremath, Vaibhav wrote: On Wed, Apr 25, 2012 at 14:10:49, Cousson, Benoit wrote: ... That will not change anything, the point is that MODULEMODE_SWCTRL is uses for module control, not for clock directly, and that's why it is handled by the hwmod. That will just replace the main_clk from the hwmod with the parent of the current modulemode nodes. Only the enable/disable part will be handled, if that node used to have a div, then the parent will handle that. Today this module mode clock node is just a duplication of the hwmod node. By removing it, you will reduce the size of the data and have a much mode accurate representation of the reality. Using the clock tree to handle these nodes was a hack we had to do because the hwmod fmwk was not ready when OMAP4 was introduced and because most drivers were not using pm_runtime. Benoit, I completely understand what are trying to explain here, and I completely agree with you on the fact that, MODULEMODE_SWCTRL is for module control and is clock node is just a duplication. Module enable and disable is one part, and I am not at all referring to this. My point is, more from other piece of code which are dependent on clocktree. In order to have proper and complete debugfs representation of all the clocks, somebody has to maintain the information of leaf clocks to parent relation, Isn't it? Nope, not at all. All the clocks will stay in the clock tree. The clock consumers a.k.a hwmods does not have to be in the clock tree. Having some fake leaf nodes in the clock tree is just adding some fake intermediate clocks instead of the real consumer. These nodes do not exist, they were added to have a point of control from the driver before runtime_pm was there. For example, take OMAP44xx dss_dss_clk clock, OR any clock with followparent_recalc field, the question I am raising here is, Then it is not an issue. If this is a real clock, it will then stay in the clock data. How would I know the rate of this clock in driver? Say for example, I want to configure my internal divider based on input rate? OR I want to change the rate of dss_clk itself? OR Looking at debugfs, would I get the rate of dss_clk? No because that clock will not exist anymore, but you will have the real clock rate from the dss_dss_clk. OR Will I have dss_clk present in /debug/clock/? OR Are we expecting user to know parent of such leaf clocks? Yes, because it is not leaf nodes anymore, but modules. OR Are we planning to export hwmod-main_clk (which is parent clk here) to User in debugfs or something? Well, I used to have a patch do expose hwmod to debugfs, but this is not that useful. I think this is a non-issue, we are just removing clock nodes that are not real nodes, so it will not change anything practically speaking. 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 6/6] twl4030-usb: Don't report EVENT_ID when there is VBUS.
On Wed, Apr 25, 2012 at 10:33 AM, NeilBrown ne...@suse.de wrote:
Some USB chargers tie the ID pin low via various resistors.
So they can cause VBUS to be high and ID to be low.
The 'A' end of an OTG cable never receives VBUS, it only ever generates it.
So if we see VBUS and are not generating it, this must be a charger,
not the A end of an OTG cable, so in that case, ignore the fact that
ID is low.
This assumes that VBUS_PRES isn't asserted when the charge pump is
providing VBUS. The document isn't clear on this and some experiments
suggest that it isn't.
Like already mentioned, this is not what I see on pandora. I don't
know, maybe it's due to some errata or different versions of TWL chip
act different, or perhaps even board design issue, but that's how it
is here.
If you look at git history, this has been changed back and forth
several times, like in commit def6f8b9. Perhaps some platform_data
could be added to handle this, I don't know..
Signed-off-by: NeilBrown ne...@suse.de
---
drivers/usb/otg/twl4030-usb.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index bd8fe9b..990400f 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -268,15 +268,16 @@ static enum usb_phy_events twl4030_usb_linkstat(struct
twl4030_usb *twl)
STS_HW_CONDITIONS);
if (status 0)
dev_err(twl-dev, USB link status err %d\n, status);
- else if (status (BIT(7) | BIT(2))) {
- if (status (BIT(7)))
- twl-vbus_supplied = true;
-
- if (status BIT(2))
- linkstat = USB_EVENT_ID;
- else
- linkstat = USB_EVENT_VBUS;
- } else
+ else if (status (BIT(7))) {
+ /* We have VBUS so ignore ID_PRES - it is only meaningful
+ * as an indicator of an A plug when there is no
+ * VBUS.
+ */
+ twl-vbus_supplied = true;
+ linkstat = USB_EVENT_VBUS;
+ } else if (status BIT(2))
+ linkstat = USB_EVENT_ID;
+ else
linkstat = USB_EVENT_NONE;
dev_dbg(twl-dev, HW_CONDITIONS 0x%02x/%d; link %d\n,
--
Gražvydas
--
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 v3] arm: omap4: hsmmc: check for null pointer
platform_device pdev can be NULL if CONFIG_MMC_OMAP_HS is not set.
Add check for NULL pointer. while at it move the duplicated functions
to omap4-common.c
Fixes the following boot crash seen with omap4sdp and omap4panda
when MMC is disabled.
Unable to handle kernel NULL pointer dereference at virtual address 008c
pgd = c0004000
[008c] *pgd=
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0Not tainted (3.4.0-rc1-05971-ga4dfa82 #4)
PC is at omap_4430sdp_init+0x184/0x410
LR is at device_add+0x1a0/0x664
Signed-off-by: Balaji T K balaj...@ti.com
Reported-by: Santosh Shilimkar santosh.shilim...@ti.com
---
v3:
do nothing in omap4_twl6030_hsmmc_init when CONFIG_MMC_OMAP_HS is disabled
v2:
move omap4 mmc board init functions to omap4-common.c
arch/arm/mach-omap2/board-4430sdp.c | 44 ---
arch/arm/mach-omap2/board-omap4panda.c | 49 --
arch/arm/mach-omap2/board-omap4pcm049.c | 45
arch/arm/mach-omap2/common.h|3 ++
arch/arm/mach-omap2/omap4-common.c | 58 +++
5 files changed, 61 insertions(+), 138 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index a39fc4b..ec06103 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -488,50 +488,6 @@ static struct platform_device omap_vwlan_device = {
},
};
-static int omap4_twl6030_hsmmc_late_init(struct device *dev)
-{
- int irq = 0;
- struct platform_device *pdev = container_of(dev,
- struct platform_device, dev);
- struct omap_mmc_platform_data *pdata = dev-platform_data;
-
- /* Setting MMC1 Card detect Irq */
- if (pdev-id == 0) {
- irq = twl6030_mmc_card_detect_config();
- if (irq 0) {
- pr_err(Failed configuring MMC1 card detect\n);
- return irq;
- }
- pdata-slots[0].card_detect_irq = irq;
- pdata-slots[0].card_detect = twl6030_mmc_card_detect;
- }
- return 0;
-}
-
-static __init void omap4_twl6030_hsmmc_set_late_init(struct device *dev)
-{
- struct omap_mmc_platform_data *pdata;
-
- /* dev can be null if CONFIG_MMC_OMAP_HS is not set */
- if (!dev) {
- pr_err(Failed %s\n, __func__);
- return;
- }
- pdata = dev-platform_data;
- pdata-init = omap4_twl6030_hsmmc_late_init;
-}
-
-static int __init omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info
*controllers)
-{
- struct omap2_hsmmc_info *c;
-
- omap_hsmmc_init(controllers);
- for (c = controllers; c-mmc; c++)
- omap4_twl6030_hsmmc_set_late_init(c-pdev-dev);
-
- return 0;
-}
-
static struct regulator_init_data sdp4430_vaux1 = {
.constraints = {
.min_uV = 100,
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index f864065..0ecf074 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -235,55 +235,6 @@ static struct wl12xx_platform_data omap_panda_wlan_data
__initdata = {
.board_ref_clock = 2,
};
-static int omap4_twl6030_hsmmc_late_init(struct device *dev)
-{
- int irq = 0;
- struct platform_device *pdev = container_of(dev,
- struct platform_device, dev);
- struct omap_mmc_platform_data *pdata = dev-platform_data;
-
- if (!pdata) {
- dev_err(dev, %s: NULL platform data\n, __func__);
- return -EINVAL;
- }
- /* Setting MMC1 Card detect Irq */
- if (pdev-id == 0) {
- irq = twl6030_mmc_card_detect_config();
- if (irq 0) {
- dev_err(dev, %s: Error card detect config(%d)\n,
- __func__, irq);
- return irq;
- }
- pdata-slots[0].card_detect = twl6030_mmc_card_detect;
- }
- return 0;
-}
-
-static __init void omap4_twl6030_hsmmc_set_late_init(struct device *dev)
-{
- struct omap_mmc_platform_data *pdata;
-
- /* dev can be null if CONFIG_MMC_OMAP_HS is not set */
- if (!dev) {
- pr_err(Failed omap4_twl6030_hsmmc_set_late_init\n);
- return;
- }
- pdata = dev-platform_data;
-
- pdata-init = omap4_twl6030_hsmmc_late_init;
-}
-
-static int __init omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info
*controllers)
-{
- struct omap2_hsmmc_info *c;
-
- omap_hsmmc_init(controllers);
- for (c = controllers; c-mmc; c++)
- omap4_twl6030_hsmmc_set_late_init(c-pdev-dev);
-
- return 0;
-}
-
static struct twl4030_codec_data twl6040_codec = {
/* single-step ramp for headset and handsfree */
Re: [PATCH v2] arm: omap4: hsmmc: check for null pointer
On Mon, Apr 23, 2012 at 8:13 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Mon, Apr 23, 2012 at 08:11:07PM +0530, Balaji T K wrote:
+int __init omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers)
+{
+ struct omap2_hsmmc_info *c;
+
+ omap_hsmmc_init(controllers);
+ for (c = controllers; c-mmc; c++) {
+ /* pdev can be null if CONFIG_MMC_OMAP_HS is not set */
+ if (!c-pdev)
+ continue;
+ omap4_twl6030_hsmmc_set_late_init(c-pdev-dev);
+ }
+
+ return 0;
+}
why are you even calling this if CONFIG_MMC_OMAP_HS isn't set ? Just
stub it out if you don't have mmc support.
Ok, added in v3
--
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
MUSB problem
I'm running 3.3.0 on an OMAP DM3730, with SMSC75xx connected via the MUSB device. I get this error continually although the device (and network channel) seem happy: musb_ep_program 835: broken !rx_reinit, ep2 csr a200 What does it mean? How do I fix it (i.e. keep it from happening)? Note: disabling DMA isn't really an option as the whole point of the SMSC75xx is to get gigabit ethernet and I doubt that's possible without DMA :-) Thanks for any pointers/ideas -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V3 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data
On Wed, Apr 25, 2012 at 17:08:43, Cousson, Benoit wrote: On 4/25/2012 12:20 PM, Hiremath, Vaibhav wrote: On Wed, Apr 25, 2012 at 14:10:49, Cousson, Benoit wrote: ... snip How would I know the rate of this clock in driver? Say for example, I want to configure my internal divider based on input rate? OR I want to change the rate of dss_clk itself? OR Looking at debugfs, would I get the rate of dss_clk? No because that clock will not exist anymore, but you will have the real clock rate from the dss_dss_clk. Thanks Benoit, I think I understand your perspective on Module Vs leaf node and now able to digest as well. Probably Last Q, which I think clarify all my doubts, Assume we have complete hwmod instance and built a device using omap_device_build() api, and also the driver is completely using runtime pm api's, How can driver get the clk handle (required to get the rate)? Is there any api already available for this? Thanks, Vaibhav -- 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] OMAP4: panda: add statics to remove warnings
On Tue, 2012-04-24 at 10:16 -0700, Tony Lindgren wrote:
* Tomi Valkeinen tomi.valkei...@ti.com [120423 00:43]:
Add statics to board-omap4-panda.c's internal functions and data
structures to remove warnings.
Care to update with the warnings produced?
Ah, sure. Updated patch below:
From e96ddeb7d783d48a15a32f8ef5a7bae3089f66b9 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen tomi.valkei...@ti.com
Date: Wed, 28 Mar 2012 11:38:58 +0300
Subject: [PATCH] OMAP4: panda: add statics to remove warnings
Add statics to board-omap4-panda.c's internal functions and data
structures to remove sparse warnings:
arch/arm/mach-omap2/board-omap4panda.c:234:29: warning: symbol
'omap_panda_wlan_data' was not declared. Should it be static?
arch/arm/mach-omap2/board-omap4panda.c:441:24: warning: symbol
'omap4_panda_dvi_device' was not declared. Should it be static?
arch/arm/mach-omap2/board-omap4panda.c:451:12: warning: symbol
'omap4_panda_dvi_init' was not declared. Should it be static?
arch/arm/mach-omap2/board-omap4panda.c:512:13: warning: symbol
'omap4_panda_display_init' was not declared. Should it be static?
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-omap4panda.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 1b782ba..8216e5f 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -231,7 +231,7 @@ static struct platform_device omap_vwlan_device = {
},
};
-struct wl12xx_platform_data omap_panda_wlan_data __initdata = {
+static struct wl12xx_platform_data omap_panda_wlan_data __initdata = {
/* PANDA ref clock is 38.4 MHz */
.board_ref_clock = 2,
};
@@ -438,7 +438,7 @@ static struct panel_dvi_platform_data omap4_dvi_panel = {
.i2c_bus_num = 3,
};
-struct omap_dss_device omap4_panda_dvi_device = {
+static struct omap_dss_device omap4_panda_dvi_device = {
.type = OMAP_DISPLAY_TYPE_DPI,
.name = dvi,
.driver_name= dvi,
@@ -448,7 +448,7 @@ struct omap_dss_device omap4_panda_dvi_device = {
.channel= OMAP_DSS_CHANNEL_LCD2,
};
-int __init omap4_panda_dvi_init(void)
+static int __init omap4_panda_dvi_init(void)
{
int r;
@@ -509,7 +509,7 @@ static struct omap_dss_board_info omap4_panda_dss_data = {
.default_device = omap4_panda_dvi_device,
};
-void __init omap4_panda_display_init(void)
+static void __init omap4_panda_display_init(void)
{
int r;
--
1.7.4.1
signature.asc
Description: This is a digitally signed message part
Re: MUSB problem
On 2012-04-25 06:19, Gary Thomas wrote: I'm running 3.3.0 on an OMAP DM3730, with SMSC75xx connected via the MUSB device. I get this error continually although the device (and network channel) seem happy: musb_ep_program 835: broken !rx_reinit, ep2 csr a200 What does it mean? How do I fix it (i.e. keep it from happening)? Note: disabling DMA isn't really an option as the whole point of the SMSC75xx is to get gigabit ethernet and I doubt that's possible without DMA :-) Thanks for any pointers/ideas Actually, I was too hasty saying that this worked even with this error. I can ping out from my board, but any higher level of traffic, e.g. SSH into the box, falls over :-( The problems vanish when I disable MUSB DMA. What gives? -- Gary Thomas | Consulting for the MLB Associates |Embedded world -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V3 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data
On 4/25/2012 2:26 PM, Hiremath, Vaibhav wrote: On Wed, Apr 25, 2012 at 17:08:43, Cousson, Benoit wrote: On 4/25/2012 12:20 PM, Hiremath, Vaibhav wrote: On Wed, Apr 25, 2012 at 14:10:49, Cousson, Benoit wrote: ... snip How would I know the rate of this clock in driver? Say for example, I want to configure my internal divider based on input rate? OR I want to change the rate of dss_clk itself? OR Looking at debugfs, would I get the rate of dss_clk? No because that clock will not exist anymore, but you will have the real clock rate from the dss_dss_clk. Thanks Benoit, I think I understand your perspective on Module Vs leaf node and now able to digest as well. Probably Last Q, which I think clarify all my doubts, Assume we have complete hwmod instance and built a device using omap_device_build() api, and also the driver is completely using runtime pm api's, How can driver get the clk handle (required to get the rate)? Is there any api already available for this? The omap_device fmwk will auto-magically create a fck clkdev entry for the main_clk. The API is thus the standard: clk_get(dev, fck), to get the clock handle and then you can use the other clock API. The idea is to enforce the usage of clock alias local to the device and not trying anymore to get the real clock name. It thus allows driver to work on various variant / revision without having to modify the driver. The fmwk will also create clock alias for any opt_clock present in the hwmod. 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 v2] OMAPDSS: VENC: allow switching venc output type at runtime
On Tue, 2012-04-24 at 00:08 +0300, Grazvydas Ignotas wrote: VENC output type (composite/svideo) doesn't have to be fixed by board wiring, it is possible to also provide composite signal through svideo luminance connector (software enabled), which is what pandora does. Having to recompile the kernel for users who have TV connector types that don't match default board setting is very inconvenient, especially for users of a consumer device, so add support for switching VENC output type at runtime over a new sysfs file output_type. Signed-off-by: Grazvydas Ignotas nota...@gmail.com --- Documentation/arm/OMAP/DSS |1 + drivers/video/omap2/dss/venc.c | 54 +++- 2 files changed, 54 insertions(+), 1 deletions(-) Looks fine to me. Thanks! Applying. Tomi signature.asc Description: This is a digitally signed message part
RE: [PATCH-V3 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data
On Wed, Apr 25, 2012 at 18:03:21, Cousson, Benoit wrote: On 4/25/2012 2:26 PM, Hiremath, Vaibhav wrote: On Wed, Apr 25, 2012 at 17:08:43, Cousson, Benoit wrote: On 4/25/2012 12:20 PM, Hiremath, Vaibhav wrote: On Wed, Apr 25, 2012 at 14:10:49, Cousson, Benoit wrote: ... snip How would I know the rate of this clock in driver? Say for example, I want to configure my internal divider based on input rate? OR I want to change the rate of dss_clk itself? OR Looking at debugfs, would I get the rate of dss_clk? No because that clock will not exist anymore, but you will have the real clock rate from the dss_dss_clk. Thanks Benoit, I think I understand your perspective on Module Vs leaf node and now able to digest as well. Probably Last Q, which I think clarify all my doubts, Assume we have complete hwmod instance and built a device using omap_device_build() api, and also the driver is completely using runtime pm api's, How can driver get the clk handle (required to get the rate)? Is there any api already available for this? The omap_device fmwk will auto-magically create a fck clkdev entry for the main_clk. The API is thus the standard: clk_get(dev, fck), to get the clock handle and then you can use the other clock API. The idea is to enforce the usage of clock alias local to the device and not trying anymore to get the real clock name. It thus allows driver to work on various variant / revision without having to modify the driver. The fmwk will also create clock alias for any opt_clock present in the hwmod. Yes, Yes, I missed this. Omap_device_build() internally add fck to the clkdev table for both main_clk and opt_clks. Thanks for describing it for me. I will change AM33XX clock tree for this And submit the next version soon. Thanks, Vaibhav -- 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 v9 11/25] gpio/omap: cleanup omap_gpio_mod_init function
On Wed, Apr 25, 2012 at 12:09 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Wed, Apr 25, 2012 at 10:04 AM, DebBarma, Tarun Kanti tarun.ka...@ti.com wrote: On Tue, Apr 24, 2012 at 9:34 PM, Tony Lindgren t...@atomide.com wrote: * DebBarma, Tarun Kanti tarun.ka...@ti.com [120424 08:40]: Hi Janusz, On Tue, Apr 24, 2012 at 12:24 AM, DebBarma, Tarun Kanti tarun.ka...@ti.com wrote: On Sat, Apr 21, 2012 at 7:33 PM, Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote: On Thursday 02 of February 2012 23:00:37 Tarun Kanti DebBarma wrote: With register offsets now defined for respective OMAP versions we can get rid of cpu_class_* checks. This function now has common initialization code for all OMAP versions... Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com Signed-off-by: Charulatha V ch...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Tony Lindgren t...@atomide.com Sorry for being so late with my comment for chanes already present in mainline, but this patch breaks GPIO on Amstrad Delta at least, and I have neither enough spare time nor enough experience with non OMAP1 machines to provide a solution myself. Yes, I looked at the omap_gpio_mod_init() and OMAP1 configurations are overwritten. Also looks like there is issue in making distinction between omap15xx and omap16xx. I will post a patch and you can help me testing it in OMAP1 platform. Thanks for pointing this out. ... Here is the patch, with attachment as well. I have just tested on OMAP4 platform. Testing on other OMAP2+ platforms is pending. In the meantime can you please validate on OMAP1 platform and confirm? Thanks. -- Tarun From: Tarun Kanti DebBarma tarun.ka...@ti.com Date: Tue, 24 Apr 2012 20:34:32 +0530 Subject: [PATCH] gpio/omap: fix omap1 register overwrite in omap_gpio_mod_init Initialization of irqenable, irqstatus registers is the common operation done in this function for all OMAP platforms, viz. OMAP1, OMAP2+. The latter _gpio_rmw()'s to irqenable register was overwriting the correctly programmed OMAP1 value at the beginning. As a result, even though it worked on OMAP2+ platforms it was breaking OMAP1 functionality. Sounds like the original patch was never tested on omap1? That's right, only bootup test was done on OMAP1710-SDP. On closer observation it is found that the first _gpio_rmw() which is supposedly done to take care of OMAP1 platform is generic enough and takes care of OMAP2+ platform as well. Therefore remove the latter _gpio_rmw() to irqenable as they are redundant. Also, changing the sequence and logic of initializing the irqstatus. Please mention also the breaking commit here and get this fix merged as a regression as soon as it's tested for the current -rc series. Sure, I will do that! Looks like it is regression on 3.4 as well so CC stable when you post the patch. Ok, I will do that. -- Tarun 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 2/3] IRQ: allow check_wakeup_irqs to notice level-triggered interrupts.
On Wed, 25 Apr 2012, NeilBrown wrote:
On Wed, 25 Apr 2012 10:50:15 +0200 (CEST) Thomas Gleixner
t...@linutronix.de wrote:
On Wed, 25 Apr 2012, NeilBrown wrote:
Level triggered interrupts do not cause IRQS_PENDING to be set, so
check_wakeup_irqs ignores them.
They don't need to set IRQS_PENDING as the level stays high which
shows that they must be pending. However if such an interrupt fired
during late suspend, it will have been masked so the fact that it
is still asserted will not cause the suspend to abort.
So if any wakeup interrupt is masked, unmask it when checking wakeup
irqs. If the interrupt is asserted, suspend will abort.
Signed-off-by: NeilBrown ne...@suse.de
---
kernel/irq/pm.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/irq/pm.c b/kernel/irq/pm.c
index 15e53b1..0d26206 100644
--- a/kernel/irq/pm.c
+++ b/kernel/irq/pm.c
@@ -106,6 +106,12 @@ int check_wakeup_irqs(void)
if (irqd_is_wakeup_set(desc-irq_data)) {
if (desc-istate IRQS_PENDING)
return -EBUSY;
+ if (irqd_irq_masked(desc-irq_data))
+ /* Probably a level interrupt
+ * which fired recently and was
+ * masked
+ */
+ unmask_irq(desc);
Oh no. We don't unmask unconditionally. What about an interrupt which
is disabled, has no handler . ? That needs more thought.
If there is no handler, then irqd_is_wakeup_set() should fail should it not?
Well, it does not. The wakeup state is a permanent flag on the irq
line. Though we don't have IRQS_SUSPENDED on that descriptor.
For disabled: would it be OK to check desc-depth?
Something like:
if (desc-depth == 1 (desc-state IRQS_SUSPENDED)
irqd_irq_masked(desc-irq_data))
unmask_irq(desc);
Why not simply managing the pending bit for level irqs ?
Index: tip/kernel/irq/chip.c
===
--- tip.orig/kernel/irq/chip.c
+++ tip/kernel/irq/chip.c
@@ -379,8 +379,10 @@ handle_level_irq(unsigned int irq, struc
* If its disabled or no action available
* keep it masked and get out of here
*/
- if (unlikely(!desc-action || irqd_irq_disabled(desc-irq_data)))
+ if (unlikely(!desc-action || irqd_irq_disabled(desc-irq_data))) {
+ desc-istate |= IRQS_PENDING;
goto out_unlock;
+ }
handle_irq_event(desc);
Index: tip/kernel/irq/resend.c
===
--- tip.orig/kernel/irq/resend.c
+++ tip/kernel/irq/resend.c
@@ -58,10 +58,13 @@ void check_irq_resend(struct irq_desc *d
/*
* We do not resend level type interrupts. Level type
* interrupts are resent by hardware when they are still
-* active.
+* active. Clear the pending bit so suspend/resume does not
+* get confused.
*/
- if (irq_settings_is_level(desc))
+ if (irq_settings_is_level(desc)) {
+ desc-istate = ~IRQS_PENDING;
return;
+ }
if (desc-istate IRQS_REPLAY)
return;
if (desc-istate IRQS_PENDING) {
And to handle interrupts which have been disabled before suspend add:
Index: tip/kernel/irq/pm.c
===
--- tip.orig/kernel/irq/pm.c
+++ tip/kernel/irq/pm.c
@@ -103,7 +103,8 @@ int check_wakeup_irqs(void)
int irq;
for_each_irq_desc(irq, desc) {
- if (irqd_is_wakeup_set(desc-irq_data)) {
+ if (desc-depth == 1
+ irqd_is_wakeup_set(desc-irq_data)) {
if (desc-istate IRQS_PENDING)
return -EBUSY;
continue;
--
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/RFT 0/3] ARM: OMAP: PM: reduce overhead of pwrdm pre/post transitions
On Tue, Apr 24, 2012 at 7:53 PM, Kevin Hilman khil...@ti.com wrote:
Here's a first pass attempt to reduce the overhead of the pre/post
transitions by allowing them to be called per powerdomain and making
them conditional on powerdomain transtions.
This can be used for testing/measurements to see the reduction the
latencies involved in entering/exiting idle with and without these
patches.
Kevin Hilman (3):
ARM: OMAP2+: powerdomain: allow pre/post transtion to be per pwrdm
ARM: OMAP3: PM: call pre/post transition per powerdomain
ARM: OMAP3: PM: cleanup cam_pwrdm leftovers
I have reviewed and tested this series on OMAP4 with coupleidle and system
wide supsned. It continues to work as expected. I have done an additional
patch(end of email) as mentioned to take advantage of per powerdomain
pre/post transition API update.
Thanks for the series. it certainly removes the big over-head we had before
with the pre-post APIs.
FWIW,
Reviewed-tested-by: Santosh Shilimkar santosh.shilim...@ti.com
Regards
Santosh
From e535b0d8948ed44732c6128ff4236cfe32d2f40a Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Wed, 25 Apr 2012 17:04:08 +0530
Subject: [PATCH] ARM: OMAP4: PM: call pre/post transition per powerdomain
Iteration over all power domains in the idle path is unnecessary since
only power domains that are transitioning need to be accounted for.
Update OMAP4 low power code accordingly.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
There is one issue though about MPUSS powerdomain accounting. It will
get called on both CPUs and might result in duplicate pm debug counter
update. There is no functional issue with that as such but needs to
be cleaned up.
Will address that issue in a seperate series.
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 22 --
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index e35a86b..3a709b2 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -117,6 +117,20 @@ static inline void clear_cpu_prev_pwrst(unsigned
int cpu_id)
}
/*
+ * CPU powerdomain pre/post transition.
+ */
+static inline void cpu_pwrdm_pre_post_transition(unsigned int cpu_id,
+ bool pre_transition)
+{
+ struct omap4_cpu_pm_info *pm_info = per_cpu(omap4_pm_info, cpu_id);
+
+ if (pre_transition)
+ pwrdm_pre_transition(pm_info-pwrdm);
+ else
+ pwrdm_post_transition(pm_info-pwrdm);
+}
+
+/*
* Store the SCU power status value to scratchpad memory
*/
static void scu_pwrst_prepare(unsigned int cpu_id, unsigned int cpu_state)
@@ -255,7 +269,7 @@ int omap4_enter_lowpower(unsigned int cpu,
unsigned int power_state)
return -ENXIO;
}
- pwrdm_pre_transition(NULL);
+ pwrdm_pre_transition(mpuss_pd);
/*
* Check MPUSS next state and save interrupt controller if needed.
@@ -266,6 +280,7 @@ int omap4_enter_lowpower(unsigned int cpu,
unsigned int power_state)
(pwrdm_read_logic_retst(mpuss_pd) == PWRDM_POWER_OFF))
save_state = 2;
+ cpu_pwrdm_pre_post_transition(cpu, 1);
cpu_clear_prev_logic_pwrst(cpu);
set_cpu_next_pwrst(cpu, power_state);
set_cpu_wakeup_addr(cpu, virt_to_phys(omap4_cpu_resume));
@@ -285,9 +300,10 @@ int omap4_enter_lowpower(unsigned int cpu,
unsigned int power_state)
* domain transition
*/
wakeup_cpu = smp_processor_id();
+ cpu_pwrdm_pre_post_transition(wakeup_cpu, 0);
set_cpu_next_pwrst(wakeup_cpu, PWRDM_POWER_ON);
- pwrdm_post_transition(NULL);
+ pwrdm_post_transition(mpuss_pd);
return 0;
}
@@ -307,6 +323,7 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu,
unsigned int power_state)
if (power_state == PWRDM_POWER_OFF)
cpu_state = 1;
+ cpu_pwrdm_pre_post_transition(cpu, 1);
clear_cpu_prev_pwrst(cpu);
set_cpu_next_pwrst(cpu, power_state);
set_cpu_wakeup_addr(cpu, virt_to_phys(omap_secondary_startup));
@@ -319,6 +336,7 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu,
unsigned int power_state)
*/
omap4_finish_suspend(cpu_state);
+ cpu_pwrdm_pre_post_transition(wakeup_cpu, 0);
set_cpu_next_pwrst(cpu, PWRDM_POWER_ON);
return 0;
}
--
1.7.5.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: DM3730 BSP issue with msleep()
On Mon, Apr 23, 2012 at 1:13 PM, Ashwin Bihari abih...@gmail.com wrote:
Greetings,
I'm trying to add support for our DM3730-based SOMs to the latest
Kernel and am basing my work on the latest and greatest Linux-next
(3.4.0-rc4-next-20120423-dirty currently) and am finding an
interesting issue with the use of msleep.
I'm trying to bring up a basic system with SD and Ethernet support for
starters, and am finding that the MMC detection code just hangs, after
some digging around I found the issue to be related to the use of
mmc_delay() calls which depending on the timeout required either uses
mdelay() or msleep(). All of the calls to mdelay() succeed, while the
msleep() call hangs.
Interestingly, msleep() is used in earlier
(arch/arm/mach-omap2)/board-* level files and that seems to function
properly.
I got around the mmc_delay() properly by using the change below (this
is only temporary), but I end up hanging somewhere farther along and
the last few lines are:
[ 2.047088] twl_rtc twl_rtc: Power up reset detected.
[ 2.052673] twl_rtc twl_rtc: Enabling TWL-RTC
[ 2.064331] twl_rtc twl_rtc: rtc core: registered twl_rtc as rtc0
[ 2.073028] i2c /dev entries driver
[ 2.080505] Driver for 1-wire Dallas network protocol.
[ 2.091522] omap_wdt: OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec
[ 2.101043] twl4030_wdt twl4030_wdt: Failed to register misc device
[ 2.107940] twl4030_wdt: probe of twl4030_wdt failed with error -16
[ 2.12] omap_hsmmc omap_hsmmc.0: Failed to get debounce clk
[ 2.382659] usbcore: registered new interface driver usbhid
[ 2.388549] usbhid: USB HID core driver
[ 2.392822] oprofile: hardware counters not available
[ 2.398284] oprofile: using timer interrupt.
[ 2.403961] TCP: cubic registered
[ 2.407623] Initializing XFRM netlink socket
[ 2.412506] NET: Registered protocol family 17
[ 2.417388] NET: Registered protocol family 15
[ 2.422821] Registering the dns_resolver key type
[ 2.428222] VFP support v0.3: implementor 41 architecture 3 part 30
variant c rev 3
[ 2.436676] ThumbEE CPU extension supported.
[ 2.493072] clock: disabling unused clocks to save power
[ 2.545989] twl_rtc twl_rtc: setting system clock to 2000-01-01
00:00:00 UTC (946684800)
[ 2.560760] Waiting for root device /dev/mmcblk0p2...
[ 2.783111] mmc0: host does not support reading read-only switch.
assuming write-enable.
[ 2.794372] mmc0: new high speed SDHC card at address b368
[ 2.814636] mmcblk0: mmc0:b368 0 3.74 GiB
[ 2.828704] mmcblk0: p1 p2
Does anyone have any pointers for me to try out to see what's going on?
diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
index 3bdafbc..7062f15 100644
--- a/drivers/mmc/core/core.h
+++ b/drivers/mmc/core/core.h
@@ -48,12 +48,16 @@ void mmc_power_off(struct mmc_host *host);
static inline void mmc_delay(unsigned int ms)
{
+ cond_resched();
+ mdelay(ms);
+#if 0
if (ms 1000 / HZ) {
cond_resched();
mdelay(ms);
} else {
msleep(ms);
}
+#endif
}
void mmc_rescan(struct work_struct *work);
-- Ashwin
I've continued to debug this a bit further and have been updating to
the latest versions of linux-next to see if any of the behavior change
and it hasn't yet. However, I did try to see if I could use an EXT2
ramdisk (that I know works on other Kernels I have) to avoid any
potential issues I am having with the SD and it turns out that the
ramdisk also doesn't mount. The mounting of the ramdisk root also
hangs in some of the very code fs/namespace.c code that I haven't
even touched.
I have a OMAP3530 SOM that works with the same image and it boots from
ramdisk, SD and all without any problems.
I must be missing or have no configured something at a very early
level to get this messed up..any ideas?
-- Ashwin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain PRM support for AM33XX device
On Fri, Mar 30, 2012 at 21:33:51, Hiremath, Vaibhav wrote: After some healthy discussion, now we have come to the conclusion and decided to handle AM33XX PRM/CM part separately; as AM33XX-PRCM module is different than OMAP3 and OMAP4 architecture. The difference becomes very interesting/weird when it comes to the consistency for register offsets in PRM address space and bit-field offsets inside PRM registers, So along with Powerdomain data and PRM api's required for AM33XX device, this patch series adds, - XXX_RSTST register offset to struct omap_hwmod_omap4_prcm - PWRSTCTRL PWRSTST register offsets to struct powerdomain - Logicretstate and mem_on/ret/pwrst/retst mask to struct powerdomain Testing: This patch series has been boot tested on AM37xEVM and AM335x based BeagleBone community board. Thanks to Paul here...for helping and concluding on this, shortly I will submit similar patch for CM, clockdomain and clock-tree support for AM33xx. This patch-series is created on top of linux-omap/cleanup branch, and also gets applied to linux-omap/master branch. The patches are also available at - https://github.com/hvaibhav/am335x-linux/tree/am335x-prm-cm Changes from previous versions: === From V3: - No code change, only added Voltagedomain patch (from V2 series) to this series. From V1 V2: - Rolled back to my original approach, where AM33xx device was handled separately (RFC version). - As per Paul's comments, added Register offsets bit-fields masks. Vaibhav Hiremath (4): ARM: OMAP3+: am33xx: Add voltage domain data ARM: OMAP3/4: omap_hwmod: Add rstst_off field to struct omap_hwmod_omap4_prcm ARM: OMAP2+: powerdomain: Add offset mask fields to struct powerdomain ARM: OMAP3+: am33xx: Add powerdomain PRM support arch/arm/mach-omap2/Makefile |6 + arch/arm/mach-omap2/io.c |2 + arch/arm/mach-omap2/omap_hwmod.c | 32 ++- arch/arm/mach-omap2/powerdomain.h | 23 ++- arch/arm/mach-omap2/powerdomain33xx.c | 230 arch/arm/mach-omap2/powerdomains33xx_data.c | 185 + arch/arm/mach-omap2/prm-regbits-33xx.h| 357 + arch/arm/mach-omap2/prm33xx.c | 134 + arch/arm/mach-omap2/prm33xx.h | 129 + arch/arm/mach-omap2/voltage.h |1 + arch/arm/mach-omap2/voltagedomains33xx_data.c | 43 +++ arch/arm/plat-omap/include/plat/omap_hwmod.h |2 + 12 files changed, 1139 insertions(+), 5 deletions(-) create mode 100644 arch/arm/mach-omap2/powerdomain33xx.c create mode 100644 arch/arm/mach-omap2/powerdomains33xx_data.c create mode 100644 arch/arm/mach-omap2/prm-regbits-33xx.h create mode 100644 arch/arm/mach-omap2/prm33xx.c create mode 100644 arch/arm/mach-omap2/prm33xx.h create mode 100644 arch/arm/mach-omap2/voltagedomains33xx_data.c Tony, Paul and Kevin, Any comments on this patch series? Thanks, Vaibhav -- 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 v9 11/25] gpio/omap: cleanup omap_gpio_mod_init function
On Wed, Apr 25, 2012 at 06:24:14PM +0530, DebBarma, Tarun Kanti wrote: On Wed, Apr 25, 2012 at 12:09 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Wed, Apr 25, 2012 at 10:04 AM, DebBarma, Tarun Kanti tarun.ka...@ti.com wrote: On Tue, Apr 24, 2012 at 9:34 PM, Tony Lindgren t...@atomide.com wrote: * DebBarma, Tarun Kanti tarun.ka...@ti.com [120424 08:40]: Hi Janusz, On Tue, Apr 24, 2012 at 12:24 AM, DebBarma, Tarun Kanti tarun.ka...@ti.com wrote: On Sat, Apr 21, 2012 at 7:33 PM, Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote: On Thursday 02 of February 2012 23:00:37 Tarun Kanti DebBarma wrote: With register offsets now defined for respective OMAP versions we can get rid of cpu_class_* checks. This function now has common initialization code for all OMAP versions... Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com Signed-off-by: Charulatha V ch...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Tony Lindgren t...@atomide.com Sorry for being so late with my comment for chanes already present in mainline, but this patch breaks GPIO on Amstrad Delta at least, and I have neither enough spare time nor enough experience with non OMAP1 machines to provide a solution myself. Yes, I looked at the omap_gpio_mod_init() and OMAP1 configurations are overwritten. Also looks like there is issue in making distinction between omap15xx and omap16xx. I will post a patch and you can help me testing it in OMAP1 platform. Thanks for pointing this out. ... Here is the patch, with attachment as well. I have just tested on OMAP4 platform. Testing on other OMAP2+ platforms is pending. In the meantime can you please validate on OMAP1 platform and confirm? Thanks. -- Tarun From: Tarun Kanti DebBarma tarun.ka...@ti.com Date: Tue, 24 Apr 2012 20:34:32 +0530 Subject: [PATCH] gpio/omap: fix omap1 register overwrite in omap_gpio_mod_init Initialization of irqenable, irqstatus registers is the common operation done in this function for all OMAP platforms, viz. OMAP1, OMAP2+. The latter _gpio_rmw()'s to irqenable register was overwriting the correctly programmed OMAP1 value at the beginning. As a result, even though it worked on OMAP2+ platforms it was breaking OMAP1 functionality. Sounds like the original patch was never tested on omap1? That's right, only bootup test was done on OMAP1710-SDP. On closer observation it is found that the first _gpio_rmw() which is supposedly done to take care of OMAP1 platform is generic enough and takes care of OMAP2+ platform as well. Therefore remove the latter _gpio_rmw() to irqenable as they are redundant. Also, changing the sequence and logic of initializing the irqstatus. Please mention also the breaking commit here and get this fix merged as a regression as soon as it's tested for the current -rc series. Sure, I will do that! Looks like it is regression on 3.4 as well so CC stable when you post the patch. Ok, I will do that. Correction. Don't email your patch in any way to the stable folk _before_ it has been taken into Linus' tree. However, you _may_ add in the patch attributations a Cc: sta...@vger.kernel.org tag if you want the stable folk to automatically pick up your patch when it _does_ end up in Linus' tree. But... make sure that git send-email or whatever doesn't automatically add that to the recipients for the emailed patch. If you send the stable people a patch before its in mainline, you'll get a whinge telling you to read Documentation/stable_kernel_rules.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-V3 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data
Hi Vaibhav, On Wed, 25 Apr 2012, Hiremath, Vaibhav wrote: Thanks for describing it for me. I will change AM33XX clock tree for this And submit the next version soon. Well I can just remove those leaf clock entries from my copy here, if you're okay with that ? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V3 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data
On Wed, Apr 25, 2012 at 19:25:29, Paul Walmsley wrote: Hi Vaibhav, On Wed, 25 Apr 2012, Hiremath, Vaibhav wrote: Thanks for describing it for me. I will change AM33XX clock tree for this And submit the next version soon. Well I can just remove those leaf clock entries from my copy here, if you're okay with that ? Great... More that OK :) Thanks, Vaibhav -- 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-V5 0/3] ARM: OMAP: Make OMAP clocksource source selection runtime
Current OMAP code supports couple of clocksource options based on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz) This patch series cleans up the existing 32k-sync timer implementation without any major code changes, uses kernel parameter to override the default clocksource of counter_32k, also in order to support some OMAP based derivative SoCs like AM33XX which doesn't have 32K sync-timer hardware IP, adds hwmod lookup for omap2+ devices, and if lookup fails then fall back to gp-timer. if(use_gptimer_clksrc == true) gptimer clocksource init; else if (counter_32 init == false) /* Fallback to gptimer */ gptimer clocksource init(; With this, we should be able to support multi-omap boot including devices with/without 32k-sync timer. This patch-series has been boot tested on AM37xEVM platform, it would be helpful if somebody help me to validate it on OMAP1/2 platforms. The patches are also available at (based on linux-omap/master) - https://github.com/hvaibhav/am335x-linux 32ksync-timer-cleanup History: Changes from V4 (No Code Change at all): http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67019.html - Updated commit description as per Tony's comment Changes from V3: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg66462.html - Fixed all review comments from Kevin H * Moved counter_32k CR register offset handling to counter_32k.c file, so now, calling funtion don't have to maintain or add offset to base addr. * Added comment for function omap_init_clocksource_32k() * Used resource_size() for calculate size * Convert WARN_ON to pr_warn Changes from V2: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/092037.html - Added early_param support to read clocksource selection from user through kernel parameter (clocksource=) - Converted to ocp_if changes from Paul Changes from V1: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/081037.html - Based on Tony's comment, added pbase size argument to omap_init_clocksource_32k(), to avoid cpu_is_xxx() check. - Added commit description based on discussion on list (Thanks to Santosh here) - Reorder patch sequence Vaibhav Hiremath (3): ARM: OMAP2/3: Add idle_st bits for ST_32KSYNC timer to prcm-common header ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod database ARM: OMAP: Make OMAP clocksource source selection using kernel param arch/arm/mach-omap1/timer32k.c |6 +- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 19 arch/arm/mach-omap2/omap_hwmod_2430_data.c | 19 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 19 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 54 ++ arch/arm/mach-omap2/omap_hwmod_common_data.h |1 + arch/arm/mach-omap2/prcm-common.h |4 + arch/arm/mach-omap2/timer.c| 99 ++ arch/arm/plat-omap/counter_32k.c | 108 ++-- arch/arm/plat-omap/include/plat/common.h |2 +- 10 files changed, 254 insertions(+), 77 deletions(-) -- 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-V5 1/3] ARM: OMAP2/3: Add idle_st bits for ST_32KSYNC timer to prcm-common header
Add missing idle_st bit for 32k-sync timer into the prcm-common header file, required for hwmod data. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Felipe Balbi ba...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com --- NOTE: This patch is same as first version, without any code changes. arch/arm/mach-omap2/prcm-common.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/prcm-common.h b/arch/arm/mach-omap2/prcm-common.h index 5aa5435..29955d5 100644 --- a/arch/arm/mach-omap2/prcm-common.h +++ b/arch/arm/mach-omap2/prcm-common.h @@ -177,6 +177,8 @@ /* PM_WKST_WKUP, CM_IDLEST_WKUP shared bits */ #define OMAP24XX_ST_GPIOS_SHIFT2 #define OMAP24XX_ST_GPIOS_MASK (1 2) +#define OMAP24XX_ST_32KSYNC_SHIFT 1 +#define OMAP24XX_ST_32KSYNC_MASK (1 1) #define OMAP24XX_ST_GPT1_SHIFT 0 #define OMAP24XX_ST_GPT1_MASK (1 0) @@ -307,6 +309,8 @@ #define OMAP3430_ST_SR1_MASK (1 6) #define OMAP3430_ST_GPIO1_SHIFT3 #define OMAP3430_ST_GPIO1_MASK (1 3) +#define OMAP3430_ST_32KSYNC_SHIFT 2 +#define OMAP3430_ST_32KSYNC_MASK (1 2) #define OMAP3430_ST_GPT12_SHIFT1 #define OMAP3430_ST_GPT12_MASK (1 1) #define OMAP3430_ST_GPT1_SHIFT 0 -- 1.7.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
[PATCH-V5 2/3] ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod database
Add 32k-sync timer hwmod-data and add ocp_if details to
omap2 3 hwmod table.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
---
NOTE: This patch is same as first version, without any code changes.
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 19 +++
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 19 +++
arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 19 +++
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 54
arch/arm/mach-omap2/omap_hwmod_common_data.h |1 +
5 files changed, 112 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 2c087ff..b961b0d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -428,6 +428,24 @@ static struct omap_hwmod_ocp_if omap2420_l4_core__mcbsp2 =
{
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_wkup - 32ksync_counter */
+static struct omap_hwmod_addr_space omap2420_counter_32k_addrs[] = {
+ {
+ .pa_start = 0x48004000,
+ .pa_end = 0x4800401f,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__counter_32k = {
+ .master = omap2xxx_l4_wkup_hwmod,
+ .slave = omap2xxx_counter_32k_hwmod,
+ .clk= sync_32k_ick,
+ .addr = omap2420_counter_32k_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[] __initdata = {
omap2xxx_l3_main__l4_core,
omap2xxx_mpu__l3_main,
@@ -468,6 +486,7 @@ static struct omap_hwmod_ocp_if *omap2420_hwmod_ocp_ifs[]
__initdata = {
omap2420_l4_core__mailbox,
omap2420_l4_core__mcbsp1,
omap2420_l4_core__mcbsp2,
+ omap2420_l4_wkup__counter_32k,
NULL,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 71d9f88..c9ac3ec 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -838,6 +838,24 @@ static struct omap_hwmod_ocp_if omap2430_l4_core__mcbsp5 =
{
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_wkup - 32ksync_counter */
+static struct omap_hwmod_addr_space omap2430_counter_32k_addrs[] = {
+ {
+ .pa_start = 0x4902,
+ .pa_end = 0x4902001f,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_wkup__counter_32k = {
+ .master = omap2xxx_l4_wkup_hwmod,
+ .slave = omap2xxx_counter_32k_hwmod,
+ .clk= sync_32k_ick,
+ .addr = omap2430_counter_32k_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *omap2430_hwmod_ocp_ifs[] __initdata = {
omap2xxx_l3_main__l4_core,
omap2xxx_mpu__l3_main,
@@ -886,6 +904,7 @@ static struct omap_hwmod_ocp_if *omap2430_hwmod_ocp_ifs[]
__initdata = {
omap2430_l4_core__mcbsp3,
omap2430_l4_core__mcbsp4,
omap2430_l4_core__mcbsp5,
+ omap2430_l4_wkup__counter_32k,
NULL,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index 45aaa07..8c37cb5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -732,3 +732,22 @@ struct omap_hwmod omap2xxx_mcspi2_hwmod = {
.class = omap2xxx_mcspi_class,
.dev_attr = omap_mcspi2_dev_attr,
};
+
+static struct omap_hwmod_class omap2xxx_counter_hwmod_class = {
+ .name = counter,
+};
+
+struct omap_hwmod omap2xxx_counter_32k_hwmod = {
+ .name = counter_32k,
+ .main_clk = func_32k_ck,
+ .prcm = {
+ .omap2 = {
+ .module_offs = WKUP_MOD,
+ .prcm_reg_id = 1,
+ .module_bit = OMAP24XX_ST_32KSYNC_SHIFT,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP24XX_ST_32KSYNC_SHIFT,
+ },
+ },
+ .class = omap2xxx_counter_hwmod_class,
+};
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 0c65079..f55dc6a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1981,6 +1981,40 @@ static struct omap_hwmod omap3xxx_usb_tll_hs_hwmod = {
};
/*
+ * '32K sync counter' class
[PATCH-V5 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param
Current OMAP code supports couple of clocksource options based
on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz).
So there can be 3 options -
1. 32KHz sync-timer
2. Sys_clock based (e.g 13/19.2/26/38.4 MHz) gptimer
3. 32KHz based gptimer.
The optional gptimer based clocksource was added so that it can
give the high precision than sync-timer, so expected usage was 2
and not 3.
Unfortunately option 2, clocksource doesn't meet the requirement of
free-running clock as per clocksource need. It stops in low power states
when sys_clock is cut. That makes gptimer based clocksource option
useless for OMAP2/3/4 devices with sys_clock as a clock input.
So, in order to use option 2, deeper idle state MUST be disabled.
Option 3 will still work but it is no better than 32K sync-timer
based clocksource.
We must support both sync timer and gptimer based clocksource as
some OMAP based derivative SoCs like AM33XX does not have the
sync timer.
Considering above, make sync-timer and gptimer clocksource runtime
selectable so that both OMAP and AM continue to use the same code.
Also, in order to precisely configure/setup sched_clock for given
clocksource, decision has to be made early enough in boot sequence.
So, the solution is,
Use standard kernel parameter (clocksource=) to override
default 32k_sync-timer, in addition to this, we also use hwmod database
lookup mechanism, through which at run-time we can identify availability
of 32k-sync timer on the device, else fall back to gptimer.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Ming Lei tom.leim...@gmail.com
---
NOTE: This patch is same as V3, without any code changes. Only
commit description has been modified.
arch/arm/mach-omap1/timer32k.c |6 ++-
arch/arm/mach-omap2/timer.c | 99 +--
arch/arm/plat-omap/counter_32k.c | 108 +++---
arch/arm/plat-omap/include/plat/common.h |2 +-
4 files changed, 138 insertions(+), 77 deletions(-)
diff --git a/arch/arm/mach-omap1/timer32k.c b/arch/arm/mach-omap1/timer32k.c
index 325b9a0..6262e11 100644
--- a/arch/arm/mach-omap1/timer32k.c
+++ b/arch/arm/mach-omap1/timer32k.c
@@ -71,6 +71,7 @@
/* 16xx specific defines */
#define OMAP1_32K_TIMER_BASE 0xfffb9000
+#define OMAP1_32KSYNC_TIMER_BASE 0xfffbc400
#define OMAP1_32K_TIMER_CR 0x08
#define OMAP1_32K_TIMER_TVR0x00
#define OMAP1_32K_TIMER_TCR0x04
@@ -184,7 +185,10 @@ static __init void omap_init_32k_timer(void)
*/
bool __init omap_32k_timer_init(void)
{
- omap_init_clocksource_32k();
+ u32 pbase;
+
+ pbase = cpu_is_omap16xx() ? OMAP1_32KSYNC_TIMER_BASE : NULL;
+ omap_init_clocksource_32k(pbase, SZ_1K);
omap_init_32k_timer();
return true;
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index ecec873..d720f58 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -243,22 +243,8 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
}
/* Clocksource code */
-
-#ifdef CONFIG_OMAP_32K_TIMER
-/*
- * When 32k-timer is enabled, don't use GPTimer for clocksource
- * instead, just leave default clocksource which uses the 32k
- * sync counter. See clocksource setup in plat-omap/counter_32k.c
- */
-
-static void __init omap2_gp_clocksource_init(int unused, const char *dummy)
-{
- omap_init_clocksource_32k();
-}
-
-#else
-
static struct omap_dm_timer clksrc;
+static bool use_gptimer_clksrc;
/*
* clocksource
@@ -285,7 +271,33 @@ static u32 notrace dmtimer_read_sched_clock(void)
}
/* Setup free-running counter for clocksource */
-static void __init omap2_gp_clocksource_init(int gptimer_id,
+static int __init omap2_sync32k_clocksource_init(void)
+{
+ int ret;
+ struct omap_hwmod *oh;
+ struct resource res;
+ const char *oh_name = counter_32k;
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh || oh-slaves_cnt == 0)
+ return -ENODEV;
+
+ ret = omap_hwmod_get_resource_byname(oh, IORESOURCE_MEM, NULL, res);
+ if (ret) {
+ pr_warn(%s: failed to get counter_32k resource (%d)\n,
+ __func__, ret);
+ return ret;
+ }
+
+ ret = omap_init_clocksource_32k(res.start, resource_size(res));
+ if (ret)
+ pr_warn(%s: failed to initialize counter_32k (%d)\n,
+ __func__, ret);
+
+ return ret;
+}
+
+static void __init omap2_gptimer_clocksource_init(int
Re: [PATCH] ARM: OMAP3: gpmc: add BCH ecc api and modes
On Tue, 2012-04-17 at 10:48 +0200, Ivan Djelic wrote: This patch adds a simple BCH ecc computation api, similar to the existing Hamming ecc api. It is intended to be used by the MTD layer. It implements the following features: - support 4-bit and 8-bit ecc computation - do not protect user bytes in spare area, only data area is protected - ecc for an erased NAND page (0xFFs) is also a sequence of 0xFFs This last feature is obtained by adding a constant polynomial to the hardware computed ecc. It allows to correct bitflips in blank pages and is extremely useful to support filesystems such as UBIFS, which expect erased pages to contain only 0xFFs. This api has been tested on an OMAP3630 board. Signed-off-by: Ivan Djelic ivan.dje...@parrot.com Hi Tony, what do you think about merging this patch? This is the enabler for making UBIFS actually usable on OMAP platforms which use BCH ECC. There are 2 other MTD patches which depend on this - so I wonder if it is easier to merge this one via the MTD tree, providing it has your/others' ack(s). Thanks! -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH 01/19] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode
Hi Tero,
On 04/25/2012 02:33 AM, Tero Kristo wrote:
On Mon, 2012-04-23 at 11:09 -0500, Jon Hunter wrote:
Hi Tero,
On 04/20/2012 04:33 AM, Tero Kristo wrote:
[...]
+/**
+ * omap4_dpll_print_reg - dump out a single DPLL register value
+ * @dpll_reg: register to dump
+ * @name: name of the register
+ * @tuple: content of the register
+ *
+ * Helper dump function to print out a DPLL register value in case
+ * of restore failures.
+ */
+static void omap4_dpll_print_reg(struct omap4_dpll_regs *dpll_reg, char
*name,
+struct dpll_reg *tuple)
+{
+ if (tuple-offset)
+ pr_warn(%s - Address offset = 0x%08x, value=0x%08x\n, name,
+ tuple-offset, tuple-val);
Minor nit-pick here ...
1. Offset is 16-bits and so we can just have offset = 0x%04x
2. Consider dropping Address from Address offset
3. Can we be consistent in our spaces for offset = and value=?
+}
+
+/*
+ * omap4_dpll_dump_regs - dump out DPLL registers
+ * @dpll_reg: DPLL to dump
+ *
+ * Dump out the contents of the registers for a DPLL. Called if a
+ * restore for DPLL fails to lock.
+ */
+static void omap4_dpll_dump_regs(struct omap4_dpll_regs *dpll_reg)
+{
+ pr_warn(%s: Unable to lock dpll %s[part=%x inst=%x]:\n,
+ __func__, dpll_reg-name, dpll_reg-mod_partition,
+ dpll_reg-mod_inst);
+ omap4_dpll_print_reg(dpll_reg, clksel, dpll_reg-clksel);
+ omap4_dpll_print_reg(dpll_reg, div_m2, dpll_reg-div_m2);
+ omap4_dpll_print_reg(dpll_reg, div_m3, dpll_reg-div_m3);
+ omap4_dpll_print_reg(dpll_reg, div_m4, dpll_reg-div_m4);
+ omap4_dpll_print_reg(dpll_reg, div_m5, dpll_reg-div_m5);
+ omap4_dpll_print_reg(dpll_reg, div_m6, dpll_reg-div_m6);
+ omap4_dpll_print_reg(dpll_reg, div_m7, dpll_reg-div_m7);
+ omap4_dpll_print_reg(dpll_reg, clkdcoldo, dpll_reg-clkdcoldo);
+ omap4_dpll_print_reg(dpll_reg, clkmode, dpll_reg-clkmode);
+ omap4_dpll_print_reg(dpll_reg, autoidle, dpll_reg-autoidle);
+ if (dpll_reg-idlest.offset)
+ pr_warn(idlest - Address offset = 0x%08x, before val=0x%08x
+after = 0x%08x\n, dpll_reg-idlest.offset,
+ dpll_reg-idlest.val,
+ omap4_dpll_read_reg(dpll_reg, dpll_reg-idlest));
Nit-pick ...
1. Same comments as above
2. Consider dropping Address offset altogether here as we print
idlest the offset should be implied.
3. Also can we be consistent in our naming of before val and after?
For example, val before = and val now = .
Okay, I'll modify both prints slightly. Question though, do we want
these prints in the kernel in the first place? At least Tony has been
frowning upon register dumps in the kernel and this falls into that
category. What we could do is just to print the warning but drop the
register dumps out.
Thanks. Good question. If we are not seeing failures often, and I would
hope not, probably ok to remove. However, I will let Tony comment here ...
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3.4-rc3] MTD: NAND: ams-delta: Fix request_mem_region() failure
On Tue, 2012-04-17 at 15:49 +0200, Janusz Krzysztofik wrote: A call to request_mem_region() has been introduced in the omap-gpio driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40, gpio/omap: Use devm_ API and add request_mem_region). This change prevented the Amstrad Delta NAND driver, which was doing the same in order to take control over OMAP MPU I/O lines that the NAND device hangs off, from loading successfully. There is another driver, omap-keypad, which also manipulates OMAP MPUIO registers, but has never been calling request_mem_region() on startup, so it's not affected by the change in the gpio-omap and works correctly. Drop request_mem_region() call and related bits from ams-delta NAND driver. Created and tested against linux-3.4-rc3. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl How about race conditions? Where is the guarantee that these 2 drivers won't affect each other when doing I/O at the same time to the same HW resources? -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH 15/19] ARM: OMAP4430: PM: workaround for DDR corruption on second CS
Hi Tero,
On 04/25/2012 02:26 AM, Tero Kristo wrote:
On Tue, 2012-04-24 at 13:22 -0500, Jon Hunter wrote:
Hi Tero,
On 04/20/2012 04:33 AM, Tero Kristo wrote:
From: Santosh Shilimkar santosh.shilim...@ti.com
Work around for Errata ID: i632 LPDDR2 Corruption After OFF Mode
Transition When CS1 Is Used On EMIF which impacts OMAP443x silicon
The issue occurs when EMIF_SDRAM_CONFIG is restored first before
EMIF_SDRAM_CONFIG_2 is not yet restored, the register configuration
is not set properly, we apply the required workaround allowing
the restore sequence to work properly.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
[t-kri...@ti.com: moved workaround from omap-sar.c to pm44xx.c]
Signed-off-by: Tero Kristo t-kri...@ti.com
---
.../include/mach/ctrl_module_wkup_44xx.h |2 +
arch/arm/mach-omap2/pm44xx.c | 24
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
b/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
index a0af9ba..b763a79 100644
--- a/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
+++ b/arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
@@ -28,6 +28,8 @@
#define OMAP4_CTRL_MODULE_WKUP_IP_REVISION 0x
#define OMAP4_CTRL_MODULE_WKUP_IP_HWINFO 0x0004
#define OMAP4_CTRL_MODULE_WKUP_IP_SYSCONFIG0x0010
+#define OMAP4_CTRL_SECURE_EMIF1_SDRAM_CONFIG2_REG 0x0114
+#define OMAP4_CTRL_SECURE_EMIF2_SDRAM_CONFIG2_REG 0x011c
#define OMAP4_CTRL_MODULE_WKUP_CONF_DEBUG_SEL_TST_00x0460
#define OMAP4_CTRL_MODULE_WKUP_CONF_DEBUG_SEL_TST_10x0464
#define OMAP4_CTRL_MODULE_WKUP_CONF_DEBUG_SEL_TST_20x0468
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 0472921..d4d18d9 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -17,6 +17,9 @@
#include linux/err.h
#include linux/slab.h
#include asm/system_misc.h
+#include linux/io.h
+
+#include mach/ctrl_module_wkup_44xx.h
#include common.h
#include clockdomain.h
@@ -215,6 +218,27 @@ static int __init omap4_pm_init(void)
pr_err(Power Management for TI OMAP4.\n);
+ /*
+* Work around for OMAP443x Errata i632: LPDDR2 Corruption After OFF
+* Mode Transition When CS1 Is Used On EMIF:
+* Overwrite EMIF1/EMIF2
+* SECURE_EMIF1_SDRAM_CONFIG2_REG
+* SECURE_EMIF2_SDRAM_CONFIG2_REG
+*/
+ if (cpu_is_omap443x()) {
+ void __iomem *secure_ctrl_mod;
+
+ secure_ctrl_mod = ioremap(OMAP4_CTRL_MODULE_WKUP, SZ_4K);
+ BUG_ON(!secure_ctrl_mod);
+
+ __raw_writel(0x10, secure_ctrl_mod +
+OMAP4_CTRL_SECURE_EMIF1_SDRAM_CONFIG2_REG);
+ __raw_writel(0x10, secure_ctrl_mod +
+OMAP4_CTRL_SECURE_EMIF2_SDRAM_CONFIG2_REG);
According to the erratum description the above registers are used to
restore the EMIFx_SDRAM_CONFIG2 registers. So although the value 0x10,
maybe the value being used for EMIFx_SDRAM_CONFIG2 registers, shouldn't
we read the EMIFx_SDRAM_CONFIG2 registers and store them in the above
registers?
This might be a good idea, however, this patch might be tagged as TEMP
until the EMIF driver is in place, this fix should rather be located
there. I'll take a look at this if I can change the implementation a
bit.
By the way, I did dump the EMIF1_SDRAM_CONFIG2 register on a omap4403
and it is configured to 0x10. So I think that reading this register and
saving would be safe.
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V3 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data
On 4/25/2012 3:55 PM, Paul Walmsley wrote: Hi Vaibhav, On Wed, 25 Apr 2012, Hiremath, Vaibhav wrote: Thanks for describing it for me. I will change AM33XX clock tree for this And submit the next version soon. Well I can just remove those leaf clock entries from my copy here, if you're okay with that ? Please take care of changing the hwmod main_clk as well. But maybe that's not part of that series. -- 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: OMAP3: gpmc: add BCH ecc api and modes
Hi, * Artem Bityutskiy dedeki...@gmail.com [120425 07:52]: On Tue, 2012-04-17 at 10:48 +0200, Ivan Djelic wrote: This patch adds a simple BCH ecc computation api, similar to the existing Hamming ecc api. It is intended to be used by the MTD layer. It implements the following features: - support 4-bit and 8-bit ecc computation - do not protect user bytes in spare area, only data area is protected - ecc for an erased NAND page (0xFFs) is also a sequence of 0xFFs This last feature is obtained by adding a constant polynomial to the hardware computed ecc. It allows to correct bitflips in blank pages and is extremely useful to support filesystems such as UBIFS, which expect erased pages to contain only 0xFFs. This api has been tested on an OMAP3630 board. Signed-off-by: Ivan Djelic ivan.dje...@parrot.com Hi Tony, what do you think about merging this patch? This is the enabler for making UBIFS actually usable on OMAP platforms which use BCH ECC. There are 2 other MTD patches which depend on this - so I wonder if it is easier to merge this one via the MTD tree, providing it has your/others' ack(s). Looks OK to me, however there are other pending GPMC patches to convert it to a platform device device driver. Need to look those closer though. Anyways, it's best that I queue them to avoid merge conflicts. Do you these for other changes for UBIFS? If so, I can set up an immutable branch for GPMC that you can merge in as well. 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-V3 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data
On Wed, 25 Apr 2012, Cousson, Benoit wrote: Please take care of changing the hwmod main_clk as well. But maybe that's not part of that series. It's not part of the series yet. Vaibhav, could you take care of changing the main_clk in your hwmod data patches, and send those to the list? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V3 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data
On Wed, Apr 25, 2012 at 21:06:43, Paul Walmsley wrote: On Wed, 25 Apr 2012, Cousson, Benoit wrote: Please take care of changing the hwmod main_clk as well. But maybe that's not part of that series. It's not part of the series yet. Vaibhav, could you take care of changing the main_clk in your hwmod data patches, and send those to the list? Yes, Working on the same now... Thanks, Vaibhav - 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] ARM: OMAP3: gpmc: add BCH ecc api and modes
On Wed, 2012-04-25 at 08:23 -0700, Tony Lindgren wrote: Hi, * Artem Bityutskiy dedeki...@gmail.com [120425 07:52]: On Tue, 2012-04-17 at 10:48 +0200, Ivan Djelic wrote: This patch adds a simple BCH ecc computation api, similar to the existing Hamming ecc api. It is intended to be used by the MTD layer. It implements the following features: - support 4-bit and 8-bit ecc computation - do not protect user bytes in spare area, only data area is protected - ecc for an erased NAND page (0xFFs) is also a sequence of 0xFFs This last feature is obtained by adding a constant polynomial to the hardware computed ecc. It allows to correct bitflips in blank pages and is extremely useful to support filesystems such as UBIFS, which expect erased pages to contain only 0xFFs. This api has been tested on an OMAP3630 board. Signed-off-by: Ivan Djelic ivan.dje...@parrot.com Hi Tony, what do you think about merging this patch? This is the enabler for making UBIFS actually usable on OMAP platforms which use BCH ECC. There are 2 other MTD patches which depend on this - so I wonder if it is easier to merge this one via the MTD tree, providing it has your/others' ack(s). Looks OK to me, however there are other pending GPMC patches to convert it to a platform device device driver. Need to look those closer though. Anyways, it's best that I queue them to avoid merge conflicts. Sure. Do you these for other changes for UBIFS? Not in UBIFS, but in drivers/mtd/nand/omap2.c - Ivan sent another patch which adds BCH support to to omap2.c, was sent to linux-omap, subject [PATCH] mtd: nand: omap: add support for hardware BCH ecc If so, I can set up an immutable branch for GPMC that you can merge in as well. I guess this would be a good idea, but probably it is better to do this when you believe you merged most gpmc patches, so probably closer to the final -rc? -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH] ARM: OMAP3: gpmc: add BCH ecc api and modes
* Artem Bityutskiy dedeki...@gmail.com [120425 08:48]: On Wed, 2012-04-25 at 08:23 -0700, Tony Lindgren wrote: Hi, * Artem Bityutskiy dedeki...@gmail.com [120425 07:52]: On Tue, 2012-04-17 at 10:48 +0200, Ivan Djelic wrote: This patch adds a simple BCH ecc computation api, similar to the existing Hamming ecc api. It is intended to be used by the MTD layer. It implements the following features: - support 4-bit and 8-bit ecc computation - do not protect user bytes in spare area, only data area is protected - ecc for an erased NAND page (0xFFs) is also a sequence of 0xFFs This last feature is obtained by adding a constant polynomial to the hardware computed ecc. It allows to correct bitflips in blank pages and is extremely useful to support filesystems such as UBIFS, which expect erased pages to contain only 0xFFs. This api has been tested on an OMAP3630 board. Signed-off-by: Ivan Djelic ivan.dje...@parrot.com Hi Tony, what do you think about merging this patch? This is the enabler for making UBIFS actually usable on OMAP platforms which use BCH ECC. There are 2 other MTD patches which depend on this - so I wonder if it is easier to merge this one via the MTD tree, providing it has your/others' ack(s). Looks OK to me, however there are other pending GPMC patches to convert it to a platform device device driver. Need to look those closer though. Anyways, it's best that I queue them to avoid merge conflicts. Sure. Do you these for other changes for UBIFS? Not in UBIFS, but in drivers/mtd/nand/omap2.c - Ivan sent another patch which adds BCH support to to omap2.c, was sent to linux-omap, subject [PATCH] mtd: nand: omap: add support for hardware BCH ecc If so, I can set up an immutable branch for GPMC that you can merge in as well. I guess this would be a good idea, but probably it is better to do this when you believe you merged most gpmc patches, so probably closer to the final -rc? Yes let's wait a week or so as there are also the dmaengine patch for drivers/mtd/nand/omap2.c that might conflict. So let's get the dmaengine patches to some branch first. 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] ASoC: omap-pcm: Free dma buffers in case of error.
On Tue, 2012-04-24 at 19:02 -0700, Oleg Matcovschi wrote: Change-Id: I4ba9de0de4681332539246ccc5e11a7a8fb32e79 Signed-off-by: Oleg Matcovschi oleg.matcovs...@ti.com --- v1: initial revision v2: resending patch including maintainers sound/soc/omap/omap-pcm.c |4 1 files changed, 4 insertions(+), 0 deletions(-) Now applied for 3.4 with change ID removed. Thanks Liam -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/9] Convert OMAP GPMC to driver
* Afzal Mohammed af...@ti.com [120405 09:06]: Hi, GPMC driver conversion series. NAND and smsc911x ethernet device has been adapted to use GPMC driver. Patches has been generated over linux-omap/master, HEAD 33fc21e Linux-omap rebuilt: Updated to v3.4-rc1, merged in most of pending branches As OMAP3EVM does not boot linux-omap/master, merge commit, 58adb29 Merge branch 'io_chain_devel_3.4' of git://git.pwsan.com/linux-2.6 into prm has to be reverted to get OMAP3EVM boot. Last patch (with subject prefix TMP - 9/9) is for testing. Once driver is acceptable, platform code for other peripherals connected via GPMC would be adapted to make use of GPMC driver. And then the board modifications. But before that HWMOD entry has to be populated for respective SoC(s ?). No, we can't do it this way, it breaks things. We need to first convert everything to use the new GPMC driver, then move it. Now DESTINATION FOR THIS DRIVER has to be decided. Original plan was to consider GPMC as MFD. The peripheral(s) connected to GPMC being considered childs of MFD. Let's not put it into MFD. This is a bus driver. But that decision can wait as we cleary have quite a few things to convert first under arch/arm/mach-omap2. Various options that could be seen so far on where this driver can go, 1. mfd 2. misc 3. drivers/platform/arm/ (create an new one?) 4. memory (create a new one ?) It's a parallel bus driver, not memory not misc, not MFD. Cheers, 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: [TMP] OMAP3EVM: Test gpmc nand smsc911x
* Afzal Mohammed af...@ti.com [120405 09:08]:
@@ -114,6 +147,8 @@ static struct omap_smsc911x_platform_data smsc911x_cfg = {
static inline void __init omap3evm_init_smsc911x(void)
{
+ struct gpmc_device_pdata *gpmc_smsc911x_info;
+
/* Configure ethernet controller reset gpio */
if (cpu_is_omap3430()) {
if (get_omap3_evm_rev() == OMAP3EVM_BOARD_GEN_1)
@@ -122,7 +157,11 @@ static inline void __init omap3evm_init_smsc911x(void)
smsc911x_cfg.gpio_reset = OMAP3EVM_GEN2_ETHR_GPIO_RST;
}
- gpmc_smsc911x_init(smsc911x_cfg);
+ gpmc_smsc911x_info = gpmc_smsc911x_init(smsc911x_cfg);
+ if (gpmc_smsc911x_info)
+ *gpmc_data_cur++ = gpmc_smsc911x_info;
+ else
+ pr_err(error: unable to initilaize gpmc smsc911x\n);
}
#else
Obviously we can't merge any of this if until all the board-*.c files
are changed and tested.
Can you maybe still keep the old interfaces in addition to the new ones
so we can do the conversion one board-*.c file at a time while keeping
things working?
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] ARM: OMAP3: gpmc: add BCH ecc api and modes
* Tony Lindgren t...@atomide.com [120425 09:01]: * Artem Bityutskiy dedeki...@gmail.com [120425 08:48]: On Wed, 2012-04-25 at 08:23 -0700, Tony Lindgren wrote: Hi, * Artem Bityutskiy dedeki...@gmail.com [120425 07:52]: On Tue, 2012-04-17 at 10:48 +0200, Ivan Djelic wrote: This patch adds a simple BCH ecc computation api, similar to the existing Hamming ecc api. It is intended to be used by the MTD layer. It implements the following features: - support 4-bit and 8-bit ecc computation - do not protect user bytes in spare area, only data area is protected - ecc for an erased NAND page (0xFFs) is also a sequence of 0xFFs This last feature is obtained by adding a constant polynomial to the hardware computed ecc. It allows to correct bitflips in blank pages and is extremely useful to support filesystems such as UBIFS, which expect erased pages to contain only 0xFFs. This api has been tested on an OMAP3630 board. Signed-off-by: Ivan Djelic ivan.dje...@parrot.com Hi Tony, what do you think about merging this patch? This is the enabler for making UBIFS actually usable on OMAP platforms which use BCH ECC. There are 2 other MTD patches which depend on this - so I wonder if it is easier to merge this one via the MTD tree, providing it has your/others' ack(s). Looks OK to me, however there are other pending GPMC patches to convert it to a platform device device driver. Need to look those closer though. Anyways, it's best that I queue them to avoid merge conflicts. Sure. Do you these for other changes for UBIFS? Not in UBIFS, but in drivers/mtd/nand/omap2.c - Ivan sent another patch which adds BCH support to to omap2.c, was sent to linux-omap, subject [PATCH] mtd: nand: omap: add support for hardware BCH ecc If so, I can set up an immutable branch for GPMC that you can merge in as well. I guess this would be a good idea, but probably it is better to do this when you believe you merged most gpmc patches, so probably closer to the final -rc? Yes let's wait a week or so as there are also the dmaengine patch for drivers/mtd/nand/omap2.c that might conflict. So let's get the dmaengine patches to some branch first. Looking at the gpmc platform driver series, we can't merge those until all the board-*.c files are converted. So let's plan on first making sure the dmaengine changes work, then apply the BCH ecc patches. 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] ARM: OMAP3: gpmc: add BCH ecc api and modes
Hi,
Few comments below.
* Ivan Djelic ivan.dje...@parrot.com [120419 11:49]:
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 00d5108..e3a91a1 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -49,6 +49,7 @@
#define GPMC_ECC_CONTROL 0x1f8
#define GPMC_ECC_SIZE_CONFIG 0x1fc
#define GPMC_ECC1_RESULT0x200
+#define GPMC_ECC_BCH_RESULT_0 0x240
Can you please add a comment here saying something like:
#define GPMC_ECC_BCH_RESULT_0 0x240 /* Not available on omap2 */
@@ -920,3 +921,150 @@ int gpmc_calculate_ecc(int cs, const u_char *dat,
u_char *ecc_code)
return 0;
}
EXPORT_SYMBOL_GPL(gpmc_calculate_ecc);
+
+#ifdef CONFIG_ARCH_OMAP3
+
+/**
+ * gpmc_enable_hwecc_bch - enable hardware BCH ecc functionality
+ * @cs: chip select number
+ * @mode: read/write mode
+ * @dev_width: device bus width(1 for x16, 0 for x8)
+ * @nsectors: how many 512-byte sectors to process
+ * @nerrors: how many errors to correct per sector (4 or 8)
+ */
+int gpmc_enable_hwecc_bch(int cs, int mode, int dev_width, int nsectors,
+ int nerrors)
+{
+ unsigned int val;
+
+ /* check if ecc module is in use */
+ if (gpmc_ecc_used != -EINVAL)
+ return -EINVAL;
+ /*
+ * FIXME: some OMAP3 revisions have a hardware bug which prevents
+ * the 4-bit BCH mode from working properly. Such revisions could be
+ * detected and rejected here.
+ */
This should then be disabled to avoid corruption. Maybe only allow it
initially on omaps that have been tested? And for omap2 it should return
error for sure.
Or do you know the broken omap3 versions?
Also, should you first request this feature in case multiple drivers
need to share it?
Other than that, looks good to me.
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 v3.4-rc3] MTD: NAND: ams-delta: Fix request_mem_region() failure
Dnia środa, 25 kwietnia 2012 18:13:38 Artem Bityutskiy pisze: On Tue, 2012-04-17 at 15:49 +0200, Janusz Krzysztofik wrote: A call to request_mem_region() has been introduced in the omap-gpio driver recently (commit 96751fcbe5438e95514b025e9cee7a6d38038f40, gpio/omap: Use devm_ API and add request_mem_region). This change prevented the Amstrad Delta NAND driver, which was doing the same in order to take control over OMAP MPU I/O lines that the NAND device hangs off, from loading successfully. There is another driver, omap-keypad, which also manipulates OMAP MPUIO registers, but has never been calling request_mem_region() on startup, so it's not affected by the change in the gpio-omap and works correctly. Drop request_mem_region() call and related bits from ams-delta NAND driver. Created and tested against linux-3.4-rc3. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl How about race conditions? Where is the guarantee that these 2 drivers won't affect each other when doing I/O at the same time to the same HW resources? Both drivers use separate subsets of registers that belong to the OMAP1 MPU I/O device, but are used for controlling different sets of I/O pins. The NAND driver reads/writes the folowing registers: - OMAP_MPUIO_INPUT_LATCH, - OMAP_MPUIO_OUTPUT, - OMAP_MPUIO_IO_CNTL, while the keypad driver - the following: - OMAP_MPUIO_KBR_LATCH, - OMAP_MPUIO_KBC, - OMAP_MPUIO_KBD_MASKIT - OMAP_MPUIO_GPIO_DEBOUNCING. Both subsets are non-overlapping, and we rely on the drivers being free of bugs and doing their job correctly, not stepping on each others' feet, I guess. Thanks, Janusz -- 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] ARM: OMAP3: gpmc: add BCH ecc api and modes
Hi Tony, Thanks for the review, On Wed, Apr 25, 2012 at 06:03:14PM +0100, Tony Lindgren wrote: (...) #define GPMC_ECC1_RESULT0x200 +#define GPMC_ECC_BCH_RESULT_0 0x240 Can you please add a comment here saying something like: #define GPMC_ECC_BCH_RESULT_0 0x240 /* Not available on omap2 */ OK sure. + /* check if ecc module is in use */ + if (gpmc_ecc_used != -EINVAL) + return -EINVAL; + /* +* FIXME: some OMAP3 revisions have a hardware bug which prevents +* the 4-bit BCH mode from working properly. Such revisions could be +* detected and rejected here. +*/ This should then be disabled to avoid corruption. Maybe only allow it initially on omaps that have been tested? And for omap2 it should return error for sure. OK I'll add a check. Or do you know the broken omap3 versions? Well, I was hoping that someone from linux-omap could tell me :) I found this HW ECC feature table in http://processors.wiki.ti.com/index.php/Raw_NAND_ECC: 1b 4b 8b --- OMAP35x YESNO YES AM35xYESYES YES AM/DM37x YESYES YES and other wiki pages confirmed that 4-bit mode is not supported on all OMAP35xx chips. OTOH, I know from TI support that 4-bit mode is at least supported on OMAP3630 ES1.x (x = 1). So, a conservative approach would be to reject 4-bit mode on all chips but omap3630 with rev = 1.1. Other revisions/chips could be added later if they are confirmed to work; what do you think ? Also, should you first request this feature in case multiple drivers need to share it? According to TI documentation (OMAP36xx ES1.x TRM, §10.1.4, GPMC functional diagram), the GPMC ECC engines (Hamming and BCH) are dedicated to NAND access only; therefore I believe the mtd driver is the only potential user of this feature. Also, the existing Hamming ecc API does not perform any request; or did I miss something? If I need to perform the request, is there an existing api to do so? Thanks, -- Ivan -- 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] ARM: OMAP3: gpmc: add BCH ecc api and modes
* Ivan Djelic ivan.dje...@parrot.com [120425 11:33]: Hi Tony, Thanks for the review, On Wed, Apr 25, 2012 at 06:03:14PM +0100, Tony Lindgren wrote: (...) #define GPMC_ECC1_RESULT0x200 +#define GPMC_ECC_BCH_RESULT_0 0x240 Can you please add a comment here saying something like: #define GPMC_ECC_BCH_RESULT_0 0x240 /* Not available on omap2 */ OK sure. + /* check if ecc module is in use */ + if (gpmc_ecc_used != -EINVAL) + return -EINVAL; + /* + * FIXME: some OMAP3 revisions have a hardware bug which prevents + * the 4-bit BCH mode from working properly. Such revisions could be + * detected and rejected here. + */ This should then be disabled to avoid corruption. Maybe only allow it initially on omaps that have been tested? And for omap2 it should return error for sure. OK I'll add a check. Or do you know the broken omap3 versions? Well, I was hoping that someone from linux-omap could tell me :) I found this HW ECC feature table in http://processors.wiki.ti.com/index.php/Raw_NAND_ECC: 1b 4b 8b --- OMAP35x YESNO YES AM35xYESYES YES AM/DM37x YESYES YES and other wiki pages confirmed that 4-bit mode is not supported on all OMAP35xx chips. OTOH, I know from TI support that 4-bit mode is at least supported on OMAP3630 ES1.x (x = 1). So, a conservative approach would be to reject 4-bit mode on all chips but omap3630 with rev = 1.1. Other revisions/chips could be added later if they are confirmed to work; what do you think ? Sounds good to me. Also, should you first request this feature in case multiple drivers need to share it? According to TI documentation (OMAP36xx ES1.x TRM, §10.1.4, GPMC functional diagram), the GPMC ECC engines (Hamming and BCH) are dedicated to NAND access only; therefore I believe the mtd driver is the only potential user of this feature. Also, the existing Hamming ecc API does not perform any request; or did I miss something? If I need to perform the request, is there an existing api to do so? OK I guess the only conflict would be multiple NAND chips then, which we don't have at least currently AFAIK. 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/3] IRQ: allow check_wakeup_irqs to notice level-triggered interrupts.
On Wed, 25 Apr 2012 14:54:54 +0200 (CEST) Thomas Gleixner
t...@linutronix.de wrote:
On Wed, 25 Apr 2012, NeilBrown wrote:
On Wed, 25 Apr 2012 10:50:15 +0200 (CEST) Thomas Gleixner
t...@linutronix.de wrote:
On Wed, 25 Apr 2012, NeilBrown wrote:
Level triggered interrupts do not cause IRQS_PENDING to be set, so
check_wakeup_irqs ignores them.
They don't need to set IRQS_PENDING as the level stays high which
shows that they must be pending. However if such an interrupt fired
during late suspend, it will have been masked so the fact that it
is still asserted will not cause the suspend to abort.
So if any wakeup interrupt is masked, unmask it when checking wakeup
irqs. If the interrupt is asserted, suspend will abort.
Signed-off-by: NeilBrown ne...@suse.de
---
kernel/irq/pm.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/kernel/irq/pm.c b/kernel/irq/pm.c
index 15e53b1..0d26206 100644
--- a/kernel/irq/pm.c
+++ b/kernel/irq/pm.c
@@ -106,6 +106,12 @@ int check_wakeup_irqs(void)
if (irqd_is_wakeup_set(desc-irq_data)) {
if (desc-istate IRQS_PENDING)
return -EBUSY;
+ if (irqd_irq_masked(desc-irq_data))
+ /* Probably a level interrupt
+* which fired recently and was
+* masked
+*/
+ unmask_irq(desc);
Oh no. We don't unmask unconditionally. What about an interrupt which
is disabled, has no handler . ? That needs more thought.
If there is no handler, then irqd_is_wakeup_set() should fail should it not?
Well, it does not. The wakeup state is a permanent flag on the irq
line. Though we don't have IRQS_SUSPENDED on that descriptor.
For disabled: would it be OK to check desc-depth?
Something like:
if (desc-depth == 1 (desc-state IRQS_SUSPENDED)
irqd_irq_masked(desc-irq_data))
unmask_irq(desc);
Why not simply managing the pending bit for level irqs ?
Primarily because I was aiming for the simplest patch that would have the
desired effect. Also because 'pending' is implicit in the level so it seems
superfluous to store the bit separately. And understanding all the
consequences of that change is not something I felt up to.
However: thanks for the patch. I'll try to explore it tomorrow and see if
seems to be behaving correctly.
Thanks,
NeilBrown
Index: tip/kernel/irq/chip.c
===
--- tip.orig/kernel/irq/chip.c
+++ tip/kernel/irq/chip.c
@@ -379,8 +379,10 @@ handle_level_irq(unsigned int irq, struc
* If its disabled or no action available
* keep it masked and get out of here
*/
- if (unlikely(!desc-action || irqd_irq_disabled(desc-irq_data)))
+ if (unlikely(!desc-action || irqd_irq_disabled(desc-irq_data))) {
+ desc-istate |= IRQS_PENDING;
goto out_unlock;
+ }
handle_irq_event(desc);
Index: tip/kernel/irq/resend.c
===
--- tip.orig/kernel/irq/resend.c
+++ tip/kernel/irq/resend.c
@@ -58,10 +58,13 @@ void check_irq_resend(struct irq_desc *d
/*
* We do not resend level type interrupts. Level type
* interrupts are resent by hardware when they are still
- * active.
+ * active. Clear the pending bit so suspend/resume does not
+ * get confused.
*/
- if (irq_settings_is_level(desc))
+ if (irq_settings_is_level(desc)) {
+ desc-istate = ~IRQS_PENDING;
return;
+ }
if (desc-istate IRQS_REPLAY)
return;
if (desc-istate IRQS_PENDING) {
And to handle interrupts which have been disabled before suspend add:
Index: tip/kernel/irq/pm.c
===
--- tip.orig/kernel/irq/pm.c
+++ tip/kernel/irq/pm.c
@@ -103,7 +103,8 @@ int check_wakeup_irqs(void)
int irq;
for_each_irq_desc(irq, desc) {
- if (irqd_is_wakeup_set(desc-irq_data)) {
+ if (desc-depth == 1
+ irqd_is_wakeup_set(desc-irq_data)) {
if (desc-istate IRQS_PENDING)
return -EBUSY;
continue;
signature.asc
Description: PGP signature
Re: [PATCH 00/18][V3] ARM: OMAP3/4 : cpuidle34xx and cpuidle44xx cleanups
On 04/24/2012 04:05 PM, Daniel Lezcano wrote: This patchset makes some cleanup on these cpuidle drivers and consolidate the code across both architecture. Tested on OMAP3 (igepV2). Partially tested on OMAP4 (pandaboard), without offlining the cpu1. Hi, could be this patchset considered for inclusion ? Thanks -- Daniel -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro:http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- 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 10/10] OMAPDSS: HDMI: Implement DSS driver interface for audio
+alsa-devel list On 04/25/2012 01:19 AM, Tomi Valkeinen wrote: On Tue, 2012-04-24 at 23:48 -0500, Ricardo Neri wrote: On 04/23/2012 08:01 AM, Tomi Valkeinen wrote: On Wed, 2012-03-28 at 16:38 -0600, Ricardo Neri wrote: Implement the DSS device driver audio support interface in the HDMI panel driver and generic driver. The implementation relies on the IP-specific functions that are defined at DSS probe time. A HW-safe spinlock is used to protect the audio functions. This is because What is a HW-safe spinlock? Sorry, I meant a spinlock that disables the HW irqs when held:hardirq-safe. the audio functions may be called while holding a lock; in such case, the panel's driver mutex is not suitable. Functions should be used to set registers and should not wait for any other event. Are you sure this is the only option? What lock is being held? For instance, ALSA calls the start audio function while holding a hardirq-safe readlock. Hence, when reaching the HDMI panel start function, a lock is held and irqs are disabled. Using a mutex, that might sleep, is not correct; nor it is using an hardirq-unsafe spinlock. Otherwise, deadlocks and/or inverse lock ordering may arise. This situation was signaled by lockdep. IMHO, as the DSS device driver does not know who is going to use it (at least the audio part), it should not assume that no locks are held when its functions are called. While a spinlock may be ok for now, quite often enabling/disabling things do not happen immediately,and it's much easier to do the wait synchronously. I don't understand this comment. To me, holding a lock until the enabling function returns is synchronous. Would you please clarify? I meant that quite often when enabling things on hardware it takes time until the HW is actually up and running. Perhaps a regulator needs to be started, or such. And it's usually simpler to wait for the HW to be up synchronously in the enable function, instead of some kind of asynchronous mechanism. And if a function waits synchronously, a mutex is better than spinlock. And in that sense it's often better to define (define meaning, adding a comment, or just mentally taking note about it) that the functions in the API may sleep, so that the driver is free to do what is best for the case, and it's also future-proof in a way that you can easily add function calls that sleep to the functions in the future. But you are also right in your previous comment, it's better to define functions so that they never sleep, as that gives the callers the freedom to call the funcs in atomic context. Perhaps we can have audio_start() that never sleeps, it just enables a few bits that start the audio. But how about audio_enable()? Is it possible that on some OMAP version it would need to enable a regulator, or set a gpio that's in an external i2c controlled mux chip, or such? I think it might be possible to have such a scenario if, for instance, an external chip is used to support DisplayPort on OMAP4/5. As DisplayPort can support audio-only use-cases, it would have to enable the adapter chip (but HDMI output would have to be enabled to feed the chip, though). If so, we need to make sure it's not currently called in an atomic context, because it would break if the function will sleep in the future. And with make sure I just mean that we check the code and keep it in mind. Or perhaps adding a comment in the header, that says audio_enable may sleep, other audio functions do not sleep or such. I revisited the ALSA code. Only the audio_start function is atomic. Although ALSA may not be the only user, it makes sense to me to think that they will follow a similar approach in terms of locks. Hence, based on that and on the reasons you describe (audio_enable potentially taking too long to return), Rephrasing what you stated, a mutex may be used for the enable/disable and config operations. Only start/stop would be protected by a spinlock. This should be described in comments in the header file. Does it make sense to you? BR, Ricardo Tomi -- 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/3] ARM: OMAP: Add platform devices for ASoC HDMI drivers
Hi Tony, I was wondering if you've had the time to take a look at these patches. Thanks! Ricardo On 04/17/2012 07:40 PM, Ricardo Neri wrote: This set of patches is intended to add the platform devices for the ASoC HDMI drivers when not using device tree. For this, I took an approach similar to DMIC and McPDM by creating a dedicated functions to create the devices. I included the device for the CPU DAI driver, omap-hdmi-audio-dai, and the device for the machine driver, omap-hdmi-audio, in devices.c to reflect the fact that any OMAP4 (and OMAP5 in the future) has HDMI IP. I put the device for the codec in the board file to reflect the fact that not necessarily all the boards with OMAP4/5 have the HDMI output wired. Best regards Ricardo Ricardo Neri (3): ARM: OMAP: devices: Register platform devices for HDMI audio ARM: OMAP4: board-4430sdp: Register platform device for HDMI audio codec ARM: OMAP4: board-omap4panda: Register platform device for HDMI audio codec arch/arm/mach-omap2/board-4430sdp.c|6 ++ arch/arm/mach-omap2/board-omap4panda.c |6 ++ arch/arm/mach-omap2/devices.c | 31 +++ 3 files changed, 43 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V3 2/3] ARM: OMAP3+: clockdomain33xx: Add clockdomain data and respective operations
On Wed, 25 Apr 2012, Hiremath, Vaibhav wrote:
On Wed, Apr 25, 2012 at 05:52:26, Paul Walmsley wrote:
A few questions while reviewing this patch:
On Tue, 3 Apr 2012, Vaibhav Hiremath wrote:
AM33XX PRCM module consist of, various clockdomains, in all
total we have 18 clockdomains available, with following
controlling options,
- NO Sleep: sleep transition can not be initiated,
- SW Sleep: sw forced sleep transition,
- SW Wakeup: sw forced wakeup transition,
- HW Auto: transitions are based upon hw conditions.
This patch adds all available clockdomain data, respective
clockdomain operations for AM33XX family of device, and also
integrates it into existing OMAP framework.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
...
+static struct clockdomain l4ls_am33xx_clkdm = {
+ .name = l4ls_clkdm,
+ .pwrdm = { .name = per_pwrdm },
+ .cm_inst= AM33XX_CM_PER_MOD,
+ .clkdm_offs = AM33XX_CM_PER_L4LS_CLKSTCTRL_OFFSET,
+ .clktrctrl_mask = AM33XX_CLKTRCTRL_MASK,
+ .flags = (CLKDM_CAN_SWSUP | CLKDM_NO_AUTODEPS),
It looks to me like we don't need the .clktrctrl_mask field, since
according to the clockdomains code, the CLKTRCTRL field is at the same bit
shift for each clockdomain.
Yeah, we actually don't need it, probably I added for completeness.
I will remove it in next version.
I've removed them here.
Also, since we're not defining any autodeps for the AM335x platform, we
shouldn't need the CLKDM_NO_AUTODEPS flag either? Since no autodeps are
defined, the default will be to not set any autodeps.
This is required to avoid few pr_debug, if you don't provide it.
For example, without this flag set, you will get,
pr_debug(clockdomain: hardware cannot set/clear sleep
dependency affecting %s from %s\n, clkdm1-name,
clkdm2-name);
Refer to the file omap_hwmod.c, function, _enable(), the call sequence is,
_enable() = _add_initiator_dep() = clkdm_add_sleepdep() =leads to warning
Seems like the better thing to do is to just avoid calling
_{add,del}_initiator_dep() on the AM335x.
Another question is about the CLKTRCTRL bitfields. According to
_AM335x ARM Cortex-A8 Microprocessors (MPUs) Technical Reference
Manual_ Rev. D (SPRUH73D), most of the clockdomains support NO_SLEEP mode
(i.e., CLKTRCTRL = 0x0). That means that technically, we should also set
the CLKDM_CAN_DISABLE_AUTO flag. Unless the documentation is incorrect
here? In another section (Table 8-9 Clock Transition Mode Settings),
it claims that CLKTRCTRL = 0 is not supported...
It is not supported, and should be considered as documentation issue.
Okay so I guess the description for this patch (quoted above) is wrong
then also?
- 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/RFT 1/3] ARM: OMAP2+: powerdomain: allow pre/post transtion to be per pwrdm
On Tue, 24 Apr 2012, Kevin Hilman wrote: Iteration over all power domains in the idle path is unnecessary since only power domains that are transitioning need to be accounted for. Also PRCM register accesses are known to be expensive, so the additional latency added to the idle path is signficiant. In order allow the pre/post transitions to be isolated and called per-pwrdm, change the API so passing in a specific power domain will trigger the pre/post transtion accounting for only that specific power domain. Passing NULL means iterating over all power domains as is current behavior. Signed-off-by: Kevin Hilman khil...@ti.com Based on a quick glance, it looks good to me: Acked-by: Paul Walmsley p...@pwsan.com Want to queue this one? - 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-V4 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param
On Tue, Apr 24, 2012 at 2:45 AM, Vaibhav Hiremath hvaib...@ti.com wrote: Current OMAP code supports couple of clocksource options based on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz). So there can be 3 options - 1. 32KHz sync-timer 2. Sys_clock based (e.g 13/19.2/26/38.4 MHz) gptimer 3. 32KHz based gptimer. The optional gptimer based clocksource was added so that it can give the high precision than sync-timer, so expected usage was 2 and not 3. Unfortunately option 2, clocksource doesn't meet the requirement of free-running clock as per clocksource need. It stops in low power states when sys_clock is cut. That makes gptimer based clocksource option useless for OMAP2/3/4 devices with sys_clock as a clock input. Option 3 will still work but it is no better than 32K sync-timer based clocksource. So ideally we can kill the gptimer based clocksource option but there are some OMAP based derivative SoCs like AM33XX which doesn't have 32K sync-timer hardware IP and need to fallback on 32KHz based gptimer clocksource. Considering above, make sync-timer and gptimer clocksource runtime selectable so that both OMAP and AM continue to use the same code. Also, in order to precisely configure/setup sched_clock for given clocksource, decision has to be made early enough in boot sequence. So, the solution is, Use kernel parameter (clocksource=) to override default 32k_sync-timer, in addition to this, we also use hwmod database lookup mechanism, through which at run-time we can identify availability of 32k-sync timer on the device, else fall back to gptimer. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Kevin Hilman khil...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com Cc: Tarun Kanti DebBarma tarun.ka...@ti.com Cc: Ming Lei tom.leim...@gmail.com This fails to boot on my Mistral am37x-evm with omap2plus_defconfig ## Booting kernel from Legacy Image at 80007fc0 ... Image Name: Linux-3.4.0-rc3-ktest-11789-gea1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3360576 Bytes = 3.2 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK XIP Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0 [0.00] Linux version 3.4.0-rc3-ktest-11789-gea133e0 (russ@russ-laptop) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #9 SMP Wed Apr 25 21:13:16 MST 2012 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: OMAP3 EVM [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk ) [0.00] Clocking rate (Crystal/Core/MPU): 26.0/400/1000 MHz [0.00] PERCPU: Embedded 8 pages/cpu @c0e0c000 s11456 r8192 d13120 u32768 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 [0.00] Kernel command line: console=ttyO0,115200n8 root=/dev/nfs nfsroot=192.168.1.143:/var/datastore/exports/192.168.1.20,nolock rw ip=dhcp [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Memory: 255MB = 255MB total [0.00] Memory: 246504k/246504k available, 15640k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB) [0.00] lowmem : 0xc000 - 0xd000 ( 256 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .text : 0xc0008000 - 0xc05cced4 (5908 kB) [0.00] .init : 0xc05cd000 - 0xc061acc0 ( 312 kB) [0.00] .data : 0xc061c000 - 0xc06b0cd8 ( 596 kB) [0.00].bss : 0xc06b0cfc - 0xc0c050e0 (5457 kB) [0.00] Hierarchical RCU implementation. [0.00] NR_IRQS:474 [0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96 interrupts [0.00] Total of 96 interrupts on 1 active controller [0.00] OMAP clockevent source: GPTIMER1 at 32768 Hz [0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms [0.00] OMAP clocksource: 32k_counter at 32768 Hz [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ...
Re: [PATCH v9 11/25] gpio/omap: cleanup omap_gpio_mod_init function
On Wed, Apr 25, 2012 at 7:15 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Wed, Apr 25, 2012 at 06:24:14PM +0530, DebBarma, Tarun Kanti wrote: On Wed, Apr 25, 2012 at 12:09 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Wed, Apr 25, 2012 at 10:04 AM, DebBarma, Tarun Kanti tarun.ka...@ti.com wrote: On Tue, Apr 24, 2012 at 9:34 PM, Tony Lindgren t...@atomide.com wrote: * DebBarma, Tarun Kanti tarun.ka...@ti.com [120424 08:40]: Hi Janusz, On Tue, Apr 24, 2012 at 12:24 AM, DebBarma, Tarun Kanti tarun.ka...@ti.com wrote: On Sat, Apr 21, 2012 at 7:33 PM, Janusz Krzysztofik jkrzy...@tis.icnet.pl wrote: On Thursday 02 of February 2012 23:00:37 Tarun Kanti DebBarma wrote: With register offsets now defined for respective OMAP versions we can get rid of cpu_class_* checks. This function now has common initialization code for all OMAP versions... Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com Signed-off-by: Charulatha V ch...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Tony Lindgren t...@atomide.com Sorry for being so late with my comment for chanes already present in mainline, but this patch breaks GPIO on Amstrad Delta at least, and I have neither enough spare time nor enough experience with non OMAP1 machines to provide a solution myself. Yes, I looked at the omap_gpio_mod_init() and OMAP1 configurations are overwritten. Also looks like there is issue in making distinction between omap15xx and omap16xx. I will post a patch and you can help me testing it in OMAP1 platform. Thanks for pointing this out. ... Here is the patch, with attachment as well. I have just tested on OMAP4 platform. Testing on other OMAP2+ platforms is pending. In the meantime can you please validate on OMAP1 platform and confirm? Thanks. -- Tarun From: Tarun Kanti DebBarma tarun.ka...@ti.com Date: Tue, 24 Apr 2012 20:34:32 +0530 Subject: [PATCH] gpio/omap: fix omap1 register overwrite in omap_gpio_mod_init Initialization of irqenable, irqstatus registers is the common operation done in this function for all OMAP platforms, viz. OMAP1, OMAP2+. The latter _gpio_rmw()'s to irqenable register was overwriting the correctly programmed OMAP1 value at the beginning. As a result, even though it worked on OMAP2+ platforms it was breaking OMAP1 functionality. Sounds like the original patch was never tested on omap1? That's right, only bootup test was done on OMAP1710-SDP. On closer observation it is found that the first _gpio_rmw() which is supposedly done to take care of OMAP1 platform is generic enough and takes care of OMAP2+ platform as well. Therefore remove the latter _gpio_rmw() to irqenable as they are redundant. Also, changing the sequence and logic of initializing the irqstatus. Please mention also the breaking commit here and get this fix merged as a regression as soon as it's tested for the current -rc series. Sure, I will do that! Looks like it is regression on 3.4 as well so CC stable when you post the patch. Ok, I will do that. Correction. Don't email your patch in any way to the stable folk _before_ it has been taken into Linus' tree. However, you _may_ add in the patch attributations a Cc: sta...@vger.kernel.org tag if you want the stable folk to automatically pick up your patch when it _does_ end up in Linus' tree. But... make sure that git send-email or whatever doesn't automatically add that to the recipients for the emailed patch. If you send the stable people a patch before its in mainline, you'll get a whinge telling you to read Documentation/stable_kernel_rules.txt Alright, I will add Cc: sta...@vger.kernel.org tag in the patch. Thanks. -- Tarun -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 0/9] Convert OMAP GPMC to driver
Hi Tony, On Wed, Apr 25, 2012 at 22:14:25, Tony Lindgren wrote: Once driver is acceptable, platform code for other peripherals connected via GPMC would be adapted to make use of GPMC driver. And then the board modifications. But before that HWMOD entry has to be populated for respective SoC(s ?). No, we can't do it this way, it breaks things. We need to first convert everything to use the new GPMC driver, then move it. Sorry, my statements were not clear, I meant once driver is acceptable still living in mach-omap2, platform code dealing with peripherals on gpmc would be adapted to make use of gpmc driver. Moving driver to new location is only planned as a separate commit after, before mentioned changes. Hope with this clarification we are on same track. Now DESTINATION FOR THIS DRIVER has to be decided. Original plan was to consider GPMC as MFD. The peripheral(s) connected to GPMC being considered childs of MFD. Let's not put it into MFD. This is a bus driver. But that decision can wait as we cleary have quite a few things to convert first under arch/arm/mach-omap2. Various options that could be seen so far on where this driver can go, 1. mfd 2. misc 3. drivers/platform/arm/ (create an new one?) 4. memory (create a new one ?) It's a parallel bus driver, not memory not misc, not MFD. Greg suggested to send gpmc driver to new memory folder. In the next version, gpmc driver would still be in mach-omap2, moving to new location can be done later. Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3.4-rc3] MTD: NAND: ams-delta: Fix request_mem_region() failure
On Wed, 2012-04-25 at 19:01 +0200, Janusz Krzysztofik wrote: Both drivers use separate subsets of registers that belong to the OMAP1 MPU I/O device, but are used for controlling different sets of I/O pins. The NAND driver reads/writes the folowing registers: - OMAP_MPUIO_INPUT_LATCH, - OMAP_MPUIO_OUTPUT, - OMAP_MPUIO_IO_CNTL, while the keypad driver - the following: - OMAP_MPUIO_KBR_LATCH, - OMAP_MPUIO_KBC, - OMAP_MPUIO_KBD_MASKIT - OMAP_MPUIO_GPIO_DEBOUNCING. Both subsets are non-overlapping, and we rely on the drivers being free of bugs and doing their job correctly, not stepping on each others' feet, I guess. First of all, I think this information should be in the commit message. Also, some sort of comment in the driver code would be nice. If locking the memory region is too coarse approach, the should have a small separate omap-specific MPUIO subsystem which will be used by drivers to access MPUIO? Another question - should request_mem_region() be also removed from the omap-gpio driver then? I think it is more sensible to put a comment there that it is sharing MPIO with other drivers, instead of having an illusion of exclusive memory region ownership. But this is up to the OMAP community - I can take this patch to my l2-mtd tree if you get an ack from Tony or other OMAP guys. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
RE: [TMP] OMAP3EVM: Test gpmc nand smsc911x
Hi Tony, On Wed, Apr 25, 2012 at 22:17:26, Tony Lindgren wrote: Obviously we can't merge any of this if until all the board-*.c files are changed and tested. Can you maybe still keep the old interfaces in addition to the new ones so we can do the conversion one board-*.c file at a time while keeping things working? As there are peripherals using helper functions, to handle those, you meant to create a new altered similar function to deal for each too ?, while keeping existing functions as such. i.e. like having gpmc_smsc911x_init gpmc_smsc911x_new_init for each peripheral ?, with gpmc_smsc911x_new_init using gpmc driver, and gpmc_smsc911x_init as is. Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V4 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param
On Thu, Apr 26, 2012 at 10:06:40, Russ Dill wrote: On Tue, Apr 24, 2012 at 2:45 AM, Vaibhav Hiremath hvaib...@ti.com wrote: Current OMAP code supports couple of clocksource options based on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz). So there can be 3 options - 1. 32KHz sync-timer 2. Sys_clock based (e.g 13/19.2/26/38.4 MHz) gptimer 3. 32KHz based gptimer. The optional gptimer based clocksource was added so that it can give the high precision than sync-timer, so expected usage was 2 and not 3. Unfortunately option 2, clocksource doesn't meet the requirement of free-running clock as per clocksource need. It stops in low power states when sys_clock is cut. That makes gptimer based clocksource option useless for OMAP2/3/4 devices with sys_clock as a clock input. Option 3 will still work but it is no better than 32K sync-timer based clocksource. So ideally we can kill the gptimer based clocksource option but there are some OMAP based derivative SoCs like AM33XX which doesn't have 32K sync-timer hardware IP and need to fallback on 32KHz based gptimer clocksource. Considering above, make sync-timer and gptimer clocksource runtime selectable so that both OMAP and AM continue to use the same code. Also, in order to precisely configure/setup sched_clock for given clocksource, decision has to be made early enough in boot sequence. So, the solution is, Use kernel parameter (clocksource=) to override default 32k_sync-timer, in addition to this, we also use hwmod database lookup mechanism, through which at run-time we can identify availability of 32k-sync timer on the device, else fall back to gptimer. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Kevin Hilman khil...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com Cc: Tarun Kanti DebBarma tarun.ka...@ti.com Cc: Ming Lei tom.leim...@gmail.com This fails to boot on my Mistral am37x-evm with omap2plus_defconfig Thanks Russ, for validating it. But I do not see any relation between your boot process stuck and this patch. What is the observation without these patches? Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V3 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data
Hi,
+/*
+ * clkdiv32 is generated from fixed division of 732.4219
+ */
+static struct clk clkdiv32k_ick = {
+ .name = clkdiv32k_ick,
+ .clkdm_name = clk_24mhz_clkdm,
+ .rate = 32768,
+ .parent = clk_24mhz,
+ .enable_reg = AM33XX_CM_PER_CLKDIV32K_CLKCTRL,
+ .enable_bit = AM33XX_MODULEMODE_SWCTRL,
+ .ops= clkops_omap2_dflt,
+};
While working on this file, this clock seemed quite perplexing. Perhaps
you might be able to answer some questions about it.
- The fractional fixed division seems a little bogus. Is this actually an
M,N counter? A few moments with PARI revealed a likely M,N of 64,46875.
Could you please confirm that this is the case for this clock?
- This clock structure makes this clock appear to be a fixed-frequency
clock. But according to SPRUH73D Figure 8-10 Peripheral PLL Structure,
the divider feeding this clock can be switched between an M,N of 64,46875
and 32,46875 depending on the value of CONTROL_CLK32K_DIVRATIO_CTRL. So
shouldn't we implement that?
- This clock is feeding downstream clocks, but it's using the MODULEMODE
control interface, as if it were a standalone IP block. Do you know why
it's using the MODULEMODE control method rather than some optional clock
control bits, like OMAP4 does?
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V3 2/3] ARM: OMAP3+: clockdomain33xx: Add clockdomain data and respective operations
On Thu, Apr 26, 2012 at 08:49:28, Paul Walmsley wrote:
On Wed, 25 Apr 2012, Hiremath, Vaibhav wrote:
On Wed, Apr 25, 2012 at 05:52:26, Paul Walmsley wrote:
A few questions while reviewing this patch:
On Tue, 3 Apr 2012, Vaibhav Hiremath wrote:
AM33XX PRCM module consist of, various clockdomains, in all
total we have 18 clockdomains available, with following
controlling options,
- NO Sleep: sleep transition can not be initiated,
- SW Sleep: sw forced sleep transition,
- SW Wakeup: sw forced wakeup transition,
- HW Auto: transitions are based upon hw conditions.
This patch adds all available clockdomain data, respective
clockdomain operations for AM33XX family of device, and also
integrates it into existing OMAP framework.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
...
+static struct clockdomain l4ls_am33xx_clkdm = {
+ .name = l4ls_clkdm,
+ .pwrdm = { .name = per_pwrdm },
+ .cm_inst= AM33XX_CM_PER_MOD,
+ .clkdm_offs = AM33XX_CM_PER_L4LS_CLKSTCTRL_OFFSET,
+ .clktrctrl_mask = AM33XX_CLKTRCTRL_MASK,
+ .flags = (CLKDM_CAN_SWSUP | CLKDM_NO_AUTODEPS),
It looks to me like we don't need the .clktrctrl_mask field, since
according to the clockdomains code, the CLKTRCTRL field is at the same
bit
shift for each clockdomain.
Yeah, we actually don't need it, probably I added for completeness.
I will remove it in next version.
I've removed them here.
Thanks.
Also, since we're not defining any autodeps for the AM335x platform, we
shouldn't need the CLKDM_NO_AUTODEPS flag either? Since no autodeps are
defined, the default will be to not set any autodeps.
This is required to avoid few pr_debug, if you don't provide it.
For example, without this flag set, you will get,
pr_debug(clockdomain: hardware cannot set/clear sleep
dependency affecting %s from %s\n, clkdm1-name,
clkdm2-name);
Refer to the file omap_hwmod.c, function, _enable(), the call sequence is,
_enable() = _add_initiator_dep() = clkdm_add_sleepdep() =leads to warning
Seems like the better thing to do is to just avoid calling
_{add,del}_initiator_dep() on the AM335x.
Don't you think, if flag is doing all the job, why to pollute code with
cpu_is_am33xx() checks.
Another question is about the CLKTRCTRL bitfields. According to
_AM335x ARM Cortex-A8 Microprocessors (MPUs) Technical Reference
Manual_ Rev. D (SPRUH73D), most of the clockdomains support NO_SLEEP mode
(i.e., CLKTRCTRL = 0x0). That means that technically, we should also set
the CLKDM_CAN_DISABLE_AUTO flag. Unless the documentation is incorrect
here? In another section (Table 8-9 Clock Transition Mode Settings),
it claims that CLKTRCTRL = 0 is not supported...
It is not supported, and should be considered as documentation issue.
Okay so I guess the description for this patch (quoted above) is wrong
then also?
Yeah, I realized it, after your comment; its copy thing...Will correct in
next version.
Paul,
I am thinking of separating clocktree patch (PATCH-V3 3/3) from this series,
so that clockdomain stuff can get in independently, and clocktree anyway
will follow them (it may take some time in review cycle).
Thanks,
Vaibhav
- 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
[RESEND/PATCHv2] Input: omap-keypad: dynamically handle register offsets
From: G, Manjunath Kondaiah manj...@ti.com
Keypad controller register offsets are different for omap4
and omap5. Handle these offsets through static mapping and
assign these mappings during run time.
Tested on omap4430 sdp with 3.4-rc3.
Tested on omap5430evm with 3.1-custom kernel.
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
Changes since v1:
- Fix Felipe's comment about getting rid
of one argument from irqstatus/irqenable api
- Fix Dmitry's comment:
- get rid of revision check in readl/writel
- Relace ENODEV with proper macro.
- Use switch statement
drivers/input/keyboard/Kconfig|6 +-
drivers/input/keyboard/omap4-keypad.c | 115 ++---
2 files changed, 95 insertions(+), 26 deletions(-)
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index f354813..9a0e1a9 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -511,10 +511,10 @@ config KEYBOARD_OMAP
To compile this driver as a module, choose M here: the
module will be called omap-keypad.
-config KEYBOARD_OMAP4
- tristate TI OMAP4 keypad support
+config KEYBOARD_OMAP4+
+ tristate TI OMAP4+ keypad support
help
- Say Y here if you want to use the OMAP4 keypad.
+ Say Y here if you want to use the OMAP4+ keypad.
To compile this driver as a module, choose M here: the
module will be called omap4-keypad.
diff --git a/drivers/input/keyboard/omap4-keypad.c
b/drivers/input/keyboard/omap4-keypad.c
index e809ac0..8e46563 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -68,6 +68,11 @@
#define OMAP4_MASK_IRQSTATUSDISABLE0x
+enum {
+ KBD_REVISION_OMAP4 = 0,
+ KBD_REVISION_OMAP5,
+};
+
struct omap4_keypad {
struct input_dev *input;
@@ -76,11 +81,61 @@ struct omap4_keypad {
unsigned int rows;
unsigned int cols;
+ unsigned int revision;
+ u32 irqstatus;
+ u32 irqenable;
+ u32 reg_offset;
unsigned int row_shift;
unsigned char key_state[8];
unsigned short keymap[];
};
+static int kbd_read_irqstatus(struct omap4_keypad *keypad_data, u32 offset)
+{
+ return __raw_readl(keypad_data-base + offset);
+}
+
+static int kbd_write_irqstatus(struct omap4_keypad *keypad_data,
+ u32 value)
+{
+ return __raw_writel(value, keypad_data-base + keypad_data-irqstatus);
+}
+
+static int kbd_write_irqenable(struct omap4_keypad *keypad_data,
+ u32 value)
+{
+ return __raw_writel(value, keypad_data-base + keypad_data-irqenable);
+}
+
+static int kbd_readl(struct omap4_keypad *keypad_data, u32 offset)
+{
+ return __raw_readl(keypad_data-base +
+ keypad_data-reg_offset + offset);
+}
+
+static void kbd_writel(struct omap4_keypad *keypad_data, u32 offset, u32 value)
+{
+ __raw_writel(value, keypad_data-base +
+ keypad_data-reg_offset + offset);
+}
+
+static int kbd_read_revision(struct omap4_keypad *keypad_data, u32 offset)
+{
+ int reg;
+ reg = __raw_readl(keypad_data-base + offset);
+ reg = 0x03 30;
+ reg = 30;
+
+ switch (reg) {
+ case 1:
+ return KBD_REVISION_OMAP5;
+ case 0:
+ return KBD_REVISION_OMAP4;
+ default:
+ return -EINVAL;
+ }
+}
+
/* Interrupt handler */
static irqreturn_t omap4_keypad_interrupt(int irq, void *dev_id)
{
@@ -91,12 +146,10 @@ static irqreturn_t omap4_keypad_interrupt(int irq, void
*dev_id)
u32 *new_state = (u32 *) key_state;
/* Disable interrupts */
- __raw_writel(OMAP4_VAL_IRQDISABLE,
-keypad_data-base + OMAP4_KBD_IRQENABLE);
+ kbd_write_irqenable(keypad_data, OMAP4_VAL_IRQDISABLE);
- *new_state = __raw_readl(keypad_data-base + OMAP4_KBD_FULLCODE31_0);
- *(new_state + 1) = __raw_readl(keypad_data-base
- + OMAP4_KBD_FULLCODE63_32);
+ *new_state = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE31_0);
+ *(new_state + 1) = kbd_readl(keypad_data, OMAP4_KBD_FULLCODE63_32);
for (row = 0; row keypad_data-rows; row++) {
changed = key_state[row] ^ keypad_data-key_state[row];
@@ -121,12 +174,12 @@ static irqreturn_t omap4_keypad_interrupt(int irq, void
*dev_id)
sizeof(keypad_data-key_state));
/* clear pending interrupts */
- __raw_writel(__raw_readl(keypad_data-base + OMAP4_KBD_IRQSTATUS),
- keypad_data-base + OMAP4_KBD_IRQSTATUS);
+ kbd_write_irqstatus(keypad_data,
+ kbd_read_irqstatus(keypad_data,
Re: [PATCH-V4 3/3] ARM: OMAP: Make OMAP clocksource source selection using kernel param
On Wed, Apr 25, 2012 at 10:42 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Thu, Apr 26, 2012 at 10:06:40, Russ Dill wrote: On Tue, Apr 24, 2012 at 2:45 AM, Vaibhav Hiremath hvaib...@ti.com wrote: Current OMAP code supports couple of clocksource options based on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz). So there can be 3 options - 1. 32KHz sync-timer 2. Sys_clock based (e.g 13/19.2/26/38.4 MHz) gptimer 3. 32KHz based gptimer. The optional gptimer based clocksource was added so that it can give the high precision than sync-timer, so expected usage was 2 and not 3. Unfortunately option 2, clocksource doesn't meet the requirement of free-running clock as per clocksource need. It stops in low power states when sys_clock is cut. That makes gptimer based clocksource option useless for OMAP2/3/4 devices with sys_clock as a clock input. Option 3 will still work but it is no better than 32K sync-timer based clocksource. So ideally we can kill the gptimer based clocksource option but there are some OMAP based derivative SoCs like AM33XX which doesn't have 32K sync-timer hardware IP and need to fallback on 32KHz based gptimer clocksource. Considering above, make sync-timer and gptimer clocksource runtime selectable so that both OMAP and AM continue to use the same code. Also, in order to precisely configure/setup sched_clock for given clocksource, decision has to be made early enough in boot sequence. So, the solution is, Use kernel parameter (clocksource=) to override default 32k_sync-timer, in addition to this, we also use hwmod database lookup mechanism, through which at run-time we can identify availability of 32k-sync timer on the device, else fall back to gptimer. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Kevin Hilman khil...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com Cc: Tarun Kanti DebBarma tarun.ka...@ti.com Cc: Ming Lei tom.leim...@gmail.com This fails to boot on my Mistral am37x-evm with omap2plus_defconfig Thanks Russ, for validating it. But I do not see any relation between your boot process stuck and this patch. What is the observation without these patches? With no patches applied it boots, with 1/3 applied it boots, with 2/3 applied it boots, with 3/3 applied it gets hung. I also tested on my beagleboard b4, that booted fine. -- 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
