Re: [PATCH] ARM: OMAP: hwmod: Fix error handling in functions used OMAP4 onwards
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) and IMHO should be handled separately, with a flag like you are suggesting or by some other means. If you already have patches on how this can be done, you should go ahead and post them out. -- To unsubscribe from this list: send the line unsubscribe 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] OMAP2+: UART: Remove cpu checks for populating errata flags
On Wed, Mar 28, 2012 at 10:13 PM, Jon Hunter jon-hun...@ti.com wrote:
Hi Govindraj,
On 3/28/2012 6:09, Raja, Govindraj wrote:
On Wed, Mar 28, 2012 at 2:38 AM, Jon Hunterjon-hun...@ti.com wrote:
Hi Govindraj,
[...]
+ u32 mvr, scheme;
+ u16 revision, major, minor;
+
+ mvr = serial_in(up, UART_OMAP_MVER);
+
+ /* Check revision register scheme */
+ scheme = mvr (0x03 30);
+ scheme= 30;
Minor nit-pick, why not ...
scheme = mvr 30;
yes will correct it.
Thinking some more, could be better to add some #defines for
OMAP_MVR_VERSION_MASK/SHIFT here.
Yes sure.
+ switch (scheme) {
+ case 0: /* Legacy Scheme: OMAP2/3 */
+ /* MINOR_REV[0:4], MAJOR_REV[4:7] */
This scheme is also true from OMAP1 devices. Maybe we could include in
the
comment.
No omap1 from $SUBJECT also reason,
mach-omap1/serial.c = 8250.c
mach-omap2/serial.c = omap-serial.c
Got it! Thanks.
+ major = (mvr 0xf0) 4;
+ minor = (mvr 0x0f);
+ break;
+ case 1:
+ /* New Scheme: OMAP4+ */
+ /* MINOR_REV[0:5], MAJOR_REV[8:10] */
+ major = (mvr 0x7 8) 8;
Nit-pick ...
major = (mvr 8) 0x7;
yes fine will correct this.
May be we should add #defines here to for OMAP_UART_MVR1_MAJ_MASK/SHIFT,
OMAP_UART_MVR1_MIN_MASK/SHIFT, OMAP_UART_MVR2_MAJ_MASK/SHIFT and
OMAP_UART_MVR2_MIN_MASK/SHIFT.
okay will add this.
--
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 v2 1/5] spi/omap: Remove bus_num usage for instance index
Hi Tarun, On Wed, Mar 28, 2012 at 2:15 PM, DebBarma, Tarun Kanti tarun.ka...@ti.com wrote: On Mon, Mar 26, 2012 at 7:14 PM, Shubhrajyoti D shubhrajy...@ti.com wrote: 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 @@ snip tmp = OMAP2_MCSPI_WAKEUPENABLE_WKEN; mcspi_write_reg(master, OMAP2_MCSPI_WAKEUPENABLE, tmp); - omap2_mcspi_ctx[master-bus_num - 1].wakeupenable = tmp; + ctx-wakeupenable = tmp; Can't we get rid of tmp now? For example: ctx-wakeupenable = OMAP2_MCSPI_WAKEUPENABLE_WKEN; mcspi_write_reg(master, OMAP2_MCSPI_WAKEUPENABLE, ctx-wakeupenable); Yes the tmp variable could be optimized since it is in addition to the $SUBJECT will do it in a separate patch . Is that fine? -- Tarun -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suspend broken on 3.3?
-Original Message- From: Kevin Hilman khil...@ti.com To: Joe Woodward j...@terrafix.co.uk Cc: Raja\, Govindraj govindraj.r...@ti.com, linux-omap@vger.kernel.org, Felipe Balbi ba...@ti.com, Paul Walmsley p...@pwsan.com, ne...@suse.de Date: Wed, 28 Mar 2012 10:46:23 -0700 Subject: Re: Suspend broken on 3.3? +Paul, NeilBrown who both have worked on/around recent UART breakage since v3.2 Joe Woodward j...@terrafix.co.uk writes: [...] This patch fixes the suspend problem for me, but there is another UART issue... Basically I've got a fairly high speed data source (in UART terms, 900KBaud) pumping data to the OMAP (such as GPS positions). I don't want this to wake me when suspended (which this patch fixes). However, it seems on 3.3 that I get a lot of corruption/lost characters, which I'm assuming is because the UART is implementing runtime-PM. So my next question is: How do I disable runtime-PM/force-always-on for a given UART? Can this be done via the sysfs? Yes, but the boot-time default for this is that the UARTs have runtime PM disabled since the default autosuspend timeout is set to -1. You must be setting an autosuspend timeout 0 if you're seeing runtime PM kick in. That being said, even with an autosuspend timeout enabled, you can disable runtime PM by setting the /sys/devices/.../power/control knob to 'on' (instead of auto, which means it's controle by runtime PM): echo on /sys/devices/platform/omap/omap_uart.2/power/control Right, First an apology... After checking /sys/devices/platform/omap/omap_uart.2/power/control I can see that runtime-PM is indeed disabled. 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). 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. All this is tested using a very simple userspace application thats reads data from ttyO1. Any ideas? Should I kick open a new thread as it's not really to do with suspend anymore? Thanks, Joe That will disable runtime PM and leave the UARTs always clocked. Or where are the runtime-PM constraints set for the UART? Look for this in the driver: /* calculate wakeup latency constraint */ up-calc_latency = (USEC_PER_SEC * up-port.fifosize) / (baud / 8); I'm guessing they'll work for 115200Baud, but my high speed UART fowls these? The constraint calculations take into account baud rate, but are known to be somewhat broken currently. You might want to experiment with Paul's work on fixing up the QoS contstraint calculation[1] to see if it helps as well. That is available here Kevin [1] git://git.pwsan.com/linux-2.6 omap_serial_fix_pm_qos_formula_devel_3.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 -- To unsubscribe from this list: send the line unsubscribe 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 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(). The point I was trying to make here was, cpu_is_xxx() check will become ugly, as more and more devices gets added to the list, am33xx being the first one in omap34xx family. and IMHO should be handled separately, with a flag like you are suggesting or by some other means. If you already have patches on how this can be done, you should go ahead and post them out. Nope. But I can work on it, once I finish my AM33xx baseport submission. 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] ARM: OMAP: hwmod: Fix error handling in functions used OMAP4 onwards
On Thursday 29 March 2012 02:26 PM, Hiremath, Vaibhav wrote: The point I was trying to make here was, cpu_is_xxx() check will become ugly, as more and more devices gets added to the list, am33xx being the first one in omap34xx family. So are there more, other than AM33xx which are cortex A8 based but share the OMAP4 PRCM IP block? -- To unsubscribe from this list: send the line unsubscribe 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 14:32:34, Nayak, Rajendra wrote: On Thursday 29 March 2012 02:26 PM, Hiremath, Vaibhav wrote: The point I was trying to make here was, cpu_is_xxx() check will become ugly, as more and more devices gets added to the list, am33xx being the first one in omap34xx family. So are there more, other than AM33xx which are cortex A8 based but share the OMAP4 PRCM IP block? I would say, probably yes. But, things are so dynamic and you never know how things will shape up by the time you freeze the design. 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: Suspend broken on 3.3?
Hi Joe, 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). How did you verify that register read? 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. All this is tested using a very simple userspace application thats reads data from ttyO1. Any ideas? Should I kick open a new thread as it's not really to do with suspend anymore? Is there any flow control you are using? -- To unsubscribe from this list: send the line unsubscribe 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?
Hi Joe,
After digging a bit further I found that the problem isn't lost
characters or character corruption at all...
The UART is actually at 460KBaud (not 900KBaud as I mentioned
earlier).
How did you verify that register read?
I actually looked at the setting applied in my code (which I should have done
earlier, oops :p).
...
newtio.c_iflag = (IGNPAR);
newtio.c_oflag = 0;
newtio.c_cflag = B460800 | CS8 | CLOCAL | CREAD;
newtio.c_lflag = 0;
newtio.c_cc[VINTR]= 0; /* Ctrl-c */
newtio.c_cc[VQUIT]= 0; /* Ctrl-\ */
newtio.c_cc[VERASE] = 0; /* del */
newtio.c_cc[VKILL]= 0; /* @ */
newtio.c_cc[VEOF] = 0; /* Ctrl-d */
newtio.c_cc[VTIME]= 0; /* inter-character timer unused */
newtio.c_cc[VMIN] = 1; /* blocking read until 1 character arrives */
newtio.c_cc[VSWTC]= 0; /* '\0' */
newtio.c_cc[VSTART] = 0; /* Ctrl-q */
newtio.c_cc[VSTOP]= 0; /* Ctrl-s */
newtio.c_cc[VSUSP]= 0; /* Ctrl-z */
newtio.c_cc[VEOL] = 0; /* '\0' */
newtio.c_cc[VREPRINT] = 0; /* Ctrl-r */
newtio.c_cc[VDISCARD] = 0; /* Ctrl-u */
newtio.c_cc[VWERASE] = 0; /* Ctrl-w */
newtio.c_cc[VLNEXT] = 0; /* Ctrl-v */
newtio.c_cc[VEOL2]= 0; /* '\0' */
/* Clean the modem line and activate the settings for the port
*/
tcflush (handle-serialFD, TCIFLUSH);
tcsetattr (handle-serialFD, TCSANOW, newtio);
...
I then loop read from a file descriptor to see the received bytes:
serialFD = open (/dev/ttyO0, O_RDWR | O_NOCTTY);
...
while (1) {
count = read (serialFD, buffer, MAXIMUM_LINE_LENGTH);
...
debug here...
...
}
And it's by inspecting the bytes read that I noticed the inserted 0x00 on 3.3.
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.
All this is tested using a very simple userspace application thats
reads data from ttyO1.
Any ideas? Should I kick open a new thread as it's not really to do
with suspend anymore?
Is there any flow control you are using?
No flow control, but lack of flow control hasn't caused problems up to 3.2.
Cheers,
Joe
--
To unsubscribe from this list: send the line unsubscribe 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 v3 0/4] ARM: OMAP: boards: changes to support dynamic irq alloc
These four patches incorporate changes to OMAP1 and OMAP2 platforms
board files whereby older references to OMAP_GPIO_IRQ macro are
now replaced with gpio_to_irq(), thereby getting rid of static
irq references.
Reference: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git omap/dt
Commit: fde7d9049e55ab85a390be7f415d74c9f62dd0f9
Test info:
OMAP1 Platforms:
Boot test on OMAP1710 H3.
OMAP2PLUS Platforms:
Boot test on OMAP2430SDP, OMAP3430SDP, OMAP3630-ZOOM3, OMAP4430-SDP.
v3:
Avoid accessing devices using device array index. Consider following list:
static struct platform_device *h2_devices[] __initdata = {
h2_nor_device,
h2_nand_device,
h2_smc91x_device,
h2_irda_device,
h2_kp_device,
h2_lcd_device,
};
static void __init h2_init(void)
{
[...]
h2_devices[2]-resource[1].start = gpio_to_irq(0);
h2_devices[2]-resource[1].end = gpio_to_irq(0);
[...]
}
The above implementation is immune to failure if someone inserts new device
in the list before h2_smc91x_device. In order to avoid such a problem access
the devices directly like this:
h2_smc91x_resources[1].start = gpio_to_irq(0);
h2_smc91x_resources[1].end = gpio_to_irq(0);
Similar change incorporated for all the boards wherever applicable.
v2:
- Modified the patch subjects as per convention.
- Added a new patch to remove OMAP_GPIO_IRQ from ams_delta_serio driver.
- Added a new patch to remove OMAP_GPIO_IRQ macro definition.
Tarun Kanti DebBarma (4):
ARM: OMAP1: boards: Fix OMAP_GPIO_IRQ usage with gpio_to_irq()
ARM: OMAP2+: boards: Fix OMAP_GPIO_IRQ usage with gpio_to_irq()
drivers: input: Fix OMAP_GPIO_IRQ with gpio_to_irq() in
ams_delta_serio_exit()
ARM: OMAP: Remove OMAP_GPIO_IRQ macro definition
arch/arm/mach-omap1/board-h2.c |8
arch/arm/mach-omap1/board-h3.c |9 -
arch/arm/mach-omap1/board-htcherald.c|6 +++---
arch/arm/mach-omap1/board-innovator.c|4 ++--
arch/arm/mach-omap1/board-nokia770.c |2 +-
arch/arm/mach-omap1/board-osk.c | 12 ++--
arch/arm/mach-omap1/board-palmte.c |2 +-
arch/arm/mach-omap1/board-palmtt.c |2 +-
arch/arm/mach-omap1/board-palmz71.c |2 +-
arch/arm/mach-omap1/board-voiceblue.c| 16 +++-
arch/arm/mach-omap2/board-2430sdp.c |2 +-
arch/arm/mach-omap2/board-4430sdp.c |2 +-
arch/arm/mach-omap2/board-apollon.c |4 ++--
arch/arm/mach-omap2/board-devkit8000.c |2 +-
arch/arm/mach-omap2/board-h4.c |2 +-
arch/arm/mach-omap2/board-omap3evm.c |2 +-
arch/arm/mach-omap2/board-omap4panda.c |2 +-
arch/arm/mach-omap2/board-rx51-peripherals.c |3 ++-
arch/arm/mach-omap2/board-zoom-debugboard.c |3 ++-
arch/arm/mach-omap2/board-zoom-peripherals.c |6 --
arch/arm/mach-omap2/common-board-devices.c |2 +-
arch/arm/plat-omap/include/plat/gpio.h |4
drivers/input/serio/ams_delta_serio.c|2 +-
23 files changed, 48 insertions(+), 51 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 v3 4/4] ARM: OMAP: Remove OMAP_GPIO_IRQ macro definition
Since all references to OMAP_GPIO_IRQ macro are replaced now with gpio_to_irq(), this can be removed altogether. Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com --- arch/arm/plat-omap/include/plat/gpio.h |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/arch/arm/plat-omap/include/plat/gpio.h b/arch/arm/plat-omap/include/plat/gpio.h index 9e86ee0..d4df414 100644 --- a/arch/arm/plat-omap/include/plat/gpio.h +++ b/arch/arm/plat-omap/include/plat/gpio.h @@ -158,10 +158,6 @@ #define OMAP_MPUIO(nr) (OMAP_MAX_GPIO_LINES + (nr)) #define OMAP_GPIO_IS_MPUIO(nr) ((nr) = OMAP_MAX_GPIO_LINES) -#define OMAP_GPIO_IRQ(nr) (OMAP_GPIO_IS_MPUIO(nr) ? \ -IH_MPUIO_BASE + ((nr) 0x0f) : \ -IH_GPIO_BASE + (nr)) - #define METHOD_MPUIO 0 #define METHOD_GPIO_1510 1 #define METHOD_GPIO_1610 2 -- 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 v3 3/4] drivers: input: Fix OMAP_GPIO_IRQ with gpio_to_irq() in ams_delta_serio_exit()
Even though ams-delta-serio input driver uses gpio_to_irq() in all
relevent places to get irq number, the ams_delta_serio_exit() still
uses OMAP_GPIO_IRQ macro. Fix this.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
drivers/input/serio/ams_delta_serio.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/input/serio/ams_delta_serio.c
b/drivers/input/serio/ams_delta_serio.c
index d4d08bd..dbe1ae8 100644
--- a/drivers/input/serio/ams_delta_serio.c
+++ b/drivers/input/serio/ams_delta_serio.c
@@ -170,7 +170,7 @@ module_init(ams_delta_serio_init);
static void __exit ams_delta_serio_exit(void)
{
serio_unregister_port(ams_delta_serio);
- free_irq(OMAP_GPIO_IRQ(AMS_DELTA_GPIO_PIN_KEYBRD_CLK), 0);
+ free_irq(gpio_to_irq(AMS_DELTA_GPIO_PIN_KEYBRD_CLK), 0);
gpio_free(AMS_DELTA_GPIO_PIN_KEYBRD_CLK);
gpio_free(AMS_DELTA_GPIO_PIN_KEYBRD_DATA);
}
--
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 v3 2/4] ARM: OMAP2+: boards: Fix OMAP_GPIO_IRQ usage with gpio_to_irq()
With dynamic allocation of IRQ the usage of OMAP_GPIO_IRQ
is no longer valid. We should be using gpio_to_irq() instead.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
arch/arm/mach-omap2/board-2430sdp.c |2 +-
arch/arm/mach-omap2/board-4430sdp.c |2 +-
arch/arm/mach-omap2/board-apollon.c |4 ++--
arch/arm/mach-omap2/board-devkit8000.c |2 +-
arch/arm/mach-omap2/board-h4.c |2 +-
arch/arm/mach-omap2/board-omap3evm.c |2 +-
arch/arm/mach-omap2/board-omap4panda.c |2 +-
arch/arm/mach-omap2/board-rx51-peripherals.c |3 ++-
arch/arm/mach-omap2/board-zoom-debugboard.c |3 ++-
arch/arm/mach-omap2/board-zoom-peripherals.c |6 --
arch/arm/mach-omap2/common-board-devices.c |2 +-
11 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 7370983..5a1b6af 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -230,12 +230,12 @@ static struct i2c_board_info __initdata
sdp2430_i2c1_boardinfo[] = {
{
I2C_BOARD_INFO(isp1301_omap, 0x2D),
.flags = I2C_CLIENT_WAKE,
- .irq = OMAP_GPIO_IRQ(78),
},
};
static int __init omap2430_i2c_init(void)
{
+ sdp2430_i2c1_boardinfo[0].irq = gpio_to_irq(78);
omap_register_i2c_bus(1, 100, sdp2430_i2c1_boardinfo,
ARRAY_SIZE(sdp2430_i2c1_boardinfo));
omap_pmic_init(2, 100, twl4030, INT_24XX_SYS_NIRQ,
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 4e90715..a09c699 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -873,7 +873,6 @@ static void __init omap4_sdp4430_wifi_mux_init(void)
}
static struct wl12xx_platform_data omap4_sdp4430_wlan_data __initdata = {
- .irq = OMAP_GPIO_IRQ(GPIO_WIFI_IRQ),
.board_ref_clock = WL12XX_REFCLOCK_26,
.board_tcxo_clock = WL12XX_TCXOCLOCK_26,
};
@@ -883,6 +882,7 @@ static void __init omap4_sdp4430_wifi_init(void)
int ret;
omap4_sdp4430_wifi_mux_init();
+ omap4_sdp4430_wlan_data.irq = gpio_to_irq(GPIO_WIFI_IRQ);
ret = wl12xx_set_platform_data(omap4_sdp4430_wlan_data);
if (ret)
pr_err(Error setting wl12xx data: %d\n, ret);
diff --git a/arch/arm/mach-omap2/board-apollon.c
b/arch/arm/mach-omap2/board-apollon.c
index ac77382..768ece2 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -136,8 +136,6 @@ static struct resource apollon_smc91x_resources[] = {
.flags = IORESOURCE_MEM,
},
[1] = {
- .start = OMAP_GPIO_IRQ(APOLLON_ETHR_GPIO_IRQ),
- .end= OMAP_GPIO_IRQ(APOLLON_ETHR_GPIO_IRQ),
.flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHEDGE,
},
};
@@ -341,6 +339,8 @@ static void __init omap_apollon_init(void)
* You have to mux them off in device drivers later on
* if not needed.
*/
+ apollon_smc91x_resources[1].start = gpio_to_irq(APOLLON_ETHR_GPIO_IRQ);
+ apollon_smc91x_resources[1].end = gpio_to_irq(APOLLON_ETHR_GPIO_IRQ);
platform_add_devices(apollon_devices, ARRAY_SIZE(apollon_devices));
omap_serial_init();
omap_sdrc_init(NULL, NULL);
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index e873063..87cdb86 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -410,7 +410,6 @@ static struct resource omap_dm9000_resources[] = {
.flags = IORESOURCE_MEM,
},
[2] = {
- .start = OMAP_GPIO_IRQ(OMAP_DM9000_GPIO_IRQ),
.flags = IORESOURCE_IRQ | IRQF_TRIGGER_LOW,
},
};
@@ -637,6 +636,7 @@ static void __init devkit8000_init(void)
omap_dm9000_init();
devkit8000_i2c_init();
+ omap_dm9000_resources[2].start = gpio_to_irq(OMAP_DM9000_GPIO_IRQ);
platform_add_devices(devkit8000_devices,
ARRAY_SIZE(devkit8000_devices));
diff --git a/arch/arm/mach-omap2/board-h4.c b/arch/arm/mach-omap2/board-h4.c
index 54af800..0bbbabe 100644
--- a/arch/arm/mach-omap2/board-h4.c
+++ b/arch/arm/mach-omap2/board-h4.c
@@ -348,7 +348,6 @@ static struct at24_platform_data m24c01 = {
static struct i2c_board_info __initdata h4_i2c_board_info[] = {
{
I2C_BOARD_INFO(isp1301_omap, 0x2d),
- .irq= OMAP_GPIO_IRQ(125),
},
{ /* EEPROM on mainboard */
I2C_BOARD_INFO(24c01, 0x52),
@@ -377,6 +376,7 @@ static void __init omap_h4_init(void)
*/
board_mkp_init();
+ h4_i2c_board_info[0].irq = gpio_to_irq(125);
i2c_register_board_info(1,
[PATCH v3 1/4] ARM: OMAP1: boards: Fix OMAP_GPIO_IRQ usage with gpio_to_irq()
With dynamic allocation of IRQ the usage of OMAP_GPIO_IRQ
is no longer valid. We should be using gpio_to_irq() instead.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
arch/arm/mach-omap1/board-h2.c|8
arch/arm/mach-omap1/board-h3.c|9 -
arch/arm/mach-omap1/board-htcherald.c |6 +++---
arch/arm/mach-omap1/board-innovator.c |4 ++--
arch/arm/mach-omap1/board-nokia770.c |2 +-
arch/arm/mach-omap1/board-osk.c | 12 ++--
arch/arm/mach-omap1/board-palmte.c|2 +-
arch/arm/mach-omap1/board-palmtt.c|2 +-
arch/arm/mach-omap1/board-palmz71.c |2 +-
arch/arm/mach-omap1/board-voiceblue.c | 16 +++-
10 files changed, 30 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 00ad6b2..b6926d4 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -244,8 +244,6 @@ static struct resource h2_smc91x_resources[] = {
.flags = IORESOURCE_MEM,
},
[1] = {
- .start = OMAP_GPIO_IRQ(0),
- .end= OMAP_GPIO_IRQ(0),
.flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWEDGE,
},
};
@@ -364,11 +362,9 @@ static struct tps65010_board tps_board = {
static struct i2c_board_info __initdata h2_i2c_board_info[] = {
{
I2C_BOARD_INFO(tps65010, 0x48),
- .irq= OMAP_GPIO_IRQ(58),
.platform_data = tps_board,
}, {
I2C_BOARD_INFO(isp1301_omap, 0x2d),
- .irq= OMAP_GPIO_IRQ(2),
},
};
@@ -437,10 +433,14 @@ static void __init h2_init(void)
omap_cfg_reg(E19_1610_KBR4);
omap_cfg_reg(N19_1610_KBR5);
+ 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));
omap_board_config = h2_config;
omap_board_config_size = ARRAY_SIZE(h2_config);
omap_serial_init();
+ h2_i2c_board_info[0].irq = gpio_to_irq(58);
+ h2_i2c_board_info[1].irq = gpio_to_irq(2);
omap_register_i2c_bus(1, 100, h2_i2c_board_info,
ARRAY_SIZE(h2_i2c_board_info));
omap1_usb_init(h2_usb_config);
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index 4a7f251..15f1028 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -246,8 +246,6 @@ static struct resource smc91x_resources[] = {
.flags = IORESOURCE_MEM,
},
[1] = {
- .start = OMAP_GPIO_IRQ(40),
- .end= OMAP_GPIO_IRQ(40),
.flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWEDGE,
},
};
@@ -337,7 +335,6 @@ static struct spi_board_info h3_spi_board_info[] __initdata
= {
.modalias = tsc2101,
.bus_num= 2,
.chip_select= 0,
- .irq= OMAP_GPIO_IRQ(H3_TS_GPIO),
.max_speed_hz = 1600,
/* .platform_data = tsc_platform_data, */
},
@@ -377,11 +374,9 @@ static struct omap_board_config_kernel h3_config[]
__initdata = {
static struct i2c_board_info __initdata h3_i2c_board_info[] = {
{
I2C_BOARD_INFO(tps65013, 0x48),
- /* .irq = OMAP_GPIO_IRQ(??), */
},
{
I2C_BOARD_INFO(isp1301_omap, 0x2d),
- .irq= OMAP_GPIO_IRQ(14),
},
};
@@ -423,12 +418,16 @@ static void __init h3_init(void)
omap_cfg_reg(E19_1610_KBR4);
omap_cfg_reg(N19_1610_KBR5);
+ smc91x_resources[1].start = gpio_to_irq(40);
+ smc91x_resources[1].end = gpio_to_irq(40);
platform_add_devices(devices, ARRAY_SIZE(devices));
+ h3_spi_board_info[0].irq = gpio_to_irq(H3_TS_GPIO);
spi_register_board_info(h3_spi_board_info,
ARRAY_SIZE(h3_spi_board_info));
omap_board_config = h3_config;
omap_board_config_size = ARRAY_SIZE(h3_config);
omap_serial_init();
+ h3_i2c_board_info[1].irq = gpio_to_irq(14);
omap_register_i2c_bus(1, 100, h3_i2c_board_info,
ARRAY_SIZE(h3_i2c_board_info));
omap1_usb_init(h3_usb_config);
diff --git a/arch/arm/mach-omap1/board-htcherald.c
b/arch/arm/mach-omap1/board-htcherald.c
index 731cc3d..cc04144 100644
--- a/arch/arm/mach-omap1/board-htcherald.c
+++ b/arch/arm/mach-omap1/board-htcherald.c
@@ -324,8 +324,6 @@ static struct platform_device gpio_leds_device = {
static struct resource htcpld_resources[] = {
[0] = {
- .start = OMAP_GPIO_IRQ(HTCHERALD_GIRQ_BTNS),
- .end= OMAP_GPIO_IRQ(HTCHERALD_GIRQ_BTNS),
.flags = IORESOURCE_IRQ,
},
};
@@ -454,7 +452,6 @@
[PATCH v3 1/4] ARM: OMAP1: boards: Fix OMAP_GPIO_IRQ usage with gpio_to_irq()
With dynamic allocation of IRQ the usage of OMAP_GPIO_IRQ
is no longer valid. We should be using gpio_to_irq() instead.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
arch/arm/mach-omap1/board-h2.c|8
arch/arm/mach-omap1/board-h3.c|9 -
arch/arm/mach-omap1/board-htcherald.c |6 +++---
arch/arm/mach-omap1/board-innovator.c |4 ++--
arch/arm/mach-omap1/board-nokia770.c |2 +-
arch/arm/mach-omap1/board-osk.c | 12 ++--
arch/arm/mach-omap1/board-palmte.c|2 +-
arch/arm/mach-omap1/board-palmtt.c|2 +-
arch/arm/mach-omap1/board-palmz71.c |2 +-
arch/arm/mach-omap1/board-voiceblue.c | 16 +++-
10 files changed, 30 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 00ad6b2..b6926d4 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -244,8 +244,6 @@ static struct resource h2_smc91x_resources[] = {
.flags = IORESOURCE_MEM,
},
[1] = {
- .start = OMAP_GPIO_IRQ(0),
- .end= OMAP_GPIO_IRQ(0),
.flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWEDGE,
},
};
@@ -364,11 +362,9 @@ static struct tps65010_board tps_board = {
static struct i2c_board_info __initdata h2_i2c_board_info[] = {
{
I2C_BOARD_INFO(tps65010, 0x48),
- .irq= OMAP_GPIO_IRQ(58),
.platform_data = tps_board,
}, {
I2C_BOARD_INFO(isp1301_omap, 0x2d),
- .irq= OMAP_GPIO_IRQ(2),
},
};
@@ -437,10 +433,14 @@ static void __init h2_init(void)
omap_cfg_reg(E19_1610_KBR4);
omap_cfg_reg(N19_1610_KBR5);
+ 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));
omap_board_config = h2_config;
omap_board_config_size = ARRAY_SIZE(h2_config);
omap_serial_init();
+ h2_i2c_board_info[0].irq = gpio_to_irq(58);
+ h2_i2c_board_info[1].irq = gpio_to_irq(2);
omap_register_i2c_bus(1, 100, h2_i2c_board_info,
ARRAY_SIZE(h2_i2c_board_info));
omap1_usb_init(h2_usb_config);
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index 4a7f251..15f1028 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -246,8 +246,6 @@ static struct resource smc91x_resources[] = {
.flags = IORESOURCE_MEM,
},
[1] = {
- .start = OMAP_GPIO_IRQ(40),
- .end= OMAP_GPIO_IRQ(40),
.flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWEDGE,
},
};
@@ -337,7 +335,6 @@ static struct spi_board_info h3_spi_board_info[] __initdata
= {
.modalias = tsc2101,
.bus_num= 2,
.chip_select= 0,
- .irq= OMAP_GPIO_IRQ(H3_TS_GPIO),
.max_speed_hz = 1600,
/* .platform_data = tsc_platform_data, */
},
@@ -377,11 +374,9 @@ static struct omap_board_config_kernel h3_config[]
__initdata = {
static struct i2c_board_info __initdata h3_i2c_board_info[] = {
{
I2C_BOARD_INFO(tps65013, 0x48),
- /* .irq = OMAP_GPIO_IRQ(??), */
},
{
I2C_BOARD_INFO(isp1301_omap, 0x2d),
- .irq= OMAP_GPIO_IRQ(14),
},
};
@@ -423,12 +418,16 @@ static void __init h3_init(void)
omap_cfg_reg(E19_1610_KBR4);
omap_cfg_reg(N19_1610_KBR5);
+ smc91x_resources[1].start = gpio_to_irq(40);
+ smc91x_resources[1].end = gpio_to_irq(40);
platform_add_devices(devices, ARRAY_SIZE(devices));
+ h3_spi_board_info[0].irq = gpio_to_irq(H3_TS_GPIO);
spi_register_board_info(h3_spi_board_info,
ARRAY_SIZE(h3_spi_board_info));
omap_board_config = h3_config;
omap_board_config_size = ARRAY_SIZE(h3_config);
omap_serial_init();
+ h3_i2c_board_info[1].irq = gpio_to_irq(14);
omap_register_i2c_bus(1, 100, h3_i2c_board_info,
ARRAY_SIZE(h3_i2c_board_info));
omap1_usb_init(h3_usb_config);
diff --git a/arch/arm/mach-omap1/board-htcherald.c
b/arch/arm/mach-omap1/board-htcherald.c
index 731cc3d..cc04144 100644
--- a/arch/arm/mach-omap1/board-htcherald.c
+++ b/arch/arm/mach-omap1/board-htcherald.c
@@ -324,8 +324,6 @@ static struct platform_device gpio_leds_device = {
static struct resource htcpld_resources[] = {
[0] = {
- .start = OMAP_GPIO_IRQ(HTCHERALD_GIRQ_BTNS),
- .end= OMAP_GPIO_IRQ(HTCHERALD_GIRQ_BTNS),
.flags = IORESOURCE_IRQ,
},
};
@@ -454,7 +452,6 @@
[PATCH] omap2+: pm: fix compilation break.
From: Govindraj.R govindraj.r...@ti.com Fix the compilation break observed on latest mainline. Fixes below compilation break: arch/arm/mach-omap2/pm.c: In function 'omap_pm_begin': arch/arm/mach-omap2/pm.c:239: error: implicit declaration of function 'disable_hlt' arch/arm/mach-omap2/pm.c: In function 'omap_pm_end': arch/arm/mach-omap2/pm.c:247: error: implicit declaration of function 'enable_hlt' Cc: Kevin Hilman khil...@ti.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Govindraj.R govindraj.r...@ti.com --- arch/arm/mach-omap2/pm.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c index a7bdec6..70da4f7 100644 --- a/arch/arm/mach-omap2/pm.c +++ b/arch/arm/mach-omap2/pm.c @@ -16,6 +16,7 @@ #include linux/opp.h #include linux/export.h #include linux/suspend.h +#include asm/system_misc.h #include plat/omap-pm.h #include plat/omap_device.h -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 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... 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. 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. And one other thing to try: does the behavior change if you set uart_debug to true at arch/arm/mach-omap2/serial.c:278 ? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 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 :) ). Cheers, Joe And one other thing to try: does the behavior change if you set uart_debug to true at arch/arm/mach-omap2/serial.c:278 ? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe 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: 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... Cheers, Joe Cheers, Joe And one other thing to try: does the behavior change if you set uart_debug to true at arch/arm/mach-omap2/serial.c:278 ? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 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 ? -- 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: [GIT PULL] omap fixes for merge window
* Olof Johansson o...@lixom.net [120328 22:04]: Hi Tony, On Wed, Mar 21, 2012 at 11:05 AM, Tony Lindgren t...@atomide.com wrote: Hi Arnd Olof, Here's a set of fixes that would be nice to get merged during the merge window before the GPIO changes get merged to avoid boot issues on many omap boards. The changes queued in the GPIO tree require getting rid of OMAP_GPIO_IRQ and use gpio_to_irq() instead. This is needed for dynamically allocated GPIO interrupt ranges. Sorry for the slow response on this, we've been focused on getting the main pulls going in. I'm about to start a fixes branch now and looked at this pull request. I replied to one of the original patches in this branch, they need to be fixed before they can go in: http://marc.info/?l=linux-omapm=133299716528617w=2 Thanks, that's a good catch. Also, that way we can get a clean branch based on current mainline without merge conflicts. Yes will do. 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: AM3517evm
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? Best regards, 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] ARM: OMAP: hwmod: Fix error handling in functions used OMAP4 onwards
Hi Viabhav, On 3/29/2012 4:14, Hiremath, Vaibhav wrote: On Thu, Mar 29, 2012 at 14:32:34, Nayak, Rajendra wrote: On Thursday 29 March 2012 02:26 PM, Hiremath, Vaibhav wrote: The point I was trying to make here was, cpu_is_xxx() check will become ugly, as more and more devices gets added to the list, am33xx being the first one in omap34xx family. So are there more, other than AM33xx which are cortex A8 based but share the OMAP4 PRCM IP block? I would say, probably yes. But, things are so dynamic and you never know how things will shape up by the time you freeze the design. So this begs the question, why does AM33xx return true from cpu_is_omap34xx() is the architecture is based upon OMAP4 and not OMAP3? I understand it is a Cortex-A8 versus Corex-A9, but if the architecture is closer to OMAP4, then should it not be classed as OMAP4 and not OMAP3? Raises another question if we should really have arch_is_omap and not cpu_is_omap. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: hwmod: Fix error handling in functions used OMAP4 onwards
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. 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] omap2+: pm: fix compilation break.
* Govindraj.R govindraj.r...@ti.com [120329 03:12]: From: Govindraj.R govindraj.r...@ti.com Fix the compilation break observed on latest mainline. Fixes below compilation break: arch/arm/mach-omap2/pm.c: In function 'omap_pm_begin': arch/arm/mach-omap2/pm.c:239: error: implicit declaration of function 'disable_hlt' arch/arm/mach-omap2/pm.c: In function 'omap_pm_end': arch/arm/mach-omap2/pm.c:247: error: implicit declaration of function 'enable_hlt' Care to mention which commit broke the compile? Regards, Tony Cc: Kevin Hilman khil...@ti.com Cc: Tony Lindgren t...@atomide.com Signed-off-by: Govindraj.R govindraj.r...@ti.com --- arch/arm/mach-omap2/pm.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c index a7bdec6..70da4f7 100644 --- a/arch/arm/mach-omap2/pm.c +++ b/arch/arm/mach-omap2/pm.c @@ -16,6 +16,7 @@ #include linux/opp.h #include linux/export.h #include linux/suspend.h +#include asm/system_misc.h #include plat/omap-pm.h #include plat/omap_device.h -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] arm: Use the plat_nand default partition parser
* H Hartley Sweeten hartl...@visionengravers.com [120328 11:16]: Use the default partition parser, cmdlinepart, provided by the plat_nand driver. Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com Cc: Ryan Mallon rmal...@gmail.com Cc: Imre Kaloz ka...@openwrt.org Cc: Krzysztof Halasa k...@pm.waw.pl Cc: Tony Lindgren t...@atomide.com Cc: Alexander Clouter a...@digriz.org.uk Cc: Nicolas Pitre n...@fluxnic.net Cc: Eric Miao eric.y.m...@gmail.com Cc: Haojian Zhuang haojian.zhu...@gmail.com Cc: Marek Vasut marek.va...@gmail.com 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 v3 0/4] ARM: OMAP: boards: changes to support dynamic irq alloc
* Tarun Kanti DebBarma tarun.ka...@ti.com [120329 03:05]:
These four patches incorporate changes to OMAP1 and OMAP2 platforms
board files whereby older references to OMAP_GPIO_IRQ macro are
now replaced with gpio_to_irq(), thereby getting rid of static
irq references.
Thanks, I'll take your updated patches 1/4 and 2/4 combined
into one. And I'll use my earlier updated comments to mention
the breaking commits. As 3/4 and 4/4 have not changed, I'll
use the earlier ones with an ack from Dmitry.
Updated combined 1/4 and 2/4 below.
Tony
From: Tarun Kanti DebBarma tarun.ka...@ti.com
Date: Thu, 29 Mar 2012 08:41:01 -0700
Subject: [PATCH] ARM: OMAP: boards: Fix OMAP_GPIO_IRQ usage with gpio_to_irq()
The following commits change gpio-omap to use dynamic
IRQ allocation:
25db711 gpio/omap: Fix IRQ handling for SPARSE_IRQ
384ebe1 gpio/omap: Add DT support to GPIO driver
With dynamic allocation of IRQ the usage of OMAP_GPIO_IRQ
is no longer valid. We must be using gpio_to_irq() instead.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
[t...@atomide.com: updated comments]
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 03e0050..3768088 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -244,8 +244,6 @@ static struct resource h2_smc91x_resources[] = {
.flags = IORESOURCE_MEM,
},
[1] = {
- .start = OMAP_GPIO_IRQ(0),
- .end= OMAP_GPIO_IRQ(0),
.flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWEDGE,
},
};
@@ -364,11 +362,9 @@ static struct tps65010_board tps_board = {
static struct i2c_board_info __initdata h2_i2c_board_info[] = {
{
I2C_BOARD_INFO(tps65010, 0x48),
- .irq= OMAP_GPIO_IRQ(58),
.platform_data = tps_board,
}, {
I2C_BOARD_INFO(isp1301_omap, 0x2d),
- .irq= OMAP_GPIO_IRQ(2),
},
};
@@ -437,10 +433,14 @@ static void __init h2_init(void)
omap_cfg_reg(E19_1610_KBR4);
omap_cfg_reg(N19_1610_KBR5);
+ 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));
omap_board_config = h2_config;
omap_board_config_size = ARRAY_SIZE(h2_config);
omap_serial_init();
+ h2_i2c_board_info[0].irq = gpio_to_irq(58);
+ h2_i2c_board_info[1].irq = gpio_to_irq(2);
omap_register_i2c_bus(1, 100, h2_i2c_board_info,
ARRAY_SIZE(h2_i2c_board_info));
omap1_usb_init(h2_usb_config);
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index f304fe2..09e8582 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -246,8 +246,6 @@ static struct resource smc91x_resources[] = {
.flags = IORESOURCE_MEM,
},
[1] = {
- .start = OMAP_GPIO_IRQ(40),
- .end= OMAP_GPIO_IRQ(40),
.flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWEDGE,
},
};
@@ -337,7 +335,6 @@ static struct spi_board_info h3_spi_board_info[] __initdata
= {
.modalias = tsc2101,
.bus_num= 2,
.chip_select= 0,
- .irq= OMAP_GPIO_IRQ(H3_TS_GPIO),
.max_speed_hz = 1600,
/* .platform_data = tsc_platform_data, */
},
@@ -377,11 +374,9 @@ static struct omap_board_config_kernel h3_config[]
__initdata = {
static struct i2c_board_info __initdata h3_i2c_board_info[] = {
{
I2C_BOARD_INFO(tps65013, 0x48),
- /* .irq = OMAP_GPIO_IRQ(??), */
},
{
I2C_BOARD_INFO(isp1301_omap, 0x2d),
- .irq= OMAP_GPIO_IRQ(14),
},
};
@@ -423,12 +418,16 @@ static void __init h3_init(void)
omap_cfg_reg(E19_1610_KBR4);
omap_cfg_reg(N19_1610_KBR5);
+ smc91x_resources[1].start = gpio_to_irq(40);
+ smc91x_resources[1].end = gpio_to_irq(40);
platform_add_devices(devices, ARRAY_SIZE(devices));
+ h3_spi_board_info[0].irq = gpio_to_irq(H3_TS_GPIO);
spi_register_board_info(h3_spi_board_info,
ARRAY_SIZE(h3_spi_board_info));
omap_board_config = h3_config;
omap_board_config_size = ARRAY_SIZE(h3_config);
omap_serial_init();
+ h3_i2c_board_info[1].irq = gpio_to_irq(14);
omap_register_i2c_bus(1, 100, h3_i2c_board_info,
ARRAY_SIZE(h3_i2c_board_info));
omap1_usb_init(h3_usb_config);
diff --git a/arch/arm/mach-omap1/board-htcherald.c
b/arch/arm/mach-omap1/board-htcherald.c
index fa52d14..797bbd6 100644
--- a/arch/arm/mach-omap1/board-htcherald.c
+++
Re: [PATCH] omap2+: pm: fix compilation break.
* Tony Lindgren t...@atomide.com [120329 08:14]: * Govindraj.R govindraj.r...@ti.com [120329 03:12]: From: Govindraj.R govindraj.r...@ti.com Fix the compilation break observed on latest mainline. Fixes below compilation break: arch/arm/mach-omap2/pm.c: In function 'omap_pm_begin': arch/arm/mach-omap2/pm.c:239: error: implicit declaration of function 'disable_hlt' arch/arm/mach-omap2/pm.c: In function 'omap_pm_end': arch/arm/mach-omap2/pm.c:247: error: implicit declaration of function 'enable_hlt' Care to mention which commit broke the compile? Seems like it was 9f97da78 (Disintegrate asm/system.h for ARM), and also needs to be fixed for omap1 too. Using the updated patch below. Tony From: Govindraj.R govindraj.r...@ti.com Date: Thu, 29 Mar 2012 09:30:28 -0700 Subject: [PATCH] ARM: OMAP: pm: fix compilation break MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fix the compilation break observed on latest mainline caused by 9f97da78 (Disintegrate asm/system.h for ARM): arch/arm/mach-omap1/pm.c: In function ‘omap_pm_prepare’: arch/arm/mach-omap1/pm.c:587: error: implicit declaration of function ‘disable_hlt’ arch/arm/mach-omap1/pm.c: In function ‘omap_pm_finish’: arch/arm/mach-omap1/pm.c:624: error: implicit declaration of function ‘enable_hlt’ arch/arm/mach-omap1/pm.c: In function ‘omap_pm_init’: arch/arm/mach-omap1/pm.c:681: error: ‘arm_pm_idle’ undeclared (first use in this function) ... arch/arm/mach-omap2/pm.c: In function 'omap_pm_begin': arch/arm/mach-omap2/pm.c:239: error: implicit declaration of function 'disable_hlt' arch/arm/mach-omap2/pm.c: In function 'omap_pm_end': arch/arm/mach-omap2/pm.c:247: error: implicit declaration of function 'enable_hlt' Cc: Kevin Hilman khil...@ti.com Signed-off-by: Govindraj.R govindraj.r...@ti.com [t...@atomide.com: updated to fix omap1 too] Signed-off-by: Tony Lindgren t...@atomide.com diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c index 306beac..f66c329 100644 --- a/arch/arm/mach-omap1/pm.c +++ b/arch/arm/mach-omap1/pm.c @@ -44,6 +44,7 @@ #include linux/io.h #include linux/atomic.h +#include asm/system_misc.h #include asm/irq.h #include asm/mach/time.h #include asm/mach/irq.h diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c index a7bdec6..d0c1c96 100644 --- a/arch/arm/mach-omap2/pm.c +++ b/arch/arm/mach-omap2/pm.c @@ -17,6 +17,8 @@ #include linux/export.h #include linux/suspend.h +#include asm/system_misc.h + #include plat/omap-pm.h #include plat/omap_device.h #include common.h -- To unsubscribe from this list: send the line unsubscribe 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] omap2+: pm: fix compilation break.
Tony Lindgren t...@atomide.com writes: * Tony Lindgren t...@atomide.com [120329 08:14]: * Govindraj.R govindraj.r...@ti.com [120329 03:12]: From: Govindraj.R govindraj.r...@ti.com Fix the compilation break observed on latest mainline. Fixes below compilation break: arch/arm/mach-omap2/pm.c: In function 'omap_pm_begin': arch/arm/mach-omap2/pm.c:239: error: implicit declaration of function 'disable_hlt' arch/arm/mach-omap2/pm.c: In function 'omap_pm_end': arch/arm/mach-omap2/pm.c:247: error: implicit declaration of function 'enable_hlt' Care to mention which commit broke the compile? Seems like it was 9f97da78 (Disintegrate asm/system.h for ARM), and also needs to be fixed for omap1 too. Using the updated patch below. Tony From: Govindraj.R govindraj.r...@ti.com Date: Thu, 29 Mar 2012 09:30:28 -0700 Subject: [PATCH] ARM: OMAP: pm: fix compilation break MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fix the compilation break observed on latest mainline caused by 9f97da78 (Disintegrate asm/system.h for ARM): arch/arm/mach-omap1/pm.c: In function ‘omap_pm_prepare’: arch/arm/mach-omap1/pm.c:587: error: implicit declaration of function ‘disable_hlt’ arch/arm/mach-omap1/pm.c: In function ‘omap_pm_finish’: arch/arm/mach-omap1/pm.c:624: error: implicit declaration of function ‘enable_hlt’ arch/arm/mach-omap1/pm.c: In function ‘omap_pm_init’: arch/arm/mach-omap1/pm.c:681: error: ‘arm_pm_idle’ undeclared (first use in this function) ... arch/arm/mach-omap2/pm.c: In function 'omap_pm_begin': arch/arm/mach-omap2/pm.c:239: error: implicit declaration of function 'disable_hlt' arch/arm/mach-omap2/pm.c: In function 'omap_pm_end': arch/arm/mach-omap2/pm.c:247: error: implicit declaration of function 'enable_hlt' Cc: Kevin Hilman khil...@ti.com Signed-off-by: Govindraj.R govindraj.r...@ti.com [t...@atomide.com: updated to fix omap1 too] Signed-off-by: Tony Lindgren t...@atomide.com Acked-by: Kevin Hilman khil...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] omap randconfig fixes for v3.3
Mathieu, * mathieu.poir...@linaro.org mathieu.poir...@linaro.org [120323 10:16]: From: Arnd Bergmann a...@arndb.de The following is a set of patches that have been sent out during the 3.1 cycle that were not acked or merged. Sending again for completeness. Tony, please pull if there are no objections: The following changes since commit c16fa4f2ad19908a47c63d8fa436a1178438c7e7: Can you please drop the already fixed ones and post a new pull request? It seems that these should merge fine to current mainline if based on v3.3. If not, then maybe use the linux-omap fixes branch as the base that I've just pushed at commit 2533c2cf. Thanks, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V3 0/3] ARM: OMAP2+: Add powerdomain PRM support for AM33XX device
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 tried it on v3.3, but patch 3 fails with a conflict in io.c. 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. 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: [GIT PULL] ARM: OMAP: i2c, gpio, spi, regulator and mmc DTS updates
On Thu, Mar 29, 2012 at 7:08 AM, Cousson, Benoit b-cous...@ti.com wrote: Hi Arnd and Olof, On 3/15/2012 9:01 AM, Arnd Bergmann wrote: On Thursday 15 March 2012, Tony Lindgren wrote: * Cousson, Benoitb-cous...@ti.com [120314 16:41]: Hi Tony, Here are the remaining DTS patches for 3.4. On top of the previous pull request, I just added the MMC DTS since the driver adaptation just got queued. It will be still be good to have that for 3.4 if possible, otherwise we will have a bunch of drivers DT adapted but no DTS file to use them :-( This might be doable as a follow-up patch series at the end of the merge window or at -rc1 when the related driver changes have been merged. Arnd and Olof, what do you guys think? I'll have to look at the patches more closely, but from the diffstat it definitely looks ok for a later merge once the driver is in. If you can rebase the branch on top of the mmc tree (or the merge of that tree with whatever else is needed), it should give us a bisectable history and I can stick it into a late/* branch right away. FYI, MMC DT adaptation just got merged, I2C, GPIO, SPI, regulator DT adaptation were already merged before, so it means that this branch can be merged to take advantage of all the DT adapted drivers. I've pulled this in as late/omap-dt, included in next/dt3 and for-next. I'll let it sit in linux-next for at least one day before it's sent in. Since it's just device tree additions, risk for regressions should be low. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap fixes for merge window
* Tony Lindgren t...@atomide.com [120329 07:44]: * Olof Johansson o...@lixom.net [120328 22:04]: Hi Tony, On Wed, Mar 21, 2012 at 11:05 AM, Tony Lindgren t...@atomide.com wrote: Hi Arnd Olof, Here's a set of fixes that would be nice to get merged during the merge window before the GPIO changes get merged to avoid boot issues on many omap boards. The changes queued in the GPIO tree require getting rid of OMAP_GPIO_IRQ and use gpio_to_irq() instead. This is needed for dynamically allocated GPIO interrupt ranges. Sorry for the slow response on this, we've been focused on getting the main pulls going in. I'm about to start a fixes branch now and looked at this pull request. I replied to one of the original patches in this branch, they need to be fixed before they can go in: http://marc.info/?l=linux-omapm=133299716528617w=2 Thanks, that's a good catch. Also, that way we can get a clean branch based on current mainline without merge conflicts. Yes will do. Olof, here's an updated pull request for your fixes staging branch. This contains the updated gpio_to_irq patches from Tarun, and a trivial build fix from Govindraj to #include asm/system_misc.h in pm.c. The DSI mux patch is the same. Note that the branch name is now just fixes as the necessary commits are now all in the mainline tree. Regards, Tony The following changes since commit 0195c00244dc2e9f522475868fa278c473ba7339: Linus Torvalds (1): Merge tag 'split-asm_system_h-for-linus-20120328' of git://git.kernel.org/.../dhowells/linux-asm_system are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixes Govindraj.R (1): ARM: OMAP: pm: fix compilation break Tarun Kanti DebBarma (3): ARM: OMAP: boards: Fix OMAP_GPIO_IRQ usage with gpio_to_irq() drivers: input: Fix OMAP_GPIO_IRQ with gpio_to_irq() in ams_delta_serio_exit() ARM: OMAP: Remove OMAP_GPIO_IRQ macro definition Tomi Valkeinen (1): ARM: OMAP2+: Remove __init from DSI mux functions Tony Lindgren (2): Merge branch 'fix-dss-mux' into fixes Merge branch 'fixes-gpio-to-irq' into fixes arch/arm/mach-omap1/board-h2.c |8 arch/arm/mach-omap1/board-h3.c |9 - arch/arm/mach-omap1/board-htcherald.c|6 +++--- arch/arm/mach-omap1/board-innovator.c|4 ++-- arch/arm/mach-omap1/board-nokia770.c |2 +- arch/arm/mach-omap1/board-osk.c | 12 ++-- arch/arm/mach-omap1/board-palmte.c |2 +- arch/arm/mach-omap1/board-palmtt.c |2 +- arch/arm/mach-omap1/board-palmz71.c |2 +- arch/arm/mach-omap1/board-voiceblue.c| 16 +++- arch/arm/mach-omap1/pm.c |1 + arch/arm/mach-omap2/board-2430sdp.c |2 +- arch/arm/mach-omap2/board-4430sdp.c |2 +- arch/arm/mach-omap2/board-apollon.c |4 ++-- arch/arm/mach-omap2/board-devkit8000.c |2 +- arch/arm/mach-omap2/board-h4.c |2 +- arch/arm/mach-omap2/board-omap3evm.c |2 +- arch/arm/mach-omap2/board-omap4panda.c |2 +- arch/arm/mach-omap2/board-rx51-peripherals.c |3 ++- arch/arm/mach-omap2/board-zoom-debugboard.c |3 ++- arch/arm/mach-omap2/board-zoom-peripherals.c |6 -- arch/arm/mach-omap2/common-board-devices.c |2 +- arch/arm/mach-omap2/display.c|8 arch/arm/mach-omap2/pm.c |2 ++ arch/arm/plat-omap/include/plat/gpio.h |4 drivers/input/serio/ams_delta_serio.c|2 +- 26 files changed, 55 insertions(+), 55 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
defconfig for panda
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? thanks - k-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap fixes for merge window
On Thu, Mar 29, 2012 at 11:56 AM, Tony Lindgren t...@atomide.com wrote: * Tony Lindgren t...@atomide.com [120329 07:44]: * Olof Johansson o...@lixom.net [120328 22:04]: Hi Tony, On Wed, Mar 21, 2012 at 11:05 AM, Tony Lindgren t...@atomide.com wrote: Hi Arnd Olof, Here's a set of fixes that would be nice to get merged during the merge window before the GPIO changes get merged to avoid boot issues on many omap boards. The changes queued in the GPIO tree require getting rid of OMAP_GPIO_IRQ and use gpio_to_irq() instead. This is needed for dynamically allocated GPIO interrupt ranges. Sorry for the slow response on this, we've been focused on getting the main pulls going in. I'm about to start a fixes branch now and looked at this pull request. I replied to one of the original patches in this branch, they need to be fixed before they can go in: http://marc.info/?l=linux-omapm=133299716528617w=2 Thanks, that's a good catch. Also, that way we can get a clean branch based on current mainline without merge conflicts. Yes will do. Olof, here's an updated pull request for your fixes staging branch. This contains the updated gpio_to_irq patches from Tarun, and a trivial build fix from Govindraj to #include asm/system_misc.h in pm.c. The DSI mux patch is the same. Note that the branch name is now just fixes as the necessary commits are now all in the mainline tree. Regards, Tony The following changes since commit 0195c00244dc2e9f522475868fa278c473ba7339: Linus Torvalds (1): Merge tag 'split-asm_system_h-for-linus-20120328' of git://git.kernel.org/.../dhowells/linux-asm_system are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap fixe Thanks, pulled. -Olof -- To unsubscribe from this list: send the line unsubscribe 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 03/17] 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
---
arch/arm/mach-at91/board-dt.c |2 +-
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-exynos/mach-exynos4-dt.c|2 +-
arch/arm/mach-exynos/mach-exynos5-dt.c|2 +-
arch/arm/mach-imx/imx27-dt.c |2 +-
arch/arm/mach-imx/imx51-dt.c |2 +-
arch/arm/mach-imx/imx53-dt.c |2 +-
arch/arm/mach-imx/mach-imx6q.c|2 +-
arch/arm/mach-kirkwood/addr-map.c |2 +-
arch/arm/mach-mmp/mmp-dt.c|2 +-
arch/arm/mach-msm/board-msm8x60.c |2 +-
arch/arm/mach-msm/board-qsd8x50.c |4 +-
arch/arm/mach-omap2/board-generic.c |8 ++--
arch/arm/mach-omap2/display.c |6 ++--
arch/arm/mach-omap2/voltagedomains3xxx_data.c |2 +-
arch/arm/mach-omap2/voltagedomains44xx_data.c |2 +-
arch/arm/mach-orion5x/addr-map.c |2 +-
arch/arm/mach-prima2/prima2.c |2 +-
22 files changed, 55 insertions(+), 55 deletions(-)
diff --git a/arch/arm/mach-at91/board-dt.c b/arch/arm/mach-at91/board-dt.c
index c18d4d3..1c48ea2 100644
--- a/arch/arm/mach-at91/board-dt.c
+++ b/arch/arm/mach-at91/board-dt.c
@@ -48,7 +48,7 @@ static void __init at91_dt_device_init(void)
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
-static const char *at91_dt_board_compat[] __initdata = {
+static const char *at91_dt_board_compat[] __initconst = {
atmel,at91sam9m10g45ek,
atmel,at91sam9x5ek,
calao,usb-a9g20,
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
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: arch/arm/mach-msm/board-msm8x60.c |2 +- arch/arm/mach-msm/board-qsd8x50.c |4 +- Acked-by: David Brown dav...@codeaurora.org -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
