Re: [PATCH 03/17] ARM: mark const init data with __initconst instead of __initdata
On Thu, Mar 29, 2012 at 11:12:20PM +0200, Uwe Kleine-König wrote:
...
diff --git a/arch/arm/mach-imx/imx51-dt.c b/arch/arm/mach-imx/imx51-dt.c
index 5cca573..7e00748 100644
--- a/arch/arm/mach-imx/imx51-dt.c
+++ b/arch/arm/mach-imx/imx51-dt.c
@@ -102,7 +102,7 @@ static struct sys_timer imx51_timer = {
.init = imx51_timer_init,
};
-static const char *imx51_dt_board_compat[] __initdata = {
+static const char *imx51_dt_board_compat[] __initconst = {
fsl,imx51-babbage,
fsl,imx51,
NULL
CC arch/arm/mach-imx/imx51-dt.o
arch/arm/mach-imx/imx51-dt.c:105:20: error: imx51_dt_board_compat causes a
section type conflict
make[2]: *** [arch/arm/mach-imx/imx51-dt.o] Error 1
I do not understand why though.
--
Regards,
Shawn
--
To unsubscribe from this list: send the line unsubscribe 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/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Wed, Mar 28, 2012 at 20:19:07, Shilimkar, Santosh wrote:
On Wed, Mar 28, 2012 at 8:07 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
On Wed, Mar 28, 2012 at 19:50:02, Shilimkar, Santosh wrote:
On Wed, Mar 28, 2012 at 7:46 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
On Wed, Mar 21, 2012 at 19:30:01, Shilimkar, Santosh wrote:
On Wed, Mar 21, 2012 at 5:12 PM, Hiremath, Vaibhav hvaib...@ti.com
wrote:
On Mon, Mar 19, 2012 at 17:45:32, Shilimkar, Santosh wrote:
On Monday 19 March 2012 05:14 PM, Ming Lei wrote:
On Mon, Mar 19, 2012 at 7:11 PM, Hiremath, Vaibhav
hvaib...@ti.com wrote:
[...]
Btw, if you need PM, how are you going to use GPTIMER
as a clocksource. Note sys-clock is generally stopped in
low power states. So that leaves you option with using
gptimer with 32K clock and in that case, GPTIMER
is not a better clock-source compare to 32K sync timer
and so shouldn't be the rating.
AM33xx has GPTIMER1 in wakeup domain, so that we are already using as a
Clocksource, without any issues.
GPTIMER1 is in wakeup domain on OMAP too but that doesn't
solve the issue I am talking. Once the sysclock is stopped, GPTIMER
can't tick anymore even if it is in wakeup domain.
The only way it will work is using always running 32KHz clock as
the clock input to GPT1. And then the end result is the accuracy
of GPTIMER = sync 32K timer. So they are of same rating.
Ohh ok, sorry I should have clarified it in my last response itself.
np.
AM33xx architecture is bit different than OMAP family, and gmtimer1 is
sourced from RTC32K clock, which is in wakeup domain.
This means we have RTC32K clock always running across suspend/resume.
0 - SEL1: Select CLK_M_OSC clock
1 - SEL2: Select CLK_32KHZ clock
2 - SEL3: Select TCLKIN clock
3 - SEL4: Select CLK_RC32K clock
4 - SEL5: Selects the CLK_32768 from 32KHz Crystal Osc
We use value 4 here, for RTC32K (always on clock).
I hope this clarifies what I am trying to say here.
I thought so and now if you look at last part of my comment.
Rating of 32K based synctimer and 32K based GPTIMER
should be same because of the precision. That's the main
point why I was saying that GPTIMER is not a better
clock-source( with 32k clock src) than sync timer when
both are enabled together.
Santosh,
In case of OMAP, we are using timer 2 for clocksource
OMAP_SYS_TIMER_INIT(2, 1, OMAP2_CLKEV_SOURCE, 2, OMAP2_MPU_SOURCE)
OMAP_SYS_TIMER_INIT(3, 1, OMAP3_CLKEV_SOURCE, 2, OMAP3_MPU_SOURCE)
And timer2 as clocksource is never used, since we have CONFIG_OMAP_32K_TIMER
defined in our defconfig.
Also, after looking at the code, I came across another problem,
setup_sched_clock(). But this can be easily fixed, if we source both the timers
with same clock (here 32k_fck).
Let me propose this,
How about, if I keep timer2 source always set to 32k_fclk for omap2,3,4?
And also, as mentioned by Santosh, I will register both the clocks as
clocksource with the same rating.
By default, kernel is going to use 32k_counter as a clocksource, and through
Command prompt user can override it without any issues.
Just to make sure that, whatever I am trying to propse here works and don't get
into unknown issue; I changed my code for this, and it is working for me
without any issues.
Also, this way I can completely get rid of option CONFIG_OMAP_32K_TIMER_HZ.
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 6b12372..ded78b7 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -45,6 +45,7 @@
#include plat/omap_hwmod.h
#include plat/omap_device.h
#include plat/omap-pm.h
+#include plat/clock.h
#include powerdomain.h
@@ -57,18 +58,18 @@
#define OMAP3_32K_SOURCE omap_32k_fck
#define OMAP4_32K_SOURCE sys_32k_ck
-#ifdef CONFIG_OMAP_32K_TIMER
+//#ifdef CONFIG_OMAP_32K_TIMER
#define OMAP2_CLKEV_SOURCE OMAP2_32K_SOURCE
#define OMAP3_CLKEV_SOURCE OMAP3_32K_SOURCE
#define OMAP4_CLKEV_SOURCE OMAP4_32K_SOURCE
#define OMAP3_SECURE_TIMER 12
-#else
+/*#else
#define OMAP2_CLKEV_SOURCE OMAP2_MPU_SOURCE
#define OMAP3_CLKEV_SOURCE OMAP3_MPU_SOURCE
#define OMAP4_CLKEV_SOURCE OMAP4_MPU_SOURCE
#define OMAP3_SECURE_TIMER 1
#endif
-
+*/
/* MAX_GPTIMER_ID: number of GPTIMERs on the chip */
#define MAX_GPTIMER_ID 12
@@ -244,6 +245,7 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
/* Clocksource code */
static struct omap_dm_timer clksrc;
+static bool is_dmtimer_clocksource;
/*
* clocksource
@@ -253,20 +255,38 @@ static cycle_t clocksource_read_cycles(struct clocksource
*cs)
return (cycle_t)__omap_dm_timer_read_counter(clksrc, 1);
}
+static int clocksource_enable(struct clocksource *cs)
+{
+ __omap_dm_timer_load_start(clksrc,
+ OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR,
+ omap_32k_read_sched_clock(), 1);
+
Re: [PATCH 03/17] ARM: mark const init data with __initconst instead of __initdata
On 23:12 Thu 29 Mar , Uwe Kleine-König wrote: As long as there is no other non-const variable marked __initdata in the same compilation unit it doesn't hurt. If there were one however compilation would fail with error: $variablename causes a section type conflict because a section containing const variables is marked read only and so cannot contain non-const variables. Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de Cc: Andrew Victor li...@maxim.org.za Cc: Nicolas Ferre nicolas.fe...@atmel.com Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com Cc: Russell King li...@arm.linux.org.uk Cc: Sekhar Nori nsek...@ti.com Cc: Kevin Hilman khil...@ti.com Cc: Kukjin Kim kgene@samsung.com Cc: Sascha Hauer ker...@pengutronix.de Cc: Shawn Guo shawn@linaro.org Cc: Lennert Buytenhek ker...@wantstofly.org Cc: Nicolas Pitre n...@fluxnic.net Cc: Eric Miao eric.y.m...@gmail.com Cc: Haojian Zhuang haojian.zhu...@gmail.com Cc: David Brown dav...@codeaurora.org Cc: Daniel Walker dwal...@fifo99.com Cc: Bryan Huntsman bry...@codeaurora.org Cc: Tony Lindgren t...@atomide.com Cc: Barry Song baohua.s...@csr.com Cc: Andrew Lunn and...@lunn.ch Cc: Lucas De Marchi lucas.demar...@profusion.mobi Cc: linux-arm-ker...@lists.infradead.org Cc: davinci-linux-open-sou...@linux.davincidsp.com Cc: linux-samsung-...@vger.kernel.org Cc: linux-arm-...@vger.kernel.org Cc: linux-omap@vger.kernel.org --- arch/arm/mach-at91/board-dt.c |2 +- arch/arm/mach-at91/clock.c|2 +- for at91 Acked-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com Best Regards, J. -- To unsubscribe from this list: send the line unsubscribe 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/3] ARM: OMAP2+: Add powerdomain PRM support for AM33XX device
On Thu, Mar 29, 2012 at 23:33:40, Hilman, Kevin wrote: Hi Vaibhav, Vaibhav Hiremath hvaib...@ti.com writes: After going round-n-round on how to add support for AM33XX family of device into kernel, especially for PRM and CM support, we have decided to handle it separately; as AM33XX-PRCM module is different than OMAP3 and OMAP4 architecture. The difference becomes very interesting/weird when it comes to the consistency for register offsets in PRM address space and bit-field offsets inside PRM registers, So along with Powerdomain data and PRM api's required for AM33XX device, this patch series adds, - XXX_RSTST register offset to struct omap_hwmod_omap4_prcm - PWRSTCTRL PWRSTST register offsets to struct powerdomain - Logicretstate and mem_on/ret/pwrst/retst mask to struct powerdomain Testing: This patch series has been boot tested on AM37xEVM and AM335x based BeagleBone community board. THANKS TO PAUL HERE...for helping and concluding on this, soon I will have similar patch for CM support, then clock-tree and hwmod will follow... Changes from V1 V2: - Rolled back to my original approach, where AM33xx device was handled separately (RFC version). My apologies for causing the run around. This approach (without the prminst layer) is indeed a better approach. Thanks for your patience (and persistence.) I went to give this a test on my BeagleBone, but it doesn't apply to mainline. What upstream commit is this supposed to apply onto. I and using, linux-omap/master and/or linux-omap/cleanup branches as a baseline for sending the patches. I tried it on v3.3, but patch 3 fails with a conflict in io.c. My bad. I did not include (or resend) voltage domain patch (had submitted last time itself). I will resend the all patch-series again including voltage domain addition patch. Just for reference, the series will follow the sequence - voltagedomains powerdomains clockdomains clock hwmod Looking at your am335x-staging branch, it seems that it depends on previous changes to io.c made in: arm:omap:am33xx: Add AM335XEVM machine support That patch appears to need an update for mainline as well. Can you please clarify on this? I use v3.3 to check on this, and it is Getting applied without any issues for me. I believe you are using V5 version of this patch series, also you can pick this patch from (created to give pull request to Tony) https://github.com/hvaibhav/am335x-linux/tree/am335x-baseport-for-tony Log: == commit 812e168a9584e180c12588ca2b0233e96461e997 Author: Afzal Mohammed af...@ti.com Date: Tue Aug 9 14:29:41 2011 +0530 arm:omap:am33xx: Add AM335XEVM machine support This patch adds minimal support for AM335X EVM. The approach taken here is to add AM335X EVM support to AM3517EVM, considering the fact that with device tree developement we will get rid of board-*.c. Signed-off-by: Afzal Mohammed af...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com [Changed ti816x_init_irq=ti81xx_init_irq, due to recent acceptance of patches] Reviewed-by: Kevin Hilman khil...@ti.com commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7 Author: Linus Torvalds torva...@linux-foundation.org Date: Sun Mar 18 16:15:34 2012 -0700 Linux 3.3 Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP: hwmod: Fix error handling in functions used OMAP4 onwards
On Thu, Mar 29, 2012 at 20:33:17, Hunter, Jon wrote: Hi Viabhav, On 3/29/2012 3:56, Hiremath, Vaibhav wrote: On Thu, Mar 29, 2012 at 11:42:34, Nayak, Rajendra wrote: On Wednesday 28 March 2012 12:02 PM, Hiremath, Vaibhav wrote: On Tue, Mar 27, 2012 at 15:28:31, Nayak, Rajendra wrote: Some functions like _omap4_disable_module() and _omap4_wait_target_disable() are (will be) used on all OMAPs OMAP4 and beyond which support module level control. Fix the error checks in these functions to return if called on any platform pre OMAP4 (i.e OMAP2 and OMAP3) instead of checking for !cpu_is_omap44xx(). This avoids having to update the error check with a ' !cpu_is_omap54xx()' when OMAP5 is introduced and possibly similar updates when further OMAP generations are added. Let me add some flavor here :) AM33xx, which has module level control, but falls under OMAP3 family of devices. cpu_is_omap34xx() is true for AM33xx device and we have to add check in all these functions. And I am sure we will have many of such devices in the future. Can we use some flag based option here, instead of cpu_is_xxx() check? The intent of this patch was to make the error handling uniform across all modules control functions in hwmod, and it atleast addresses one problem of having to update these checks every time a new OMAP gets added. The problem that you bring up with AM33xx is regardless of this patch (you would still need to go update every !cpu_is_omap44xx() check) Indeed, in any of cpu_is_xxx() check implementation, I have to add check for cpu_is_am33xx(). I hope we can avoid adding more cpu_is_am. That should be a last resort. Yes, indeed; adding cpu_is_xxx check would be my last option. Thanks, Vaibhav Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Fri, Mar 30, 2012 at 12:04 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
On Wed, Mar 28, 2012 at 20:19:07, Shilimkar, Santosh wrote:
On Wed, Mar 28, 2012 at 8:07 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
On Wed, Mar 28, 2012 at 19:50:02, Shilimkar, Santosh wrote:
On Wed, Mar 28, 2012 at 7:46 PM, Hiremath, Vaibhav hvaib...@ti.com
wrote:
On Wed, Mar 21, 2012 at 19:30:01, Shilimkar, Santosh wrote:
On Wed, Mar 21, 2012 at 5:12 PM, Hiremath, Vaibhav hvaib...@ti.com
wrote:
On Mon, Mar 19, 2012 at 17:45:32, Shilimkar, Santosh wrote:
On Monday 19 March 2012 05:14 PM, Ming Lei wrote:
On Mon, Mar 19, 2012 at 7:11 PM, Hiremath, Vaibhav
hvaib...@ti.com wrote:
[...]
I thought so and now if you look at last part of my comment.
Rating of 32K based synctimer and 32K based GPTIMER
should be same because of the precision. That's the main
point why I was saying that GPTIMER is not a better
clock-source( with 32k clock src) than sync timer when
both are enabled together.
Santosh,
In case of OMAP, we are using timer 2 for clocksource
OMAP_SYS_TIMER_INIT(2, 1, OMAP2_CLKEV_SOURCE, 2, OMAP2_MPU_SOURCE)
OMAP_SYS_TIMER_INIT(3, 1, OMAP3_CLKEV_SOURCE, 2, OMAP3_MPU_SOURCE)
And timer2 as clocksource is never used, since we have CONFIG_OMAP_32K_TIMER
defined in our defconfig.
Also, after looking at the code, I came across another problem,
setup_sched_clock(). But this can be easily fixed, if we source both the
timers with same clock (here 32k_fck).
Let me propose this,
How about, if I keep timer2 source always set to 32k_fclk for omap2,3,4?
And also, as mentioned by Santosh, I will register both the clocks as
clocksource with the same rating.
By default, kernel is going to use 32k_counter as a clocksource, and through
Command prompt user can override it without any issues.
Just to make sure that, whatever I am trying to propse here works and don't
get into unknown issue; I changed my code for this, and it is working for me
without any issues.
Let's not make this more complicated. I guess below simple patch should sort
out the issue. I briefly tested it on OMAP4 and it works. let me know
if it helps AMxxx machines.
Regards
Santosh
From 0a9283e26174d76ff2753ac88521b61a26b24e8f Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Fri, 30 Mar 2012 12:43:29 +0530
Subject: [PATCH] ARM: OMAP: Make OMAP clocksource source selection runtime.
Current OMAP code support couple of clocksource options based on compilation
flag. The 32KHz based sync timer and a gptimer based clock source which can
run on 32KHz or system clock (e.g 38.4 MHz). So there can be 3 options.
1. 32KHz synctimer
2. Sysclock based(e.g 38.4 MHz) gptimer
3. 32KHz based gptimer.
The optional gptimer based clocksource was added so that it can give the
high precision than synctimer so expected usage was 2 and not 3. Unfortunatlly
option 2, clocksource doesn't meet the requirement of free-running clock
as per clocksource need. It stops in low power states when sysclock is cut.
That makes gptimer based clocksource option useless for OMAP2/3/4 devices
with sysclock as a clock input. Option 3 will still work but it is no better'
than 32K synctimer based clocksource.
So ideally we can kill the gptimer based clocksource option but there are some
OMAP based derivative SoCs like AM which doesn't have synictimer hardware IP
and need to fallback on 32KHz based gptimer clocksource.
Considering above, make synctimer and gptimer clocksource runtime
selectable so that both OMAP and AM continue to use the same code.
Not-yet-signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/timer.c | 25 -
1 files changed, 8 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index c512bac..3878e59 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -234,21 +234,6 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
}
/* Clocksource code */
-
-#ifdef CONFIG_OMAP_32K_TIMER
-/*
- * When 32k-timer is enabled, don't use GPTimer for clocksource
- * instead, just leave default clocksource which uses the 32k
- * sync counter. See clocksource setup in plat-omap/counter_32k.c
- */
-
-static void __init omap2_gp_clocksource_init(int unused, const char *dummy)
-{
- omap_init_clocksource_32k();
-}
-
-#else
-
static struct omap_dm_timer clksrc;
/*
@@ -276,7 +261,7 @@ static u32 notrace dmtimer_read_sched_clock(void)
}
/* Setup free-running counter for clocksource */
-static void __init omap2_gp_clocksource_init(int gptimer_id,
+static void __init omap2_gptimer_clocksource_init(int gptimer_id,
const char *fck_source)
{
int res;
@@ -295,7 +280,13 @@ static void __init omap2_gp_clocksource_init(int
gptimer_id,
pr_err(Could not register clocksource %s\n,
Re: Suspend broken on 3.3?
-Original Message- From: Raja, Govindraj govindraj.r...@ti.com To: Joe Woodward j...@terrafix.co.uk Cc: Paul Walmsley p...@pwsan.com, Kevin Hilman khil...@ti.com, linux-omap@vger.kernel.org, Felipe Balbi ba...@ti.com, ne...@suse.de Date: Thu, 29 Mar 2012 19:59:54 +0530 Subject: Re: Suspend broken on 3.3? On Thu, Mar 29, 2012 at 5:10 PM, Joe Woodward j...@terrafix.co.uk wrote: -Original Message- From: Joe Woodward j...@terrafix.co.uk To: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com, Raja\\, Govindraj govindraj.r...@ti.com, linux-omap@vger.kernel.org, Felipe Balbi ba...@ti.com, ne...@suse.de Date: Thu, 29 Mar 2012 12:27:55 +0100 Subject: Re: Suspend broken on 3.3? Hello Joe, thanks for reporting this. Some thoughts -- really just pure speculation -- but I hope some of it might be useful for you... On Thu, 29 Mar 2012, Joe Woodward wrote: After digging a bit further I found that the problem isn't lost characters or character corruption at all... The UART is actually at 430KBaud (not 900KBaud as I mentioned earlier). 430Kbps? Could you confirm this? OMAP UARTs don't support that rate as far as I know - the closest is 460Kbps (OMAP34xx TRM vZR Table 17-1 UART Mode Baud Rates, Divisor Values, and Error Rates). If one was desperate, it might be possible to get 430Kbps by tweaking other parts of the clock tree though... Sorry for the confusion... It's 460KBaud - the 430 was just a typo in my previous mail... The data received is very bursty (i.e. sets of messages every second or so), containing a sync sequence to indicate a start of packet. The received bytes should be: 0x01, 0x52, 0x41 rest of packet. This works 100% of the time on 3.2, but on 3.3 I sometimes (but not always) get: 0x01, 0x00, 0x52, 0x41. i.e. there is a NULL/0x00 inserted after the first character. Is this on the serial console, or on a non-console serial port? Looking at drivers/tty/serial/omap-serial.c:receive_chars(), I wonder if the driver is somehow reading bytes from the RX FIFO when it's empty. It's unclear to me how this could happen. But you might want to try doing an LSR read right before entering the loop in drivers/tty/serial/omap-serial.c:receive_chars(). In stock v3.3, this would mean adding lsr = serial_in(up, UART_LSR); at line 190 of drivers/tty/serial/omap-serial.c. Adding this is made no obvious difference. You might also try the DMA path as an experiment. This will totally wedge power management due to an insanely low timer expiration in that path, but at least might help narrow the problem down. To do so with a quick hack, you could set omap_serial_default_info.dma_enabled to true instead of false at arch/arm/mach-omap2/serial.c:76. This did the trick (I've added it in addition to the LSR read above, i'll back out the LSR read and see if it still works). When DMA is enabled the behaviour (as seen from my application in userspace) is the same as on the stock 3.2 kernel (i.e. for me it works :) ). I've just realised that if anyone has joined this thread late, then I'm running in a state with Govindraj's patch in a previous mail in this thread applied to serial.c to fix the suspend issues due to the UART wakeup's not being correctly changed from userspace via sysfs. It may actually by this patch that is causing the interrupt-enabled serial driver to have broken? The tty that is causing me a problem does have wake-from-suspend disabled for it from userspace... Is the patch shared earlier causing this issue of getting 0x00 from rx randomly ? In short, yes. I've gone back to a stock 3.3 kernel and the serial ports give the correct data, but suspend fails (due to not being able to disable wake-from-serial). I then applied your patch and could disable wakeup on the serial ports and suspend correctly, but the (non-console) serial port starts to misbehave. Forcing the driver to be DMA-enabled caused everything to work again. So something in the patch is causing the (default) interrupt-enabled serial driver to occassionally fail. Sorry for the goose chase yesterday. I didn't even think to check if the patch caused the issue as it seemed a bit unrelated. Cheers, Joe -- Thanks, Govindraj.R -- To unsubscribe from this list: send the line unsubscribe 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
OMAP4 errata i740
Hi, I just found out about OMAP4 errata i740: DESCRIPTION A bug has been identified in the interconnect agent handling the connect-disconnect protocol between an initiator and interconnect. When the disconnect protocol violation occurs, there is a dead lock and a system lockup is observed. The issue can occur in a corner case when the impacted module has started a transition to standby, for the L3 initiator on which it is attached, exactly at the time the initiator gets an event for exiting idle state. Such a situation can occur when the impacted initiator is generating short MStandby pulses (pulse durations less than one L4 clock cycle). DSS and ISS are the only initiators that are impacted. WORKAROUND L3_CLK1 must be kept in NO-IDLE when the DSS clock domain is ON. It can be switched back to HW_AUTO when the DSS clock domain is IDLE. L3_CLK2 must be kept in NO-IDLE when the ISS clock domain is ON. It can be switched back to HW_AUTO when the ISS clock domain is IDLE. All OMAP4 versions seem to be affected. I couldn't find a mention about this in the mainline kernel. Any ideas how and where this should be fixed? Tomi signature.asc Description: This is a digitally signed message part
Re: OMAP4 errata i740
On Fri, Mar 30, 2012 at 1:37 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi, I just found out about OMAP4 errata i740: DESCRIPTION A bug has been identified in the interconnect agent handling the connect-disconnect protocol between an initiator and interconnect. When the disconnect protocol violation occurs, there is a dead lock and a system lockup is observed. The issue can occur in a corner case when the impacted module has started a transition to standby, for the L3 initiator on which it is attached, exactly at the time the initiator gets an event for exiting idle state. Such a situation can occur when the impacted initiator is generating short MStandby pulses (pulse durations less than one L4 clock cycle). DSS and ISS are the only initiators that are impacted. WORKAROUND L3_CLK1 must be kept in NO-IDLE when the DSS clock domain is ON. It can be switched back to HW_AUTO when the DSS clock domain is IDLE. L3_CLK2 must be kept in NO-IDLE when the ISS clock domain is ON. It can be switched back to HW_AUTO when the ISS clock domain is IDLE. All OMAP4 versions seem to be affected. I couldn't find a mention about this in the mainline kernel. Any ideas how and where this should be fixed? It's not patched for mainline. Generally clock-domain code is abstracted from drivers but considering the errata and affected modules, I guees it should be handled by DSS driver since that is where the state of DSS or ISS will be known. Note ISS will be automatically taken care since it will always use disaplay. In internal tree's this was handled as part of DSS early suspend/resume 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 errata i740
On Fri, 2012-03-30 at 13:51 +0530, Shilimkar, Santosh wrote: On Fri, Mar 30, 2012 at 1:37 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: All OMAP4 versions seem to be affected. I couldn't find a mention about this in the mainline kernel. Any ideas how and where this should be fixed? It's not patched for mainline. Generally clock-domain code is abstracted from drivers but considering the errata and affected modules, I guees it should be handled by DSS driver since that is where the state of DSS or ISS will be known. Note ISS will be automatically taken care since it will always use disaplay. In internal tree's this was handled as part of DSS early suspend/resume That version doesn't work as it uses functions that are not exported to drivers. I don't know much about the clock domain code, but I hope there's a way to handle it there. Otherwise I guess I need to add a new set of platform callback functions, so that the dss driver can call arch/arm/mach-omap2 code to enable and disable the work-around. I dislike that because I'm currently trying to remove those kinds of hacks to make dss work better with DT =). Tomi signature.asc Description: This is a digitally signed message part
Re: OMAP4 errata i740
+ Kevin On Friday 30 March 2012 01:56 PM, Tomi Valkeinen wrote: On Fri, 2012-03-30 at 13:51 +0530, Shilimkar, Santosh wrote: On Fri, Mar 30, 2012 at 1:37 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: All OMAP4 versions seem to be affected. I couldn't find a mention about this in the mainline kernel. Any ideas how and where this should be fixed? It's not patched for mainline. Generally clock-domain code is abstracted from drivers but considering the errata and affected modules, I guees it should be handled by DSS driver since that is where the state of DSS or ISS will be known. Note ISS will be automatically taken care since it will always use disaplay. In internal tree's this was handled as part of DSS early suspend/resume That version doesn't work as it uses functions that are not exported to drivers. I don't know much about the clock domain code, but I hope there's a way to handle it there. Otherwise I guess I need to add a new set of platform callback functions, so that the dss driver can call arch/arm/mach-omap2 code to enable and disable the work-around. I dislike that because I'm currently trying to remove those kinds of hacks to make dss work better with DT =). I agree. In fact I faced similar issue when I briefly tried moving OMAP cpuidle code to drivers/idle/*. That time me and Kevin concluded that till we move the powerdomain, clockdomain code to drivers/* and export it, the cpuidle movement needs to be deferred. 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/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Fri, Mar 30, 2012 at 13:11:35, Shilimkar, Santosh wrote:
On Fri, Mar 30, 2012 at 12:04 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
On Wed, Mar 28, 2012 at 20:19:07, Shilimkar, Santosh wrote:
On Wed, Mar 28, 2012 at 8:07 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
On Wed, Mar 28, 2012 at 19:50:02, Shilimkar, Santosh wrote:
On Wed, Mar 28, 2012 at 7:46 PM, Hiremath, Vaibhav hvaib...@ti.com
wrote:
On Wed, Mar 21, 2012 at 19:30:01, Shilimkar, Santosh wrote:
On Wed, Mar 21, 2012 at 5:12 PM, Hiremath, Vaibhav hvaib...@ti.com
wrote:
On Mon, Mar 19, 2012 at 17:45:32, Shilimkar, Santosh wrote:
On Monday 19 March 2012 05:14 PM, Ming Lei wrote:
On Mon, Mar 19, 2012 at 7:11 PM, Hiremath, Vaibhav
hvaib...@ti.com wrote:
[...]
I thought so and now if you look at last part of my comment.
Rating of 32K based synctimer and 32K based GPTIMER
should be same because of the precision. That's the main
point why I was saying that GPTIMER is not a better
clock-source( with 32k clock src) than sync timer when
both are enabled together.
Santosh,
In case of OMAP, we are using timer 2 for clocksource
OMAP_SYS_TIMER_INIT(2, 1, OMAP2_CLKEV_SOURCE, 2, OMAP2_MPU_SOURCE)
OMAP_SYS_TIMER_INIT(3, 1, OMAP3_CLKEV_SOURCE, 2, OMAP3_MPU_SOURCE)
And timer2 as clocksource is never used, since we have CONFIG_OMAP_32K_TIMER
defined in our defconfig.
Also, after looking at the code, I came across another problem,
setup_sched_clock(). But this can be easily fixed, if we source both the
timers with same clock (here 32k_fck).
Let me propose this,
How about, if I keep timer2 source always set to 32k_fclk for omap2,3,4?
And also, as mentioned by Santosh, I will register both the clocks as
clocksource with the same rating.
By default, kernel is going to use 32k_counter as a clocksource, and through
Command prompt user can override it without any issues.
Just to make sure that, whatever I am trying to propse here works and don't
get into unknown issue; I changed my code for this, and it is working for
me without any issues.
Let's not make this more complicated. I guess below simple patch should sort
out the issue. I briefly tested it on OMAP4 and it works. let me know
if it helps AMxxx machines.
Regards
Santosh
From 0a9283e26174d76ff2753ac88521b61a26b24e8f Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Fri, 30 Mar 2012 12:43:29 +0530
Subject: [PATCH] ARM: OMAP: Make OMAP clocksource source selection runtime.
Current OMAP code support couple of clocksource options based on compilation
flag. The 32KHz based sync timer and a gptimer based clock source which can
run on 32KHz or system clock (e.g 38.4 MHz). So there can be 3 options.
1. 32KHz synctimer
2. Sysclock based(e.g 38.4 MHz) gptimer
3. 32KHz based gptimer.
The optional gptimer based clocksource was added so that it can give the
high precision than synctimer so expected usage was 2 and not 3. Unfortunatlly
option 2, clocksource doesn't meet the requirement of free-running clock
as per clocksource need. It stops in low power states when sysclock is cut.
That makes gptimer based clocksource option useless for OMAP2/3/4 devices
with sysclock as a clock input. Option 3 will still work but it is no better'
than 32K synctimer based clocksource.
So ideally we can kill the gptimer based clocksource option but there are some
OMAP based derivative SoCs like AM which doesn't have synictimer hardware
IP
and need to fallback on 32KHz based gptimer clocksource.
Considering above, make synctimer and gptimer clocksource runtime
selectable so that both OMAP and AM continue to use the same code.
Not-yet-signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/timer.c | 25 -
1 files changed, 8 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index c512bac..3878e59 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -234,21 +234,6 @@ static void __init omap2_gp_clockevent_init(int
gptimer_id,
}
/* Clocksource code */
-
-#ifdef CONFIG_OMAP_32K_TIMER
-/*
- * When 32k-timer is enabled, don't use GPTimer for clocksource
- * instead, just leave default clocksource which uses the 32k
- * sync counter. See clocksource setup in plat-omap/counter_32k.c
- */
-
-static void __init omap2_gp_clocksource_init(int unused, const char *dummy)
-{
- omap_init_clocksource_32k();
-}
-
-#else
-
static struct omap_dm_timer clksrc;
/*
@@ -276,7 +261,7 @@ static u32 notrace dmtimer_read_sched_clock(void)
}
/* Setup free-running counter for clocksource */
-static void __init omap2_gp_clocksource_init(int gptimer_id,
+static void __init omap2_gptimer_clocksource_init(int gptimer_id,
const char
Re: OMAP4 errata i740
On Friday 30 March 2012 02:01 PM, Santosh Shilimkar wrote: + Kevin On Friday 30 March 2012 01:56 PM, Tomi Valkeinen wrote: On Fri, 2012-03-30 at 13:51 +0530, Shilimkar, Santosh wrote: On Fri, Mar 30, 2012 at 1:37 PM, Tomi Valkeinentomi.valkei...@ti.com wrote: All OMAP4 versions seem to be affected. I couldn't find a mention about this in the mainline kernel. Any ideas how and where this should be fixed? It's not patched for mainline. Generally clock-domain code is abstracted from drivers but considering the errata and affected modules, I guees it should be handled by DSS driver since that is where the state of DSS or ISS will be known. Note ISS will be automatically taken care since it will always use disaplay. In internal tree's this was handled as part of DSS early suspend/resume That version doesn't work as it uses functions that are not exported to drivers. I don't know much about the clock domain code, but I hope there's a way to handle it there. Otherwise I guess I need to add a new set of platform callback functions, so that the dss driver can call arch/arm/mach-omap2 code to enable and disable the work-around. I dislike that because I'm currently trying to remove those kinds of hacks to make dss work better with DT =). I agree. In fact I faced similar issue when I briefly tried moving OMAP cpuidle code to drivers/idle/*. That time me and Kevin concluded that till we move the powerdomain, clockdomain code to drivers/* and export it, the cpuidle movement needs to be deferred. How about preventing the issue to occur by keeping DSS and ISS in No-standby mode for the affected OMAP versions. The errata says: Such a situation can occur when the impacted initiator is generating short MStandby pulses (pulse durations less than one L4 clock cycle) Chaning the mstandby hwmod data for DSS and ISS would prevent the need for exporting these clock domain functions only for this errata. Archit 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: Fix omap2+ build error.
With CONFIG_OMAP4_ERRATA_I688 enabled, omap2+ build
was broken as below.
arch/arm/kernel/io.c: In function '_memcpy_toio':
arch/arm/kernel/io.c:29: error: implicit declaration of function
'outer_sync'
make[1]: *** [arch/arm/kernel/io.o] Error 1
Fixing this here.
Signed-off-by: R Sricharan r.sricha...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/include/asm/barrier.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
index 44f4a09..0511238 100644
--- a/arch/arm/include/asm/barrier.h
+++ b/arch/arm/include/asm/barrier.h
@@ -2,6 +2,7 @@
#define __ASM_BARRIER_H
#ifndef __ASSEMBLY__
+#include asm/outercache.h
#define nop() __asm__ __volatile__(mov\tr0,r0\t@ nop\n\t);
@@ -39,7 +40,6 @@
#ifdef CONFIG_ARCH_HAS_BARRIERS
#include mach/barriers.h
#elif defined(CONFIG_ARM_DMA_MEM_BUFFERABLE) || defined(CONFIG_SMP)
-#include asm/outercache.h
#define mb() do { dsb(); outer_sync(); } while (0)
#define rmb() dsb()
#define wmb() mb()
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Friday 30 March 2012 02:02 PM, Hiremath, Vaibhav wrote:
On Fri, Mar 30, 2012 at 13:11:35, Shilimkar, Santosh wrote:
On Fri, Mar 30, 2012 at 12:04 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
On Wed, Mar 28, 2012 at 20:19:07, Shilimkar, Santosh wrote:
On Wed, Mar 28, 2012 at 8:07 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
On Wed, Mar 28, 2012 at 19:50:02, Shilimkar, Santosh wrote:
On Wed, Mar 28, 2012 at 7:46 PM, Hiremath, Vaibhav hvaib...@ti.com
wrote:
On Wed, Mar 21, 2012 at 19:30:01, Shilimkar, Santosh wrote:
On Wed, Mar 21, 2012 at 5:12 PM, Hiremath, Vaibhav hvaib...@ti.com
wrote:
On Mon, Mar 19, 2012 at 17:45:32, Shilimkar, Santosh wrote:
On Monday 19 March 2012 05:14 PM, Ming Lei wrote:
On Mon, Mar 19, 2012 at 7:11 PM, Hiremath, Vaibhav
hvaib...@ti.com wrote:
[...]
I thought so and now if you look at last part of my comment.
Rating of 32K based synctimer and 32K based GPTIMER
should be same because of the precision. That's the main
point why I was saying that GPTIMER is not a better
clock-source( with 32k clock src) than sync timer when
both are enabled together.
Santosh,
In case of OMAP, we are using timer 2 for clocksource
OMAP_SYS_TIMER_INIT(2, 1, OMAP2_CLKEV_SOURCE, 2, OMAP2_MPU_SOURCE)
OMAP_SYS_TIMER_INIT(3, 1, OMAP3_CLKEV_SOURCE, 2, OMAP3_MPU_SOURCE)
And timer2 as clocksource is never used, since we have CONFIG_OMAP_32K_TIMER
defined in our defconfig.
Also, after looking at the code, I came across another problem,
setup_sched_clock(). But this can be easily fixed, if we source both the
timers with same clock (here 32k_fck).
Let me propose this,
How about, if I keep timer2 source always set to 32k_fclk for omap2,3,4?
And also, as mentioned by Santosh, I will register both the clocks as
clocksource with the same rating.
By default, kernel is going to use 32k_counter as a clocksource, and through
Command prompt user can override it without any issues.
Just to make sure that, whatever I am trying to propse here works and don't
get into unknown issue; I changed my code for this, and it is working for
me without any issues.
Let's not make this more complicated. I guess below simple patch should sort
out the issue. I briefly tested it on OMAP4 and it works. let me know
if it helps AMxxx machines.
Regards
Santosh
From 0a9283e26174d76ff2753ac88521b61a26b24e8f Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Fri, 30 Mar 2012 12:43:29 +0530
Subject: [PATCH] ARM: OMAP: Make OMAP clocksource source selection runtime.
Current OMAP code support couple of clocksource options based on compilation
flag. The 32KHz based sync timer and a gptimer based clock source which can
run on 32KHz or system clock (e.g 38.4 MHz). So there can be 3 options.
1. 32KHz synctimer
2. Sysclock based(e.g 38.4 MHz) gptimer
3. 32KHz based gptimer.
The optional gptimer based clocksource was added so that it can give the
high precision than synctimer so expected usage was 2 and not 3.
Unfortunatlly
option 2, clocksource doesn't meet the requirement of free-running clock
as per clocksource need. It stops in low power states when sysclock is cut.
That makes gptimer based clocksource option useless for OMAP2/3/4 devices
with sysclock as a clock input. Option 3 will still work but it is no better'
than 32K synctimer based clocksource.
So ideally we can kill the gptimer based clocksource option but there are
some
OMAP based derivative SoCs like AM which doesn't have synictimer
hardware IP
and need to fallback on 32KHz based gptimer clocksource.
Considering above, make synctimer and gptimer clocksource runtime
selectable so that both OMAP and AM continue to use the same code.
Not-yet-signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/timer.c | 25 -
1 files changed, 8 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index c512bac..3878e59 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -234,21 +234,6 @@ static void __init omap2_gp_clockevent_init(int
gptimer_id,
}
/* Clocksource code */
-
-#ifdef CONFIG_OMAP_32K_TIMER
-/*
- * When 32k-timer is enabled, don't use GPTimer for clocksource
- * instead, just leave default clocksource which uses the 32k
- * sync counter. See clocksource setup in plat-omap/counter_32k.c
- */
-
-static void __init omap2_gp_clocksource_init(int unused, const char *dummy)
-{
-omap_init_clocksource_32k();
-}
-
-#else
-
static struct omap_dm_timer clksrc;
/*
@@ -276,7 +261,7 @@ static u32 notrace dmtimer_read_sched_clock(void)
}
/* Setup free-running counter for clocksource */
-static void __init omap2_gp_clocksource_init(int gptimer_id,
+static void __init omap2_gptimer_clocksource_init(int gptimer_id,
const char *fck_source)
{
int res;
Re: OMAP4 errata i740
On Friday 30 March 2012 02:04 PM, Archit Taneja wrote: On Friday 30 March 2012 02:01 PM, Santosh Shilimkar wrote: + Kevin On Friday 30 March 2012 01:56 PM, Tomi Valkeinen wrote: On Fri, 2012-03-30 at 13:51 +0530, Shilimkar, Santosh wrote: On Fri, Mar 30, 2012 at 1:37 PM, Tomi Valkeinentomi.valkei...@ti.com wrote: All OMAP4 versions seem to be affected. I couldn't find a mention about this in the mainline kernel. Any ideas how and where this should be fixed? It's not patched for mainline. Generally clock-domain code is abstracted from drivers but considering the errata and affected modules, I guees it should be handled by DSS driver since that is where the state of DSS or ISS will be known. Note ISS will be automatically taken care since it will always use disaplay. In internal tree's this was handled as part of DSS early suspend/resume That version doesn't work as it uses functions that are not exported to drivers. I don't know much about the clock domain code, but I hope there's a way to handle it there. Otherwise I guess I need to add a new set of platform callback functions, so that the dss driver can call arch/arm/mach-omap2 code to enable and disable the work-around. I dislike that because I'm currently trying to remove those kinds of hacks to make dss work better with DT =). I agree. In fact I faced similar issue when I briefly tried moving OMAP cpuidle code to drivers/idle/*. That time me and Kevin concluded that till we move the powerdomain, clockdomain code to drivers/* and export it, the cpuidle movement needs to be deferred. How about preventing the issue to occur by keeping DSS and ISS in No-standby mode for the affected OMAP versions. The errata says: Such a situation can occur when the impacted initiator is generating short MStandby pulses (pulse durations less than one L4 clock cycle) Chaning the mstandby hwmod data for DSS and ISS would prevent the need for exporting these clock domain functions only for this errata. That will just break PM :-) With this change DSS will never assert standby and then PRCM can never send idle-req to modules. Indirectly no power transitions. 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: Suspend broken on 3.3?
On Fri, Mar 30, 2012 at 1:23 PM, Joe Woodward j...@terrafix.co.uk wrote: -Original Message- From: Raja, Govindraj govindraj.r...@ti.com To: Joe Woodward j...@terrafix.co.uk Cc: Paul Walmsley p...@pwsan.com, Kevin Hilman khil...@ti.com, linux-omap@vger.kernel.org, Felipe Balbi ba...@ti.com, ne...@suse.de Date: Thu, 29 Mar 2012 19:59:54 +0530 Subject: Re: Suspend broken on 3.3? On Thu, Mar 29, 2012 at 5:10 PM, Joe Woodward j...@terrafix.co.uk wrote: -Original Message- From: Joe Woodward j...@terrafix.co.uk To: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com, Raja\\, Govindraj govindraj.r...@ti.com, linux-omap@vger.kernel.org, Felipe Balbi ba...@ti.com, ne...@suse.de Date: Thu, 29 Mar 2012 12:27:55 +0100 Subject: Re: Suspend broken on 3.3? Hello Joe, thanks for reporting this. Some thoughts -- really just pure speculation -- but I hope some of it might be useful for you... On Thu, 29 Mar 2012, Joe Woodward wrote: After digging a bit further I found that the problem isn't lost characters or character corruption at all... The UART is actually at 430KBaud (not 900KBaud as I mentioned earlier). 430Kbps? Could you confirm this? OMAP UARTs don't support that rate as far as I know - the closest is 460Kbps (OMAP34xx TRM vZR Table 17-1 UART Mode Baud Rates, Divisor Values, and Error Rates). If one was desperate, it might be possible to get 430Kbps by tweaking other parts of the clock tree though... Sorry for the confusion... It's 460KBaud - the 430 was just a typo in my previous mail... The data received is very bursty (i.e. sets of messages every second or so), containing a sync sequence to indicate a start of packet. The received bytes should be: 0x01, 0x52, 0x41 rest of packet. This works 100% of the time on 3.2, but on 3.3 I sometimes (but not always) get: 0x01, 0x00, 0x52, 0x41. i.e. there is a NULL/0x00 inserted after the first character. Is this on the serial console, or on a non-console serial port? Looking at drivers/tty/serial/omap-serial.c:receive_chars(), I wonder if the driver is somehow reading bytes from the RX FIFO when it's empty. It's unclear to me how this could happen. But you might want to try doing an LSR read right before entering the loop in drivers/tty/serial/omap-serial.c:receive_chars(). In stock v3.3, this would mean adding lsr = serial_in(up, UART_LSR); at line 190 of drivers/tty/serial/omap-serial.c. Adding this is made no obvious difference. You might also try the DMA path as an experiment. This will totally wedge power management due to an insanely low timer expiration in that path, but at least might help narrow the problem down. To do so with a quick hack, you could set omap_serial_default_info.dma_enabled to true instead of false at arch/arm/mach-omap2/serial.c:76. This did the trick (I've added it in addition to the LSR read above, i'll back out the LSR read and see if it still works). When DMA is enabled the behaviour (as seen from my application in userspace) is the same as on the stock 3.2 kernel (i.e. for me it works :) ). I've just realised that if anyone has joined this thread late, then I'm running in a state with Govindraj's patch in a previous mail in this thread applied to serial.c to fix the suspend issues due to the UART wakeup's not being correctly changed from userspace via sysfs. It may actually by this patch that is causing the interrupt-enabled serial driver to have broken? The tty that is causing me a problem does have wake-from-suspend disabled for it from userspace... Is the patch shared earlier causing this issue of getting 0x00 from rx randomly ? In short, yes. I've gone back to a stock 3.3 kernel and the serial ports give the correct data, but suspend fails (due to not being able to disable wake-from-serial). I then applied your patch and could disable wakeup on the serial ports and suspend correctly, but the (non-console) serial port starts to misbehave. Forcing the driver to be DMA-enabled caused everything to work again. So something in the patch is causing the (default) interrupt-enabled serial driver to occassionally fail. Disabling module level wakeup by default on bootup in previous shared patch in serial.c in omap_uart_idle_init = omap_uart_disable_module_wakeup might be causing this issue and probably this should be left enabled by default and be disabled only when requested from sysfs on suspend. Could you please try attached patch and let me know if this solves the rx issue as well, without using dma mode. -- Thanks, Govindraj.R 0001-OMAP2-UART-Correct-the-module-level-wakeup-enable-di.patch Description: Binary data
Re: [PATCH] ARM: OMAP2+: Fix omap2+ build error.
On Fri, Mar 30, 2012 at 2:05 PM, R Sricharan r.sricha...@ti.com wrote: With CONFIG_OMAP4_ERRATA_I688 enabled, omap2+ build was broken as below. arch/arm/kernel/io.c: In function '_memcpy_toio': arch/arm/kernel/io.c:29: error: implicit declaration of function 'outer_sync' make[1]: *** [arch/arm/kernel/io.o] Error 1 Fixing this here. Signed-off-by: R Sricharan r.sricha...@ti.com Acked-by: Santosh Shilimkar santosh.shilim...@ti.com --- arch/arm/include/asm/barrier.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Can you please add information about the commit after this was broken. Regards santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM: OMAP2+: Fix omap2+ build error.
With CONFIG_OMAP4_ERRATA_I688 enabled, omap2+ build
was broken as below.
arch/arm/kernel/io.c: In function '_memcpy_toio':
arch/arm/kernel/io.c:29: error: implicit declaration of function
'outer_sync'
make[1]: *** [arch/arm/kernel/io.o] Error 1
after the commit,
commit 9f97da78bf018206fb623cd351d454af2f105fe0
Author: David Howells dhowe...@redhat.com
Date: Wed Mar 28 18:30:01 2012 +0100
Disintegrate asm/system.h for ARM
Disintegrate asm/system.h for ARM.
Fixing this here.
Signed-off-by: R Sricharan r.sricha...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/include/asm/barrier.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/barrier.h b/arch/arm/include/asm/barrier.h
index 44f4a09..0511238 100644
--- a/arch/arm/include/asm/barrier.h
+++ b/arch/arm/include/asm/barrier.h
@@ -2,6 +2,7 @@
#define __ASM_BARRIER_H
#ifndef __ASSEMBLY__
+#include asm/outercache.h
#define nop() __asm__ __volatile__(mov\tr0,r0\t@ nop\n\t);
@@ -39,7 +40,6 @@
#ifdef CONFIG_ARCH_HAS_BARRIERS
#include mach/barriers.h
#elif defined(CONFIG_ARM_DMA_MEM_BUFFERABLE) || defined(CONFIG_SMP)
-#include asm/outercache.h
#define mb() do { dsb(); outer_sync(); } while (0)
#define rmb() dsb()
#define wmb() mb()
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Fri, Mar 30, 2012 at 14:08:20, Shilimkar, Santosh wrote:
On Friday 30 March 2012 02:02 PM, Hiremath, Vaibhav wrote:
On Fri, Mar 30, 2012 at 13:11:35, Shilimkar, Santosh wrote:
On Fri, Mar 30, 2012 at 12:04 PM, Hiremath, Vaibhav hvaib...@ti.com
wrote:
On Wed, Mar 28, 2012 at 20:19:07, Shilimkar, Santosh wrote:
On Wed, Mar 28, 2012 at 8:07 PM, Hiremath, Vaibhav hvaib...@ti.com
wrote:
On Wed, Mar 28, 2012 at 19:50:02, Shilimkar, Santosh wrote:
On Wed, Mar 28, 2012 at 7:46 PM, Hiremath, Vaibhav hvaib...@ti.com
wrote:
On Wed, Mar 21, 2012 at 19:30:01, Shilimkar, Santosh wrote:
On Wed, Mar 21, 2012 at 5:12 PM, Hiremath, Vaibhav hvaib...@ti.com
wrote:
On Mon, Mar 19, 2012 at 17:45:32, Shilimkar, Santosh wrote:
On Monday 19 March 2012 05:14 PM, Ming Lei wrote:
On Mon, Mar 19, 2012 at 7:11 PM, Hiremath, Vaibhav
hvaib...@ti.com wrote:
[...]
I thought so and now if you look at last part of my comment.
Rating of 32K based synctimer and 32K based GPTIMER
should be same because of the precision. That's the main
point why I was saying that GPTIMER is not a better
clock-source( with 32k clock src) than sync timer when
both are enabled together.
Santosh,
In case of OMAP, we are using timer 2 for clocksource
OMAP_SYS_TIMER_INIT(2, 1, OMAP2_CLKEV_SOURCE, 2, OMAP2_MPU_SOURCE)
OMAP_SYS_TIMER_INIT(3, 1, OMAP3_CLKEV_SOURCE, 2, OMAP3_MPU_SOURCE)
And timer2 as clocksource is never used, since we have
CONFIG_OMAP_32K_TIMER
defined in our defconfig.
Also, after looking at the code, I came across another problem,
setup_sched_clock(). But this can be easily fixed, if we source both the
timers with same clock (here 32k_fck).
Let me propose this,
How about, if I keep timer2 source always set to 32k_fclk for omap2,3,4?
And also, as mentioned by Santosh, I will register both the clocks as
clocksource with the same rating.
By default, kernel is going to use 32k_counter as a clocksource, and
through
Command prompt user can override it without any issues.
Just to make sure that, whatever I am trying to propse here works and
don't get into unknown issue; I changed my code for this, and it is
working for me without any issues.
Let's not make this more complicated. I guess below simple patch should
sort
out the issue. I briefly tested it on OMAP4 and it works. let me know
if it helps AMxxx machines.
Regards
Santosh
From 0a9283e26174d76ff2753ac88521b61a26b24e8f Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Fri, 30 Mar 2012 12:43:29 +0530
Subject: [PATCH] ARM: OMAP: Make OMAP clocksource source selection runtime.
Current OMAP code support couple of clocksource options based on
compilation
flag. The 32KHz based sync timer and a gptimer based clock source which can
run on 32KHz or system clock (e.g 38.4 MHz). So there can be 3 options.
1. 32KHz synctimer
2. Sysclock based(e.g 38.4 MHz) gptimer
3. 32KHz based gptimer.
The optional gptimer based clocksource was added so that it can give the
high precision than synctimer so expected usage was 2 and not 3.
Unfortunatlly
option 2, clocksource doesn't meet the requirement of free-running clock
as per clocksource need. It stops in low power states when sysclock is
cut.
That makes gptimer based clocksource option useless for OMAP2/3/4 devices
with sysclock as a clock input. Option 3 will still work but it is no
better'
than 32K synctimer based clocksource.
So ideally we can kill the gptimer based clocksource option but there are
some
OMAP based derivative SoCs like AM which doesn't have synictimer
hardware IP
and need to fallback on 32KHz based gptimer clocksource.
Considering above, make synctimer and gptimer clocksource runtime
selectable so that both OMAP and AM continue to use the same code.
Not-yet-signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/timer.c | 25 -
1 files changed, 8 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index c512bac..3878e59 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -234,21 +234,6 @@ static void __init omap2_gp_clockevent_init(int
gptimer_id,
}
/* Clocksource code */
-
-#ifdef CONFIG_OMAP_32K_TIMER
-/*
- * When 32k-timer is enabled, don't use GPTimer for clocksource
- * instead, just leave default clocksource which uses the 32k
- * sync counter. See clocksource setup in plat-omap/counter_32k.c
- */
-
-static void __init omap2_gp_clocksource_init(int unused, const char
*dummy)
-{
- omap_init_clocksource_32k();
-}
-
-#else
-
static struct omap_dm_timer clksrc;
/*
@@ -276,7 +261,7 @@ static u32 notrace dmtimer_read_sched_clock(void)
}
/* Setup free-running counter for clocksource */
Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Fri, Mar 30, 2012 at 2:42 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Fri, Mar 30, 2012 at 14:08:20, Shilimkar, Santosh wrote: On Friday 30 March 2012 02:02 PM, Hiremath, Vaibhav wrote: On Fri, Mar 30, 2012 at 13:11:35, Shilimkar, Santosh wrote: [] With this patch, will you be able to choose gptimer as a clocksource using bootparameter (or sysfs) for given kernel uImage? Why do you want that ? Look at changelog. The gptimer based clocksource is useless for OMAP and for AM devices synctimer is not available. The answer is simply NO...as the registration of gptimer is based on failure from omap_init_clocksource_32k(). And this is nothing different than my original patch, my patch exactly does same thing. I ight have missed your original patch. If that patch is similar then no problems. The requirement after 'ming Lie' response on my patch was, there will be usecases where we might need to use gptimer for clocksource and with the patch it is not possible, since you will only register 32k_counter here. I think Ming Lie might have expected that gptimer clocksource might be better which is not the case. So in order to allow user to choose between 32K and gptimer, you must register both and make 32k as a default thing. As described in the commit log, its not needed at all. Let's not add a feature which is just useless because the gptimer based clock source has no advantage against the syntimer. I completely agree with you, and that is my understanding too. Thanks !! After Ming Lie's comment, the point that I came to my mind was, certainly there will be resolution difference between these two clocksources, if gptimer2 is sourced from sys_ck (26Mhz). GPTIMER2 with sysclock is not an option. GPTIMER is not in wakeup domain and when sysclock is cut, it stops. I am quite not sure, whether will there be any practical usecase where you change the kernel clocksource for high resolution dynamically through sysfs or something. May be notbut still it is possible. Even if there is a usecase, there no option with full PM. In that case my original patch still holds good here. I would still request you to review the same and give your acked-by or tested-by. I just looked at that. It looks fine to me. Can you repost that patch addressing Kevin and Tony's comments. Also update the change log as describe in the patch i posted. Once that done, will ack 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: Suspend broken on 3.3?
...[snip]... Could you please try attached patch and let me know if this solves the rx issue as well, without using dma mode. Right, I think we've getting closer, but still not quite there... Firstly, the patch adds an include to iomap.h - but this doesn't exist in stock 3.3. Simply removing this include seemed to allow the compile to complete successfully. With this patch applied (and not in DMA mode) I now get the following: - If I leave wake-from-suspend enabled for the serial port then it works correctly (i.e. no lost/extra 0x00 characters). - If I disable wake-from-suspend for the serial port and go through a suspend cycle (i.e. suspend and then wake), then the serial port starts to misbehave as before. - If I then re-enable wake-from-suspend and go through a suspend cycle it starts to work correctly again. So the problem is still that if wake-from-suspend is disabled for a serial port, and a suspend cycle is performed then when woken the serial port will not function correctly if operating in interrupt-mode. Cheers, Joe -- Thanks, Govindraj.R -- To unsubscribe from this list: send the line unsubscribe 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/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Fri, Mar 30, 2012 at 14:50:02, Shilimkar, Santosh wrote: On Fri, Mar 30, 2012 at 2:42 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Fri, Mar 30, 2012 at 14:08:20, Shilimkar, Santosh wrote: On Friday 30 March 2012 02:02 PM, Hiremath, Vaibhav wrote: On Fri, Mar 30, 2012 at 13:11:35, Shilimkar, Santosh wrote: [] With this patch, will you be able to choose gptimer as a clocksource using bootparameter (or sysfs) for given kernel uImage? Why do you want that ? Look at changelog. The gptimer based clocksource is useless for OMAP and for AM devices synctimer is not available. The answer is simply NO...as the registration of gptimer is based on failure from omap_init_clocksource_32k(). And this is nothing different than my original patch, my patch exactly does same thing. I ight have missed your original patch. If that patch is similar then no problems. The requirement after 'ming Lie' response on my patch was, there will be usecases where we might need to use gptimer for clocksource and with the patch it is not possible, since you will only register 32k_counter here. I think Ming Lie might have expected that gptimer clocksource might be better which is not the case. So in order to allow user to choose between 32K and gptimer, you must register both and make 32k as a default thing. As described in the commit log, its not needed at all. Let's not add a feature which is just useless because the gptimer based clock source has no advantage against the syntimer. I completely agree with you, and that is my understanding too. Thanks !! After Ming Lie's comment, the point that I came to my mind was, certainly there will be resolution difference between these two clocksources, if gptimer2 is sourced from sys_ck (26Mhz). GPTIMER2 with sysclock is not an option. GPTIMER is not in wakeup domain and when sysclock is cut, it stops. I am quite not sure, whether will there be any practical usecase where you change the kernel clocksource for high resolution dynamically through sysfs or something. May be notbut still it is possible. Even if there is a usecase, there no option with full PM. What if before suspending the system, you switch back to 32k_counter everytime, and in resume you again switch to gp_timer? Please consider this as just a technical discussion, as I am myself quite not sure whether we have such use-case available. In that case my original patch still holds good here. I would still request you to review the same and give your acked-by or tested-by. I just looked at that. It looks fine to me. Can you repost that patch addressing Kevin and Tony's comments. Also update the change log as describe in the patch i posted. Once that done, will ack it. Thanks for the review and discussion, I will submit revised version shortly. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Fri, Mar 30, 2012 at 2:58 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Fri, Mar 30, 2012 at 14:50:02, Shilimkar, Santosh wrote: On Fri, Mar 30, 2012 at 2:42 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Fri, Mar 30, 2012 at 14:08:20, Shilimkar, Santosh wrote: On Friday 30 March 2012 02:02 PM, Hiremath, Vaibhav wrote: On Fri, Mar 30, 2012 at 13:11:35, Shilimkar, Santosh wrote: [] With this patch, will you be able to choose gptimer as a clocksource using bootparameter (or sysfs) for given kernel uImage? Why do you want that ? Look at changelog. The gptimer based clocksource is useless for OMAP and for AM devices synctimer is not available. The answer is simply NO...as the registration of gptimer is based on failure from omap_init_clocksource_32k(). And this is nothing different than my original patch, my patch exactly does same thing. I ight have missed your original patch. If that patch is similar then no problems. The requirement after 'ming Lie' response on my patch was, there will be usecases where we might need to use gptimer for clocksource and with the patch it is not possible, since you will only register 32k_counter here. I think Ming Lie might have expected that gptimer clocksource might be better which is not the case. So in order to allow user to choose between 32K and gptimer, you must register both and make 32k as a default thing. As described in the commit log, its not needed at all. Let's not add a feature which is just useless because the gptimer based clock source has no advantage against the syntimer. I completely agree with you, and that is my understanding too. Thanks !! After Ming Lie's comment, the point that I came to my mind was, certainly there will be resolution difference between these two clocksources, if gptimer2 is sourced from sys_ck (26Mhz). GPTIMER2 with sysclock is not an option. GPTIMER is not in wakeup domain and when sysclock is cut, it stops. I am quite not sure, whether will there be any practical usecase where you change the kernel clocksource for high resolution dynamically through sysfs or something. May be notbut still it is possible. Even if there is a usecase, there no option with full PM. What if before suspending the system, you switch back to 32k_counter everytime, and in resume you again switch to gp_timer? This has been discussed at length. Dynamic switching between clock-sources affects the NTP time corrections. Go through [1] when you have time, since its a long thread. If and when that feature works, we can update the clocksource code. Regards Santosh [1] https://lkml.org/lkml/2011/6/2/167 -- To unsubscribe from this list: send the line unsubscribe 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: AM3517evm
Am 29.03.2012 16:59, schrieb Yegor Yefremov: Am 15.03.2012 17:52, schrieb Mark A. Greer: On Thu, Mar 15, 2012 at 09:42:21AM -0700, Mark A. Greer wrote: On Thu, Mar 15, 2012 at 04:52:40PM +0100, Yegor Yefremov wrote: Am 15.03.2012 16:43, schrieb Mark A. Greer: On Mon, Mar 12, 2012 at 02:55:02PM +0100, Yegor Yefremov wrote: Am 09.03.2012 18:22, schrieb George C. Huntington, III: I would like to make the newer kernel (3.x) work with the AM3517EVM. I have a 2.6.32 and a 2.6.33 that run well on the board, but the recent kernels have kernel panics before even running init. where should I start? is there a better place to pursue this? Have you tried this one? http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=summary I have this one booting one month ago, but I checked out the kernel today and it hangs somewhere: Starting kernel ... Uncompressing Linux... done, booting the kernel. This looks like you have your console device set to ttyS2 instead of ttyO2. Which branch of that repository did you use? My kernel params: CONFIG_CMDLINE=root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 and I force them, so bootloader has nothing to say. I'm using master branch. I just booted the latest master branch (b8fe178) with the hack below. (Kernel command line: console=ttyO2,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait) I meant to add that I booted an am3517evm. Is frame buffer working? I can boot with the latest linux-omap version, but as soon as I enable omapfb, kernel freezes before making any output to the serial console. Have I missed some DSS/DPI patches? After some research I found out that only the master branch is broken. At least rc7 is O.K.: git checkout v3.3-rc7 master freezes: git checkout origin/master According to commit log (http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commitdiff;h=b8fe1781ec8bed5e086691a827a6ee11facec2aa), there is nothing suspicious. How can I see the real difference between v3.3-rc7 and master branch? Is this command sufficient? git diff v3.3-rc7..origin/master Yegor -- To unsubscribe from this list: send the line unsubscribe 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 03/17] ARM: mark const init data with __initconst instead of __initdata
Hello Shawn,
On Fri, Mar 30, 2012 at 02:11:36PM +0800, Shawn Guo wrote:
On Thu, Mar 29, 2012 at 11:12:20PM +0200, Uwe Kleine-König wrote:
...
diff --git a/arch/arm/mach-imx/imx51-dt.c b/arch/arm/mach-imx/imx51-dt.c
index 5cca573..7e00748 100644
--- a/arch/arm/mach-imx/imx51-dt.c
+++ b/arch/arm/mach-imx/imx51-dt.c
@@ -102,7 +102,7 @@ static struct sys_timer imx51_timer = {
.init = imx51_timer_init,
};
-static const char *imx51_dt_board_compat[] __initdata = {
+static const char *imx51_dt_board_compat[] __initconst = {
fsl,imx51-babbage,
fsl,imx51,
NULL
CC arch/arm/mach-imx/imx51-dt.o
arch/arm/mach-imx/imx51-dt.c:105:20: error: imx51_dt_board_compat causes a
section type conflict
make[2]: *** [arch/arm/mach-imx/imx51-dt.o] Error 1
I do not understand why though.
that's because the strings are constant, but the array is not. The fix
is:
-static const char *imx51_dt_board_compat[] __initconst = {
+static const char *const imx51_dt_board_compat[] __initconst = {
or keeping __initdata.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line unsubscribe 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 errata i740
On 3/30/2012 10:26 AM, Tomi Valkeinen wrote: On Fri, 2012-03-30 at 13:51 +0530, Shilimkar, Santosh wrote: On Fri, Mar 30, 2012 at 1:37 PM, Tomi Valkeinentomi.valkei...@ti.com wrote: All OMAP4 versions seem to be affected. I couldn't find a mention about this in the mainline kernel. Any ideas how and where this should be fixed? It's not patched for mainline. Generally clock-domain code is abstracted from drivers but considering the errata and affected modules, I guees it should be handled by DSS driver since that is where the state of DSS or ISS will be known. Note ISS will be automatically taken care since it will always use disaplay. In internal tree's this was handled as part of DSS early suspend/resume That version doesn't work as it uses functions that are not exported to drivers. I don't know much about the clock domain code, but I hope there's a way to handle it there. Otherwise I guess I need to add a new set of platform callback functions, so that the dss driver can call arch/arm/mach-omap2 code to enable and disable the work-around. I dislike that because I'm currently trying to remove those kinds of hacks to make dss work better with DT =). I think we should just find another workaround :-) There is not way we can let the drivers play directly with the clock domain idle mode. And in theory hacking the local sysconfig should have the same effect. So we should check for a better workaround with HW designers on that one. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suspend broken on 3.3?
On Fri, Mar 30, 2012 at 2:56 PM, Joe Woodward j...@terrafix.co.uk wrote: ...[snip]... Could you please try attached patch and let me know if this solves the rx issue as well, without using dma mode. Right, I think we've getting closer, but still not quite there... Firstly, the patch adds an include to iomap.h - but this doesn't exist in stock 3.3. Simply removing this include seemed to allow the compile to complete successfully. Sorry I forgot to specify this is needed for latest mainline. With this patch applied (and not in DMA mode) I now get the following: - If I leave wake-from-suspend enabled for the serial port then it works correctly (i.e. no lost/extra 0x00 characters). - If I disable wake-from-suspend for the serial port and go through a suspend cycle (i.e. suspend and then wake), then the serial port starts to misbehave as before. - If I then re-enable wake-from-suspend and go through a suspend cycle it starts to work correctly again. So the problem is still that if wake-from-suspend is disabled for a serial port, and a suspend cycle is performed then when woken the serial port will not function correctly if operating in interrupt-mode. I tried it on my 3430sdp but strangely I don't see a 0x00 char read after disabling uart wakeups and waking up by keypad press. Probably as a quick try we can try doing uart_insert_char only if data was read from rx fifo (Attached patch) -- Thanks, Govindraj.R rx_fifo_check.patch Description: Binary data
[PATCHv3 0/6] spi: omap2-mcspi: driver updates
The patch series does the following cleanups - Converts the spi to module_platform_driver - Use the devm functions so that the freeing need not be done in the driver. - Makes the driver use autosuspend - Folds Benoit's bus_num removal patch in the series Changes from v1 - Makes the driver use autosuspend - Folds Benoit's bus_num removal patch in the series Changes from v2 - The tmp variable is used to write this can be optimised as it is not needed if the value is directly written. Acknowledge Tarun for the suggestion. This is also available through git : git://gitorious.org/linus-tree/linus-tree.git branch : spi This is targeted for v3.5. Benoit Cousson (1): spi/omap: Remove bus_num usage for instance index Felipe Balbi (2): spi: omap2-mcspi: make it behave as a module spi: omap2-mcspi: convert to module_platform_driver Shubhrajyoti D (3): spi: omap2-mcspi: use devm_* functions spi: omap2-mcspi: add support for pm_runtime autosuspend spi: omap2-mcspi: Trivial optimisation drivers/spi/spi-omap2-mcspi.c | 132 +++- 1 files changed, 50 insertions(+), 82 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 1/6] spi/omap: Remove bus_num usage for instance index
From: Benoit Cousson b-cous...@ti.com
bus_num was used to reference the mcspi controller instance in a fixed array.
Remove this array and store this information directly inside drvdata structure.
bus_num is now just set if the pdev-id is present or with -1 for dynamic
allocation by SPI core, but the driver does not access it anymore.
Clean some bad comments format, and remove un-needed space.
Signed-off-by: Benoit Cousson b-cous...@ti.com
[Cleanup the OMAP2_MCSPI_MAX_CTRL macro as it is not needed anymore]
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/spi/spi-omap2-mcspi.c | 75 ++--
1 files changed, 34 insertions(+), 41 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index bb9274c..7785091 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -45,9 +45,6 @@
#define OMAP2_MCSPI_MAX_FREQ 4800
-/* OMAP2 has 3 SPI controllers, while OMAP3 has 4 */
-#define OMAP2_MCSPI_MAX_CTRL 4
-
#define OMAP2_MCSPI_REVISION 0x00
#define OMAP2_MCSPI_SYSSTATUS 0x14
#define OMAP2_MCSPI_IRQSTATUS 0x18
@@ -111,6 +108,16 @@ struct omap2_mcspi_dma {
#define DMA_MIN_BYTES 160
+/*
+ * Used for context save and restore, structure members to be updated whenever
+ * corresponding registers are modified.
+ */
+struct omap2_mcspi_regs {
+ u32 modulctrl;
+ u32 wakeupenable;
+ struct list_head cs;
+};
+
struct omap2_mcspi {
struct work_struct work;
/* lock protects queue and registers */
@@ -122,8 +129,9 @@ struct omap2_mcspi {
unsigned long phys;
/* SPI1 has 4 channels, while SPI2 has 2 */
struct omap2_mcspi_dma *dma_channels;
- struct device *dev;
+ struct device *dev;
struct workqueue_struct *wq;
+ struct omap2_mcspi_regs ctx;
};
struct omap2_mcspi_cs {
@@ -135,17 +143,6 @@ struct omap2_mcspi_cs {
u32 chconf0;
};
-/* used for context save and restore, structure members to be updated whenever
- * corresponding registers are modified.
- */
-struct omap2_mcspi_regs {
- u32 modulctrl;
- u32 wakeupenable;
- struct list_head cs;
-};
-
-static struct omap2_mcspi_regs omap2_mcspi_ctx[OMAP2_MCSPI_MAX_CTRL];
-
#define MOD_REG_BIT(val, mask, set) do { \
if (set) \
val |= mask; \
@@ -236,9 +233,12 @@ static void omap2_mcspi_force_cs(struct spi_device *spi,
int cs_active)
static void omap2_mcspi_set_master_mode(struct spi_master *master)
{
+ struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
+ struct omap2_mcspi_regs *ctx = mcspi-ctx;
u32 l;
- /* setup when switching from (reset default) slave mode
+ /*
+* Setup when switching from (reset default) slave mode
* to single-channel master mode
*/
l = mcspi_read_reg(master, OMAP2_MCSPI_MODULCTRL);
@@ -247,24 +247,20 @@ static void omap2_mcspi_set_master_mode(struct spi_master
*master)
MOD_REG_BIT(l, OMAP2_MCSPI_MODULCTRL_SINGLE, 1);
mcspi_write_reg(master, OMAP2_MCSPI_MODULCTRL, l);
- omap2_mcspi_ctx[master-bus_num - 1].modulctrl = l;
+ ctx-modulctrl = l;
}
static void omap2_mcspi_restore_ctx(struct omap2_mcspi *mcspi)
{
- struct spi_master *spi_cntrl;
- struct omap2_mcspi_cs *cs;
- spi_cntrl = mcspi-master;
+ struct spi_master *spi_cntrl = mcspi-master;
+ struct omap2_mcspi_regs *ctx = mcspi-ctx;
+ struct omap2_mcspi_cs *cs;
/* McSPI: context restore */
- mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_MODULCTRL,
- omap2_mcspi_ctx[spi_cntrl-bus_num - 1].modulctrl);
+ mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_MODULCTRL, ctx-modulctrl);
+ mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_WAKEUPENABLE, ctx-wakeupenable);
- mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_WAKEUPENABLE,
- omap2_mcspi_ctx[spi_cntrl-bus_num - 1].wakeupenable);
-
- list_for_each_entry(cs, omap2_mcspi_ctx[spi_cntrl-bus_num - 1].cs,
- node)
+ list_for_each_entry(cs, ctx-cs, node)
__raw_writel(cs-chconf0, cs-base + OMAP2_MCSPI_CHCONF0);
}
static void omap2_mcspi_disable_clocks(struct omap2_mcspi *mcspi)
@@ -777,7 +773,8 @@ static int omap2_mcspi_request_dma(struct spi_device *spi)
static int omap2_mcspi_setup(struct spi_device *spi)
{
int ret;
- struct omap2_mcspi *mcspi;
+ struct omap2_mcspi *mcspi = spi_master_get_devdata(spi-master);
+ struct omap2_mcspi_regs *ctx = mcspi-ctx;
struct omap2_mcspi_dma *mcspi_dma;
struct omap2_mcspi_cs *cs = spi-controller_state;
@@ -787,7 +784,6 @@ static int omap2_mcspi_setup(struct spi_device *spi)
return -EINVAL;
}
-
[PATCHv3 4/6] spi: omap2-mcspi: use devm_* functions
The various devm_* functions allocate memory that is released when a driver
detaches. This patch uses devm_request_and_ioremap
to request memory in probe function. Since the freeing is not
needed the calls are deleted from remove function.Also use
use devm_kzalloc for the cs memory allocation.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/spi/spi-omap2-mcspi.c | 24
1 files changed, 4 insertions(+), 20 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 66cbf22..1907ed2 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -787,7 +787,7 @@ static int omap2_mcspi_setup(struct spi_device *spi)
mcspi_dma = mcspi-dma_channels[spi-chip_select];
if (!cs) {
- cs = kzalloc(sizeof *cs, GFP_KERNEL);
+ cs = devm_kzalloc(spi-dev , sizeof *cs, GFP_KERNEL);
if (!cs)
return -ENOMEM;
cs-base = mcspi-base + spi-chip_select * 0x14;
@@ -828,7 +828,6 @@ static void omap2_mcspi_cleanup(struct spi_device *spi)
cs = spi-controller_state;
list_del(cs-node);
- kfree(spi-controller_state);
}
if (spi-chip_select spi-master-num_chipselect) {
@@ -1160,17 +1159,12 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
r-start += regs_offset;
r-end += regs_offset;
mcspi-phys = r-start;
- if (!request_mem_region(r-start, resource_size(r),
- dev_name(pdev-dev))) {
- status = -EBUSY;
- goto free_master;
- }
- mcspi-base = ioremap(r-start, resource_size(r));
+ mcspi-base = devm_request_and_ioremap(pdev-dev, r);
if (!mcspi-base) {
dev_dbg(pdev-dev, can't ioremap MCSPI\n);
status = -ENOMEM;
- goto release_region;
+ goto free_master;
}
mcspi-dev = pdev-dev;
@@ -1185,7 +1179,7 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
GFP_KERNEL);
if (mcspi-dma_channels == NULL)
- goto unmap_io;
+ goto free_master;
for (i = 0; i master-num_chipselect; i++) {
char dma_ch_name[14];
@@ -1235,10 +1229,6 @@ disable_pm:
pm_runtime_disable(pdev-dev);
dma_chnl_free:
kfree(mcspi-dma_channels);
-unmap_io:
- iounmap(mcspi-base);
-release_region:
- release_mem_region(r-start, resource_size(r));
free_master:
kfree(master);
platform_set_drvdata(pdev, NULL);
@@ -1250,8 +1240,6 @@ static int __devexit omap2_mcspi_remove(struct
platform_device *pdev)
struct spi_master *master;
struct omap2_mcspi *mcspi;
struct omap2_mcspi_dma *dma_channels;
- struct resource *r;
- void __iomem *base;
master = dev_get_drvdata(pdev-dev);
mcspi = spi_master_get_devdata(master);
@@ -1259,12 +1247,8 @@ static int __devexit omap2_mcspi_remove(struct
platform_device *pdev)
omap2_mcspi_disable_clocks(mcspi);
pm_runtime_disable(pdev-dev);
- r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(r-start, resource_size(r));
- base = mcspi-base;
spi_unregister_master(master);
- iounmap(base);
kfree(dma_channels);
destroy_workqueue(mcspi-wq);
platform_set_drvdata(pdev, NULL);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 3/6] spi: omap2-mcspi: convert to module_platform_driver
From: Felipe Balbi ba...@ti.com
this will delete a few lines of code, no functional
changes.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/spi/spi-omap2-mcspi.c | 15 +--
1 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 26dd79f..66cbf22 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -1324,18 +1324,5 @@ static struct platform_driver omap2_mcspi_driver = {
.remove = __devexit_p(omap2_mcspi_remove),
};
-
-static int __init omap2_mcspi_init(void)
-{
- return platform_driver_register(omap2_mcspi_driver);
-}
-subsys_initcall(omap2_mcspi_init);
-
-static void __exit omap2_mcspi_exit(void)
-{
- platform_driver_unregister(omap2_mcspi_driver);
-
-}
-module_exit(omap2_mcspi_exit);
-
+module_platform_driver(omap2_mcspi_driver);
MODULE_LICENSE(GPL);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 6/6] spi: omap2-mcspi: Trivial optimisation
Trivial optimisation of tmp variable by directly writing the value
to the register.
Cc : Tarun Kanti DebBarma tarun.ka...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/spi/spi-omap2-mcspi.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 0b0da2f..f374eee 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -1050,16 +1050,15 @@ static int __init omap2_mcspi_master_setup(struct
omap2_mcspi *mcspi)
{
struct spi_master *master = mcspi-master;
struct omap2_mcspi_regs *ctx = mcspi-ctx;
- u32 tmp;
int ret = 0;
ret = omap2_mcspi_enable_clocks(mcspi);
if (ret 0)
return ret;
- tmp = OMAP2_MCSPI_WAKEUPENABLE_WKEN;
- mcspi_write_reg(master, OMAP2_MCSPI_WAKEUPENABLE, tmp);
- ctx-wakeupenable = tmp;
+ mcspi_write_reg(master, OMAP2_MCSPI_WAKEUPENABLE,
+ OMAP2_MCSPI_WAKEUPENABLE_WKEN);
+ ctx-wakeupenable = OMAP2_MCSPI_WAKEUPENABLE_WKEN;
omap2_mcspi_set_master_mode(master);
omap2_mcspi_disable_clocks(mcspi);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 2/6] spi: omap2-mcspi: make it behave as a module
From: Felipe Balbi ba...@ti.com
move probe away from __init section and use
platform_driver_register() instead of
platform_driver_probe().
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/spi/spi-omap2-mcspi.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 7785091..26dd79f 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -1098,7 +1098,7 @@ static const struct of_device_id omap_mcspi_of_match[] = {
};
MODULE_DEVICE_TABLE(of, omap_mcspi_of_match);
-static int __init omap2_mcspi_probe(struct platform_device *pdev)
+static int __devinit omap2_mcspi_probe(struct platform_device *pdev)
{
struct spi_master *master;
struct omap2_mcspi_platform_config *pdata;
@@ -1245,7 +1245,7 @@ free_master:
return status;
}
-static int __exit omap2_mcspi_remove(struct platform_device *pdev)
+static int __devexit omap2_mcspi_remove(struct platform_device *pdev)
{
struct spi_master *master;
struct omap2_mcspi *mcspi;
@@ -1320,13 +1320,14 @@ static struct platform_driver omap2_mcspi_driver = {
.pm = omap2_mcspi_pm_ops,
.of_match_table = omap_mcspi_of_match,
},
- .remove = __exit_p(omap2_mcspi_remove),
+ .probe =omap2_mcspi_probe,
+ .remove = __devexit_p(omap2_mcspi_remove),
};
static int __init omap2_mcspi_init(void)
{
- return platform_driver_probe(omap2_mcspi_driver, omap2_mcspi_probe);
+ return platform_driver_register(omap2_mcspi_driver);
}
subsys_initcall(omap2_mcspi_init);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 5/6] spi: omap2-mcspi: add support for pm_runtime autosuspend
Adds support for configuring the omap2-mcspi driver use autosuspend for
runtime power management. This can reduce the latency in starting an
spi transfer by not suspending the device immediately following
completion of a transfer. If another transfer then takes place before
the autosuspend timeout (2 secs), the call to resume the device can
return immediately saving some save/ restore cycles.
Acked-by: Govindraj.R govindraj.r...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/spi/spi-omap2-mcspi.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 1907ed2..0b0da2f 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -44,6 +44,7 @@
#include plat/mcspi.h
#define OMAP2_MCSPI_MAX_FREQ 4800
+#define SPI_AUTOSUSPEND_TIMEOUT2000
#define OMAP2_MCSPI_REVISION 0x00
#define OMAP2_MCSPI_SYSSTATUS 0x14
@@ -265,7 +266,8 @@ static void omap2_mcspi_restore_ctx(struct omap2_mcspi
*mcspi)
}
static void omap2_mcspi_disable_clocks(struct omap2_mcspi *mcspi)
{
- pm_runtime_put_sync(mcspi-dev);
+ pm_runtime_mark_last_busy(mcspi-dev);
+ pm_runtime_put_autosuspend(mcspi-dev);
}
static int omap2_mcspi_enable_clocks(struct omap2_mcspi *mcspi)
@@ -1212,6 +1214,8 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
if (status 0)
goto dma_chnl_free;
+ pm_runtime_use_autosuspend(pdev-dev);
+ pm_runtime_set_autosuspend_delay(pdev-dev, SPI_AUTOSUSPEND_TIMEOUT);
pm_runtime_enable(pdev-dev);
if (status || omap2_mcspi_master_setup(mcspi) 0)
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 1/6] spi/omap: Remove bus_num usage for instance index
From: Benoit Cousson b-cous...@ti.com
bus_num was used to reference the mcspi controller instance in a fixed array.
Remove this array and store this information directly inside drvdata structure.
bus_num is now just set if the pdev-id is present or with -1 for dynamic
allocation by SPI core, but the driver does not access it anymore.
Clean some bad comments format, and remove un-needed space.
Signed-off-by: Benoit Cousson b-cous...@ti.com
[Cleanup the OMAP2_MCSPI_MAX_CTRL macro as it is not needed anymore]
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/spi/spi-omap2-mcspi.c | 75 ++--
1 files changed, 34 insertions(+), 41 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index bb9274c..7785091 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -45,9 +45,6 @@
#define OMAP2_MCSPI_MAX_FREQ 4800
-/* OMAP2 has 3 SPI controllers, while OMAP3 has 4 */
-#define OMAP2_MCSPI_MAX_CTRL 4
-
#define OMAP2_MCSPI_REVISION 0x00
#define OMAP2_MCSPI_SYSSTATUS 0x14
#define OMAP2_MCSPI_IRQSTATUS 0x18
@@ -111,6 +108,16 @@ struct omap2_mcspi_dma {
#define DMA_MIN_BYTES 160
+/*
+ * Used for context save and restore, structure members to be updated whenever
+ * corresponding registers are modified.
+ */
+struct omap2_mcspi_regs {
+ u32 modulctrl;
+ u32 wakeupenable;
+ struct list_head cs;
+};
+
struct omap2_mcspi {
struct work_struct work;
/* lock protects queue and registers */
@@ -122,8 +129,9 @@ struct omap2_mcspi {
unsigned long phys;
/* SPI1 has 4 channels, while SPI2 has 2 */
struct omap2_mcspi_dma *dma_channels;
- struct device *dev;
+ struct device *dev;
struct workqueue_struct *wq;
+ struct omap2_mcspi_regs ctx;
};
struct omap2_mcspi_cs {
@@ -135,17 +143,6 @@ struct omap2_mcspi_cs {
u32 chconf0;
};
-/* used for context save and restore, structure members to be updated whenever
- * corresponding registers are modified.
- */
-struct omap2_mcspi_regs {
- u32 modulctrl;
- u32 wakeupenable;
- struct list_head cs;
-};
-
-static struct omap2_mcspi_regs omap2_mcspi_ctx[OMAP2_MCSPI_MAX_CTRL];
-
#define MOD_REG_BIT(val, mask, set) do { \
if (set) \
val |= mask; \
@@ -236,9 +233,12 @@ static void omap2_mcspi_force_cs(struct spi_device *spi,
int cs_active)
static void omap2_mcspi_set_master_mode(struct spi_master *master)
{
+ struct omap2_mcspi *mcspi = spi_master_get_devdata(master);
+ struct omap2_mcspi_regs *ctx = mcspi-ctx;
u32 l;
- /* setup when switching from (reset default) slave mode
+ /*
+* Setup when switching from (reset default) slave mode
* to single-channel master mode
*/
l = mcspi_read_reg(master, OMAP2_MCSPI_MODULCTRL);
@@ -247,24 +247,20 @@ static void omap2_mcspi_set_master_mode(struct spi_master
*master)
MOD_REG_BIT(l, OMAP2_MCSPI_MODULCTRL_SINGLE, 1);
mcspi_write_reg(master, OMAP2_MCSPI_MODULCTRL, l);
- omap2_mcspi_ctx[master-bus_num - 1].modulctrl = l;
+ ctx-modulctrl = l;
}
static void omap2_mcspi_restore_ctx(struct omap2_mcspi *mcspi)
{
- struct spi_master *spi_cntrl;
- struct omap2_mcspi_cs *cs;
- spi_cntrl = mcspi-master;
+ struct spi_master *spi_cntrl = mcspi-master;
+ struct omap2_mcspi_regs *ctx = mcspi-ctx;
+ struct omap2_mcspi_cs *cs;
/* McSPI: context restore */
- mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_MODULCTRL,
- omap2_mcspi_ctx[spi_cntrl-bus_num - 1].modulctrl);
+ mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_MODULCTRL, ctx-modulctrl);
+ mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_WAKEUPENABLE, ctx-wakeupenable);
- mcspi_write_reg(spi_cntrl, OMAP2_MCSPI_WAKEUPENABLE,
- omap2_mcspi_ctx[spi_cntrl-bus_num - 1].wakeupenable);
-
- list_for_each_entry(cs, omap2_mcspi_ctx[spi_cntrl-bus_num - 1].cs,
- node)
+ list_for_each_entry(cs, ctx-cs, node)
__raw_writel(cs-chconf0, cs-base + OMAP2_MCSPI_CHCONF0);
}
static void omap2_mcspi_disable_clocks(struct omap2_mcspi *mcspi)
@@ -777,7 +773,8 @@ static int omap2_mcspi_request_dma(struct spi_device *spi)
static int omap2_mcspi_setup(struct spi_device *spi)
{
int ret;
- struct omap2_mcspi *mcspi;
+ struct omap2_mcspi *mcspi = spi_master_get_devdata(spi-master);
+ struct omap2_mcspi_regs *ctx = mcspi-ctx;
struct omap2_mcspi_dma *mcspi_dma;
struct omap2_mcspi_cs *cs = spi-controller_state;
@@ -787,7 +784,6 @@ static int omap2_mcspi_setup(struct spi_device *spi)
return -EINVAL;
}
-
[PATCHv3 0/6] spi: omap2-mcspi: driver updates
The patch series does the following cleanups - Converts the spi to module_platform_driver - Use the devm functions so that the freeing need not be done in the driver. - Makes the driver use autosuspend - Folds Benoit's bus_num removal patch in the series Changes from v1 - Makes the driver use autosuspend - Folds Benoit's bus_num removal patch in the series Changes from v2 - The tmp variable is used to write this can be optimised as it is not needed if the value is directly written. Acknowledge Tarun for the suggestion. This is also available through git : git://gitorious.org/linus-tree/linus-tree.git branch : spi This is targeted for v3.5. Benoit Cousson (1): spi/omap: Remove bus_num usage for instance index Felipe Balbi (2): spi: omap2-mcspi: make it behave as a module spi: omap2-mcspi: convert to module_platform_driver Shubhrajyoti D (3): spi: omap2-mcspi: use devm_* functions spi: omap2-mcspi: add support for pm_runtime autosuspend spi: omap2-mcspi: Trivial optimisation drivers/spi/spi-omap2-mcspi.c | 132 +++- 1 files changed, 50 insertions(+), 82 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP4 errata i740
On 3/30/2012 10:44 AM, Santosh Shilimkar wrote: On Friday 30 March 2012 02:04 PM, Archit Taneja wrote: On Friday 30 March 2012 02:01 PM, Santosh Shilimkar wrote: + Kevin On Friday 30 March 2012 01:56 PM, Tomi Valkeinen wrote: On Fri, 2012-03-30 at 13:51 +0530, Shilimkar, Santosh wrote: On Fri, Mar 30, 2012 at 1:37 PM, Tomi Valkeinentomi.valkei...@ti.com wrote: All OMAP4 versions seem to be affected. I couldn't find a mention about this in the mainline kernel. Any ideas how and where this should be fixed? It's not patched for mainline. Generally clock-domain code is abstracted from drivers but considering the errata and affected modules, I guees it should be handled by DSS driver since that is where the state of DSS or ISS will be known. Note ISS will be automatically taken care since it will always use disaplay. In internal tree's this was handled as part of DSS early suspend/resume That version doesn't work as it uses functions that are not exported to drivers. I don't know much about the clock domain code, but I hope there's a way to handle it there. Otherwise I guess I need to add a new set of platform callback functions, so that the dss driver can call arch/arm/mach-omap2 code to enable and disable the work-around. I dislike that because I'm currently trying to remove those kinds of hacks to make dss work better with DT =). I agree. In fact I faced similar issue when I briefly tried moving OMAP cpuidle code to drivers/idle/*. That time me and Kevin concluded that till we move the powerdomain, clockdomain code to drivers/* and export it, the cpuidle movement needs to be deferred. How about preventing the issue to occur by keeping DSS and ISS in No-standby mode for the affected OMAP versions. The errata says: Such a situation can occur when the impacted initiator is generating short MStandby pulses (pulse durations less than one L4 clock cycle) Chaning the mstandby hwmod data for DSS and ISS would prevent the need for exporting these clock domain functions only for this errata. That will just break PM :-) Not at all. At least it will not be worst than the current WA. I think Archit is right, at least this is the exact same question I'm asking to the designers :-). With this change DSS will never assert standby and then PRCM can never send idle-req to modules. Indirectly no power transitions. This is exactly what will happen if you set the clock domain in NO_IDLE. So in any case, you cannot have autoidle during the Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP4 errata i740
On Friday 30 March 2012 03:53 PM, Cousson, Benoit wrote: On 3/30/2012 10:44 AM, Santosh Shilimkar wrote: On Friday 30 March 2012 02:04 PM, Archit Taneja wrote: On Friday 30 March 2012 02:01 PM, Santosh Shilimkar wrote: + Kevin On Friday 30 March 2012 01:56 PM, Tomi Valkeinen wrote: On Fri, 2012-03-30 at 13:51 +0530, Shilimkar, Santosh wrote: On Fri, Mar 30, 2012 at 1:37 PM, Tomi Valkeinentomi.valkei...@ti.com wrote: All OMAP4 versions seem to be affected. I couldn't find a mention about this in the mainline kernel. Any ideas how and where this should be fixed? It's not patched for mainline. Generally clock-domain code is abstracted from drivers but considering the errata and affected modules, I guees it should be handled by DSS driver since that is where the state of DSS or ISS will be known. Note ISS will be automatically taken care since it will always use disaplay. In internal tree's this was handled as part of DSS early suspend/resume That version doesn't work as it uses functions that are not exported to drivers. I don't know much about the clock domain code, but I hope there's a way to handle it there. Otherwise I guess I need to add a new set of platform callback functions, so that the dss driver can call arch/arm/mach-omap2 code to enable and disable the work-around. I dislike that because I'm currently trying to remove those kinds of hacks to make dss work better with DT =). I agree. In fact I faced similar issue when I briefly tried moving OMAP cpuidle code to drivers/idle/*. That time me and Kevin concluded that till we move the powerdomain, clockdomain code to drivers/* and export it, the cpuidle movement needs to be deferred. How about preventing the issue to occur by keeping DSS and ISS in No-standby mode for the affected OMAP versions. The errata says: Such a situation can occur when the impacted initiator is generating short MStandby pulses (pulse durations less than one L4 clock cycle) Chaning the mstandby hwmod data for DSS and ISS would prevent the need for exporting these clock domain functions only for this errata. That will just break PM :-) Not at all. At least it will not be worst than the current WA. I think Archit is right, at least this is the exact same question I'm asking to the designers :-). Am not sure what do you mean by here. What Archit said is statitically setting up DSS/ISS sysnconfig to no standby. It will definitely break PM. The WA was doing runtime this with clockdomain APIs. If you say manage the sysconfig runtime in driver, then it will work. With this change DSS will never assert standby and then PRCM can never send idle-req to modules. Indirectly no power transitions. This is exactly what will happen if you set the clock domain in NO_IDLE. So in any case, you cannot have autoidle during the Guess I was not clear. The idea was to put CD in no_idle when DSS active and allow idle when not active. Looks like you saying OK to hack sysconfig for which we have been pushing back on drivers not to do it. Ofcourse errata and various reset bugs have broken that rule anyways. 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: OMAP4 errata i740
On Friday 30 March 2012 03:59 PM, Santosh Shilimkar wrote: On Friday 30 March 2012 03:53 PM, Cousson, Benoit wrote: On 3/30/2012 10:44 AM, Santosh Shilimkar wrote: On Friday 30 March 2012 02:04 PM, Archit Taneja wrote: On Friday 30 March 2012 02:01 PM, Santosh Shilimkar wrote: + Kevin On Friday 30 March 2012 01:56 PM, Tomi Valkeinen wrote: On Fri, 2012-03-30 at 13:51 +0530, Shilimkar, Santosh wrote: On Fri, Mar 30, 2012 at 1:37 PM, Tomi Valkeinentomi.valkei...@ti.comwrote: All OMAP4 versions seem to be affected. I couldn't find a mention about this in the mainline kernel. Any ideas how and where this should be fixed? It's not patched for mainline. Generally clock-domain code is abstracted from drivers but considering the errata and affected modules, I guees it should be handled by DSS driver since that is where the state of DSS or ISS will be known. Note ISS will be automatically taken care since it will always use disaplay. In internal tree's this was handled as part of DSS early suspend/resume That version doesn't work as it uses functions that are not exported to drivers. I don't know much about the clock domain code, but I hope there's a way to handle it there. Otherwise I guess I need to add a new set of platform callback functions, so that the dss driver can call arch/arm/mach-omap2 code to enable and disable the work-around. I dislike that because I'm currently trying to remove those kinds of hacks to make dss work better with DT =). I agree. In fact I faced similar issue when I briefly tried moving OMAP cpuidle code to drivers/idle/*. That time me and Kevin concluded that till we move the powerdomain, clockdomain code to drivers/* and export it, the cpuidle movement needs to be deferred. How about preventing the issue to occur by keeping DSS and ISS in No-standby mode for the affected OMAP versions. The errata says: Such a situation can occur when the impacted initiator is generating short MStandby pulses (pulse durations less than one L4 clock cycle) Chaning the mstandby hwmod data for DSS and ISS would prevent the need for exporting these clock domain functions only for this errata. That will just break PM :-) Not at all. At least it will not be worst than the current WA. I think Archit is right, at least this is the exact same question I'm asking to the designers :-). Am not sure what do you mean by here. What Archit said is statitically setting up DSS/ISS sysnconfig to no standby. It will definitely break PM. The WA was doing runtime this with clockdomain APIs. If you say manage the sysconfig runtime in driver, then it will work. I had a general PRCM question regarding this. If an initiator is disabled (i.e, clocks are OFF and Power state is OFF), then would the PRCM even care to look at the IdleAck/Mstandby signal of that initiator? Or in other words, look at what the initiator had programmed in it's SYSCONFIG register. If it does consider them, it seems like that's bad HW design! Archit With this change DSS will never assert standby and then PRCM can never send idle-req to modules. Indirectly no power transitions. This is exactly what will happen if you set the clock domain in NO_IDLE. So in any case, you cannot have autoidle during the Guess I was not clear. The idea was to put CD in no_idle when DSS active and allow idle when not active. Looks like you saying OK to hack sysconfig for which we have been pushing back on drivers not to do it. Ofcourse errata and various reset bugs have broken that rule anyways. 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: OMAP4 errata i740
On Fri, Mar 30, 2012 at 4:26 PM, Archit Taneja a0393...@ti.com wrote: On Friday 30 March 2012 03:59 PM, Santosh Shilimkar wrote: On Friday 30 March 2012 03:53 PM, Cousson, Benoit wrote: On 3/30/2012 10:44 AM, Santosh Shilimkar wrote: On Friday 30 March 2012 02:04 PM, Archit Taneja wrote: On Friday 30 March 2012 02:01 PM, Santosh Shilimkar wrote: + Kevin On Friday 30 March 2012 01:56 PM, Tomi Valkeinen wrote: On Fri, 2012-03-30 at 13:51 +0530, Shilimkar, Santosh wrote: On Fri, Mar 30, 2012 at 1:37 PM, Tomi Valkeinentomi.valkei...@ti.com wrote: [...] I had a general PRCM question regarding this. If an initiator is disabled (i.e, clocks are OFF and Power state is OFF), then would the PRCM even care to look at the IdleAck/Mstandby signal of that initiator? Or in other words, look at what the initiator had programmed in it's SYSCONFIG register. If it does consider them, it seems like that's bad HW design! If a PD 9powerdomain) is already in OFF state, that means all the initiators in that PD already has standby asserted. The modules in that PD also have transitioned. So PRCM won't poke that PD initiators/modules because it has already have a green signal for power transitions. At least that is what my understanding from the OMAP PRCM specs. 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: Suspend broken on 3.3?
-Original Message- From: Raja, Govindraj govindraj.r...@ti.com To: Joe Woodward j...@terrafix.co.uk Cc: Paul Walmsley p...@pwsan.com, Kevin Hilman khil...@ti.com, linux-omap@vger.kernel.org, Felipe Balbi ba...@ti.com, ne...@suse.de Date: Fri, 30 Mar 2012 15:45:19 +0530 Subject: Re: Suspend broken on 3.3? On Fri, Mar 30, 2012 at 2:56 PM, Joe Woodward j...@terrafix.co.uk wrote: ...[snip]... Could you please try attached patch and let me know if this solves the rx issue as well, without using dma mode. Right, I think we've getting closer, but still not quite there... Firstly, the patch adds an include to iomap.h - but this doesn't exist in stock 3.3. Simply removing this include seemed to allow the compile to complete successfully. Sorry I forgot to specify this is needed for latest mainline. With this patch applied (and not in DMA mode) I now get the following: - If I leave wake-from-suspend enabled for the serial port then it works correctly (i.e. no lost/extra 0x00 characters). - If I disable wake-from-suspend for the serial port and go through a suspend cycle (i.e. suspend and then wake), then the serial port starts to misbehave as before. - If I then re-enable wake-from-suspend and go through a suspend cycle it starts to work correctly again. So the problem is still that if wake-from-suspend is disabled for a serial port, and a suspend cycle is performed then when woken the serial port will not function correctly if operating in interrupt-mode. I tried it on my 3430sdp but strangely I don't see a 0x00 char read after disabling uart wakeups and waking up by keypad press. Probably as a quick try we can try doing uart_insert_char only if data was read from rx fifo (Attached patch) Sadly the patch makes no difference. I'm suprised you aren't seeing similar effects. I've done more testing, and a simplified test case is as follows: - take a stock 3.3 kernel and apply your patch to allow disabling of wake-from-suspend for the serial ports. - disable wake-from-suspend for the console tty: echo disable /sys/devices/platform/omap/omap_uart.2/power/wakeup - perform a suspend (you'll need a button or something to wake you now that the console wont). echo mem /sys/power/state At this point the console is noticable/painfully slow. No characters are lost, but it's obvious something isn't right! Cheers, Joe -- Thanks, Govindraj.R -- To unsubscribe from this list: send the line unsubscribe 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 errata i740
On Friday 30 March 2012 04:34 PM, Shilimkar, Santosh wrote: On Fri, Mar 30, 2012 at 4:26 PM, Archit Tanejaa0393...@ti.com wrote: On Friday 30 March 2012 03:59 PM, Santosh Shilimkar wrote: On Friday 30 March 2012 03:53 PM, Cousson, Benoit wrote: On 3/30/2012 10:44 AM, Santosh Shilimkar wrote: On Friday 30 March 2012 02:04 PM, Archit Taneja wrote: On Friday 30 March 2012 02:01 PM, Santosh Shilimkar wrote: + Kevin On Friday 30 March 2012 01:56 PM, Tomi Valkeinen wrote: On Fri, 2012-03-30 at 13:51 +0530, Shilimkar, Santosh wrote: On Fri, Mar 30, 2012 at 1:37 PM, Tomi Valkeinentomi.valkei...@ti.com wrote: [...] I had a general PRCM question regarding this. If an initiator is disabled (i.e, clocks are OFF and Power state is OFF), then would the PRCM even care to look at the IdleAck/Mstandby signal of that initiator? Or in other words, look at what the initiator had programmed in it's SYSCONFIG register. If it does consider them, it seems like that's bad HW design! If a PD 9powerdomain) is already in OFF state, that means all the initiators in that PD already has standby asserted. The modules in that PD also have transitioned. Ah, so if DSS was configured as Nostandby, and if we try to disable DSS, it would never transition to OFF, and hence never get disabled correctly, hence giving trouble to PRCM. So just before disabling DSS, we would need to put it to Force standby, and then try to cut the clocks and change the power state. Is this correct? If so, then it's equally messy as the suggested workaround :) Archit So PRCM won't poke that PD initiators/modules because it has already have a green signal for power transitions. At least that is what my understanding from the OMAP PRCM specs. 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 errata i740
On Fri, Mar 30, 2012 at 4:47 PM, Archit Taneja a0393...@ti.com wrote: On Friday 30 March 2012 04:34 PM, Shilimkar, Santosh wrote: On Fri, Mar 30, 2012 at 4:26 PM, Archit Tanejaa0393...@ti.com wrote: On Friday 30 March 2012 03:59 PM, Santosh Shilimkar wrote: On Friday 30 March 2012 03:53 PM, Cousson, Benoit wrote: On 3/30/2012 10:44 AM, Santosh Shilimkar wrote: On Friday 30 March 2012 02:04 PM, Archit Taneja wrote: On Friday 30 March 2012 02:01 PM, Santosh Shilimkar wrote: + Kevin On Friday 30 March 2012 01:56 PM, Tomi Valkeinen wrote: On Fri, 2012-03-30 at 13:51 +0530, Shilimkar, Santosh wrote: On Fri, Mar 30, 2012 at 1:37 PM, Tomi Valkeinentomi.valkei...@ti.com wrote: [...] I had a general PRCM question regarding this. If an initiator is disabled (i.e, clocks are OFF and Power state is OFF), then would the PRCM even care to look at the IdleAck/Mstandby signal of that initiator? Or in other words, look at what the initiator had programmed in it's SYSCONFIG register. If it does consider them, it seems like that's bad HW design! If a PD 9powerdomain) is already in OFF state, that means all the initiators in that PD already has standby asserted. The modules in that PD also have transitioned. Ah, so if DSS was configured as Nostandby, and if we try to disable DSS, it would never transition to OFF, and hence never get disabled correctly, hence giving trouble to PRCM. So just before disabling DSS, we would need to put it to Force standby, and then try to cut the clocks and change the power state. Is this correct? If so, then it's equally messy as the suggested workaround :) Exactly. That's what I mean. You tweak sysconfig or clockdomain, both are messy. if one need to choose between two bad options, I guess sysconifig one is better because that is local to IPs and there is some way today for drivers to manage sysconfig directly. 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 03/17] ARM: mark const init data with __initconst instead of __initdata
On Fri, Mar 30, 2012 at 11:50:24AM +0200, Uwe Kleine-König wrote:
Hello Shawn,
On Fri, Mar 30, 2012 at 02:11:36PM +0800, Shawn Guo wrote:
On Thu, Mar 29, 2012 at 11:12:20PM +0200, Uwe Kleine-König wrote:
...
diff --git a/arch/arm/mach-imx/imx51-dt.c b/arch/arm/mach-imx/imx51-dt.c
index 5cca573..7e00748 100644
--- a/arch/arm/mach-imx/imx51-dt.c
+++ b/arch/arm/mach-imx/imx51-dt.c
@@ -102,7 +102,7 @@ static struct sys_timer imx51_timer = {
.init = imx51_timer_init,
};
-static const char *imx51_dt_board_compat[] __initdata = {
+static const char *imx51_dt_board_compat[] __initconst = {
fsl,imx51-babbage,
fsl,imx51,
NULL
CC arch/arm/mach-imx/imx51-dt.o
arch/arm/mach-imx/imx51-dt.c:105:20: error: imx51_dt_board_compat causes a
section type conflict
make[2]: *** [arch/arm/mach-imx/imx51-dt.o] Error 1
I do not understand why though.
that's because the strings are constant, but the array is not.
Ah, yes. It indeed could be overlooked :)
--
Regards,
Shawn
--
To unsubscribe from this list: send the line unsubscribe 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/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Fri, Mar 30, 2012 at 15:12:19, Shilimkar, Santosh wrote: On Fri, Mar 30, 2012 at 2:58 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Fri, Mar 30, 2012 at 14:50:02, Shilimkar, Santosh wrote: On Fri, Mar 30, 2012 at 2:42 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Fri, Mar 30, 2012 at 14:08:20, Shilimkar, Santosh wrote: On Friday 30 March 2012 02:02 PM, Hiremath, Vaibhav wrote: On Fri, Mar 30, 2012 at 13:11:35, Shilimkar, Santosh wrote: ... Santosh others, Do you think, it makes sense to clean up the CONFIG_OMAP_32K_TIMER usage in mach-omap2/timer.c file now? Specifically below code-snippet - #ifdef CONFIG_OMAP_32K_TIMER #define OMAP2_CLKEV_SOURCE OMAP2_32K_SOURCE #define OMAP3_CLKEV_SOURCE OMAP3_32K_SOURCE #define OMAP4_CLKEV_SOURCE OMAP4_32K_SOURCE #define OMAP3_SECURE_TIMER 12 #else #define OMAP2_CLKEV_SOURCE OMAP2_MPU_SOURCE #define OMAP3_CLKEV_SOURCE OMAP3_MPU_SOURCE #define OMAP4_CLKEV_SOURCE OMAP4_MPU_SOURCE #define OMAP3_SECURE_TIMER 1 #endif And lets make 32k_fclk as default clocksource for gptimer, if it is being used as clocksource. Atleast with this I can clean whole omap2/3/4 families, and I can take omap1 thing later . (as I have to understand/read about omap1 first). If you agree, I can include this cleanup also in my next version of patch- series. What's your opinion here? Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: OMAP2+: 32k-counter: Use hwmod lookup to check presence of 32k timer
On Friday 30 March 2012 04:59 PM, Hiremath, Vaibhav wrote: On Fri, Mar 30, 2012 at 15:12:19, Shilimkar, Santosh wrote: On Fri, Mar 30, 2012 at 2:58 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Fri, Mar 30, 2012 at 14:50:02, Shilimkar, Santosh wrote: On Fri, Mar 30, 2012 at 2:42 PM, Hiremath, Vaibhav hvaib...@ti.com wrote: On Fri, Mar 30, 2012 at 14:08:20, Shilimkar, Santosh wrote: On Friday 30 March 2012 02:02 PM, Hiremath, Vaibhav wrote: On Fri, Mar 30, 2012 at 13:11:35, Shilimkar, Santosh wrote: ... Santosh others, Do you think, it makes sense to clean up the CONFIG_OMAP_32K_TIMER usage in mach-omap2/timer.c file now? Specifically below code-snippet - #ifdef CONFIG_OMAP_32K_TIMER #define OMAP2_CLKEV_SOURCE OMAP2_32K_SOURCE #define OMAP3_CLKEV_SOURCE OMAP3_32K_SOURCE #define OMAP4_CLKEV_SOURCE OMAP4_32K_SOURCE #define OMAP3_SECURE_TIMER 12 #else #define OMAP2_CLKEV_SOURCE OMAP2_MPU_SOURCE #define OMAP3_CLKEV_SOURCE OMAP3_MPU_SOURCE #define OMAP4_CLKEV_SOURCE OMAP4_MPU_SOURCE #define OMAP3_SECURE_TIMER 1 #endif And lets make 32k_fclk as default clocksource for gptimer, if it is being used as clocksource. Atleast with this I can clean whole omap2/3/4 families, and I can take omap1 thing later . (as I have to understand/read about omap1 first). If you agree, I can include this cleanup also in my next version of patch- series. What's your opinion here? I am ok with this clean up. But I let Tony take decision on 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
[PATCH v5 00/18] Introduce a led trigger for CPU activity and consolidate LED driver in ARM
Based on Linus Walleij's ARM LED consolidation work, this patchset introduce a new generic led trigger for CPU not only for ARM but also for others. For enabling CPU idle event, CPU arch code should call ledtrig_cpu() stub to trigger idle start or idle end event. These patches convert old style LED driver in arch/arm to gpio_led or new led driver interface. Against linux-next 20120330 and build successfully for all the machines. Test ledtrig-cpu driver on OMAP4 Panda board. -- root@omap4430-panda:~# dmesg | grep trig [1.891265] LED trigger cpu0 indicate activity on CPU 0 [1.896728] LED trigger cpu1 indicate activity on CPU 1 root@omap4430-panda:~# cat /sys/class/leds/pandaboard\:\:status1/trigger none nand-disk mmc0 mmc1 timer [heartbeat] cpu0 cpu1 root@omap4430-panda:~# cat /sys/class/leds/pandaboard\:\:status2/trigger none nand-disk [mmc0] mmc1 timer heartbeat cpu0 cpu1 root@omap4430-panda:~# echo cpu0 /sys/class/leds/pandaboard\:\:status1/trigger root@omap4430-panda:~# cat /sys/class/leds/pandaboard\:\:status1/trigger none nand-disk mmc0 mmc1 timer heartbeat [cpu0] cpu1 root@omap4430-panda:~# echo cpu1 /sys/class/leds/pandaboard\:\:status2/trigger root@omap4430-panda:~# cat /sys/class/leds/pandaboard\:\:status2/trigger none nand-disk mmc0 mmc1 timer heartbeat cpu0 [cpu1] Then try some heavy task like dd and use taskset to assign the task to a specific CPU, LED will turn on or off as expect -- Please find these patches here: git://kernel.ubuntu.com/roc/linux-2.6/.git leds v4 -- v5: * rebase all the patches on top of latest linux-next * replace on_each_cpu() with for_each_possible_cpu() * add some description of ledtrig_cpu() API * remove old leds code from driver nwflash.c, which should use a new led trigger then * this trigger driver can be built as module now v3 -- v4: * fix a typo pointed by Jochen Friedrich * fix some building errors * add Reviewed-by and Tested-by into patch log v2 -- v3: * almost rewrote the whole ledtrig-cpu driver, which is more simple * every CPU will have a per-CPU trigger * cpu trigger can be assigned to any leds * fix a lockdep issue in led-trigger common code * other fix according to review v1 -- v2: * remove select operations in Kconfig of every machines * add back supporting of led in core module of mach-integrator * solidate name scheme in ledtrig-cpu.c * add comments of CPU_LED_* cpu led events * fold patches of RealView and Versatile together * add machine_is_ check during assabet led driver init * add some Acked-by in patch logs * remove code for simpad machine in machine-sa11000, since Jochen Friedrich introduced gpiolib and gpio-led driver for simpad * on Assabet and Netwinder machine, LED operations is reversed like: setting bit means turn off leds clearing bit means turn on leds * add a new function to read CM_CTRL register for led driver Bryan Wu (18): led-triggers: create a trigger for CPU activity ARM: at91: convert old leds drivers to gpio_led and led_trigger drivers ARM: mach-realview and mach-versatile: retire custom LED code ARM: mach-ks8695: remove leds driver, since nobody use it ARM: mach-shark: retire custom LED code ARM: mach-orion5x: convert custom LED code to gpio_led and LED CPU trigger ARM: mach-integrator: move CM_CTRL to header file for accessing by other functions ARM: mach-integrator: retire custom LED code ARM: mach-clps711x: retire custom LED code of P720T machine ARM: mach-ebsa110: retire custom LED code ARM: mach-footbridge: retire custom LED code char: nwflash: remove old led event code ARM: mach-pxa: retire custom LED code ARM: plat-samsung: remove including old leds event API header file ARM: mach-pnx4008: remove including old leds event API header file ARM: mach-omap1: retire custom LED code ARM: mach-sa1100: retire custom LED code ARM: use new LEDS CPU trigger stub to replace old one arch/arm/Kconfig | 53 - arch/arm/include/asm/leds.h | 50 - arch/arm/kernel/Makefile |1 - arch/arm/kernel/leds.c | 121 --- arch/arm/kernel/process.c|6 +- arch/arm/kernel/time.c | 17 -- arch/arm/mach-at91/board-csb337.c|3 - arch/arm/mach-at91/board-ecbat91.c | 18 ++- arch/arm/mach-at91/board-eco920.c| 23 ++- arch/arm/mach-at91/board-kafa.c | 17 ++- arch/arm/mach-at91/board-kb9202.c| 23 ++- arch/arm/mach-at91/board-rm9200dk.c |3 - arch/arm/mach-at91/board-rm9200ek.c |3 - arch/arm/mach-at91/board-sam9-l9260.c| 23 ++- arch/arm/mach-at91/board-sam9261ek.c |3 - arch/arm/mach-at91/board-yl-9200.c |3 - arch/arm/mach-at91/include/mach/board.h |1 - arch/arm/mach-at91/leds.c| 105 - arch/arm/mach-clps711x/Makefile
[PATCH 01/18] led-triggers: create a trigger for CPU activity
Attempting to consolidate the ARM LED code, this removes the
custom RealView LED trigger code to turn LEDs on and off in
response to CPU activity and replace it with a standard trigger.
(bryan...@canonical.com:
It moves arch/arm/kernel/leds.c syscore stubs into this trigger.
It also provides ledtrig_cpu trigger event stub in linux/leds.h.
Although it was inspired by ARM work, it can be used in other arch.)
Cc: Richard Purdie rpur...@rpsys.net
Signed-off-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Bryan Wu bryan...@canonical.com
Reviewed-by: Jamie Iles ja...@jamieiles.com
Tested-by: Jochen Friedrich joc...@scram.de
---
drivers/leds/Kconfig | 10 +++
drivers/leds/Makefile |1 +
drivers/leds/ledtrig-cpu.c | 138
include/linux/leds.h | 23 +++
4 files changed, 172 insertions(+), 0 deletions(-)
create mode 100644 drivers/leds/ledtrig-cpu.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index ff4b8cf..cf02fb8 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -448,6 +448,16 @@ config LEDS_TRIGGER_BACKLIGHT
If unsure, say N.
+config LEDS_TRIGGER_CPU
+ tristate LED CPU Trigger
+ depends on LEDS_TRIGGERS
+ help
+ This allows LEDs to be controlled by active CPUs. This shows
+ the active CPUs across an array of LEDs so you can see what
+ CPUs are active on the system at any given moment.
+
+ If unsure, say N.
+
config LEDS_TRIGGER_GPIO
tristate LED GPIO Trigger
depends on LEDS_TRIGGERS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 890481c..0a3d5ad 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -55,4 +55,5 @@ obj-$(CONFIG_LEDS_TRIGGER_IDE_DISK) += ledtrig-ide-disk.o
obj-$(CONFIG_LEDS_TRIGGER_HEARTBEAT) += ledtrig-heartbeat.o
obj-$(CONFIG_LEDS_TRIGGER_BACKLIGHT) += ledtrig-backlight.o
obj-$(CONFIG_LEDS_TRIGGER_GPIO)+= ledtrig-gpio.o
+obj-$(CONFIG_LEDS_TRIGGER_CPU) += ledtrig-cpu.o
obj-$(CONFIG_LEDS_TRIGGER_DEFAULT_ON) += ledtrig-default-on.o
diff --git a/drivers/leds/ledtrig-cpu.c b/drivers/leds/ledtrig-cpu.c
new file mode 100644
index 000..d48c4b5
--- /dev/null
+++ b/drivers/leds/ledtrig-cpu.c
@@ -0,0 +1,138 @@
+/*
+ * ledtrig-cpu.c - LED trigger based on CPU activity
+ *
+ * This LED trigger will be registered for each possible CPU and named as
+ * cpu0, cpu1, cpu2, cpu3, etc.
+ *
+ * It can be binded with any LEDs as other triggers does, either in board
+ * file or via sysfs interface.
+ *
+ * An API named ledtrig_cpu is exported for any user, who want to add CPU
+ * activity indication in their code
+ *
+ * Copyright 2011 Linus Walleij linus.wall...@linaro.org
+ * Copyright 2011 - 2012 Bryan Wu bryan...@canonical.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/percpu.h
+#include linux/syscore_ops.h
+#include leds.h
+
+#define MAX_NAME_LEN 8
+
+static DEFINE_PER_CPU(struct led_trigger *, cpu_trig);
+static DEFINE_PER_CPU(char [MAX_NAME_LEN], trig_name);
+
+void ledtrig_cpu(enum cpu_led_event ledevt)
+{
+ struct led_trigger *trig = __get_cpu_var(cpu_trig);
+
+ if (!trig)
+ return;
+
+ /* Locate the correct CPU LED */
+ switch (ledevt) {
+ case CPU_LED_IDLE_END:
+ case CPU_LED_START:
+ /* Will turn the LED on, max brightness */
+ led_trigger_event(trig, LED_FULL);
+ break;
+
+ case CPU_LED_IDLE_START:
+ case CPU_LED_STOP:
+ case CPU_LED_HALTED:
+ /* Will turn the LED off */
+ led_trigger_event(trig, LED_OFF);
+ break;
+
+ default:
+ /* Will leave the LED as it is */
+ break;
+ }
+}
+EXPORT_SYMBOL(ledtrig_cpu);
+
+static int ledtrig_cpu_syscore_suspend(void)
+{
+ ledtrig_cpu(CPU_LED_STOP);
+ return 0;
+}
+
+static void ledtrig_cpu_syscore_resume(void)
+{
+ ledtrig_cpu(CPU_LED_START);
+}
+
+static void ledtrig_cpu_syscore_shutdown(void)
+{
+ ledtrig_cpu(CPU_LED_HALTED);
+}
+
+static struct syscore_ops ledtrig_cpu_syscore_ops = {
+ .shutdown = ledtrig_cpu_syscore_shutdown,
+ .suspend= ledtrig_cpu_syscore_suspend,
+ .resume = ledtrig_cpu_syscore_resume,
+};
+
+static void __init ledtrig_cpu_register(void)
+{
+ int cpuid = smp_processor_id();
+ struct led_trigger *trig;
+ char *name = __get_cpu_var(trig_name);
+
+ snprintf(name, MAX_NAME_LEN, cpu%d, cpuid);
+ led_trigger_register_simple(name, trig);
+
+ pr_info(LED trigger %s indicate activity on CPU %d\n,
+ trig-name, cpuid);
+
+
Re: OMAP4 errata i740
On Fri, 2012-03-30 at 16:50 +0530, Shilimkar, Santosh wrote: Exactly. That's what I mean. You tweak sysconfig or clockdomain, both are messy. if one need to choose between two bad options, I guess sysconifig one is better because that is local to IPs and there is some way today for drivers to manage sysconfig directly. If the driver touches sysconfig, isn't it possible that hwmod/something just reverts the changes? I mean, sysconfig register is supposedly owned by the arch code, and if the driver modifies it there could be a race condition. Tomi signature.asc Description: This is a digitally signed message part
[PATCH 03/18] ARM: mach-realview and mach-versatile: retire custom LED code
This replaces the custom LED trigger code in mach-realview with
some overarching platform code for the plat-versatile family that
will lock down LEDs 2 thru 5 for CPU activity indication. The
day we have 8 core ARM systems the plat-versatile code will have
to become more elaborate.
Tested on RealView PB11MPCore by invoking four different CPU
hogs (yes /dev/null) and see the LEDs go on one at a time.
They all go off as the hogs are killed. Tested on the PB1176
as well - just one activity led (led 2) goes on and off with
CPU activity.
(bryan...@canonical.com: use ledtrig-cpu instead of ledtrig-arm-cpu)
Cc: Richard Purdie rpur...@rpsys.net
Signed-off-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Bryan Wu bryan...@canonical.com
Acked-by: Pawel Moll pawel.m...@arm.com
---
arch/arm/mach-realview/core.c| 39 --
arch/arm/mach-realview/core.h|2 -
arch/arm/mach-realview/realview_eb.c |5
arch/arm/mach-realview/realview_pb1176.c |5
arch/arm/mach-realview/realview_pb11mp.c |5
arch/arm/mach-realview/realview_pba8.c |5
arch/arm/mach-realview/realview_pbx.c|5
arch/arm/mach-versatile/core.c |5
arch/arm/plat-versatile/Kconfig |4 ++-
arch/arm/plat-versatile/leds.c | 13 +++---
10 files changed, 12 insertions(+), 76 deletions(-)
diff --git a/arch/arm/mach-realview/core.c b/arch/arm/mach-realview/core.c
index 45868bb..d22dee9 100644
--- a/arch/arm/mach-realview/core.c
+++ b/arch/arm/mach-realview/core.c
@@ -35,7 +35,6 @@
#include mach/hardware.h
#include asm/irq.h
-#include asm/leds.h
#include asm/mach-types.h
#include asm/hardware/arm_timer.h
#include asm/hardware/icst.h
@@ -436,44 +435,6 @@ struct clcd_board clcd_plat_data = {
.remove = versatile_clcd_remove_dma,
};
-#ifdef CONFIG_LEDS
-#define VA_LEDS_BASE (__io_address(REALVIEW_SYS_BASE) +
REALVIEW_SYS_LED_OFFSET)
-
-void realview_leds_event(led_event_t ledevt)
-{
- unsigned long flags;
- u32 val;
- u32 led = 1 smp_processor_id();
-
- local_irq_save(flags);
- val = readl(VA_LEDS_BASE);
-
- switch (ledevt) {
- case led_idle_start:
- val = val ~led;
- break;
-
- case led_idle_end:
- val = val | led;
- break;
-
- case led_timer:
- val = val ^ REALVIEW_SYS_LED7;
- break;
-
- case led_halted:
- val = 0;
- break;
-
- default:
- break;
- }
-
- writel(val, VA_LEDS_BASE);
- local_irq_restore(flags);
-}
-#endif /* CONFIG_LEDS */
-
/*
* Where is the timer (VA)?
*/
diff --git a/arch/arm/mach-realview/core.h b/arch/arm/mach-realview/core.h
index f8f2c0a..f2141ae 100644
--- a/arch/arm/mach-realview/core.h
+++ b/arch/arm/mach-realview/core.h
@@ -26,7 +26,6 @@
#include linux/io.h
#include asm/setup.h
-#include asm/leds.h
#define APB_DEVICE(name, busid, base, plat)\
static AMBA_APB_DEVICE(name, busid, 0, REALVIEW_##base##_BASE, base##_IRQ,
plat)
@@ -47,7 +46,6 @@ extern void __iomem *timer1_va_base;
extern void __iomem *timer2_va_base;
extern void __iomem *timer3_va_base;
-extern void realview_leds_event(led_event_t ledevt);
extern void realview_timer_init(unsigned int timer_irq);
extern int realview_flash_register(struct resource *res, u32 num);
extern int realview_eth_register(const char *name, struct resource *res);
diff --git a/arch/arm/mach-realview/realview_eb.c
b/arch/arm/mach-realview/realview_eb.c
index baf382c..21661ad 100644
--- a/arch/arm/mach-realview/realview_eb.c
+++ b/arch/arm/mach-realview/realview_eb.c
@@ -30,7 +30,6 @@
#include mach/hardware.h
#include asm/irq.h
-#include asm/leds.h
#include asm/mach-types.h
#include asm/pmu.h
#include asm/pgtable.h
@@ -462,10 +461,6 @@ static void __init realview_eb_init(void)
struct amba_device *d = amba_devs[i];
amba_device_register(d, iomem_resource);
}
-
-#ifdef CONFIG_LEDS
- leds_event = realview_leds_event;
-#endif
}
MACHINE_START(REALVIEW_EB, ARM-RealView EB)
diff --git a/arch/arm/mach-realview/realview_pb1176.c
b/arch/arm/mach-realview/realview_pb1176.c
index b1d7caf..c0ff882 100644
--- a/arch/arm/mach-realview/realview_pb1176.c
+++ b/arch/arm/mach-realview/realview_pb1176.c
@@ -32,7 +32,6 @@
#include mach/hardware.h
#include asm/irq.h
-#include asm/leds.h
#include asm/mach-types.h
#include asm/pmu.h
#include asm/pgtable.h
@@ -375,10 +374,6 @@ static void __init realview_pb1176_init(void)
struct amba_device *d = amba_devs[i];
amba_device_register(d, iomem_resource);
}
-
-#ifdef CONFIG_LEDS
- leds_event = realview_leds_event;
-#endif
}
MACHINE_START(REALVIEW_PB1176, ARM-RealView PB1176)
diff --git a/arch/arm/mach-realview/realview_pb11mp.c
[PATCH 02/18] ARM: at91: convert old leds drivers to gpio_led and led_trigger drivers
Build with at91 defconfigs successfully
Signed-off-by: Bryan Wu bryan...@canonical.com
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
---
arch/arm/mach-at91/board-csb337.c |3 -
arch/arm/mach-at91/board-ecbat91.c | 18 +-
arch/arm/mach-at91/board-eco920.c | 23 ++-
arch/arm/mach-at91/board-kafa.c | 17 -
arch/arm/mach-at91/board-kb9202.c | 23 ++-
arch/arm/mach-at91/board-rm9200dk.c |3 -
arch/arm/mach-at91/board-rm9200ek.c |3 -
arch/arm/mach-at91/board-sam9-l9260.c | 23 ++-
arch/arm/mach-at91/board-sam9261ek.c|3 -
arch/arm/mach-at91/board-yl-9200.c |3 -
arch/arm/mach-at91/include/mach/board.h |1 -
arch/arm/mach-at91/leds.c | 105 ---
12 files changed, 89 insertions(+), 136 deletions(-)
diff --git a/arch/arm/mach-at91/board-csb337.c
b/arch/arm/mach-at91/board-csb337.c
index 1a1547b..ce2eea3 100644
--- a/arch/arm/mach-at91/board-csb337.c
+++ b/arch/arm/mach-at91/board-csb337.c
@@ -48,9 +48,6 @@ static void __init csb337_init_early(void)
/* Initialize processor: 3.6864 MHz crystal */
at91_initialize(3686400);
- /* Setup the LEDs */
- at91_init_leds(AT91_PIN_PB0, AT91_PIN_PB1);
-
/* DBGU on ttyS0 */
at91_register_uart(0, 0, 0);
diff --git a/arch/arm/mach-at91/board-ecbat91.c
b/arch/arm/mach-at91/board-ecbat91.c
index 69966ce..da671f5 100644
--- a/arch/arm/mach-at91/board-ecbat91.c
+++ b/arch/arm/mach-at91/board-ecbat91.c
@@ -51,9 +51,6 @@ static void __init ecb_at91init_early(void)
/* Initialize processor: 18.432 MHz crystal */
at91_initialize(18432000);
- /* Setup the LEDs */
- at91_init_leds(AT91_PIN_PC7, AT91_PIN_PC7);
-
/* DBGU on ttyS0. (Rx Tx only) */
at91_register_uart(0, 0, 0);
@@ -149,6 +146,18 @@ static struct spi_board_info __initdata
ecb_at91spi_devices[] = {
},
};
+/*
+ * LEDs
+ */
+static struct gpio_led ecb_leds[] = {
+ { /* D1 */
+ .name = led1,
+ .gpio = AT91_PIN_PC7,
+ .active_low = 1,
+ .default_trigger= heartbeat,
+ }
+};
+
static void __init ecb_at91board_init(void)
{
/* Serial */
@@ -168,6 +177,9 @@ static void __init ecb_at91board_init(void)
/* SPI */
at91_add_device_spi(ecb_at91spi_devices,
ARRAY_SIZE(ecb_at91spi_devices));
+
+ /* LEDs */
+ at91_gpio_leds(ecb_leds, ARRAY_SIZE(ecb_leds));
}
MACHINE_START(ECBAT91, emQbit's ECB_AT91)
diff --git a/arch/arm/mach-at91/board-eco920.c
b/arch/arm/mach-at91/board-eco920.c
index f23aabe..3484eac 100644
--- a/arch/arm/mach-at91/board-eco920.c
+++ b/arch/arm/mach-at91/board-eco920.c
@@ -38,9 +38,6 @@ static void __init eco920_init_early(void)
at91_initialize(18432000);
- /* Setup the LEDs */
- at91_init_leds(AT91_PIN_PB0, AT91_PIN_PB1);
-
/* DBGU on ttyS0. (Rx Tx only */
at91_register_uart(0, 0, 0);
@@ -101,6 +98,24 @@ static struct spi_board_info eco920_spi_devices[] = {
},
};
+/*
+ * LEDs
+ */
+static struct gpio_led eco920_leds[] = {
+ { /* D1 */
+ .name = led1,
+ .gpio = AT91_PIN_PB0,
+ .active_low = 1,
+ .default_trigger= heartbeat,
+ },
+ { /* D2 */
+ .name = led2,
+ .gpio = AT91_PIN_PB1,
+ .active_low = 1,
+ .default_trigger= timer,
+ }
+};
+
static void __init eco920_board_init(void)
{
at91_add_device_serial();
@@ -131,6 +146,8 @@ static void __init eco920_board_init(void)
);
at91_add_device_spi(eco920_spi_devices, ARRAY_SIZE(eco920_spi_devices));
+ /* LEDs */
+ at91_gpio_leds(eco920_leds, ARRAY_SIZE(eco920_leds));
}
MACHINE_START(ECO920, eco920)
diff --git a/arch/arm/mach-at91/board-kafa.c b/arch/arm/mach-at91/board-kafa.c
index efde1b2..bcd7f44 100644
--- a/arch/arm/mach-at91/board-kafa.c
+++ b/arch/arm/mach-at91/board-kafa.c
@@ -48,9 +48,6 @@ static void __init kafa_init_early(void)
/* Initialize processor: 18.432 MHz crystal */
at91_initialize(18432000);
- /* Set up the LEDs */
- at91_init_leds(AT91_PIN_PB4, AT91_PIN_PB4);
-
/* DBGU on ttyS0. (Rx Tx only) */
at91_register_uart(0, 0, 0);
@@ -77,6 +74,18 @@ static struct at91_udc_data __initdata kafa_udc_data = {
.pullup_pin = AT91_PIN_PB7,
};
+/*
+ * LEDs
+ */
+static struct gpio_led kafa_leds[] = {
+ { /* D1 */
+ .name = led1,
+ .gpio = AT91_PIN_PB4,
+ .active_low = 1,
+ .default_trigger= heartbeat,
+ },
+};
+
[PATCH 04/18] ARM: mach-ks8695: remove leds driver, since nobody use it
Signed-off-by: Bryan Wu bryan...@canonical.com
Acked-by: Andrew Victor li...@maxim.org.za
---
arch/arm/mach-ks8695/Makefile |3 -
arch/arm/mach-ks8695/devices.c | 21 --
arch/arm/mach-ks8695/include/mach/devices.h |5 --
arch/arm/mach-ks8695/leds.c | 92 ---
4 files changed, 0 insertions(+), 121 deletions(-)
delete mode 100644 arch/arm/mach-ks8695/leds.c
diff --git a/arch/arm/mach-ks8695/Makefile b/arch/arm/mach-ks8695/Makefile
index 853efd9..9324ef9 100644
--- a/arch/arm/mach-ks8695/Makefile
+++ b/arch/arm/mach-ks8695/Makefile
@@ -11,9 +11,6 @@ obj- :=
# PCI support is optional
obj-$(CONFIG_PCI) += pci.o
-# LEDs
-obj-$(CONFIG_LEDS) += leds.o
-
# Board-specific support
obj-$(CONFIG_MACH_KS8695) += board-micrel.o
obj-$(CONFIG_MACH_DSM320) += board-dsm320.o
diff --git a/arch/arm/mach-ks8695/devices.c b/arch/arm/mach-ks8695/devices.c
index 73bd638..47399bc 100644
--- a/arch/arm/mach-ks8695/devices.c
+++ b/arch/arm/mach-ks8695/devices.c
@@ -182,27 +182,6 @@ static void __init ks8695_add_device_watchdog(void)
}
-/*
- * LEDs
- * */
-
-#if defined(CONFIG_LEDS)
-short ks8695_leds_cpu = -1;
-short ks8695_leds_timer = -1;
-
-void __init ks8695_init_leds(u8 cpu_led, u8 timer_led)
-{
- /* Enable GPIO to access the LEDs */
- gpio_direction_output(cpu_led, 1);
- gpio_direction_output(timer_led, 1);
-
- ks8695_leds_cpu = cpu_led;
- ks8695_leds_timer = timer_led;
-}
-#else
-void __init ks8695_init_leds(u8 cpu_led, u8 timer_led) {}
-#endif
-
/* */
/*
diff --git a/arch/arm/mach-ks8695/include/mach/devices.h
b/arch/arm/mach-ks8695/include/mach/devices.h
index 85a3c9a..1e6594a 100644
--- a/arch/arm/mach-ks8695/include/mach/devices.h
+++ b/arch/arm/mach-ks8695/include/mach/devices.h
@@ -18,11 +18,6 @@ extern void __init ks8695_add_device_wan(void);
extern void __init ks8695_add_device_lan(void);
extern void __init ks8695_add_device_hpna(void);
- /* LEDs */
-extern short ks8695_leds_cpu;
-extern short ks8695_leds_timer;
-extern void __init ks8695_init_leds(u8 cpu_led, u8 timer_led);
-
/* PCI */
#define KS8695_MODE_PCI0
#define KS8695_MODE_MINIPCI1
diff --git a/arch/arm/mach-ks8695/leds.c b/arch/arm/mach-ks8695/leds.c
deleted file mode 100644
index 4bd7075..000
--- a/arch/arm/mach-ks8695/leds.c
+++ /dev/null
@@ -1,92 +0,0 @@
-/*
- * LED driver for KS8695-based boards.
- *
- * Copyright (C) Andrew Victor
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-#include linux/gpio.h
-#include linux/kernel.h
-#include linux/module.h
-#include linux/init.h
-
-#include asm/leds.h
-#include mach/devices.h
-
-
-static inline void ks8695_led_on(unsigned int led)
-{
- gpio_set_value(led, 0);
-}
-
-static inline void ks8695_led_off(unsigned int led)
-{
- gpio_set_value(led, 1);
-}
-
-static inline void ks8695_led_toggle(unsigned int led)
-{
- unsigned long is_off = gpio_get_value(led);
- if (is_off)
- ks8695_led_on(led);
- else
- ks8695_led_off(led);
-}
-
-
-/*
- * Handle LED events.
- */
-static void ks8695_leds_event(led_event_t evt)
-{
- unsigned long flags;
-
- local_irq_save(flags);
-
- switch(evt) {
- case led_start: /* System startup */
- ks8695_led_on(ks8695_leds_cpu);
- break;
-
- case led_stop: /* System stop / suspend */
- ks8695_led_off(ks8695_leds_cpu);
- break;
-
-#ifdef CONFIG_LEDS_TIMER
- case led_timer: /* Every 50 timer ticks */
- ks8695_led_toggle(ks8695_leds_timer);
- break;
-#endif
-
-#ifdef CONFIG_LEDS_CPU
- case led_idle_start:/* Entering idle state */
- ks8695_led_off(ks8695_leds_cpu);
- break;
-
- case led_idle_end: /* Exit idle state */
- ks8695_led_on(ks8695_leds_cpu);
- break;
-#endif
-
- default:
- break;
- }
-
- local_irq_restore(flags);
-}
-
-
-static int __init leds_init(void)
-{
- if ((ks8695_leds_timer == -1) || (ks8695_leds_cpu == -1))
- return -ENODEV;
-
- leds_event = ks8695_leds_event;
-
- leds_event(led_start);
- return 0;
-}
-
-__initcall(leds_init);
--
1.7.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/18] ARM: mach-shark: retire custom LED code
The CPU activity LED is now handled by the trigger in the leds
subsystem, retire this old CONFIG_LEDS-based code.
Signed-off-by: Bryan Wu bryan...@canonical.com
---
arch/arm/mach-shark/Makefile |4 +-
arch/arm/mach-shark/core.c |1 -
arch/arm/mach-shark/leds.c | 226 -
3 files changed, 89 insertions(+), 142 deletions(-)
diff --git a/arch/arm/mach-shark/Makefile b/arch/arm/mach-shark/Makefile
index 45be9b0..2965718 100644
--- a/arch/arm/mach-shark/Makefile
+++ b/arch/arm/mach-shark/Makefile
@@ -4,9 +4,7 @@
# Object file lists.
-obj-y := core.o dma.o irq.o pci.o
+obj-y := core.o dma.o irq.o pci.o leds.o
obj-m :=
obj-n :=
obj- :=
-
-obj-$(CONFIG_LEDS) += leds.o
diff --git a/arch/arm/mach-shark/core.c b/arch/arm/mach-shark/core.c
index 6a2a7f2..58f6c65 100644
--- a/arch/arm/mach-shark/core.c
+++ b/arch/arm/mach-shark/core.c
@@ -13,7 +13,6 @@
#include asm/setup.h
#include asm/mach-types.h
-#include asm/leds.h
#include asm/param.h
#include asm/mach/map.h
diff --git a/arch/arm/mach-shark/leds.c b/arch/arm/mach-shark/leds.c
index 2560907..55433b0 100644
--- a/arch/arm/mach-shark/leds.c
+++ b/arch/arm/mach-shark/leds.c
@@ -1,165 +1,115 @@
/*
- * arch/arm/mach-shark/leds.c
- * by Alexander Schulz
- *
- * derived from:
- * arch/arm/kernel/leds-footbridge.c
- * Copyright (C) 1998-1999 Russell King
- *
* DIGITAL Shark LED control routines.
*
- * The leds use is as follows:
- * - Green front - toggles state every 50 timer interrupts
- * - Amber front - Unused, this is a dual color led (Amber/Green)
- * - Amber back - On if system is not idle
+ * Driver for the 3 user LEDs found on the Shark
+ * Based on Versatile and RealView machine LED code
*
- * Changelog:
+ * License terms: GNU General Public License (GPL) version 2
+ * Author: Bryan Wu bryan...@canonical.com
*/
#include linux/kernel.h
-#include linux/module.h
#include linux/init.h
-#include linux/spinlock.h
-#include linux/ioport.h
#include linux/io.h
+#include linux/ioport.h
+#include linux/slab.h
+#include linux/leds.h
-#include asm/leds.h
+#include asm/mach-types.h
-#define LED_STATE_ENABLED 1
-#define LED_STATE_CLAIMED 2
+struct shark_led {
+ struct led_classdev cdev;
+ u8 mask;
+};
-#define SEQUOIA_LED_GREEN (16)
-#define SEQUOIA_LED_AMBER (15)
-#define SEQUOIA_LED_BACK(17)
+/*
+ * The triggers lines up below will only be used if the
+ * LED triggers are compiled in.
+ */
+static const struct {
+ const char *name;
+ const char *trigger;
+} shark_leds[] = {
+ { shark:amber0, default-on, }, /* Bit 5 */
+ { shark:green, heartbeat, },/* Bit 6 */
+ { shark:amber1, cpu0 }, /* Bit 7 */
+};
+
+static u16 led_reg_read(void)
+{
+ outw(0x09, 0x24);
+ return inw(0x26);
+}
-static char led_state;
-static short hw_led_state;
-static short saved_state;
+static void led_reg_write(u16 value)
+{
+ outw(0x09, 0x24);
+ outw(value, 0x26);
+}
-static DEFINE_RAW_SPINLOCK(leds_lock);
+static void shark_led_set(struct led_classdev *cdev,
+ enum led_brightness b)
+{
+ struct shark_led *led = container_of(cdev,
+struct shark_led, cdev);
+ u16 reg = led_reg_read();
-short sequoia_read(int addr) {
- outw(addr,0x24);
- return inw(0x26);
-}
+ if (b != LED_OFF)
+ reg |= led-mask;
+ else
+ reg = ~led-mask;
-void sequoia_write(short value,short addr) {
- outw(addr,0x24);
- outw(value,0x26);
+ led_reg_write(reg);
}
-static void sequoia_leds_event(led_event_t evt)
+static enum led_brightness shark_led_get(struct led_classdev *cdev)
{
- unsigned long flags;
-
- raw_spin_lock_irqsave(leds_lock, flags);
-
- hw_led_state = sequoia_read(0x09);
-
- switch (evt) {
- case led_start:
- hw_led_state |= SEQUOIA_LED_GREEN;
- hw_led_state |= SEQUOIA_LED_AMBER;
-#ifdef CONFIG_LEDS_CPU
- hw_led_state |= SEQUOIA_LED_BACK;
-#else
- hw_led_state = ~SEQUOIA_LED_BACK;
-#endif
- led_state |= LED_STATE_ENABLED;
- break;
-
- case led_stop:
- hw_led_state = ~SEQUOIA_LED_BACK;
- hw_led_state |= SEQUOIA_LED_GREEN;
- hw_led_state |= SEQUOIA_LED_AMBER;
- led_state = ~LED_STATE_ENABLED;
- break;
-
- case led_claim:
- led_state |= LED_STATE_CLAIMED;
- saved_state = hw_led_state;
- hw_led_state = ~SEQUOIA_LED_BACK;
- hw_led_state |= SEQUOIA_LED_GREEN;
- hw_led_state |= SEQUOIA_LED_AMBER;
- break;
-
- case led_release:
- led_state = ~LED_STATE_CLAIMED;
- hw_led_state =
[PATCH 06/18] ARM: mach-orion5x: convert custom LED code to gpio_led and LED CPU trigger
Signed-off-by: Bryan Wu bryan...@canonical.com
Acked-by: Nicolas Pitre n...@fluxnic.net
---
arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c |1 -
arch/arm/mach-orion5x/rd88f5181l-ge-setup.c |1 -
arch/arm/mach-orion5x/rd88f5182-setup.c | 72 --
arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c |1 -
4 files changed, 22 insertions(+), 53 deletions(-)
diff --git a/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
b/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
index 292038f..698ad13 100644
--- a/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
+++ b/arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c
@@ -18,7 +18,6 @@
#include linux/ethtool.h
#include net/dsa.h
#include asm/mach-types.h
-#include asm/leds.h
#include asm/mach/arch.h
#include asm/mach/pci.h
#include mach/orion5x.h
diff --git a/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
b/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
index c44eaba..0379f5b 100644
--- a/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
+++ b/arch/arm/mach-orion5x/rd88f5181l-ge-setup.c
@@ -19,7 +19,6 @@
#include linux/i2c.h
#include net/dsa.h
#include asm/mach-types.h
-#include asm/leds.h
#include asm/mach/arch.h
#include asm/mach/pci.h
#include mach/orion5x.h
diff --git a/arch/arm/mach-orion5x/rd88f5182-setup.c
b/arch/arm/mach-orion5x/rd88f5182-setup.c
index e3ce617..8bc8962 100644
--- a/arch/arm/mach-orion5x/rd88f5182-setup.c
+++ b/arch/arm/mach-orion5x/rd88f5182-setup.c
@@ -19,8 +19,8 @@
#include linux/mv643xx_eth.h
#include linux/ata_platform.h
#include linux/i2c.h
+#include linux/leds.h
#include asm/mach-types.h
-#include asm/leds.h
#include asm/mach/arch.h
#include asm/mach/pci.h
#include mach/orion5x.h
@@ -53,12 +53,6 @@
#define RD88F5182_PCI_SLOT0_IRQ_A_PIN 7
#define RD88F5182_PCI_SLOT0_IRQ_B_PIN 6
-/*
- * GPIO Debug LED
- */
-
-#define RD88F5182_GPIO_DBG_LED 0
-
/*
* 16M NOR Flash on Device bus CS1
/
@@ -83,55 +77,32 @@ static struct platform_device rd88f5182_nor_flash = {
.resource = rd88f5182_nor_flash_resource,
};
-#ifdef CONFIG_LEDS
-
/*
- * Use GPIO debug led as CPU active indication
+ * Use GPIO LED as CPU active indication
/
-static void rd88f5182_dbgled_event(led_event_t evt)
-{
- int val;
-
- if (evt == led_idle_end)
- val = 1;
- else if (evt == led_idle_start)
- val = 0;
- else
- return;
-
- gpio_set_value(RD88F5182_GPIO_DBG_LED, val);
-}
-
-static int __init rd88f5182_dbgled_init(void)
-{
- int pin;
-
- if (machine_is_rd88f5182()) {
- pin = RD88F5182_GPIO_DBG_LED;
+#define RD88F5182_GPIO_LED 0
- if (gpio_request(pin, DBGLED) == 0) {
- if (gpio_direction_output(pin, 0) != 0) {
- printk(KERN_ERR rd88f5182_dbgled_init failed
- to set output pin %d\n, pin);
- gpio_free(pin);
- return 0;
- }
- } else {
- printk(KERN_ERR rd88f5182_dbgled_init failed
- to request gpio %d\n, pin);
- return 0;
- }
-
- leds_event = rd88f5182_dbgled_event;
- }
-
- return 0;
-}
+static struct gpio_led rd88f5182_gpio_led_pins[] = {
+ {
+ .name = rd88f5182:cpu,
+ .default_trigger = cpu0,
+ .gpio = RD88F5182_GPIO_LED,
+ },
+};
-__initcall(rd88f5182_dbgled_init);
+static struct gpio_led_platform_data rd88f5182_gpio_led_data = {
+ .leds = rd88f5182_gpio_led_pins,
+ .num_leds = ARRAY_SIZE(rd88f5182_gpio_led_pins),
+};
-#endif
+static struct platform_device rd88f5182_gpio_leds = {
+ .name = leds-gpio,
+ .id = -1,
+ .dev= {
+ .platform_data = rd88f5182_gpio_led_data,
+ },
+};
/*
* PCI
@@ -299,6 +270,7 @@ static void __init rd88f5182_init(void)
orion5x_setup_dev1_win(RD88F5182_NOR_BASE, RD88F5182_NOR_SIZE);
platform_device_register(rd88f5182_nor_flash);
+ platform_device_register(rd88f5182_gpio_leds);
i2c_register_board_info(0, rd88f5182_i2c_rtc, 1);
}
diff --git a/arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c
b/arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c
index 2c5fab0..e2fd500 100644
--- a/arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c
+++ b/arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c
@@ -21,7 +21,6 @@
#include
[PATCH 08/18] ARM: mach-integrator: retire custom LED code
Use the LED in core module for CPU activity and also enable 4
debugging LEDs in baseboard.
The CPU activity LED is now handled by the trigger in the leds
subsystem, retire this old CONFIG_LEDS-based code.
Signed-off-by: Bryan Wu bryan...@canonical.com
---
arch/arm/mach-integrator/Makefile |3 +-
arch/arm/mach-integrator/core.c |1 -
arch/arm/mach-integrator/leds.c | 158 ++---
3 files changed, 96 insertions(+), 66 deletions(-)
diff --git a/arch/arm/mach-integrator/Makefile
b/arch/arm/mach-integrator/Makefile
index ebeef96..5521d18 100644
--- a/arch/arm/mach-integrator/Makefile
+++ b/arch/arm/mach-integrator/Makefile
@@ -4,11 +4,10 @@
# Object file lists.
-obj-y := core.o lm.o
+obj-y := core.o lm.o leds.o
obj-$(CONFIG_ARCH_INTEGRATOR_AP) += integrator_ap.o
obj-$(CONFIG_ARCH_INTEGRATOR_CP) += integrator_cp.o
-obj-$(CONFIG_LEDS) += leds.o
obj-$(CONFIG_PCI) += pci_v3.o pci.o
obj-$(CONFIG_CPU_FREQ_INTEGRATOR) += cpu.o
obj-$(CONFIG_INTEGRATOR_IMPD1) += impd1.o
diff --git a/arch/arm/mach-integrator/core.c b/arch/arm/mach-integrator/core.c
index 8c53562..0c7c4ef 100644
--- a/arch/arm/mach-integrator/core.c
+++ b/arch/arm/mach-integrator/core.c
@@ -28,7 +28,6 @@
#include mach/cm.h
#include mach/irqs.h
-#include asm/leds.h
#include asm/mach-types.h
#include asm/mach/time.h
#include asm/pgtable.h
diff --git a/arch/arm/mach-integrator/leds.c b/arch/arm/mach-integrator/leds.c
index 466defa..dab912b 100644
--- a/arch/arm/mach-integrator/leds.c
+++ b/arch/arm/mach-integrator/leds.c
@@ -1,90 +1,122 @@
/*
- * linux/arch/arm/mach-integrator/leds.c
+ * Driver for the 4 user LEDs found on the Integrator AP/CP baseboard
+ * Based on Versatile and RealView machine LED code
*
- * Integrator/AP and Integrator/CP LED control routines
- *
- * Copyright (C) 1999 ARM Limited
- * Copyright (C) 2000 Deep Blue Solutions Ltd
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ * License terms: GNU General Public License (GPL) version 2
+ * Author: Bryan Wu bryan...@canonical.com
*/
#include linux/kernel.h
#include linux/init.h
-#include linux/smp.h
-#include linux/spinlock.h
#include linux/io.h
+#include linux/slab.h
+#include linux/leds.h
+#include mach/cm.h
#include mach/hardware.h
#include mach/platform.h
-#include asm/leds.h
-#include asm/mach-types.h
-#include mach/cm.h
-static int saved_leds;
+#define ALPHA_REG __io_address(INTEGRATOR_DBG_BASE)
+#define LEDREG (__io_address(INTEGRATOR_DBG_BASE) + INTEGRATOR_DBG_LEDS_OFFSET)
+
+struct integrator_led {
+ struct led_classdev cdev;
+ u8 mask;
+};
+
+/*
+ * The triggers lines up below will only be used if the
+ * LED triggers are compiled in.
+ */
+static const struct {
+ const char *name;
+ const char *trigger;
+} integrator_leds[] = {
+ { integrator:green0, heartbeat, },
+ { integrator:yellow, },
+ { integrator:red, },
+ { integrator:green1, },
+ { integrator:core_module, cpu0, },
+};
-static void integrator_leds_event(led_event_t ledevt)
+static void integrator_led_set(struct led_classdev *cdev,
+ enum led_brightness b)
{
- unsigned long flags;
- const unsigned int dbg_base = IO_ADDRESS(INTEGRATOR_DBG_BASE);
- unsigned int update_alpha_leds;
+ struct integrator_led *led = container_of(cdev,
+struct integrator_led, cdev);
+ u32 reg = __raw_readl(LEDREG);
- // yup, change the LEDs
- local_irq_save(flags);
- update_alpha_leds = 0;
+ if (b != LED_OFF)
+ reg |= led-mask;
+ else
+ reg = ~led-mask;
- switch(ledevt) {
- case led_idle_start:
- cm_control(CM_CTRL_LED, 0);
- break;
+ while (__raw_readl(ALPHA_REG) 1)
+ cpu_relax();
- case led_idle_end:
- cm_control(CM_CTRL_LED, CM_CTRL_LED);
- break;
+ __raw_writel(reg, LEDREG);
+}
- case led_timer:
- saved_leds ^= GREEN_LED;
- update_alpha_leds = 1;
- break;
+static
[PATCH 09/18] ARM: mach-clps711x: retire custom LED code of P720T machine
Add tigger based LED driver into board file of P720T.
Remove old LED driver file.
Signed-off-by: Bryan Wu bryan...@canonical.com
---
arch/arm/mach-clps711x/Makefile|2 -
arch/arm/mach-clps711x/common.c|1 -
arch/arm/mach-clps711x/include/mach/time.h |2 -
arch/arm/mach-clps711x/p720t-leds.c| 66
arch/arm/mach-clps711x/p720t.c | 59 +
5 files changed, 59 insertions(+), 71 deletions(-)
delete mode 100644 arch/arm/mach-clps711x/p720t-leds.c
diff --git a/arch/arm/mach-clps711x/Makefile b/arch/arm/mach-clps711x/Makefile
index f2f0256..5872b49 100644
--- a/arch/arm/mach-clps711x/Makefile
+++ b/arch/arm/mach-clps711x/Makefile
@@ -16,5 +16,3 @@ obj-$(CONFIG_ARCH_CLEP7312) += clep7312.o
obj-$(CONFIG_ARCH_EDB7211) += edb7211-arch.o edb7211-mm.o
obj-$(CONFIG_ARCH_FORTUNET) += fortunet.o
obj-$(CONFIG_ARCH_P720T)+= p720t.o
-leds-$(CONFIG_ARCH_P720T) += p720t-leds.o
-obj-$(CONFIG_LEDS) += $(leds-y)
diff --git a/arch/arm/mach-clps711x/common.c b/arch/arm/mach-clps711x/common.c
index 3c5b5bb..c9ba167 100644
--- a/arch/arm/mach-clps711x/common.c
+++ b/arch/arm/mach-clps711x/common.c
@@ -31,7 +31,6 @@
#include asm/sizes.h
#include mach/hardware.h
#include asm/irq.h
-#include asm/leds.h
#include asm/pgtable.h
#include asm/page.h
#include asm/mach/map.h
diff --git a/arch/arm/mach-clps711x/include/mach/time.h
b/arch/arm/mach-clps711x/include/mach/time.h
index 61fef91..bafc325 100644
--- a/arch/arm/mach-clps711x/include/mach/time.h
+++ b/arch/arm/mach-clps711x/include/mach/time.h
@@ -17,7 +17,6 @@
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
-#include asm/leds.h
#include asm/hardware/clps7111.h
extern void clps711x_setup_timer(void);
@@ -29,7 +28,6 @@ static irqreturn_t
p720t_timer_interrupt(int irq, void *dev_id)
{
struct pt_regs *regs = get_irq_regs();
- do_leds();
xtime_update(1);
#ifndef CONFIG_SMP
update_process_times(user_mode(regs));
diff --git a/arch/arm/mach-clps711x/p720t-leds.c
b/arch/arm/mach-clps711x/p720t-leds.c
deleted file mode 100644
index dd9a6cd..000
--- a/arch/arm/mach-clps711x/p720t-leds.c
+++ /dev/null
@@ -1,66 +0,0 @@
-/*
- * linux/arch/arm/mach-clps711x/leds.c
- *
- * Integrator LED control routines
- *
- * Copyright (C) 2000 Deep Blue Solutions Ltd
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-#include linux/kernel.h
-#include linux/init.h
-#include linux/io.h
-
-#include mach/hardware.h
-#include asm/leds.h
-#include asm/mach-types.h
-
-#include asm/hardware/clps7111.h
-#include asm/hardware/ep7212.h
-
-static void p720t_leds_event(led_event_t ledevt)
-{
- unsigned long flags;
- u32 pddr;
-
- local_irq_save(flags);
- switch(ledevt) {
- case led_idle_start:
- break;
-
- case led_idle_end:
- break;
-
- case led_timer:
- pddr = clps_readb(PDDR);
- clps_writeb(pddr ^ 1, PDDR);
- break;
-
- default:
- break;
- }
-
- local_irq_restore(flags);
-}
-
-static int __init leds_init(void)
-{
- if (machine_is_p720t())
- leds_event = p720t_leds_event;
-
- return 0;
-}
-
-arch_initcall(leds_init);
diff --git a/arch/arm/mach-clps711x/p720t.c b/arch/arm/mach-clps711x/p720t.c
index 42ee8f3..c782cbf 100644
--- a/arch/arm/mach-clps711x/p720t.c
+++ b/arch/arm/mach-clps711x/p720t.c
@@ -23,6 +23,8 @@
#include linux/string.h
#include linux/mm.h
#include linux/io.h
+#include linux/slab.h
+#include linux/leds.h
#include mach/hardware.h
#include asm/pgtable.h
@@ -34,6 +36,8 @@
#include asm/mach/map.h
#include mach/syspld.h
+#include asm/hardware/clps7111.h
+
#include common.h
/*
@@ -121,3 +125,58 @@ static int p720t_hw_init(void)
__initcall(p720t_hw_init);
+/*
+ * LED controled by CPLD
+ */
+static void p720t_led_set(struct led_classdev *cdev,
+ enum led_brightness b)
+{
+ u8 reg = clps_readb(PDDR);
+
+ if (b != LED_OFF)
+ reg |= 0x1;
+ else
+ reg = ~0x1;
+
+ clps_writeb(reg, PDDR);
+}
+
+static enum
[PATCH 10/18] ARM: mach-ebsa110: retire custom LED code
Signed-off-by: Bryan Wu bryan...@canonical.com
---
arch/arm/mach-ebsa110/Makefile |4 +--
arch/arm/mach-ebsa110/leds.c | 79
2 files changed, 49 insertions(+), 34 deletions(-)
diff --git a/arch/arm/mach-ebsa110/Makefile b/arch/arm/mach-ebsa110/Makefile
index 6520ac8..935e4af 100644
--- a/arch/arm/mach-ebsa110/Makefile
+++ b/arch/arm/mach-ebsa110/Makefile
@@ -4,9 +4,7 @@
# Object file lists.
-obj-y := core.o io.o
+obj-y := core.o io.o leds.o
obj-m :=
obj-n :=
obj- :=
-
-obj-$(CONFIG_LEDS) += leds.o
diff --git a/arch/arm/mach-ebsa110/leds.c b/arch/arm/mach-ebsa110/leds.c
index 99e14e3..b7dd0a5 100644
--- a/arch/arm/mach-ebsa110/leds.c
+++ b/arch/arm/mach-ebsa110/leds.c
@@ -1,52 +1,69 @@
/*
- * linux/arch/arm/mach-ebsa110/leds.c
+ * Driver for the LED found on the EBSA110 machine
+ * Based on Versatile and RealView machine LED code
*
- * Copyright (C) 1998 Russell King
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * EBSA-110 LED control routines. We use the led as follows:
- *
- * - Red - toggles state every 50 timer interrupts
+ * License terms: GNU General Public License (GPL) version 2
+ * Author: Bryan Wu bryan...@canonical.com
*/
-#include linux/module.h
-#include linux/spinlock.h
+#include linux/kernel.h
#include linux/init.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/leds.h
-#include mach/hardware.h
-#include asm/leds.h
#include asm/mach-types.h
#include core.h
-static spinlock_t leds_lock;
-
-static void ebsa110_leds_event(led_event_t ledevt)
+static void ebsa110_led_set(struct led_classdev *cdev,
+ enum led_brightness b)
{
- unsigned long flags;
+ u8 reg = __raw_readb(SOFT_BASE);
- spin_lock_irqsave(leds_lock, flags);
+ if (b != LED_OFF)
+ reg |= 0x80;
+ else
+ reg = ~0x80;
- switch(ledevt) {
- case led_timer:
- *(volatile unsigned char *)SOFT_BASE ^= 128;
- break;
+ __raw_writeb(reg, SOFT_BASE);
+}
- default:
- break;
- }
+static enum led_brightness ebsa110_led_get(struct led_classdev *cdev)
+{
+ u8 reg = __raw_readb(SOFT_BASE);
- spin_unlock_irqrestore(leds_lock, flags);
+ return (reg 0x80) ? LED_FULL : LED_OFF;
}
-static int __init leds_init(void)
+static int __init ebsa110_leds_init(void)
{
- if (machine_is_ebsa110())
- leds_event = ebsa110_leds_event;
+
+ struct led_classdev *cdev;
+ int ret;
+
+ if (!machine_is_ebsa110())
+ return -ENODEV;
+
+ cdev = kzalloc(sizeof(*cdev), GFP_KERNEL);
+ if (!cdev)
+ return -ENOMEM;
+
+ cdev-name = ebsa110:0;
+ cdev-brightness_set = ebsa110_led_set;
+ cdev-brightness_get = ebsa110_led_get;
+ cdev-default_trigger = heartbeat;
+
+ ret = led_classdev_register(NULL, cdev);
+ if (ret 0) {
+ kfree(cdev);
+ return ret;
+ }
return 0;
}
-__initcall(leds_init);
+/*
+ * Since we may have triggers on any subsystem, defer registration
+ * until after subsystem_init.
+ */
+fs_initcall(ebsa110_leds_init);
--
1.7.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/18] ARM: mach-footbridge: retire custom LED code
Signed-off-by: Bryan Wu bryan...@canonical.com
---
arch/arm/mach-footbridge/Makefile |4 -
arch/arm/mach-footbridge/ebsa285-leds.c | 138 -
arch/arm/mach-footbridge/ebsa285.c| 79
arch/arm/mach-footbridge/netwinder-hw.c | 110 ---
arch/arm/mach-footbridge/netwinder-leds.c | 138 -
5 files changed, 175 insertions(+), 294 deletions(-)
delete mode 100644 arch/arm/mach-footbridge/ebsa285-leds.c
delete mode 100644 arch/arm/mach-footbridge/netwinder-leds.c
diff --git a/arch/arm/mach-footbridge/Makefile
b/arch/arm/mach-footbridge/Makefile
index 3afb1b2..0b64dd4 100644
--- a/arch/arm/mach-footbridge/Makefile
+++ b/arch/arm/mach-footbridge/Makefile
@@ -14,15 +14,11 @@ pci-$(CONFIG_ARCH_EBSA285_HOST) += ebsa285-pci.o
pci-$(CONFIG_ARCH_NETWINDER) += netwinder-pci.o
pci-$(CONFIG_ARCH_PERSONAL_SERVER) += personal-pci.o
-leds-$(CONFIG_ARCH_EBSA285) += ebsa285-leds.o
-leds-$(CONFIG_ARCH_NETWINDER) += netwinder-leds.o
-
obj-$(CONFIG_ARCH_CATS) += cats-hw.o isa-timer.o
obj-$(CONFIG_ARCH_EBSA285) += ebsa285.o dc21285-timer.o
obj-$(CONFIG_ARCH_NETWINDER) += netwinder-hw.o isa-timer.o
obj-$(CONFIG_ARCH_PERSONAL_SERVER) += personal.o dc21285-timer.o
obj-$(CONFIG_PCI) +=$(pci-y)
-obj-$(CONFIG_LEDS) +=$(leds-y)
obj-$(CONFIG_ISA) += isa.o isa-rtc.o
diff --git a/arch/arm/mach-footbridge/ebsa285-leds.c
b/arch/arm/mach-footbridge/ebsa285-leds.c
deleted file mode 100644
index 5bd2667..000
--- a/arch/arm/mach-footbridge/ebsa285-leds.c
+++ /dev/null
@@ -1,138 +0,0 @@
-/*
- * linux/arch/arm/mach-footbridge/ebsa285-leds.c
- *
- * Copyright (C) 1998-1999 Russell King
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- * EBSA-285 control routines.
- *
- * The EBSA-285 uses the leds as follows:
- * - Green - toggles state every 50 timer interrupts
- * - Amber - On if system is not idle
- * - Red - currently unused
- *
- * Changelog:
- * 02-05-1999RMK Various cleanups
- */
-#include linux/module.h
-#include linux/kernel.h
-#include linux/init.h
-#include linux/spinlock.h
-
-#include mach/hardware.h
-#include asm/leds.h
-#include asm/mach-types.h
-
-#define LED_STATE_ENABLED 1
-#define LED_STATE_CLAIMED 2
-static char led_state;
-static char hw_led_state;
-
-static DEFINE_SPINLOCK(leds_lock);
-
-static void ebsa285_leds_event(led_event_t evt)
-{
- unsigned long flags;
-
- spin_lock_irqsave(leds_lock, flags);
-
- switch (evt) {
- case led_start:
- hw_led_state = XBUS_LED_RED | XBUS_LED_GREEN;
-#ifndef CONFIG_LEDS_CPU
- hw_led_state |= XBUS_LED_AMBER;
-#endif
- led_state |= LED_STATE_ENABLED;
- break;
-
- case led_stop:
- led_state = ~LED_STATE_ENABLED;
- break;
-
- case led_claim:
- led_state |= LED_STATE_CLAIMED;
- hw_led_state = XBUS_LED_RED | XBUS_LED_GREEN | XBUS_LED_AMBER;
- break;
-
- case led_release:
- led_state = ~LED_STATE_CLAIMED;
- hw_led_state = XBUS_LED_RED | XBUS_LED_GREEN | XBUS_LED_AMBER;
- break;
-
-#ifdef CONFIG_LEDS_TIMER
- case led_timer:
- if (!(led_state LED_STATE_CLAIMED))
- hw_led_state ^= XBUS_LED_GREEN;
- break;
-#endif
-
-#ifdef CONFIG_LEDS_CPU
- case led_idle_start:
- if (!(led_state LED_STATE_CLAIMED))
- hw_led_state |= XBUS_LED_AMBER;
- break;
-
- case led_idle_end:
- if (!(led_state LED_STATE_CLAIMED))
- hw_led_state = ~XBUS_LED_AMBER;
- break;
-#endif
-
- case led_halted:
- if (!(led_state LED_STATE_CLAIMED))
- hw_led_state = ~XBUS_LED_RED;
- break;
-
- case led_green_on:
- if (led_state LED_STATE_CLAIMED)
- hw_led_state = ~XBUS_LED_GREEN;
- break;
-
- case led_green_off:
- if (led_state LED_STATE_CLAIMED)
- hw_led_state |= XBUS_LED_GREEN;
- break;
-
- case led_amber_on:
- if (led_state LED_STATE_CLAIMED)
- hw_led_state = ~XBUS_LED_AMBER;
- break;
-
- case led_amber_off:
- if (led_state LED_STATE_CLAIMED)
- hw_led_state |= XBUS_LED_AMBER;
- break;
-
- case led_red_on:
- if (led_state LED_STATE_CLAIMED)
- hw_led_state = ~XBUS_LED_RED;
- break;
-
- case led_red_off:
- if (led_state LED_STATE_CLAIMED)
- hw_led_state |= XBUS_LED_RED;
[PATCH 12/18] char: nwflash: remove old led event code
Signed-off-by: Bryan Wu bryan...@canonical.com
---
drivers/char/nwflash.c | 34 --
1 files changed, 0 insertions(+), 34 deletions(-)
diff --git a/drivers/char/nwflash.c b/drivers/char/nwflash.c
index d45c334..a0e2f7d 100644
--- a/drivers/char/nwflash.c
+++ b/drivers/char/nwflash.c
@@ -30,7 +30,6 @@
#include asm/hardware/dec21285.h
#include asm/io.h
-#include asm/leds.h
#include asm/mach-types.h
#include asm/uaccess.h
@@ -179,9 +178,6 @@ static ssize_t flash_write(struct file *file, const char
__user *buf,
written = 0;
- leds_event(led_claim);
- leds_event(led_green_on);
-
nBlock = (int) p 16; //block # of 64K bytes
/*
@@ -258,11 +254,6 @@ static ssize_t flash_write(struct file *file, const char
__user *buf,
printk(KERN_DEBUG flash_write: written 0x%X bytes
OK.\n, written);
}
- /*
-* restore reg on exit
-*/
- leds_event(led_release);
-
mutex_unlock(nwflash_mutex);
return written;
@@ -334,11 +325,6 @@ static int erase_block(int nBlock)
int temp, temp1;
/*
-* orange LED == erase
-*/
- leds_event(led_amber_on);
-
- /*
* reset footbridge to the correct offset 0 (...0..3)
*/
*CSR_ROMWRITEREG = 0;
@@ -446,12 +432,6 @@ static int write_block(unsigned long p, const char __user
*buf, int count)
unsigned long timeout;
unsigned long timeout1;
- /*
-* red LED == write
-*/
- leds_event(led_amber_off);
- leds_event(led_red_on);
-
pWritePtr = (unsigned char *) ((unsigned int) (FLASH_BASE + p));
/*
@@ -558,17 +538,9 @@ static int write_block(unsigned long p, const char __user
*buf, int count)
pWritePtr - FLASH_BASE);
/*
-* no LED == waiting
-*/
- leds_event(led_amber_off);
- /*
* wait couple ms
*/
msleep(10);
- /*
-* red LED == write
-*/
- leds_event(led_red_on);
goto WriteRetry;
} else {
@@ -583,12 +555,6 @@ static int write_block(unsigned long p, const char __user
*buf, int count)
}
}
- /*
-* green LED == read/verify
-*/
- leds_event(led_amber_off);
- leds_event(led_green_on);
-
msleep(10);
pWritePtr = (unsigned char *) ((unsigned int) (FLASH_BASE + p));
--
1.7.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/18] ARM: plat-samsung: remove including old leds event API header file
Signed-off-by: Bryan Wu bryan...@canonical.com --- arch/arm/plat-samsung/time.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/plat-samsung/time.c b/arch/arm/plat-samsung/time.c index 4dcb11c..60552e2 100644 --- a/arch/arm/plat-samsung/time.c +++ b/arch/arm/plat-samsung/time.c @@ -28,7 +28,6 @@ #include linux/io.h #include linux/platform_device.h -#include asm/leds.h #include asm/mach-types.h #include asm/irq.h -- 1.7.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/18] ARM: mach-pxa: retire custom LED code
Signed-off-by: Bryan Wu bryan...@canonical.com
---
arch/arm/mach-pxa/Makefile |8 --
arch/arm/mach-pxa/idp.c| 79 +++
arch/arm/mach-pxa/leds-idp.c | 115 -
arch/arm/mach-pxa/leds-lubbock.c | 124
arch/arm/mach-pxa/leds-mainstone.c | 119 --
arch/arm/mach-pxa/leds.c | 32 -
arch/arm/mach-pxa/leds.h | 13
arch/arm/mach-pxa/lubbock.c| 93 +++
arch/arm/mach-pxa/mainstone.c | 92 ++
9 files changed, 264 insertions(+), 411 deletions(-)
delete mode 100644 arch/arm/mach-pxa/leds-idp.c
delete mode 100644 arch/arm/mach-pxa/leds-lubbock.c
delete mode 100644 arch/arm/mach-pxa/leds-mainstone.c
delete mode 100644 arch/arm/mach-pxa/leds.c
delete mode 100644 arch/arm/mach-pxa/leds.h
diff --git a/arch/arm/mach-pxa/Makefile b/arch/arm/mach-pxa/Makefile
index be0f7df..d4337e3 100644
--- a/arch/arm/mach-pxa/Makefile
+++ b/arch/arm/mach-pxa/Makefile
@@ -95,12 +95,4 @@ obj-$(CONFIG_MACH_RAUMFELD_CONNECTOR)+= raumfeld.o
obj-$(CONFIG_MACH_RAUMFELD_SPEAKER)+= raumfeld.o
obj-$(CONFIG_MACH_ZIPIT2) += z2.o
-# Support for blinky lights
-led-y := leds.o
-led-$(CONFIG_ARCH_LUBBOCK) += leds-lubbock.o
-led-$(CONFIG_MACH_MAINSTONE) += leds-mainstone.o
-led-$(CONFIG_ARCH_PXA_IDP) += leds-idp.o
-
-obj-$(CONFIG_LEDS) += $(led-y)
-
obj-$(CONFIG_TOSA_BT) += tosa-bt.o
diff --git a/arch/arm/mach-pxa/idp.c b/arch/arm/mach-pxa/idp.c
index 6ff466b..3c58d95 100644
--- a/arch/arm/mach-pxa/idp.c
+++ b/arch/arm/mach-pxa/idp.c
@@ -191,6 +191,85 @@ static void __init idp_map_io(void)
iotable_init(idp_io_desc, ARRAY_SIZE(idp_io_desc));
}
+/* LEDs */
+struct idp_led {
+ struct led_classdev cdev;
+ u8 mask;
+};
+
+/*
+ * The triggers lines up below will only be used if the
+ * LED triggers are compiled in.
+ */
+static const struct {
+ const char *name;
+ const char *trigger;
+} idp_leds[] = {
+ { idp:green, heartbeat, },
+ { idp:red, cpu0, },
+};
+
+static void idp_led_set(struct led_classdev *cdev,
+ enum led_brightness b)
+{
+ struct idp_led *led = container_of(cdev,
+ struct idp_led, cdev);
+ u32 reg = IDP_CPLD_LED_CONTROL;
+
+ if (b != LED_OFF)
+ reg = ~led-mask;
+ else
+ reg |= led-mask;
+
+ IDP_CPLD_LED_CONTROL = reg;
+}
+
+static enum led_brightness idp_led_get(struct led_classdev *cdev)
+{
+ struct idp_led *led = container_of(cdev,
+ struct idp_led, cdev);
+
+ return (IDP_CPLD_LED_CONTROL led-mask) ? LED_OFF : LED_FULL;
+}
+
+static int __init idp_leds_init(void)
+{
+ int i;
+
+ if (!machine_is_pxa_idp())
+ return -ENODEV;
+
+ for (i = 0; i ARRAY_SIZE(idp_leds); i++) {
+ struct idp_led *led;
+
+ led = kzalloc(sizeof(*led), GFP_KERNEL);
+ if (!led)
+ break;
+
+ led-cdev.name = idp_leds[i].name;
+ led-cdev.brightness_set = idp_led_set;
+ led-cdev.brightness_get = idp_led_get;
+ led-cdev.default_trigger = idp_leds[i].trigger;
+
+ if (i == 0)
+ led-mask = IDP_HB_LED;
+ else
+ led-mask = IDP_BUSY_LED;
+
+ if (led_classdev_register(NULL, led-cdev) 0) {
+ kfree(led);
+ break;
+ }
+ }
+
+ return 0;
+}
+
+/*
+ * Since we may have triggers on any subsystem, defer registration
+ * until after subsystem_init.
+ */
+fs_initcall(idp_leds_init);
MACHINE_START(PXA_IDP, Vibren PXA255 IDP)
/* Maintainer: Vibren Technologies */
diff --git a/arch/arm/mach-pxa/leds-idp.c b/arch/arm/mach-pxa/leds-idp.c
deleted file mode 100644
index 06b0600..000
--- a/arch/arm/mach-pxa/leds-idp.c
+++ /dev/null
@@ -1,115 +0,0 @@
-/*
- * linux/arch/arm/mach-pxa/leds-idp.c
- *
- * Copyright (C) 2000 John Dorsey jo...@cs.cmu.edu
- *
- * Copyright (c) 2001 Jeff Sutherland je...@accelent.com
- *
- * Original (leds-footbridge.c) by Russell King
- *
- * Macros for actual LED manipulation should be in machine specific
- * files in this 'mach' directory.
- */
-
-
-#include linux/init.h
-
-#include mach/hardware.h
-#include asm/leds.h
-
-#include mach/pxa25x.h
-#include mach/idp.h
-
-#include leds.h
-
-#define LED_STATE_ENABLED 1
-#define LED_STATE_CLAIMED 2
-
-static unsigned int led_state;
-static unsigned int hw_led_state;
-
-void idp_leds_event(led_event_t evt)
-{
- unsigned long flags;
-
- local_irq_save(flags);
-
- switch (evt) {
- case led_start:
- hw_led_state = IDP_HB_LED | IDP_BUSY_LED;
-
[PATCH 15/18] ARM: mach-pnx4008: remove including old leds event API header file
Signed-off-by: Bryan Wu bryan...@canonical.com --- arch/arm/mach-pnx4008/time.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-pnx4008/time.c b/arch/arm/mach-pnx4008/time.c index 0cfe8af..47a7ae9 100644 --- a/arch/arm/mach-pnx4008/time.c +++ b/arch/arm/mach-pnx4008/time.c @@ -25,7 +25,6 @@ #include linux/io.h #include mach/hardware.h -#include asm/leds.h #include asm/mach/time.h #include asm/errno.h -- 1.7.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 17/18] ARM: mach-sa1100: retire custom LED code
Signed-off-by: Bryan Wu bryan...@canonical.com
---
arch/arm/mach-sa1100/Makefile |9 ---
arch/arm/mach-sa1100/assabet.c | 83 +
arch/arm/mach-sa1100/badge4.c | 30 +
arch/arm/mach-sa1100/cerf.c | 42 +
arch/arm/mach-sa1100/hackkit.c | 32 ++
arch/arm/mach-sa1100/lart.c | 26
arch/arm/mach-sa1100/leds-assabet.c | 113 ---
arch/arm/mach-sa1100/leds-badge4.c | 110 --
arch/arm/mach-sa1100/leds-cerf.c| 109 -
arch/arm/mach-sa1100/leds-hackkit.c | 111 --
arch/arm/mach-sa1100/leds-lart.c| 100 ---
arch/arm/mach-sa1100/leds.c | 50 ---
arch/arm/mach-sa1100/leds.h | 13
13 files changed, 213 insertions(+), 615 deletions(-)
delete mode 100644 arch/arm/mach-sa1100/leds-assabet.c
delete mode 100644 arch/arm/mach-sa1100/leds-badge4.c
delete mode 100644 arch/arm/mach-sa1100/leds-cerf.c
delete mode 100644 arch/arm/mach-sa1100/leds-hackkit.c
delete mode 100644 arch/arm/mach-sa1100/leds-lart.c
delete mode 100644 arch/arm/mach-sa1100/leds.c
delete mode 100644 arch/arm/mach-sa1100/leds.h
diff --git a/arch/arm/mach-sa1100/Makefile b/arch/arm/mach-sa1100/Makefile
index 60b97ec..1aed9e7 100644
--- a/arch/arm/mach-sa1100/Makefile
+++ b/arch/arm/mach-sa1100/Makefile
@@ -7,21 +7,17 @@ obj-y := clock.o generic.o irq.o time.o #nmi-oopser.o
obj-m :=
obj-n :=
obj- :=
-led-y := leds.o
obj-$(CONFIG_CPU_FREQ_SA1100) += cpu-sa1100.o
obj-$(CONFIG_CPU_FREQ_SA1110) += cpu-sa1110.o
# Specific board support
obj-$(CONFIG_SA1100_ASSABET) += assabet.o
-led-$(CONFIG_SA1100_ASSABET) += leds-assabet.o
obj-$(CONFIG_ASSABET_NEPONSET) += neponset.o
obj-$(CONFIG_SA1100_BADGE4)+= badge4.o
-led-$(CONFIG_SA1100_BADGE4)+= leds-badge4.o
obj-$(CONFIG_SA1100_CERF) += cerf.o
-led-$(CONFIG_SA1100_CERF) += leds-cerf.o
obj-$(CONFIG_SA1100_COLLIE)+= collie.o
@@ -29,13 +25,11 @@ obj-$(CONFIG_SA1100_H3100) += h3100.o h3xxx.o
obj-$(CONFIG_SA1100_H3600) += h3600.o h3xxx.o
obj-$(CONFIG_SA1100_HACKKIT) += hackkit.o
-led-$(CONFIG_SA1100_HACKKIT) += leds-hackkit.o
obj-$(CONFIG_SA1100_JORNADA720)+= jornada720.o
obj-$(CONFIG_SA1100_JORNADA720_SSP)+= jornada720_ssp.o
obj-$(CONFIG_SA1100_LART) += lart.o
-led-$(CONFIG_SA1100_LART) += leds-lart.o
obj-$(CONFIG_SA1100_NANOENGINE)+= nanoengine.o
obj-$(CONFIG_PCI_NANOENGINE) += pci-nanoengine.o
@@ -46,9 +40,6 @@ obj-$(CONFIG_SA1100_SHANNON) += shannon.o
obj-$(CONFIG_SA1100_SIMPAD)+= simpad.o
-# LEDs support
-obj-$(CONFIG_LEDS) += $(led-y)
-
# Miscellaneous functions
obj-$(CONFIG_PM) += pm.o sleep.o
obj-$(CONFIG_SA1100_SSP) += ssp.o
diff --git a/arch/arm/mach-sa1100/assabet.c b/arch/arm/mach-sa1100/assabet.c
index 375d3f7..0e29ec2 100644
--- a/arch/arm/mach-sa1100/assabet.c
+++ b/arch/arm/mach-sa1100/assabet.c
@@ -20,6 +20,8 @@
#include linux/mtd/partitions.h
#include linux/delay.h
#include linux/mm.h
+#include linux/leds.h
+#include linux/slab.h
#include video/sa1100fb.h
@@ -529,6 +531,87 @@ static void __init assabet_map_io(void)
sa1100_register_uart(2, 3);
}
+/* LEDs */
+struct assabet_led {
+ struct led_classdev cdev;
+ u32 mask;
+};
+
+/*
+ * The triggers lines up below will only be used if the
+ * LED triggers are compiled in.
+ */
+static const struct {
+ const char *name;
+ const char *trigger;
+} assabet_leds[] = {
+ { assabet:red, cpu0,},
+ { assabet:green, heartbeat, },
+};
+
+/*
+ * The LED control in Assabet is reversed:
+ * - setting bit means turn off LED
+ * - clearing bit means turn on LED
+ */
+static void assabet_led_set(struct led_classdev *cdev,
+ enum led_brightness b)
+{
+ struct assabet_led *led = container_of(cdev,
+ struct assabet_led, cdev);
+
+ if (b != LED_OFF)
+ ASSABET_BCR_clear(led-mask);
+ else
+ ASSABET_BCR_set(led-mask);
+}
+
+static enum led_brightness assabet_led_get(struct led_classdev *cdev)
+{
+ struct assabet_led *led = container_of(cdev,
+ struct assabet_led, cdev);
+
+ return (ASSABET_BCR led-mask) ? LED_OFF : LED_FULL;
+}
+
+static int __init assabet_leds_init(void)
+{
+ int i;
+
+ if (!machine_is_assabet())
+ return -ENODEV;
+
+ for (i = 0; i ARRAY_SIZE(assabet_leds); i++) {
+ struct assabet_led *led;
+
+ led = kzalloc(sizeof(*led), GFP_KERNEL);
+ if (!led)
+ break;
+
+
[PATCH 18/18] ARM: use new LEDS CPU trigger stub to replace old one
Cc: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Bryan Wu bryan...@canonical.com
---
arch/arm/Kconfig| 53 ---
arch/arm/include/asm/leds.h | 50 --
arch/arm/kernel/Makefile|1 -
arch/arm/kernel/leds.c | 121 ---
arch/arm/kernel/process.c |6 +-
arch/arm/kernel/time.c | 17 --
6 files changed, 3 insertions(+), 245 deletions(-)
delete mode 100644 arch/arm/include/asm/leds.h
delete mode 100644 arch/arm/kernel/leds.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index bd84f2d..3e247a6 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1760,59 +1760,6 @@ config FORCE_MAX_ZONEORDER
This config option is actually maximum order plus one. For example,
a value of 11 means that the largest free memory block is 2^10 pages.
-config LEDS
- bool Timer and CPU usage LEDs
- depends on ARCH_CDB89712 || ARCH_EBSA110 || \
- ARCH_EBSA285 || ARCH_INTEGRATOR || \
- ARCH_LUBBOCK || MACH_MAINSTONE || ARCH_NETWINDER || \
- ARCH_OMAP || ARCH_P720T || ARCH_PXA_IDP || \
- ARCH_SA1100 || ARCH_SHARK || ARCH_VERSATILE || \
- ARCH_AT91 || ARCH_DAVINCI || \
- ARCH_KS8695 || MACH_RD88F5182 || ARCH_REALVIEW
- help
- If you say Y here, the LEDs on your machine will be used
- to provide useful information about your current system status.
-
- If you are compiling a kernel for a NetWinder or EBSA-285, you will
- be able to select which LEDs are active using the options below. If
- you are compiling a kernel for the EBSA-110 or the LART however, the
- red LED will simply flash regularly to indicate that the system is
- still functional. It is safe to say Y here if you have a CATS
- system, but the driver will do nothing.
-
-config LEDS_TIMER
- bool Timer LED if (!ARCH_CDB89712 !ARCH_OMAP) || \
- OMAP_OSK_MISTRAL || MACH_OMAP_H2 \
- || MACH_OMAP_PERSEUS2
- depends on LEDS
- depends on !GENERIC_CLOCKEVENTS
- default y if ARCH_EBSA110
- help
- If you say Y here, one of the system LEDs (the green one on the
- NetWinder, the amber one on the EBSA285, or the red one on the LART)
- will flash regularly to indicate that the system is still
- operational. This is mainly useful to kernel hackers who are
- debugging unstable kernels.
-
- The LART uses the same LED for both Timer LED and CPU usage LED
- functions. You may choose to use both, but the Timer LED function
- will overrule the CPU usage LED.
-
-config LEDS_CPU
- bool CPU usage LED if (!ARCH_CDB89712 !ARCH_EBSA110 \
- !ARCH_OMAP) \
- || OMAP_OSK_MISTRAL || MACH_OMAP_H2 \
- || MACH_OMAP_PERSEUS2
- depends on LEDS
- help
- If you say Y here, the red LED will be used to give a good real
- time indication of CPU usage, by lighting whenever the idle task
- is not currently executing.
-
- The LART uses the same LED for both Timer LED and CPU usage LED
- functions. You may choose to use both, but the Timer LED function
- will overrule the CPU usage LED.
-
config ALIGNMENT_TRAP
bool
depends on CPU_CP15_MMU
diff --git a/arch/arm/include/asm/leds.h b/arch/arm/include/asm/leds.h
deleted file mode 100644
index c545739..000
--- a/arch/arm/include/asm/leds.h
+++ /dev/null
@@ -1,50 +0,0 @@
-/*
- * arch/arm/include/asm/leds.h
- *
- * Copyright (C) 1998 Russell King
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * Event-driven interface for LEDs on machines
- * Added led_start and led_stop- Alex Holden, 28th Dec 1998.
- */
-#ifndef ASM_ARM_LEDS_H
-#define ASM_ARM_LEDS_H
-
-
-typedef enum {
- led_idle_start,
- led_idle_end,
- led_timer,
- led_start,
- led_stop,
- led_claim, /* override idle timer leds */
- led_release,/* restore idle timer leds */
- led_start_timer_mode,
- led_stop_timer_mode,
- led_green_on,
- led_green_off,
- led_amber_on,
- led_amber_off,
- led_red_on,
- led_red_off,
- led_blue_on,
- led_blue_off,
- /*
-* I want this between led_timer and led_start, but
-* someone has decided to export this to user space
-*/
- led_halted
-} led_event_t;
-
-/* Use this routine to handle LEDs */
-
-#ifdef CONFIG_LEDS
-extern void (*leds_event)(led_event_t);
-#else
-#define leds_event(e)
-#endif
-
-#endif
diff --git a/arch/arm/kernel/Makefile
[PATCH 16/18] ARM: mach-omap1: retire custom LED code
Signed-off-by: Bryan Wu bryan...@canonical.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap1/Makefile |8 -
arch/arm/mach-omap1/board-h2.c| 32
arch/arm/mach-omap1/board-h3.c| 32
arch/arm/mach-omap1/board-osk.c | 33
arch/arm/mach-omap1/leds-h2p2-debug.c | 166 ---
arch/arm/mach-omap1/leds-innovator.c | 98 ---
arch/arm/mach-omap1/leds-osk.c| 113 -
arch/arm/mach-omap1/leds.c| 69
arch/arm/mach-omap1/leds.h|3 -
arch/arm/mach-omap1/time.c|1 -
arch/arm/mach-omap1/timer32k.c|1 -
arch/arm/plat-omap/Kconfig|3 +-
arch/arm/plat-omap/debug-leds.c | 293 -
13 files changed, 165 insertions(+), 687 deletions(-)
delete mode 100644 arch/arm/mach-omap1/leds-h2p2-debug.c
delete mode 100644 arch/arm/mach-omap1/leds-innovator.c
delete mode 100644 arch/arm/mach-omap1/leds-osk.c
delete mode 100644 arch/arm/mach-omap1/leds.c
delete mode 100644 arch/arm/mach-omap1/leds.h
diff --git a/arch/arm/mach-omap1/Makefile b/arch/arm/mach-omap1/Makefile
index 9923f92..e63e6e7 100644
--- a/arch/arm/mach-omap1/Makefile
+++ b/arch/arm/mach-omap1/Makefile
@@ -56,14 +56,6 @@ obj-$(CONFIG_ARCH_OMAP850) += gpio7xx.o
obj-$(CONFIG_ARCH_OMAP15XX)+= gpio15xx.o
obj-$(CONFIG_ARCH_OMAP16XX)+= gpio16xx.o
-# LEDs support
-led-$(CONFIG_MACH_OMAP_H2) += leds-h2p2-debug.o
-led-$(CONFIG_MACH_OMAP_H3) += leds-h2p2-debug.o
-led-$(CONFIG_MACH_OMAP_INNOVATOR) += leds-innovator.o
-led-$(CONFIG_MACH_OMAP_PERSEUS2) += leds-h2p2-debug.o
-led-$(CONFIG_MACH_OMAP_OSK)+= leds-osk.o
-obj-$(CONFIG_LEDS) += $(led-y)
-
ifneq ($(CONFIG_FB_OMAP),)
obj-y += lcd_dma.o
endif
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 553a2e5..6a22696 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -31,6 +31,7 @@
#include linux/i2c/tps65010.h
#include linux/smc91x.h
#include linux/omapfb.h
+#include linux/leds.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -324,12 +325,39 @@ static struct platform_device h2_irda_device = {
.resource = h2_irda_resources,
};
+static struct gpio_led h2_gpio_led_pins[] = {
+ {
+ .name = h2:red,
+ .default_trigger = heartbeat,
+ .gpio = 3,
+ },
+ {
+ .name = h2:green,
+ .default_trigger = cpu0,
+ .gpio = OMAP_MPUIO(4),
+ },
+};
+
+static struct gpio_led_platform_data h2_gpio_led_data = {
+ .leds = h2_gpio_led_pins,
+ .num_leds = ARRAY_SIZE(h2_gpio_led_pins),
+};
+
+static struct platform_device h2_gpio_leds = {
+ .name = leds-gpio,
+ .id = -1,
+ .dev= {
+ .platform_data = h2_gpio_led_data,
+ },
+};
+
static struct platform_device *h2_devices[] __initdata = {
h2_nor_device,
h2_nand_device,
h2_smc91x_device,
h2_irda_device,
h2_kp_device,
+ h2_gpio_leds,
};
static void __init h2_init_smc91x(void)
@@ -424,6 +452,10 @@ static void __init h2_init(void)
omap_cfg_reg(E19_1610_KBR4);
omap_cfg_reg(N19_1610_KBR5);
+ /* GPIO based LEDs */
+ omap_cfg_reg(P18_1610_GPIO3);
+ omap_cfg_reg(MPUIO4);
+
h2_smc91x_resources[1].start = gpio_to_irq(0);
h2_smc91x_resources[1].end = gpio_to_irq(0);
platform_add_devices(h2_devices, ARRAY_SIZE(h2_devices));
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index 4c19f4c..4acdc71 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -31,6 +31,7 @@
#include linux/i2c/tps65010.h
#include linux/smc91x.h
#include linux/omapfb.h
+#include linux/leds.h
#include asm/setup.h
#include asm/page.h
@@ -341,6 +342,32 @@ static struct spi_board_info h3_spi_board_info[]
__initdata = {
},
};
+static struct gpio_led h3_gpio_led_pins[] = {
+ {
+ .name = h3:red,
+ .default_trigger = heartbeat,
+ .gpio = 3,
+ },
+ {
+ .name = h3:green,
+ .default_trigger = cpu0,
+ .gpio = OMAP_MPUIO(4),
+ },
+};
+
+static struct gpio_led_platform_data h3_gpio_led_data = {
+ .leds = h3_gpio_led_pins,
+ .num_leds = ARRAY_SIZE(h3_gpio_led_pins),
+};
+
+static struct platform_device h3_gpio_leds = {
+ .name = leds-gpio,
+ .id = -1,
+ .dev= {
+ .platform_data = h3_gpio_led_data,
+ },
+};
+
static struct platform_device *devices[] __initdata = {
nor_device,
nand_device,
@@ -348,6
Re: OMAP4 errata i740
On 3/30/2012 1:20 PM, Shilimkar, Santosh wrote: On Fri, Mar 30, 2012 at 4:47 PM, Archit Tanejaa0393...@ti.com wrote: On Friday 30 March 2012 04:34 PM, Shilimkar, Santosh wrote: On Fri, Mar 30, 2012 at 4:26 PM, Archit Tanejaa0393...@ti.comwrote: On Friday 30 March 2012 03:59 PM, Santosh Shilimkar wrote: On Friday 30 March 2012 03:53 PM, Cousson, Benoit wrote: On 3/30/2012 10:44 AM, Santosh Shilimkar wrote: On Friday 30 March 2012 02:04 PM, Archit Taneja wrote: On Friday 30 March 2012 02:01 PM, Santosh Shilimkar wrote: + Kevin On Friday 30 March 2012 01:56 PM, Tomi Valkeinen wrote: On Fri, 2012-03-30 at 13:51 +0530, Shilimkar, Santosh wrote: On Fri, Mar 30, 2012 at 1:37 PM, Tomi Valkeinentomi.valkei...@ti.comwrote: [...] I had a general PRCM question regarding this. If an initiator is disabled (i.e, clocks are OFF and Power state is OFF), then would the PRCM even care to look at the IdleAck/Mstandby signal of that initiator? Or in other words, look at what the initiator had programmed in it's SYSCONFIG register. If it does consider them, it seems like that's bad HW design! If a PD 9powerdomain) is already in OFF state, that means all the initiators in that PD already has standby asserted. The modules in that PD also have transitioned. Ah, so if DSS was configured as Nostandby, and if we try to disable DSS, it would never transition to OFF, and hence never get disabled correctly, hence giving trouble to PRCM. So just before disabling DSS, we would need to put it to Force standby, and then try to cut the clocks and change the power state. Is this correct? If so, then it's equally messy as the suggested workaround :) Exactly. That's what I mean. You tweak sysconfig or clockdomain, both are messy. Not it's not. We are trying to avoid accessing the sysconfig from the driver, but at least this is a setting local to the IP. And as you said, we have to do that already do to the various bugs here and there on a lot of IPs. Playing with clock domain state from the driver is just not acceptable. if one need to choose between two bad options, I guess sysconifig one is better because that is local to IPs and there is some way today for drivers to manage sysconfig directly. Yes, that's the point. Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP4 errata i740
On 3/30/2012 1:59 PM, Tomi Valkeinen wrote: On Fri, 2012-03-30 at 16:50 +0530, Shilimkar, Santosh wrote: Exactly. That's what I mean. You tweak sysconfig or clockdomain, both are messy. if one need to choose between two bad options, I guess sysconifig one is better because that is local to IPs and there is some way today for drivers to manage sysconfig directly. If the driver touches sysconfig, isn't it possible that hwmod/something just reverts the changes? I mean, sysconfig register is supposedly owned by the arch code, and if the driver modifies it there could be a race condition. No because we had to expose API from hwmod core code to do that already because of various HW bugs. So you will not access it directly but through the hwmod API. The only issue is that these API are exposed today through pdata function pointers, and thus this is not usable in a DT case :-( Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/18] ARM: mach-integrator: move CM_CTRL to header file for accessing by other functions
Signed-off-by: Bryan Wu bryan...@canonical.com
---
arch/arm/mach-integrator/core.c|2 --
arch/arm/mach-integrator/include/mach/cm.h |2 ++
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-integrator/core.c b/arch/arm/mach-integrator/core.c
index eaf6c63..8c53562 100644
--- a/arch/arm/mach-integrator/core.c
+++ b/arch/arm/mach-integrator/core.c
@@ -172,8 +172,6 @@ static struct amba_pl010_data integrator_uart_data = {
.set_mctrl = integrator_uart_set_mctrl,
};
-#define CM_CTRLIO_ADDRESS(INTEGRATOR_HDR_CTRL)
-
static DEFINE_RAW_SPINLOCK(cm_lock);
/**
diff --git a/arch/arm/mach-integrator/include/mach/cm.h
b/arch/arm/mach-integrator/include/mach/cm.h
index 445d57a..1a78692e 100644
--- a/arch/arm/mach-integrator/include/mach/cm.h
+++ b/arch/arm/mach-integrator/include/mach/cm.h
@@ -3,6 +3,8 @@
*/
void cm_control(u32, u32);
+#define CM_CTRLIO_ADDRESS(INTEGRATOR_HDR_CTRL)
+
#define CM_CTRL_LED(1 0)
#define CM_CTRL_nMBDET (1 1)
#define CM_CTRL_REMAP (1 2)
--
1.7.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP4 errata i740
On Fri, 2012-03-30 at 14:02 +0200, Cousson, Benoit wrote: On 3/30/2012 1:59 PM, Tomi Valkeinen wrote: On Fri, 2012-03-30 at 16:50 +0530, Shilimkar, Santosh wrote: Exactly. That's what I mean. You tweak sysconfig or clockdomain, both are messy. if one need to choose between two bad options, I guess sysconifig one is better because that is local to IPs and there is some way today for drivers to manage sysconfig directly. If the driver touches sysconfig, isn't it possible that hwmod/something just reverts the changes? I mean, sysconfig register is supposedly owned by the arch code, and if the driver modifies it there could be a race condition. No because we had to expose API from hwmod core code to do that already because of various HW bugs. So you will not access it directly but through the hwmod API. Ah. What functions would be needed to solve this case? The only issue is that these API are exposed today through pdata function pointers, and thus this is not usable in a DT case :-( That's ok (for now), we will anyway have this omapdss higer level driver, which is not HW driver (i.e. not mentioned in the DT data), but created in arch/arm code. I have put all the current function pointers there already, so I can add a few more. Tomi signature.asc Description: This is a digitally signed message part
Re: OMAP4 errata i740
On Friday 30 March 2012 05:30 PM, Cousson, Benoit wrote: On 3/30/2012 1:20 PM, Shilimkar, Santosh wrote: [..] Playing with clock domain state from the driver is just not acceptable. Sorry for small digration but the clock-domain/power domain APIs were coming in between CPUIDLE code movement to drivers/idle/* How do we deal with that code which is today lying under platform code. 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: Suspend broken on 3.3?
On Fri, Mar 30, 2012 at 4:34 PM, Joe Woodward j...@terrafix.co.uk wrote: -Original Message- From: Raja, Govindraj govindraj.r...@ti.com To: Joe Woodward j...@terrafix.co.uk Cc: Paul Walmsley p...@pwsan.com, Kevin Hilman khil...@ti.com, linux-omap@vger.kernel.org, Felipe Balbi ba...@ti.com, ne...@suse.de Date: Fri, 30 Mar 2012 15:45:19 +0530 Subject: Re: Suspend broken on 3.3? On Fri, Mar 30, 2012 at 2:56 PM, Joe Woodward j...@terrafix.co.uk wrote: ...[snip]... Could you please try attached patch and let me know if this solves the rx issue as well, without using dma mode. Right, I think we've getting closer, but still not quite there... Firstly, the patch adds an include to iomap.h - but this doesn't exist in stock 3.3. Simply removing this include seemed to allow the compile to complete successfully. Sorry I forgot to specify this is needed for latest mainline. With this patch applied (and not in DMA mode) I now get the following: - If I leave wake-from-suspend enabled for the serial port then it works correctly (i.e. no lost/extra 0x00 characters). - If I disable wake-from-suspend for the serial port and go through a suspend cycle (i.e. suspend and then wake), then the serial port starts to misbehave as before. - If I then re-enable wake-from-suspend and go through a suspend cycle it starts to work correctly again. So the problem is still that if wake-from-suspend is disabled for a serial port, and a suspend cycle is performed then when woken the serial port will not function correctly if operating in interrupt-mode. I tried it on my 3430sdp but strangely I don't see a 0x00 char read after disabling uart wakeups and waking up by keypad press. Probably as a quick try we can try doing uart_insert_char only if data was read from rx fifo (Attached patch) Sadly the patch makes no difference. I'm suprised you aren't seeing similar effects. I've done more testing, and a simplified test case is as follows: - take a stock 3.3 kernel and apply your patch to allow disabling of wake-from-suspend for the serial ports. - disable wake-from-suspend for the console tty: echo disable /sys/devices/platform/omap/omap_uart.2/power/wakeup - perform a suspend (you'll need a button or something to wake you now that the console wont). echo mem /sys/power/state At this point the console is noticable/painfully slow. No characters are lost, but it's obvious something isn't right! Yes I see this behavior with console now it becomes very slow after we disable module level wakeups. One difference to note is : in 3.2 = full system PM is prevented in idle path if uart is active i.e, MPU will not hit retention in 3.3 = MPU will hit retention independently of uart is active or not. I think the way to get MPU qos for uart port activity while in irq mode is to use PM_WKEN1 reg settings, meaning enabling module level wakeup event generation. Disabling it is causing this slow response. Checking if we can workaround this scenario. -- Thanks, Govindraj.R -- To unsubscribe from this list: send the line unsubscribe 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: fix build errors: depends on ARCH_OMAP2PLUS
On Mon, Mar 26, 2012 at 05:19:28PM -0700, Kevin Hilman wrote:
The OMAP driver needs a 'depends on ARCH_OMAP2PLUS' since it only
builds for OMAP2+ platforms.
This 'depends on' was in the original patch from Russell King, but was
erroneously removed by me when making this option user-selectable in
commit b09db45c (cpufreq: OMAP driver depends CPUfreq tables.) This
patch remedies that.
Apologies to Russell King for breaking his originally working patch.
Also, thanks to Grazvydas Ignotas for reporting the same problem.
Cc: Russell King rmk+ker...@arm.linux.org.uk
Cc: Grazvydas Ignotas nota...@gmail.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
Dave, this applies on top of your current fixes branch, and fixes a
problem introduced there by me. Please merge for v3.4-rc. Thanks.
Can you please check that you've picked up everything that's necessary,
as I'm still seeing the below as outstanding from my original patch.
commit e55a42528cebb8fa7408dc95abb3859639a46750
Author: Russell King rmk+ker...@arm.linux.org.uk
Date: Wed Feb 15 11:20:51 2012 +
ARM: OMAP: fix cpufreq build
OMAPs cpufreq requires the frequency table support, but nothing ensures
that this is selected. This can result in configurations which fail to
build:
drivers/built-in.o:(.data+0x5238): undefined reference to
`cpufreq_freq_attr_scaling_available_freqs'
drivers/cpufreq/omap-cpufreq.c:88: undefined reference to
`cpufreq_frequency_table_target'
drivers/cpufreq/omap-cpufreq.c:60: undefined reference to
`cpufreq_frequency_table_verify'
drivers/cpufreq/omap-cpufreq.c:186: undefined reference to
`cpufreq_frequency_table_cpuinfo'
drivers/cpufreq/omap-cpufreq.c:190: undefined reference to
`cpufreq_frequency_table_get_attr'
Fix this by introducing a new configuration variable and having that
select CPU_FREQ_TABLE.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
diff --git a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
index 7072e0d..ad35d4e 100644
--- a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
+++ b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
@@ -166,7 +166,7 @@ int omap2_select_table_rate(struct clk *clk, unsigned long
rate)
return 0;
}
-#ifdef CONFIG_CPU_FREQ
+#ifdef CONFIG_ARM_OMAP2PLUS_CPUFREQ
/*
* Walk PRCM rate table and fillout cpufreq freq_table
* XXX This should be replaced by an OPP layer in the near future
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index f57ed5b..450feb0 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -536,7 +536,7 @@ struct clk_functions omap2_clk_functions = {
.clk_set_rate = omap2_clk_set_rate,
.clk_set_parent = omap2_clk_set_parent,
.clk_disable_unused = omap2_clk_disable_unused,
-#ifdef CONFIG_CPU_FREQ
+#ifdef CONFIG_ARM_OMAP2PLUS_CPUFREQ
/* These will be removed when the OPP code is integrated */
.clk_init_cpufreq_table = omap2_clk_init_cpufreq_table,
.clk_exit_cpufreq_table = omap2_clk_exit_cpufreq_table,
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index b8c2a68..f331cfc 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -146,7 +146,7 @@ extern const struct clksel_rate gpt_sys_rates[];
extern const struct clksel_rate gfx_l3_rates[];
extern const struct clksel_rate dsp_ick_rates[];
-#if defined(CONFIG_ARCH_OMAP2) defined(CONFIG_CPU_FREQ)
+#if defined(CONFIG_ARCH_OMAP2) defined(CONFIG_ARM_OMAP2PLUS_CPUFREQ)
extern void omap2_clk_init_cpufreq_table(struct cpufreq_frequency_table
**table);
extern void omap2_clk_exit_cpufreq_table(struct cpufreq_frequency_table
**table);
#else
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 56b6f8b..618cf80 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -398,7 +398,7 @@ struct clk dummy_ck = {
.ops= clkops_null,
};
-#ifdef CONFIG_CPU_FREQ
+#ifdef CONFIG_ARM_OMAP2PLUS_CPUFREQ
void clk_init_cpufreq_table(struct cpufreq_frequency_table **table)
{
unsigned long flags;
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index 240a7b9..879ba27 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -283,7 +283,7 @@ struct clk_functions {
void(*clk_allow_idle)(struct clk *clk);
void(*clk_deny_idle)(struct clk *clk);
void(*clk_disable_unused)(struct clk *clk);
-#ifdef CONFIG_CPU_FREQ
+#ifdef CONFIG_ARM_OMAP2PLUS_CPUFREQ
void(*clk_init_cpufreq_table)(struct
cpufreq_frequency_table **);
void(*clk_exit_cpufreq_table)(struct
cpufreq_frequency_table **);
#endif
@@ -301,7 +301,7 @@ extern void recalculate_root_clocks(void);
extern unsigned long
[PATCH 0/3] OMAP4: CPUidle: Add coupled idle support
The series adds the coupled cpuidle support for OMAP4 based on the v2 series posted [1]. This makes OMAP4 to support SMP cpuidle and also removes the hard dependency of off-lining CPU1 to trigger deeper C-states. I have put together a branch which is based on 3.3 kernel with Len Browns next branch [2] which has time keeping and other cpuidle patches which will mostly get merged by 3.4-rc1 and rebased coupled idle series from [1]. git://gitorious.org/omap-sw-develoment/linux-omap-dev.git for_3.5/omap4_coupled_cpuidle-rebase Special thanks to Kevin Hilman and Colin Cross on their help on this series. Kevin Hilman (1): ARM: OMAP4: CPUidle: add synchronization for coupled idle states Santosh Shilimkar (2): ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus ARM: OMAP4: cpuidle: Use coupled cpuidle states to implement SMP cpuidle. arch/arm/mach-omap2/Kconfig |1 + arch/arm/mach-omap2/cpuidle44xx.c | 187 - arch/arm/mach-omap2/timer.c |4 +- 3 files changed, 124 insertions(+), 68 deletions(-) Regards Santosh [1] http://lwn.net/Articles/486484/ [2] Power Management git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux.git -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: OMAP: timer: allow gp timer clock-event to be used on both cpus
For coupled cpuidle to work when both cpus are active, it needs a global timer
that can handle events for both cpus. This timer is used as the broadcast
clock-event when the per-cpu timer hardware stop in low power states.
Set the cpumask of clockevent_gpt to all cpus, set the rating correctly, and
set the irq to allow the clockevent core to determine the affinity of the
timer.
Signed-off-by: Colin Cross ccr...@android.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/timer.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index fc73567..e33f9c4 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -135,6 +135,7 @@ static struct clock_event_device clockevent_gpt = {
.name = gp timer,
.features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
.shift = 32,
+ .rating = 300,
.set_next_event = omap2_gp_timer_set_next_event,
.set_mode = omap2_gp_timer_set_mode,
};
@@ -225,7 +226,8 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
clockevent_delta2ns(3, clockevent_gpt);
/* Timer internal resynch latency. */
- clockevent_gpt.cpumask = cpumask_of(0);
+ clockevent_gpt.cpumask = cpu_all_mask;
+ clockevent_gpt.irq = omap_dm_timer_get_irq(clkev);
clockevents_register_device(clockevent_gpt);
pr_info(OMAP clockevent source: GPTIMER%d at %lu Hz\n,
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: OMAP4: cpuidle: Use coupled cpuidle states to implement SMP cpuidle.
OMAP4 CPUDILE driver is converted mainly based on notes from the
coupled cpuidle patch series.
The changes include :
- Register both CPUs and C-states to cpuidle driver.
- Set struct cpuidle_device.coupled_cpus
- Set struct cpuidle_device.safe_state to non coupled state.
- Set CPUIDLE_FLAG_COUPLED in struct cpuidle_state.flags for each
state that affects multiple cpus.
- Separate -enter hooks for coupled simple idle.
- CPU0 wait loop for CPU1 power transition.
- CPU1 wakeup mechanism for the idle exit.
- Enabling ARCH_NEEDS_CPU_IDLE_COUPLED for OMAP4.
Thanks to Kevin Hilman and Colin Cross on the suggestions/fixes
on the intermediate version of this patch.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
CC: Kevin Hilman khil...@ti.com
Cc: Colin Cross ccr...@android.com
---
arch/arm/mach-omap2/Kconfig |1 +
arch/arm/mach-omap2/cpuidle44xx.c | 167 ++---
2 files changed, 101 insertions(+), 67 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index e20c8ab..250786e 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -54,6 +54,7 @@ config ARCH_OMAP4
select PM_OPP if PM
select USB_ARCH_HAS_EHCI
select ARM_CPU_SUSPEND if PM
+ select ARCH_NEEDS_CPU_IDLE_COUPLED if CPU_IDLE
comment OMAP Core Type
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index f386cbe..5724393 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -21,6 +21,7 @@
#include common.h
#include pm.h
#include prm.h
+#include clockdomain.h
#ifdef CONFIG_CPU_IDLE
@@ -44,10 +45,11 @@ static struct cpuidle_params cpuidle_params_table[] = {
#define OMAP4_NUM_STATES ARRAY_SIZE(cpuidle_params_table)
struct omap4_idle_statedata omap4_idle_data[OMAP4_NUM_STATES];
-static struct powerdomain *mpu_pd, *cpu0_pd, *cpu1_pd;
+static struct powerdomain *mpu_pd, *cpu_pd[NR_CPUS];
+static struct clockdomain *cpu_clkdm[NR_CPUS];
/**
- * omap4_enter_idle - Programs OMAP4 to enter the specified state
+ * omap4_enter_idle_coupled_[simple/coupled] - OMAP4 cpuidle entry functions
* @dev: cpuidle device
* @drv: cpuidle driver
* @index: the index of state to be entered
@@ -56,34 +58,40 @@ static struct powerdomain *mpu_pd, *cpu0_pd, *cpu1_pd;
* specified low power state selected by the governor.
* Returns the amount of time spent in the low power state.
*/
-static int omap4_enter_idle(struct cpuidle_device *dev,
+static int omap4_enter_idle_simple(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ local_fiq_disable();
+ omap_do_wfi();
+ local_fiq_enable();
+
+ return index;
+}
+
+static int omap4_enter_idle_coupled(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
struct omap4_idle_statedata *cx =
cpuidle_get_statedata(dev-states_usage[index]);
- u32 cpu1_state;
int cpu_id = smp_processor_id();
local_fiq_disable();
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
+
/*
-* CPU0 has to stay ON (i.e in C1) until CPU1 is OFF state.
+* CPU0 has to wait and stay ON until CPU1 is OFF state.
* This is necessary to honour hardware recommondation
* of triggeing all the possible low power modes once CPU1 is
* out of coherency and in OFF mode.
-* Update dev-last_state so that governor stats reflects right
-* data.
*/
- cpu1_state = pwrdm_read_pwrst(cpu1_pd);
- if (cpu1_state != PWRDM_POWER_OFF) {
- index = drv-safe_state_index;
- cx = cpuidle_get_statedata(dev-states_usage[index]);
+ if (dev-cpu == 0) {
+ while (pwrdm_read_pwrst(cpu_pd[1]) != PWRDM_POWER_OFF)
+ cpu_relax();
}
- if (index 0)
- clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
-
/*
* Call idle CPU PM enter notifier chain so that
* VFP and per CPU interrupt context is saved.
@@ -91,25 +99,35 @@ static int omap4_enter_idle(struct cpuidle_device *dev,
if (cx-cpu_state == PWRDM_POWER_OFF)
cpu_pm_enter();
- pwrdm_set_logic_retst(mpu_pd, cx-mpu_logic_state);
- omap_set_pwrdm_state(mpu_pd, cx-mpu_state);
-
- /*
-* Call idle CPU cluster PM enter notifier chain
-* to save GIC and wakeupgen context.
-*/
- if ((cx-mpu_state == PWRDM_POWER_RET)
- (cx-mpu_logic_state == PWRDM_POWER_OFF))
- cpu_cluster_pm_enter();
+ if (dev-cpu == 0) {
+ pwrdm_set_logic_retst(mpu_pd, cx-mpu_logic_state);
+ omap_set_pwrdm_state(mpu_pd, cx-mpu_state);
+
+
[PATCH 3/3] ARM: OMAP4: CPUidle: add synchronization for coupled idle states
From: Kevin Hilman khil...@ti.com
With coupled idle states, a failure for any CPU to hit a low power
state must be coordinated such that all CPUs abort.
On OMAP4, when entering a coupled state, CPU0 has to wait for CPU1 to
enter its low power state before it can enter its low power state.
This is implemented by letting CPU0 wait for the CPU1 powerdomain to
hit off. However, there are conditions where CPU1 might abort/fail
and not hit off while CPU0 is waiting for it. For example, a CPU1
wakeup or a failed attempt to hit off due to hardware conditions.
To avoid the deadlock where CPU0 would continually wait for CPU1 to
hit off-mode, this patch adds a flag to signal when each CPU has come
out of its low-power state. CPU0 then checks whether CPU1 has hit off
*or* has already completed its attempt to hit off. If the latter,
CPU0 must abort its attempt to hit a low-power state so the coupled
state enter method can return.
In addition, cpuidle_coupled_parallel_barrier() is used to ensure the
clearing of the 'done' flag is synchronized on all CPUs.
Cc: Colin Cross ccr...@android.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/cpuidle44xx.c | 22 +-
1 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 5724393..fcf6653 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -48,6 +48,9 @@ struct omap4_idle_statedata omap4_idle_data[OMAP4_NUM_STATES];
static struct powerdomain *mpu_pd, *cpu_pd[NR_CPUS];
static struct clockdomain *cpu_clkdm[NR_CPUS];
+static atomic_t abort_barrier;
+static bool cpu_done[NR_CPUS];
+
/**
* omap4_enter_idle_coupled_[simple/coupled] - OMAP4 cpuidle entry functions
* @dev: cpuidle device
@@ -88,8 +91,20 @@ static int omap4_enter_idle_coupled(struct cpuidle_device
*dev,
* out of coherency and in OFF mode.
*/
if (dev-cpu == 0) {
- while (pwrdm_read_pwrst(cpu_pd[1]) != PWRDM_POWER_OFF)
+ while (pwrdm_read_pwrst(cpu_pd[1]) != PWRDM_POWER_OFF) {
cpu_relax();
+
+ /*
+* CPU1 could have already entered exited idle
+* without hitting off because of a wakeup
+* or a failed attempt to hit off mode. Check for
+* that here, otherwise we could spin forever
+* waiting for CPU1 off.
+*/
+ if (cpu_done[1])
+ goto fail;
+
+ }
}
/*
@@ -113,6 +128,7 @@ static int omap4_enter_idle_coupled(struct cpuidle_device
*dev,
}
omap4_enter_lowpower(dev-cpu, cx-cpu_state);
+ cpu_done[dev-cpu] = true;
if (dev-cpu == 0) {
/* Wakeup CPU1 only if it is not offlined */
@@ -137,6 +153,10 @@ static int omap4_enter_idle_coupled(struct cpuidle_device
*dev,
if (omap4_mpuss_read_prev_context_state())
cpu_cluster_pm_exit();
+fail:
+ cpuidle_coupled_parallel_barrier(dev, abort_barrier);
+ cpu_done[dev-cpu] = false;
+
clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);
local_fiq_enable();
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-V2 0/3] ARM: OMAP: Make OMAP clocksource source selection runtime
Current OMAP code supports couple of clocksource options based on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz) This patch series cleans up the existing 32k-sync timer implementation without any major code change, in order to enable runtime selection between 32k sync-timer and gptimer and adds hwmod lookup for omap2+ devices, if lookup fails then fall back to gp-timer. With this, we should be able to support multi-omap boot including devices with/without 32k-sync timer. For example, AM33xx device doesn't have 32k-sync timer available, which breaks multi-omap boot. This patch-series has been boot tested on AM37xEVM platform, it would be helpful if somebody help me to validate it on OMAP1/2 platforms. Changes from previous submissions: == Changes from V1: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/081037.html - Based on Tony's comment, added pbase size argument to omap_init_clocksource_32k(), to avoid cpu_is_xxx() check. - Added commit description based on discussion on list (Thanks to Santosh here) - Reorder patch sequence Vaibhav Hiremath (3): ARM: OMAP2/3: Add idle_st bits for ST_32KSYNC timer to prcm-common header ARM: OMAP2+: hwmod data: Add 32k-sync timer data to hwmod database ARM: OMAP: Make OMAP clocksource source selection runtime arch/arm/mach-omap1/timer32k.c |6 ++- arch/arm/mach-omap2/omap_hwmod_2420_data.c | 53 + arch/arm/mach-omap2/omap_hwmod_2430_data.c | 52 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 51 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +- arch/arm/mach-omap2/prcm-common.h |4 + arch/arm/mach-omap2/timer.c| 45 -- arch/arm/plat-omap/counter_32k.c | 86 arch/arm/plat-omap/include/plat/common.h |2 +- 9 files changed, 229 insertions(+), 72 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-V2 1/3] ARM: OMAP2/3: Add idle_st bits for ST_32KSYNC timer to prcm-common header
Add missing idle_st bit for 32k-sync timer into the prcm-common header file, required for hwmod data. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Felipe Balbi ba...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Paul Walmsley p...@pwsan.com CC: Santosh Shilimkar santosh.shilim...@ti.com Cc: Ming Lei tom.leim...@gmail.com --- arch/arm/mach-omap2/prcm-common.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/prcm-common.h b/arch/arm/mach-omap2/prcm-common.h index 5aa5435..29955d5 100644 --- a/arch/arm/mach-omap2/prcm-common.h +++ b/arch/arm/mach-omap2/prcm-common.h @@ -177,6 +177,8 @@ /* PM_WKST_WKUP, CM_IDLEST_WKUP shared bits */ #define OMAP24XX_ST_GPIOS_SHIFT2 #define OMAP24XX_ST_GPIOS_MASK (1 2) +#define OMAP24XX_ST_32KSYNC_SHIFT 1 +#define OMAP24XX_ST_32KSYNC_MASK (1 1) #define OMAP24XX_ST_GPT1_SHIFT 0 #define OMAP24XX_ST_GPT1_MASK (1 0) @@ -307,6 +309,8 @@ #define OMAP3430_ST_SR1_MASK (1 6) #define OMAP3430_ST_GPIO1_SHIFT3 #define OMAP3430_ST_GPIO1_MASK (1 3) +#define OMAP3430_ST_32KSYNC_SHIFT 2 +#define OMAP3430_ST_32KSYNC_MASK (1 2) #define OMAP3430_ST_GPT12_SHIFT1 #define OMAP3430_ST_GPT12_MASK (1 1) #define OMAP3430_ST_GPT1_SHIFT 0 -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-V2 2/3] ARM: OMAP2+: hwmod data: Add 32k-sync timer data to hwmod database
Add 32k-sync timer hwmod data to omap2 3 hwmod table
and also enable existing hwmod data for omap4 (was disabled before).
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
CC: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Ming Lei tom.leim...@gmail.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 53
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 52 +++
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 51 ++
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +-
4 files changed, 157 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index a5409ce..2091a5c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -54,6 +54,7 @@ static struct omap_hwmod omap2420_gpio4_hwmod;
static struct omap_hwmod omap2420_dma_system_hwmod;
static struct omap_hwmod omap2420_mcspi1_hwmod;
static struct omap_hwmod omap2420_mcspi2_hwmod;
+static struct omap_hwmod omap2420_counter_32k_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap2420_l3_main__l4_core = {
@@ -1513,6 +1514,55 @@ static struct omap_hwmod omap2420_mcbsp2_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap2420_mcbsp2_slaves),
};
+/*
+ * '32K sync counter' class
+ * 32-bit ordinary counter, clocked by the falling edge of the 32 khz clock
+ */
+static struct omap_hwmod_class omap2420_counter_hwmod_class = {
+ .name = counter,
+};
+
+/* counter_32k */
+static struct omap_hwmod_addr_space omap2420_counter_32k_addrs[] = {
+ {
+ .pa_start = 0x48004000,
+ .pa_end = 0x48004000 + SZ_4K,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* l4_wkup - counter_32k */
+static struct omap_hwmod_ocp_if omap2420_l4_wkup__counter_32k = {
+ .master = omap2420_l4_wkup_hwmod,
+ .slave = omap2420_counter_32k_hwmod,
+ .clk= l4_ck,
+ .addr = omap2420_counter_32k_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* counter_32k slave ports */
+static struct omap_hwmod_ocp_if *omap2420_counter_32k_slaves[] = {
+ omap2420_l4_wkup__counter_32k,
+};
+
+static struct omap_hwmod omap2420_counter_32k_hwmod = {
+ .name = counter_32k,
+ .class = omap2420_counter_hwmod_class,
+ .main_clk = sync_32k_ick,
+ .prcm = {
+ .omap2 = {
+ .module_offs= WKUP_MOD,
+ .prcm_reg_id= 1,
+ .module_bit = OMAP24XX_ST_32KSYNC_SHIFT,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit= OMAP24XX_ST_32KSYNC_SHIFT,
+ },
+ },
+ .slaves = omap2420_counter_32k_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap2420_counter_32k_slaves),
+};
+
static __initdata struct omap_hwmod *omap2420_hwmods[] = {
omap2420_l3_main_hwmod,
omap2420_l4_core_hwmod,
@@ -1565,6 +1615,9 @@ static __initdata struct omap_hwmod *omap2420_hwmods[] = {
/* mcspi class */
omap2420_mcspi1_hwmod,
omap2420_mcspi2_hwmod,
+
+ /* 32k sync timer */
+ omap2420_counter_32k_hwmod,
NULL,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index c4f56cb..f7cc4bb 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -64,6 +64,7 @@ static struct omap_hwmod omap2430_mcspi2_hwmod;
static struct omap_hwmod omap2430_mcspi3_hwmod;
static struct omap_hwmod omap2430_mmc1_hwmod;
static struct omap_hwmod omap2430_mmc2_hwmod;
+static struct omap_hwmod omap2430_counter_32k_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap2430_l3_main__l4_core = {
@@ -2001,6 +2002,55 @@ static struct omap_hwmod omap2430_mmc2_hwmod = {
.class = omap2430_mmc_class,
};
+/*
+ * '32K sync counter' class
+ * 32-bit ordinary counter, clocked by the falling edge of the 32 khz clock
+ */
+static struct omap_hwmod_class omap2430_counter_hwmod_class = {
+ .name = counter,
+};
+
+/* counter_32k */
+static struct omap_hwmod_addr_space omap2430_counter_32k_addrs[] = {
+ {
+ .pa_start = 0x4902,
+ .pa_end = 0x4902 + SZ_4K,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* l4_wkup - counter_32k */
+static struct omap_hwmod_ocp_if omap2430_l4_wkup__counter_32k = {
+ .master = omap2430_l4_wkup_hwmod,
+ .slave = omap2430_counter_32k_hwmod,
+ .clk= l4_ck,
+ .addr
[PATCH-V2 3/3] ARM: OMAP: Make OMAP clocksource source selection runtime
Current OMAP code supports couple of clocksource options based
on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz).
So there can be 3 options -
1. 32KHz sync-timer
2. Sys_clock based (e.g 13/19.2/26/38.4 MHz) gptimer
3. 32KHz based gptimer.
The optional gptimer based clocksource was added so that it can
give the high precision than sync-timer, so expected usage was 2
and not 3.
Unfortunately option 2, clocksource doesn't meet the requirement of
free-running clock as per clocksource need. It stops in low power states
when sys_clock is cut. That makes gptimer based clocksource option
useless for OMAP2/3/4 devices with sys_clock as a clock input.
Option 3 will still work but it is no better than 32K sync-timer
based clocksource.
So ideally we can kill the gptimer based clocksource option but there
are some OMAP based derivative SoCs like AM33XX which doesn't have
32K sync-timer hardware IP and need to fallback on 32KHz based gptimer
clocksource.
Considering above, make sync-timer and gptimer clocksource runtime
selectable so that both OMAP and AM continue to use the same code.
Use hwmod database lookup mechanism, through which at run-time
we can identify availability of 32k-sync timer on the device,
else fall back to gptimer.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
CC: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Ming Lei tom.leim...@gmail.com
---
arch/arm/mach-omap1/timer32k.c |6 ++-
arch/arm/mach-omap2/timer.c | 45 +---
arch/arm/plat-omap/counter_32k.c | 86 -
arch/arm/plat-omap/include/plat/common.h |2 +-
4 files changed, 68 insertions(+), 71 deletions(-)
diff --git a/arch/arm/mach-omap1/timer32k.c b/arch/arm/mach-omap1/timer32k.c
index a2e6d07..3f96a00 100644
--- a/arch/arm/mach-omap1/timer32k.c
+++ b/arch/arm/mach-omap1/timer32k.c
@@ -72,6 +72,7 @@
/* 16xx specific defines */
#define OMAP1_32K_TIMER_BASE 0xfffb9000
+#define OMAP1_32KSYNC_TIMER_BASE 0xfffbc410
#define OMAP1_32K_TIMER_CR 0x08
#define OMAP1_32K_TIMER_TVR0x00
#define OMAP1_32K_TIMER_TCR0x04
@@ -185,7 +186,10 @@ static __init void omap_init_32k_timer(void)
*/
bool __init omap_32k_timer_init(void)
{
- omap_init_clocksource_32k();
+ u32 pbase;
+
+ pbase = cpu_is_omap16xx() ? OMAP1_32KSYNC_TIMER_BASE : NULL;
+ omap_init_clocksource_32k(pbase, SZ_1K);
omap_init_32k_timer();
return true;
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 5c9acea..f35db1a 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -234,21 +234,6 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
}
/* Clocksource code */
-
-#ifdef CONFIG_OMAP_32K_TIMER
-/*
- * When 32k-timer is enabled, don't use GPTimer for clocksource
- * instead, just leave default clocksource which uses the 32k
- * sync counter. See clocksource setup in plat-omap/counter_32k.c
- */
-
-static void __init omap2_gp_clocksource_init(int unused, const char *dummy)
-{
- omap_init_clocksource_32k();
-}
-
-#else
-
static struct omap_dm_timer clksrc;
/*
@@ -280,13 +265,33 @@ static void __init omap2_gp_clocksource_init(int
gptimer_id,
const char *fck_source)
{
int res;
+ struct omap_hwmod *oh;
+ const char *oh_name = counter_32k;
+
+ /*
+* First check for availability for 32k-sync timer.
+*
+* In case of failure in finding 32k_counter module or
+* registering it as clocksource, execution will fallback to
+* gp-timer.
+*/
+ oh = omap_hwmod_lookup(oh_name);
+ if (oh oh-slaves_cnt != 0) {
+ u32 pbase;
+ unsigned long size;
+
+ pbase = oh-slaves[0]-addr-pa_start + 0x10;
+ size = oh-slaves[0]-addr-pa_end -
+ oh-slaves[0]-addr-pa_start;
+ res = omap_init_clocksource_32k(pbase, size);
+ if (!res)
+ return;
+ }
+ /* Fall back to gp-timer code */
res = omap_dm_timer_init_one(clksrc, gptimer_id, fck_source);
BUG_ON(res);
- pr_info(OMAP clocksource: GPTIMER%d at %lu Hz\n,
- gptimer_id, clksrc.rate);
-
__omap_dm_timer_load_start(clksrc,
OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
setup_sched_clock(dmtimer_read_sched_clock, 32, clksrc.rate);
@@ -294,8 +299,10 @@ static void __init omap2_gp_clocksource_init(int
gptimer_id,
if (clocksource_register_hz(clocksource_gpt, clksrc.rate))
pr_err(Could not
Re: [PATCH] cpufreq: OMAP: fix build errors: depends on ARCH_OMAP2PLUS
Russell King - ARM Linux li...@arm.linux.org.uk writes:
On Mon, Mar 26, 2012 at 05:19:28PM -0700, Kevin Hilman wrote:
The OMAP driver needs a 'depends on ARCH_OMAP2PLUS' since it only
builds for OMAP2+ platforms.
This 'depends on' was in the original patch from Russell King, but was
erroneously removed by me when making this option user-selectable in
commit b09db45c (cpufreq: OMAP driver depends CPUfreq tables.) This
patch remedies that.
Apologies to Russell King for breaking his originally working patch.
Also, thanks to Grazvydas Ignotas for reporting the same problem.
Cc: Russell King rmk+ker...@arm.linux.org.uk
Cc: Grazvydas Ignotas nota...@gmail.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
Dave, this applies on top of your current fixes branch, and fixes a
problem introduced there by me. Please merge for v3.4-rc. Thanks.
Can you please check that you've picked up everything that's necessary,
as I'm still seeing the below as outstanding from my original patch.
Yes, all the code you touch below is now removed, and queued by Paul,
but unfortunately, that branch didn't make it in time for v3.4. :(
Paul, maybe you can pull out my cleanup cpufreq leftovers patch and
submit for v3.4-rc?
Thanks,
Kevin
commit e55a42528cebb8fa7408dc95abb3859639a46750
Author: Russell King rmk+ker...@arm.linux.org.uk
Date: Wed Feb 15 11:20:51 2012 +
ARM: OMAP: fix cpufreq build
OMAPs cpufreq requires the frequency table support, but nothing ensures
that this is selected. This can result in configurations which fail to
build:
drivers/built-in.o:(.data+0x5238): undefined reference to
`cpufreq_freq_attr_scaling_available_freqs'
drivers/cpufreq/omap-cpufreq.c:88: undefined reference to
`cpufreq_frequency_table_target'
drivers/cpufreq/omap-cpufreq.c:60: undefined reference to
`cpufreq_frequency_table_verify'
drivers/cpufreq/omap-cpufreq.c:186: undefined reference to
`cpufreq_frequency_table_cpuinfo'
drivers/cpufreq/omap-cpufreq.c:190: undefined reference to
`cpufreq_frequency_table_get_attr'
Fix this by introducing a new configuration variable and having that
select CPU_FREQ_TABLE.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
diff --git a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
index 7072e0d..ad35d4e 100644
--- a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
+++ b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
@@ -166,7 +166,7 @@ int omap2_select_table_rate(struct clk *clk, unsigned
long rate)
return 0;
}
-#ifdef CONFIG_CPU_FREQ
+#ifdef CONFIG_ARM_OMAP2PLUS_CPUFREQ
/*
* Walk PRCM rate table and fillout cpufreq freq_table
* XXX This should be replaced by an OPP layer in the near future
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index f57ed5b..450feb0 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -536,7 +536,7 @@ struct clk_functions omap2_clk_functions = {
.clk_set_rate = omap2_clk_set_rate,
.clk_set_parent = omap2_clk_set_parent,
.clk_disable_unused = omap2_clk_disable_unused,
-#ifdef CONFIG_CPU_FREQ
+#ifdef CONFIG_ARM_OMAP2PLUS_CPUFREQ
/* These will be removed when the OPP code is integrated */
.clk_init_cpufreq_table = omap2_clk_init_cpufreq_table,
.clk_exit_cpufreq_table = omap2_clk_exit_cpufreq_table,
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index b8c2a68..f331cfc 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -146,7 +146,7 @@ extern const struct clksel_rate gpt_sys_rates[];
extern const struct clksel_rate gfx_l3_rates[];
extern const struct clksel_rate dsp_ick_rates[];
-#if defined(CONFIG_ARCH_OMAP2) defined(CONFIG_CPU_FREQ)
+#if defined(CONFIG_ARCH_OMAP2) defined(CONFIG_ARM_OMAP2PLUS_CPUFREQ)
extern void omap2_clk_init_cpufreq_table(struct cpufreq_frequency_table
**table);
extern void omap2_clk_exit_cpufreq_table(struct cpufreq_frequency_table
**table);
#else
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 56b6f8b..618cf80 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -398,7 +398,7 @@ struct clk dummy_ck = {
.ops= clkops_null,
};
-#ifdef CONFIG_CPU_FREQ
+#ifdef CONFIG_ARM_OMAP2PLUS_CPUFREQ
void clk_init_cpufreq_table(struct cpufreq_frequency_table **table)
{
unsigned long flags;
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index 240a7b9..879ba27 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -283,7 +283,7 @@ struct clk_functions {
void(*clk_allow_idle)(struct clk *clk);
void(*clk_deny_idle)(struct clk *clk);
void
Re: [PATCH 05/12] Add dummy smsc911x regulators to cm-t35.
On 03/28/12 19:03, Tony Lindgren wrote: * Igor Grinberg grinb...@compulab.co.il [120327 23:36]: Hi Tony, On 03/27/12 19:28, Tony Lindgren wrote: * Igor Grinberg grinb...@compulab.co.il [120327 08:56]: Hi Russ, This patch works, but can we, please use the attached patch instead? Hmm what's the difference here? Do you have some real controllable regulator for one of the smsc911x instances? Well, the difference here is that those regulators will only be present if the smsc911x controllers are present and their initialization is done along with the controllers. Also, I want to separate the cm-t35 from sb-t35 for future easier refactoring of the sb-t35 code so it can be reused also on cm-t3517. Only vddvario for smsc911x.0 is controllable - connected to VIO, but VIO will never be disabled as it also controls many other devices (DRAM is among them), so I prefer it to be dummy and keep it together with vdd33a. OK thanks for the clarification. Anyways, I take it that you have tested that both smsc911x interfaces work now? Yes, both regulators are registered and found by the smsc911x driver. There is some kind of problem with the smsc911x.1, but it looks unrelated to the patch: OK good to hear. Regarding the following problem.. smsc911x: Driver version 2008-10-21 irq 323: nobody cared (try booting with the irqpoll option) [c001ae6c] (unwind_backtrace+0x0/0xfc) from [c0088960] (__report_bad_irq+0x28/0xbc) [c0088960] (__report_bad_irq+0x28/0xbc) from [c0088bd4] (note_interrupt+0x1e0/0x230) [c0088bd4] (note_interrupt+0x1e0/0x230) from [c0086e48] (handle_irq_event_percpu+0xb0/0x1a0) [c0086e48] (handle_irq_event_percpu+0xb0/0x1a0) from [c0086f74] (handle_irq_event+0x3c/0x5c) [c0086f74] (handle_irq_event+0x3c/0x5c) from [c00895a0] (handle_level_irq+0x90/0xfc) [c00895a0] (handle_level_irq+0x90/0xfc) from [c008699c] (generic_handle_irq+0x38/0x40) [c008699c] (generic_handle_irq+0x38/0x40) from [c02635a0] (gpio_irq_handler+0x1b0/0x20c) [c02635a0] (gpio_irq_handler+0x1b0/0x20c) from [c008699c] (generic_handle_irq+0x38/0x40) [c008699c] (generic_handle_irq+0x38/0x40) from [c0015404] (handle_IRQ+0x38/0x84) [c0015404] (handle_IRQ+0x38/0x84) from [c000865c] (omap3_intc_handle_irq+0x48/0x4c) [c000865c] (omap3_intc_handle_irq+0x48/0x4c) from [c00140c4] (__irq_svc+0x44/0x78) Exception stack(0xcf02de20 to 0xcf02de68) de20: cf02c018 cf02c000 cf02de58 6013 c06739fc 0143 c06739fc de40: 6013 0508 c06739dc 00022d69 cf02de68 cf02b3c0 c04890fc de60: 2013 [c00140c4] (__irq_svc+0x44/0x78) from [c04890fc] (_raw_spin_unlock_irqrestore+0x64/0x68) [c04890fc] (_raw_spin_unlock_irqrestore+0x64/0x68) from [c0087d50] (__setup_irq+0x1b4/0x3d4) [c0087d50] (__setup_irq+0x1b4/0x3d4) from [c00881a0] (request_threaded_irq+0xdc/0x148) [c00881a0] (request_threaded_irq+0xdc/0x148) from [c0482954] (smsc911x_drv_probe+0x350/0x528) [c0482954] (smsc911x_drv_probe+0x350/0x528) from [c02d5a8c] (platform_drv_probe+0x18/0x1c) [c02d5a8c] (platform_drv_probe+0x18/0x1c) from [c02d4580] (really_probe+0x64/0x160) [c02d4580] (really_probe+0x64/0x160) from [c02d46c4] (driver_probe_device+0x48/0x60) [c02d46c4] (driver_probe_device+0x48/0x60) from [c02d4770] (__driver_attach+0x94/0x98) [c02d4770] (__driver_attach+0x94/0x98) from [c02d2ffc] (bus_for_each_dev+0x54/0x80) [c02d2ffc] (bus_for_each_dev+0x54/0x80) from [c02d3730] (bus_add_driver+0xa8/0x2a4) [c02d3730] (bus_add_driver+0xa8/0x2a4) from [c02d4d6c] (driver_register+0x78/0x184) [c02d4d6c] (driver_register+0x78/0x184) from [c0008758] (do_one_initcall+0x34/0x184) [c0008758] (do_one_initcall+0x34/0x184) from [c0613248] (do_basic_setup+0x34/0x40) [c0613248] (do_basic_setup+0x34/0x40) from [c06132b8] (kernel_init+0x64/0xec) [c06132b8] (kernel_init+0x64/0xec) from [c00154cc] (kernel_thread_exit+0x0/0x8) handlers: [c032ea98] smsc911x_irqhandler Disabling IRQ #323 I still haven't had a chance to look into this. Does anyone have a clue? ..care to see if you have OMAP_GPIO_IRQ entry for your board? If so, we're still waiting for the cleanup-fixes branch to get merged that changes things to use gpio_to_irq() instead. Nope, no OMAP_GPIO_IRQ in the board code. Also, the GPIO - IRQ mapping for the smsc911x is done in gpmc-smsc911x.c and it uses gpio_to_irq() already. -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe 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: smsc911x on Gumstix Overo/Tobi doesn't work
Hi, I finally had some time to do more tests on this problem. Findings below. Am 20.03.2012 20:47, schrieb Javier Martinez Canillas: On Tue, Mar 20, 2012 at 3:27 PM, Thomas Klute thomas2.kl...@uni-dortmund.de wrote: Am 19.03.2012 23:51, schrieb Tony Lindgren: * Thomas Klute thomas2.kl...@uni-dortmund.de [120319 09:26]: Am 16.03.2012 20:33, schrieb Tony Lindgren: Hi, * Thomas Klute thomas2.kl...@uni-dortmund.de [120316 05:08]: Hi, I have trouble getting the Ethernet port on a Gumstix Overo with Tobi expansion board to work with current kernel versions. With the latest commit from linux-omap git (b8fe1781ec8bed5e086691a827a6ee11facec2aa), the output from loading the smsc911x driver is as follows: du14:~# modprobe smsc911x [ 254.843811] smsc911x: Driver version 2008-10-21 [ 254.854553] smsc911x: Driver version 2008-10-21 [ 254.859588] _regulator_get: smsc911x.1 supply vdd33a not found, using dummy regulator [ 254.868377] _regulator_get: smsc911x.1 supply vddvario not found, using dummy regulator ip link show does not show any available Ethernet port. The first instance one should work the same way as earlier using fixed regulator in gpmc-smsc911x.c. Is it not working for you somehow? At least it works for me on zoom3. The Tobi board has only one Ethernet port. I know there has been some trouble with changes around smsc911x regulator support and Gumstix Overo in particular. Am I just missing the right regulator in my kernel config or is this a bug? I can test patches in the latter case. The second smsc911x now needs a regulator. For multiple smsc911x instances, we should change things around so no regulator is created if one is passed. Care to test the following patch by passing a fixed regulator from board-overo.c? After applying the patch the Ethernet port works consistently once I had done a cold boot (reboot from the unpatched kernel did not work). Thank you! Hmm but this patch should not change the behaviour for the first smsc911x instance unless you specify a custom regulator.. Did you patch in a custom regulator, or do we have a bug somewhere? Or do you just need to do a cold reset without the patch I posted? You're right, during further tests I found that the problem lies elsewhere: If the Ethernet cable is attached on modprobe, the device works as expected, if not, it's not found (with or without the patch). This means if I boot with the cable disconnected, the device won't show up, but after # modprobe -r smsc911x [attach cable] # modprobe smsc911x it will work. I'd still consider this a bug, but it doesn't seem to be a regulator problem. Hi Thomas, I had the same behavior with the smsc911x chip but on an IGEPv2 board. The problem was when CONFIG_SMSC_PHY=y since the driver for the chip internal PHY enables an energy detect power-down mode. The smsc911x driver probe function tries to software reset the chip but if the cable is unplugged the energy detect puts the chip in a low power mode. Since the chip is not in an operational state the reset fails and hence the driver probe function. If the cable is plugged then then energy is detected, the chip is in an operational state and the reset is successful. I sent a patch a few months ago to fix this issue. The patch disables the energy detect power-down mode before reseting the chip and then it enables again after reset. The commit is: commit 6386994e03ebbe60338ded3d586308a41e81c0dc Author: Javier Martinez Canillas jav...@dowhile0.org Date: Tue Jan 3 13:36:19 2012 + net/smsc911x: Check if PHY is in operational mode before software reset When I fix the issue I only guarded against generation 4 chips (i.e: pdata-generation == 4), but maybe this problem also exists in other SMSC chips (I didn't know since I only had access to specific data-sheets). Also you can try enabling debug in the driver by setting USE_DEBUG to 1 in drivers/net/ethernet/smsc/smsc911x.h and also trying disabling CONFIG_SMSC_PHY, this will use a generic PHY driver that doesn't put the chip in auto power mode. After looking at the code I set USE_DEBUG to 3 to get as much information as possible and tested with and without the SMSC PHY driver. Results: With the Ethernet cable attached, the device is properly initialized with and without the PHY driver (as before). Without the cable, the smsc911x driver can initialize the card only if the smsc PHY driver had not been loaded previously. Unloading the PHY driver is not enough, even a reboot doesn't help. I have to do a cold boot (or attach the cable). I guess this confirms Javier's guess, but there's one catch: If you take a look at the attached logs (both without cable attached), you'll see that the device is recognized a generation 4, so the Javier's workaround should actually be used. I added a log output in the if (pdata-generation == 4) block to be sure, and indeed it is used. Any hints why the reset still
Re: [PATCH-V2 3/3] ARM: OMAP: Make OMAP clocksource source selection runtime
Hi Vaibhav,
On 3/30/2012 8:54, Vaibhav Hiremath wrote:
Current OMAP code supports couple of clocksource options based
on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz).
So there can be 3 options -
1. 32KHz sync-timer
2. Sys_clock based (e.g 13/19.2/26/38.4 MHz) gptimer
3. 32KHz based gptimer.
The optional gptimer based clocksource was added so that it can
give the high precision than sync-timer, so expected usage was 2
and not 3.
Unfortunately option 2, clocksource doesn't meet the requirement of
free-running clock as per clocksource need. It stops in low power states
when sys_clock is cut. That makes gptimer based clocksource option
useless for OMAP2/3/4 devices with sys_clock as a clock input.
Option 3 will still work but it is no better than 32K sync-timer
based clocksource.
So ideally we can kill the gptimer based clocksource option but there
are some OMAP based derivative SoCs like AM33XX which doesn't have
32K sync-timer hardware IP and need to fallback on 32KHz based gptimer
clocksource.
Considering above, make sync-timer and gptimer clocksource runtime
selectable so that both OMAP and AM continue to use the same code.
Use hwmod database lookup mechanism, through which at run-time
we can identify availability of 32k-sync timer on the device,
else fall back to gptimer.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
CC: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tarun Kanti DebBarma tarun.ka...@ti.com
Cc: Ming Lei tom.leim...@gmail.com
---
arch/arm/mach-omap1/timer32k.c |6 ++-
arch/arm/mach-omap2/timer.c | 45 +---
arch/arm/plat-omap/counter_32k.c | 86 -
arch/arm/plat-omap/include/plat/common.h |2 +-
4 files changed, 68 insertions(+), 71 deletions(-)
[...]
@@ -280,13 +265,33 @@ static void __init omap2_gp_clocksource_init(int
gptimer_id,
const char *fck_source)
{
int res;
+ struct omap_hwmod *oh;
+ const char *oh_name = counter_32k;
+
+ /*
+ * First check for availability for 32k-sync timer.
+ *
+ * In case of failure in finding 32k_counter module or
+ * registering it as clocksource, execution will fallback to
+ * gp-timer.
+ */
+ oh = omap_hwmod_lookup(oh_name);
+ if (oh oh-slaves_cnt != 0) {
+ u32 pbase;
+ unsigned long size;
+
+ pbase = oh-slaves[0]-addr-pa_start + 0x10;
+ size = oh-slaves[0]-addr-pa_end -
+ oh-slaves[0]-addr-pa_start;
+ res = omap_init_clocksource_32k(pbase, size);
+ if (!res)
+ return;
If omap_init_clocksource_32k() fails should we also call BUG_ON here?
+ }
+ /* Fall back to gp-timer code */
res = omap_dm_timer_init_one(clksrc, gptimer_id, fck_source);
BUG_ON(res);
- pr_info(OMAP clocksource: GPTIMER%d at %lu Hz\n,
- gptimer_id, clksrc.rate);
-
__omap_dm_timer_load_start(clksrc,
OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
setup_sched_clock(dmtimer_read_sched_clock, 32, clksrc.rate);
@@ -294,8 +299,10 @@ static void __init omap2_gp_clocksource_init(int
gptimer_id,
if (clocksource_register_hz(clocksource_gpt, clksrc.rate))
pr_err(Could not register clocksource %s\n,
clocksource_gpt.name);
+ else
+ pr_info(OMAP clocksource: GPTIMER%d at %lu Hz\n,
+ gptimer_id, clksrc.rate);
}
-#endif
#define OMAP_SYS_TIMER_INIT(name, clkev_nr, clkev_src,
\
clksrc_nr, clksrc_src) \
diff --git a/arch/arm/plat-omap/counter_32k.c
b/arch/arm/plat-omap/counter_32k.c
index 5068fe5..c1af18c 100644
--- a/arch/arm/plat-omap/counter_32k.c
+++ b/arch/arm/plat-omap/counter_32k.c
@@ -35,8 +35,6 @@
*/
static void __iomem *timer_32k_base;
-#define OMAP16XX_TIMER_32K_SYNCHRONIZED 0xfffbc410
-
static u32 notrace omap_32k_read_sched_clock(void)
{
return timer_32k_base ? __raw_readl(timer_32k_base) : 0;
@@ -68,54 +66,42 @@ void read_persistent_clock(struct timespec *ts)
*ts = *tsp;
}
-int __init omap_init_clocksource_32k(void)
+int __init omap_init_clocksource_32k(u32 pbase, unsigned long size)
{
- static char err[] __initdata = KERN_ERR
- %s: can't register clocksource!\n;
-
- if (cpu_is_omap16xx() || cpu_class_is_omap2()) {
- u32 pbase;
- unsigned long size = SZ_4K;
- void __iomem *base;
- struct clk *sync_32k_ick;
[PATCH] iommu: OMAP: device detach on domain destroy
'domain_destroy with devices attached' case isn't yet handled, instead
code assumes that the device was already detached.
If the domain is destroyed the hardware still has access to invalid
pointers to its page table and internal iommu object. In order to
detach the users we need to track devices using the iommu, current
use cases only have one user of iommu per instance. When required
this can evolve to a list with the devices using the iommu_dev.
Reported-by: Joerg Roedel j...@8bytes.org
Reviewed-by: Ohad Ben-Cohen o...@wizery.com
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
drivers/iommu/omap-iommu.c | 32 +++-
1 files changed, 23 insertions(+), 9 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 821062a..e32bd15 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -41,11 +41,13 @@
* @pgtable: the page table
* @iommu_dev: an omap iommu device attached to this domain. only a single
* iommu device can be attached for now.
+ * @dev: Device using this domain.
* @lock: domain lock, should be taken when attaching/detaching
*/
struct omap_iommu_domain {
u32 *pgtable;
struct omap_iommu *iommu_dev;
+ struct device *dev;
spinlock_t lock;
};
@@ -1074,6 +1076,7 @@ omap_iommu_attach_dev(struct iommu_domain *domain, struct
device *dev)
}
omap_domain-iommu_dev = arch_data-iommu_dev = oiommu;
+ omap_domain-dev = dev;
oiommu-domain = domain;
/* temporary workaround */
@@ -1084,19 +1087,16 @@ out:
return ret;
}
-static void omap_iommu_detach_dev(struct iommu_domain *domain,
-struct device *dev)
+static void _omap_iommu_detach_dev(struct omap_iommu_domain *omap_domain,
+ struct device *dev)
{
- struct omap_iommu_domain *omap_domain = domain-priv;
- struct omap_iommu_arch_data *arch_data = dev-archdata.iommu;
struct omap_iommu *oiommu = dev_to_omap_iommu(dev);
-
- spin_lock(omap_domain-lock);
+ struct omap_iommu_arch_data *arch_data = dev-archdata.iommu;
/* only a single device is supported per domain for now */
if (omap_domain-iommu_dev != oiommu) {
dev_err(dev, invalid iommu device\n);
- goto out;
+ return;
}
iopgtable_clear_entry_all(oiommu);
@@ -1104,11 +1104,19 @@ static void omap_iommu_detach_dev(struct iommu_domain
*domain,
omap_iommu_detach(oiommu);
omap_domain-iommu_dev = arch_data-iommu_dev = NULL;
+ omap_domain-dev = NULL;
/* temporary workaround */
clk_disable(oiommu-clk);
+}
-out:
+static void omap_iommu_detach_dev(struct iommu_domain *domain,
+struct device *dev)
+{
+ struct omap_iommu_domain *omap_domain = domain-priv;
+
+ spin_lock(omap_domain-lock);
+ _omap_iommu_detach_dev(omap_domain, dev);
spin_unlock(omap_domain-lock);
}
@@ -1147,13 +1155,19 @@ out:
return -ENOMEM;
}
-/* assume device was already detached */
static void omap_iommu_domain_destroy(struct iommu_domain *domain)
{
struct omap_iommu_domain *omap_domain = domain-priv;
domain-priv = NULL;
+ /*
+* An iommu device is still attached
+* (currently, only one device can be attached) ?
+*/
+ if (omap_domain-iommu_dev)
+ _omap_iommu_detach_dev(omap_domain, omap_domain-dev);
+
kfree(omap_domain-pgtable);
kfree(omap_domain);
}
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain PRM support for AM33XX device
After some healthy discussion, now we have come to the conclusion and decided to handle AM33XX PRM/CM part separately; as AM33XX-PRCM module is different than OMAP3 and OMAP4 architecture. The difference becomes very interesting/weird when it comes to the consistency for register offsets in PRM address space and bit-field offsets inside PRM registers, So along with Powerdomain data and PRM api's required for AM33XX device, this patch series adds, - XXX_RSTST register offset to struct omap_hwmod_omap4_prcm - PWRSTCTRL PWRSTST register offsets to struct powerdomain - Logicretstate and mem_on/ret/pwrst/retst mask to struct powerdomain Testing: This patch series has been boot tested on AM37xEVM and AM335x based BeagleBone community board. Thanks to Paul here...for helping and concluding on this, shortly I will submit similar patch for CM, clockdomain and clock-tree support for AM33xx. This patch-series is created on top of linux-omap/cleanup branch, and also gets applied to linux-omap/master branch. The patches are also available at - https://github.com/hvaibhav/am335x-linux/tree/am335x-prm-cm Changes from previous versions: === From V3: - No code change, only added Voltagedomain patch (from V2 series) to this series. From V1 V2: - Rolled back to my original approach, where AM33xx device was handled separately (RFC version). - As per Paul's comments, added Register offsets bit-fields masks. Vaibhav Hiremath (4): ARM: OMAP3+: am33xx: Add voltage domain data ARM: OMAP3/4: omap_hwmod: Add rstst_off field to struct omap_hwmod_omap4_prcm ARM: OMAP2+: powerdomain: Add offset mask fields to struct powerdomain ARM: OMAP3+: am33xx: Add powerdomain PRM support arch/arm/mach-omap2/Makefile |6 + arch/arm/mach-omap2/io.c |2 + arch/arm/mach-omap2/omap_hwmod.c | 32 ++- arch/arm/mach-omap2/powerdomain.h | 23 ++- arch/arm/mach-omap2/powerdomain33xx.c | 230 arch/arm/mach-omap2/powerdomains33xx_data.c | 185 + arch/arm/mach-omap2/prm-regbits-33xx.h| 357 + arch/arm/mach-omap2/prm33xx.c | 134 + arch/arm/mach-omap2/prm33xx.h | 129 + arch/arm/mach-omap2/voltage.h |1 + arch/arm/mach-omap2/voltagedomains33xx_data.c | 43 +++ arch/arm/plat-omap/include/plat/omap_hwmod.h |2 + 12 files changed, 1139 insertions(+), 5 deletions(-) create mode 100644 arch/arm/mach-omap2/powerdomain33xx.c create mode 100644 arch/arm/mach-omap2/powerdomains33xx_data.c create mode 100644 arch/arm/mach-omap2/prm-regbits-33xx.h create mode 100644 arch/arm/mach-omap2/prm33xx.c create mode 100644 arch/arm/mach-omap2/prm33xx.h create mode 100644 arch/arm/mach-omap2/voltagedomains33xx_data.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-V4 1/4] ARM: OMAP3+: am33xx: Add voltage domain data
Currently dummy voltage domain data is being created
in order to succeed boot process, nothing has been done
w.r.t actual hardware (voltage control).
Also, hook up the AM33XX voltage domain to OMAP framework.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/Makefile |2 +
arch/arm/mach-omap2/io.c |1 +
arch/arm/mach-omap2/voltage.h |1 +
arch/arm/mach-omap2/voltagedomains33xx_data.c | 43 +
4 files changed, 47 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/voltagedomains33xx_data.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 74ae499..8d90f9f 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -99,6 +99,8 @@ obj-$(CONFIG_ARCH_OMAP2) +=
$(voltagedomain-common) \
voltagedomains2xxx_data.o
obj-$(CONFIG_ARCH_OMAP3) += $(voltagedomain-common) \
voltagedomains3xxx_data.o
+obj-$(CONFIG_SOC_OMAPAM33XX) += $(voltagedomain-common) \
+ voltagedomains33xx_data.o
obj-$(CONFIG_ARCH_OMAP4) += $(voltagedomain-common) \
voltagedomains44xx_data.o
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 51d4df8..523fb6d 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -466,6 +466,7 @@ void __init am33xx_init_early(void)
{
omap2_set_globals_am33xx();
omap_common_init_early();
+ am33xx_voltagedomains_init();
omap3xxx_clk_init();
}
#endif
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 16a1b09..a7c43c1 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -156,6 +156,7 @@ int omap_voltage_late_init(void);
extern void omap2xxx_voltagedomains_init(void);
extern void omap3xxx_voltagedomains_init(void);
+extern void am33xx_voltagedomains_init(void);
extern void omap44xx_voltagedomains_init(void);
struct voltagedomain *voltdm_lookup(const char *name);
diff --git a/arch/arm/mach-omap2/voltagedomains33xx_data.c
b/arch/arm/mach-omap2/voltagedomains33xx_data.c
new file mode 100644
index 000..965458d
--- /dev/null
+++ b/arch/arm/mach-omap2/voltagedomains33xx_data.c
@@ -0,0 +1,43 @@
+/*
+ * AM33XX voltage domain data
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+
+#include voltage.h
+
+static struct voltagedomain am33xx_voltdm_mpu = {
+ .name = mpu,
+};
+
+static struct voltagedomain am33xx_voltdm_core = {
+ .name = core,
+};
+
+static struct voltagedomain am33xx_voltdm_rtc = {
+ .name = rtc,
+};
+
+static struct voltagedomain *voltagedomains_am33xx[] __initdata = {
+ am33xx_voltdm_mpu,
+ am33xx_voltdm_core,
+ am33xx_voltdm_rtc,
+ NULL,
+};
+
+void __init am33xx_voltagedomains_init(void)
+{
+ voltdm_init(voltagedomains_am33xx);
+}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-V4 2/4] ARM: OMAP3/4: omap_hwmod: Add rstst_off field to struct omap_hwmod_omap4_prcm
In case of AM33XX device, XXX_RSTST register offset is not
consistent across PRM modules/instances,
PRM_XXXRSTST
=
PRM_PER_MOD: 0x04
PRM_WKUP_MOD: 0x0C
PRM_MPU_MOD: NA
PRM_DEVICE_MOD:0x08
This means, we need to pass on XXX_RSTST register offset
information through omap_hwmod data, similar to XXX_RSTCTRL.
Currently, this field is only applicable and used for AM33XX
devices.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
---
arch/arm/plat-omap/include/plat/omap_hwmod.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 9ae87eb..50f42ec 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -374,11 +374,13 @@ struct omap_hwmod_omap2_prcm {
* struct omap_hwmod_omap4_prcm - OMAP4-specific PRCM data
* @clkctrl_reg: PRCM address of the clock control register
* @rstctrl_reg: address of the XXX_RSTCTRL register located in the PRM
+ * @rstst_reg: (AM33XX Only) address of the XXX_RSTST register located in the
PRM
* @submodule_wkdep_bit: bit shift of the WKDEP range
*/
struct omap_hwmod_omap4_prcm {
u16 clkctrl_offs;
u16 rstctrl_offs;
+ u16 rstst_offs;
u16 context_offs;
u8 submodule_wkdep_bit;
u8 modulemode;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-V4 3/4] ARM: OMAP2+: powerdomain: Add offset mask fields to struct powerdomain
In case of AM33xx family of devices, there is no consistency between
PWRSTCTRL PWRSTST register offsers in PRM space, for example -
PRM_XXX PWRSTCTRL PWRSTST
===
PRM_PER_MOD: 0x0C, 0x08
PRM_WKUP_MOD: 0x04, 0x08
PRM_MPU_MOD: 0x00, 0x04
PRM_DEVICE_MOD: NA, NA
And also, there is no consistency between bit-offsets inside
PWRSTCTRL PWRSTST register, for example -
PRM_XXX LOGICRET MEMON MEMRET
===
GFX_PWRCTRL: 2,17,6
PER_PWRCTRL: 3,25,29
MPU_PWRCTRL: 2,18,22
WKUP_PWRCTRL: 3,NA,NA
This means, we need to maintain and pass on all this information
in powerdomain handle; so adding fields for,
- PWRSTCTRL/ST register offset
- Logic retention state mask
- mem_on/ret/pwrst/retst mask
Currently, this fields is only applicable and used for AM33XX devices.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/powerdomain.h | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index 0d72a8a..8fc50b2 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -92,6 +92,15 @@ struct powerdomain;
* @pwrdm_clkdms: Clockdomains in this powerdomain
* @node: list_head linking all powerdomains
* @voltdm_node: list_head linking all powerdomains in a voltagedomain
+ * @pwrstctrl_offs: (AM33XX only) XXX_PWRSTCTRL reg offset from prcm_offs
+ * @pwrstst_offs: (AM33XX only) XXX_PWRSTST reg offset from prcm_offs
+ * @logicretstate_mask: (AM33XX only) mask for logic retention bitfield
+ * in @pwrstctrl_offs
+ * @mem_on_mask: (AM33XX only) mask for mem on bitfield in @pwrstctrl_offs
+ * @mem_ret_mask: (AM33XX only) mask for mem retention bitfield in
@pwrstctrl_offs
+ * @mem_pwrst_mask: (AM33XX only) mask for mem state bitfield in @pwrstst_offs
+ * @mem_retst_mask: (AM33XX only) mask for mem retention state bitfield
+ * in @pwrstctrl_offs
* @state:
* @state_counter:
* @timer:
@@ -121,6 +130,14 @@ struct powerdomain {
unsigned ret_logic_off_counter;
unsigned ret_mem_off_counter[PWRDM_MAX_MEM_BANKS];
+ const u8 pwrstctrl_offs;
+ const u8 pwrstst_offs;
+ const u32 logicretstate_mask;
+ const u32 mem_on_mask[PWRDM_MAX_MEM_BANKS];
+ const u32 mem_ret_mask[PWRDM_MAX_MEM_BANKS];
+ const u32 mem_pwrst_mask[PWRDM_MAX_MEM_BANKS];
+ const u32 mem_retst_mask[PWRDM_MAX_MEM_BANKS];
+
#ifdef CONFIG_PM_DEBUG
s64 timer;
s64 state_timer[PWRDM_MAX_PWRSTS];
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-V4 4/4] ARM: OMAP3+: am33xx: Add powerdomain PRM support
As far as PRM/CM/PRCM modules are concerned, AM33XX device is
different than OMAP3 and OMAP4 architectures; so we need to
handle it separately.
This patch adds support for, Powerdomain, Powerdomain data,
PRM api's required for AM33XX device.
And also, hooks up AM33XX powerdomain to existing OMAP framework.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/Makefile|4 +
arch/arm/mach-omap2/io.c|1 +
arch/arm/mach-omap2/omap_hwmod.c| 32 +++-
arch/arm/mach-omap2/powerdomain.h |6 +-
arch/arm/mach-omap2/powerdomain33xx.c | 230 +
arch/arm/mach-omap2/powerdomains33xx_data.c | 185 ++
arch/arm/mach-omap2/prm-regbits-33xx.h | 357 +++
arch/arm/mach-omap2/prm33xx.c | 134 ++
arch/arm/mach-omap2/prm33xx.h | 129 ++
9 files changed, 1073 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/mach-omap2/powerdomain33xx.c
create mode 100644 arch/arm/mach-omap2/powerdomains33xx_data.c
create mode 100644 arch/arm/mach-omap2/prm-regbits-33xx.h
create mode 100644 arch/arm/mach-omap2/prm33xx.c
create mode 100644 arch/arm/mach-omap2/prm33xx.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 8d90f9f..8220369 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -114,6 +114,10 @@ obj-$(CONFIG_ARCH_OMAP3) +=
$(powerdomain-common) \
powerdomain2xxx_3xxx.o \
powerdomains3xxx_data.o \
powerdomains2xxx_3xxx_data.o
+obj-$(CONFIG_SOC_OMAPAM33XX) += $(powerdomain-common) \
+ prm33xx.o \
+ powerdomain33xx.o \
+ powerdomains33xx_data.o
obj-$(CONFIG_ARCH_OMAP4) += $(powerdomain-common) \
powerdomain44xx.o \
powerdomains44xx_data.o
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 523fb6d..b8fd170 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -467,6 +467,7 @@ void __init am33xx_init_early(void)
omap2_set_globals_am33xx();
omap_common_init_early();
am33xx_voltagedomains_init();
+ am33xx_powerdomains_init();
omap3xxx_clk_init();
}
#endif
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5192cab..97b47f2 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -150,6 +150,7 @@
#include cminst44xx.h
#include prm2xxx_3xxx.h
#include prm44xx.h
+#include prm33xx.h
#include prminst44xx.h
#include mux.h
@@ -1288,7 +1289,15 @@ static int _assert_hardreset(struct omap_hwmod *oh,
const char *name)
if (IS_ERR_VALUE(ret))
return ret;
- if (cpu_is_omap24xx() || cpu_is_omap34xx())
+ /*
+* cpu_is_omap34xx() is true for am33xx device as well, so
+* fist check for cpu_is_am33xx().
+*/
+ if (cpu_is_am33xx())
+ return am33xx_prm_assert_hardreset(ohri.rst_shift,
+ oh-clkdm-pwrdm.ptr-prcm_offs,
+ oh-prcm.omap4.rstctrl_offs);
+ else if (cpu_is_omap24xx() || cpu_is_omap34xx())
return omap2_prm_assert_hardreset(oh-prcm.omap2.module_offs,
ohri.rst_shift);
else if (cpu_is_omap44xx())
@@ -1322,7 +1331,16 @@ static int _deassert_hardreset(struct omap_hwmod *oh,
const char *name)
if (IS_ERR_VALUE(ret))
return ret;
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
+ /*
+* cpu_is_omap34xx() is true for am33xx device as well, so
+* fist check for cpu_is_am33xx().
+*/
+ if (cpu_is_am33xx()) {
+ return am33xx_prm_deassert_hardreset(ohri.rst_shift,
+ oh-clkdm-pwrdm.ptr-prcm_offs,
+ oh-prcm.omap4.rstctrl_offs,
+ oh-prcm.omap4.rstst_offs);
+ } else if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
ret = omap2_prm_deassert_hardreset(oh-prcm.omap2.module_offs,
ohri.rst_shift,
ohri.st_shift);
@@ -1364,7 +1382,15 @@ static int _read_hardreset(struct omap_hwmod *oh, const
char *name)
if (IS_ERR_VALUE(ret))
return ret;
- if (cpu_is_omap24xx() ||
Re: [PATCH 03/17] ARM: mark const init data with __initconst instead of __initdata
* Uwe Kleine-König u.kleine-koe...@pengutronix.de [120329 14:16]: As long as there is no other non-const variable marked __initdata in the same compilation unit it doesn't hurt. If there were one however compilation would fail with error: $variablename causes a section type conflict because a section containing const variables is marked read only and so cannot contain non-const variables. Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V4 0/4] ARM: OMAP2+: Add voltagedomain, powerdomain PRM support for AM33XX device
On Fri, Mar 30, 2012 at 21:33:51, Hiremath, Vaibhav wrote: After some healthy discussion, now we have come to the conclusion and decided to handle AM33XX PRM/CM part separately; as AM33XX-PRCM module is different than OMAP3 and OMAP4 architecture. The difference becomes very interesting/weird when it comes to the consistency for register offsets in PRM address space and bit-field offsets inside PRM registers, So along with Powerdomain data and PRM api's required for AM33XX device, this patch series adds, - XXX_RSTST register offset to struct omap_hwmod_omap4_prcm - PWRSTCTRL PWRSTST register offsets to struct powerdomain - Logicretstate and mem_on/ret/pwrst/retst mask to struct powerdomain Testing: This patch series has been boot tested on AM37xEVM and AM335x based BeagleBone community board. Thanks to Paul here...for helping and concluding on this, shortly I will submit similar patch for CM, clockdomain and clock-tree support for AM33xx. This patch-series is created on top of linux-omap/cleanup branch, and also gets applied to linux-omap/master branch. The patches are also available at - https://github.com/hvaibhav/am335x-linux/tree/am335x-prm-cm Please use am335x-upstream-staging branch, to able to boot on BeagleBone board, due to missing clock hwmod data. I am in the process of submitting these patches. Thanks, Vaibhav -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM3517evm
On Fri, Mar 30, 2012 at 11:44:09AM +0200, Yegor Yefremov wrote: Am 29.03.2012 16:59, schrieb Yegor Yefremov: Am 15.03.2012 17:52, schrieb Mark A. Greer: On Thu, Mar 15, 2012 at 09:42:21AM -0700, Mark A. Greer wrote: On Thu, Mar 15, 2012 at 04:52:40PM +0100, Yegor Yefremov wrote: Am 15.03.2012 16:43, schrieb Mark A. Greer: On Mon, Mar 12, 2012 at 02:55:02PM +0100, Yegor Yefremov wrote: Am 09.03.2012 18:22, schrieb George C. Huntington, III: I would like to make the newer kernel (3.x) work with the AM3517EVM. I have a 2.6.32 and a 2.6.33 that run well on the board, but the recent kernels have kernel panics before even running init. where should I start? is there a better place to pursue this? Have you tried this one? http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=summary I have this one booting one month ago, but I checked out the kernel today and it hangs somewhere: Starting kernel ... Uncompressing Linux... done, booting the kernel. This looks like you have your console device set to ttyS2 instead of ttyO2. Which branch of that repository did you use? My kernel params: CONFIG_CMDLINE=root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 and I force them, so bootloader has nothing to say. I'm using master branch. I just booted the latest master branch (b8fe178) with the hack below. (Kernel command line: console=ttyO2,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait) I meant to add that I booted an am3517evm. Is frame buffer working? I can boot with the latest linux-omap version, but as soon as I enable omapfb, kernel freezes before making any output to the serial console. Have I missed some DSS/DPI patches? [Sorry for the delay. I didn't notice your email until now.] After some research I found out that only the master branch is broken. At least rc7 is O.K.: git checkout v3.3-rc7 master freezes: git checkout origin/master I'm not sure what you're trying to say here. According to commit log (http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=commitdiff;h=b8fe1781ec8bed5e086691a827a6ee11facec2aa), there is nothing suspicious. Its not necessarily that commit. It could be any commit between v3.3-rc7 and the current one (including the current one). How can I see the real difference between v3.3-rc7 and master branch? Is this command sufficient? git diff v3.3-rc7..origin/master Yes, that will show the actual diff. Another way to view it would be to use gitk or qgit (or ...) to see the commits that have been applied since v3.3-rc7. Mark -- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP TWL4030/TPS65950 power off
Greetings, In one of the older Kernels, there was a twl4030-poweroff driver that provided a hook to shutdown the OMAP when the poweroff or shutdown -h now command was issued in Linux. This also put the TWL4030/TPS65950 into it's power on state awaiting a press of the power button. My most recent experience with this functionality working is with a 2.6.32 Kernel. I'm trying to get this functionality going with a 3.1.10 Kernel. I've brought over the same twl4030-poweroff driver, but now the system just crashes during shutdown as opposed to nice going down. The file 'drivers/mfd/twl4030-power.c' does define the PWR_P1_SW_EVENTS and PWR_DEVOFF bit, but the PWR_DEVOFF bit is never used to turn the system off, why is it even defined and what is the right way of turning of the system now? -- Ashwin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: defconfig for panda
Hi, * Kumar Gala ga...@kernel.crashing.org [120329 12:24]: As I'm new to the OMAP community this might be a stupid question but trying to just build and run a stock v3.3 kernel on a pandaboard. In doing so it seems as if some basic drivers are not enabled in omap2plus_defconfig for the board. I'm trying to figure out if this is normal for some reason or just an oversight. For example, USB and USB ethernet (SMC95xx). I notice the linaro kernel tree introduces an omap4_defconfig, so just wondering should I send patches to omap2plus_defconfig or what? We can add those to omap2plus_defconfig for sure, but let's have them added as modules. Then distros can use that easily in a standard way using initramfs-tools etc. Let's not change the drivers that are currently built in if they're needed for mounting mmc or nfsroot. Those can be changed later on. 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: OMAP TWL4030/TPS65950 power off
Hi Ashwin, On 03/30/12 21:04, Ashwin Bihari wrote: Greetings, In one of the older Kernels, there was a twl4030-poweroff driver that provided a hook to shutdown the OMAP when the poweroff or shutdown -h now command was issued in Linux. This also put the TWL4030/TPS65950 into it's power on state awaiting a press of the power button. My most recent experience with this functionality working is with a 2.6.32 Kernel. Probably, not the mainline kernel... I'm trying to get this functionality going with a 3.1.10 Kernel. I've brought over the same twl4030-poweroff driver, but now the system just crashes during shutdown as opposed to nice going down. The power off functionality of the TWL4030 is split in two phases: 1) capturing the interrupt and propagating it through the input event handler to the userspace (drivers/input/misc/twl4030-pwrbutton.c) - this is already available in v3.1.10 stable kernel. 2) overriding the pm_power_off method with TWL4030 specific implementation (drivers/mfd/twl4030-power.c) available since: # git describe 26cc3ab984cd00e95cb58ba5aaea4238ea56c700 v3.2-36-g26cc3ab To get that working, you need: 1) the CONFIG_INPUT_TWL4030_PWRBUTTON enabled in the kernel config 2) git cherry-pick 26cc3ab984cd00e95cb58ba5aaea4238ea56c700 3) add struct twl4030_power_data to your board file and set use_poweroff field, here is an example: http://www.spinics.net/lists/linux-omap/msg67280.html The file 'drivers/mfd/twl4030-power.c' does define the PWR_P1_SW_EVENTS and PWR_DEVOFF bit, but the PWR_DEVOFF bit is never used to turn the system off, why is it even defined and what is the right way of turning of the system now? If you experience problems with the above proposed solution, please, post console logs and may be also some debug output. Also, why can't you try it on 3.3 kernel? -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: OMAP4: cpuidle: Use coupled cpuidle states to implement SMP cpuidle.
On Fri, Mar 30, 2012 at 6:27 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
OMAP4 CPUDILE driver is converted mainly based on notes from the
coupled cpuidle patch series.
The changes include :
- Register both CPUs and C-states to cpuidle driver.
- Set struct cpuidle_device.coupled_cpus
- Set struct cpuidle_device.safe_state to non coupled state.
- Set CPUIDLE_FLAG_COUPLED in struct cpuidle_state.flags for each
state that affects multiple cpus.
- Separate -enter hooks for coupled simple idle.
- CPU0 wait loop for CPU1 power transition.
- CPU1 wakeup mechanism for the idle exit.
- Enabling ARCH_NEEDS_CPU_IDLE_COUPLED for OMAP4.
Thanks to Kevin Hilman and Colin Cross on the suggestions/fixes
on the intermediate version of this patch.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
CC: Kevin Hilman khil...@ti.com
Cc: Colin Cross ccr...@android.com
---
arch/arm/mach-omap2/Kconfig | 1 +
arch/arm/mach-omap2/cpuidle44xx.c | 167
++---
2 files changed, 101 insertions(+), 67 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index e20c8ab..250786e 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -54,6 +54,7 @@ config ARCH_OMAP4
select PM_OPP if PM
select USB_ARCH_HAS_EHCI
select ARM_CPU_SUSPEND if PM
+ select ARCH_NEEDS_CPU_IDLE_COUPLED if CPU_IDLE
The if CPU_IDLE is not necessary, ARCH_NEEDS_CPU_IDLE_COUPLED is
designed to have no effect if CPU_IDLE is not set.
comment OMAP Core Type
depends on ARCH_OMAP2
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index f386cbe..5724393 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -21,6 +21,7 @@
#include common.h
#include pm.h
#include prm.h
+#include clockdomain.h
#ifdef CONFIG_CPU_IDLE
@@ -44,10 +45,11 @@ static struct cpuidle_params cpuidle_params_table[] = {
#define OMAP4_NUM_STATES ARRAY_SIZE(cpuidle_params_table)
struct omap4_idle_statedata omap4_idle_data[OMAP4_NUM_STATES];
-static struct powerdomain *mpu_pd, *cpu0_pd, *cpu1_pd;
+static struct powerdomain *mpu_pd, *cpu_pd[NR_CPUS];
+static struct clockdomain *cpu_clkdm[NR_CPUS];
/**
- * omap4_enter_idle - Programs OMAP4 to enter the specified state
+ * omap4_enter_idle_coupled_[simple/coupled] - OMAP4 cpuidle entry functions
* @dev: cpuidle device
* @drv: cpuidle driver
* @index: the index of state to be entered
@@ -56,34 +58,40 @@ static struct powerdomain *mpu_pd, *cpu0_pd, *cpu1_pd;
* specified low power state selected by the governor.
* Returns the amount of time spent in the low power state.
*/
-static int omap4_enter_idle(struct cpuidle_device *dev,
+static int omap4_enter_idle_simple(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ local_fiq_disable();
+ omap_do_wfi();
+ local_fiq_enable();
+
+ return index;
+}
+
+static int omap4_enter_idle_coupled(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
struct omap4_idle_statedata *cx =
cpuidle_get_statedata(dev-states_usage[index]);
- u32 cpu1_state;
int cpu_id = smp_processor_id();
local_fiq_disable();
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
+
/*
- * CPU0 has to stay ON (i.e in C1) until CPU1 is OFF state.
+ * CPU0 has to wait and stay ON until CPU1 is OFF state.
* This is necessary to honour hardware recommondation
* of triggeing all the possible low power modes once CPU1 is
* out of coherency and in OFF mode.
- * Update dev-last_state so that governor stats reflects right
- * data.
*/
- cpu1_state = pwrdm_read_pwrst(cpu1_pd);
- if (cpu1_state != PWRDM_POWER_OFF) {
- index = drv-safe_state_index;
- cx = cpuidle_get_statedata(dev-states_usage[index]);
+ if (dev-cpu == 0) {
+ while (pwrdm_read_pwrst(cpu_pd[1]) != PWRDM_POWER_OFF)
+ cpu_relax();
If something goes wrong in the core coupled code or in the cpu 1 power
state transition, this will hang forever and be hard to debug. It
might be worth adding a timeout with a BUG_ON.
}
- if (index 0)
- clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
-
/*
* Call idle CPU PM enter notifier chain so that
* VFP and per CPU interrupt context is saved.
@@ -91,25 +99,35 @@ static int omap4_enter_idle(struct cpuidle_device *dev,
if (cx-cpu_state == PWRDM_POWER_OFF)
cpu_pm_enter();
This should never get called without cpu_state == PWRDM_POWER_OFF, and
even if it did,
[PATCH v2 02/15] ARM: mark const init data with __initconst instead of __initdata
As long as there is no other non-const variable marked __initdata in the
same compilation unit it doesn't hurt. If there were one however
compilation would fail with
error: $variablename causes a section type conflict
because a section containing const variables is marked read only and so
cannot contain non-const variables.
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
Cc: Andrew Victor li...@maxim.org.za
Cc: Nicolas Ferre nicolas.fe...@atmel.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Kukjin Kim kgene@samsung.com
Cc: Sascha Hauer ker...@pengutronix.de
Cc: Shawn Guo shawn@linaro.org
Cc: Lennert Buytenhek ker...@wantstofly.org
Cc: Nicolas Pitre n...@fluxnic.net
Cc: Eric Miao eric.y.m...@gmail.com
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: David Brown dav...@codeaurora.org
Cc: Daniel Walker dwal...@fifo99.com
Cc: Bryan Huntsman bry...@codeaurora.org
Cc: Tony Lindgren t...@atomide.com
Cc: Barry Song baohua.s...@csr.com
Cc: Andrew Lunn and...@lunn.ch
Cc: Lucas De Marchi lucas.demar...@profusion.mobi
Cc: linux-arm-ker...@lists.infradead.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-arm-...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
---
changes since (implicit) v1:
- drop changes to several files that were wrong:
- arch/arm/mach-at91/board-dt.c
- arch/arm/mach-exynos/*
- arch/arm/mach-imx/*
- arch/arm/mach-mmp/mmp-dt.c
- arch/arm/mach-msm/board-msm8x60.c
- arch/arm/mach-omap2/board-generic.c
- arch/arm/mach-omap2/voltagedomains{3x,44}xx_data.c
- arch/arm/mach-prima2
- fix position of __initconst
- arch/arm/mach-kirkwood/addr-map.c
- arch/arm/mach-orion5x/addr-map.c
arch/arm/mach-at91/clock.c |2 +-
arch/arm/mach-davinci/board-tnetv107x-evm.c |6 ++--
arch/arm/mach-davinci/da830.c | 48 +--
arch/arm/mach-davinci/da850.c |6 ++--
arch/arm/mach-dove/addr-map.c |2 +-
arch/arm/mach-kirkwood/addr-map.c |2 +-
arch/arm/mach-msm/board-qsd8x50.c |4 +--
arch/arm/mach-omap2/display.c |6 ++--
arch/arm/mach-orion5x/addr-map.c|2 +-
9 files changed, 39 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-at91/clock.c b/arch/arm/mach-at91/clock.c
index a0f4d74..e4a255d 100644
--- a/arch/arm/mach-at91/clock.c
+++ b/arch/arm/mach-at91/clock.c
@@ -613,7 +613,7 @@ fail:
return 0;
}
-static struct clk *const standard_pmc_clocks[] __initdata = {
+static struct clk *const standard_pmc_clocks[] __initconst = {
/* four primary clocks */
clk32k,
main_clk,
diff --git a/arch/arm/mach-davinci/board-tnetv107x-evm.c
b/arch/arm/mach-davinci/board-tnetv107x-evm.c
index 5f14e30..645a587 100644
--- a/arch/arm/mach-davinci/board-tnetv107x-evm.c
+++ b/arch/arm/mach-davinci/board-tnetv107x-evm.c
@@ -88,7 +88,7 @@ static struct davinci_mmc_config mmc_config = {
.version= MMC_CTLR_VERSION_1,
};
-static const short sdio1_pins[] __initdata = {
+static const short sdio1_pins[] __initconst = {
TNETV107X_SDIO1_CLK_1, TNETV107X_SDIO1_CMD_1,
TNETV107X_SDIO1_DATA0_1,TNETV107X_SDIO1_DATA1_1,
TNETV107X_SDIO1_DATA2_1,TNETV107X_SDIO1_DATA3_1,
@@ -96,12 +96,12 @@ static const short sdio1_pins[] __initdata = {
-1
};
-static const short uart1_pins[] __initdata = {
+static const short uart1_pins[] __initconst = {
TNETV107X_UART1_RD, TNETV107X_UART1_TD,
-1
};
-static const short ssp_pins[] __initdata = {
+static const short ssp_pins[] __initconst = {
TNETV107X_SSP0_0, TNETV107X_SSP0_1, TNETV107X_SSP0_2,
TNETV107X_SSP1_0, TNETV107X_SSP1_1, TNETV107X_SSP1_2,
TNETV107X_SSP1_3, -1
diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index deee5c2..510648e 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -838,7 +838,7 @@ static const struct mux_config da830_pins[] = {
#endif
};
-const short da830_emif25_pins[] __initdata = {
+const short da830_emif25_pins[] __initconst = {
DA830_EMA_D_0, DA830_EMA_D_1, DA830_EMA_D_2, DA830_EMA_D_3,
DA830_EMA_D_4, DA830_EMA_D_5, DA830_EMA_D_6, DA830_EMA_D_7,
DA830_EMA_D_8, DA830_EMA_D_9, DA830_EMA_D_10, DA830_EMA_D_11,
@@ -853,19 +853,19 @@ const short da830_emif25_pins[] __initdata = {
-1
};
-const short da830_spi0_pins[] __initdata = {
+const short da830_spi0_pins[] __initconst = {
DA830_SPI0_SOMI_0, DA830_SPI0_SIMO_0, DA830_SPI0_CLK, DA830_NSPI0_ENA,
DA830_NSPI0_SCS_0,
-1
};
-const short da830_spi1_pins[] __initdata = {
+const short da830_spi1_pins[] __initconst = {
DA830_SPI1_SOMI_0, DA830_SPI1_SIMO_0,
Re: defconfig for panda
* Kumar Gala ga...@kernel.crashing.org [120330 14:14]: On Mar 30, 2012, at 1:48 PM, Tony Lindgren wrote: Hi, * Kumar Gala ga...@kernel.crashing.org [120329 12:24]: As I'm new to the OMAP community this might be a stupid question but trying to just build and run a stock v3.3 kernel on a pandaboard. In doing so it seems as if some basic drivers are not enabled in omap2plus_defconfig for the board. I'm trying to figure out if this is normal for some reason or just an oversight. For example, USB and USB ethernet (SMC95xx). I notice the linaro kernel tree introduces an omap4_defconfig, so just wondering should I send patches to omap2plus_defconfig or what? We can add those to omap2plus_defconfig for sure, but let's have them added as modules. Then distros can use that easily in a standard way using initramfs-tools etc. Let's not change the drivers that are currently built in if they're needed for mounting mmc or nfsroot. Those can be changed later on. I'll work up a patch, however I was doing this as I was trying to get NFS root working and thus would need USB + USB ethernet compiled in and not as modules for panda. Is that ok? Maybe, let's take a look how much bigger the kernel becomes. Also we need to check if the same EHCI configuration works for omap3/4. 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
