RE: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support
Sorry for the format. Emailing from webmail.
From: Daniel Lezcano [daniel.lezc...@linaro.org]
Sent: Wednesday, September 17, 2014 2:49 PM
To: Menon, Nishanth; Shilimkar, Santosh; Tony Lindgren; Kristo, Tero; Paul
Walmsley
Cc: Kevin Hilman; linux-arm-ker...@lists.infradead.org;
linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; J, KEERTHY; Benoît
Cousson
Subject: Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support
On 08/22/2014 07:02 AM, Nishanth Menon wrote:
From: Santosh Shilimkar santosh.shilim...@ti.com
Add OMAP5/DRA74/72 CPUIDLE support.
This patch adds MPUSS low power states in cpuidle.
C1 - CPU0 WFI + CPU1 WFI + MPU ON
C2 - CPU0 RET + CPU1 RET + MPU CSWR
Tested on DRA74/72-EVM for C1 and C2 states.
NOTE: DRA7 does not do voltage scaling as part of retention transition
and has Mercury which speeds up transition paths - Latency numbers are
based on measurements done by toggling GPIOs.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
[ j-keer...@ti.com rework on 3.14]
Signed-off-by: Keerthy j-keer...@ti.com
[n...@ti.com: updates based on profiling, OMAP5 squashed]
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/mach-omap2/cpuidle44xx.c | 82
-
arch/arm/mach-omap2/pm44xx.c |2 +-
2 files changed, 82 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 2498ab0..8ad4f44 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -22,6 +22,7 @@
#include common.h
#include pm.h
#include prm.h
+#include soc.h
#include clockdomain.h
#define MAX_CPUS2
@@ -31,6 +32,7 @@ struct idle_statedata {
u32 cpu_state;
u32 mpu_logic_state;
u32 mpu_state;
+ u32 mpu_state_vote;
};
static struct idle_statedata omap4_idle_data[] = {
@@ -51,12 +53,26 @@ static struct idle_statedata omap4_idle_data[] = {
},
};
+static struct idle_statedata dra7_idle_data[] = {
+ {
+ .cpu_state = PWRDM_POWER_ON,
+ .mpu_state = PWRDM_POWER_ON,
+ .mpu_logic_state = PWRDM_POWER_ON,
+ },
+ {
+ .cpu_state = PWRDM_POWER_RET,
+ .mpu_state = PWRDM_POWER_RET,
+ .mpu_logic_state = PWRDM_POWER_RET,
+ },
+};
+
static struct powerdomain *mpu_pd, *cpu_pd[MAX_CPUS];
static struct clockdomain *cpu_clkdm[MAX_CPUS];
static atomic_t abort_barrier;
static bool cpu_done[MAX_CPUS];
static struct idle_statedata *state_ptr = omap4_idle_data[0];
+static DEFINE_RAW_SPINLOCK(mpu_lock);
/* Private functions */
@@ -78,6 +94,32 @@ static int omap_enter_idle_simple(struct cpuidle_device
*dev,
return index;
}
+static int omap_enter_idle_smp(struct cpuidle_device *dev,
+struct cpuidle_driver *drv,
+int index)
+{
+ struct idle_statedata *cx = state_ptr + index;
+ unsigned long flag;
+
+ raw_spin_lock_irqsave(mpu_lock, flag);
Why do you need this spin_lock_irqsave ? Aren't the local irqs already
disabled ?
[Santosh] Actually at one point of time before the idle consolidation the local
irq disable was inside the idle drivers. Now with that moved to core layer,
I think plain spin_lock/unlock() should work.
+ cx-mpu_state_vote++;
+ if (cx-mpu_state_vote == num_online_cpus()) {
+ pwrdm_set_logic_retst(mpu_pd, cx-mpu_logic_state);
+ omap_set_pwrdm_state(mpu_pd, cx-mpu_state);
+ }
+ raw_spin_unlock_irqrestore(mpu_lock, flag);
+
+ omap4_enter_lowpower(dev-cpu, cx-cpu_state);
+
+ raw_spin_lock_irqsave(mpu_lock, flag);
+ if (cx-mpu_state_vote == num_online_cpus())
+ omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
+ cx-mpu_state_vote--;
+ raw_spin_unlock_irqrestore(mpu_lock, flag);
I am not sure that will work. What happens if a cpu exits idle and then
re-enter idle immediately ?
[Santosh] It works and that case is already taken care. CPU exist the idle and
then votes
out for cluster state and if it reenters with the right targeted state, the
cluster state would
be picked.
Could you try a long run of this little program:
https://git.linaro.org/power/pm-qa.git/blob/HEAD:/cpuidle/cpuidle_killer.c
[Santosh] I am sure there will not be any issue with the long run test case
here.
Lets see if Nishant sees anything otherwise
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 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support
From: Daniel Lezcano [daniel.lezc...@linaro.org]
Sent: Wednesday, September 17, 2014 8:22 PM
To: Shilimkar, Santosh; Menon, Nishanth; Tony Lindgren; Kristo, Tero; Paul
Walmsley
Cc: Kevin Hilman; linux-arm-ker...@lists.infradead.org;
linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; J, KEERTHY; Benoît
Cousson
Subject: Re: [PATCH 08/10] ARM: OMAP5/DRA7: PM: cpuidle MPU CSWR support
On 09/17/2014 04:20 PM, Shilimkar, Santosh wrote:
Sorry for the format. Emailing from webmail.
[ ... ]
+ cx-mpu_state_vote++;
+ if (cx-mpu_state_vote == num_online_cpus()) {
+ pwrdm_set_logic_retst(mpu_pd, cx-mpu_logic_state);
+ omap_set_pwrdm_state(mpu_pd, cx-mpu_state);
+ }
+ raw_spin_unlock_irqrestore(mpu_lock, flag);
+
+ omap4_enter_lowpower(dev-cpu, cx-cpu_state);
+
+ raw_spin_lock_irqsave(mpu_lock, flag);
+ if (cx-mpu_state_vote == num_online_cpus())
+ omap_set_pwrdm_state(mpu_pd, PWRDM_POWER_ON);
+ cx-mpu_state_vote--;
+ raw_spin_unlock_irqrestore(mpu_lock, flag);
I am not sure that will work. What happens if a cpu exits idle and then
re-enter idle immediately ?
[Santosh] It works and that case is already taken care. CPU exist the idle
and then votes
out for cluster state and if it reenters with the right targeted state, the
cluster state would
be picked.
It isn't possible to have one cpu disabling the coherency, while the
other one is looking for a lock ? Or eg. cpu0 is on WFI then cpu1 is the
last entering idle. While cpu1 is entering 'lowpower', cpu0 exits the
wfi check the state vote and set the power domain on. In the meantime
cpu1 disables the coherency and cpu0 decrease the vote and release the
lock. Could be possible there is a very small racy window here ?
[Santosh] The coherency isn't disable by CPU. Thats actually taken care by
hardware. CPU takes it own power domain down and takes itself out of
coherency. The Coherency is always ON as long as there is a CPU ON
and SMP bit on that CPU is enabled.
The scenario, you mentioned can never happen on this hardware thanks
to the inbuilt smart hardware.
If you have more questions, lets discuss. I am around here at connect. ;-)
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 0/2] ARM: OMAP: dmtimers improvements.
Sorry for top posting Probably we should move the dmtimer to drivers/misc or create drivers/timer/ This has been pending for quite some time now Tony, what you say ? From: linux-arm-kernel [linux-arm-kernel-boun...@lists.infradead.org] on behalf of NeilBrown [ne...@suse.de] Sent: Thursday, October 24, 2013 2:57 AM To: Tony Lindgren; Russell King Cc: Belisko Marek; linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Dr. H. Nikolaus Schaller Subject: [PATCH 0/2] ARM: OMAP: dmtimers improvements. I would like to use omap dmtimer for a PWM driver (for the backlight on my display). But there are two difficulties. Unfortunately Jon Hunter (who has helped me with dmtimers before) seems to have disappeared. So I guess I get to do it myself :-) Following two patches make dmtimers more usable. 1/ allow the counter to be set even when the timer isn't counting. 2/ move the include file to a more useful location Any help you can provide in getting these fixes upstream would be appreciated. Thanks, NeilBrown --- NeilBrown (2): ARM: OMAP2+: dmtimer: allow counter to be set at any time. ARM: OMAP: move dmtimer.h from plat-omap/include/plat to include/linux arch/arm/mach-omap1/pm.c |2 arch/arm/mach-omap1/timer.c|2 arch/arm/mach-omap2/omap_hwmod_2420_data.c |2 arch/arm/mach-omap2/omap_hwmod_2430_data.c |2 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |2 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 arch/arm/mach-omap2/omap_hwmod_54xx_data.c |2 arch/arm/mach-omap2/omap_hwmod_7xx_data.c |2 arch/arm/mach-omap2/timer.c|2 arch/arm/plat-omap/dmtimer.c | 11 - arch/arm/plat-omap/include/plat/dmtimer.h | 415 drivers/media/rc/ir-rx51.c |2 drivers/pwm/pwm-omap.c |2 drivers/staging/tidspbridge/core/dsp-clock.c |2 include/linux/omap-dmtimer.h | 415 16 files changed, 434 insertions(+), 433 deletions(-) delete mode 100644 arch/arm/plat-omap/include/plat/dmtimer.h create mode 100644 include/linux/omap-dmtimer.h -- Signature ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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 1/2] gpio/omap: don't create an IRQ mapping for every GPIO on DT
(Sorry for the top posting) Linus, Auto request GPIO as an input line when used as IRQ line for DT case has been broken and we did discuss the issue on couple of threads. Javier's intermediate approach with $subject series was addressing this long standing issue. But while fixing that case, unfortunately breaks another case as highlighted by Alexander. I think the default OMAP DT files will continue to work with these patches applied and mostly doesn't break anything in default configuration. Ofcourse with the DT modification as done by Alexander will expose the issue. So either case we will something broken. I really wanted to have the auto request GPIO supported when used as IRQ line but surely not at expense of breaking the client drivers. So I am fine with whatever you decide. Regards, Santosh From: Linus Walleij [linus.wall...@linaro.org] Sent: Sunday, July 28, 2013 10:11 AM To: Alexander Holler Cc: ext Tony Lindgren; Grant Likely; Shilimkar, Santosh; Kevin Hilman; Javier Martinez Canillas; Jon Hunter; Jean-Christophe PLAGNIOL-VILLARD; Enric Balletbo Serra; Linux-OMAP; Florian Vaussard; Aaro Koskinen; Krishnamoorthy, Balaji T Subject: Re: [PATCH v4 1/2] gpio/omap: don't create an IRQ mapping for every GPIO on DT On Sun, Jul 28, 2013 at 2:59 PM, Alexander Holler hol...@ahsoftware.de wrote: Am 28.07.2013 13:14, schrieb Linus Walleij: What shall we do with this mess now? (...) Hmm, maybe something which adds a mapping for a IRQ when gpio_to_irq() is called would help. I think this bug is pointing back to my initial remark that we need to flag, in the DT node for each GPIOchip that provides auto-IRQs exactly which IRQ lines that will be used as simple IRQ lines. This is what I called GPIO hogs a while back. If this had been done, gpio_request_one() would *only* have been called on the GPIOs marked as being used for IRQs simply. And we wouldn't have had this bug. I am leaning towards reverting the whole shebang right now, and using that as an argument to hammer in my opinion that we need to do it my way unless something incredibly clever comes up. Yours, Linus Walleij -- 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 14/14] ARM: OMAP4: hwmod data: Clean up the data file
Sorry for top posting. We should still drop the IRQ data for those devices and only retain DMA data in that case. Tony, can you please refresh your commit so that IRQ data is dropped from those devices ? Regards, Santosh From: Tony Lindgren [t...@atomide.com] Sent: Saturday, June 08, 2013 12:57 PM To: R, Sricharan Cc: Shilimkar, Santosh; Paul Walmsley; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Nayak, Rajendra; Cousson, Benoit; Kristo, Tero; K, Ambresh Subject: Re: [PATCH V2 14/14] ARM: OMAP4: hwmod data: Clean up the data file * Sricharan R r.sricha...@ti.com [130608 09:52]: On Saturday 08 June 2013 12:14 AM, Santosh Shilimkar wrote: On Friday 07 June 2013 02:37 PM, Tony Lindgren wrote: Looking at the diff output with and without, it seems to be that the DMA channels won't get configured. That should work since DMA engine changes are in mainline and the DMA channel information is already in DT. The issue is that mmc, spi drivers try to get the 'dma' request number from get_platform_resource, which fails if hwmod has not populated the data. There are patches already from Balaji [1] for hsmmc, Matt Porter [2] mcspi for adapting the drivers for Dma engine. Dma engine gets the data from DT. [1] http://comments.gmane.org/gmane.linux.kernel.mmc/20378 [2] http://www.spinics.net/lists/linux-omap/msg87634.html [1] is already in mmc-next for 3.10 branch. Then one more patch for spi [3] is required for completing this. This is similar to the patch done for mmc to skip the get_platform_resource call in case of DT. [3] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg90112.html OK thanks for looking into that. Once those driver changes hit mainline, please send a follow-up patch to remove the spi and mmc entries. 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: OMAP5: select SCU
Sorry for top posting. Can you just add static inlines functions in header file and #ifdef it for OMAP5. Regards, Santosh From: Stehle, Vincent Sent: Thursday, May 16, 2013 7:59 PM To: Shilimkar, Santosh Cc: Vincent Stehlé; Tony Lindgren; linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org Subject: Re: [PATCH] ARM: OMAP5: select SCU So the exact commit breaking OMAP5 link for me is: 883a106 ARM: default machine descriptor for multiplatform The breakage seems to be a side effect of not selecting ARCH_VEXPRESS any more, which causes HAVE_ARM_SCU to not be selected any more, too, when compiling only for OMAP5. IMHO this only reveals a deeper issue. Probably the ideal fix would be to remove all references to the scu_ functions for OMAP5, but those seem to exist in files and functions, common to OMAP4 and 5 (sleep44xx.S, omap-smp.c). How would you deal with that, please? Best regards, V. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [GIT PULL] ARM: OMAP2+: Generic cleanups for 3.10
Sorry for top posting ... I will pick the ack and update commit log to prepare new pull request for you. Regards, Santosh From: Tony Lindgren [t...@atomide.com] Sent: Thursday, March 28, 2013 1:28 AM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [GIT PULL] ARM: OMAP2+: Generic cleanups for 3.10 * Santosh Shilimkar santosh.shilim...@ti.com [130327 12:08]: On Wednesday 27 March 2013 11:33 PM, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [130320 01:42]: Tony, Here is the pull request for various OMAP cleanups and fixes which are posted earlier on the list. It contains OMAP4 smp cleanup, removal of unwanted static deps from OMAP4, RAM offset consolidation and fiq tuple cleanup. The following changes since commit a937536b868b8369b98967929045f1df54234323: Linux 3.9-rc3 (2013-03-17 15:59:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.10/omap_generic_cleanup for you to fetch changes up to 37e1f64c3bc2b3455a9688de8527a341847b3ad9: ARM: OMAP4: Fix the init code to have OMAP4460 errata available in DT build (2013-03-19 12:57:30 +0530) Thanks pulled this into omap-for-v3.10/cleanup. Thanks Tony !! Hmm looks like Kevin had some good comments and acks, can you please update and send a new pull req? I'll set up cleanup-v2 branch when those are available. 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: OMAP4460/PandaES: hang during resume
On Wed, Oct 3, 2012 at 5:05 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Hi Santosh, Tero, I just added my 4460/PandaES to my board farm for automated PM testing and see that basic suspend/resume tests don't work in mainline. It fails on v3.6 and linux-next,arm-soc/for-next. Adding 'no_console_suspend' to the cmdline shows me that wakeup event is happening so the hang is somewhere during resume. I haven't dug any deeper than that. This works fine on 4430/Panda. Do you know of anything else we're missing in mainline for a basic suspend/resume test on 4430? OMAP4460 has one ROM code BUG which impacts MPUSS OSWR. I suspect you are missing that Errata WA. You need a patch [1] which is in Tero's CORE RET series. Regards Santosh [1] https://patchwork.kernel.org/patch/1216671/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] ARM: OMAP: Move omap_reserve() locally to mach-omap1/2
On Sun, Sep 30, 2012 at 1:09 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Sep 28, 2012 at 07:10:08PM +0530, Lokesh Vutla wrote:
omap_reserve() is a stub for omap1. So creating a
stub locally in mach-omap1. And moving the definition
to mach-omap2.
This helps in moving plat/omap_secure.h local to
mach-omap2
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Acked-by : Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap1/common.h |3 +++
arch/arm/mach-omap2/common.c | 20
arch/arm/mach-omap2/common.h |1 +
arch/arm/plat-omap/common.c | 17 -
arch/arm/plat-omap/include/plat/common.h |1 -
5 files changed, 24 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap1/common.h b/arch/arm/mach-omap1/common.h
index c2552b2..f7b01f1 100644
--- a/arch/arm/mach-omap1/common.h
+++ b/arch/arm/mach-omap1/common.h
@@ -90,4 +90,7 @@ extern int ocpi_enable(void);
static inline int ocpi_enable(void) { return 0; }
#endif
+static inline void omap_reserve(void)
+{ }
This is the wrong approach. If OMAP1 doesn't need to do any reservation,
then OMAP1 platforms should not be calling omap_reserve() and OMAP1 should
not have this defined.
Just because OMAP2 does something one way does not mean OMAP1 needs to
copy it in every detail.
This patch just updated the code as is. I mean the empty reserve
callback already
exist before this patch.
But I do agree with you. I think we can drop the reserve callback completly from
OMAP1 board files and then its easier to just make the omap_reserve() local to
OMAP2+ machines.
Tony,
Are you ok in dropping OMAP1 reserve callback from all OMAP1 machines ?
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 V2] ARM: OMAP2+: Round of the carve out memory requested to section_size
On Wed, Sep 12, 2012 at 12:44 PM, R Sricharan r.sricha...@ti.com wrote: memblock_steal tries to reserve physical memory during boot. When the requested size is not aligned on the section size then, the remaining memory available for lowmem becomes unaligned on the section boundary. There is a issue with this, which is discussed in the thread below. https://lkml.org/lkml/2012/6/28/112 The final conclusion from the thread seems to be align the memblock_steal calls on the SECTION boundary. The issue comes out when LPAE is enabled, where the section size is 2MB. Boot tested this on OMAP5 evm with and without LPAE. Signed-off-by: R Sricharan r.sricha...@ti.com --- [V2] Corrected the subject and added one more description line. Looks good. Acked-by : Santosh Shilimkar santosh.shilim...@ti.com Tony, Can you take this into your next fixes-noncritical queue please ? 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
linux-next ASOC build break ? (Was... Re: Help needed with remaining plat headers)
+ Peter, Liam in case they haven't seen the issue yet. On Fri, Sep 28, 2012 at 12:28 PM, Vutla, Lokesh lokeshvu...@ti.com wrote: Hi, I see a module build failure in linux-next tree. Any one else facing this issue or I am missing something. Using master branch on git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Below is the log . $ make modules -j 10 CHK include/linux/version.h CHK include/generated/utsrelease.h LD [M] drivers/video/omap2/dss/omapdss.o Building modules, stage 2. [..] MODPOST 45 modules ERROR: snd_hwparams_to_dma_slave_config [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_pointer [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_open [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_close [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_get_chan [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_trigger [sound/soc/omap/snd-soc-omap.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 -- 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/4] ARM: OMAP: DMA: Move plat/dma hearder to platform_data/dma-omap
On Fri, Sep 28, 2012 at 8:25 PM, Tony Lindgren t...@atomide.com wrote: * Lokesh Vutla lokeshvu...@ti.com [120928 06:41]: Move plat/dma.h header to platform_data/dma-omap.h as part of the single zImage work. Hmm there's no platform data in this header, just exported things for drivers to use. So it should not be placed into platform_data. Maybe it should be #include asm/mach/dma-omap.h for now? I wasn't sure either when the file was placed under platform-data. I agree for now we can keep it mach layer but than means OMAP1 and OMAP2+ DMA header and source code needs to be split. That is not so straight forward. With DMA engine conversion hopefully, we might get rid of the header eventually, but for now not sure whether we should go ahead and follow the splitting part. Thoughts ? 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/4] ARM: OMAP: DMA: Move plat/dma hearder to platform_data/dma-omap
On Fri, Sep 28, 2012 at 8:35 PM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120928 08:02]: On Fri, Sep 28, 2012 at 8:25 PM, Tony Lindgren t...@atomide.com wrote: * Lokesh Vutla lokeshvu...@ti.com [120928 06:41]: Move plat/dma.h header to platform_data/dma-omap.h as part of the single zImage work. Hmm there's no platform data in this header, just exported things for drivers to use. So it should not be placed into platform_data. Maybe it should be #include asm/mach/dma-omap.h for now? I wasn't sure either when the file was placed under platform-data. I agree for now we can keep it mach layer but than means OMAP1 and OMAP2+ DMA header and source code needs to be split. That is not so straight forward. No need for that, the path I'm suggesting is located under arch/arm/include/asm/mach, it's not same as include mach/dma-omap.h. That sound ok. With DMA engine conversion hopefully, we might get rid of the header eventually, but for now not sure whether we should go ahead and follow the splitting part. Thoughts ? No need for splitting anything :) The other possible location would be just include linux/dma-omap.h, but as we all know that will be going away, asm/mach/dma-omap.h is probably better. Agree. I missed the arch/arm/include/asm/mach path. Thanks. 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: Help needed with remaining plat headers
On Fri, Sep 28, 2012 at 1:56 AM, Tony Lindgren t...@atomide.com wrote: Please see below a status update on the remaining problem plat headers. Note that all patches should be against current linux next in this case. * Tony Lindgren t...@atomide.com [120920 16:30]: $ ls arch/arm/plat-omap/include/plat/ [..] omap-secure.h Will work with Lokesh to get this one sorted out along with dma. It can be made local to mach-omap2. 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: rcu self-detected stall messages on OMAP3, 4 boards
On Sun, Sep 23, 2012 at 3:29 AM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: On Sat, Sep 22, 2012 at 01:10:43PM -0700, Paul E. McKenney wrote: On Sat, Sep 22, 2012 at 06:42:08PM +, Paul Walmsley wrote: On Fri, 21 Sep 2012, Paul E. McKenney wrote: [...] And here is a patch. I am still having trouble reproducing the problem, but figured that I should avoid serializing things. Thanx, Paul b/kernel/rcutree.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) rcu: Fix day-one dyntick-idle stall-warning bug Each grace period is supposed to have at least one callback waiting for that grace period to complete. However, if CONFIG_NO_HZ=n, an extra callback-free grace period is no big problem -- it will chew up a tiny bit of CPU time, but it will complete normally. In contrast, CONFIG_NO_HZ=y kernels have the potential for all the CPUs to go to sleep indefinitely, in turn indefinitely delaying completion of the callback-free grace period. Given that nothing is waiting on this grace period, this is also not a problem. Unless RCU CPU stall warnings are also enabled, as they are in recent kernels. In this case, if a CPU wakes up after at least one minute of inactivity, an RCU CPU stall warning will result. The reason that no one noticed until quite recently is that most systems have enough OS noise that they will never remain absolutely idle for a full minute. But there are some embedded systems with cut-down userspace configurations that get into this mode quite easily. All this begs the question of exactly how a callback-free grace period gets started in the first place. This can happen due to the fact that CPUs do not necessarily agree on which grace period is in progress. If a CPU still believes that the grace period that just completed is still ongoing, it will believe that it has callbacks that need to wait for another grace period, never mind the fact that the grace period that they were waiting for just completed. This CPU can therefore erroneously decide to start a new grace period. Once this CPU notices that the earlier grace period completed, it will invoke its callbacks. It then won't have any callbacks left. If no other CPU has any callbacks, we now have a callback-free grace period. This commit therefore makes CPUs check more carefully before starting a new grace period. This new check relies on an array of tail pointers into each CPU's list of callbacks. If the CPU is up to date on which grace periods have completed, it checks to see if any callbacks follow the RCU_DONE_TAIL segment, otherwise it checks to see if any callbacks follow the RCU_WAIT_TAIL segment. The reason that this works is that the RCU_WAIT_TAIL segment will be promoted to the RCU_DONE_TAIL segment as soon as the CPU figures out that the old grace period has ended. This change is to cpu_needs_another_gp(), which is called in a number of places. The only one that really matters is in rcu_start_gp(), where the root rcu_node structure's -lock is held, which prevents any other CPU from starting or completing a grace period, so that the comparison that determines whether the CPU is missing the completion of a grace period is stable. Signed-off-by: Paul E. McKenney paul.mcken...@linaro.org Signed-off-by: Paul E. McKenney paul...@linux.vnet.ibm.com As already confirmed by Paul W and others, I too no longer see the rcu dumps any more with above patch. Thanks a lot for the fix. 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: OMAP baseline test results for v3.6-rc4
On Sun, Sep 23, 2012 at 12:01 AM, Paul Walmsley p...@pwsan.com wrote: cc Santosh Hi Igor, I regret the delay in responding, On Fri, 7 Sep 2012, Igor Grinberg wrote: On 09/05/12 18:44, Paul Walmsley wrote: * CM-T3517: L3 in-band error with USB OTG during boot - Cause unknown; longstanding issue; does not occur on the 3517EVM We see this problem on several cm-t3517, but not all of them. There's probably a dependency on the bootloader or X-Loader. It looks something like: cut NET: Registered protocol family 16 GPMC revision 5.0 gpmc: irq-20 could not claim: err -22 OMAP GPIO hardware version 2.5 In-band Error seen by USB_OTG at address 0 That tag USB_OTG above isn't 100% accurate for AM3517/3505, by the way. omap_l3_smx.c doesn't have a correct initiator map for those chips. The offender could be USBOTG, but it could also be any other initiator in the IP subsystem, such as Camera/VPFE or EMAC. Table 5-18 InitiatorID Definition in the AM35x TRM vB (SPRUGR0B) lists these. That is possible. Will have a look at AMXX initiator map. As far as I know, the message means that some module in the IPSS tried to initiate an L3 interconnect transaction, but that it failed. Probably the IPSS isn't clocked. In-band error is reported to an initiator typically for the out of band access. Probably address space is not accessible either because the IP(ISS) as per Pauls TRM decoding either still not out of reset or not clocked yet. If the clocking itself was the issue at least address space should have been valid and there I expect a different error. [ cut here ] WARNING: at /home/lifshitz/workroot/git-repo/linux-cm-t3x/arch/arm/mach-omap2/omap_l3_smx.c:162 omap3_l3_app_irq+0xdc/0x120() Modules linked in: [c001ad08] (unwind_backtrace+0x0/0xf4) from [c003f670] (warn_slowpath_common+0x4c/0x64) [c003f670] (warn_slowpath_common+0x4c/0x64) from [c003f6a4] (warn_slowpath_null+0x1c/0x24) [c003f6a4] (warn_slowpath_null+0x1c/0x24) from [c0033af0] (omap3_l3_app_irq+0xdc/0x120) [c0033af0] (omap3_l3_app_irq+0xdc/0x120) from [c008b8bc] (handle_irq_event_percpu+0xac/0x298) [c008b8bc] (handle_irq_event_percpu+0xac/0x298) from [c008bafc] (handle_irq_event+0x54/0x74) [c008bafc] (handle_irq_event+0x54/0x74) from [c008e290] (handle_level_irq+0xc4/0x118) [c008e290] (handle_level_irq+0xc4/0x118) from [c008b3ac] (generic_handle_irq+0x2c/0x44) [c008b3ac] (generic_handle_irq+0x2c/0x44) from [c001500c] (handle_IRQ+0x60/0x80) [c001500c] (handle_IRQ+0x60/0x80) from [c00085ec] (omap3_intc_handle_irq+0x60/0x74) [c00085ec] (omap3_intc_handle_irq+0x60/0x74) from [c04e3100] (__irq_svc+0x40/0x74) Exception stack(0xcf02de00 to 0xcf02de48) de00: 000a 0021 c074bcac cf046280 000a 6013 de20: c074bcdc c070020c 0001 cf02de48 c008c988 de40: 4013 [c04e3100] (__irq_svc+0x40/0x74) from [c008c988] (__setup_irq+0x2a8/0x404) [c008c988] (__setup_irq+0x2a8/0x404) from [c008cd18] (request_threaded_irq+0xe8/0x13c) [c008cd18] (request_threaded_irq+0xe8/0x13c) from [c06c3d24] (omap3_l3_probe+0x10c/0x16c) [c06c3d24] (omap3_l3_probe+0x10c/0x16c) from [c033586c] (platform_drv_probe+0x18/0x1c) [c033586c] (platform_drv_probe+0x18/0x1c) from [c0334414] (really_probe+0xac/0x1c8) [c0334414] (really_probe+0xac/0x1c8) from [c0334578] (driver_probe_device+0x48/0x60) [c0334578] (driver_probe_device+0x48/0x60) from [c03345f0] (__driver_attach+0x60/0x84) [c03345f0] (__driver_attach+0x60/0x84) from [c0332ce0] (bus_for_each_dev+0x4c/0x80) [c0332ce0] (bus_for_each_dev+0x4c/0x80) from [c0333414] (bus_add_driver+0xa4/0x294) [c0333414] (bus_add_driver+0xa4/0x294) from [c0334bdc] (driver_register+0xa4/0x188) [c0334bdc] (driver_register+0xa4/0x188) from [c0335c5c] (platform_driver_probe+0x18/0x98) [c0335c5c] (platform_driver_probe+0x18/0x98) from [c0008798] (do_one_initcall+0xac/0x16c) [c0008798] (do_one_initcall+0xac/0x16c) from [c06b52ac] (do_basic_setup+0x88/0xc0) [c06b52ac] (do_basic_setup+0x88/0xc0) from [c06b53c4] (kernel_init+0x60/0xfc) [c06b53c4] (kernel_init+0x60/0xfc) from [c00150a4] (kernel_thread_exit+0x0/0x8) ---[ end trace 1b75b31a2719ed1c ]--- -cut--- After that, the board continues to function properly. Any hints how to debug this? Probably the core problem is that we don't yet have the IPSS correctly supported in the AM35xx hwmod data. This is partially due to the fact that we're missing hierarchical enables/disables in that code, a longstanding omission. My guess is that if you hacked in some code to enable the IPSS early in boot (see the CONTROL_IPSS_CLK_CTRL register), the problem would probably go away. I suspect, the module MPU is trying to access is still not out of reset which
Re: CPU_IDLE causes random reboots on custom 4430
On Sat, Sep 22, 2012 at 10:41 PM, Chris Hoffmann chrmhoffm...@gmail.com wrote: On 09/22/2012 07:45 AM, Shilimkar, Santosh wrote: On Sat, Sep 22, 2012 at 4:19 AM, Chris Hoffmann chrmhoffm...@gmail.com wrote: Hi, We're trying to get a custom 4430 board (aka. nook tablet with OMAP4430 ES2.3 HS TWL6030 ES2.1) working with p-android-omap-3.0 on android jelly bean. The board works quite well, but we experience random hangs and the watchdog kicks the board to reboot. On the same kernel, you should have support for the persistent log. You might want to check the output. That should give you pointers on what CPU was doing before the freeze which resulted in reboot. Hi, I have some problems to provide logs. If I add -DDEBUG to cpuidle44xx.o the problem doesn't seem to occur. It could be that printk-ing alleviates the issue. Also the watchdog seems to shutdown the device rather than rebooting it (or it hangs?) and then I can't provide /proc/last_kmsg. How could I provide more info? Check if you have /sys/kernel/debug/persistent_trace available on your kernel. This generally helps whenever there are hangs, the last call stack is stored on memory and on the reboot it can be cat'ed to see if some useful information about hang is available. 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] ARM: OMAP4+: wakeupgen: fix memory corruption
Paul,
On Sat, Sep 22, 2012 at 1:41 PM, Paul Walmsley p...@pwsan.com wrote:
Fix a memory corruption bug caused by commit
247c445c0fbd52c77e497ff5bfcf0dceb8afea8d (ARM: OMAP5: Add the
WakeupGen IP updates) and commit
ec2c0825ca3183a646a24717966cc7752e8b0393 (ARM: OMAP2+: Remove
hardcoded IRQs and enable SPARSE_IRQ).
The first commit, in the OMAP4+ wakeupgen code, has an implicit
dependency on !SPARSE_IRQ. It allocates a static array with NR_IRQS
elements, then proceeds to iterate over 128 or 160 elements of
that array, clearing them to zero.
The second commit switched OMAP2+ to use sparse IRQs, but missed the
NR_IRQS reference in the wakeupgen code. Before the second commit,
NR_IRQS was 474 on OMAP4430; but afterwards, it became 16.
This resulted in the wakeupgen code allocating a 16 element array, and
then attempting to write to 128 or 160 of those elements, depending on the
type of SoC. This trashed a chunk of whatever was allocated after the
array.
The immediate manifestation was a set of boot warnings similar to the
following:
WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1941 _enable+0x1bc/0x204()
omap_hwmod: mpu: could not enable clockdomain mpuss_clkdm: -22
...
since it blew away arch_clkdm. Ultimately the kernel crashed during boot.
Fix the problem in the OMAP4+ wakeupgen code by removing the reference to
NR_IRQS, allocating a larger array, and warning if the iteration is larger
than the array.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
Applies on arm-soc omap/cleanup-sparseirq and should ideally be merged
there before the 3.7 merge window.
The issue is already fixed by commit e534e87 {ARM: OMAP4: Fix array size for
irq_target_cpu} in mainline. The fix got merged after 3.6-rc5 tag and hence
not appearing in the 'omap/cleanup-sparseirq' branch which seems to be based
of 3.6-rc5.
If you merge 3.6-rc6 tag or the latest mainline with omap/cleanup-sparseirq, the
issue should go away. So from 3.7 merge window point of view, the fix is already
in place.
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: [GIT PULL] ARM: OMAP5: Enable arch timer support
On Sat, Sep 22, 2012 at 2:16 AM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120919 00:54]: (With fixed git URL) On Wed, Sep 19, 2012 at 1:21 PM, Santosh Shilimkar santosh.shilim...@ti.com wrote: Tony, Here is the pull request which enables the architected cpu local timer support for OMAP5 devices. The following changes since commit 5698bd757d55b1bb87edd1a9744ab09c142abfc2: Linux 3.6-rc6 (2012-09-16 14:58:51 -0700) are available in the git repository at: g...@github.com:SantoshShilimkar/linux.git for_3.7/omap5_arch_timer git://github.com/SantoshShilimkar/linux.git for_3.7/omap5_arch_timer Thanks pulled now into devel-dt-arch-timer branch. Note that we're pretty much out of time for v3.7 merge window, so most likely this won't get merged until for v3.8. See message Status of arm-soc for 3.7 posted to LAKML for details. OK. Thanks for heads up. 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: CPU_IDLE causes random reboots on custom 4430
On Sat, Sep 22, 2012 at 4:19 AM, Chris Hoffmann chrmhoffm...@gmail.com wrote: Hi, We're trying to get a custom 4430 board (aka. nook tablet with OMAP4430 ES2.3 HS TWL6030 ES2.1) working with p-android-omap-3.0 on android jelly bean. The board works quite well, but we experience random hangs and the watchdog kicks the board to reboot. On the same kernel, you should have support for the persistent log. You might want to check the output. That should give you pointers on what CPU was doing before the freeze which resulted in reboot. 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 V3 0/8] ARM: OMAP4: Add PMU Support
Paul, On Thu, Sep 20, 2012 at 10:47 PM, Paul Walmsley p...@pwsan.com wrote: Hi Jon, Will, Ming, et al., Have queued most of these for 3.7 with the exception of the OMAP4430 CTI-related patches (which look to me like 3.8 material) and the PM runtime suspend/resume patch (which looks to me like 3.7-rc material) -- assuming this series makes it in for 3.7 ... Any reason CTI patches can't be taken now. In fact the CTI patches are on the list more time than the other ones. Apologies in advance if I broke something else in the process. Perf will remain broken on OMAP4 without CTI patches. 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 V3 0/8] ARM: OMAP4: Add PMU Support
On Thu, Sep 20, 2012 at 11:13 PM, Paul Walmsley p...@pwsan.com wrote: Hi On Thu, 20 Sep 2012, Shilimkar, Santosh wrote: On Thu, Sep 20, 2012 at 10:47 PM, Paul Walmsley p...@pwsan.com wrote: Have queued most of these for 3.7 with the exception of the OMAP4430 CTI-related patches (which look to me like 3.8 material) and the PM runtime suspend/resume patch (which looks to me like 3.7-rc material) -- assuming this series makes it in for 3.7 ... Any reason CTI patches can't be taken now. In fact the CTI patches are on the list more time than the other ones. I listed the reasons briefly here: http://marc.info/?l=linux-omapm=134816037709379w=2 Sorry I should read it before asking the question. Let me know if you need more detail. Thats pretty clear. Apologies in advance if I broke something else in the process. Perf will remain broken on OMAP4 without CTI patches. Looks to me that it should work on OMAP4460/4470 since those chips don't have a CTI dependency for the PMU? You are right. OMAP44_60/70 should work. Thanks for clarification Paul. 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: [GIT PULL] ARM: OMAP5: Enable arch timer support
(With fixed git URL) On Wed, Sep 19, 2012 at 1:21 PM, Santosh Shilimkar santosh.shilim...@ti.com wrote: Tony, Here is the pull request which enables the architected cpu local timer support for OMAP5 devices. The following changes since commit 5698bd757d55b1bb87edd1a9744ab09c142abfc2: Linux 3.6-rc6 (2012-09-16 14:58:51 -0700) are available in the git repository at: g...@github.com:SantoshShilimkar/linux.git for_3.7/omap5_arch_timer git://github.com/SantoshShilimkar/linux.git for_3.7/omap5_arch_timer for you to fetch changes up to 3c7c5dab44d6c8861bc86dab924353d8d40344f8: ARM: OMAP5: Enable arch timer support (2012-09-19 13:00:37 +0530) Santosh Shilimkar (2): ARM: OMAP: Add initialisation for the real-time counter. ARM: OMAP5: Enable arch timer support arch/arm/boot/dts/omap5.dtsi | 12 ++ arch/arm/mach-omap2/Kconfig |5 +++ arch/arm/mach-omap2/timer.c | 97 +- 3 files changed, 113 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: OMAP5: Enable arch timer support
On Tue, Sep 18, 2012 at 11:23 PM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120917 23:07]: On Tue, Sep 18, 2012 at 3:09 AM, Tony Lindgren t...@atomide.com wrote: * Tony Lindgren t...@atomide.com [120917 14:39]: * Benoit Cousson b-cous...@ti.com [120913 01:57]: Enable Cortex A15 generic timer support for OMAP5 based SOCs. The CPU local timers run on the free running real time counter clock. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Benoit Cousson b-cous...@ti.com Tony, I can potentially add it along with the timer changes in the dts part2 series if you ack the timer patch. We don't have tons of OMAP5 content in the dts branch so it should not conflict. Yes makes sense to me. These may cause bad merge conflicts with Jon's timer patches though? These patches can be applied against any branch so not necessary to only apply against the DT tree. Have you merged Jon's series ? I can refresh the patches against that branch. Another option is I can split the patch so that DT change and timer change is seperated. Let me know what is your preference. Maybe do a pull request for the arch timer and dtimer DT changes? Just sent. It seems that Jon is still working on the fixes series, so let's assume that will need to wait a bit. Ok. Thanks for clarification. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] drivers: bus: Move the OMAP interconnect driver to drivers/bus/
On Wed, Sep 19, 2012 at 8:28 PM, Arnd Bergmann a...@arndb.de wrote: On Monday 17 September 2012, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [120914 02:21]: OMAP interconnect drivers are used for the interconnect error handling. Since they are bus driver, lets move it to newly created drivers/bus. Cc: Arnd Bergmann a...@arndb.de Cc: Tony Lindgren t...@atomide.com Tested-by: Lokesh Vutla lokeshvu...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- Patch just moves OMAP interconnect drivers as is to the newly created driver/bus/* directory. Patch is generated against arm-soc/drivers/ocp2scp tree and test on all OMAP boards. Great, looks like this should not conflict with other omap patches queued, so Arnd should probably take this into the bus branch: Acked-by: Tony Lindgren t...@atomide.com Ok, added to the branch. In the future please Cc both Olof and me when submitting patches for inclusion. Thanks Arnd. Sorry I missed to Cc Olof on the patch. Will take care of this in future. Regards santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] drivers: bus: Move the OMAP interconnect driver to drivers/bus/
On Thu, Sep 20, 2012 at 12:27 AM, Arnd Bergmann a...@arndb.de wrote: On Monday 17 September 2012, Tony Lindgren wrote: * Santosh Shilimkar santosh.shilim...@ti.com [120914 02:21]: OMAP interconnect drivers are used for the interconnect error handling. Since they are bus driver, lets move it to newly created drivers/bus. Cc: Arnd Bergmann a...@arndb.de Cc: Tony Lindgren t...@atomide.com Tested-by: Lokesh Vutla lokeshvu...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- Patch just moves OMAP interconnect drivers as is to the newly created driver/bus/* directory. Patch is generated against arm-soc/drivers/ocp2scp tree and test on all OMAP boards. Great, looks like this should not conflict with other omap patches queued, so Arnd should probably take this into the bus branch: Acked-by: Tony Lindgren t...@atomide.com It turns out that the patch actually did conflict and we now have a broken omap2plus_defconfig. The patch below seems to fix it, but please verify that this makes sense. Signed-off-by: Arnd Bergmann a...@arndb.de Looks correct. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: OMAP5: Enable arch timer support
On Tue, Sep 18, 2012 at 3:09 AM, Tony Lindgren t...@atomide.com wrote: * Tony Lindgren t...@atomide.com [120917 14:39]: * Benoit Cousson b-cous...@ti.com [120913 01:57]: Enable Cortex A15 generic timer support for OMAP5 based SOCs. The CPU local timers run on the free running real time counter clock. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Benoit Cousson b-cous...@ti.com Tony, I can potentially add it along with the timer changes in the dts part2 series if you ack the timer patch. We don't have tons of OMAP5 content in the dts branch so it should not conflict. Yes makes sense to me. These may cause bad merge conflicts with Jon's timer patches though? These patches can be applied against any branch so not necessary to only apply against the DT tree. Have you merged Jon's series ? I can refresh the patches against that branch. Another option is I can split the patch so that DT change and timer change is seperated. Let me know what is your preference. 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: OMAP4: crypto acceleration (AES, SHA, ...)
On Tue, Sep 18, 2012 at 2:08 AM, Tony Lindgren t...@atomide.com wrote: * Sebastian Reichel s...@debian.org [120913 14:58]: Hi, Are there plans to add crypto acceleration support to OMAP4? Has this hardware component been removed from OMAP4? I tried to load the code written for OMAP3 on my Pandaboard, but it just outputs platform not supported: [0.370513] omap_init_sham: platform not supported [0.375488] omap_init_aes: platform not supported I recall hearing at some point that these are now available only in the secure mode? Maybe somebody from TI could check this? Thats right. I will cross verify but at least for sure I know that OMAP4 onwards, these blocks are not available for non-secure software. 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/2] ARM: OMAP5: Enable arch timer support
On Thu, Sep 13, 2012 at 2:26 PM, Benoit Cousson b-cous...@ti.com wrote: Hi Santosh, On 09/11/2012 11:29 AM, Shilimkar, Santosh wrote: Benoit, On Mon, Sep 10, 2012 at 7:09 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Mon, Sep 10, 2012 at 6:44 PM, Benoit Cousson b-cous...@ti.com wrote: [...] Silly question: Don't we have one arch-timer per CPU? It is per CPU just like A9 TWD Shouldn't we have two nodes then? I need to check this but arch timer DT node should be same as the twd DT node. May be one node with reference to each CPU node should do but am not too sure about the DT nodes and how all that work. Here is an updated patch based on our discussion. Thanks for comments. Let me know if you are ok with this version. Cool, thanks for the update. From 98f6a3b4b52ef7c76ed8b19bf9257c51ee5d7323 Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar santosh.shilim...@ti.com Date: Mon, 13 Aug 2012 14:39:03 +0530 Subject: [PATCH] ARM: OMAP5: Enable arch timer support Enable Cortex A15 generic timer support for OMAP5 based SOCs. The CPU local timers run on the free running real time counter clock. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Benoit Cousson b-cous...@ti.com Thanks Benoit. Tony, I can potentially add it along with the timer changes in the dts part2 series if you ack the timer patch. We don't have tons of OMAP5 content in the dts branch so it should not conflict. Yep. let me know what works. if needed I can put these two patches on a branch and send a pull request. 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/2] ARM: OMAP5: Enable arch timer support
On Thu, Sep 13, 2012 at 2:57 PM, Benoit Cousson b-cous...@ti.com wrote: On 09/13/2012 11:00 AM, Shilimkar, Santosh wrote: On Thu, Sep 13, 2012 at 2:26 PM, Benoit Cousson b-cous...@ti.com wrote: Hi Santosh, On 09/11/2012 11:29 AM, Shilimkar, Santosh wrote: Benoit, On Mon, Sep 10, 2012 at 7:09 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Mon, Sep 10, 2012 at 6:44 PM, Benoit Cousson b-cous...@ti.com wrote: [...] Silly question: Don't we have one arch-timer per CPU? It is per CPU just like A9 TWD Shouldn't we have two nodes then? I need to check this but arch timer DT node should be same as the twd DT node. May be one node with reference to each CPU node should do but am not too sure about the DT nodes and how all that work. Here is an updated patch based on our discussion. Thanks for comments. Let me know if you are ok with this version. Cool, thanks for the update. From 98f6a3b4b52ef7c76ed8b19bf9257c51ee5d7323 Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar santosh.shilim...@ti.com Date: Mon, 13 Aug 2012 14:39:03 +0530 Subject: [PATCH] ARM: OMAP5: Enable arch timer support Enable Cortex A15 generic timer support for OMAP5 based SOCs. The CPU local timers run on the free running real time counter clock. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Benoit Cousson b-cous...@ti.com Thanks Benoit. Tony, I can potentially add it along with the timer changes in the dts part2 series if you ack the timer patch. We don't have tons of OMAP5 content in the dts branch so it should not conflict. Yep. let me know what works. if needed I can put these two patches on a branch and send a pull request. It does not apply to the current devel-dt, what base did you used? Mainline 3.6-rc3. Just refreshed the patches against devel-dt. The Kconfig file had a minor conflict. Updated patches are updated. Regards Santosh 0001-ARM-OMAP-Add-initialisation-for-the-real-time-counte.patch Description: Binary data 0002-ARM-OMAP5-Enable-arch-timer-support.patch Description: Binary data
Re: [PATCH 2/2] ARM: OMAP5: Enable arch timer support
On Thu, Sep 13, 2012 at 3:30 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Thu, Sep 13, 2012 at 2:57 PM, Benoit Cousson b-cous...@ti.com wrote: On 09/13/2012 11:00 AM, Shilimkar, Santosh wrote: On Thu, Sep 13, 2012 at 2:26 PM, Benoit Cousson b-cous...@ti.com wrote: Hi Santosh, On 09/11/2012 11:29 AM, Shilimkar, Santosh wrote: Benoit, On Mon, Sep 10, 2012 at 7:09 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Mon, Sep 10, 2012 at 6:44 PM, Benoit Cousson b-cous...@ti.com wrote: [...] Silly question: Don't we have one arch-timer per CPU? It is per CPU just like A9 TWD Shouldn't we have two nodes then? I need to check this but arch timer DT node should be same as the twd DT node. May be one node with reference to each CPU node should do but am not too sure about the DT nodes and how all that work. Here is an updated patch based on our discussion. Thanks for comments. Let me know if you are ok with this version. Cool, thanks for the update. From 98f6a3b4b52ef7c76ed8b19bf9257c51ee5d7323 Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar santosh.shilim...@ti.com Date: Mon, 13 Aug 2012 14:39:03 +0530 Subject: [PATCH] ARM: OMAP5: Enable arch timer support Enable Cortex A15 generic timer support for OMAP5 based SOCs. The CPU local timers run on the free running real time counter clock. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Benoit Cousson b-cous...@ti.com Thanks Benoit. Tony, I can potentially add it along with the timer changes in the dts part2 series if you ack the timer patch. We don't have tons of OMAP5 content in the dts branch so it should not conflict. Yep. let me know what works. if needed I can put these two patches on a branch and send a pull request. It does not apply to the current devel-dt, what base did you used? Mainline 3.6-rc3. Just refreshed the patches against devel-dt. The Kconfig file had a minor conflict. Updated patches. Let me know if they apply ok for you ? 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: [RFC PATCH 4/6] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
On Thu, Sep 13, 2012 at 6:23 PM, Dave Martin dave.mar...@linaro.org wrote: On Thu, Sep 13, 2012 at 11:20:49AM +0100, Lorenzo Pieralisi wrote: In processors like A15/A7 L2 cache is unified and integrated within the processor cache hierarchy, so that it is not considered an outer cache anymore. For processors like A15/A7 flush_cache_all() ends up cleaning all cache levels up to Level of Coherency (LoC) that includes the L2 unified cache. When a single CPU is suspended (CPU idle) a complete L2 clean is not required, so generic cpu_suspend code must clean the data cache using the newly introduced cache LoUIS function. The context and stack pointer (context pointer) are cleaned to main memory using cache area functions that operate on MVA and guarantee that the data is written back to main memory (perform cache cleaning up to the Point of Coherency - PoC) so that the processor can fetch the context when the MMU is off in the cpu_resume code path. outer_cache management remains unchanged. LoUIS matches the power domain affected by turning a single CPU off on most (all?) current v7 SoCs where this matters, but only by coincidence. There is no guarantee of that. The _louis() API is useful, because this is exactly what you need to to I-/D-/TLB synchronisation in an SMP OS. Using it as preparation for powering a CPU off feels like misuse, at least in theory. For powerdown, we would logically need a separate function, flush_cache_cpu() or something, whose job is precisely to flush those levels which will be affected by the power-down if that single CPU. In the series, there is patch [PATCH 3/6] which adds an API which let you operate on a specific level. 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: [RFC PATCH 4/6] ARM: kernel: update cpu_suspend code to use cache LoUIS operations
On Thu, Sep 13, 2012 at 6:38 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Thu, Sep 13, 2012 at 06:31:35PM +0530, Shilimkar, Santosh wrote: In the series, there is patch [PATCH 3/6] which adds an API which let you operate on a specific level. Which is introduced but as far as I can see, is never used in the patch set. Therefore, it shouldn't be introduced. We've been here before many many many times, where people introduce stuff into the kernel, and then they never get around to using the damned stuff. It's happened far too many times to permit on a but I will use it in the future kind of arguments. If you're going to introduce something new, include the users in the patch set, or don't bother submitting the new function in the vague hope that some day it will get used. Fair enough. We can postpone adding that API now in this series and add it along with the user. For the record, it was added to use in the A15 low power code to operate on L1 and L2 levels based on the power domain states. 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] CPUFreq: OMAP: remove unnecessary plat/ includes
On Wed, Sep 12, 2012 at 6:02 AM, Paul Walmsley p...@pwsan.com wrote: Remove some unnecessary plat/ includes that are interfering with multi-subarch ARM kernels. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com Cc: Rafael J. Wysocki r...@sisk.pl Acked-by: Kevin Hilman khil...@ti.com --- Still awaiting some final testing here. Rafael, was wondering if you would be willing to ack this so we can merge it via the OMAP tree? Otherwise the patch can be split into an OMAP part and a CPUFreq part that can go in across two merge windows. Hmm. I did similar change[1] a while back. Kevin didn't like idea though that point of time. Regards, Santosh [1] http://www.spinics.net/lists/linux-omap/msg48382.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] ARM: mm: ADD descriptor string to CONFIG_DMA_ADDR_64BIT_T
On Wed, Sep 12, 2012 at 6:16 PM, Cyril Chemparathy cy...@ti.com wrote: On 9/12/2012 1:50 AM, R Sricharan wrote: Even if CONFIG_DMA_ADDR_64BIT_T is enabled by the defconfig, the feature is not getting selected. Adding a string description in the Kconfig resolves this. But not sure if this is the right way to fix this. Shouldn't you be selecting this in your 64-bit dma address capable arch instead? Yes. The selection to enable CONFIG_DMA_ADDR_64BIT_T happens in the arch which needs it. Since this option was made as simple bool, looks like because of some KCONFIG magic, it was not getting selected. Adding some help text does fix the issue and thats is the patch all about. 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] CPUFreq: OMAP: remove unnecessary plat/ includes
On Wed, Sep 12, 2012 at 7:27 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Shilimkar, Santosh santosh.shilim...@ti.com writes: On Wed, Sep 12, 2012 at 6:02 AM, Paul Walmsley p...@pwsan.com wrote: Remove some unnecessary plat/ includes that are interfering with multi-subarch ARM kernels. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com Cc: Rafael J. Wysocki r...@sisk.pl Acked-by: Kevin Hilman khil...@ti.com --- Still awaiting some final testing here. Rafael, was wondering if you would be willing to ack this so we can merge it via the OMAP tree? Otherwise the patch can be split into an OMAP part and a CPUFreq part that can go in across two merge windows. Hmm. I did similar change[1] a while back. Kevin didn't like idea though that point of time. I was wrong. At the time, we were thinking about how to get rid of clkdev nodes instead of add more. Now, we need to clean up these drivers and this is the only way to do it, so I retract my objection. Thanks for clarifying. For patch itself, Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: wakeupgen: remove duplicate AUXCOREBOOT* read/write
On Tue, Sep 11, 2012 at 12:25 AM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120908 01:20]: Will you able to pick up these couple of wakeupgen fixes from here or do you want me to send you a pull request for 3.6-rc5/6 I can pick them into fixes-noncritical. But if the second one is a major bug for the -rc series, the patch should be describe what breaks (regression? oops?). Fixes non critical is fine. No major issue without these patches. 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] ARM: OMAP4: wakeupgen: remove duplicate AUXCOREBOOT* read/write
On Tue, Sep 11, 2012 at 12:07 PM, Paul Walmsley p...@pwsan.com wrote: On Tue, 11 Sep 2012, Shilimkar, Santosh wrote: On Tue, Sep 11, 2012 at 12:25 AM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120908 01:20]: Will you able to pick up these couple of wakeupgen fixes from here or do you want me to send you a pull request for 3.6-rc5/6 I can pick them into fixes-noncritical. But if the second one is a major bug for the -rc series, the patch should be describe what breaks (regression? oops?). Fixes non critical is fine. No major issue without these patches. There's an ordering constraint though: Santosh's patch needs to go in first, then mine. Its other way round ;-) Mine I created after applying your change. 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 V3 0/8] ARM: OMAP4: Add PMU Support
Jon, On Mon, Sep 10, 2012 at 8:53 PM, Jon Hunter jon-hun...@ti.com wrote: This series adds PMU support for OMAP4 devices. This is based upon Will Deacons series [1] and re-based upon the latest arm-soc next/cleanup branch (3.6-rc3) that includes Will's series. It has been re-based upon this series because of the dependency on Sudeep KarkadaNagesha's change (ARM: pmu: remove arm_pmu_type enumeration) [2] that modifies the OMAP PMU code. This series is also dependent upon some clock fixes for OMAP3 [3] and OMAP4 [4] for PMU to operate correctly on OMAP3 and OMAP4. This series also converts OMAP2/3 devices to use HWMOD to create the PMU device and add a new file to mach-omap2 directory called pmu.c where the PMU devices are created. Testing: - Verified that PMU is working on OMAP2420 H4, OMAP3430 Beagle Board, OMAP4430 Panda and OMAP4460 Panda. - Tested on the above boards with CPU-idle enabled to ensure that PMU is working with power management. For OMAP3430 verified that CORE retention state is entered again after stopping PMU events. V3 changes: - Will Deacon has taken the PMU runtime PM adaption patch in his series and so not included here [1]. - Dropped my fix for managing the EMU power domain on OMAP4 in favour of Paul's implementation [4]. Paul is planning to submit for v3.7. - Added HWMOD data for OMAP3 DEBUG sub-system. The DEBUG sub-system was always being enabled on OMAP3 devices when using PMU and hence, hinding the fact that PMU is dependent upon the DEBUG sub-system on OMAP3 for it to work. [1] git://git.kernel.org/pub/sicm/linux/kernel/git/will/linux.git perf/updates [2] http://www.spinics.net/lists/arm-kernel/msg188726.html [3] http://marc.info/?l=linux-omapm=134333691309305w=2 [4] http://marc.info/?l=linux-arm-kernelm=134383567112518w=2 Cc: Ming Lei ming@canonical.com Cc: Will Deacon will.dea...@arm.com Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com Jon Hunter (6): ARM: OMAP3: Add debugss HWMOD data ARM: OMAP2+: PMU: Convert OMAP2/3 devices to use HWMOD ARM: OMAP4: Re-map the CTIs IRQs from MPU to DEBUGSS ARM: OMAP2+: PMU: Add runtime PM support ARM: OMAP4: Enable PMU for OMAP4460/70 ARM: OMAP2+: PMU: Add QoS constraint Ming Lei (2): ARM: OMAP4430: Create PMU device via HWMOD ARM: OMAP4: Route PMU IRQs to CTI IRQs Thanks for persisting with the PMU series and great work to get it working across almost all OMAPs supporting PMU. I have acked few patches already from the series. Just quickly rescanned full series and also tried it on OMAP4 SDP. PMU counters seems to work fine with it. Feel free to add my ack for the entire series. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP4: wakeupgen: remove duplicate AUXCOREBOOT* read/write
On Tue, Sep 11, 2012 at 12:13 PM, Paul Walmsley p...@pwsan.com wrote: On Tue, 11 Sep 2012, Shilimkar, Santosh wrote: On Tue, Sep 11, 2012 at 12:07 PM, Paul Walmsley p...@pwsan.com wrote: On Tue, 11 Sep 2012, Shilimkar, Santosh wrote: On Tue, Sep 11, 2012 at 12:25 AM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120908 01:20]: Will you able to pick up these couple of wakeupgen fixes from here or do you want me to send you a pull request for 3.6-rc5/6 I can pick them into fixes-noncritical. But if the second one is a major bug for the -rc series, the patch should be describe what breaks (regression? oops?). Fixes non critical is fine. No major issue without these patches. There's an ordering constraint though: Santosh's patch needs to go in first, then mine. Its other way round ;-) Mine I created after applying your change. The problem is that if my patch is applied first, then there will be a point after my patch where the AUXCOREBOOT1 register won't be saved, which might break PM. So the patches may need to be updated. Good point. It's trivial to re-order them. Tony, Updated patches in the end of the email. Also attached. Regards Santosh From 4e1da2a44d92b956c3a740f5af6a45ff1c2dc294 Mon Sep 17 00:00:00 2001 From: Paul Walmsley p...@pwsan.com Date: Tue, 11 Sep 2012 12:43:18 +0530 Subject: [PATCH 2/2] ARM: OMAP4: wakeupgen: remove duplicate AUXCOREBOOT* read/write The wakeupgen context-save code reads and stores the AUXCOREBOOT0 and AUXCOREBOOT1 register contents twice. This seems like a waste of time, so, remove the duplicates. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/omap-wakeupgen.c |6 -- 1 file changed, 6 deletions(-) diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c index c3795c2..567f672 100644 --- a/arch/arm/mach-omap2/omap-wakeupgen.c +++ b/arch/arm/mach-omap2/omap-wakeupgen.c @@ -233,12 +233,6 @@ static inline void omap4_irq_save_context(void) __raw_writel(val, sar_base + AUXCOREBOOT1_OFFSET); /* Save SyncReq generation logic */ - val = __raw_readl(wakeupgen_base + OMAP_AUX_CORE_BOOT_0); - __raw_writel(val, sar_base + AUXCOREBOOT0_OFFSET); - val = __raw_readl(wakeupgen_base + OMAP_AUX_CORE_BOOT_0); - __raw_writel(val, sar_base + AUXCOREBOOT1_OFFSET); - - /* Save SyncReq generation logic */ val = __raw_readl(wakeupgen_base + OMAP_PTMSYNCREQ_MASK); __raw_writel(val, sar_base + PTMSYNCREQ_MASK_OFFSET); val = __raw_readl(wakeupgen_base + OMAP_PTMSYNCREQ_EN); -- 1.7.9.5 From 6e3b8a3f6ec231f588b860d87b7a80f6ba38ce98 Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar santosh.shilim...@ti.com Date: Thu, 6 Sep 2012 11:51:34 +0530 Subject: [PATCH 1/2] ARM: OMAP4: wakeupgen: Fix the typo in AUXCOREBOOT register save The wakeupgen context-save code reads AUXCOREBOOT0 register instead of AUXCOREBOOT1 register contents while saving AUXCOREBOOT1. Fix the same. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/omap-wakeupgen.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c index 05fdebf..c3795c2 100644 --- a/arch/arm/mach-omap2/omap-wakeupgen.c +++ b/arch/arm/mach-omap2/omap-wakeupgen.c @@ -229,7 +229,7 @@ static inline void omap4_irq_save_context(void) /* Save AuxBoot* registers */ val = __raw_readl(wakeupgen_base + OMAP_AUX_CORE_BOOT_0); __raw_writel(val, sar_base + AUXCOREBOOT0_OFFSET); - val = __raw_readl(wakeupgen_base + OMAP_AUX_CORE_BOOT_0); + val = __raw_readl(wakeupgen_base + OMAP_AUX_CORE_BOOT_1); __raw_writel(val, sar_base + AUXCOREBOOT1_OFFSET); /* Save SyncReq generation logic */ -- 1.7.9.5 0002-ARM-OMAP4-wakeupgen-remove-duplicate-AUXCOREBOOT-rea.patch Description: Binary data 0001-ARM-OMAP4-wakeupgen-Fix-the-typo-in-AUXCOREBOOT-regi.patch Description: Binary data
Re: [PATCH 2/2] ARM: OMAP5: Enable arch timer support
Benoit,
On Mon, Sep 10, 2012 at 7:09 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Mon, Sep 10, 2012 at 6:44 PM, Benoit Cousson b-cous...@ti.com wrote:
[...]
Silly question: Don't we have one arch-timer per CPU?
It is per CPU just like A9 TWD
Shouldn't we have two nodes then?
I need to check this but arch timer DT node should be same
as the twd DT node. May be one node with reference to
each CPU node should do but am not too sure about the DT
nodes and how all that work.
Here is an updated patch based on our discussion. Thanks for comments.
Let me know if you are ok with this version.
From 98f6a3b4b52ef7c76ed8b19bf9257c51ee5d7323 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Mon, 13 Aug 2012 14:39:03 +0530
Subject: [PATCH] ARM: OMAP5: Enable arch timer support
Enable Cortex A15 generic timer support for OMAP5 based SOCs.
The CPU local timers run on the free running real time counter clock.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 12
arch/arm/mach-omap2/Kconfig |1 +
arch/arm/mach-omap2/timer.c |7 +++
3 files changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 57e5270..7b986ed 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -33,9 +33,21 @@
cpus {
cpu@0 {
compatible = arm,cortex-a15;
+ timer {
+ compatible = arm,armv7-timer;
+ /* 14th PPI IRQ, active low level-sensitive */
+ interrupts = 1 14 0x308;
+ clock-frequency = 6144000;
+ };
};
cpu@1 {
compatible = arm,cortex-a15;
+ timer {
+ compatible = arm,armv7-timer;
+ /* 14th PPI IRQ, active low level-sensitive */
+ interrupts = 1 14 0x308;
+ clock-frequency = 6144000;
+ };
};
};
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 2120f90..53fb77c 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -73,6 +73,7 @@ config SOC_OMAP5
select ARM_GIC
select HAVE_SMP
select SOC_HAS_REALTIME_COUNTER
+ select ARM_ARCH_TIMER
comment OMAP Core Type
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 8f5b88b..46982d0 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -41,6 +41,7 @@
#include plat/dmtimer.h
#include asm/smp_twd.h
#include asm/sched_clock.h
+#include asm/arch_timer.h
#include common.h
#include plat/omap_hwmod.h
#include plat/omap_device.h
@@ -481,9 +482,15 @@ OMAP_SYS_TIMER(4)
#ifdef CONFIG_SOC_OMAP5
static void __init omap5_timer_init(void)
{
+ int err;
+
omap2_gp_clockevent_init(1, OMAP4_CLKEV_SOURCE);
omap2_clocksource_init(2, OMAP4_MPU_SOURCE);
realtime_counter_init();
+
+ err = arch_timer_of_register();
+ if (err)
+ pr_err(%s: arch_timer_register failed %d\n, __func__, err);
}
OMAP_SYS_TIMER(5)
#endif
--
1.7.9.5
0001-ARM-OMAP5-Enable-arch-timer-support.patch
Description: Binary data
Re: [PATCH 13/16] ARM: omap: move platform_data definitions
Arnd, On Tue, Sep 11, 2012 at 6:32 PM, Arnd Bergmann a...@arndb.de wrote: Platform data for device drivers should be defined in include/linux/platform_data/*.h, not in the architecture and platform specific directories. This moves such data out of the omap include directories Signed-off-by: Arnd Bergmann a...@arndb.de [...] 81 files changed, 87 insertions(+), 87 deletions(-) rename arch/arm/plat-omap/include/plat/mcbsp.h = include/linux/platform_data/dsp-mcbsp.h (100%) rename arch/arm/plat-omap/include/plat/dsp.h = include/linux/platform_data/dsp-omap.h (100%) rename arch/arm/plat-omap/include/plat/keypad.h = include/linux/platform_data/keypad-omap.h (100%) rename arch/arm/plat-omap/include/plat/lcd_mipid.h = include/linux/platform_data/lcd-mipid.h (100%) rename arch/arm/plat-omap/include/plat/nand.h = include/linux/platform_data/mtd-nand-omap2.h (100%) rename arch/arm/plat-omap/include/plat/onenand.h = include/linux/platform_data/mtd-onenand-omap2.h (100%) rename arch/arm/plat-omap/include/plat/remoteproc.h = include/linux/platform_data/remoteproc-omap.h (100%) rename arch/arm/plat-omap/include/plat/voltage.h = include/linux/platform_data/smartreflex-omap.h (100%) rename arch/arm/plat-omap/include/plat/mcspi.h = include/linux/platform_data/spi-omap2-mcspi.h (100%) Just curious to know how you came with some of the above header names ? plat/mcbsp --- dsp-mcbsp.h There is no connection of DSP with McBSP. omap-mcbsp.h would been a better name. plat/nand.h -- /mtd-nand-omap2.h plat/onenand.h -- /mtd-onenand-omap2.h May be omap-nand.h and omap-onenand.h plat/mcspi.h--spi-omap2-mcspi.h May be omap-spi.h 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 13/16] ARM: omap: move platform_data definitions
On Tue, Sep 11, 2012 at 7:47 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 11 September 2012, Shilimkar, Santosh wrote: Just curious to know how you came with some of the above header names ? plat/mcbsp --- dsp-mcbsp.h There is no connection of DSP with McBSP. omap-mcbsp.h would been a better name. This one was a mistake on my side, as Tony and Peter already pointed out. How about asoc-mcbsp.h or asoc-omap-mcbsp.h? After re-reading the cover-letter and your below response, 'asoc-omap-mcbsp.h' seems to be fine. plat/nand.h -- /mtd-nand-omap2.h plat/onenand.h -- /mtd-onenand-omap2.h May be omap-nand.h and omap-onenand.h plat/mcspi.h--spi-omap2-mcspi.h May be omap-spi.h As I wrote in the introductory mail, I tried to always prefix the file names with the subsystem, followed by the name of the driver, in order to standardize on just one set of rules. Just read that now. The drivers implementing the three headers above are: drivers/mtd/nand/omap2.c drivers/mtd/onenand/omap2.c drivers/spi/spi-omap2-mcspi.c so these all seem appropriate. Sorry I missed the subsystem prefix point. These names seems to be fine then. 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] ARM: OMAP2+: TEMP: Round of the carve out memory requested to section_size
On Wed, Sep 12, 2012 at 11:21 AM, R Sricharan r.sricha...@ti.com wrote: memblock_steal tries to reserve physical memory during boot. When the requested size is not aligned on the section size then, the remaining memory available for lowmem becomes unaligned on the section boundary. There is a issue with this, which is discussed in the thread below. https://lkml.org/lkml/2012/6/28/112 The final conclusion from the thread seems to be align the memblock_steal calls on the SECTION boundary. Signed-off-by: R Sricharan r.sricha...@ti.com Why is the TEMP in the subject line. From patch it doesn't be temporary version. Can you please clarify that ? 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: Seeking clarity on IRQCHIP_MASK_ON_SUSPEND
Thomas, On Mon, Sep 10, 2012 at 3:58 PM, Thomas Gleixner t...@linutronix.de wrote: On Mon, 10 Sep 2012, NeilBrown wrote: The IRQCHIP_MASK_ON_SUSPEND flag seems to be hard to use correctly, so either I'm understanding it wrongly, or it could be made easier to use. If the first case, I'm hoping that some improvement to documentation might result. If the second, then maybe we can fix the code. ... Is anyone able to give a definitive answer on this? Should IRQCHIP_MASK_ON_SUSPEND be removed? The whole point of IRQCHIP_MASK_ON_SUSPEND is to deal with hardware designed by geniuses. Most SoCs have a way to mark the interrupts which serve as a wake up source as such. All other interrupts are magically masked on entry to suspend. Just to support this, IRQCHIP_MASK_ON_SUSPEND does work with quite a few ARM platforms too. OMAP already uses it in mainline and I have seen patches for U500 and Tegra SOCs. Most of these usages are with IRQ chips who doesn't have any driver run time PM supported and the IRQ CHIP itself is shutdown when the CPU/CPU cluster gets power down. So as far as functionality concerned with the flag, it does what it suppose to do. Now there is hardware which is missing such a control, so we need to mask the non wakeup interrupts right before going into suspend. That's what IRQCHIP_MASK_ON_SUSPEND does. Not more, not less. See commit d209a699a0b for more ugly details. You might be looking for a different functionality. Can you explain what you need? Neil's email came from a discussion on the usage of this flag for OMAP GPIO irqchip which I proposed. With the flag, when the lazy check_irq routine is called, the GPIO driver is runtime suspended and hence the late mask/unmask calls take abort(clocks are already gated). GPIO IRQCHIP is secondary IRQCHIP connected to 1 interrupt line per bank(32 GPIOs) to the primary interrupt controller IRQCHIP. Hope this gives bit more clarity to the discussed problem. 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/2] ARM: OMAP5: Enable arch timer support
Benoit, On Mon, Aug 13, 2012 at 4:37 PM, Santosh Shilimkar santosh.shilim...@ti.com wrote: Enable Cortex A15 generic timer support for OMAP5 based SOCs. The CPU local timers run on the free running real time counter clock. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/boot/dts/omap5.dtsi |6 ++ arch/arm/mach-omap2/Kconfig |1 + arch/arm/mach-omap2/timer.c |7 +++ 3 files changed, 14 insertions(+) Missed to copy you on this patch. Your comments/ack on the DT part. 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/2] ARM: OMAP5: Enable arch timer support
On Mon, Sep 10, 2012 at 6:17 PM, Benoit Cousson b-cous...@ti.com wrote:
Hi Santosh,
On 08/13/2012 01:07 PM, Santosh Shilimkar wrote:
Enable Cortex A15 generic timer support for OMAP5 based SOCs.
The CPU local timers run on the free running real time counter clock.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/omap5.dtsi |6 ++
arch/arm/mach-omap2/Kconfig |1 +
arch/arm/mach-omap2/timer.c |7 +++
3 files changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 57e5270..9686056 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -73,6 +73,12 @@
0x48212000 0x1000;
};
+ arch-timer {
arch-timer is the ARM specific name, so I guess here it should be named
with the generic timer name.
is local_timer name fine then?
+ compatible = arm,armv7-timer;
+ interrupts = 1 14 0x304;
Could you add some comment, because these hexa value are a little bit
hard to understand.
OK. Will add some comments.
+ clock-frequency = 614;
+ };
+
That node does not even have a base address?
If this is located inside the MPU, it should not be in the OCP node.
Its inside MPU and Cp15 control based. No OCP node.
Silly question: Don't we have one arch-timer per CPU?
It is per CPU just like A9 TWD
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/2] ARM: OMAP5: Enable arch timer support
On Mon, Sep 10, 2012 at 6:44 PM, Benoit Cousson b-cous...@ti.com wrote:
On 09/10/2012 03:01 PM, Shilimkar, Santosh wrote:
On Mon, Sep 10, 2012 at 6:17 PM, Benoit Cousson b-cous...@ti.com
wrote:
Hi Santosh,
On 08/13/2012 01:07 PM, Santosh Shilimkar wrote:
Enable Cortex A15 generic timer support for OMAP5 based SOCs.
The CPU local timers run on the free running real time counter clock.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/omap5.dtsi |6 ++
arch/arm/mach-omap2/Kconfig |1 +
arch/arm/mach-omap2/timer.c |7 +++
3 files changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi
b/arch/arm/boot/dts/omap5.dtsi
index 57e5270..9686056 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -73,6 +73,12 @@
0x48212000 0x1000;
};
+ arch-timer {
arch-timer is the ARM specific name, so I guess here it should be named
with the generic timer name.
is local_timer name fine then?
No, *timer* is fine. The point here is to provide the generic name when
it exists. That name is supposed to be the general class of the device.
Potentially you can add a label to give an unique name, but since that
label will not be used elsewhere it is not even needed.
arch-timer: timer { ... }
Ok. Will use this.
+ compatible = arm,armv7-timer;
+ interrupts = 1 14 0x304;
Could you add some comment, because these hexa value are a little bit
hard to understand.
OK. Will add some comments.
+ clock-frequency = 614;
+ };
+
That node does not even have a base address?
If this is located inside the MPU, it should not be in the OCP node.
Its inside MPU and Cp15 control based. No OCP node.
OK, so you must move it inside the CPU node.
OK. Will do.
Silly question: Don't we have one arch-timer per CPU?
It is per CPU just like A9 TWD
Shouldn't we have two nodes then?
I need to check this but arch timer DT node should be same
as the twd DT node. May be one node with reference to
each CPU node should do but am not too sure about the DT
nodes and how all that work.
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] OMAP GPIO - don't wake from suspend unless requested.
On Sat, Sep 8, 2012 at 3:07 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Hi Neil, NeilBrown ne...@suse.de writes: On Thu, 6 Sep 2012 11:18:09 +0530 Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Thu, Sep 6, 2012 at 8:35 AM, NeilBrown ne...@suse.de wrote: On Mon, 3 Sep 2012 22:59:06 -0700 Shilimkar, Santosh santosh.shilim...@ti.com wrote: After thinking bit more on this, the problem seems to be coming mainly because the gpio device is runtime suspended bit early than it should be. Similar issue seen with i2c driver as well. The i2c issue was discussed with Rafael at LPC last week. The idea is to move the pm_runtime_enable/disable() calls entirely up to the _late/_early stage of device suspend/resume. Will update this thread once I have further update. This won't be late enough. IRQCHIP_MASK_ON_SUSPEND takes effect after all the _late callbacks have been called. I, too, spoke to Rafael about this in San Diego. He seemed to agree with me that the interrupt needs to be masked in the -suspend callback. any later is too late. Thanks for information about your discussion. Will wait for the patch then. Regards santosh I already sent a patch - that is what started this thread :-) I include it below. You said The patch doesn't seems to be correct but didn't expand on why. Do you still think it is not correct? I wouldn't be surprised if there is some case that it doesn't handle quite right, but it seems right to me. Thanks, NeilBrown From: NeilBrown ne...@suse.de Subject: [PATCH] OMAP GPIO - don't wake from suspend unless requested. Current kernel will wake from suspend on an event on any active GPIO even if enable_irq_wake() wasn't called. There are two reasons that the hardware wake-enable bit should be set: 1/ while non-suspended the CPU might go into a deep sleep (off_mode) in which the wake-enable bit is needed for an interrupt to be recognised. 2/ while suspended the GPIO interrupt should wake from suspend if and only if irq_wake as been enabled. The code currently doesn't keep these two reasons separate so they get confused and sometimes the wakeup flags is set incorrectly. This patch reverts: commit 9c4ed9e6c01e7a8bd9079da8267e1f03cb4761fc gpio/omap: remove suspend/resume callbacks and commit 0aa2727399c0b78225021413022c164cb99fbc5e gpio/omap: remove suspend_wakeup field from struct gpio_bank and makes some minor changes so that we have separate flags for GPIO should wake from deep idle and GPIO should wake from suspend. With this patch, the GPIO from my touch screen doesn't wake my device any more, which is what I want. I think the direction is right here. We never should've separated the handling of idle vs suspend wakeups. However, I have a few questions/doubts below... I thought irq_set_wake() is suspend only wakeup functionality. In idle, the driver IRQs are not disabled/masked so there no need of any special wakeup calls for idle. More ever patch is adding the suspend hooks for wakeups. I have no objection on the subject patch, but the suspend wakeup facility is easy enough to implement for IRQCHIPS and that is what I was proposing it. Infact the mask on suspend patch almost works and it fails only because the GPIO driver is suspended earlier than the IRQ framework expect it to be. Anyways I step back here since the proposed patch already fixes the issue seen. Assuming the IRQCHIP mask on suspend doesn't seems to work well with drivers as Neil mentioned, the $subject patch seems to be the right option. 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] ARM: OMAP4: wakeupgen: remove duplicate AUXCOREBOOT* read/write
Tony, On Thu, Sep 6, 2012 at 12:05 PM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Thu, Sep 6, 2012 at 5:04 AM, Paul Walmsley p...@pwsan.com wrote: The wakeupgen context-save code reads and stores the AUXCOREBOOT0 and AUXCOREBOOT1 register contents twice. This seems like a waste of time, so, remove the duplicates. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Santosh Shilimkar santosh.shilim...@ti.com --- Looks fine to me. Thanks Paul. Reviewed-by: Santosh Shilimkar ,santosh.shilim...@ti.com While reviewing your patch, i noticed a typo in the code. Since the patch fixes nearby code as the subject patch, I generated that patch on top of yours. Same is end of the email as well as attachment. The patch applies on top of your patch. Regards Santosh From 5fcd24e5782e502aa607b73de78be68b394f9639 Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar santosh.shilim...@ti.com Date: Thu, 6 Sep 2012 11:51:34 +0530 Subject: [PATCH] ARM: OMAP4: wakeupgen: Fix the typo in AUXCOREBOOT register save The wakeupgen context-save code reads AUXCOREBOOT0 register instead of AUXCOREBOOT1 register contents while saving AUXCOREBOOT1. Fix the same. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- Will you able to pick up these couple of wakeupgen fixes from here or do you want me to send you a pull request for 3.6-rc5/6 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] ARM: OMAP4: wakeupgen: remove duplicate AUXCOREBOOT* read/write
On Thu, Sep 6, 2012 at 5:04 AM, Paul Walmsley p...@pwsan.com wrote: The wakeupgen context-save code reads and stores the AUXCOREBOOT0 and AUXCOREBOOT1 register contents twice. This seems like a waste of time, so, remove the duplicates. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Santosh Shilimkar santosh.shilim...@ti.com --- Looks fine to me. Thanks Paul. Reviewed-by: Santosh Shilimkar ,santosh.shilim...@ti.com While reviewing your patch, i noticed a typo in the code. Since the patch fixes nearby code as the subject patch, I generated that patch on top of yours. Same is end of the email as well as attachment. The patch applies on top of your patch. Regards Santosh From 5fcd24e5782e502aa607b73de78be68b394f9639 Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar santosh.shilim...@ti.com Date: Thu, 6 Sep 2012 11:51:34 +0530 Subject: [PATCH] ARM: OMAP4: wakeupgen: Fix the typo in AUXCOREBOOT register save The wakeupgen context-save code reads AUXCOREBOOT0 register instead of AUXCOREBOOT1 register contents while saving AUXCOREBOOT1. Fix the same. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/mach-omap2/omap-wakeupgen.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c b/arch/arm/mach-omap2/omap-wakeupgen.c index b55432d..567f672 100644 --- a/arch/arm/mach-omap2/omap-wakeupgen.c +++ b/arch/arm/mach-omap2/omap-wakeupgen.c @@ -229,7 +229,7 @@ static inline void omap4_irq_save_context(void) /* Save AuxBoot* registers */ val = __raw_readl(wakeupgen_base + OMAP_AUX_CORE_BOOT_0); __raw_writel(val, sar_base + AUXCOREBOOT0_OFFSET); - val = __raw_readl(wakeupgen_base + OMAP_AUX_CORE_BOOT_0); + val = __raw_readl(wakeupgen_base + OMAP_AUX_CORE_BOOT_1); __raw_writel(val, sar_base + AUXCOREBOOT1_OFFSET); /* Save SyncReq generation logic */ -- 1.7.9.5 0001-ARM-OMAP4-wakeupgen-Fix-the-typo-in-AUXCOREBOOT-regi.patch Description: Binary data
Re: [PATCH] OMAP GPIO - don't wake from suspend unless requested.
On Thu, Sep 6, 2012 at 12:32 PM, NeilBrown ne...@suse.de wrote: On Thu, 6 Sep 2012 11:18:09 +0530 Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Thu, Sep 6, 2012 at 8:35 AM, NeilBrown ne...@suse.de wrote: On Mon, 3 Sep 2012 22:59:06 -0700 Shilimkar, Santosh santosh.shilim...@ti.com wrote: After thinking bit more on this, the problem seems to be coming mainly because the gpio device is runtime suspended bit early than it should be. Similar issue seen with i2c driver as well. The i2c issue was discussed with Rafael at LPC last week. The idea is to move the pm_runtime_enable/disable() calls entirely up to the _late/_early stage of device suspend/resume. Will update this thread once I have further update. This won't be late enough. IRQCHIP_MASK_ON_SUSPEND takes effect after all the _late callbacks have been called. I, too, spoke to Rafael about this in San Diego. He seemed to agree with me that the interrupt needs to be masked in the -suspend callback. any later is too late. Thanks for information about your discussion. Will wait for the patch then. Regards santosh I already sent a patch - that is what started this thread :-) I include it below. You said The patch doesn't seems to be correct but didn't expand on why. Do you still think it is not correct? I wouldn't be surprised if there is some case that it doesn't handle quite right, but it seems right to me. Sorry I though you were talking about moving the Checking wakeup interrupts bit early as discussed on the follow up of alternate suggested patch to make use of IRQCHIP_MASK_ON_SUSPEND. I think we need to fix the issue seen with ' IRQCHIP_MASK_ON_SUSPEND' patch. That is at least the expected way to manage suspend and wakeup irq masks for a IRQCHIP. 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] OMAP GPIO - don't wake from suspend unless requested.
On Thu, Sep 6, 2012 at 1:21 PM, NeilBrown ne...@suse.de wrote: On Thu, 6 Sep 2012 12:57:46 +0530 Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Thu, Sep 6, 2012 at 12:32 PM, NeilBrown ne...@suse.de wrote: On Thu, 6 Sep 2012 11:18:09 +0530 Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Thu, Sep 6, 2012 at 8:35 AM, NeilBrown ne...@suse.de wrote: On Mon, 3 Sep 2012 22:59:06 -0700 Shilimkar, Santosh santosh.shilim...@ti.com wrote: After thinking bit more on this, the problem seems to be coming mainly because the gpio device is runtime suspended bit early than it should be. Similar issue seen with i2c driver as well. The i2c issue was discussed with Rafael at LPC last week. The idea is to move the pm_runtime_enable/disable() calls entirely up to the _late/_early stage of device suspend/resume. Will update this thread once I have further update. This won't be late enough. IRQCHIP_MASK_ON_SUSPEND takes effect after all the _late callbacks have been called. I, too, spoke to Rafael about this in San Diego. He seemed to agree with me that the interrupt needs to be masked in the -suspend callback. any later is too late. Thanks for information about your discussion. Will wait for the patch then. Regards santosh I already sent a patch - that is what started this thread :-) I include it below. You said The patch doesn't seems to be correct but didn't expand on why. Do you still think it is not correct? I wouldn't be surprised if there is some case that it doesn't handle quite right, but it seems right to me. Sorry I though you were talking about moving the Checking wakeup interrupts bit early as discussed on the follow up of alternate suggested patch to make use of IRQCHIP_MASK_ON_SUSPEND. I think we need to fix the issue seen with ' IRQCHIP_MASK_ON_SUSPEND' patch. That is at least the expected way to manage suspend and wakeup irq masks for a IRQCHIP. That is what I thought at first too. But when talking to Rafael he said that IRQCHIP_MASK_ON_SUSPEND was intended mainly for clock interrupts. For other less fundamental interrupts, doing the mask/unmask in suspend/resume callbacks is sufficient and simpler... and actually works. That is not the how I undetand IRQCHIP_MASK_ON_SUSPEND use. I thought it can be used for any IRQ chip for masking or setting wakeup on interrupts lines managed by that chip for suspend. May be I am wrong. IRQCHIP_MASK_ON_SUSPEND is currently used by precisely two drivers: arch/arm/mach-omap2/omap-wakeupgen.c and drivers/mfd/pm8xxx-irq.c which suggests that it isn't widely used and quite possibly doesn't actually work in general. I have seen lot more platforms use in downstream kernels. Also seen recently patches on the linux-arm list for couple of platforms. Maybe we need to start a new thread and pester Rafael or Thomas Gleixner to either explain what is intended for this case, or to fix IRQCHIP_MASK_ON_SUSPEND so that it can be used in general. Sounds a good idea. Since you already had discussion with Rafael, probably you can describe the issue better. 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] ARM: OMAP4: Fix array size for irq_target_cpu
On Wed, Sep 5, 2012 at 5:11 PM, Benoit Cousson b-cous...@ti.com wrote: Hi Tony, On 09/05/2012 02:03 AM, Tony Lindgren wrote: If NR_IRQS is less than MAX_IRQS, we end up writing past the irq_target_cpu array in omap_wakeupgen_init(): /* Associate all the IRQs to boot CPU like GIC init does. */ for (i = 0; i max_irqs; i++) irq_target_cpu[i] = boot_cpu; This can happen if SPARSE_IRQ is enabled as by default NR_IRQS is set to 16. Without this patch we're overwriting other data during the boot. In fact I already sent a patch to fix that when I started my SPARSE_IRQ cleanup, but it looks like it was never merged :-( I guess I forgot a little bit that series. Indeed. I remember acking few patches in that series. Infact this patch set was the basis on which I was talking to Arnd that SPARSE_IRQ should work on OMAP. Didn't think that it has not made it yet in mainline. 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] OMAP GPIO - don't wake from suspend unless requested.
On Thu, Sep 6, 2012 at 8:35 AM, NeilBrown ne...@suse.de wrote:
On Mon, 3 Sep 2012 22:59:06 -0700 Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Sun, Aug 26, 2012 at 6:29 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Sun, Aug 26, 2012 at 3:53 PM, NeilBrown ne...@suse.de wrote:
On Sun, 26 Aug 2012 09:47:50 +0530 Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
+ Jon,
On Sat, Aug 25, 2012 at 5:14 PM, NeilBrown ne...@suse.de wrote:
Current kernel will wake from suspend on an event on any active
GPIO even if enable_irq_wake() wasn't called.
There are two reasons that the hardware wake-enable bit should be set:
1/ while non-suspended the CPU might go into a deep sleep (off_mode)
in which the wake-enable bit is needed for an interrupt to be
recognised.
2/ while suspended the GPIO interrupt should wake from suspend if and
only if irq_wake as been enabled.
The code currently doesn't keep these two reasons separate so they get
confused and sometimes the wakeup flags is set incorrectly.
This patch reverts:
commit 9c4ed9e6c01e7a8bd9079da8267e1f03cb4761fc
gpio/omap: remove suspend/resume callbacks
and
commit 0aa2727399c0b78225021413022c164cb99fbc5e
gpio/omap: remove suspend_wakeup field from struct gpio_bank
and makes some minor changes so that we have separate flags for GPIO
should wake from deep idle and GPIO should wake from suspend.
With this patch, the GPIO from my touch screen doesn't wake my device
any more, which is what I want.
Cc: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Govindraj.R govindraj.r...@ti.com
Signed-off-by: NeilBrown ne...@suse.de
The patch doesn't seems to be correct. At least the 2/ gets
fixed with a proper IRQCHIP flag. Can you try the patch at
end of the email and see if it helps ? Am attaching it in case
mailer damages it.
Regards
Santosh
From b8a38fc75e046f6462610e26c47c620cad850c24 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Sun, 26 Aug 2012 09:39:51 +0530
Subject: [PATCH] gpio: omap: Set IRQCHIP_MASK_ON_SUSPEND to mask all
non-wakeup gpio wakeups.
Set the irq chip flag IRQCHIP_MASK_ON_SUSPEND to cause the irq pm code
to mask all non-wake gpios in suspend, which will ensure the wakeup
enable
bit is not set on non-wake gpios.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/gpio/gpio-omap.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index e6efd77..50b4c18 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -779,6 +779,7 @@ static struct irq_chip gpio_irq_chip = {
.irq_unmask = gpio_unmask_irq,
.irq_set_type = gpio_irq_type,
.irq_set_wake = gpio_wake_enable,
+ .flags = IRQCHIP_MASK_ON_SUSPEND;
};
/*-*/
No obvious damage, unless the mailer is responsible or the ';' at the end
of
the line, rather than ',' :-)
:-) That was typo.
The approach makes sense, but does actually work. Should be fixable
though.
When I try this I get:
[ 158.114440] Checking wakeup interrupts
[ 158.118408] Unhandled fault: external abort on non-linefetch (0x1028)
at 0xfb054040
[ 158.126403] Internal error: : 1028 [#1] PREEMPT ARM
[ 158.131500] Modules linked in: ipv6 g_ether hso libertas_sdio libertas
cfg80211
[ 158.139190] CPU: 0Not tainted (3.5.0-gta04-debug+ #2)
[ 158.144927] PC is at _set_gpio_triggering+0x38/0x258
[ 158.150115] LR is at gpio_mask_irq+0xac/0xc0
[ 158.154602] pc : [c01d24a0]lr : [c01d2f68]psr: 6193
[ 158.154602] sp : db521e90 ip : 0011 fp : beeecc2c
[ 158.166595] r10: c05c8ebc r9 : daa5a858 r8 : 0003
[ 158.172027] r7 : a193 r6 : r5 : fb054000 r4 : ded44e18
[ 158.178863] r3 : 0001 r2 : r1 : ded30340 r0 : 0040
[ 158.185668] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM
Segment use
so it looks like runtime PM has turned off the iclk to the GPIO module so
that
when we try to tell it to change settings, it is no longer listening to
us.
From the crash logs it appears like that.
The Checking wakeup interrupts function happens very late in the suspend
cycle, after all the suspend_late and suspend_noirq functions have run.
Maybe it needs to be moved earlier...
No it shouldn't be moved and it is that point for lot many good
reasons. Ofcourse
Re: [PATCH] ARM: OMAP4: Fix array size for irq_target_cpu
On Wed, Sep 5, 2012 at 5:33 AM, Tony Lindgren t...@atomide.com wrote: If NR_IRQS is less than MAX_IRQS, we end up writing past the irq_target_cpu array in omap_wakeupgen_init(): /* Associate all the IRQs to boot CPU like GIC init does. */ for (i = 0; i max_irqs; i++) irq_target_cpu[i] = boot_cpu; This can happen if SPARSE_IRQ is enabled as by default NR_IRQS is set to 16. Without this patch we're overwriting other data during the boot. Signed-off-by: Tony Lindgren t...@atomide.com Looks good. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] ARM: OMAP: Few device tree patches for 3.7
On Mon, Sep 3, 2012 at 8:04 AM, Benoit Cousson b-cous...@ti.com wrote: Hi Santosh, Sorry for the delay, I missed that email :-( On 08/23/2012 09:32 AM, Santosh Shilimkar wrote: Benoit, On Monday 13 August 2012 04:30 PM, Santosh Shilimkar wrote: These are the few device tree related patches which has been posted and reviewed on the list. They are intended for 3.7 merge window but I am posting them early enough to get into linux-next and linux-omap for testing. The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee: Linux 3.6-rc1 (2012-08-02 16:38:10 -0700) are available in the git repository at: git://github.com/SantoshShilimkar/linux.git for_3.7/omap_dt for you to fetch changes up to bedee5fcb18062dfc933e0971e67fd6889c6446d: ARM: OMAP4: Add local timer support for Device Tree (2012-08-13 11:59:26 +0530) Aneesh V (3): dt: device tree bindings for LPDDR2 memories dt: emif: device tree bindings for TI's EMIF sdram controller ARM: dts: EMIF and LPDDR2 device tree data for OMAP4 boards Santosh Shilimkar (2): ARM: OMAP4: Add L2 Cache Controller in Device Tree ARM: OMAP4: Add local timer support for Device Tree Will you pull this series from above git url or do you want me to send a separate git pull request email ? I'll merge that branch on top of Sourav's and Peter's series and send the pull request to Tony. Thanks Benoit. 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] ARM: dts: OMAP4: Cleanup and move GIC outside of the OCP node
On Mon, Sep 3, 2012 at 9:20 AM, Benoit Cousson b-cous...@ti.com wrote: Remove a useless comment and move GIC controller outside of the OCP node since it does use the MPU internal bus and not the OCP. This will not change the functionality but will reflect the reality more accurately. Signed-off-by: Benoit Cousson b-cous...@ti.com --- Make sense. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP GPIO - don't wake from suspend unless requested.
On Sun, Aug 26, 2012 at 6:29 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Sun, Aug 26, 2012 at 3:53 PM, NeilBrown ne...@suse.de wrote:
On Sun, 26 Aug 2012 09:47:50 +0530 Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
+ Jon,
On Sat, Aug 25, 2012 at 5:14 PM, NeilBrown ne...@suse.de wrote:
Current kernel will wake from suspend on an event on any active
GPIO even if enable_irq_wake() wasn't called.
There are two reasons that the hardware wake-enable bit should be set:
1/ while non-suspended the CPU might go into a deep sleep (off_mode)
in which the wake-enable bit is needed for an interrupt to be
recognised.
2/ while suspended the GPIO interrupt should wake from suspend if and
only if irq_wake as been enabled.
The code currently doesn't keep these two reasons separate so they get
confused and sometimes the wakeup flags is set incorrectly.
This patch reverts:
commit 9c4ed9e6c01e7a8bd9079da8267e1f03cb4761fc
gpio/omap: remove suspend/resume callbacks
and
commit 0aa2727399c0b78225021413022c164cb99fbc5e
gpio/omap: remove suspend_wakeup field from struct gpio_bank
and makes some minor changes so that we have separate flags for GPIO
should wake from deep idle and GPIO should wake from suspend.
With this patch, the GPIO from my touch screen doesn't wake my device
any more, which is what I want.
Cc: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Govindraj.R govindraj.r...@ti.com
Signed-off-by: NeilBrown ne...@suse.de
The patch doesn't seems to be correct. At least the 2/ gets
fixed with a proper IRQCHIP flag. Can you try the patch at
end of the email and see if it helps ? Am attaching it in case
mailer damages it.
Regards
Santosh
From b8a38fc75e046f6462610e26c47c620cad850c24 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Sun, 26 Aug 2012 09:39:51 +0530
Subject: [PATCH] gpio: omap: Set IRQCHIP_MASK_ON_SUSPEND to mask all
non-wakeup gpio wakeups.
Set the irq chip flag IRQCHIP_MASK_ON_SUSPEND to cause the irq pm code
to mask all non-wake gpios in suspend, which will ensure the wakeup
enable
bit is not set on non-wake gpios.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/gpio/gpio-omap.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index e6efd77..50b4c18 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -779,6 +779,7 @@ static struct irq_chip gpio_irq_chip = {
.irq_unmask = gpio_unmask_irq,
.irq_set_type = gpio_irq_type,
.irq_set_wake = gpio_wake_enable,
+ .flags = IRQCHIP_MASK_ON_SUSPEND;
};
/*-*/
No obvious damage, unless the mailer is responsible or the ';' at the end
of
the line, rather than ',' :-)
:-) That was typo.
The approach makes sense, but does actually work. Should be fixable
though.
When I try this I get:
[ 158.114440] Checking wakeup interrupts
[ 158.118408] Unhandled fault: external abort on non-linefetch (0x1028)
at 0xfb054040
[ 158.126403] Internal error: : 1028 [#1] PREEMPT ARM
[ 158.131500] Modules linked in: ipv6 g_ether hso libertas_sdio libertas
cfg80211
[ 158.139190] CPU: 0Not tainted (3.5.0-gta04-debug+ #2)
[ 158.144927] PC is at _set_gpio_triggering+0x38/0x258
[ 158.150115] LR is at gpio_mask_irq+0xac/0xc0
[ 158.154602] pc : [c01d24a0]lr : [c01d2f68]psr: 6193
[ 158.154602] sp : db521e90 ip : 0011 fp : beeecc2c
[ 158.166595] r10: c05c8ebc r9 : daa5a858 r8 : 0003
[ 158.172027] r7 : a193 r6 : r5 : fb054000 r4 : ded44e18
[ 158.178863] r3 : 0001 r2 : r1 : ded30340 r0 : 0040
[ 158.185668] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM
Segment use
so it looks like runtime PM has turned off the iclk to the GPIO module so
that
when we try to tell it to change settings, it is no longer listening to
us.
From the crash logs it appears like that.
The Checking wakeup interrupts function happens very late in the suspend
cycle, after all the suspend_late and suspend_noirq functions have run.
Maybe it needs to be moved earlier...
No it shouldn't be moved and it is that point for lot many good
reasons. Ofcourse
this omap gpio driver crash needs to be addressed. Need to think bit
more on this
issue.
After thinking bit more on this, the problem seems to be coming
mainly because the gpio device is runtime suspended bit early than
it should be. Similar issue seen with i2c driver as well
Re: [PATCH 1/2] arm: omap: sram: fix OMAP4 errata handling
On Wed, Aug 29, 2012 at 8:24 AM, Aaro Koskinen aaro.koski...@iki.fi wrote: OMAP4-specific code should be executed only if we are running on OMAP4. Otherwise it may break multi-OMAP kernels. Found by reading the code. Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi --- Looks good. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] arm: omap: sram: skip the first 16K on OMAP3 HS
On Wed, Aug 29, 2012 at 8:24 AM, Aaro Koskinen aaro.koski...@iki.fi wrote: In some OMAP3 HS devices (at least Nokia N9 and N950), the public SRAM seems to conflict with secure portition of SRAM. When booting the 3.6-rc3 kernel (and also earlier) on these devices, the kernel gets tainted with tons of the following warnings: [6.894348] In-band Error seen by MPU at address 0 [...] [6.894378] WARNING: at arch/arm/mach-omap2/omap_l3_smx.c:162 Fix this by skipping the first 16K of the public SRAM. (Note that the mapping could not be changed, as it resulted in secure monitor call failure in save_secure_sram().) This will leave 12K SRAM available that should be still sufficient. The patch has been boot tested with vanilla 3.6-rc3 on N900, N950 and N9. Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi --- arch/arm/plat-omap/sram.c |9 ++--- 1 files changed, 6 insertions(+), 3 deletions(-) Looks good. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap: ratelimit omap_l3_smx error log spam
On Tue, Aug 28, 2012 at 5:20 AM, Aaro Koskinen aaro.koski...@iki.fi wrote: Hi, On Mon, Aug 27, 2012 at 05:17:30PM -0700, Shilimkar, Santosh wrote: On Mon, Aug 27, 2012 at 4:26 PM, Aaro Koskinen aaro.koski...@iki.fi wrote: I tried bypassing the whole SRAM init, but the device does not seem to boot up at all. If I comment out the memset alone, then it boots and the issue is gone: +#if 0 memset_io(omap_sram_base + SRAM_BOOTLOADER_SZ, 0, omap_sram_size - SRAM_BOOTLOADER_SZ); +#endif Good. So the issue is indeed direct or indirect access to the secure SRAM. As security can dynamically resize the secure RAM size it is even harder to fix this issue properly. One easier way to deal with the issue is map only needed SRAM and leave rest for security. For now, Can you check if reducing the size of the SRAM in init is helping you to get way with the issue. Sorry it might need few iterations for you to get a working SRAM size. The problem is triggered by writing to the beginning of the SRAM area, not to the end. I need to skip the first 16k (0x4000) to get rid of the errors. Maybe the base address calculation is wrong? This could also explain why it's still possible to use the device - it seems the allocator starts from the end, and moves towards the base... Or the PPA has resized the secure area of 16K. As you have seen the issue on one OMAP3 device, it makes sense to takeout that 16K from the public SRAM map. Can you send the patch with fixed base address fir PUB SRAM ? 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] arm: omap: ratelimit omap_l3_smx error log spam
On Tue, Aug 28, 2012 at 4:09 PM, Aaro Koskinen aaro.koski...@iki.fi wrote: Hi, On Tue, Aug 28, 2012 at 07:19:38AM -0700, Shilimkar, Santosh wrote: Or the PPA has resized the secure area of 16K. As you have seen the issue on one OMAP3 device, it makes sense to takeout that 16K from the public SRAM map. Can you send the patch with fixed base address fir PUB SRAM ? Maybe I'm missing something, but I tried the following and now something else got broken: save_secure_sram() returns ff02 Damn. Looks like, you are running short of memory now for sram_push stuff. 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] arm: omap: ratelimit omap_l3_smx error log spam
On Mon, Aug 27, 2012 at 2:03 PM, Aaro Koskinen aaro.koski...@iki.fi wrote: When booting kernel on RM-680/N950, the console is flooded with: [6.894348] In-band Error seen by MPU at address 0 [6.894348] [ cut here ] [6.894378] WARNING: at arch/arm/mach-omap2/omap_l3_smx.c:162 omap3_l3_app_irq+0xd4/0x12c() [6.894378] Modules linked in: [6.894409] Backtrace: [6.894409] [c0012440] (dump_backtrace+0x0/0x10c) from [c02fb698] (dump_stack+0x18/0x1c) [6.894439] r6:c002de58 r5:0009 r4: r3:c0880180 [6.894470] [c02fb680] (dump_stack+0x0/0x1c) from [c0039854] (warn_slowpath_common+0x54/0x6c) [6.894500] [c0039800] (warn_slowpath_common+0x0/0x6c) from [c0039890] (warn_slowpath_null+0x24/0x2c) [6.894500] r8:000a r7: r6:f8001400 r5: r4:84001b00 [6.894500] r3:0009 [6.894561] [c003986c] (warn_slowpath_null+0x0/0x2c) from [c002de58] (omap3_l3_app_irq+0xd4/0x12c) [6.894561] [c002dd84] (omap3_l3_app_irq+0x0/0x12c) from [c008561c] (handle_irq_event_percpu+0x54/0x19c) [6.894592] r7: r6: r5:c082c710 r4:ef072340 [6.894622] [c00855c8] (handle_irq_event_percpu+0x0/0x19c) from [c00857c4] (handle_irq_event+0x60/0x80) [6.894653] [c0085764] (handle_irq_event+0x0/0x80) from [c0088300] (handle_level_irq+0xb4/0x134) [6.894653] r5:c082c710 r4:c082c6c0 [6.894683] [c008824c] (handle_level_irq+0x0/0x134) from [c0084e18] (generic_handle_irq+0x2c/0x44) [6.894683] r6:ef02c000 r5:c0829014 r4:c0841e18 r3:c008824c [6.894744] [c0084dec] (generic_handle_irq+0x0/0x44) from [c000f228] (handle_IRQ+0x54/0xb8) [6.894744] [c000f1d4] (handle_IRQ+0x0/0xb8) from [c000873c] (omap3_intc_handle_irq+0x68/0x7c) [6.894775] r8:c08415cc r7:000a r6:c0898c38 r5:ef02de88 r4:fa20 [6.894775] r3: [6.894805] [c00086d4] (omap3_intc_handle_irq+0x0/0x7c) from [c0302e80] (__irq_svc+0x40/0x54) [6.894836] Exception stack(0xef02de88 to 0xef02ded0) [6.894836] de80: f0048000 7000 3035 f004bfca [6.894866] dea0: c08415cc c0898140 ef02c000 ef02def4 ef02 def8 ef02ded0 [6.894866] dec0: c042b1dc c0016efc 2013 [6.894897] r7:ef02debc r6: r5:2013 r4:c0016efc [6.894927] [c0016ed0] (_memset_io+0x0/0x50) from [c042b1dc] (omap_sram_init+0x228/0x56c) [6.894927] r8:c0445cf4 r7:c0417208 r6:c0898140 r5:c0899840 r4:c0899a3c [6.894927] r3:f004f000 [6.894989] [c042afb4] (omap_sram_init+0x0/0x56c) from [c041f01c] (omap_sdrc_init+0x18/0xb8) [6.894989] r6:c0898140 r5:c0899840 r4:c0899840 r3:0005e601 [6.895019] [c041f004] (omap_sdrc_init+0x0/0xb8) from [c0427e38] (rm680_init+0x34/0xc0) [6.895050] r5:c04518e0 r4:c0875da0 [6.895080] [c0427e04] (rm680_init+0x0/0xc0) from [c0419934] (customize_machine+0x24/0x30) [6.895080] r5:0003 r4: [6.895111] [c0419910] (customize_machine+0x0/0x30) from [c00088e0] (do_one_initcall+0x11c/0x184) [6.895141] [c00087c4] (do_one_initcall+0x0/0x184) from [c041799c] (kernel_init+0x100/0x1c4) [6.895141] [c041789c] (kernel_init+0x0/0x1c4) from [c003ef18] (do_exit+0x0/0x794) [6.895172] ---[ end trace 1b75b31a271a0d00 ]--- This is repeated maybe a thousand times. While the root cause remains unknown (they seem to occur during SDRC and DMA init), the errors should be at least ratelimited so that user will also have chance to see other boot messages. Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi --- arch/arm/mach-omap2/omap_l3_smx.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/omap_l3_smx.c b/arch/arm/mach-omap2/omap_l3_smx.c index acc2164..e3b4948 100644 --- a/arch/arm/mach-omap2/omap_l3_smx.c +++ b/arch/arm/mach-omap2/omap_l3_smx.c @@ -155,11 +155,11 @@ static irqreturn_t omap3_l3_block_irq(struct omap3_l3 *l3, u8 multi = error L3_ERROR_LOG_MULTI; u32 address = omap3_l3_decode_addr(error_addr); - pr_err(%s seen by %s %s at address %x\n, + pr_err_ratelimited(%s seen by %s %s at address %x\n, omap3_l3_code_string(code), omap3_l3_initiator_string(initid), multi ? Multiple Errors : , address); - WARN_ON(1); + WARN_ON_ONCE(1); The issue needs to be fixed instead of WARN_ON_ONCE() and then just moving ahead. Interconnect in bad states is really bad state and you won't have reliable operations post that on SOC. 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] arm: omap: ratelimit omap_l3_smx error log spam
On Mon, Aug 27, 2012 at 3:02 PM, Aaro Koskinen aaro.koski...@iki.fi wrote:
Hi,
On Mon, Aug 27, 2012 at 02:35:57PM -0700, Shilimkar, Santosh wrote:
- pr_err(%s seen by %s %s at address %x\n,
+ pr_err_ratelimited(%s seen by %s %s at address %x\n,
omap3_l3_code_string(code),
omap3_l3_initiator_string(initid),
multi ? Multiple Errors : , address);
- WARN_ON(1);
+ WARN_ON_ONCE(1);
The issue needs to be fixed instead of WARN_ON_ONCE() and then
just moving ahead. Interconnect in bad states is really bad state and you
won't have reliable operations post that on SOC.
How printing megabytes of identical stack traces helps anything?
It just says repeatedly and loudly... Fix the issue :-)
This has been there always (since the L3 driver was added) on every boot
with N950/N9 (which BTW are HS devices, not sure if that has anything
to do with it). There is no apparent effect on device functionality,
at least nothing unusual has been observed...
I assumed this is secure device when I saw the SRAM memset is causing the
issue.
Is there any documentation how to interpret and debug this error report?
The issue could be, there is memset tried on Secure portion of SRAM or
CPU speculatively accessed adjacent SRAM region of public SRAM which
is secure and hence the error.
If you just bypass the SRAM init [1], does the issue go away ?
Regards
Santosh
[1]
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index 766181c..305e6de 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -384,6 +384,7 @@ static inline int am33xx_sram_init(void)
int __init omap_sram_init(void)
{
+#if 0
omap_detect_sram();
omap_map_sram();
@@ -397,6 +398,6 @@ int __init omap_sram_init(void)
am33xx_sram_init();
else if (cpu_is_omap34xx())
omap34xx_sram_init();
-
+#endif
return 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
Re: [PATCH] ARM: OMAP: timer: obey the !CONFIG_OMAP_32K_TIMER
On Mon, Aug 27, 2012 at 3:26 PM, Igor Grinberg grinb...@compulab.co.il wrote: Currently, omap2_sync32k_clocksource_init() function initializes the 32K timer as the system clock source regardless of the CONFIG_OMAP_32K_TIMER setting. Fix this by providing a default implementation for !CONFIG_OMAP_32K_TIMER case. Signed-off-by: Igor Grinberg grinb...@compulab.co.il Reviewed-by: Paul Walmsley p...@pwsan.com --- Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap: ratelimit omap_l3_smx error log spam
On Mon, Aug 27, 2012 at 4:26 PM, Aaro Koskinen aaro.koski...@iki.fi wrote: On Mon, Aug 27, 2012 at 03:12:07PM -0700, Shilimkar, Santosh wrote: On Mon, Aug 27, 2012 at 3:02 PM, Aaro Koskinen aaro.koski...@iki.fi wrote: Hi, On Mon, Aug 27, 2012 at 02:35:57PM -0700, Shilimkar, Santosh wrote: - pr_err(%s seen by %s %s at address %x\n, + pr_err_ratelimited(%s seen by %s %s at address %x\n, omap3_l3_code_string(code), omap3_l3_initiator_string(initid), multi ? Multiple Errors : , address); - WARN_ON(1); + WARN_ON_ONCE(1); The issue needs to be fixed instead of WARN_ON_ONCE() and then just moving ahead. Interconnect in bad states is really bad state and you won't have reliable operations post that on SOC. How printing megabytes of identical stack traces helps anything? It just says repeatedly and loudly... Fix the issue :-) This has been there always (since the L3 driver was added) on every boot with N950/N9 (which BTW are HS devices, not sure if that has anything to do with it). There is no apparent effect on device functionality, at least nothing unusual has been observed... I assumed this is secure device when I saw the SRAM memset is causing the issue. Is there any documentation how to interpret and debug this error report? The issue could be, there is memset tried on Secure portion of SRAM or CPU speculatively accessed adjacent SRAM region of public SRAM which is secure and hence the error. Thanks, that makes sense. If you just bypass the SRAM init [1], does the issue go away ? I tried bypassing the whole SRAM init, but the device does not seem to boot up at all. If I comment out the memset alone, then it boots and the issue is gone: +#if 0 memset_io(omap_sram_base + SRAM_BOOTLOADER_SZ, 0, omap_sram_size - SRAM_BOOTLOADER_SZ); +#endif Good. So the issue is indeed direct or indirect access to the secure SRAM. As security can dynamically resize the secure RAM size it is even harder to fix this issue properly. One easier way to deal with the issue is map only needed SRAM and leave rest for security. For now, Can you check if reducing the size of the SRAM in init is helping you to get way with the issue. Sorry it might need few iterations for you to get a working SRAM size. 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] OMAP GPIO - don't wake from suspend unless requested.
On Sun, Aug 26, 2012 at 3:53 PM, NeilBrown ne...@suse.de wrote:
On Sun, 26 Aug 2012 09:47:50 +0530 Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
+ Jon,
On Sat, Aug 25, 2012 at 5:14 PM, NeilBrown ne...@suse.de wrote:
Current kernel will wake from suspend on an event on any active
GPIO even if enable_irq_wake() wasn't called.
There are two reasons that the hardware wake-enable bit should be set:
1/ while non-suspended the CPU might go into a deep sleep (off_mode)
in which the wake-enable bit is needed for an interrupt to be
recognised.
2/ while suspended the GPIO interrupt should wake from suspend if and
only if irq_wake as been enabled.
The code currently doesn't keep these two reasons separate so they get
confused and sometimes the wakeup flags is set incorrectly.
This patch reverts:
commit 9c4ed9e6c01e7a8bd9079da8267e1f03cb4761fc
gpio/omap: remove suspend/resume callbacks
and
commit 0aa2727399c0b78225021413022c164cb99fbc5e
gpio/omap: remove suspend_wakeup field from struct gpio_bank
and makes some minor changes so that we have separate flags for GPIO
should wake from deep idle and GPIO should wake from suspend.
With this patch, the GPIO from my touch screen doesn't wake my device
any more, which is what I want.
Cc: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Govindraj.R govindraj.r...@ti.com
Signed-off-by: NeilBrown ne...@suse.de
The patch doesn't seems to be correct. At least the 2/ gets
fixed with a proper IRQCHIP flag. Can you try the patch at
end of the email and see if it helps ? Am attaching it in case
mailer damages it.
Regards
Santosh
From b8a38fc75e046f6462610e26c47c620cad850c24 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Sun, 26 Aug 2012 09:39:51 +0530
Subject: [PATCH] gpio: omap: Set IRQCHIP_MASK_ON_SUSPEND to mask all
non-wakeup gpio wakeups.
Set the irq chip flag IRQCHIP_MASK_ON_SUSPEND to cause the irq pm code
to mask all non-wake gpios in suspend, which will ensure the wakeup
enable
bit is not set on non-wake gpios.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/gpio/gpio-omap.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index e6efd77..50b4c18 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -779,6 +779,7 @@ static struct irq_chip gpio_irq_chip = {
.irq_unmask = gpio_unmask_irq,
.irq_set_type = gpio_irq_type,
.irq_set_wake = gpio_wake_enable,
+ .flags = IRQCHIP_MASK_ON_SUSPEND;
};
/*-*/
No obvious damage, unless the mailer is responsible or the ';' at the end
of
the line, rather than ',' :-)
:-) That was typo.
The approach makes sense, but does actually work. Should be fixable
though.
When I try this I get:
[ 158.114440] Checking wakeup interrupts
[ 158.118408] Unhandled fault: external abort on non-linefetch (0x1028)
at 0xfb054040
[ 158.126403] Internal error: : 1028 [#1] PREEMPT ARM
[ 158.131500] Modules linked in: ipv6 g_ether hso libertas_sdio libertas
cfg80211
[ 158.139190] CPU: 0Not tainted (3.5.0-gta04-debug+ #2)
[ 158.144927] PC is at _set_gpio_triggering+0x38/0x258
[ 158.150115] LR is at gpio_mask_irq+0xac/0xc0
[ 158.154602] pc : [c01d24a0]lr : [c01d2f68]psr: 6193
[ 158.154602] sp : db521e90 ip : 0011 fp : beeecc2c
[ 158.166595] r10: c05c8ebc r9 : daa5a858 r8 : 0003
[ 158.172027] r7 : a193 r6 : r5 : fb054000 r4 : ded44e18
[ 158.178863] r3 : 0001 r2 : r1 : ded30340 r0 : 0040
[ 158.185668] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM
Segment use
so it looks like runtime PM has turned off the iclk to the GPIO module so
that
when we try to tell it to change settings, it is no longer listening to
us.
From the crash logs it appears like that.
The Checking wakeup interrupts function happens very late in the suspend
cycle, after all the suspend_late and suspend_noirq functions have run.
Maybe it needs to be moved earlier...
No it shouldn't be moved and it is that point for lot many good
reasons. Ofcourse
this omap gpio driver crash needs to be addressed. Need to think bit
more on this
issue.
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] OMAP GPIO - don't wake from suspend unless requested.
+ Jon,
On Sat, Aug 25, 2012 at 5:14 PM, NeilBrown ne...@suse.de wrote:
Current kernel will wake from suspend on an event on any active
GPIO even if enable_irq_wake() wasn't called.
There are two reasons that the hardware wake-enable bit should be set:
1/ while non-suspended the CPU might go into a deep sleep (off_mode)
in which the wake-enable bit is needed for an interrupt to be
recognised.
2/ while suspended the GPIO interrupt should wake from suspend if and
only if irq_wake as been enabled.
The code currently doesn't keep these two reasons separate so they get
confused and sometimes the wakeup flags is set incorrectly.
This patch reverts:
commit 9c4ed9e6c01e7a8bd9079da8267e1f03cb4761fc
gpio/omap: remove suspend/resume callbacks
and
commit 0aa2727399c0b78225021413022c164cb99fbc5e
gpio/omap: remove suspend_wakeup field from struct gpio_bank
and makes some minor changes so that we have separate flags for GPIO
should wake from deep idle and GPIO should wake from suspend.
With this patch, the GPIO from my touch screen doesn't wake my device
any more, which is what I want.
Cc: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Cousson, Benoit b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Govindraj.R govindraj.r...@ti.com
Signed-off-by: NeilBrown ne...@suse.de
The patch doesn't seems to be correct. At least the 2/ gets
fixed with a proper IRQCHIP flag. Can you try the patch at
end of the email and see if it helps ? Am attaching it in case
mailer damages it.
Regards
Santosh
From b8a38fc75e046f6462610e26c47c620cad850c24 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Sun, 26 Aug 2012 09:39:51 +0530
Subject: [PATCH] gpio: omap: Set IRQCHIP_MASK_ON_SUSPEND to mask all
non-wakeup gpio wakeups.
Set the irq chip flag IRQCHIP_MASK_ON_SUSPEND to cause the irq pm code
to mask all non-wake gpios in suspend, which will ensure the wakeup enable
bit is not set on non-wake gpios.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/gpio/gpio-omap.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index e6efd77..50b4c18 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -779,6 +779,7 @@ static struct irq_chip gpio_irq_chip = {
.irq_unmask = gpio_unmask_irq,
.irq_set_type = gpio_irq_type,
.irq_set_wake = gpio_wake_enable,
+ .flags = IRQCHIP_MASK_ON_SUSPEND;
};
/*-*/
--
1.7.9.5
0001-gpio-omap-Set-IRQCHIP_MASK_ON_SUSPEND-to-mask-all-no.patch
Description: Binary data
Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
On Fri, Aug 24, 2012 at 2:30 AM, Peter Meerwald pme...@pmeerw.net wrote: On Wed, 18 Jul 2012, Javier Martinez Canillas wrote: On Wed, Jul 18, 2012 at 10:36 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: On Wed, Jul 18, 2012 at 1:14 PM, S, Venkatraman svenk...@ti.com wrote: On Wed, Jul 18, 2012 at 12:40 PM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120718 00:09]: On Wed, Jul 18, 2012 at 12:29 PM, Tony Lindgren t...@atomide.com wrote: * Javier Martinez Canillas jav...@dowhile0.org [120716 23:56]: On Tue, Jul 17, 2012 at 8:45 AM, Shilimkar, Santosh santosh.shilim...@ti.com wrote: Hi, On Tue, Jul 17, 2012 at 6:00 AM, Javier Martinez Canillas jav...@dowhile0.org wrote: The OMAP MMC and OMAP High Speed MMC hosts now use entirely the DMA engine API instead of the previous private DMA API implementation. So, if the kernel is built with support for any of these hosts but it doesn't support DMA devices nor OMAP DMA support, it fails when trying to obtain a DMA channel which leads to the following error on an OMAP3 IGEPv2 Rev.C board (and probably on most OMAP boards with MMC support): [ 2.199981] omap_hsmmc omap_hsmmc.1: unable to obtain RX DMA engine channel 48 [2.215087] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine channel 62 selecting automatically CONFIG_DMADEVICES and CONFIG_DMA_OMAP solves it. Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org --- Considering, we are updating drivers to select the DMA engine, can you also include drivers/spi/spi-omap2-mcspi.c which is also updated for DMA engine. Regards Santosh Hi Santosh, Ok, I'll send a v2 now which includes spi-omap2-mcspi then. I don't think we should do this, the drivers should work with and without dma. This just needs to be added to the omap2plus_defconfig. Well this was not decided based on any DMA CONFIG option before for the subject drivers. It is already by default enabled if the DMA is supported by the driver IP. There is a possibility to disable it from driver platform/dt data so that still remains. I think it should rather be that if the driver is broken and does not work without DMA, it should have depends on CONFIG_DMA_OMAP. I can confirm that omap MMC can't work without DMA; polled mode is not supported / implemented. Same case for SPI driver as well. It uses DMA for everything except the cases where DMA doesn't make sense like 1 byte/2 byte etc. And its not configurable, At least considering this, it is better we do this per driver than enabling it at SOC config. Regards Santosh -- Hi Santosh, And what about enabling it at the SoC config level but making the drivers dependant on CONFIG_DMADEVICES and CONFIG_DMA_OMAP? If you agree I can send something like this in two different patches (one for the omap2plus_defconfig and another to make the drivers dependant on the config option): diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index b152de7..e58edc3 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -193,6 +193,8 @@ CONFIG_MMC_OMAP_HS=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_TWL92330=y CONFIG_RTC_DRV_TWL4030=y +CONFIG_DMADEVICES=y +CONFIG_DMA_OMAP=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set above has been merged, 89269ef1f0abc72c551198123e19cd4edfd43cf4 but I am missing the patches below in mainline (3.6-rc3) -- what happened? as Javier pointed out in https://patchwork.kernel.org/patch/1203391/, MMC is broken support e.g. on beagleboard unless DMA_OMAP is defined I suggest to take below patches and help to avoid some extra gray hair for people looking for a fix for non-booting beagleboards May be I am missing something, but why you would need below patch for beagle with 89269ef1f0abc72c551198123e19cd4edfd43cf4 commit enabling the DMA_OMAP for all OMAP boards. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
On Fri, Aug 24, 2012 at 3:12 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Aug 24, 2012 at 09:51:15AM +0200, Peter Meerwald wrote: the commit just sets CONFIG_DMA_OMAP=y and CONFIG_DMADEVICES=y in omap2plus_defconfig; this does not help people updating the kernel while keeping the config, nor does it help people in configuring the kernel there is a dependency (at least for beagleboard) between MMC_OMAP_HS and DMA_OMAP, and I think this should be made explicit Well, this is where stuff starts to get really yucky, because that means if you have DMA_OMAP as a module, you have to have MMC_OMAP_HS as a module too. Or vice versa. Which is a real pain for further development of DMA_OMAP. Whatever, the solution here is NOT to add select statements to the Kconfig to force DMA engine support and DMA_OMAP to 'y' for OMAP. The best solution is for MMC_OMAP_HS to depend on DMA_OMAP, but that will just mean that you'll end up with MMC_OMAP_HS disabled in your config witout DMA engine support. Another less desirable solution is to have MMC_OMAP_HS select DMA engine and DMA_OMAP. Part of the patch [1] does the last part. MMC_OMAP_HS select DMA engine and DMA_OMAP. Regards Santosh [1] https://patchwork.kernel.org/patch/1203391/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] mmc: host: enable OMAP DMA engine support for omap hosts by default
On Fri, Aug 24, 2012 at 4:09 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Aug 24, 2012 at 03:51:26PM +0530, Shilimkar, Santosh wrote: On Fri, Aug 24, 2012 at 3:12 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Aug 24, 2012 at 09:51:15AM +0200, Peter Meerwald wrote: the commit just sets CONFIG_DMA_OMAP=y and CONFIG_DMADEVICES=y in omap2plus_defconfig; this does not help people updating the kernel while keeping the config, nor does it help people in configuring the kernel there is a dependency (at least for beagleboard) between MMC_OMAP_HS and DMA_OMAP, and I think this should be made explicit Well, this is where stuff starts to get really yucky, because that means if you have DMA_OMAP as a module, you have to have MMC_OMAP_HS as a module too. Or vice versa. Which is a real pain for further development of DMA_OMAP. Whatever, the solution here is NOT to add select statements to the Kconfig to force DMA engine support and DMA_OMAP to 'y' for OMAP. The best solution is for MMC_OMAP_HS to depend on DMA_OMAP, but that will just mean that you'll end up with MMC_OMAP_HS disabled in your config witout DMA engine support. Another less desirable solution is to have MMC_OMAP_HS select DMA engine and DMA_OMAP. Part of the patch [1] does the last part. MMC_OMAP_HS select DMA engine and DMA_OMAP. Regards Santosh [1] https://patchwork.kernel.org/patch/1203391/ Well, I never saw that patch. When I say I'm going to be away for most of July, and I won't be reading email, and I won't catch up with email when I'm back and when I get back I explicitly ask for stuff which needs my attention sending, that's hardly surprising... But anyway, as I said above, the select option is less desirable because it forces stuff. And if you've seen the kind of crap that you have to go through to figure out why the hell you can't disable an option, you'll understand why I consider that solution revolting. Take, for instance, a list of dependencies spits out by menuconfig that fills your entire screen, and you have to work out by reading carefully through 2K of characters which combination of options is forcing the one you want to turn off back on. That is why select used inappropriately is pure evil incarnate. I fully agree on the select and it's undesirable side effects. Since the polling mode isn't supported yet on OMAP MMC drivers, there was no choice. As per the previous discussion on [1], MMC and SPI driver folks are looking at supporting polling mode support which can remove the force select needed for OMAP_DMA. Regards santosh 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 4/5] ARM: OMAP4: Add L2 Cache Controller in Device Tree
On Mon, Aug 20, 2012 at 9:21 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Mon, Aug 20, 2012 at 7:21 PM, Benoit Cousson b-cous...@ti.com wrote:
Hi Santosh,
On 08/13/2012 01:00 PM, Santosh Shilimkar wrote:
This provides PL310 Level 2 Cache Controller Device Tree
support for OMAP4 based devices.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |7 +++
arch/arm/mach-omap2/omap4-common.c |6 +-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 6717c71..cf1efb6 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -36,6 +36,13 @@
};
};
+ L2: l2-cache-controller {
The reg offset is missing: l2-cache-controller@48242000
+ compatible = arm,pl310-cache;
+ reg = 0x48242000 0x1000;
+ cache-unified;
+ cache-level = 2;
+ };
+
In theory, the L2 cache should be referenced from the CPUs.
Agree.
I have added the reference for the L2 controller in CPUs.
Other information like L1 cache size etc can be added in cpu
DT node with another patch.
Updated patch below. Have also updated git branch
accordingly.
Regards
Santosh
From 91d6cb4f999061c8cfc844a3916ee3384f2e488a Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Wed, 4 Jul 2012 17:57:34 +0530
Subject: [PATCH 1/2 v2] ARM: OMAP4: Add L2 Cache Controller in Device Tree
This provides PL310 Level 2 Cache Controller Device Tree
support for OMAP4 based devices.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |9 +
arch/arm/mach-omap2/omap4-common.c |6 +-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 6717c71..0229dd2 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -30,12 +30,21 @@
cpus {
cpu@0 {
compatible = arm,cortex-a9;
+ next-level-cache = L2;
};
cpu@1 {
compatible = arm,cortex-a9;
+ next-level-cache = L2;
};
};
+ L2: l2-cache-controller@48242000 {
+ compatible = arm,pl310-cache;
+ reg = 0x48242000 0x1000;
+ cache-unified;
+ cache-level = 2;
+ };
+
/*
* The soc node represents the soc top level view. It is uses for IPs
* that are not memory mapped in the MPU view or for the MPU itself.
diff --git a/arch/arm/mach-omap2/omap4-common.c
b/arch/arm/mach-omap2/omap4-common.c
index c29dee9..6f95992 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -16,6 +16,7 @@
#include linux/io.h
#include linux/platform_device.h
#include linux/memblock.h
+#include linux/of.h
#include asm/hardware/gic.h
#include asm/hardware/cache-l2x0.h
@@ -171,7 +172,10 @@ static int __init omap_l2_cache_init(void)
/* Enable PL310 L2 Cache controller */
omap_smc1(0x102, 0x1);
- l2x0_init(l2cache_base, aux_ctrl, L2X0_AUX_CTRL_MASK);
+ if (of_have_populated_dt())
+ l2x0_of_init(aux_ctrl, L2X0_AUX_CTRL_MASK);
+ else
+ l2x0_init(l2cache_base, aux_ctrl, L2X0_AUX_CTRL_MASK);
/*
* Override default outer_cache.disable with a OMAP4
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 05/13] serial: omap: drop DMA support
On Tue, Aug 21, 2012 at 2:45 PM, Felipe Balbi ba...@ti.com wrote: The current support is known to be broken and a later patch will come re-adding it using dma engine API. Signed-off-by: Felipe Balbi ba...@ti.com --- Thanks Felipe !! One less driver now towards OMAP DMA engine conversion. FWIW, Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] ARM: OMAP4: Add L2 Cache Controller in Device Tree
On Tue, Aug 21, 2012 at 3:54 PM, Felipe Balbi ba...@ti.com wrote:
On Tue, Aug 21, 2012 at 03:11:51PM +0530, Shilimkar, Santosh wrote:
On Mon, Aug 20, 2012 at 9:21 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Mon, Aug 20, 2012 at 7:21 PM, Benoit Cousson b-cous...@ti.com wrote:
Hi Santosh,
On 08/13/2012 01:00 PM, Santosh Shilimkar wrote:
This provides PL310 Level 2 Cache Controller Device Tree
support for OMAP4 based devices.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |7 +++
arch/arm/mach-omap2/omap4-common.c |6 +-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 6717c71..cf1efb6 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -36,6 +36,13 @@
};
};
+ L2: l2-cache-controller {
The reg offset is missing: l2-cache-controller@48242000
+ compatible = arm,pl310-cache;
+ reg = 0x48242000 0x1000;
+ cache-unified;
+ cache-level = 2;
+ };
+
In theory, the L2 cache should be referenced from the CPUs.
Agree.
I have added the reference for the L2 controller in CPUs.
Other information like L1 cache size etc can be added in cpu
DT node with another patch.
Updated patch below. Have also updated git branch
accordingly.
Regards
Santosh
From 91d6cb4f999061c8cfc844a3916ee3384f2e488a Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Wed, 4 Jul 2012 17:57:34 +0530
Subject: [PATCH 1/2 v2] ARM: OMAP4: Add L2 Cache Controller in Device Tree
This provides PL310 Level 2 Cache Controller Device Tree
support for OMAP4 based devices.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
nice work :-)
FWIW this looks good to me:
Acked-by: Felipe Balbi ba...@ti.com
Thanks.
just one thing, will a similar patch for omap3 be sent ?
OMAP3 has an integrated L2 cache controller so there
won't any additional DT node for L2.
OMAP3 CPU DT node can be updated with l1/l2 cache
size etc related information though.
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: [RFC/PATCH 05/13] serial: omap: drop DMA support
On Tue, Aug 21, 2012 at 3:50 PM, Felipe Balbi ba...@ti.com wrote: On Tue, Aug 21, 2012 at 03:14:19PM +0530, Shilimkar, Santosh wrote: On Tue, Aug 21, 2012 at 2:45 PM, Felipe Balbi ba...@ti.com wrote: The current support is known to be broken and a later patch will come re-adding it using dma engine API. Signed-off-by: Felipe Balbi ba...@ti.com --- Thanks Felipe !! no problem. One less driver now towards OMAP DMA engine conversion. indeed :-) I'll take a closer look into rx timeout IRQ, but it looks like we can use it to kick dma only for big transfers... need to play with it for a while first, though. Yep. The RX path with DMA is bit of difficult part to manage for UART. FWIW, Acked-by: Santosh Shilimkar santosh.shilim...@ti.com is this Ack for this patch only or the entire series ?? Two more patches to review and then I will do it for full series on top of the cover-letter :-) 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: [RFC/PATCH 10/13] serial: omap: stick to put_autosuspend
On Tue, Aug 21, 2012 at 2:45 PM, Felipe Balbi ba...@ti.com wrote: Everytime we're done using our TTY, we want the pm timer to be reinitilized. By sticking to pm_runtime_pm_autosuspend() we make sure that this will always be the case. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/tty/serial/omap-serial.c | 33 ++--- 1 file changed, 22 insertions(+), 11 deletions(-) diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index 6ea24c5..458d77c 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -164,7 +164,8 @@ static void serial_omap_enable_ms(struct uart_port *port) pm_runtime_get_sync(up-dev); up-ier |= UART_IER_MSI; serial_out(up, UART_IER, up-ier); - pm_runtime_put(up-dev); + pm_runtime_mark_last_busy(up-dev); + pm_runtime_put_autosuspend(up-dev); } Can you please expand the change-log a bit ? Didn't follow the time re-init part completely. 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: [RFC/PATCH 00/13] OMAP UART patches
On Tue, Aug 21, 2012 at 2:45 PM, Felipe Balbi ba...@ti.com wrote: Hi guys, here's a series of cleanup patches to the OMAP serial driver. A later series could be made re-implementing DMA using the DMA Engine API. Note that for RX DMA we could be using RX Timeout IRQ as a hint that we better use PIO instead ;-) All patches were tested on my pandaboard, but I'd really like to receive Tested-by on other platforms. After this goes in, I'll probably try to get UART wakeup working again and only after that look at DMA. cheers Felipe Balbi (13): serial: omap: define and use to_uart_omap_port() serial: omap: always return IRQ_HANDLED serial: omap: define helpers for pdata function pointers serial: omap: don't access the platform_device serial: omap: drop DMA support serial: add OMAP-specific defines serial: omap: simplify IRQ handling serial: omap: refactor receive_chars() into rdi/rlsi handlers serial: omap: move THRE check to transmit_chars() serial: omap: stick to put_autosuspend serial: omap: set dev-drvdata before enabling pm_runtime serial: omap: drop unnecessary check from remove serial: omap: make sure to suspend device before remove Apart from that one question on last patch, rest of the clean-up is really good. Nice work. FWIW, Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] ARM: OMAP4: Add L2 Cache Controller in Device Tree
On Tue, Aug 21, 2012 at 4:14 PM, Benoit Cousson b-cous...@ti.com wrote: Hi Santosh, [...] From 91d6cb4f999061c8cfc844a3916ee3384f2e488a Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar santosh.shilim...@ti.com Date: Wed, 4 Jul 2012 17:57:34 +0530 Subject: [PATCH 1/2 v2] ARM: OMAP4: Add L2 Cache Controller in Device Tree This provides PL310 Level 2 Cache Controller Device Tree support for OMAP4 based devices. Cc: Benoit Cousson b-cous...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com nice work :-) FWIW this looks good to me: Acked-by: Felipe Balbi ba...@ti.com Thanks. just one thing, will a similar patch for omap3 be sent ? OMAP3 has an integrated L2 cache controller so there won't any additional DT node for L2. OMAP3 CPU DT node can be updated with l1/l2 cache size etc related information though. That's not needed if the information is available from the HW. DT is only there to provide information that cannot be extracted from HW. Good to know. If CP15 registers already contains the details about caches, then there is no need to add them in the DT file. True. In that case as you said, there is no need to add that information in DT. 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: [RFC/PATCH 10/13] serial: omap: stick to put_autosuspend
On Tue, Aug 21, 2012 at 4:27 PM, Felipe Balbi ba...@ti.com wrote: On Tue, Aug 21, 2012 at 04:12:11PM +0530, Shilimkar, Santosh wrote: On Tue, Aug 21, 2012 at 2:45 PM, Felipe Balbi ba...@ti.com wrote: Everytime we're done using our TTY, we want the pm timer to be reinitilized. By sticking to pm_runtime_pm_autosuspend() we make sure that this will always be the case. Signed-off-by: Felipe Balbi ba...@ti.com --- drivers/tty/serial/omap-serial.c | 33 ++--- 1 file changed, 22 insertions(+), 11 deletions(-) diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index 6ea24c5..458d77c 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -164,7 +164,8 @@ static void serial_omap_enable_ms(struct uart_port *port) pm_runtime_get_sync(up-dev); up-ier |= UART_IER_MSI; serial_out(up, UART_IER, up-ier); - pm_runtime_put(up-dev); + pm_runtime_mark_last_busy(up-dev); + pm_runtime_put_autosuspend(up-dev); } Can you please expand the change-log a bit ? Didn't follow the time re-init part completely. It's really just a micro-optimization. The thing is: if I call pm_runtime_put(), I will not reinitialize the pm timer to whatever timeout value I used. This means that pm_runtime_put() could actually execute right away (if timer was about to expire when I called pm_runtime_put()). While this wouldn't cause any issues, it's better to reinitialize the timer and make sure if there's another read/write/set_termios/whatever coming right after this, UART is still powered up. I mean, it's really just trying to avoid context save restore when UART is still under heavy usage. Does it make sense ? It does. Would be good to add the above description in the change-log. Thanks for clarification. Regars 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] omap-hsmmc: Implementation of i761 errata
On Mon, Aug 20, 2012 at 12:08 PM, S, Venkatraman svenk...@ti.com wrote: On Fri, Aug 17, 2012 at 11:43 PM, Puttagunta, Viswanath vi...@ti.com wrote: On Fri, Aug 17, 2012 at 12:28 PM, S, Venkatraman svenk...@ti.com wrote: On Fri, Aug 17, 2012 at 9:35 PM, Semen Protsenko semen.protse...@ti.com wrote: Errata description: Due to a bad behavior of an internal signal, the Card Error interrupt bit MMCHS_STAT[28] CERR may not be set sometimes when an error occurred in the card response. Workaround: After responses of type R1/R1b for all cards and responses of type R5/R5b/R6 for SD and SDIO cards, software must read two registers: MMCHS_RSP10 and MMCHS_CSRE. When a MMCHS_CSRE[i] bit is set to 1, if the corresponding bit at the same position in the response MMCHS_RSP10[i] is set to 1, the host controller indicates a card error and software should proceed in the same way as if a CERR interrupt would have been detected in the MMCHS_STAT register. Note: This errata is applicable for omap44xx. Signed-off-by: Semen Protsenko semen.protse...@ti.com The implementation looks fine, but can we simply not set the errata flag and make this as default behaviour ? I suppose the documented behaviour with CSRE and RSP10 is independent of the errata.. Also, please send it to the linux-mmc list as well. Vish We don't know if this errata effects OMAP5 as well. So, I think we should only do this if we are OMAP4. That's precisely why the code shouldn't check for cpu_() flags. There are other OMAP variants as well and we can't check all of them What I mean is to make the check for RSP10 and CSRE all the time as part of the IRQ check. Then it equally applies to silcon with or without errata. Apart from above comment, please don't add the cpu_is_xxx() check inside device driver. You can pass that information from platform code while registering the MMC controllers using a flag and then just use that flag to enable/disable errata in the driver. 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: OMAP3 Overo: Crash on boot with Linus' master
Tomi,
On Mon, Aug 20, 2012 at 1:38 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Hi,
Anyone ideas what could I do to debug this further? The problem exists
on v3.6-rc2.
Can you try merging [1] {[GIT PULL] arm-soc: bug fixes for v3.6-rc3}
and see if it helps.
Regards
Santosh
[1] https://lkml.org/lkml/2012/8/20/120
--
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: OMAP3 Overo: Crash on boot with Linus' master
On Mon, Aug 20, 2012 at 2:24 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
Hi,
On Mon, 2012-08-20 at 13:58 +0530, Shilimkar, Santosh wrote:
Tomi,
On Mon, Aug 20, 2012 at 1:38 PM, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
Hi,
Anyone ideas what could I do to debug this further? The problem exists
on v3.6-rc2.
Can you try merging [1] {[GIT PULL] arm-soc: bug fixes for v3.6-rc3}
and see if it helps.
Regards
Santosh
[1] https://lkml.org/lkml/2012/8/20/120
Merging that branch seems to fix the issue. Good to know, thanks!
Cool !!
Thanks for confirming it.
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 4/5] ARM: OMAP4: Add L2 Cache Controller in Device Tree
On Mon, Aug 20, 2012 at 7:21 PM, Benoit Cousson b-cous...@ti.com wrote:
Hi Santosh,
On 08/13/2012 01:00 PM, Santosh Shilimkar wrote:
This provides PL310 Level 2 Cache Controller Device Tree
support for OMAP4 based devices.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |7 +++
arch/arm/mach-omap2/omap4-common.c |6 +-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 6717c71..cf1efb6 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -36,6 +36,13 @@
};
};
+ L2: l2-cache-controller {
The reg offset is missing: l2-cache-controller@48242000
+ compatible = arm,pl310-cache;
+ reg = 0x48242000 0x1000;
+ cache-unified;
+ cache-level = 2;
+ };
+
In theory, the L2 cache should be referenced from the CPUs.
Agree.
Here is the way it is done for mpc8541cdc.dts for example:
I will move it under CPU. Thanks
regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP: Add initialisation for the real-time counter.
On Tue, Aug 14, 2012 at 11:52 AM, Hiremath, Vaibhav hvaib...@ti.com wrote:
On Tue, Aug 14, 2012 at 11:46:35, Shilimkar, Santosh wrote:
On Mon, Aug 13, 2012 at 11:05 PM, Vaibhav Hiremath hvaib...@ti.com
wrote:
[...]
Also, does it make sense to get rid of hardcoded values above?
Actually not. Because the values are fixed since the counter
clock-rate is hardwired to be 6.144 MHz and hence all the
other numbers becomes constant. All these numbers are
coming from TRM and not from any formula. I don't wanted
to go on mathematical equation path since all the values
are well documented.
Yes, I looked at the TRM and they are well documented there.
I would atleast suggest you to state that, these values are coming
directly
from TRM and possibly give reference to the TRM section here.
Added the TRM chapter information and iounmap() change.
Updated patch at end of the email.
Regards
Santosh
From aae85431b1a0e985bbc5611972642e96a1501368 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Mon, 13 Aug 2012 14:24:24 +0530
Subject: [PATCH 1/2] ARM: OMAP: Add initialisation for the real-time counter.
The real time counter also called master counter, is a free-running
counter. It produces the count used by the CPU local timer peripherals
in the MPU cluster. The timer counts at a rate of 6.144 MHz.
The ratio registers needs to be configured based on system clock
only onetime. After initialisation, hardware takes care of adjusting
the clock in different low power modes to keep counter rate constant.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/Kconfig |4 ++
arch/arm/mach-omap2/timer.c | 90 ++-
2 files changed, 93 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index dd2db02..2120f90 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -24,6 +24,9 @@ config ARCH_OMAP2PLUS_TYPICAL
config SOC_HAS_OMAP2_SDRC
bool OMAP2 SDRAM Controller support
+config SOC_HAS_REALTIME_COUNTER
+ bool Real time free running counter
+
config ARCH_OMAP2
bool TI OMAP2
depends on ARCH_OMAP2PLUS
@@ -69,6 +72,7 @@ config SOC_OMAP5
select CPU_V7
select ARM_GIC
select HAVE_SMP
+ select SOC_HAS_REALTIME_COUNTER
comment OMAP Core Type
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 2ff6d41..fd5c048 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -69,6 +69,11 @@
#define OMAP3_SECURE_TIMER 1
#endif
+#define REALTIME_COUNTER_BASE 0x48243200
+#define INCREMENTER_NUMERATOR_OFFSET 0x10
+#define INCREMENTER_DENUMERATOR_RELOAD_OFFSET 0x14
+#define NUMERATOR_DENUMERATOR_MASK 0xf000
+
/* Clockevent code */
static struct omap_dm_timer clkev;
@@ -339,6 +344,84 @@ static void __init omap2_clocksource_init(int gptimer_id,
omap2_gptimer_clocksource_init(gptimer_id, fck_source);
}
+#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
+/*
+ * The realtime counter also called master counter, is a free-running
+ * counter, which is related to real time. It produces the count used
+ * by the CPU local timer peripherals in the MPU cluster. The timer counts
+ * at a rate of 6.144 MHz. Because the device operates on different clocks
+ * in different power modes, the master counter shifts operation between
+ * clocks, adjusting the increment per clock in hardware accordingly to
+ * maintain a constant count rate.
+ */
+static void __init realtime_counter_init(void)
+{
+ void __iomem *base;
+ static struct clk *sys_clk;
+ unsigned long rate;
+ unsigned int reg, num, den;
+
+ base = ioremap(REALTIME_COUNTER_BASE, SZ_32);
+ if (!base) {
+ pr_err(%s: ioremap failed\n, __func__);
+ return;
+ }
+ sys_clk = clk_get(NULL, sys_clkin_ck);
+ if (!sys_clk) {
+ pr_err(%s: failed to get system clock handle\n, __func__);
+ iounmap(base);
+ return;
+ }
+
+ rate = clk_get_rate(sys_clk);
+ /* Numerator/denumerator values refer TRM Realtime Counter section */
+ switch (rate) {
+ case 120:
+ num = 64;
+ den = 125;
+ break;
+ case 130:
+ num = 768;
+ den = 1625;
+ break;
+ case 1920:
+ num = 8;
+ den = 25;
+ break;
+ case 260:
+ num = 384;
+ den = 1625;
+ break;
+ case 270:
+ num = 256;
+ den = 1125;
+ break;
+ case 3840:
+ default:
+ /* Program it for 38.4 MHz */
+ num = 4
Re: [PATCH v4 4/4] memory: emif: add device tree support to emif driver
On Fri, Aug 17, 2012 at 12:15 AM, Greg KH gre...@linuxfoundation.org wrote:
On Mon, Aug 13, 2012 at 10:57:06AM +0530, Shilimkar, Santosh wrote:
Greg,
On Wed, Jul 18, 2012 at 12:14 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Tue, Jul 17, 2012 at 11:28 PM, Greg KH gre...@linuxfoundation.org
wrote:
On Tue, Jul 17, 2012 at 10:37:45PM +0530, Shilimkar, Santosh wrote:
On Tue, Jul 17, 2012 at 10:06 PM, Greg KH gre...@linuxfoundation.org
wrote:
On Mon, Jul 09, 2012 at 07:02:36PM +0530, Shilimkar, Santosh wrote:
Greg,
[..]
From 74688a87fd490909e9122bf757c0096480e9fc11 Mon Sep 17 00:00:00 2001
From: Aneesh V ane...@ti.com
Date: Mon, 30 Jan 2012 20:06:30 +0530
Subject: [PATCH 4/4] memory: emif: add device tree support to emif driver
Device tree support for the EMIF driver. LPDDR2 generic timings
extraction from device is managed using couple of helper
functions which can be used by other memory controller
drivers.
Reviewed-by: Benoit Cousson b-cous...@ti.com
Reviewed-by: Grant Likely grant.lik...@secretlab.ca
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Aneesh V ane...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/memory/Makefile|1 +
drivers/memory/emif.c | 182
+++-
drivers/memory/of_memory.c | 153 +
drivers/memory/of_memory.h | 36 +
4 files changed, 371 insertions(+), 1 deletion(-)
create mode 100644 drivers/memory/of_memory.c
create mode 100644 drivers/memory/of_memory.h
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 42b3ce9..cd8486b 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -2,6 +2,7 @@
# Makefile for memory devices
#
+obj-$(CONFIG_OF) += of_memory.o
obj-$(CONFIG_TI_EMIF)+= emif.o
obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o
obj-$(CONFIG_TEGRA30_MC) += tegra30-mc.o
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 33a4396..06b4eb7 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -18,6 +18,7 @@
#include linux/platform_device.h
#include linux/interrupt.h
#include linux/slab.h
+#include linux/of.h
#include linux/debugfs.h
#include linux/seq_file.h
#include linux/module.h
@@ -25,6 +26,7 @@
#include linux/spinlock.h
#include memory/jedec_ddr.h
#include emif.h
+#include of_memory.h
/**
* struct emif_data - Per device static data for driver's use
@@ -49,6 +51,7 @@
* frequency in effect at the moment)
* @plat_data: Pointer to saved platform data.
* @debugfs_root:dentry to the root folder for EMIF in
debugfs
+ * @np_ddr: Pointer to ddr device tree node
*/
struct emif_data {
u8 duplicate;
@@ -63,6 +66,7 @@ struct emif_data {
struct emif_regs*curr_regs;
struct emif_platform_data *plat_data;
struct dentry *debugfs_root;
+ struct device_node *np_ddr;
};
static struct emif_data *emif1;
@@ -1148,6 +1152,168 @@ static int is_custom_config_valid(struct
emif_custom_configs *cust_cfgs,
return valid;
}
+#if defined(CONFIG_OF)
+static void __init_or_module of_get_custom_configs(struct device_node
*np_emif,
+ struct emif_data *emif)
Why can't all of this code be in the of_memory.c file?
Primarily because the parameters are very much specific to EMIF
memory controller and won't be of much use for other memory controllers.
Currently the information extracted from DT with these function is like:
- EMIF controller IP version : EMIF_4D or EMIF_4D5
- Which analog phy is integrated : EMIF_ATTILAPHY or EMIF_ATTILAPHY
- IP hardware interface: EMIF Low latency port or sys port interface.
- EMIF connections - Whether EMIF1 only, EMIF2 only or EMIF1 EMIF2
- Memory connections to EMIF - Same type and size memories or asymmetric
- Chip select usage per controller: Whether CS0, CS1, CS0 CS1
- ZQ calibration - Per chip select or enable EMIF dual calibration feature.
- Enable/disable EMIF Low power mode and temperature alerts.
- EMIF low power mode configuration:
- Clock stop, self refresh, Deep power down.
- Low power time out values for performance and power mode.
- DDR frequency threshold to switch between power and
performance settings.
- EMIF temperature polling cycle configuration.
As you can see these are very specific to the EMIF memory controller and
hence
I didn't move them to of_memory.c
Do you have any more comment on this patch? If not, I can go ahead and
post the refreshed version of the patch.
Please always
Re: [PATCH v5 0/8] ARM: OMAP2+: PM: introduce the power domains functional states
Jean, On Wed, Aug 15, 2012 at 3:32 PM, Jean Pihet jean.pi...@newoldbits.com wrote: Here is a re-spin after some comments and suggestions after review. Implement the functional states for the power domains: - unify the API to use the functional states. pwrdm_set_next_fpwrst now is the function to control the power domains power and logic states, - reorganize the powerdomain API in internal and external parts, in powerdomain.h [1] - protect the power domain state change by a lock in pwrdm_set_next_fpwrst, - introduce the functional states for power domains power states and logic power states, and the conversion functions between the functional and internal states, - program the logic power state of power domains from the functional states, in pwrdm_set_next_fpwrst - convert the OMAP2/3/4 PM code to use the updated API, - provide the power domains statistics by functional states, - provide ftrace tracepoints with the functional state, - provide error logs in critical code, which makes the development easier. Note: [1] the physical split of internal and external APIs into different header files is not part of this series, it comes as a separate patch set. Based on mainline kernel 3.6.0-rc1. Tested on OMAP3 Beagleboard, with suspend and cpuidle in RET and OFF modes. I didn't find any mention here about why are we going in this path and not in the direction proposed in another RFC [1] I have already given my comments[2] against the introduction of another PD layer which can be avoided easily as demonstrated by the RFC[1]. The comments are still applicable for this series too. We really need to reduce OMAP specific framework overhead and move towards more generic PM frameworks. For me, this series is a step back-ward from that direction. Am really sorry for being critical again but I remain unconvinced about this series and the problem it is trying to solve. May be you have valid reasons not to follow the approach in [1] and in that case, it will be good to clarify that so that some of us get to know your rationale. Regards Santosh [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg71732.html [2] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69081.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 v5 0/8] ARM: OMAP2+: PM: introduce the power domains functional states
Paul, On Thu, Aug 16, 2012 at 6:18 AM, Paul Walmsley p...@pwsan.com wrote: Hi Santosh, On Wed, 15 Aug 2012, Shilimkar, Santosh wrote: On Wed, Aug 15, 2012 at 3:32 PM, Jean Pihet jean.pi...@newoldbits.com wrote: I didn't find any mention here about why are we going in this path and not in the direction proposed in another RFC [1] I have already given my comments[2] against the introduction of another PD layer which can be avoided easily as demonstrated by the RFC[1]. The comments are still applicable for this series too. We really need to reduce OMAP specific framework overhead and move towards more generic PM frameworks. For me, this series is a step back-ward from that direction. Am really sorry for being critical again but I remain unconvinced about this series and the problem it is trying to solve. May be you have valid reasons not to follow the approach in [1] and in that case, it will be good to clarify that so that some of us get to know your rationale. I've asked Jean to handle the work of evaluating and/or integrating any feedback from you and Rajendra into this series. Jean, has this latest series fully considered those issues? Or are there still some areas of misalignment / lack of clarity? Thanks for the information. The main objection to this series was to not add un-necessary glue layer which still remains. From our discussion in past on and off list, your main intention for such a series was - 1. Need a way to support OSWR. - OSWR by definition is a RET with configurable logic and memory states. Its a true power state from PD point of view and its not a logical state. Now since we have agreed to make the OSWR as a static definition (in all products so far OSWR is used as a static definition with logic lost, memory retained kind of configuration.) - The above requirement can be easily fixed by adding the OSWR as an additional basic power state as demonstrated in RFC. - There is no need to add another glue layer for above. 2. Locking so that the low level APIs don't race and henec abstracting the exported API to 1 or 2 and making rest as private functions. -- Even before this series, except low level PM code, only one common API was used to set the PD low power state. int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 pwrst) -- Once we make OSWR as basic power state, we also avoid usage of pwrdm_set_logic_retst() API. -- We implement lock at this API and export only above API + may be omap_get_pwrdm_state() kind of API based on need. -- This solves the second requirement too. Even if we have more requirement, they can be addressed too without need of another layer. If you look at the diffstat alone between two approaches, it is evident how small piece of code is needed to support above. Am not too much into the lines of code but basic objection we have is not to add another glue layer. Thinking bit loud, for the logical layer for power domain we should move towards common device power domain APIs and if needed add/enhance them to support OMAP. drivers/base/power/domain.c May be this though is bit premature but the intetion is to move towards generic linux framework. Anyway. If there's a problem with this process, it sounds like you, Rajendra, Jean, Benoît and I should schedule some time to talk over the same issues that you discussed with me on the phone. Perhaps next week? We can surely do a call if needed. But the comments given so far and the RFC makes things more or less clear the contention point against the $subject series. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP: Add initialisation for the real-time counter.
On Mon, Aug 13, 2012 at 11:05 PM, Vaibhav Hiremath hvaib...@ti.com wrote:
On 8/13/2012 4:37 PM, Santosh Shilimkar wrote:
The real time counter also called master counter, is a free-running
counter. It produces the count used by the CPU local timer peripherals
in the MPU cluster. The timer counts at a rate of 6.144 MHz.
The ratio registers needs to be configured based on system clock
only onetime. After initialisation, hardware takes care of adjusting
the clock in different low power modes to keep counter rate constant.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/Kconfig |4 ++
arch/arm/mach-omap2/timer.c | 89
++-
2 files changed, 92 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index dd2db02..2120f90 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -24,6 +24,9 @@ config ARCH_OMAP2PLUS_TYPICAL
config SOC_HAS_OMAP2_SDRC
bool OMAP2 SDRAM Controller support
+config SOC_HAS_REALTIME_COUNTER
+ bool Real time free running counter
+
config ARCH_OMAP2
bool TI OMAP2
depends on ARCH_OMAP2PLUS
@@ -69,6 +72,7 @@ config SOC_OMAP5
select CPU_V7
select ARM_GIC
select HAVE_SMP
+ select SOC_HAS_REALTIME_COUNTER
comment OMAP Core Type
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 2ff6d41..9b17e6c 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -69,6 +69,11 @@
#define OMAP3_SECURE_TIMER 1
#endif
+#define REALTIME_COUNTER_BASE0x48243200
+#define INCREMENTER_NUMERATOR_OFFSET 0x10
+#define INCREMENTER_DENUMERATOR_RELOAD_OFFSET0x14
+#define NUMERATOR_DENUMERATOR_MASK 0xf000
+
/* Clockevent code */
static struct omap_dm_timer clkev;
@@ -339,6 +344,83 @@ static void __init omap2_clocksource_init(int
gptimer_id,
omap2_gptimer_clocksource_init(gptimer_id, fck_source);
}
+#ifdef CONFIG_SOC_HAS_REALTIME_COUNTER
+/*
+ * The realtime counter also called master counter, is a free-running
+ * counter, which is related to real time. It produces the count used
+ * by the CPU local timer peripherals in the MPU cluster. The timer
counts
+ * at a rate of 6.144 MHz. Because the device operates on different
clocks
+ * in different power modes, the master counter shifts operation
between
+ * clocks, adjusting the increment per clock in hardware accordingly to
+ * maintain a constant count rate.
+ */
+static void __init realtime_counter_init(void)
+{
+ void __iomem *base;
+ static struct clk *sys_clk;
+ unsigned long rate;
+ unsigned int reg, num, den;
+
+ base = ioremap(REALTIME_COUNTER_BASE, SZ_32);
+ if (!base) {
+ pr_err(%s: ioremap failed\n, __func__);
+ return;
+ }
+ sys_clk = clk_get(NULL, sys_clkin_ck);
+ if (!sys_clk) {
+ pr_err(%s: failed to get system clock handle\n,
__func__);
+ return;
Don't want to unmap the ioremap'ed space?
yep. Infact at the end of this function I wanted to unmap the
space since this is one time init. Will fix that in next version.
+ }
+
+ rate = clk_get_rate(sys_clk);
+ switch (rate) {
+ case 120:
+ num = 64;
+ den = 125;
+ break;
+ case 130:
+ num = 768;
+ den = 1625;
+ break;
+ case 1920:
+ num = 8;
+ den = 25;
+ break;
+ case 260:
+ num = 384;
+ den = 1625;
+ break;
+ case 270:
+ num = 256;
+ den = 1125;
+ break;
+ case 3840:
+ num = 4;
+ den = 25;
+ break;
+ default:
+ /* Program it for 38.4 MHz */
+ num = 4;
+ den = 25;
+ break;
You can simply do something like,
case 3840:
/* Program it for 38.4 MHz */
default:
num = 4;
den = 25;
break;
Yes.
Also, suggest to mention about why 38.4MHz as default? I believe it is
reset value, right?
This is the default sys clock rate assumed in most of the documentation
and also expected to be a default sys clock rate. Reset values as you
said in many other registers also assume 38.4 MHz.
Also, does it make sense to get rid of hardcoded values above?
Actually not. Because the values are fixed since the counter
clock-rate is hardwired to be 6.144 MHz and hence all the
other numbers becomes constant. All these numbers are
coming from
Re: [PATCHv2 0/4] Add device tree data for omap5
Sourav, On Mon, Aug 13, 2012 at 3:35 PM, Sourav Poddar sourav.pod...@ti.com wrote: The following patch series add i2c support for omap5. As well as enable I2C based devices like pressure and temperature through device tree. Also add onchip keypad dts data. Cc: Benoit Cousson b-cous...@ti.com Cc: Felipe Balbi ba...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Sourav Poddar (4): arm/dts: omap5-evm: Add I2C support arm/dts: omap5-evm: Add tmp102 sensor support arm/dts: omap5-evm: Add keypad data arm/dts: omap5-evm: Add bmp085 sensor support arch/arm/boot/dts/omap5-evm.dts | 30 + arch/arm/boot/dts/omap5.dtsi| 40 +++ 2 files changed, 70 insertions(+), 0 deletions(-) The entire series looks fine to me. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Allow memblock steal operations to remove memory from anywhere
On Sun, Aug 12, 2012 at 4:27 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Found this with the cubox, which wants to obtain large blocks of RAM for the GPU and VPU devices at boot time. I don't believe any other platforms care where the memory comes from, so I think this is safe. Agree. However, OMAP and iMX folk should check this patch - thanks. Works for OMAP without any issues. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com 8=== From: Russell King rmk+ker...@arm.linux.org.uk Subject: ARM: Allow arm_memblock_steal() to remove memory from any RAM region Allow arm_memblock_steal() to remove memory from any RAM region, including highmem areas. This allows memory to be stolen from the very top of declared memory, including highmem areas, rather than our precious lowmem. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/mm/init.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c index f54d592..04632f3 100644 --- a/arch/arm/mm/init.c +++ b/arch/arm/mm/init.c @@ -324,7 +324,7 @@ phys_addr_t __init arm_memblock_steal(phys_addr_t size, phys_addr_t align) BUG_ON(!arm_memblock_steal_permitted); - phys = memblock_alloc(size, align); + phys = memblock_alloc_base(size, align, MEMBLOCK_ALLOC_ANYWHERE); memblock_free(phys, size); memblock_remove(phys, size); -- 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 v4 4/4] memory: emif: add device tree support to emif driver
Greg,
On Wed, Jul 18, 2012 at 12:14 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Tue, Jul 17, 2012 at 11:28 PM, Greg KH gre...@linuxfoundation.org wrote:
On Tue, Jul 17, 2012 at 10:37:45PM +0530, Shilimkar, Santosh wrote:
On Tue, Jul 17, 2012 at 10:06 PM, Greg KH gre...@linuxfoundation.org
wrote:
On Mon, Jul 09, 2012 at 07:02:36PM +0530, Shilimkar, Santosh wrote:
Greg,
[..]
From 74688a87fd490909e9122bf757c0096480e9fc11 Mon Sep 17 00:00:00 2001
From: Aneesh V ane...@ti.com
Date: Mon, 30 Jan 2012 20:06:30 +0530
Subject: [PATCH 4/4] memory: emif: add device tree support to emif driver
Device tree support for the EMIF driver. LPDDR2 generic timings
extraction from device is managed using couple of helper
functions which can be used by other memory controller
drivers.
Reviewed-by: Benoit Cousson b-cous...@ti.com
Reviewed-by: Grant Likely grant.lik...@secretlab.ca
Tested-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Aneesh V ane...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/memory/Makefile|1 +
drivers/memory/emif.c | 182
+++-
drivers/memory/of_memory.c | 153 +
drivers/memory/of_memory.h | 36 +
4 files changed, 371 insertions(+), 1 deletion(-)
create mode 100644 drivers/memory/of_memory.c
create mode 100644 drivers/memory/of_memory.h
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index 42b3ce9..cd8486b 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -2,6 +2,7 @@
# Makefile for memory devices
#
+obj-$(CONFIG_OF) += of_memory.o
obj-$(CONFIG_TI_EMIF)+= emif.o
obj-$(CONFIG_TEGRA20_MC) += tegra20-mc.o
obj-$(CONFIG_TEGRA30_MC) += tegra30-mc.o
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index 33a4396..06b4eb7 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -18,6 +18,7 @@
#include linux/platform_device.h
#include linux/interrupt.h
#include linux/slab.h
+#include linux/of.h
#include linux/debugfs.h
#include linux/seq_file.h
#include linux/module.h
@@ -25,6 +26,7 @@
#include linux/spinlock.h
#include memory/jedec_ddr.h
#include emif.h
+#include of_memory.h
/**
* struct emif_data - Per device static data for driver's use
@@ -49,6 +51,7 @@
* frequency in effect at the moment)
* @plat_data: Pointer to saved platform data.
* @debugfs_root:dentry to the root folder for EMIF in debugfs
+ * @np_ddr: Pointer to ddr device tree node
*/
struct emif_data {
u8 duplicate;
@@ -63,6 +66,7 @@ struct emif_data {
struct emif_regs*curr_regs;
struct emif_platform_data *plat_data;
struct dentry *debugfs_root;
+ struct device_node *np_ddr;
};
static struct emif_data *emif1;
@@ -1148,6 +1152,168 @@ static int is_custom_config_valid(struct
emif_custom_configs *cust_cfgs,
return valid;
}
+#if defined(CONFIG_OF)
+static void __init_or_module of_get_custom_configs(struct device_node
*np_emif,
+ struct emif_data *emif)
Why can't all of this code be in the of_memory.c file?
Primarily because the parameters are very much specific to EMIF
memory controller and won't be of much use for other memory controllers.
Currently the information extracted from DT with these function is like:
- EMIF controller IP version : EMIF_4D or EMIF_4D5
- Which analog phy is integrated : EMIF_ATTILAPHY or EMIF_ATTILAPHY
- IP hardware interface: EMIF Low latency port or sys port interface.
- EMIF connections - Whether EMIF1 only, EMIF2 only or EMIF1 EMIF2
- Memory connections to EMIF - Same type and size memories or asymmetric
- Chip select usage per controller: Whether CS0, CS1, CS0 CS1
- ZQ calibration - Per chip select or enable EMIF dual calibration feature.
- Enable/disable EMIF Low power mode and temperature alerts.
- EMIF low power mode configuration:
- Clock stop, self refresh, Deep power down.
- Low power time out values for performance and power mode.
- DDR frequency threshold to switch between power and
performance settings.
- EMIF temperature polling cycle configuration.
As you can see these are very specific to the EMIF memory controller and hence
I didn't move them to of_memory.c
Do you have any more comment on this patch? If not, I can go ahead and
post the refreshed version of 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
Re: [PATCH v2] gpio/omap: add *remove* callback in platform_driver
On Fri, Aug 10, 2012 at 11:38 AM, DebBarma, Tarun Kanti tarun.ka...@ti.com wrote: On Thu, Aug 9, 2012 at 8:28 PM, Kevin Hilman khil...@ti.com wrote: DebBarma, Tarun Kanti tarun.ka...@ti.com writes: On Wed, Aug 8, 2012 at 10:40 PM, Kevin Hilman khil...@ti.com wrote: Tarun Kanti DebBarma tarun.ka...@ti.com writes: Add *remove* callback so that necessary cleanup operations are performed when device is unregistered. The device is deleted from the list and associated clock handle is released by calling clk_put() and irq descriptor is released using the irq_free_desc() api. Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com Reported-by: Paul Walmsley p...@pwsan.com Reviewed-by: Jon Hunter jon-hun...@ti.com Cc: Kevin Hilman khil...@ti.com Cc: Rajendra Nayak rna...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Cousson, Benoit b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com --- v2: Baseline: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Commit: 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee (Linux 3.6-rc1) (1) Use irq_free_descs() instead of irq_free_desc(). Besides, irq_free_desc() was using wrong parameter, irq_base, instead of bank-irq. (2) irq_free_descs() moved outside spin_lock/unlock_*() in order to avoid exception warnings. (3) pm_runtime_disable() added so that bind can happen successfully Test Detail: Step 1: Unbind gpio.5 device in order to invoke the *remove* callback. #echo omap_gpio.5 sys/bus/platform/drivers/omap_gpio/unbind Step 2: Bind gpio.5 device and confirm probe() for the device succeeds. #echo omap_gpio.5 sys/bus/platform/drivers/omap_gpio/bind Step 3: Execute read/write GPIO test case. What happens when GPIOs are in use (requested)? If I try to unbind a currently active GPIO bank then I see an exception after the irq descriptor is freed by the remove. I believe this is expected because interrupt raised by the system would not be handled. ... and the GPIO is still configured to trigger interrupts. Right! The point is that there is lots to cleanup/unconfigure properly for this to work properly. As far as I can think of, all active gpio requests done either in board files or through DT have to be freed. But if this is done then when we bind() the device again initialization done in omap_gpio_probe() would not restore the board/DT related configuration. So the point is are we supposed to do all these cleanup in *remove* callback? If yes, how do we manage board level gpio usage? More and more I think of the .remove() for GPIO, the interface not seems to make sense. Being an infrastructure driver which can be used by many client drivers like Ethernet, MMC card detect, sensors etc etc. And hence it can not be made a loadable module. So I am in favor of dropping the $subject patch completely unless and until we need it genuinely. 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 v2 2/2] ARM: OMAP4: Register the OPP table only for 4430 device
On Thu, Aug 9, 2012 at 12:38 PM, Rajendra Nayak rna...@ti.com wrote: The 4430 OPP table was being registered for all other OMAP4 variants too, like 4460 and 4470 causing issues with cpufreq driver enabled. 4460 and 4470 devices have different OPPs as compared to 4430, and they should be populated seperately. As long as that happens, let the OPP table registeration happen only on 4430 device. Signed-off-by: Rajendra Nayak rna...@ti.com --- Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] cpufreq: OMAP: Handle missing frequency table on SMP systems
On Wed, Aug 8, 2012 at 4:24 PM, Rajendra Nayak rna...@ti.com wrote:
On OMAP4, if the first CPU fails to get a valid frequency table (this
could happen if the platform does not register any OPP table), the
subsequent CPU instances end up dealing with a NULL freq_table and
crash. Add a check for a NULL freq_table to help error the rest
of the CPU instances out.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: linux...@vger.kernel.org
---
drivers/cpufreq/omap-cpufreq.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c
b/drivers/cpufreq/omap-cpufreq.c
index 17fa04d..0ee824c 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -221,7 +221,7 @@ static int __cpuinit omap_cpu_init(struct
cpufreq_policy *policy)
if (atomic_inc_return(freq_table_users) == 1)
result = opp_init_cpufreq_table(mpu_dev, freq_table);
- if (result) {
+ if (result || !freq_table) {
dev_err(mpu_dev, %s: cpu%d: failed creating freq
table[%d]\n,
__func__, policy-cpu, result);
goto fail_ck;
The freq_table use count seems to be buggy in that case.
Something like below should fix the issue.
Feel free to update your patch with below if you agree.
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 17fa04d..fd97c3d 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -218,7 +218,7 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy *po
policy-cur = policy-min = policy-max = omap_getspeed(policy-cpu);
- if (atomic_inc_return(freq_table_users) == 1)
+ if (freq_table)
result = opp_init_cpufreq_table(mpu_dev, freq_table);
if (result) {
@@ -227,6 +227,7 @@ static int __cpuinit omap_cpu_init(struct cpufreq_policy *po
goto fail_ck;
}
+ atomic_inc_return(freq_table_users);
result = cpufreq_frequency_table_cpuinfo(policy, freq_table);
if (result)
goto fail_table;
--
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] gpio/omap: add *remove* callback in platform_driver
On Wed, Aug 8, 2012 at 7:28 PM, Tarun Kanti DebBarma tarun.ka...@ti.com wrote: Add *remove* callback so that necessary cleanup operations are performed when device is unregistered. The device is deleted from the list and associated clock handle is released by calling clk_put() and irq descriptor is released using the irq_free_desc() api. Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com Reported-by: Paul Walmsley p...@pwsan.com Reviewed-by: Jon Hunter jon-hun...@ti.com Cc: Kevin Hilman khil...@ti.com Cc: Rajendra Nayak rna...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Cousson, Benoit b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com --- v2: Baseline: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Commit: 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee (Linux 3.6-rc1) (1) Use irq_free_descs() instead of irq_free_desc(). Besides, irq_free_desc() was using wrong parameter, irq_base, instead of bank-irq. (2) irq_free_descs() moved outside spin_lock/unlock_*() in order to avoid exception warnings. (3) pm_runtime_disable() added so that bind can happen successfully Test Detail: Step 1: Unbind gpio.5 device in order to invoke the *remove* callback. #echo omap_gpio.5 sys/bus/platform/drivers/omap_gpio/unbind Step 2: Bind gpio.5 device and confirm probe() for the device succeeds. #echo omap_gpio.5 sys/bus/platform/drivers/omap_gpio/bind Step 3: Execute read/write GPIO test case. Thanks details about test. Whe you to Unbind-bind, do you see that PM is not broken. In other words, can you also test and ensure that the OMAP3 suspend and CPUIDLE are not broken because of this patch. PER and CORE domains should transition to low power states. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] cpufreq: OMAP: Handle missing frequency table on SMP systems
On Wed, Aug 8, 2012 at 10:58 PM, Kevin Hilman khil...@ti.com wrote:
Shilimkar, Santosh santosh.shilim...@ti.com writes:
On Wed, Aug 8, 2012 at 4:24 PM, Rajendra Nayak rna...@ti.com wrote:
On OMAP4, if the first CPU fails to get a valid frequency table (this
could happen if the platform does not register any OPP table), the
subsequent CPU instances end up dealing with a NULL freq_table and
crash. Add a check for a NULL freq_table to help error the rest
of the CPU instances out.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: linux...@vger.kernel.org
---
drivers/cpufreq/omap-cpufreq.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c
b/drivers/cpufreq/omap-cpufreq.c
index 17fa04d..0ee824c 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -221,7 +221,7 @@ static int __cpuinit omap_cpu_init(struct
cpufreq_policy *policy)
if (atomic_inc_return(freq_table_users) == 1)
result = opp_init_cpufreq_table(mpu_dev, freq_table);
- if (result) {
+ if (result || !freq_table) {
dev_err(mpu_dev, %s: cpu%d: failed creating freq
table[%d]\n,
__func__, policy-cpu, result);
goto fail_ck;
The freq_table use count seems to be buggy in that case.
Something like below should fix the issue.
Feel free to update your patch with below if you agree.
diff --git a/drivers/cpufreq/omap-cpufreq.c
b/drivers/cpufreq/omap-cpufreq.c
index 17fa04d..fd97c3d 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -218,7 +218,7 @@ static int __cpuinit omap_cpu_init(struct
cpufreq_policy *po
policy-cur = policy-min = policy-max =
omap_getspeed(policy-cpu);
- if (atomic_inc_return(freq_table_users) == 1)
+ if (freq_table)
I think you meant 'if (!freq_table)' ?
Right.
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] ARM: OMAP4: sleep: Save the complete used register stack frame
On Wed, Aug 8, 2012 at 10:45 PM, Kevin Hilman khil...@ti.com wrote: Santosh Shilimkar santosh.shilim...@ti.com writes: OMAP4 sleep entry code even though itself don't use many CPU registers makes call to the v7_flush_dcache_all() which uses them. Since v7_flush_dcache_all() doesn't make use of stack, the caller must take care of the stack frame. Otherwise it will lead to corrupted stack frame. Fix it by saving used registers. Reported-by: Grygorii Strashko grygorii.stras...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Kevin Hilman khil...@ti.com Please add a brief comment in the code as well explaining why the additional registers are saved/restored. Ok. After that, I'll add to my PM fixes queue for v3.6-rc. Thanks. 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: [GIT PULL] ARM: OMAP5: Add minimal OMAP5 SOC support for 3.6
On Tue, Aug 7, 2012 at 12:30 PM, Tony Lindgren t...@atomide.com wrote: * Shilimkar, Santosh santosh.shilim...@ti.com [120726 00:27]: On Tue, Jul 10, 2012 at 10:33 AM, Tony Lindgren t...@atomide.com wrote: * Santosh Shilimkar santosh.shilim...@ti.com [120709 08:07]: Tony, Please pull below OMAP5 SOC minimal support. It is generated against the cleanup-part2 branch of yours. As you suggested, I have dropped CK_54XX flag changes to avoid conflicts. OK seems to merge fine now, pulled into devel-omap5. Now OMAP5 support appearing in mainline. In case you would like to boot mainline on your OMAP5 board, you need to merge a OMAP5 SOC hwmod/clock data which is out of tree. I have put that on a branch and same is available [1]. Please note that the only DT boot supported. Nice to see it being a small set :) Have these changes been posted to the mailing lists for review? Not yet. Benoit was looking into the database difference between the current and next version of the silicon. Since there is a difference between the data, the idea was to submit the final version of data to avoid potential huge patching. Regards santosh [1] git://github.com/SantoshShilimkar/linux.git out-of-tree/omap5-data -- 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: [GPIO] Crashed when not using
On Tue, Jul 31, 2012 at 6:26 PM, Poddar, Sourav sourav.pod...@ti.com wrote:
Hi Santosh,
On Tue, Jul 31, 2012 at 6:02 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Tue, Jul 31, 2012 at 8:52 AM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Tue, Jul 31, 2012 at 10:23:16AM +0530, Poddar, Sourav wrote:
The device tree data for acquiring the above GPIO interrupt line
looks
like this.
+++ linux-omap-storage/arch/arm/boot/dts/omap5-evm.dts 2012-07-30
14:11:08.931694001 +0530
@@ -42,7 +42,8 @@
tsl2771@39 {
compatible = taos,tsl2771;
reg = 0x39;
+interrupt-parent = gpio5;
+interrupts = 21; /* gpio line 149 */
};
};
Note: using gpio_request_one in the driver solves the issue.
Is using this api in the driver required?
Any pointer on the above crash?
Hi Tarun,
Any user/client driver of GPIO is supposed to go through
gpio_request() API so that module clock
is enabled correctly. Overriding of APIs would put the power
management state machine in jeopardy.
--
I tried putting pm_runtime_get_sync in gpio_irq_type api where the
kernel
is crashing and the crash is no longer observed. So indeed, its about
enabling clocks.
One doubt: Can't we put runtime apis in gpio_irq_type and eliminate
the use of
gpio_request_one??
No.
You must use the GPIO requiest/free APIs to tell the GPIO core that
the GPIO line is in use.
Thanks for this confirmation.
Why do you want to avoid using gpio_request/gpio_free?
I was assuming that DT based gpio IRQ registration will automatically
take care of
the above APIs. But since that is not the case(as mentioned by
santosh), we need to use the
gpio_request/free apis.
Hang on for a while, let's try to get to the bottom of this debate first
;-)
We have a canonical way of passing IRQ numbers to drivers through DT and
that is the interrupts attribute. It shouldn't matter if that IRQ pin
is connected to a real IRQ line or through a GPIO controller. In both
cases we should use the interrupts attribute.
If DT core doesn't allocate the GPIO for us then how does this work:
(omap4-sdp.dts)
127 mcspi1 {
128 eth@0 {
129 compatible = ks8851;
130 spi-max-frequency = 2400;
131 reg = 0;
132 interrupt-parent = gpio2;
133 interrupts = 2; /* gpio line 34 */
134 vdd-supply = vdd_eth;
135 };
136 };
There's no gpio request on the driver:
$ git grep -e gpio_request drivers/net/ethernet/micrel/ks8851.c
$
Since Benoit was the one who added that to the dts file (commit
e7c64db9), I assume he tested his patch before posting, so again I ask -
How does that work and why doesn't this work for Sourav's tsl2771
controller ?
This is either a regression on drivers/of, or commit e7c64db9 is also
broken...
Benoit, do you know how should this work ?
I had a discussion with Benoit on this. In fact there is a way to actually
trigger the GPIO request.
132 interrupt-parent = gpio2;
133 interrupts = 2; /* gpio line 34 */
As above you can see, GPIO2 bank and 2nd line.
And then it will make use of gpio_irq chip properties
to probe the GPIO line.
Saurabh can try this out for his use case.
I am using the above properties only and seeing the issue.
There seeems to be an issue with the GPIO DT probing. The Ethernet
works because there is another GPIO line from BANK2 is probed and since
BANK2 shares the clock, you won't see any issue.
We are looking at fixing the issue. Will keep the thread posted.
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
