Re: [PATCH v2] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup
On Fri, May 11, 2012 at 12:41 AM, Tony Lindgren t...@atomide.com wrote:
* Govindraj.R govindraj.r...@ti.com [120510 06:09]:
From: Govindraj.R govindraj.r...@ti.com
The commit (bce492c0 ARM: OMAP2+: UART: Fix incorrect population of
default uart pads) removed default uart pads that where getting populated
and which was making rx pin wakeup capable. If uart pads was used in
Nitpick.. this should say were used here ^^^
will change this.
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -295,8 +353,7 @@ void __init omap_serial_board_init(struct
omap_uart_port_info *info)
bdata.pads = NULL;
bdata.pads_cnt = 0;
- if (cpu_is_omap44xx() || cpu_is_omap34xx())
- omap_serial_fill_default_pads(bdata);
+ omap_serial_check_wakeup(bdata, uart);
Should this section become:
if (!info) {
omap_serial_check_wakeup(bdata, uart);
omap_serial_init_port(bdata, NULL);
} else {
omap_serial_init_port(bdata, info[uart-num]);
}
As if you have bdata, then there should not be anything to mux,
right?
populating bdata should not depend on port_info,
omap_serial_board_init takes only port info parameter and tries to populate
wakeup parameter since it has not received the same from board file.
And board file may or may not pass port info.
So populating bdata - for uart wakeup pin should not be coupled with
availability of port info.
--
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] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup
On Fri, May 11, 2012 at 2:04 PM, Russ Dill russ.d...@gmail.com wrote: On Thu, May 10, 2012 at 6:05 AM, Govindraj.R govindraj.r...@ti.com wrote: From: Govindraj.R govindraj.r...@ti.com The commit (bce492c0 ARM: OMAP2+: UART: Fix incorrect population of default uart pads) removed default uart pads that where getting populated and which was making rx pin wakeup capable. If uart pads was used in different mode by any other module then it would fail since the default pads took over all the uart pins forcefully. With removal of default pads the rx_pad wakeup for console uart while waking up from off mode is broken. [...] + * Check if uart is used in default tx/rx mode i.e. in mux mode0 + * if yes then configure rx pin for wake up capability + */ + if (!(rx_mode 0x07) !(tx_mode 0x07)) + omap_serial_fill_uart_tx_rx_pads(bdata, uart); I realize the comment makes it clear, but it'd probably be better to just make the code clear. I noticed mux.h has a OMAP_MODE_GPIO(x) macro for testing if a mux is in mode4. Perhaps its time to start expanding on that, at least with a macro like: #define OMAP_MUX_MODE(x) ((x) OMAP_MUX_MODE7) So you can do a OMAP_MUX_MODE(rx_mode) == OMAP_MUX_MODE0 Yes sure, will add the macro and use the same. (will post v3 addressing the comments received so far) -- 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 0/8] gpio/omap: remaining cleanups and fix
Hi Tarun,
On Fri, Apr 27, 2012 at 7:43 PM, Tarun Kanti DebBarma
tarun.ka...@ti.com wrote:
Here are the remaining cleanup patches. There are broadly
two categories of cleanups.
Cat-1: Those missed while introducing new feature like SPARSE_IRQ
handling and DT support; use edge/level handlers from
generic IRQ framework.
Cat-2: Removal of redundant fields from struct gpio_bank{} as a
result of they being already covered by members within
context field of struct gpio_bank{}.
Reference:
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Commit: 66f75a5d028beaf67c931435fdc3e7823125730c (Linux 3.4-rc4)
Series is available for reference here:
git://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev.git
for_3.5/gpio_more_cleanup_fixes
I tested this series from your tree on Beagle-XM retention, offmode,
suspend to mem and resume with and and without enabling offmode
from sysfs was checked and found retention count and off mode
count was getting incremented.
Also ran few test cases available from here[1] to request and release gpio,
test cases passed.
Feel Free to add:
Tested-by: Govindraj.R govindraj.r...@ti.com
--
Thanks
Govindraj.R
[1]:
http://gitorious.org/omap-ddt/omap-ddt/trees/master/gpio/test_code/utils/gpio_mods
--
To unsubscribe from this list: send the line unsubscribe 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: Broken UART I/O wakeups on v3.4-rc4+
On Tue, May 8, 2012 at 10:35 AM, Paul Walmsley p...@pwsan.com wrote: Govindraj, After your commit bce492c04ba8fc66a4ea0a52b181ba255daaaf54 (ARM: OMAP2+: UART: Fix incorrect population of default uart pads), the kernel does not return from static suspend when off-mode is enabled upon an incoming serial character. The following steps reproduce the problem: echo 1 /debug/pm_debug/enable_off_mode echo mem /sys/power/state (send a serial character after suspend is entered) (N.B., on the BeagleBoard, the GPIO-connected USER button can be used to wake the system at this point.) The same is discussed in this thread as in here: http://www.spinics.net/lists/linux-omap/msg68659.html Could you please fix this? We probably aren't too far from the v3.5 merge window opening, so there isn't much time to fix it. okay, one possible solution is to probe pins dynamically and make rx wakeup capable which myself and Tony discussed and came up with this patch [1] or to add rx wakeup pad support for each board, based on uart used as console. -- Thanks, Govindraj.R [1]: http://www.spinics.net/lists/linux-omap/msg67822.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] omap3_beagle: init uart2 for beagle rev AX/BX only
On Fri, May 4, 2012 at 11:48 PM, Tony Lindgren t...@atomide.com wrote:
Hi,
Looking at this again..
* Govindraj.R govindraj.r...@ti.com [120306 00:34]:
From: Govindraj.R govindraj.r...@ti.com
All beagle boards rev AX/BX have external usb hubs connected to ehci
interface, external hub/peripheral uses a nreset sequence for which
uart2_rx.gpio_147 pin in mux mode4(USB2HS_nRST) is used on all beagle
boards expect rev Ax/BX.
(Reference to all beagle boards rev schematics:
http://beagleboard.org/hardware/design)
Initialising uart2 will lead to serial init taking over uart2_rx pin
so init uart2_rx pin mux only for Beagle AX/BX rev boards.
Dont init uart2 for all other boards allowing usb_ehci functionality.
OK so the above got fixed for the muxing part with commit
bce492c04ba8fc66a4ea0a52b181ba255daaaf54.
To initialise individual uart port by id utilise and modify the existing
available func. omap_serial_board_init.
This makes sense as board specific fixes.
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -126,6 +126,7 @@ static void __init omap3_beagle_init_rev(void)
beagle_config.mmc1_gpio_wp = 29;
beagle_config.reset_gpio = 170;
beagle_config.usr_button_gpio = 7;
+ omap_serial_board_init(NULL, 1);
break;
case 6:
printk(KERN_INFO OMAP3 Beagle Rev: C1/C2/C3\n);
@@ -528,7 +529,10 @@ static void __init omap3_beagle_init(void)
platform_add_devices(omap3_beagle_devices,
ARRAY_SIZE(omap3_beagle_devices));
omap_display_init(beagle_dss_data);
- omap_serial_init();
+ omap_serial_board_init(NULL, 0);
+ omap_serial_board_init(NULL, 2);
+ omap_serial_board_init(NULL, 3);
+
omap_sdrc_init(mt46h32m32lf6_sdrc_params,
mt46h32m32lf6_sdrc_params);
So this still looks valid, except now you also add the muxing for the
uart pins instead of NULL? Note that you could define OMAP3_UART1_DEFAULT_PINS
etc in some header.
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -393,30 +393,32 @@ void __init omap_serial_init_port(struct
omap_board_data *bdata,
/**
* omap_serial_board_init() - initialize all supported serial ports
* @info: platform specific data pointer
+ * @port_id: uart port number to be initialised
*
- * Initializes all available UARTs as serial ports. Platforms
+ * Initializes individual UARTs as serial ports. Platforms
* can call this function when they want to have default behaviour
- * for serial ports (e.g initialize them all as serial ports).
+ * for serial ports (e.g initialize individual serial ports based on port
id).
*/
-void __init omap_serial_board_init(struct omap_uart_port_info *info)
+void __init omap_serial_board_init(struct omap_uart_port_info *info, u8
port_id)
{
struct omap_uart_state *uart;
struct omap_board_data bdata;
- list_for_each_entry(uart, uart_list, node) {
- bdata.id = uart-num;
- bdata.flags = 0;
- bdata.pads = NULL;
- bdata.pads_cnt = 0;
-
- if (cpu_is_omap44xx() || cpu_is_omap34xx())
- omap_serial_fill_default_pads(bdata);
-
- if (!info)
- omap_serial_init_port(bdata, NULL);
- else
- omap_serial_init_port(bdata, info[uart-num]);
- }
+ list_for_each_entry(uart, uart_list, node)
+ if (uart-num == port_id) {
+ bdata.id = uart-num;
+ bdata.flags = 0;
+ bdata.pads = NULL;
+ bdata.pads_cnt = 0;
+
+ if (!cpu_is_omap24xx())
+ omap_serial_fill_default_pads(bdata);
+
+ if (!info)
+ omap_serial_init_port(bdata, NULL);
+ else
+ omap_serial_init_port(bdata, info);
+ }
}
@@ -428,5 +430,8 @@ void __init omap_serial_board_init(struct
omap_uart_port_info *info)
*/
void __init omap_serial_init(void)
{
- omap_serial_board_init(NULL);
+ struct omap_uart_state *uart;
+
+ list_for_each_entry(uart, uart_list, node)
+ omap_serial_board_init(NULL, uart-num);
}
Is this fix still needed? If so, it should probably be a separate fix
with it's own description.
No this one is not needed anymore
since its fixed part of commit
bce492c04ba8fc66a4ea0a52b181ba255daaaf54
--
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 RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On Thu, May 3, 2012 at 6:55 AM, Russ Dill russ.d...@ti.com wrote: On Wed, May 2, 2012 at 3:38 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Wed, May 2, 2012 at 2:17 PM, Russ Dill russ.d...@ti.com wrote: On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: From: Keshava Munegowda keshava_mgo...@ti.com It is observed that the echi ports of 3430 sdp board are not working due to the random timing of programming the associated GPIOs of the ULPI PHYs of the EHCI for reset. If the PHYs are reset at during usbhs core driver, host ports will not work because EHCI driver is loaded after the resetting PHYs. The PHYs should be in reset state while initializing the EHCI controller. The code which does the GPIO pins associated with the PHYs are programmed to reset is moved from the USB host core driver to EHCI driver. I tested on beagle xm where gpio nreset is requested from board file. (Basic enumertaion after gpio nreset seems to work fine, Hub and smsc lan chip get detected afetr boot up) What base did you test this on top of? my xM is failing USB-wise when I apply this on v3.3.3 (with the UART mux fix patch) and where it is applied within master (3.4-rc4, again, with the UART mux fix patch). Additionally, reverting this patch from 3.4-rc5 causes rc5 to work properly. Works for me be on 3.4-rc5 Beagle-XM even without reverting the patch Logs as in here [1]. I've compared the boot logs and modified some configuration options and command line parameters to make them match, but still no dice. Can you send me your .config? I have uploaded the .config + my binaries (MLO +u-boot +uimage with initramfs) available here [1] -- Thanks, Govindraj.R [1]: http://www.sendspace.com/file/g7m58r -- To unsubscribe from this list: send the line unsubscribe 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 RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On Wed, May 2, 2012 at 2:17 PM, Russ Dill russ.d...@ti.com wrote: On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: From: Keshava Munegowda keshava_mgo...@ti.com It is observed that the echi ports of 3430 sdp board are not working due to the random timing of programming the associated GPIOs of the ULPI PHYs of the EHCI for reset. If the PHYs are reset at during usbhs core driver, host ports will not work because EHCI driver is loaded after the resetting PHYs. The PHYs should be in reset state while initializing the EHCI controller. The code which does the GPIO pins associated with the PHYs are programmed to reset is moved from the USB host core driver to EHCI driver. I tested on beagle xm where gpio nreset is requested from board file. (Basic enumertaion after gpio nreset seems to work fine, Hub and smsc lan chip get detected afetr boot up) What base did you test this on top of? my xM is failing USB-wise when I apply this on v3.3.3 (with the UART mux fix patch) and where it is applied within master (3.4-rc4, again, with the UART mux fix patch). Additionally, reverting this patch from 3.4-rc5 causes rc5 to work properly. Works for me be on 3.4-rc5 Beagle-XM even without reverting the patch Logs as in here [1]. -- Thanks, Govindraj.R [1]: http://pastebin.pandaboard.org/index.php/view/20343533 -- To unsubscribe from this list: send the line unsubscribe 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 RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On Wed, May 2, 2012 at 4:20 PM, Koen Kooi k...@dominion.thruhere.net wrote: Op 2 mei 2012, om 12:38 heeft Raja, Govindraj het volgende geschreven: On Wed, May 2, 2012 at 2:17 PM, Russ Dill russ.d...@ti.com wrote: On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.r...@ti.com wrote: On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: From: Keshava Munegowda keshava_mgo...@ti.com It is observed that the echi ports of 3430 sdp board are not working due to the random timing of programming the associated GPIOs of the ULPI PHYs of the EHCI for reset. If the PHYs are reset at during usbhs core driver, host ports will not work because EHCI driver is loaded after the resetting PHYs. The PHYs should be in reset state while initializing the EHCI controller. The code which does the GPIO pins associated with the PHYs are programmed to reset is moved from the USB host core driver to EHCI driver. I tested on beagle xm where gpio nreset is requested from board file. (Basic enumertaion after gpio nreset seems to work fine, Hub and smsc lan chip get detected afetr boot up) What base did you test this on top of? my xM is failing USB-wise when I apply this on v3.3.3 (with the UART mux fix patch) and where it is applied within master (3.4-rc4, again, with the UART mux fix patch). Additionally, reverting this patch from 3.4-rc5 causes rc5 to work properly. Works for me be on 3.4-rc5 Beagle-XM even without reverting the patch Logs as in here [1]. From your log: [ 1.705291] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 3.726593] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller Why is the ehci stuff taking more than 2 seconds? phy reset operation in omap_ehci_soft_phy_reset failing and timing out. -- 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/2] OMAP2+: UART: Fix incorrect population of default uart pads
On Tue, Apr 24, 2012 at 5:15 AM, Kevin Hilman khil...@ti.com wrote: Govindraj.R govindraj.r...@ti.com writes: From: Govindraj.R govindraj.r...@ti.com The following commit: (7496ba3 ARM: OMAP2+: UART: Add default mux for all uarts) added default pads for all uarts. But not all boards tend to use all uarts and most of unused uart pins are muxed for other purpose. This commit breaks the modules which where trying to use unused uart pins on their boards. So remove the default pads adding. I just noticed that this patch breaks runtime PM wakeups for UART console (at least on 3530/Overo with ttyO2 console.) By removing the pads, the initial device_init_wakeup() is not called on port init. Without this call serial_omap_pm() disables runtime PM because it checks device_may_wakeup(). Since runtime PM was disabled, I manually re-enabled it and then enabled wakeups: echo auto /sys/devices/platform/omap_uart.2/power/control echo enabled /sys/devices/platform/omap_uart.2/tty/ttyO2/power/wakeup Then, after enabling auto-suspend timeouts, it seems wakeups are still not working since the console hangs. Reverting $SUBJECT patch gets things working again. This was decided as part of discussion [1] If we are _reconsidering_ taking this patch [2] to dynamically probe uart pins and enable rx wakeup. I can re-work on the patch[2] as per tony's comments[1] and re-post it. -- Thanks, Govindraj.R [1]: http://www.spinics.net/lists/linux-omap/msg68226.html [2]: http://www.spinics.net/lists/linux-omap/msg67822.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: defconfig for panda
On Fri, Apr 20, 2012 at 10:43 PM, Tony Lindgren t...@atomide.com wrote: * Matt Porter mpor...@ti.com [120420 09:04]: On Fri, Mar 30, 2012 at 02:39:32PM -0700, Tony Lindgren wrote: * 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. FWIW, the same EHCI + SMSC95xx config is used for Beagle xM for nfsroot. First thing I enable on any builds. OK, can somebody please do a minimal patch to omap2plus_defconfig for this? Basically run make savedefconfig with those changes added and then diff against omap2plus_defconfig. I have not seen the patch to enable this on the list, so here is the patch[1] to do the same. -- Thanks, Govindraj.R [1]: From 2965cfb8c05003dba333963c6206b5457adad943 Mon Sep 17 00:00:00 2001 From: Govindraj.R govindraj.r...@ti.com Date: Tue, 24 Apr 2012 14:41:53 +0530 Subject: [PATCH] ARM: omap2plus_defconfig: Enable ehci-omap and sms95xx support Boards like beagle and panda use ehci based smsc95xx lan chips one has to manually enable these supports to get nfs working on these boards. So keep these support enable by default. Signed-off-by: Govindraj.R govindraj.r...@ti.com --- arch/arm/configs/omap2plus_defconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index d5f00d7..9854ff4 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -98,6 +98,7 @@ CONFIG_LIBERTAS_USB=m CONFIG_LIBERTAS_SDIO=m CONFIG_LIBERTAS_DEBUG=y CONFIG_USB_USBNET=y +CONFIG_USB_NET_SMSC95XX=y CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_EPSON2888=y @@ -175,6 +176,7 @@ CONFIG_USB_ANNOUNCE_NEW_DEVICES=y CONFIG_USB_DEVICEFS=y CONFIG_USB_SUSPEND=y CONFIG_USB_MON=y +CONFIG_USB_EHCI_HCD=y CONFIG_USB_WDM=y CONFIG_USB_STORAGE=y CONFIG_USB_LIBUSUAL=y -- 1.7.9 0001-ARM-omap2plus_defconfig-Enable-ehci-omap-and-sms95xx.patch Description: Binary data
Re: [PATCH] tty: serial_core: Add mechanism to identify port closure.
Hi Alan,
On Fri, Apr 20, 2012 at 6:57 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
diff --git a/drivers/tty/serial/serial_core.c
b/drivers/tty/serial/serial_core.c
index 9c4c05b..0dc246d 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1284,6 +1284,8 @@ static void uart_close(struct tty_struct *tty, struct
file *filp)
uart_wait_until_sent(tty, uport-timeout);
}
+ state-uart_port-closing = true;
So what are the locking rules for this - when is it valid and when can it
be tested.
This also still seems a hack to me - the core tty code doesn't have
suspend/resume/open/close confused. The uart layer does, so really the
uart layer needs untangling. I'm skeptical yet another magic state
variable is the answer, particularly when the locking model for the
variable appears undefined.
Teach the uart core code to pass an extra argument indicating whether its
really doing shutdown/open or merely doing suspend/resume. It's perfectly
sensible that it tries to use the same helper for both, its broken that
the called code cannot tell which.
The parameter would also be a local variable which avoids all the locking
questions.
Yes adding a _state_ local variable from port_shutdown from serial_core layer
and passing the same to low level driver can inform the low level driver.
whether current ops is shutdown or a suspend.
Also, looking into the struct uart_ops.
struct uart_ops {
.
.
int (*set_wake)(struct uart_port *, unsigned int state);
.
.
};
Unfortunately set wake is not being used in serial_core.c
So this uart ops can be used to enable wakeups
when port is opened and disable wakeups when port
is closed.
If set_wake is not supposed to be used in this manner I
will fall back to option1 to use state variable for shutdown ops.
tmp patch as in here[1] to use set_wake.
--
Thanks,
Govindraj.R
[1]:
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 9c4c05b..c176ff2 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1426,6 +1426,9 @@ static void uart_port_shutdown(struct tty_port *port)
*/
uport-ops-shutdown(uport);
+ if (uport-ops-set_wake)
+ uport-ops-set_wake(uport, false);
+
/*
* Ensure that the IRQ handler isn't running on another CPU.
*/
@@ -1512,6 +1515,9 @@ static int uart_open(struct tty_struct *tty,
struct file *filp)
goto err_dec_count;
}
+ if (uport-ops-set_wake)
+ uport-ops-set_wake(uport, true);
+
/*
* Make sure the device is in D0 state.
*/
--
To unsubscribe from this list: send the line unsubscribe 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] tty: omap-serial: Keep the wakeup mechanism enabled by default
On Thu, Apr 19, 2012 at 12:38 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: The point is that wakeups should be enabled whenever driver is in use, and disabled when the driver is not in use. Which is the tty_port methods for initialisation and shutdown, which are mutex protected against each other and hang up. Not sure how the uart layer glue exposes that. Is it okay to read the port flags to identify the port state in driver whether the serial port shutdown ops is called from port_suspend or due to port closure. Since port_shutdown gets called even from uart_suspend_port Is things like test_bit(ASYNCB_SUSPENDED, port-flags); or test_bit(ASYNCB_CLOSING, port-flags); allowed in low level driver ? -- 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] tty: omap-serial: Keep the wakeup mechanism enabled by default
On Wed, Apr 18, 2012 at 4:55 AM, Kevin Hilman khil...@ti.com wrote: Govindraj.R govindraj.r...@ti.com writes: From: Govindraj.R govindraj.r...@ti.com The wakeups can be left enabled by default and should be disabled only when disabled from sysfs and while entering suspend. Left enabled? That assumes something else has initizlied them, but we can't make that assumption. First, wakeups should be disabled when -probe has finished. Then, they should be enabled whenever driver is in use, and disabled when the driver is not in use. I'm not familiar enough with uart_ops, but it looks like they should probably be enabled in uart_ops-startup and disabled in uart_ops-shutdown. uart_ops-shutdown gets called in suspend path also serial_omap_suspend = uart_suspend_port = ops-shutdown(uport); This will leave uart wakeup disabled in suspend path. -- 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 2/2] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup
On Tue, Apr 17, 2012 at 7:11 AM, Tony Lindgren t...@atomide.com wrote:
Hi,
Few more comments below.
* Raja, Govindraj govindraj.r...@ti.com [120411 04:53]:
...
+static int __init omap_serial_fill_default_pads(struct omap_board_data
*bdata,
+ struct omap_uart_state *uart)
+{
+ struct omap_mux_partition *tx_partition = NULL, *rx_partition = NULL;
+ struct omap_mux *rx_mux = NULL, *tx_mux = NULL;
+ char *rx_fmt, *tx_fmt;
+ int uart_nr = bdata-id + 1;
+
+ if (bdata-id != 2) {
+ rx_fmt = uart%d_rx.uart%d_rx;
+ tx_fmt = uart%d_tx.uart%d_tx;
+ } else {
+ rx_fmt = uart%d_rx_irrx.uart%d_rx_irrx;
+ tx_fmt = uart%d_tx_irtx.uart%d_tx_irtx;
+ }
+
+ snprintf(rx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN, rx_fmt,
+ uart_nr, uart_nr);
+ snprintf(tx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN, tx_fmt,
+ uart_nr, uart_nr);
This naming won't work for the fourth port on 3630 as there are no uart4_rx
or uart4_tx mux entries, they are gpmc_wait2.uart4_tx and
gpmc_wait3.uart4_tx.
But uart4 is unused on 3630 boards and boards trying to use them
should configure them from board file.
(I thought we agreed on this approach where only if uarts are
available in mux mode0 those ports will be dynamically muxed for wakeup
others should use omap_serial_init_port)
@@ -289,8 +354,8 @@ void __init omap_serial_board_init(struct
omap_uart_port_info *info)
bdata.pads = NULL;
bdata.pads_cnt = 0;
- if (cpu_is_omap44xx() || cpu_is_omap34xx())
- omap_serial_fill_default_pads(bdata);
+ if (omap_serial_fill_default_pads(bdata, uart))
+ continue;
if (!info)
omap_serial_init_port(bdata, NULL);
Can't the omap_serial_board_init() now be just be omap_serial_init(void)
as it's not used anywhere else?
Yes sure we can remove that.
Anyways, this is getting too complex for the -rc series as at least 2430sdp
is using alternative pins for the first uart. Let's patch to remove just
the uart4 entry for 3630 for the -rc and then we can properly fix this
for the next merge window.
Okay. in that case the earlier patch [1] should be fine to solve the
gpmc issue observed
and ehci issue on beagle-xm.
--
Thanks,
Govindraj.R
[1]:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/090961.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: [GIT PULL]: omap-serial updates for 3.4-rc
Hi Tony, On Tue, Apr 10, 2012 at 3:36 PM, Raja, Govindraj govindraj.r...@ti.com wrote: CC'ing Linux-ARM On Tue, Apr 10, 2012 at 3:32 PM, Govindraj.R govindraj.r...@ti.com wrote: Hi Tony, Please Pull the following omap uart changes. Changes basically involves getting rid of cpu checks for populating erratas and features and move the same from serial.c to omap-serial.c, MVR reg is used to find uart versions and errata flags are populated accordingly. here [1] is the updated pull request I have incorporated even the serial mux fixes done along with previous changes. -- Thanks, Govindraj.R [1]: The following changes since commit e816b57a337ea3b755de72bec38c10c864f23015: Linux 3.4-rc3 (2012-04-15 18:28:29 -0700) are available in the git repository at: git://gitorious.org/linux-3-x/omap-serial.git for_3.4/uart_fixes for you to fetch changes up to 32b41c3c98aa652470ca42d1f0be4b558602babb: OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup (2012-04-16 12:25:14 +0530) Govindraj.R (5): OMAP2+: UART: Remove cpu checks for populating errata flags OMAP2+: UART: enable tx wakeup bit for wer reg OMAP2+: UART: replace omap34xx/omap4xx cpu checks with not omap24xx OMAP2+: UART: Fix incorrect population of default uart pads OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup arch/arm/mach-omap2/mux.c |3 +- arch/arm/mach-omap2/mux.h | 10 ++ arch/arm/mach-omap2/serial.c | 190 + arch/arm/plat-omap/include/plat/omap-serial.h |9 +- drivers/tty/serial/omap-serial.c | 83 +++- 5 files changed, 165 insertions(+), 130 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: serial: Fix the ocp smart idlemode handling bug
On Fri, Apr 13, 2012 at 11:25 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
The current serial UART code, while fidling with ocp idlemode bits,
forget about the smart idle wakeup bit even if it is supported by
UART IP block. This will lead to missing the module wakeup on OMAP's
where the smart idle wakeup is supported.
This was the root cause of the console sluggishness issue, I have been
observing on OMAP4 devices and also can be potential reason for some
other UART wakeup issues.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Govindraj.R govindraj.r...@ti.com
Acked-by: Govindraj.R govindraj.r...@ti.com
Adding to git://gitorious.org/linux-3-x/omap-serial.git for_3.4/uart_fixes
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/serial.c | 8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index c9503a7..b28aae1 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -108,8 +108,14 @@ static void omap_uart_set_noidle(struct platform_device
*pdev)
static void omap_uart_set_smartidle(struct platform_device *pdev)
{
struct omap_device *od = to_omap_device(pdev);
+ u8 idlemode;
- omap_hwmod_set_slave_idlemode(od-hwmods[0], HWMOD_IDLEMODE_SMART);
+ if (od-hwmods[0]-class-sysc-idlemodes SIDLE_SMART_WKUP)
+ idlemode = HWMOD_IDLEMODE_SMART_WKUP;
+ else
+ idlemode = HWMOD_IDLEMODE_SMART;
+
+ omap_hwmod_set_slave_idlemode(od-hwmods[0], idlemode);
}
#else
--
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: [GIT PULL]: omap-serial updates for 3.4-rc
On Mon, Apr 16, 2012 at 12:52 PM, Raja, Govindraj govindraj.r...@ti.com wrote: Hi Tony, On Tue, Apr 10, 2012 at 3:36 PM, Raja, Govindraj govindraj.r...@ti.com wrote: CC'ing Linux-ARM On Tue, Apr 10, 2012 at 3:32 PM, Govindraj.R govindraj.r...@ti.com wrote: Hi Tony, Please Pull the following omap uart changes. Changes basically involves getting rid of cpu checks for populating erratas and features and move the same from serial.c to omap-serial.c, MVR reg is used to find uart versions and errata flags are populated accordingly. here [1] is the updated pull request I have incorporated even the serial mux fixes done along with previous changes. Updated request [1] After adding Santosh's serial fix to use smartidle wakeup if available from hwmod. -- Thanks, Govindraj.R [1]: The following changes since commit e816b57a337ea3b755de72bec38c10c864f23015: Linux 3.4-rc3 (2012-04-15 18:28:29 -0700) are available in the git repository at: git://gitorious.org/linux-3-x/omap-serial.git for_3.4/uart_fixes for you to fetch changes up to 381772fefe13e73fc3d01c462d401785767c3775: ARM: OMAP: serial: Fix the ocp smart idlemode handling bug (2012-04-16 15:46:26 +0530) Govindraj.R (5): OMAP2+: UART: Remove cpu checks for populating errata flags OMAP2+: UART: enable tx wakeup bit for wer reg OMAP2+: UART: replace omap34xx/omap4xx cpu checks with not omap24xx OMAP2+: UART: Fix incorrect population of default uart pads OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup Santosh Shilimkar (1): ARM: OMAP: serial: Fix the ocp smart idlemode handling bug arch/arm/mach-omap2/mux.c |3 +- arch/arm/mach-omap2/mux.h | 10 ++ arch/arm/mach-omap2/serial.c | 198 + arch/arm/plat-omap/include/plat/omap-serial.h |9 +- drivers/tty/serial/omap-serial.c | 83 ++- 5 files changed, 172 insertions(+), 131 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: omap-serial: transmission of x-char with DMA (and other issues)
On Fri, Apr 13, 2012 at 4:11 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: Can someone tell me how this works with the current omap-serial driver please? It looks to me like this has been broken when DMA support was added to the driver. Yes x-char transmission in dma case is broken will post a patch to fix this. Moreover, please look at the probe function error paths. They seem to be lacking any kind of realistic cleanup, so are a potential memory leak. I thought this is fixed in 3.4-rc3 with this commit: commit 388bc26226807fbcf4c626b81bb17a2e74aa4b1b Author: Shubhrajyoti D shubhrajy...@ti.com Date: Wed Mar 21 17:22:22 2012 +0530 omap-serial: Fix the error handling in the omap_serial probe Then there's the issue of fiddling with the xmit buffer so that it's using coherent memory in the startup and shutdown functions (why? when other serial drivers cope just fine without doing this). If we want to use DMA coherent memory there, there should be a clean way to do this, rather than going behind the upper layers. Okay I will have a look into 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: Suspend broken on 3.3?
On Thu, Apr 12, 2012 at 1:04 AM, Paul Walmsley p...@pwsan.com wrote:
Hi
a few brief comments based on a quick scan:
On Wed, 11 Apr 2012, Raja, Govindraj wrote:
Here is the patch [1] to do the same.
- I don't see where it affects I/O wakeups for the UART. If I/O wakeups
are still set on the UART pads, won't that still wake the chip up from
suspend, even if module-level wakeups are disabled?
pdata-enable_wakeup = omap_uart_enable_wakeup
was disabling both module level and pad wakeup.
omap_uart_enable_wakeup = has enabling/disabling both
module level and pad wakeup together.
- The UART driver and integration code should not be reading from or
writing to registers outside the UART IP block. PRM register reads and
writes belong in the PRM code, which should then export a higher-level
interface to the calling code. This is because, aside from making the
code easier to read and debug, we're trying to move the PRM and CM code to
drivers/.
okay.
- The code to change the PM_WKEN* and test the PM_WKST* bits should
probably be called from omap_hwmod_{enable,disable}_wakeup(), not the UART
code directly. The UART code shouldn't need to care about the hardware
details; it should just ask the integration layer to enable or disable
module-level wakeups.
To implement this I plan to extend the omap_hwmod_omap2_prcm structure
like this:
(unaligned tmp code snippet)
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 8070145..5c7711b 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -343,6 +343,8 @@ struct omap_hwmod_class_sysconfig {
* @idlest_reg_id: IDLEST register ID (e.g., 3 for CM_IDLEST3)
* @idlest_idle_bit: register bit shift for CM_IDLEST slave idle bit
* @idlest_stdby_bit: register bit shift for CM_IDLEST master standby bit
+ * @module_wakeup_offs: PRCM register offset for PM_WKEN
+ * @module_wakeup_bit: regiter bit mask for PM_WKEN
*
* @prcm_reg_id and @module_bit are specific to the AUTOIDLE, WKST,
* WKEN, GRPSEL registers. In an ideal world, no extra information
@@ -357,6 +359,8 @@ struct omap_hwmod_omap2_prcm {
u8 idlest_reg_id;
u8 idlest_idle_bit;
u8 idlest_stdby_bit;
+ s16 module_wakeup_offs;
+ u32 module_wakeup_bit;
};
As you work on these changes, please split them up into several different
topic series - one for the PRM changes, one for hwmod code/data changes,
and one for the UART driver/integration changes. Just note the
dependencies in the series description E-mails. That way, we can avoid
merge conflicts.
Yes fine. Since most changes will be on /mach-omap2/omap_hwmod*.c
Do you prefer the patches to be on any particular tree/branch where hwmod fixes
are already queued.
--
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 2/2] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup
On Tue, Apr 10, 2012 at 9:41 PM, Tony Lindgren t...@atomide.com wrote:
* Govindraj.R govindraj.r...@ti.com [120410 06:44]:
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -120,11 +120,63 @@ static void omap_uart_set_smartidle(struct
platform_device *pdev) {}
#endif /* CONFIG_PM */
#ifdef CONFIG_OMAP_MUX
-static void omap_serial_fill_default_pads(struct omap_board_data *bdata)
+
+#define OMAP_UART_DEFAULT_PAD_NAME_LEN 28
+static char rx_pad_name[OMAP_UART_DEFAULT_PAD_NAME_LEN],
+ tx_pad_name[OMAP_UART_DEFAULT_PAD_NAME_LEN] __initdata;
+static struct omap_device_pad default_omap_uart_pads[2] __initdata;
Won't the default_omap_uart_pads get overwritten for each port?
We need that information in the driver too for each port? Why don't you
just allocate bdata.pads in omap_serial_board_init as we now assume it's
needed for each port?
Yes can be part of omap_uart_state structure.
+static void __init omap_serial_fill_default_pads(struct omap_board_data
*bdata)
{
+ struct omap_mux_partition *tx_partition = NULL, *rx_partition = NULL;
+ struct omap_mux *rx_mux = NULL, *tx_mux = NULL;
+
+ if (bdata-id != 2) {
+ snprintf(rx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN,
+ uart%d_rx.uart%d_rx, bdata-id + 1, bdata-id + 1);
+ snprintf(tx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN,
+ uart%d_tx.uart%d_tx, bdata-id + 1, bdata-id + 1);
+ } else {
+ snprintf(rx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN,
+ uart%d_rx_irrx.uart%d_rx_irrx, bdata-id + 1,
+ bdata-id + 1);
+ snprintf(tx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN,
+ uart%d_tx_irtx.uart%d_tx_irtx, bdata-id + 1,
+ bdata-id + 1);
+ }
This would be simpler with something like this (untested):
char *rx_fmt, *tx_fmt;
int uart_nr = bdata-id + 1;
if (bdata-id == 2) {
rx_fmt = uart%d_rx.uart%d_rx;
tx_fmt = uart%d_tx.uart%d_tx;
} else {
rx_fmt = uart%d_rx_irrx.uart%d_rx_irrx;
tx_fmt = uart%d_tx_irtx.uart%d_tx_irtx;
}
snprintf(rx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN, rx_fmt,
uart_nr, uart_nr);
snprintf(tx_pad_name, OMAP_UART_DEFAULT_PAD_NAME_LEN, tx_fmt,
uart_nr, uart_nr);
okay fine.
+ if (omap_mux_get_by_name(rx_pad_name, rx_partition, rx_mux) = 0
+ omap_mux_get_by_name
+ (tx_pad_name, tx_partition, tx_mux) = 0) {
+ u16 tx_mode, rx_mode;
+
+ tx_mode = omap_mux_read(tx_partition, tx_mux-reg_offset);
+ rx_mode = omap_mux_read(rx_partition, rx_mux-reg_offset);
+
+ /*
+ * Check if uart is used in default tx/rx mode i.e. in mux
mode0
+ * if yes then configure rx pin for wake up capability
+ */
+ if (!(rx_mode 0x07) !(tx_mode 0x07)) {
+ default_omap_uart_pads[0].name = rx_pad_name;
+ default_omap_uart_pads[0].flags =
+ OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP;
+ default_omap_uart_pads[0].enable = OMAP_PIN_INPUT |
+ OMAP_MUX_MODE0;
+ default_omap_uart_pads[0].idle = OMAP_PIN_INPUT |
+ OMAP_MUX_MODE0;
+
+ default_omap_uart_pads[1].name = tx_pad_name;
+ default_omap_uart_pads[1].enable = OMAP_PIN_OUTPUT |
+ OMAP_MUX_MODE0;
+ bdata-pads = default_omap_uart_pads;
+ bdata-pads_cnt = ARRAY_SIZE(default_omap_uart_pads);
+ }
+ }
}
Then looking at omap_serial_board_init, it still looks wrong:
void __init omap_serial_board_init(struct omap_uart_port_info *info)
{
struct omap_uart_state *uart;
struct omap_board_data bdata;
list_for_each_entry(uart, uart_list, node) {
bdata.id = uart-num;
bdata.flags = 0;
bdata.pads = NULL;
bdata.pads_cnt = 0;
if (cpu_is_omap44xx() || cpu_is_omap34xx())
omap_serial_fill_default_pads(bdata);
Why don't you fill the pads for omap2? It has the same pads, although
it does not have the serial wake-up events working.
And why don't you exit if omap_serial_fill_default_pads fails for the
no info case?
Shouldn't it be something like:
if (!info) {
res = omap_serial_fill_default_pads(bdata);
if (!res)
return;
Re: Suspend broken on 3.3?
On Tue, Apr 10, 2012 at 11:33 PM, Kevin Hilman khil...@ti.com wrote:
Raja, Govindraj govindraj.r...@ti.com writes:
Hi Kevin,
On Mon, Apr 9, 2012 at 10:40 PM, Kevin Hilman khil...@ti.com wrote:
Paul Walmsley p...@pwsan.com writes:
[...]
Just to summarize on how the behavior should be IIUC if user disables uart
wakeup from sysfs and does system wide suspend it should _not_ wakeup
from uart.
Correct.
And if the system is woken up from suspend due to keypad press and
uart resumes we have keep module level wakeup enabled from here.
Keypad press, or any other wakeup source, yes.
Basically, UART wakeups (module and IO) should be enabled all the time,
*except* when suspending and wakeups were disabled by sysfs control.
Here is the patch [1] to do the same.
Tested on beagle-XM with retention and off mode in suspend path and
idle path by disabling/enabling the uart wakeups from sysfs for the console.
--
Thanks,
Govindraj.R
[1]:
From 4e2502015e8b69d3a5047ae9f92820e4833e6d74 Mon Sep 17 00:00:00 2001
From: Govindraj.R govindraj.r...@ti.com
Date: Tue, 27 Mar 2012 18:55:00 +0530
Subject: [PATCH] OMAP2+: UART: Correct the module level wakeup enable/disable
mechanism
The commit (62f3ec5 ARM: OMAP2+: UART: Add wakeup mechanism for omap-uarts)
removed module level wakeup enable/disable mechanism and retained only
the pad wakeup handling.
On 24xx/34xx/36xx Module level wakeup events are enabled/disabled using
PM_WKEN1_CORE/PM_WKEN_PER regs. The module level wakeups are enabled by
default from bootloader, however the wakeups can be enabled/disabled
using sysfs entry
echo disabled /sys/devices/platform/omap/omap_uart.X/power/wakeup
[X=0,1,2,3]
Since module level wakeups were left enabled from bootup and when
wakeups were disabled from sysfs uart module level wakeups were
still happening as they were not getting disabled.
The wakeup can be left enabled by default and should be disabled only
when disabled from sysfs and thus prevent system from uart wakeup in suspend
path. However in idle path the wakeup can be enabled and thus uart can wakeup
after gating of uart functional clocks.
Thanks to Kevin Hilman khil...@ti.com for suggesting this.
Discussion References:
http://www.spinics.net/lists/linux-omap/msg67764.html
http://www.spinics.net/lists/linux-omap/msg67838.html
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 88 +-
drivers/tty/serial/omap-serial.c | 30 +
2 files changed, 97 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0cdd359..9312d6b 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -41,6 +41,7 @@
#include prm-regbits-34xx.h
#include control.h
#include mux.h
+#include iomap.h
/*
* NOTE: By default the serial auto_suspend timeout is disabled as it causes
@@ -55,6 +56,10 @@
struct omap_uart_state {
int num;
+ void __iomem *wk_st;
+ void __iomem *wk_en;
+ u32 wk_mask;
+
struct list_head node;
struct omap_hwmod *oh;
};
@@ -80,17 +85,46 @@ static struct omap_uart_port_info
omap_serial_default_info[] __initdata = {
};
#ifdef CONFIG_PM
+
+static void omap_uart_disable_module_wakeup(struct omap_uart_state *uart)
+{
+ /* Clear wake-enable bit */
+ if (uart-wk_en uart-wk_mask) {
+ u32 v = __raw_readl(uart-wk_en);
+ v = ~uart-wk_mask;
+ __raw_writel(v, uart-wk_en);
+ }
+}
+
+static void omap_uart_enable_module_wakeup(struct omap_uart_state *uart)
+{
+ /* Set wake-enable bit */
+ if (uart-wk_en uart-wk_mask) {
+ u32 v = __raw_readl(uart-wk_en);
+ v |= uart-wk_mask;
+ __raw_writel(v, uart-wk_en);
+ }
+}
+
static void omap_uart_enable_wakeup(struct platform_device *pdev, bool enable)
{
struct omap_device *od = to_omap_device(pdev);
+ struct omap_uart_state *uart;
if (!od)
return;
- if (enable)
+ list_for_each_entry(uart, uart_list, node)
+ if (pdev-id == uart-num)
+ break;
+
+ if (enable) {
+ omap_uart_enable_module_wakeup(uart);
omap_hwmod_enable_wakeup(od-hwmods[0]);
- else
+ } else {
+ omap_uart_disable_module_wakeup(uart);
omap_hwmod_disable_wakeup(od-hwmods[0]);
+ }
}
/*
@@ -112,7 +146,56 @@ static void omap_uart_set_smartidle(struct
platform_device *pdev)
omap_hwmod_set_slave_idlemode(od-hwmods[0], HWMOD_IDLEMODE_SMART);
}
+static void omap_uart_idle_init(struct omap_uart_state *uart)
+{
+ if (cpu_is_omap34xx() !cpu_is_ti816x()) {
+ u32 mod = (uart-num == 2) ? OMAP3430_PER_MOD : CORE_MOD;
+
+ uart-wk_en = OMAP34XX_PRM_REGADDR(mod, PM_WKEN1);
+ uart-wk_st = OMAP34XX_PRM_REGADDR(mod, PM_WKST1
Re: Suspend broken on 3.3?
Hi Kevin, On Mon, Apr 9, 2012 at 10:40 PM, Kevin Hilman khil...@ti.com wrote: Paul Walmsley p...@pwsan.com writes: [...] I don't understand why a user would ever want to disable dynamic wakeups on an in-use serial port via the sysfs power/wakeup file. (Disabling wakeups from suspend is a different matter, of course.) The OMAP UART driver needs hardware wakeups to function for FIFO drain wakeups, etc. So to me it really doesn't make sense to disable those types of wakeup events, ever. But maybe you know of some use-case that I don't? No, I don't have a use-case in mind. The more I try to remember why we added support to use the sysfs wakeup attribute to manage idle, the more I think we can probably drop it now. IIRC, it was added because on most boards we used to blindly initialize all the UARTs, including default wakeup settings (we still do this on many boards.) However, now that we have a real PM-aware driver for OMAP UARTs, this should all be handled from the driver itself, so the sysfs wakeup attribute should go back to only managing wakeups from suspend and wakeups during idle should always be on for in-use UARTs. Just to summarize on how the behavior should be IIUC if user disables uart wakeup from sysfs and does system wide suspend it should _not_ wakeup from uart. And if the system is woken up from suspend due to keypad press and uart resumes we have keep module level wakeup enabled from here. We might need some minor changes in omap-serial to have this behavior which I plan to do once we are aligned on 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: [GIT PULL]: omap-serial updates for 3.4-rc
CC'ing Linux-ARM On Tue, Apr 10, 2012 at 3:32 PM, Govindraj.R govindraj.r...@ti.com wrote: Hi Tony, Please Pull the following omap uart changes. Changes basically involves getting rid of cpu checks for populating erratas and features and move the same from serial.c to omap-serial.c, MVR reg is used to find uart versions and errata flags are populated accordingly. -- Thanks, Govindraj.R The following changes since commit 0034102808e0dbbf3a2394b82b1bb40b5778de9e: Linux 3.4-rc2 (2012-04-07 18:30:41 -0700) are available in the git repository at: git://gitorious.org/linux-3-x/omap-serial.git for_3.4/uart_fixes for you to fetch changes up to 6c34f211069409ea6d08b900eeaf86ef8efd0dca: OMAP2+: UART: replace omap34xx/omap4xx cpu checks with not omap24xx (2012-04-10 15:14:58 +0530) Govindraj.R (3): OMAP2+: UART: Remove cpu checks for populating errata flags OMAP2+: UART: enable tx wakeup bit for wer reg OMAP2+: UART: replace omap34xx/omap4xx cpu checks with not omap24xx arch/arm/mach-omap2/serial.c | 13 +--- arch/arm/plat-omap/include/plat/omap-serial.h | 9 +++- drivers/tty/serial/omap-serial.c | 83 - 3 files changed, 91 insertions(+), 14 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH] ARM :OMAP2+: UART: Remove some of uart default pads
Hi Tony,
On Fri, Apr 6, 2012 at 11:45 PM, Tony Lindgren t...@atomide.com wrote:
* Raja, Govindraj govindraj.r...@ti.com [120405 23:08]:
On Thu, Apr 5, 2012 at 10:28 PM, Tony Lindgren t...@atomide.com wrote:
Hmm I don't think any muxing was done automatically unless
omap_serial_init_port was being called with pins.
Muxing was happening even if we don't call omap_serial_init_port
rx pin was muxed for wakeup capability for all uart pins
OK, but that was only for the wake-up muxing? That sounds risky
too for some boards as the board may be using alternative uart
pins instead of the default ones.
omap_uart_idle_init = was populating padconf offset value for ech uart
which was used in omap_uart_enable/disable_wakeup functions.
This mechanism was keeping PM happening for all boards.
OK, that's safe if we also bail out for the cases where the default
uart pins are not muxed to serial functionality to start with.
So to summarize, the right fix is to:
1. Only do muxing of uarts from other modes to uart mode if
omap_serial_init_port is being called with the board specific
mux options for the port in question.
2. Bail out early in omap_serial_init for each port that does not
have it's default uart pins already muxed to uart functionality.
3. For the uart ports configured in #1 or #2 above, allow dynamic
remuxing of the wake-up capability but don't touch the others.
Thanks for the review and suggestions, here is the patch [1] to do the same.
I tested this patch on beagle-xm where uart pin mux was causing clash
with usb ehci hub gpio nrest pin, now with this patch smsc hub + ethernet
get enumerated.
--
Thanks,
Govindraj.R
[1]:
From 37850b9e80fc4dac050bff5b6dbb67c245be43cc Mon Sep 17 00:00:00 2001
From: Govindraj.R govindraj.r...@ti.com
Date: Mon, 9 Apr 2012 15:16:52 +0530
Subject: [PATCH] ARM: OMAP2+: UART: Fix usage of default uart pads.
The following commit:
(7496ba3 ARM: OMAP2+: UART: Add default mux for all uarts)
added default pads for all uarts. But not all boards tend to
use all uarts and most of unused uart pins are muxed for
other purpose. This commit breaks the modules which where trying
to use unused uart pins on their boards.
So check for the availability of uart pins before filling the pads
if both tx and rx are available as uart pins then use them for
filling as default pads where rx pin is muxed dynamically for
rx wakeup capability.
However the board file owners can use omap_serial_init_port
and pass mux data part of board data for board specific use cases.
Cc: Felipe Balbi ba...@ti.com
Cc: Kevin Hilman khil...@ti.com
Reported-by: Tony Lindgren t...@atomide.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/mux.c|2 +-
arch/arm/mach-omap2/mux.h| 10 +++
arch/arm/mach-omap2/serial.c | 158 --
3 files changed, 56 insertions(+), 114 deletions(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 65c3391..5334914 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -217,7 +217,7 @@ static int __init _omap_mux_get_by_name(struct
omap_mux_partition *partition,
return -ENODEV;
}
-static int __init
+int __init
omap_mux_get_by_name(const char *muxname,
struct omap_mux_partition **found_partition,
struct omap_mux **found_mux)
diff --git a/arch/arm/mach-omap2/mux.h b/arch/arm/mach-omap2/mux.h
index 69fe060..461b90d 100644
--- a/arch/arm/mach-omap2/mux.h
+++ b/arch/arm/mach-omap2/mux.h
@@ -225,8 +225,18 @@ omap_hwmod_mux_init(struct omap_device_pad
*bpads, int nr_pads);
*/
void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state);
+int omap_mux_get_by_name(const char *muxname,
+struct omap_mux_partition **found_partition,
+struct omap_mux **found_mux);
#else
+static inline int omap_mux_get_by_name(const char *muxname,
+struct omap_mux_partition **found_partition,
+struct omap_mux **found_mux)
+{
+ return 0;
+}
+
static inline int omap_mux_init_gpio(int gpio, int val)
{
return 0;
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0cdd359..30a0f4e 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -120,127 +120,59 @@ static void omap_uart_set_smartidle(struct
platform_device *pdev) {}
#endif /* CONFIG_PM */
#ifdef CONFIG_OMAP_MUX
-static struct omap_device_pad default_uart1_pads[] __initdata = {
- {
- .name = uart1_cts.uart1_cts,
- .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
- },
- {
- .name = uart1_rts.uart1_rts,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
- },
- {
- .name = uart1_tx.uart1_tx,
- .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0
Re: Suspend broken on 3.3?
Hi Kevin / Paul, On Fri, Apr 6, 2012 at 7:51 PM, Kevin Hilman khil...@ti.com wrote: Paul Walmsley p...@pwsan.com writes: On Wed, 4 Apr 2012, Raja, Govindraj wrote: On Wed, Apr 4, 2012 at 8:26 PM, Paul Walmsley p...@pwsan.com wrote: On Mon, 2 Apr 2012, Raja, Govindraj wrote: As of now what I can think of is to update qos reqest to prevent MPU from transitioning in case of port activity if wakeup capability for port is disabled. Haven't been following this thread closely, but this doesn't seem right. Why would changing the UART driver's ability to wake from suspend via the sysfs file prevent the driver from using hardware wakeups to wake from dynamic idle? IIUC wakeup capability is needed in suspend path or in cpu idle path. once uart wakeup capability is disabled from sysfs the Module level wakeup from PM_WKEN1 reg on omap3 and pad wakeup from pin mux data given will be disabled.. As far as I know, that sysfs wakeup file is not meant to disable all module-level wakeup. Kevin can correct me if I'm wrong, but I think it's only supposed to control wakeup from suspend. In theory, sysfs control is meant for static suspend. ISTR though that we were using it for idle as well so there weren't unncessary UART wakeups from idle on UART activity that was not serial console. So incase of uart wakeups are disabled and uart tx/rx is requested can we prevent MPU from low power state. -- 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: [RESEND PATCH] ARM :OMAP2+: UART: Remove some of uart default pads
On Thu, Apr 5, 2012 at 10:28 PM, Tony Lindgren t...@atomide.com wrote: * Raja, Govindraj govindraj.r...@ti.com [120403 23:18]: On Tue, Apr 3, 2012 at 11:49 PM, Tony Lindgren t...@atomide.com wrote: * Govindraj.R govindraj.r...@ti.com [120321 03:06]: From: Govindraj.R govindraj.r...@ti.com The following commit: (7496ba3 ARM: OMAP2+: UART: Add default mux for all uarts) added default pads for all uarts. But not all boards tend to use all uarts and most of unused uart pins are muxed for other purpose. This commit breaks the modules which where trying to use unused uart pins on their boards. So remove all default pads except uart1/3 as most boards tend to use either uart1/3 as console port and use only tx/rx lines, declare only those pads for uart1/3. If any boards tend to use any other uart other uart1/3 the mux data should to passed from board file and init individual uart port using omap_serial_init_port api. This is still wrong. We can't mux any serial pins unless specifically requested from the board-*.c files. So please do a fix to get back to v3.2 behaviour where you basically revert 7496ba3. How to do we fix the rx pin wakeup capability? The mux data has the info about the rx pin wakeup Without rx pin wakeup PM will be broken. Let's first make things work reliably before even getting started about PM being broken. okay. Fix all board files with duplicated data for uart3 or uart1 having rx pin marked as wakeup capable? And how do you know which pins to mux? You don't, unless you look at the schematics for all the boards. agree even I am not sure of uarts used for console on all boards The only safe option without looking at the schematics is to make omap_serial_init not do any muxing. If you want muxing and PM wake-up events, then use omap_serial_init_port for those ports with board specific pins. okay. Behavior in v3.2 was raw_write to all uarts rx_pin to enable wakeup enable bit. Hmm I don't think any muxing was done automatically unless omap_serial_init_port was being called with pins. Muxing was happening even if we don't call omap_serial_init_port rx pin was muxed for wakeup capability for all uart pins omap_uart_idle_init = was populating padconf offset value for ech uart which was used in omap_uart_enable/disable_wakeup functions. This mechanism was keeping PM happening for all boards. -- 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: OMAP3EVM not booting on l-o master
Hi Afzal, On Thu, Apr 5, 2012 at 3:47 PM, Paul Walmsley p...@pwsan.com wrote: cc Tony Hi, On Thu, 5 Apr 2012, Mohammed, Afzal wrote: On Thu, Apr 05, 2012 at 15:03:36, Paul Walmsley wrote: Could you try booting with initcall_debug and posting the boot log? Logs as follows, thanks. ... [ 6.065307] calling omap_mux_late_init+0x0/0x1a0 @ 1 Looks like a mux-related problem. Tony recently found some mux-related bugs that got merged with the v3.3 mach-omap2/serial.c - I wonder if they might be affecting your board too? Can you try this patch [1], Just to confirm its serial mux issue however still the patch is not aligned on how to fix it. -- Thanks, Govindraj.R [1]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg65347.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 0/3] OMAP2+: UART: Enable tx wakeup + remove cpu checks
On Wed, Mar 21, 2012 at 3:54 PM, Govindraj.R govindraj.r...@ti.com wrote: From: Govindraj.R govindraj.r...@ti.com Based on Linux-OMAP tree uart branch. (git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git remotes/origin/uart) * Removes the cpu checks wherever possible and use version reg for populating features and errata's * enable tx wakeup available in wer reg for applicable module revision's Govindraj.R (3): OMAP2+: UART: Remove cpu checks for populating errata flags OMAP2+: UART: enable tx wakeup bit for wer reg OMAP2+: UART: replace omap34xx/omap4xx cpu checks with not omap24xx arch/arm/mach-omap2/serial.c | 13 + arch/arm/plat-omap/include/plat/omap-serial.h | 8 +++- drivers/tty/serial/omap-serial.c | 71 - 3 files changed, 78 insertions(+), 14 deletions(-) Alan / Greg, With you ack on tty parts can this series be upstreamed from omap tree ? Tony, Can you take these series into your uart fixes branch for 3.4-rc (Let me know if you need a pull request with patches based on linux-omap tree uart branch) -- 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: [RESEND PATCH] ARM :OMAP2+: UART: Remove some of uart default pads
On Tue, Apr 3, 2012 at 11:49 PM, Tony Lindgren t...@atomide.com wrote: * Govindraj.R govindraj.r...@ti.com [120321 03:06]: From: Govindraj.R govindraj.r...@ti.com The following commit: (7496ba3 ARM: OMAP2+: UART: Add default mux for all uarts) added default pads for all uarts. But not all boards tend to use all uarts and most of unused uart pins are muxed for other purpose. This commit breaks the modules which where trying to use unused uart pins on their boards. So remove all default pads except uart1/3 as most boards tend to use either uart1/3 as console port and use only tx/rx lines, declare only those pads for uart1/3. If any boards tend to use any other uart other uart1/3 the mux data should to passed from board file and init individual uart port using omap_serial_init_port api. This is still wrong. We can't mux any serial pins unless specifically requested from the board-*.c files. So please do a fix to get back to v3.2 behaviour where you basically revert 7496ba3. How to do we fix the rx pin wakeup capability? The mux data has the info about the rx pin wakeup Without rx pin wakeup PM will be broken. Fix all board files with duplicated data for uart3 or uart1 having rx pin marked as wakeup capable? Behavior in v3.2 was raw_write to all uarts rx_pin to enable wakeup enable bit. -- 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: Suspend broken on 3.3?
On Wed, Apr 4, 2012 at 8:26 PM, Paul Walmsley p...@pwsan.com wrote: Hello Govindraj On Mon, 2 Apr 2012, Raja, Govindraj wrote: As of now what I can think of is to update qos reqest to prevent MPU from transitioning in case of port activity if wakeup capability for port is disabled. Haven't been following this thread closely, but this doesn't seem right. Why would changing the UART driver's ability to wake from suspend via the sysfs file prevent the driver from using hardware wakeups to wake from dynamic idle? IIUC wakeup capability is needed in suspend path or in cpu idle path. once uart wakeup capability is disabled from sysfs the Module level wakeup from PM_WKEN1 reg on omap3 and pad wakeup from pin mux data given will be disabled.. So after we enter suspend and wakeup from suspend using keypad press, now through pm workqueue the MPU enters retention and uart module level wakeups disabled at this point console becomes slower to respond. Now enabling wakeups from sysfs enter suspend/resume to enable wakeups and once we come back from wakeup console response is better. So disabling uart module level wake up and allowing MPU to enter retention is making console slow. -- 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: 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: 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
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 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: 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: [PATCH] ARM: OMAP: USB: fix warning on EHCI PHY reset path
On Wed, Mar 28, 2012 at 2:22 PM, Felipe Balbi ba...@ti.com wrote: On Tue, Mar 27, 2012 at 04:08:55PM +0200, Igor Grinberg wrote: When PHY reset pin is connected to a GPIO on external GPIO chip (e.g. I2C), we should not call the gpio_set_value() function, but gpio_set_value_cansleep(). Signed-off-by: Igor Grinberg grinb...@compulab.co.il Acked-by: Felipe Balbi ba...@ti.com Keshava, please give us your tested-by. Patch looks fine to me. Tried on beagle-xm where the smsc hub + smsc95xx ethernet controller relies gpio nreset sequence for initialization. Both hub + Ethernet controller get enumerated even after this patch. Tested-by: Govindraj.R govindraj.r...@ti.com --- This patch depends on the patch from Keshava [1]: ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue [1] http://www.spinics.net/lists/linux-omap/msg66774.html drivers/usb/host/ehci-omap.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index 5c78f9e..26e9241 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -258,10 +258,10 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev) udelay(10); if (gpio_is_valid(pdata-reset_gpio_port[0])) - gpio_set_value(pdata-reset_gpio_port[0], 1); + gpio_set_value_cansleep(pdata-reset_gpio_port[0], 1); if (gpio_is_valid(pdata-reset_gpio_port[1])) - gpio_set_value(pdata-reset_gpio_port[1], 1); + gpio_set_value_cansleep(pdata-reset_gpio_port[1], 1); } return 0; -- 1.7.3.4 -- balbi -- To unsubscribe from this list: send the line unsubscribe 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 Wed, Mar 28, 2012 at 3:07 AM, Kevin Hilman khil...@ti.com wrote:
Raja, Govindraj govindraj.r...@ti.com writes:
Hi Kevin,
On Tue, Mar 27, 2012 at 6:04 AM, Kevin Hilman khil...@ti.com wrote:
+Govindraj,
Joe Woodward j...@terrafix.co.uk writes:
Right, I've stepped back a bit and dug out a GUSMTIX Palo43 carrier
board on which to test the Overo OMAP3530 COM and I've found:
- Running a stock 3.3 (with absolutely no changes) does indeed suspend
correctly.
- Running the 3.3 kernel with my (minor) board modifications
(basically defining some buttons) suspends correctly as well.
Then I went back to my original board and the 3.3 still wakes up from
suspend immediately. So I had a think, and the only real differences
between my board the the GUMSTIX Palo43 board is that I am using
multiple UARTs.
Up to this point I've only wanted to wake on the console (ttyO2), and
not any other UARTs so I've stopped them waking with:
echo disabled /sys/devices/platform/omap/omap_uart.0/power/wakeup
echo disabled /sys/devices/platform/omap/omap_uart.1/power/wakeup
I wanted to check that this still worked, so tried disabling wakeup on
the console (ttyO2):
echo disabled /sys/devices/platform/omap/omap_uart.2/power/wakeup
And if I do echo mem /sys/power/state I was expecting to stay in
suspend when I typed on my keyboard... However, the kernel still woke
from suspend, which leads me to believe that the UART wakeup hasn't
been disabled?
Just to confirm: did the above work for you before v3.3?
Could you test if this is also the case your end?
Yes, I get the same behavior, which is indeed broken.
Govindraj, can you look into this?
A quick glance suggests that disabling wakeups via the sysfs file is
only disabling runtime PM, but not actually disabling wakups at the
module-level or at the IO ring.
I have started looking into this, disabling and enabling of wake-ups
from .runtime_suspend needs some changes as in here[1] with that I see pad
wakeup getting disabled and it doesn't wake up after enabling off mode
and suspending.
Thanks for looking into this.
Looks like the module wakeup event handling left to default
value during runtime clean up is causing the wakeup to happen
Here is the patch[1] to fix the same tested on 3430SDP.
--
Thanks,
Govindraj.R
[1]:
From 5a5126750d527811547a45de9546c3e0f0fac77d Mon Sep 17 00:00:00 2001
From: Govindraj.R govindraj.r...@ti.com
Date: Tue, 27 Mar 2012 18:55:00 +0530
Subject: [PATCH] OMAP2+: UART: Correct the module level wakeup enable/disable
mechanism
The commit (62f3ec5 ARM: OMAP2+: UART: Add wakeup mechanism for omap-uarts)
removed module level wakeup enable/disable mechanism and retained only
the pad wakeup handling.
On 24xx/34xx/36xx Module level wakeup events are enabled/disabled using
PM_WKEN1_CORE/PM_WKEN_PER regs. The module level wakeups are enabled by
default from bootloader, however the wakeups can be enabled/disabled
using sysfs entry
echo disabled /sys/devices/platform/omap/omap_uart.X/power/wakeup
[X=0,1,2,3]
Since module level wakeups were left enabled from bootup and when
wakeups were disabled from sysfs uart module level wakeups were
still happening as they were not getting disabled.
Adding the support to handle module level wakeups for omap2/3 socs.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 95 +-
1 files changed, 93 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index f590afc..92ff94c 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -56,6 +56,10 @@ struct omap_uart_state {
int num;
int can_sleep;
+ void __iomem *wk_st;
+ void __iomem *wk_en;
+ u32 wk_mask;
+
struct list_head node;
struct omap_hwmod *oh;
struct platform_device *pdev;
@@ -82,17 +86,46 @@ static struct omap_uart_port_info
omap_serial_default_info[] __initdata = {
};
#ifdef CONFIG_PM
+
+static void omap_uart_disable_module_wakeup(struct omap_uart_state *uart)
+{
+ /* Clear wake-enable bit */
+ if (uart-wk_en uart-wk_mask) {
+ u32 v = __raw_readl(uart-wk_en);
+ v = ~uart-wk_mask;
+ __raw_writel(v, uart-wk_en);
+ }
+}
+
+static void omap_uart_enable_module_wakeup(struct omap_uart_state *uart)
+{
+ /* Set wake-enable bit */
+ if (uart-wk_en uart-wk_mask) {
+ u32 v = __raw_readl(uart-wk_en);
+ v |= uart-wk_mask;
+ __raw_writel(v, uart-wk_en);
+ }
+}
+
static void omap_uart_enable_wakeup(struct platform_device *pdev, bool enable)
{
struct omap_device *od = to_omap_device(pdev);
+ struct omap_uart_state *uart;
if (!od)
return;
- if (enable)
+ list_for_each_entry(uart, uart_list, node)
+ if (pdev-id == uart-num
Re: [PATCH 1/3] OMAP2+: UART: Remove cpu checks for populating errata flags
On Wed, Mar 28, 2012 at 2:38 AM, Jon Hunter jon-hun...@ti.com wrote:
Hi Govindraj,
On 3/21/2012 5:24, Govindraj.R wrote:
From: Govindraj.Rgovindraj.r...@ti.com
Currently the errata is populated based on cpu checks this can
be removed and replaced with module version check of uart ip block.
MVR reg is provided within the uart reg map use the same
to populate the errata and thus now errata population and handling
can be managed within the driver itself.
Cc: Paul Walmsleyp...@pwsan.com
Cc: Kevin Hilmankhil...@ti.com
Signed-off-by: Felipe Balbiba...@ti.com
Signed-off-by: Govindraj.Rgovindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 8 ---
arch/arm/plat-omap/include/plat/omap-serial.h | 1 -
drivers/tty/serial/omap-serial.c | 62
-
3 files changed, 61 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index f590afc..330ee04 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -357,14 +357,6 @@ void __init omap_serial_init_port(struct
omap_board_data *bdata,
omap_up.dma_rx_poll_rate = info-dma_rx_poll_rate;
omap_up.autosuspend_timeout = info-autosuspend_timeout;
- /* Enable the MDR1 Errata i202 for OMAP2430/3xxx/44xx */
- if (!cpu_is_omap2420() !cpu_is_ti816x())
- omap_up.errata |= UART_ERRATA_i202_MDR1_ACCESS;
-
- /* Enable DMA Mode Force Idle Errata i291 for omap34xx/3630 */
- if (cpu_is_omap34xx() || cpu_is_omap3630())
- omap_up.errata |= UART_ERRATA_i291_DMA_FORCEIDLE;
-
pdata =omap_up;
pdata_size = sizeof(struct omap_uart_port_info);
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 9ff..1a52725 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -65,7 +65,6 @@ struct omap_uart_port_info {
bool dma_enabled; /* To specify DMA Mode */
unsigned int uartclk; /* UART clock rate */
upf_t flags; /* UPF_* flags */
- u32 errata;
unsigned int dma_rx_buf_size;
unsigned int dma_rx_timeout;
unsigned int autosuspend_timeout;
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index f809041..c7666d6 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -44,6 +44,13 @@
#includeplat/dmtimer.h
#includeplat/omap-serial.h
+#define UART_BUILD_REVISION(x, y) (((x) 8) | (y))
+
+#define OMAP_UART_REV_42 0x0402
+#define OMAP_UART_REV_46 0x0406
+#define OMAP_UART_REV_52 0x0502
+#define OMAP_UART_REV_63 0x0603
+
#define DEFAULT_CLK_SPEED 4800 /* 48Mhz*/
/* SCR register bitmasks */
@@ -1346,6 +1353,58 @@ static void uart_tx_dma_callback(int lch, u16
ch_status, void *data)
return;
}
+static void omap_serial_fill_features_erratas(struct uart_omap_port *up)
+{
+ 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.
+ 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
+ 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.
--
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: Suspend broken on 3.3?
Hi Kevin,
On Tue, Mar 27, 2012 at 6:04 AM, Kevin Hilman khil...@ti.com wrote:
+Govindraj,
Joe Woodward j...@terrafix.co.uk writes:
Right, I've stepped back a bit and dug out a GUSMTIX Palo43 carrier
board on which to test the Overo OMAP3530 COM and I've found:
- Running a stock 3.3 (with absolutely no changes) does indeed suspend
correctly.
- Running the 3.3 kernel with my (minor) board modifications
(basically defining some buttons) suspends correctly as well.
Then I went back to my original board and the 3.3 still wakes up from
suspend immediately. So I had a think, and the only real differences
between my board the the GUMSTIX Palo43 board is that I am using
multiple UARTs.
Up to this point I've only wanted to wake on the console (ttyO2), and
not any other UARTs so I've stopped them waking with:
echo disabled /sys/devices/platform/omap/omap_uart.0/power/wakeup
echo disabled /sys/devices/platform/omap/omap_uart.1/power/wakeup
I wanted to check that this still worked, so tried disabling wakeup on
the console (ttyO2):
echo disabled /sys/devices/platform/omap/omap_uart.2/power/wakeup
And if I do echo mem /sys/power/state I was expecting to stay in
suspend when I typed on my keyboard... However, the kernel still woke
from suspend, which leads me to believe that the UART wakeup hasn't
been disabled?
Just to confirm: did the above work for you before v3.3?
Could you test if this is also the case your end?
Yes, I get the same behavior, which is indeed broken.
Govindraj, can you look into this?
A quick glance suggests that disabling wakeups via the sysfs file is
only disabling runtime PM, but not actually disabling wakups at the
module-level or at the IO ring.
I have started looking into this, disabling and enabling of wake-ups
from .runtime_suspend needs some changes as in here[1] with that I see pad
wakeup getting disabled and it doesn't wake up after enabling off mode
and suspending.
If clocks left enabled form uart driver during system wide suspend
- _od_suspend_noirq
- .runtime_suspend from uart driver (with [1])
- omap_hwmod_disable_wakeup
- omap_device_idle
But module level wakeup from sysc reg also needs to be disabled,
with which I see some strange behavior, even though _disable_wakeup
updates sysc reg it seem to wakeup, but removing SYSC_HAS_ENAWAKEUP
flag from .sysc flags from hmwod data I see module level wakeup failing after
disabling wakeup. Still checking on this.
--
Thanks,
Govindraj.R
[1]:
From 7f92f73006a82fdd7328fe7906fbf094b503cd13 Mon Sep 17 00:00:00 2001
From: Govindraj.R govindraj.r...@ti.com
Date: Tue, 27 Mar 2012 18:55:00 +0530
Subject: [PATCH] OMAP2+: UART: Correct the wakeup enable mechanism
The module level wakeups are enabled by default during bootup
init from hmwod framework and pad wakeup will be disabled.
Correct the condition check in uart runtime suspend path to
enable/disable wakeups.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/plat-omap/include/plat/omap-serial.h |3 ++-
drivers/tty/serial/omap-serial.c | 16
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 9ff..386a25b 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -130,7 +130,8 @@ struct uart_omap_port {
unsigned long port_activity;
u32 context_loss_cnt;
u32 errata;
- u8 wakeups_enabled;
+ u8 pad_wakeups_enabled;
+ u8 module_wakeups_enabled;
struct pm_qos_request pm_qos_request;
u32 latency;
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 0121486..0a35b7e 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1458,6 +1458,12 @@ static int serial_omap_probe(struct
platform_device *pdev)
up-uart_dma.rx_dma_channel = OMAP_UART_DMA_CH_FREE;
}
+ /* Module level wakeup from sysc(BIT[2])
+* will be enabled during boot
+* from hwmod framework.
+*/
+ up-module_wakeups_enabled = true;
+
up-latency = PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE;
up-calc_latency = PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE;
pm_qos_add_request(up-pm_qos_request,
@@ -1586,14 +1592,16 @@ static int serial_omap_runtime_suspend(struct
device *dev)
up-context_loss_cnt = pdata-get_context_loss_count(dev);
if (device_may_wakeup(dev)) {
- if (!up-wakeups_enabled) {
+ if (!up-pad_wakeups_enabled || !up-module_wakeups_enabled) {
pdata-enable_wakeup(up-pdev, true);
- up-wakeups_enabled = true;
+
Re: [PATCH 0/3] OMAP2+: UART: Enable tx wakeup + remove cpu checks
Hi Paul, On Fri, Mar 23, 2012 at 5:10 AM, Paul Walmsley p...@pwsan.com wrote: Hi On Thu, 22 Mar 2012, Raja, Govindraj wrote: Sorry I for got to add that, here are details on what was tested. 1.) OMAP2430 SDP : Boot tested with uart1 as console. 2.) OMAP3430 SDP: Boot test, suspend/resume tests, retention off mode (checking retention and off mode count in cpu idle cases) 3.) OMAP3630 - Beagle XM: Boot test, suspend/resume tests, retention off mode (checking retention and off mode count in cpu idle cases) 4.) OMAP4430 - PANDA: Boot test, suspend/resume tests 5.) OMAP4460 - PANDA: Boot test. What kernel .config was used for these tests? omap2plus_defconfig was used. the same kernel image was tested with all these boards. (kernel image was built along with initramfs support using minimal busybox filesystem) -- 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 0/3] OMAP2+: UART: Enable tx wakeup + remove cpu checks
On Wed, Mar 21, 2012 at 7:58 PM, Kevin Hilman khil...@ti.com wrote: Govindraj.R govindraj.r...@ti.com writes: From: Govindraj.R govindraj.r...@ti.com Based on Linux-OMAP tree uart branch. (git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git remotes/origin/uart) * Removes the cpu checks wherever possible and use version reg for populating features and errata's * enable tx wakeup available in wer reg for applicable module revision's As this affects multiple SoCs, please report what SoCs it was tested on as well. Sorry I for got to add that, here are details on what was tested. 1.) OMAP2430 SDP : Boot tested with uart1 as console. 2.) OMAP3430 SDP: Boot test, suspend/resume tests, retention off mode (checking retention and off mode count in cpu idle cases) 3.) OMAP3630 - Beagle XM: Boot test, suspend/resume tests, retention off mode (checking retention and off mode count in cpu idle cases) 4.) OMAP4430 - PANDA: Boot test, suspend/resume tests 5.) OMAP4460 - PANDA: Boot test. -- Thanks, Govindraj.R Thanks, Kevin Govindraj.R (3): OMAP2+: UART: Remove cpu checks for populating errata flags OMAP2+: UART: enable tx wakeup bit for wer reg OMAP2+: UART: replace omap34xx/omap4xx cpu checks with not omap24xx arch/arm/mach-omap2/serial.c | 13 + arch/arm/plat-omap/include/plat/omap-serial.h | 8 +++- drivers/tty/serial/omap-serial.c | 71 - 3 files changed, 78 insertions(+), 14 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue
On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda
keshava_mgo...@ti.com wrote:
From: Keshava Munegowda keshava_mgo...@ti.com
It is observed that the echi ports of 3430 sdp board
are not working due to the random timing of programming
the associated GPIOs of the ULPI PHYs of the EHCI for reset.
If the PHYs are reset at during usbhs core driver, host ports will
not work because EHCI driver is loaded after the resetting PHYs.
The PHYs should be in reset state while initializing the EHCI
controller.
The code which does the GPIO pins associated with the PHYs
are programmed to reset is moved from the USB host core driver
to EHCI driver.
I tested on beagle xm where gpio nreset is requested from
board file.
(Basic enumertaion after gpio nreset seems to work fine,
Hub and smsc lan chip get detected afetr boot up)
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
Tested-by: Govindraj.R govindraj.r...@ti.com
---
drivers/mfd/omap-usb-host.c | 44
--
drivers/usb/host/ehci-omap.c | 39 +++-
2 files changed, 37 insertions(+), 46 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 68ac2c5..9927129 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -25,7 +25,6 @@
#include linux/clk.h
#include linux/dma-mapping.h
#include linux/spinlock.h
-#include linux/gpio.h
#include plat/usb.h
#include linux/pm_runtime.h
@@ -502,19 +501,6 @@ static void omap_usbhs_init(struct device *dev)
pm_runtime_get_sync(dev);
spin_lock_irqsave(omap-lock, flags);
- if (pdata-ehci_data-phy_reset) {
- if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[0]))
- gpio_request_one(pdata-ehci_data-reset_gpio_port[0],
- GPIOF_OUT_INIT_LOW, USB1 PHY
reset);
-
- if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[1]))
- gpio_request_one(pdata-ehci_data-reset_gpio_port[1],
- GPIOF_OUT_INIT_LOW, USB2 PHY
reset);
-
- /* Hold the PHY in RESET for enough time till DIR is high */
- udelay(10);
- }
-
omap-usbhs_rev = usbhs_read(omap-uhh_base, OMAP_UHH_REVISION);
dev_dbg(dev, OMAP UHH_REVISION 0x%x\n, omap-usbhs_rev);
@@ -593,39 +579,10 @@ static void omap_usbhs_init(struct device *dev)
usbhs_omap_tll_init(dev, OMAP_TLL_CHANNEL_COUNT);
}
- if (pdata-ehci_data-phy_reset) {
- /* Hold the PHY in RESET for enough time till
- * PHY is settled and ready
- */
- udelay(10);
-
- if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[0]))
- gpio_set_value
- (pdata-ehci_data-reset_gpio_port[0], 1);
-
- if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[1]))
- gpio_set_value
- (pdata-ehci_data-reset_gpio_port[1], 1);
- }
-
spin_unlock_irqrestore(omap-lock, flags);
pm_runtime_put_sync(dev);
}
-static void omap_usbhs_deinit(struct device *dev)
-{
- struct usbhs_hcd_omap *omap = dev_get_drvdata(dev);
- struct usbhs_omap_platform_data *pdata = omap-platdata;
-
- if (pdata-ehci_data-phy_reset) {
- if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[0]))
- gpio_free(pdata-ehci_data-reset_gpio_port[0]);
-
- if (gpio_is_valid(pdata-ehci_data-reset_gpio_port[1]))
- gpio_free(pdata-ehci_data-reset_gpio_port[1]);
- }
-}
-
/**
* usbhs_omap_probe - initialize TI-based HCDs
@@ -861,7 +818,6 @@ static int __devexit usbhs_omap_remove(struct
platform_device *pdev)
{
struct usbhs_hcd_omap *omap = platform_get_drvdata(pdev);
- omap_usbhs_deinit(pdev-dev);
iounmap(omap-tll_base);
iounmap(omap-uhh_base);
clk_put(omap-init_60m_fclk);
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index bba9850..5c78f9e 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -42,6 +42,7 @@
#include plat/usb.h
#include linux/regulator/consumer.h
#include linux/pm_runtime.h
+#include linux/gpio.h
/* EHCI Register Set */
#define EHCI_INSNREG04 (0xA0)
@@ -191,6 +192,19 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
}
}
+ if (pdata-phy_reset) {
+ if (gpio_is_valid(pdata-reset_gpio_port[0]))
+ gpio_request_one(pdata-reset_gpio_port[0],
+ GPIOF_OUT_INIT_LOW, USB1 PHY
reset);
+
+ if
Re: [PATCH] omap_hwmod: Allow io_ring wakeup configuration for all modules.
On Wed, Mar 7, 2012 at 7:40 PM, Raja, Govindraj govindraj.r...@ti.com wrote:
On Wed, Mar 7, 2012 at 5:49 PM, Govindraj.R govindraj.r...@ti.com wrote:
[...]
From b3aa1dac5909cad1b959f5b97bbf408b2f974060 Mon Sep 17 00:00:00 2001
From: Govindraj.R govindraj.r...@ti.com
Date: Wed, 7 Mar 2012 17:14:02 +0530
Subject: [PATCH] omap_hwmod: Allow io_ring wakeup configuration for all
modules.
Some modules doesn't have SYSC_HAS_ENAWAKEUP bit available
(ex: usb host uhh module) in absence of this flag
omap_hwmod_enable/disable_wakeup avoids configuring
pad mux wakeup capability.
Configure sysc if SYSC_HAS_ENAWAKEUP is available and for other cases
try enabling/disabling wakeup from mux_pad pins.
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
Gentle Ping.
--
Thanks,
Govindraj.R
arch/arm/mach-omap2/omap_hwmod.c | 30 --
1 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index eba6cd3..9605fad 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2475,14 +2475,15 @@ int omap_hwmod_enable_wakeup(struct omap_hwmod *oh)
unsigned long flags;
u32 v;
- if (!oh-class-sysc ||
- !(oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP))
- return -EINVAL;
-
spin_lock_irqsave(oh-_lock, flags);
- v = oh-_sysc_cache;
- _enable_wakeup(oh, v);
- _write_sysconfig(v, oh);
+
+ if (oh-class-sysc
+ (oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP)) {
+ v = oh-_sysc_cache;
+ _enable_wakeup(oh, v);
+ _write_sysconfig(v, oh);
+ }
+
_set_idle_ioring_wakeup(oh, true);
spin_unlock_irqrestore(oh-_lock, flags);
@@ -2506,14 +2507,15 @@ int omap_hwmod_disable_wakeup(struct omap_hwmod *oh)
unsigned long flags;
u32 v;
- if (!oh-class-sysc ||
- !(oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP))
- return -EINVAL;
-
spin_lock_irqsave(oh-_lock, flags);
- v = oh-_sysc_cache;
- _disable_wakeup(oh, v);
- _write_sysconfig(v, oh);
+
+ if (oh-class-sysc
+ (oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP)) {
+ v = oh-_sysc_cache;
+ _disable_wakeup(oh, v);
+ _write_sysconfig(v, oh);
+ }
+
_set_idle_ioring_wakeup(oh, false);
spin_unlock_irqrestore(oh-_lock, flags);
--
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: [RFC PATCH] OMAP: UART: Enable tx wakeup bit in wer
On Wed, Mar 7, 2012 at 11:27 AM, Paul Walmsley p...@pwsan.com wrote: Hi On Tue, 6 Mar 2012, Raja, Govindraj wrote: I see two ways of adding this tx wake-up flag. 1.) passing a feature flag from pdata and populating the feature value to wer. 2.) Duplicating the uart1/2/3 hwmod for omap3430 without dev attrib and uart1/2/3/4 hwmod for omap3630 with dev attribs. Approach-2 adds unnecessary code duplication in hwmod file with and without dev_attribs, So right now here is the patch to follow approach [1], If its strongly recommended to use approach-2 will add it. (My concern is the diffstat it might produce with approach-2) Both 1 and 2 are needed. The current way that errata are handled in arch/arm/mach-omap2/serial.c needs to be changed. Those should be flags that are passed from hwmod dev_attr data. The presence of the TX wakeup bit should simply be another dev_attr flag. These flags should be passed to the driver via the omap_up.errata field for the time being. okay. The exception to this is if the IP block's revision register was changed when TX wakeups became possible. If that's the case, then that mechanism can be used in lieu of dev_attr and platform_data in this situation. I will check on the MVR reg available for uart-rev on different omap socs, and will get back by end on next of week with a possible patch. -- 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] omap_hwmod: Allow io_ring wakeup configuration for all modules.
On Wed, Mar 7, 2012 at 5:49 PM, Govindraj.R govindraj.r...@ti.com wrote:
From: Govindraj.R govindraj.r...@ti.com
Some modules doesn't have SYSC_HAS_ENAWAKEUP bit available
(ex: usb host uhh module) in absence of this flag
omap_hwmod_enable/disable_wakeup avoids configuring
pad mux wakeup capability.
Configure sysc if SYSC_HAS_ENAWAKEUP is available and for other cases
try enabling/disabling wakeup from mux_pad pins.
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 30 --
1 files changed, 16 insertions(+), 14 deletions(-)
[...]
@@ -2506,14 +2507,15 @@ int omap_hwmod_disable_wakeup(struct omap_hwmod *oh)
unsigned long flags;
u32 v;
- if (!oh-class-sysc ||
- !(oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP))
- return -EINVAL;
-
spin_lock_irqsave(oh-_lock, flags);
- v = oh-_sysc_cache;
- _disable_wakeup(oh, v);
- _write_sysconfig(v, oh);
+
+ if (oh-class-sysc ||
+ (oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP)) {
This condition check should have been _and_ ()
sorry for the typo,
Here [1] is the updated patch.
--
Thanks,
Govindraj.R
[1]:
From b3aa1dac5909cad1b959f5b97bbf408b2f974060 Mon Sep 17 00:00:00 2001
From: Govindraj.R govindraj.r...@ti.com
Date: Wed, 7 Mar 2012 17:14:02 +0530
Subject: [PATCH] omap_hwmod: Allow io_ring wakeup configuration for all
modules.
Some modules doesn't have SYSC_HAS_ENAWAKEUP bit available
(ex: usb host uhh module) in absence of this flag
omap_hwmod_enable/disable_wakeup avoids configuring
pad mux wakeup capability.
Configure sysc if SYSC_HAS_ENAWAKEUP is available and for other cases
try enabling/disabling wakeup from mux_pad pins.
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 30 --
1 files changed, 16 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index eba6cd3..9605fad 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2475,14 +2475,15 @@ int omap_hwmod_enable_wakeup(struct omap_hwmod *oh)
unsigned long flags;
u32 v;
- if (!oh-class-sysc ||
- !(oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP))
- return -EINVAL;
-
spin_lock_irqsave(oh-_lock, flags);
- v = oh-_sysc_cache;
- _enable_wakeup(oh, v);
- _write_sysconfig(v, oh);
+
+ if (oh-class-sysc
+ (oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP)) {
+ v = oh-_sysc_cache;
+ _enable_wakeup(oh, v);
+ _write_sysconfig(v, oh);
+ }
+
_set_idle_ioring_wakeup(oh, true);
spin_unlock_irqrestore(oh-_lock, flags);
@@ -2506,14 +2507,15 @@ int omap_hwmod_disable_wakeup(struct omap_hwmod *oh)
unsigned long flags;
u32 v;
- if (!oh-class-sysc ||
- !(oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP))
- return -EINVAL;
-
spin_lock_irqsave(oh-_lock, flags);
- v = oh-_sysc_cache;
- _disable_wakeup(oh, v);
- _write_sysconfig(v, oh);
+
+ if (oh-class-sysc
+ (oh-class-sysc-sysc_flags SYSC_HAS_ENAWAKEUP)) {
+ v = oh-_sysc_cache;
+ _disable_wakeup(oh, v);
+ _write_sysconfig(v, oh);
+ }
+
_set_idle_ioring_wakeup(oh, false);
spin_unlock_irqrestore(oh-_lock, flags);
--
1.7.5.4
0001-omap_hwmod-Allow-io_ring-wakeup-configuration-for-al.patch
Description: Binary data
Re: [PATCH] omap3_beagle: Init only uart3 used for console
On Mon, Mar 5, 2012 at 7:36 PM, Koen Kooi k...@dominion.thruhere.net wrote: Op 5 mrt. 2012, om 12:12 heeft Govindraj.R het volgende geschreven: From: Govindraj.R govindraj.r...@ti.com On beagle some of uart mux lines are used for other purpose so init only uart3. Uart2 rx line clashes with gpio_147 used for usb ehci phy reset. Initializing uart2 pad_mux lines can break ehci module on beagle xm. (gpio_147 is available on uart2_rx in mode4 reference mux34xx.c - uart2_rx.gpio_147) That's only on xM revision C, right? Applicable to all beagle boards having external usb hub (USB2HS_nRST will require uart2_rx.gpio_147) Beagle Rev Ax/Bx doesn't seem to have external hub module so not applicable for those boards Will modify and post a new patch. -- 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] omap3_beagle: Init only uart3 used for console
On Tue, Mar 6, 2012 at 1:30 AM, Kevin Hilman khil...@ti.com wrote: Govindraj.R govindraj.r...@ti.com writes: From: Govindraj.R govindraj.r...@ti.com On beagle some of uart mux lines are used for other purpose so init only uart3. OK, but you should also be clear that this patch is effectively disabling all UARTS (except UART3) by defatul, which I'm not sure all Beagle users will be happy about. Okay, I have posted new version of the patch [PATCH] omap3_beagle: init uart2 for beagle rev AX/BX only which initialises uart1/3/4 on all beagle boards and uart2 init is done for only beagle rev ax/bx which doesn't seem to have external usb module. Uart2 rx line clashes with gpio_147 used for usb ehci phy reset. Initializing uart2 pad_mux lines can break ehci module on beagle xm. (gpio_147 is available on uart2_rx in mode4 reference mux34xx.c - uart2_rx.gpio_147) As Koen mentioned, this conflict only exists on certain boards, so you should be clear that this is just an example. conflict exists all beagle rev's expect rev ax/bx. -- 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] omap3_beagle: Init only uart3 used for console
On Tue, Mar 6, 2012 at 2:21 AM, Tony Lindgren t...@atomide.com wrote: * Kevin Hilman khil...@ti.com [120305 11:28]: Govindraj.R govindraj.r...@ti.com writes: From: Govindraj.R govindraj.r...@ti.com On beagle some of uart mux lines are used for other purpose so init only uart3. OK, but you should also be clear that this patch is effectively disabling all UARTS (except UART3) by defatul, which I'm not sure all Beagle users will be happy about. Uart2 rx line clashes with gpio_147 used for usb ehci phy reset. Initializing uart2 pad_mux lines can break ehci module on beagle xm. (gpio_147 is available on uart2_rx in mode4 reference mux34xx.c - uart2_rx.gpio_147) As Koen mentioned, this conflict only exists on certain boards, so you should be clear that this is just an example. OK, thanks for the comments. Also it's a bit clear if this really is safe to do on all beagles. I have clarified the same in reply to Kevin Hilman and Koen Kooi in the same thread. Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Tested-by: Peter Ujfalusi peter.ujfal...@ti.com Tested-by: Robert Nelson robertcnel...@gmail.com Signed-off-by: Govindraj.R govindraj.r...@ti.com [...] + +static inline void board_serial_init(void) Should be __init [...] +static inline void board_serial_init(void) here too. ..so dropping the patch for now until these are fixed and we have some tested-bys for non-xm beagles too. Okay fine, I have new version of the patch [PATCH] omap3_beagle: init uart2 for beagle rev AX/BX only This patch shouldn't have any impact and should work on beagles. -- 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: [RFC PATCH] OMAP: UART: Enable tx wakeup bit in wer
On Tue, Mar 6, 2012 at 1:53 AM, Paul Walmsley p...@pwsan.com wrote:
Hello Govindraj
Do you intend to update and repost this serial patch? Or should someone
else deal with it? It would be good to get support for this additional
wakeup bit.
Thanks for reminding.
(I had got preempted with other activities, apologies for the delay)
I see two ways of adding this tx wake-up flag.
1.) passing a feature flag from pdata and populating the feature value to wer.
2.) Duplicating the uart1/2/3 hwmod for omap3430 without dev attrib
and uart1/2/3/4
hwmod for omap3630 with dev attribs.
Approach-2 adds unnecessary code duplication in hwmod file with and without
dev_attribs, So right now here is the patch to follow approach [1],
If its strongly recommended to use approach-2 will add it.
(My concern is the diffstat it might produce with approach-2)
--
Thanks,
Govindraj.R
[1]:
From 867dfa7328b4219be259a204555a6baae82ec4df Mon Sep 17 00:00:00 2001
From: Govindraj.R govindraj.r...@ti.com
Date: Tue, 6 Mar 2012 15:04:47 +0530
Subject: [PATCH] OMAP: UART: enable tx wake up capability for 3630 above socs
From omap3630 above UART wer(wakeup enable reg) has TX
wakeup capability, enable the tx wakeup bit by passing
the required feature flag from pdata.
Also add missing wer reg restore from context restore function.
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c |3 +++
arch/arm/plat-omap/include/plat/omap-serial.h |7 +++
drivers/tty/serial/omap-serial.c |8 +++-
3 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index f590afc..eb43996 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -357,6 +357,9 @@ void __init omap_serial_init_port(struct
omap_board_data *bdata,
omap_up.dma_rx_poll_rate = info-dma_rx_poll_rate;
omap_up.autosuspend_timeout = info-autosuspend_timeout;
+ if (!cpu_is_omap24xx() !cpu_is_omap3430())
+ omap_up.has_feature = UART_FEATURE_TX_WAKEUP_EN;
+
/* Enable the MDR1 Errata i202 for OMAP2430/3xxx/44xx */
if (!cpu_is_omap2420() !cpu_is_ti816x())
omap_up.errata |= UART_ERRATA_i202_MDR1_ACCESS;
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 9ff..b4f42dc 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -61,6 +61,11 @@
#define UART_ERRATA_i202_MDR1_ACCESS BIT(0)
#define UART_ERRATA_i291_DMA_FORCEIDLE BIT(1)
+#define OMAP_UART_TX_WAKEUP_EN BIT(7)
+
+/* Feature flags */
+#define UART_FEATURE_TX_WAKEUP_EN BIT(0)
+
struct omap_uart_port_info {
booldma_enabled;/* To specify DMA Mode */
unsigned intuartclk;/* UART clock rate */
@@ -70,6 +75,7 @@ struct omap_uart_port_info {
unsigned intdma_rx_timeout;
unsigned intautosuspend_timeout;
unsigned intdma_rx_poll_rate;
+ unsigned inthas_feature;
int (*get_context_loss_count)(struct device *);
void (*set_forceidle)(struct platform_device *);
@@ -117,6 +123,7 @@ struct uart_omap_port {
unsigned char dlh;
unsigned char mdr1;
unsigned char scr;
+ unsigned char wer;
int use_dma;
/*
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index f809041..5d7330f 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -577,8 +577,10 @@ static int serial_omap_startup(struct uart_port *port)
up-ier = UART_IER_RLSI | UART_IER_RDI;
serial_out(up, UART_IER, up-ier);
+ up-wer |= OMAP_UART_WER_MOD_WKUP;
+
/* Enable module level wake up */
- serial_out(up, UART_OMAP_WER, OMAP_UART_WER_MOD_WKUP);
+ serial_out(up, UART_OMAP_WER, up-wer);
pm_runtime_mark_last_busy(up-pdev-dev);
pm_runtime_put_autosuspend(up-pdev-dev);
@@ -1444,6 +1446,8 @@ static int serial_omap_probe(struct platform_device *pdev)
}
up-uart_dma.uart_base = mem-start;
up-errata = omap_up_info-errata;
+ if (omap_up_info-has_feature UART_FEATURE_TX_WAKEUP_EN)
+ up-wer |= OMAP_UART_TX_WAKEUP_EN;
if (omap_up_info-dma_enabled) {
up-uart_dma.uart_dma_tx = dma_tx-start;
@@ -1569,6 +1573,8 @@ static void serial_omap_restore_context(struct
uart_omap_port *up)
serial_omap_mdr1_errataset(up, up-mdr1);
else
serial_out(up, UART_OMAP_MDR1, up-mdr1);
+
+ serial_out(up, UART_OMAP_WER, up-wer);
}
static int serial_omap_runtime_suspend(struct device *dev)
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap
