* Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore
From: Tony Lindgren @ 2011-12-14 18:21 UTC (permalink / raw)
To: Janusz Krzysztofik
Cc: Grant Likely, linux-omap, linux-arm-kernel, linux-kernel,
Greg Kroah-Hartman, linux-serial
In-Reply-To: <201112141410.53522.jkrzyszt@tis.icnet.pl>
* Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [111214 04:40]:
> On Tuesday 13 of December 2011 at 00:55:44, Tony Lindgren wrote:
> > * Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [111212 15:13]:
> > > On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote:
> > > >
> > > > Might be worth checking if some board specific __initcall helps here
> > > > too?
> > >
> > > If I only knew how I could insert a board specific __initcall between
> > > two points from where the generic-gpio first, then the 8250 driver, are
> > > called.
> > >
> > > Any hints?
> >
> > Hmm, can't you do all that in the order you want in
> > ams_delta_modem_init()? Or make that into a late_initcall so
> > you have generic-gpio available?
> >
> > It seems that the pieces of code you're talking about don't need
> > to be initialized early, just needs to be done in the right
> > order to get things working.
>
> Hi,
> I'm almost done with moving registration of all latch dependent devices
> down to a late_initcall hook, however while working on this, I've found
> still another arrangement, yet better in my opinion:
> 1) generic-gpio driver registration moved from device_initcall up to
> subsys_initcall,
> 2) latch dependent device registration left at arch_initcall, as it is
> now,
> 3) a temporary hack, removed with the last patch in the series, that
> requests GPIO pins on behalf of device drivers before those are
> updated, placed between subsys_initcall and device_initcall, i.e., at
> fs_initcall or rootfs_initcall; both look ugly, but this is only for
> a while, in order to keep things working while in the transition,
> 4) the modem init hook, once updated with extra GPIO setup that must be
> done on behalf of the 8250 driver, which is not prepared for
> accepting any extra init hooks passed with the device platform data,
> moved down to late_initcall, as suggested,
> 5) once all drivers are updated, the hack is removed, and an
> initialization of unused pins added to that late_initcall modem hook,
> perhaps renamed in order to not suggest it is still modem only
> related.
>
> What do you think?
Sounds better for sure than what we currently have :)
Tony
^ permalink raw reply
* Re: [PATCH v3 0/4] OMAP serial device tree support
From: Alan Cox @ 2011-12-14 17:18 UTC (permalink / raw)
To: Kevin Hilman
Cc: Rajendra Nayak, Greg KH, linux-serial, linux-omap,
devicetree-discuss, tony, govindraj.raja, b-cousson,
linux-arm-kernel, linaro-dev, patches, robherring2
In-Reply-To: <87d3brnpsi.fsf@ti.com>
On Wed, 14 Dec 2011 07:20:13 -0800
Kevin Hilman <khilman@ti.com> wrote:
> Greg, Alan,
>
> Rajendra Nayak <rnayak@ti.com> writes:
>
> > v3 is rebased on top of the latest serial runtime
> > patches[1] and boot tested with/without DT on OMAP4
> > SDP and OMAP4 Panda boards.
>
> With your ack on the drivers/tty/* stuff, I can queue this via the
> OMAP tree on top of the runtime PM conversion that it depends on.
Go for it
^ permalink raw reply
* Re: [PATCH v8 00/20] OMAP2+: UART: Runtime adaptation + cleanup
From: Govindraj @ 2011-12-14 16:20 UTC (permalink / raw)
To: Kevin Hilman
Cc: Tony Lindgren, linux-omap, linux-serial, linux-arm-kernel,
Partha Basak, Vishwanath Sripathy, Rajendra Nayak,
Santosh Shilimkar, Govindraj.R
In-Reply-To: <877h1znpdo.fsf@ti.com>
On Wed, Dec 14, 2011 at 8:59 PM, Kevin Hilman <khilman@ti.com> wrote:
> Govindraj <govindraj.ti@gmail.com> writes:
>
>> On Wed, Dec 14, 2011 at 12:56 AM, Kevin Hilman <khilman@ti.com> wrote:
>>> Govindraj <govindraj.ti@gmail.com> writes:
>>>
>>> [...]
>>>
>>>> I have re-based this patch series against LO master
>>>> commit id: deee6d5359969a0ce4e2760cfd7b9f379bd5698a
>>>>
>>>> Same is available here [1]
>>>>
>>>> I have tested this patch series along with:
>>>>
>>>> 1.) Tero's V11 irq chaining series
>>>> http://www.spinics.net/lists/linux-omap/msg61445.html
>>>> (This patch series is used for uart wakeup handling using
>>>> prcm_irq chaining)
>>>>
>>>> 2.) Rajendra's hwmod change
>>>> http://www.spinics.net/lists/arm-kernel/msg148632.html
>>>> (This patch handles init_no_idle flag setting
>>>> without this patch there will be boot warning however
>>>> all pm features will work after boot up.)
>>>>
>>>> 3.) Vishwa's io daisy chain changes.
>>>> http://permalink.gmane.org/gmane.linux.ports.arm.omap/65500
>>>> (tested with and without this patch series pm features works).
>>>>
>>>> Same combination of patches based on above commit id
>>>> used for testing is available here [2].
>>>
>>> Please have a closer look at your branch.
>>>
>>> The second commit[1] commits the .rej file from a failed patch apply,
>>> so obviously doesn't do what was intended.
>>>
>>
>> Sorry my bad I have refreshed the uart runtime branch [1]
>> & test branch [2].
>
> Can you add another patch which fixes these compiler warnings:
>
> /work/kernel/omap/pm/drivers/tty/serial/omap-serial.c: In function 'serial_omap_irq':
> /work/kernel/omap/pm/drivers/tty/serial/omap-serial.c:228:29: warning: 'ch' may be used uninitialized in this function [-Wuninitialized]
> /work/kernel/omap/pm/drivers/tty/serial/omap-serial.c:176:16: note: 'ch' was declared here
> /work/kernel/omap/pm/drivers/tty/serial/omap-serial.c:228:29: warning: 'ch' may be used uninitialized in this function [-Wuninitialized]
> /work/kernel/omap/pm/drivers/tty/serial/omap-serial.c:176:16: note: 'ch' was declared here
>
Here is the patch [1] and pushed to
git://gitorious.org/runtime_3-0/runtime_3-0.git for_3_3/lo_rc4_uartruntime
--
Thanks,
Govindraj.R
[1]:
From 3a40f4e1a4c6db40d06cc6c5536ec06e9e5daf3d Mon Sep 17 00:00:00 2001
From: "Govindraj.R" <govindraj.raja@ti.com>
Date: Wed, 14 Dec 2011 21:24:11 +0530
Subject: [PATCH] OMAP2+: UART: Fix compilation/sparse warnings
Fixes below compilation warning.
drivers/tty/serial/omap-serial.c: In function 'serial_omap_irq':
drivers/tty/serial/omap-serial.c:228:29: warning: 'ch' may be used
uninitialized in this function [-Wuninitialized]
Fix below sparse warning.
drivers/tty/serial/omap-serial.c:392:52: warning: incorrect type in
argument 2 (different signedness)
drivers/tty/serial/omap-serial.c:392:52: expected int *status
drivers/tty/serial/omap-serial.c:392:52: got unsigned int *<noident>
Reported-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
---
drivers/tty/serial/omap-serial.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index f3ff0ca..7b0303d 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -166,11 +166,12 @@ static void serial_omap_stop_rx(struct uart_port *port)
pm_runtime_put_autosuspend(&up->pdev->dev);
}
-static inline void receive_chars(struct uart_omap_port *up, int *status)
+static inline void receive_chars(struct uart_omap_port *up,
+ unsigned int *status)
{
struct tty_struct *tty = up->port.state->port.tty;
- unsigned int flag;
- unsigned char ch, lsr = *status;
+ unsigned int flag, lsr = *status;
+ unsigned char ch = 0;
int max_count = 256;
do {
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v8 00/20] OMAP2+: UART: Runtime adaptation + cleanup
From: Kevin Hilman @ 2011-12-14 15:29 UTC (permalink / raw)
To: Govindraj
Cc: Tony Lindgren, linux-omap, linux-serial, linux-arm-kernel,
Partha Basak, Vishwanath Sripathy, Rajendra Nayak,
Santosh Shilimkar, Govindraj.R
In-Reply-To: <CAAL8m4wR-3WDYf_c56-h1ZtCg=Ob2T+FvOOaXLSKK1pyo9oh8Q@mail.gmail.com>
Govindraj <govindraj.ti@gmail.com> writes:
> On Wed, Dec 14, 2011 at 12:56 AM, Kevin Hilman <khilman@ti.com> wrote:
>> Govindraj <govindraj.ti@gmail.com> writes:
>>
>> [...]
>>
>>> I have re-based this patch series against LO master
>>> commit id: deee6d5359969a0ce4e2760cfd7b9f379bd5698a
>>>
>>> Same is available here [1]
>>>
>>> I have tested this patch series along with:
>>>
>>> 1.) Tero's V11 irq chaining series
>>> http://www.spinics.net/lists/linux-omap/msg61445.html
>>> (This patch series is used for uart wakeup handling using
>>> prcm_irq chaining)
>>>
>>> 2.) Rajendra's hwmod change
>>> http://www.spinics.net/lists/arm-kernel/msg148632.html
>>> (This patch handles init_no_idle flag setting
>>> without this patch there will be boot warning however
>>> all pm features will work after boot up.)
>>>
>>> 3.) Vishwa's io daisy chain changes.
>>> http://permalink.gmane.org/gmane.linux.ports.arm.omap/65500
>>> (tested with and without this patch series pm features works).
>>>
>>> Same combination of patches based on above commit id
>>> used for testing is available here [2].
>>
>> Please have a closer look at your branch.
>>
>> The second commit[1] commits the .rej file from a failed patch apply,
>> so obviously doesn't do what was intended.
>>
>
> Sorry my bad I have refreshed the uart runtime branch [1]
> & test branch [2].
Can you add another patch which fixes these compiler warnings:
/work/kernel/omap/pm/drivers/tty/serial/omap-serial.c: In function 'serial_omap_irq':
/work/kernel/omap/pm/drivers/tty/serial/omap-serial.c:228:29: warning: 'ch' may be used uninitialized in this function [-Wuninitialized]
/work/kernel/omap/pm/drivers/tty/serial/omap-serial.c:176:16: note: 'ch' was declared here
/work/kernel/omap/pm/drivers/tty/serial/omap-serial.c:228:29: warning: 'ch' may be used uninitialized in this function [-Wuninitialized]
/work/kernel/omap/pm/drivers/tty/serial/omap-serial.c:176:16: note: 'ch' was declared here
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 0/4] OMAP serial device tree support
From: Kevin Hilman @ 2011-12-14 15:20 UTC (permalink / raw)
To: Rajendra Nayak, Greg KH, Alan Cox
Cc: linux-serial, linux-omap, devicetree-discuss, tony,
govindraj.raja, b-cousson, linux-arm-kernel, linaro-dev, patches,
robherring2
In-Reply-To: <1323863746-18145-1-git-send-email-rnayak@ti.com>
Greg, Alan,
Rajendra Nayak <rnayak@ti.com> writes:
> v3 is rebased on top of the latest serial runtime
> patches[1] and boot tested with/without DT on OMAP4
> SDP and OMAP4 Panda boards.
With your ack on the drivers/tty/* stuff, I can queue this via the OMAP
tree on top of the runtime PM conversion that it depends on.
Thanks,
Kevin
> Patches can be found here..
> git://gitorious.org/omap-pm/linux.git for-dt/serial
>
> I also had to pull in a fix[2] for DT testing (already in linux-omap
> master) which was missing as the serial runtime branch[1]
> was based on an older master commit.
>
> Changes in v3:
> -1- Rebased on latest serial runtime patches
> -2- Minor typr fixes
>
> Changes in v2:
> -1- Got rid of binding to define which uart is console
> -2- Added checks to default clock speed to 48Mhz
> -3- Added compatible for each OMAP family
> -4- Used of_alias_get_id to populate port.line
>
> [1] git://gitorious.org/runtime_3-0/runtime_3-0.git for_3_3/lo_rc4_uartruntime
> [2] http://www.spinics.net/lists/arm-kernel/msg150751.html
>
> Rajendra Nayak (4):
> omap-serial: Get rid of all pdev->id usage
> omap-serial: Use default clock speed (48Mhz) if not specified
> omap-serial: Add minimal device tree support
> ARM: omap: pass minimal SoC/board data for UART from dt
>
> .../devicetree/bindings/serial/omap_serial.txt | 10 +++
> arch/arm/boot/dts/omap3.dtsi | 31 ++++++++
> arch/arm/boot/dts/omap4.dtsi | 28 +++++++
> arch/arm/mach-omap2/board-generic.c | 1 -
> drivers/tty/serial/omap-serial.c | 80 +++++++++++++++----
> 5 files changed, 132 insertions(+), 18 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 0/4] OMAP serial device tree support
From: Govindraj @ 2011-12-14 14:41 UTC (permalink / raw)
To: Rajendra Nayak
Cc: linux-serial, linux-omap, devicetree-discuss, khilman, tony,
govindraj.raja, b-cousson, linux-arm-kernel, linaro-dev, patches,
robherring2
In-Reply-To: <1323863746-18145-1-git-send-email-rnayak@ti.com>
Hi Rajendra,
On Wed, Dec 14, 2011 at 5:25 PM, Rajendra Nayak <rnayak@ti.com> wrote:
> v3 is rebased on top of the latest serial runtime
> patches[1] and boot tested with/without DT on OMAP4
> SDP and OMAP4 Panda boards.
>
> Patches can be found here..
> git://gitorious.org/omap-pm/linux.git for-dt/serial
>
> I also had to pull in a fix[2] for DT testing (already in linux-omap
> master) which was missing as the serial runtime branch[1]
> was based on an older master commit.
>
> Changes in v3:
> -1- Rebased on latest serial runtime patches
> -2- Minor typr fixes
>
> Changes in v2:
> -1- Got rid of binding to define which uart is console
> -2- Added checks to default clock speed to 48Mhz
> -3- Added compatible for each OMAP family
> -4- Used of_alias_get_id to populate port.line
>
> [1] git://gitorious.org/runtime_3-0/runtime_3-0.git for_3_3/lo_rc4_uartruntime
> [2] http://www.spinics.net/lists/arm-kernel/msg150751.html
>
I merged this patch series to a tmp_intg branch [1]
having uart runtime changes and sanity tested on
3430sdp/zoom3/panda seems fine.
--
Thanks,
Govindraj.R
[1]:
git://gitorious.org/runtime_3-0/runtime_3-0.git
for_3_3/tmp_rc4_uart_pm_intg
^ permalink raw reply
* Re: [PATCH v3 0/4] OMAP serial device tree support
From: Rob Herring @ 2011-12-14 13:47 UTC (permalink / raw)
To: Rajendra Nayak
Cc: linux-serial, linux-omap, devicetree-discuss, khilman, tony,
govindraj.raja, b-cousson, linux-arm-kernel, linaro-dev, patches
In-Reply-To: <1323863746-18145-1-git-send-email-rnayak@ti.com>
On 12/14/2011 05:55 AM, Rajendra Nayak wrote:
> v3 is rebased on top of the latest serial runtime
> patches[1] and boot tested with/without DT on OMAP4
> SDP and OMAP4 Panda boards.
>
> Patches can be found here..
> git://gitorious.org/omap-pm/linux.git for-dt/serial
>
> I also had to pull in a fix[2] for DT testing (already in linux-omap
> master) which was missing as the serial runtime branch[1]
> was based on an older master commit.
>
> Changes in v3:
> -1- Rebased on latest serial runtime patches
> -2- Minor typr fixes
>
> Changes in v2:
> -1- Got rid of binding to define which uart is console
> -2- Added checks to default clock speed to 48Mhz
> -3- Added compatible for each OMAP family
> -4- Used of_alias_get_id to populate port.line
>
> [1] git://gitorious.org/runtime_3-0/runtime_3-0.git for_3_3/lo_rc4_uartruntime
> [2] http://www.spinics.net/lists/arm-kernel/msg150751.html
>
> Rajendra Nayak (4):
> omap-serial: Get rid of all pdev->id usage
> omap-serial: Use default clock speed (48Mhz) if not specified
> omap-serial: Add minimal device tree support
> ARM: omap: pass minimal SoC/board data for UART from dt
>
> .../devicetree/bindings/serial/omap_serial.txt | 10 +++
> arch/arm/boot/dts/omap3.dtsi | 31 ++++++++
> arch/arm/boot/dts/omap4.dtsi | 28 +++++++
> arch/arm/mach-omap2/board-generic.c | 1 -
> drivers/tty/serial/omap-serial.c | 80 +++++++++++++++----
> 5 files changed, 132 insertions(+), 18 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt
Looks good. For the series:
Reviewed-by: Rob Herring <rob.herring@calxeda.com>
^ permalink raw reply
* Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore
From: Janusz Krzysztofik @ 2011-12-14 13:10 UTC (permalink / raw)
To: Tony Lindgren
Cc: Grant Likely, linux-omap, linux-arm-kernel, linux-kernel,
Greg Kroah-Hartman, linux-serial
In-Reply-To: <20111212235544.GM32251@atomide.com>
On Tuesday 13 of December 2011 at 00:55:44, Tony Lindgren wrote:
> * Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [111212 15:13]:
> > On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote:
> > >
> > > Might be worth checking if some board specific __initcall helps here
> > > too?
> >
> > If I only knew how I could insert a board specific __initcall between
> > two points from where the generic-gpio first, then the 8250 driver, are
> > called.
> >
> > Any hints?
>
> Hmm, can't you do all that in the order you want in
> ams_delta_modem_init()? Or make that into a late_initcall so
> you have generic-gpio available?
>
> It seems that the pieces of code you're talking about don't need
> to be initialized early, just needs to be done in the right
> order to get things working.
Hi,
I'm almost done with moving registration of all latch dependent devices
down to a late_initcall hook, however while working on this, I've found
still another arrangement, yet better in my opinion:
1) generic-gpio driver registration moved from device_initcall up to
subsys_initcall,
2) latch dependent device registration left at arch_initcall, as it is
now,
3) a temporary hack, removed with the last patch in the series, that
requests GPIO pins on behalf of device drivers before those are
updated, placed between subsys_initcall and device_initcall, i.e., at
fs_initcall or rootfs_initcall; both look ugly, but this is only for
a while, in order to keep things working while in the transition,
4) the modem init hook, once updated with extra GPIO setup that must be
done on behalf of the 8250 driver, which is not prepared for
accepting any extra init hooks passed with the device platform data,
moved down to late_initcall, as suggested,
5) once all drivers are updated, the hack is removed, and an
initialization of unused pins added to that late_initcall modem hook,
perhaps renamed in order to not suggest it is still modem only
related.
What do you think?
Thanks,
Janusz
^ permalink raw reply
* [PATCH v3 4/4] ARM: omap: pass minimal SoC/board data for UART from dt
From: Rajendra Nayak @ 2011-12-14 11:55 UTC (permalink / raw)
To: linux-serial, linux-omap, devicetree-discuss, khilman
Cc: tony, govindraj.raja, b-cousson, linux-arm-kernel, linaro-dev,
patches, robherring2, Rajendra Nayak
In-Reply-To: <1323863746-18145-1-git-send-email-rnayak@ti.com>
Pass minimal data needed for console boot, from dt, for
OMAP4 panda/sdp and OMAP3 beagle boards, and get rid of the
static initialization from generic board file.
Acked-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
arch/arm/boot/dts/omap3.dtsi | 31 +++++++++++++++++++++++++++++++
arch/arm/boot/dts/omap4.dtsi | 28 ++++++++++++++++++++++++++++
arch/arm/mach-omap2/board-generic.c | 1 -
3 files changed, 59 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index d202bb5..216c331 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -13,6 +13,13 @@
/ {
compatible = "ti,omap3430", "ti,omap3";
+ aliases {
+ serial0 = &uart1;
+ serial1 = &uart2;
+ serial2 = &uart3;
+ serial3 = &uart4;
+ };
+
cpus {
cpu@0 {
compatible = "arm,cortex-a8";
@@ -59,5 +66,29 @@
interrupt-controller;
#interrupt-cells = <1>;
};
+
+ uart1: serial@0x4806a000 {
+ compatible = "ti,omap3-uart";
+ ti,hwmods = "uart1";
+ clock-frequency = <48000000>;
+ };
+
+ uart2: serial@0x4806c000 {
+ compatible = "ti,omap3-uart";
+ ti,hwmods = "uart2";
+ clock-frequency = <48000000>;
+ };
+
+ uart3: serial@0x49020000 {
+ compatible = "ti,omap3-uart";
+ ti,hwmods = "uart3";
+ clock-frequency = <48000000>;
+ };
+
+ uart4: serial@0x49042000 {
+ compatible = "ti,omap3-uart";
+ ti,hwmods = "uart4";
+ clock-frequency = <48000000>;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 4c61c82..e8fe75f 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -21,6 +21,10 @@
interrupt-parent = <&gic>;
aliases {
+ serial0 = &uart1;
+ serial1 = &uart2;
+ serial2 = &uart3;
+ serial3 = &uart4;
};
cpus {
@@ -99,5 +103,29 @@
reg = <0x48241000 0x1000>,
<0x48240100 0x0100>;
};
+
+ uart1: serial@0x4806a000 {
+ compatible = "ti,omap4-uart";
+ ti,hwmods = "uart1";
+ clock-frequency = <48000000>;
+ };
+
+ uart2: serial@0x4806c000 {
+ compatible = "ti,omap4-uart";
+ ti,hwmods = "uart2";
+ clock-frequency = <48000000>;
+ };
+
+ uart3: serial@0x48020000 {
+ compatible = "ti,omap4-uart";
+ ti,hwmods = "uart3";
+ clock-frequency = <48000000>;
+ };
+
+ uart4: serial@0x4806e000 {
+ compatible = "ti,omap4-uart";
+ ti,hwmods = "uart4";
+ clock-frequency = <48000000>;
+ };
};
};
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index 63b5416..a508ed5 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -69,7 +69,6 @@ static void __init omap_generic_init(void)
if (node)
irq_domain_add_simple(node, 0);
- omap_serial_init();
omap_sdrc_init(NULL, NULL);
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
--
1.7.1
^ permalink raw reply related
* [PATCH v3 3/4] omap-serial: Add minimal device tree support
From: Rajendra Nayak @ 2011-12-14 11:55 UTC (permalink / raw)
To: linux-serial, linux-omap, devicetree-discuss, khilman
Cc: tony, govindraj.raja, b-cousson, linux-arm-kernel, linaro-dev,
patches, robherring2, Rajendra Nayak
In-Reply-To: <1323863746-18145-1-git-send-email-rnayak@ti.com>
Adapt the driver to device tree and pass minimal platform
data from device tree needed for console boot.
No power management features will be suppported for now
since it requires more tweaks around OCP settings
to toggle forceidle/noidle/smartidle bits and handling
remote wakeup and dynamic muxing.
Acked-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
.../devicetree/bindings/serial/omap_serial.txt | 10 ++++
drivers/tty/serial/omap-serial.c | 45 ++++++++++++++++++-
2 files changed, 52 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt
diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
new file mode 100644
index 0000000..342eedd
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -0,0 +1,10 @@
+OMAP UART controller
+
+Required properties:
+- compatible : should be "ti,omap2-uart" for OMAP2 controllers
+- compatible : should be "ti,omap3-uart" for OMAP3 controllers
+- compatible : should be "ti,omap4-uart" for OMAP4 controllers
+- ti,hwmods : Must be "uart<n>", n being the instance number (1-based)
+
+Optional properties:
+- clock-frequency : frequency of the clock input to the UART
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index f14b9c5..5aa524e 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -38,6 +38,7 @@
#include <linux/serial_core.h>
#include <linux/irq.h>
#include <linux/pm_runtime.h>
+#include <linux/of.h>
#include <plat/dma.h>
#include <plat/dmtimer.h>
@@ -1324,6 +1325,19 @@ static void uart_tx_dma_callback(int lch, u16 ch_status, void *data)
return;
}
+static struct omap_uart_port_info *of_get_uart_port_info(struct device *dev)
+{
+ struct omap_uart_port_info *omap_up_info;
+
+ omap_up_info = devm_kzalloc(dev, sizeof(*omap_up_info), GFP_KERNEL);
+ if (!omap_up_info)
+ return NULL; /* out of memory */
+
+ of_property_read_u32(dev->of_node, "clock-frequency",
+ &omap_up_info->uartclk);
+ return omap_up_info;
+}
+
static int serial_omap_probe(struct platform_device *pdev)
{
struct uart_omap_port *up;
@@ -1331,6 +1345,9 @@ static int serial_omap_probe(struct platform_device *pdev)
struct omap_uart_port_info *omap_up_info = pdev->dev.platform_data;
int ret = -ENOSPC;
+ if (pdev->dev.of_node)
+ omap_up_info = of_get_uart_port_info(&pdev->dev);
+
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!mem) {
dev_err(&pdev->dev, "no mem resource?\n");
@@ -1375,9 +1392,20 @@ static int serial_omap_probe(struct platform_device *pdev)
up->port.regshift = 2;
up->port.fifosize = 64;
up->port.ops = &serial_omap_pops;
- up->port.line = pdev->id;
- sprintf(up->name, "OMAP UART%d", up->port.line);
+ if (pdev->dev.of_node)
+ up->port.line = of_alias_get_id(pdev->dev.of_node, "serial");
+ else
+ up->port.line = pdev->id;
+
+ if (up->port.line < 0) {
+ dev_err(&pdev->dev, "failed to get alias/pdev id, errno %d\n",
+ up->port.line);
+ ret = -ENODEV;
+ goto err;
+ }
+
+ sprintf(up->name, "OMAP UART%d", up->port.line);
up->port.mapbase = mem->start;
up->port.membase = ioremap(mem->start, resource_size(mem));
if (!up->port.membase) {
@@ -1530,7 +1558,7 @@ static int serial_omap_runtime_suspend(struct device *dev)
if (!up)
return -EINVAL;
- if (!pdata->enable_wakeup)
+ if (!pdata || !pdata->enable_wakeup)
return 0;
if (pdata->get_context_loss_count)
@@ -1591,12 +1619,23 @@ static const struct dev_pm_ops serial_omap_dev_pm_ops = {
serial_omap_runtime_resume, NULL)
};
+#if defined(CONFIG_OF)
+static const struct of_device_id omap_serial_of_match[] = {
+ { .compatible = "ti,omap2-uart" },
+ { .compatible = "ti,omap3-uart" },
+ { .compatible = "ti,omap4-uart" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_serial_of_match);
+#endif
+
static struct platform_driver serial_omap_driver = {
.probe = serial_omap_probe,
.remove = serial_omap_remove,
.driver = {
.name = DRIVER_NAME,
.pm = &serial_omap_dev_pm_ops,
+ .of_match_table = of_match_ptr(omap_serial_of_match),
},
};
--
1.7.1
^ permalink raw reply related
* [PATCH v3 0/4] OMAP serial device tree support
From: Rajendra Nayak @ 2011-12-14 11:55 UTC (permalink / raw)
To: linux-serial, linux-omap, devicetree-discuss, khilman
Cc: tony, govindraj.raja, b-cousson, linux-arm-kernel, linaro-dev,
patches, robherring2, Rajendra Nayak
v3 is rebased on top of the latest serial runtime
patches[1] and boot tested with/without DT on OMAP4
SDP and OMAP4 Panda boards.
Patches can be found here..
git://gitorious.org/omap-pm/linux.git for-dt/serial
I also had to pull in a fix[2] for DT testing (already in linux-omap
master) which was missing as the serial runtime branch[1]
was based on an older master commit.
Changes in v3:
-1- Rebased on latest serial runtime patches
-2- Minor typr fixes
Changes in v2:
-1- Got rid of binding to define which uart is console
-2- Added checks to default clock speed to 48Mhz
-3- Added compatible for each OMAP family
-4- Used of_alias_get_id to populate port.line
[1] git://gitorious.org/runtime_3-0/runtime_3-0.git for_3_3/lo_rc4_uartruntime
[2] http://www.spinics.net/lists/arm-kernel/msg150751.html
Rajendra Nayak (4):
omap-serial: Get rid of all pdev->id usage
omap-serial: Use default clock speed (48Mhz) if not specified
omap-serial: Add minimal device tree support
ARM: omap: pass minimal SoC/board data for UART from dt
.../devicetree/bindings/serial/omap_serial.txt | 10 +++
arch/arm/boot/dts/omap3.dtsi | 31 ++++++++
arch/arm/boot/dts/omap4.dtsi | 28 +++++++
arch/arm/mach-omap2/board-generic.c | 1 -
drivers/tty/serial/omap-serial.c | 80 +++++++++++++++----
5 files changed, 132 insertions(+), 18 deletions(-)
create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt
^ permalink raw reply
* [PATCH v3 2/4] omap-serial: Use default clock speed (48Mhz) if not specified
From: Rajendra Nayak @ 2011-12-14 11:55 UTC (permalink / raw)
To: linux-serial, linux-omap, devicetree-discuss, khilman
Cc: tony, govindraj.raja, b-cousson, linux-arm-kernel, linaro-dev,
patches, robherring2, Rajendra Nayak
In-Reply-To: <1323863746-18145-1-git-send-email-rnayak@ti.com>
Use a default clock speed of 48Mhz, instead of ending up with 0,
if platforms fail to specify a valid clock speed.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
drivers/tty/serial/omap-serial.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index a02cc9f..f14b9c5 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -43,6 +43,8 @@
#include <plat/dmtimer.h>
#include <plat/omap-serial.h>
+#define DEFAULT_CLK_SPEED 48000000 /* 48Mhz*/
+
static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
/* Forward declaration of functions */
@@ -1386,6 +1388,11 @@ static int serial_omap_probe(struct platform_device *pdev)
up->port.flags = omap_up_info->flags;
up->port.uartclk = omap_up_info->uartclk;
+ if (!up->port.uartclk) {
+ up->port.uartclk = DEFAULT_CLK_SPEED;
+ dev_warn(&pdev->dev, "No clock speed specified: using default:"
+ "%d\n", DEFAULT_CLK_SPEED);
+ }
up->uart_dma.uart_base = mem->start;
up->errata = omap_up_info->errata;
--
1.7.1
^ permalink raw reply related
* [PATCH v3 1/4] omap-serial: Get rid of all pdev->id usage
From: Rajendra Nayak @ 2011-12-14 11:55 UTC (permalink / raw)
To: linux-serial, linux-omap, devicetree-discuss, khilman
Cc: tony, govindraj.raja, b-cousson, linux-arm-kernel, linaro-dev,
patches, robherring2, Rajendra Nayak
In-Reply-To: <1323863746-18145-1-git-send-email-rnayak@ti.com>
With Device tree, pdev->id would no longer be Valid.
Hence get rid of all instances of its usage in the
driver. Device tree support for the driver is added
in subsequent patches.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
drivers/tty/serial/omap-serial.c | 30 +++++++++++++++---------------
1 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index f3ff0ca..a02cc9f 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -115,7 +115,7 @@ static void serial_omap_enable_ms(struct uart_port *port)
{
struct uart_omap_port *up = (struct uart_omap_port *)port;
- dev_dbg(up->port.dev, "serial_omap_enable_ms+%d\n", up->pdev->id);
+ dev_dbg(up->port.dev, "serial_omap_enable_ms+%d\n", up->port.line);
pm_runtime_get_sync(&up->pdev->dev);
up->ier |= UART_IER_MSI;
@@ -418,7 +418,7 @@ static unsigned int serial_omap_tx_empty(struct uart_port *port)
unsigned int ret = 0;
pm_runtime_get_sync(&up->pdev->dev);
- dev_dbg(up->port.dev, "serial_omap_tx_empty+%d\n", up->pdev->id);
+ dev_dbg(up->port.dev, "serial_omap_tx_empty+%d\n", up->port.line);
spin_lock_irqsave(&up->port.lock, flags);
ret = serial_in(up, UART_LSR) & UART_LSR_TEMT ? TIOCSER_TEMT : 0;
spin_unlock_irqrestore(&up->port.lock, flags);
@@ -436,7 +436,7 @@ static unsigned int serial_omap_get_mctrl(struct uart_port *port)
status = check_modem_status(up);
pm_runtime_put(&up->pdev->dev);
- dev_dbg(up->port.dev, "serial_omap_get_mctrl+%d\n", up->pdev->id);
+ dev_dbg(up->port.dev, "serial_omap_get_mctrl+%d\n", up->port.line);
if (status & UART_MSR_DCD)
ret |= TIOCM_CAR;
@@ -454,7 +454,7 @@ static void serial_omap_set_mctrl(struct uart_port *port, unsigned int mctrl)
struct uart_omap_port *up = (struct uart_omap_port *)port;
unsigned char mcr = 0;
- dev_dbg(up->port.dev, "serial_omap_set_mctrl+%d\n", up->pdev->id);
+ dev_dbg(up->port.dev, "serial_omap_set_mctrl+%d\n", up->port.line);
if (mctrl & TIOCM_RTS)
mcr |= UART_MCR_RTS;
if (mctrl & TIOCM_DTR)
@@ -478,7 +478,7 @@ static void serial_omap_break_ctl(struct uart_port *port, int break_state)
struct uart_omap_port *up = (struct uart_omap_port *)port;
unsigned long flags = 0;
- dev_dbg(up->port.dev, "serial_omap_break_ctl+%d\n", up->pdev->id);
+ dev_dbg(up->port.dev, "serial_omap_break_ctl+%d\n", up->port.line);
pm_runtime_get_sync(&up->pdev->dev);
spin_lock_irqsave(&up->port.lock, flags);
if (break_state == -1)
@@ -504,7 +504,7 @@ static int serial_omap_startup(struct uart_port *port)
if (retval)
return retval;
- dev_dbg(up->port.dev, "serial_omap_startup+%d\n", up->pdev->id);
+ dev_dbg(up->port.dev, "serial_omap_startup+%d\n", up->port.line);
pm_runtime_get_sync(&up->pdev->dev);
/*
@@ -545,7 +545,7 @@ static int serial_omap_startup(struct uart_port *port)
0);
init_timer(&(up->uart_dma.rx_timer));
up->uart_dma.rx_timer.function = serial_omap_rxdma_poll;
- up->uart_dma.rx_timer.data = up->pdev->id;
+ up->uart_dma.rx_timer.data = up->port.line;
/* Currently the buffer size is 4KB. Can increase it */
up->uart_dma.rx_buf = dma_alloc_coherent(NULL,
up->uart_dma.rx_buf_size,
@@ -573,7 +573,7 @@ static void serial_omap_shutdown(struct uart_port *port)
struct uart_omap_port *up = (struct uart_omap_port *)port;
unsigned long flags = 0;
- dev_dbg(up->port.dev, "serial_omap_shutdown+%d\n", up->pdev->id);
+ dev_dbg(up->port.dev, "serial_omap_shutdown+%d\n", up->port.line);
pm_runtime_get_sync(&up->pdev->dev);
/*
@@ -883,7 +883,7 @@ serial_omap_set_termios(struct uart_port *port, struct ktermios *termios,
spin_unlock_irqrestore(&up->port.lock, flags);
pm_runtime_put(&up->pdev->dev);
- dev_dbg(up->port.dev, "serial_omap_set_termios+%d\n", up->pdev->id);
+ dev_dbg(up->port.dev, "serial_omap_set_termios+%d\n", up->port.line);
}
static void
@@ -893,7 +893,7 @@ serial_omap_pm(struct uart_port *port, unsigned int state,
struct uart_omap_port *up = (struct uart_omap_port *)port;
unsigned char efr;
- dev_dbg(up->port.dev, "serial_omap_pm+%d\n", up->pdev->id);
+ dev_dbg(up->port.dev, "serial_omap_pm+%d\n", up->port.line);
pm_runtime_get_sync(&up->pdev->dev);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
@@ -932,7 +932,7 @@ static void serial_omap_config_port(struct uart_port *port, int flags)
struct uart_omap_port *up = (struct uart_omap_port *)port;
dev_dbg(up->port.dev, "serial_omap_config_port+%d\n",
- up->pdev->id);
+ up->port.line);
up->port.type = PORT_OMAP;
}
@@ -949,7 +949,7 @@ serial_omap_type(struct uart_port *port)
{
struct uart_omap_port *up = (struct uart_omap_port *)port;
- dev_dbg(up->port.dev, "serial_omap_type+%d\n", up->pdev->id);
+ dev_dbg(up->port.dev, "serial_omap_type+%d\n", up->port.line);
return up->name;
}
@@ -1110,7 +1110,7 @@ static struct console serial_omap_console = {
static void serial_omap_add_console_port(struct uart_omap_port *up)
{
- serial_omap_console_ports[up->pdev->id] = up;
+ serial_omap_console_ports[up->port.line] = up;
}
#define OMAP_CONSOLE (&serial_omap_console)
@@ -1364,7 +1364,6 @@ static int serial_omap_probe(struct platform_device *pdev)
ret = -ENOMEM;
goto do_release_region;
}
- sprintf(up->name, "OMAP UART%d", pdev->id);
up->pdev = pdev;
up->port.dev = &pdev->dev;
up->port.type = PORT_OMAP;
@@ -1375,6 +1374,7 @@ static int serial_omap_probe(struct platform_device *pdev)
up->port.fifosize = 64;
up->port.ops = &serial_omap_pops;
up->port.line = pdev->id;
+ sprintf(up->name, "OMAP UART%d", up->port.line);
up->port.mapbase = mem->start;
up->port.membase = ioremap(mem->start, resource_size(mem));
@@ -1417,7 +1417,7 @@ static int serial_omap_probe(struct platform_device *pdev)
pm_runtime_enable(&pdev->dev);
pm_runtime_get_sync(&pdev->dev);
- ui[pdev->id] = up;
+ ui[up->port.line] = up;
serial_omap_add_console_port(up);
ret = uart_add_one_port(&serial_omap_reg, &up->port);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v8 00/20] OMAP2+: UART: Runtime adaptation + cleanup
From: Govindraj @ 2011-12-14 9:21 UTC (permalink / raw)
To: Kevin Hilman
Cc: Tony Lindgren, linux-omap, linux-serial, linux-arm-kernel,
Partha Basak, Vishwanath Sripathy, Rajendra Nayak,
Santosh Shilimkar, Govindraj.R
In-Reply-To: <87zkewt5e0.fsf@ti.com>
On Wed, Dec 14, 2011 at 5:02 AM, Kevin Hilman <khilman@ti.com> wrote:
> Govindraj <govindraj.ti@gmail.com> writes:
>
> [...]
>
>> I have re-based this patch series against LO master
>> commit id: deee6d5359969a0ce4e2760cfd7b9f379bd5698a
>>
>> Same is available here [1]
>>
>> I have tested this patch series along with:
>>
>> 1.) Tero's V11 irq chaining series
>> http://www.spinics.net/lists/linux-omap/msg61445.html
>> (This patch series is used for uart wakeup handling using
>> prcm_irq chaining)
>>
>> 2.) Rajendra's hwmod change
>> http://www.spinics.net/lists/arm-kernel/msg148632.html
>> (This patch handles init_no_idle flag setting
>> without this patch there will be boot warning however
>> all pm features will work after boot up.)
>
> Actually, without Rajendra's patch all features do not work. I don't
> get UART console wakeups from idle (with runtime PM autosuspend enabled)
> on 3430/n900 or 3530/Overo without Rajendra's patch.
okay, I forgot last time when I tested without rajendra's patch was
with a custom activate func.
and now we have removed it.
Yes you are correct Rajendra's patch + Tero's v11 series is a needed
for proper uart_runtime_pm functioning.
--
Thanks,
Govindraj.R
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v8 00/20] OMAP2+: UART: Runtime adaptation + cleanup
From: Govindraj @ 2011-12-14 8:46 UTC (permalink / raw)
To: Kevin Hilman
Cc: Tony Lindgren, linux-omap, linux-serial, linux-arm-kernel,
Partha Basak, Vishwanath Sripathy, Rajendra Nayak,
Santosh Shilimkar, Govindraj.R
In-Reply-To: <87fwgow9vz.fsf@ti.com>
On Wed, Dec 14, 2011 at 12:56 AM, Kevin Hilman <khilman@ti.com> wrote:
> Govindraj <govindraj.ti@gmail.com> writes:
>
> [...]
>
>> I have re-based this patch series against LO master
>> commit id: deee6d5359969a0ce4e2760cfd7b9f379bd5698a
>>
>> Same is available here [1]
>>
>> I have tested this patch series along with:
>>
>> 1.) Tero's V11 irq chaining series
>> http://www.spinics.net/lists/linux-omap/msg61445.html
>> (This patch series is used for uart wakeup handling using
>> prcm_irq chaining)
>>
>> 2.) Rajendra's hwmod change
>> http://www.spinics.net/lists/arm-kernel/msg148632.html
>> (This patch handles init_no_idle flag setting
>> without this patch there will be boot warning however
>> all pm features will work after boot up.)
>>
>> 3.) Vishwa's io daisy chain changes.
>> http://permalink.gmane.org/gmane.linux.ports.arm.omap/65500
>> (tested with and without this patch series pm features works).
>>
>> Same combination of patches based on above commit id
>> used for testing is available here [2].
>
> Please have a closer look at your branch.
>
> The second commit[1] commits the .rej file from a failed patch apply,
> so obviously doesn't do what was intended.
>
Sorry my bad I have refreshed the uart runtime branch [1]
& test branch [2].
stat for uart patches for the both the branches as here [3]
--
Thanks,
Govindraj.R
[1]:
git://gitorious.org/runtime_3-0/runtime_3-0.git
for_3_3/lo_rc4_uartruntime
[2]:
git://gitorious.org/runtime_3-0/runtime_3-0.git
for_3_3/tmp_rc4_uart_pm_intg
[3]:
<<uart runtime branch>>
ubnuser@ula0131859:~/clones/runtime_3-0$ git diff --stat deee6d5
arch/arm/mach-omap2/board-3430sdp.c | 100 +---
arch/arm/mach-omap2/board-4430sdp.c | 68 +--
arch/arm/mach-omap2/board-n8x0.c | 6 +-
arch/arm/mach-omap2/board-omap4panda.c | 68 +--
arch/arm/mach-omap2/cpuidle34xx.c | 6 -
arch/arm/mach-omap2/pm24xx.c | 20 -
arch/arm/mach-omap2/pm34xx.c | 43 --
arch/arm/mach-omap2/serial.c | 907 +++++++------------------
arch/arm/plat-omap/include/plat/omap-serial.h | 37 +-
arch/arm/plat-omap/include/plat/serial.h | 10 +-
drivers/tty/serial/omap-serial.c | 343 ++++++++--
11 files changed, 584 insertions(+), 1024 deletions(-)
<<tmp_intg_test branch>>
ubnuser@ula0131859:~/clones/runtime_3-0$ git diff --stat deee6d5..aad8423
arch/arm/mach-omap2/board-3430sdp.c | 100 +---
arch/arm/mach-omap2/board-4430sdp.c | 68 +--
arch/arm/mach-omap2/board-n8x0.c | 6 +-
arch/arm/mach-omap2/board-omap4panda.c | 68 +--
arch/arm/mach-omap2/cpuidle34xx.c | 6 -
arch/arm/mach-omap2/pm24xx.c | 20 -
arch/arm/mach-omap2/pm34xx.c | 43 --
arch/arm/mach-omap2/serial.c | 907 +++++++------------------
arch/arm/plat-omap/include/plat/omap-serial.h | 37 +-
arch/arm/plat-omap/include/plat/serial.h | 10 +-
drivers/tty/serial/omap-serial.c | 343 ++++++++--
11 files changed, 584 insertions(+), 1024 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5] tty: serial: imx: Allow UART to be a source for wakeup
From: Richard Zhao @ 2011-12-14 0:44 UTC (permalink / raw)
To: Fabio Estevam
Cc: linux-arm-kernel, Fabio Estevam, linux-serial, shawn.guo, kernel,
alan
In-Reply-To: <1323746628-25163-1-git-send-email-festevam@gmail.com>
On Tue, Dec 13, 2011 at 01:23:48AM -0200, Fabio Estevam wrote:
> Allow UART to be a source for wakeup from low power mode.
>
> Tested on a MX27PDK by doing:
>
> echo enabled > /sys/devices/platform/imx21-uart.0/tty/ttymxc0/power/wakeup
>
> echo mem > /sys/power/state
>
> and then pressing a key in the console will wakeup the sytem.
>
> Suggested-by: Shawn Guo <shawn.guo@freescale.com>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
For imx6q sabrelite,
Tested-by: Richard Zhao <richard.zhao@freescale.com>
> ---
> Changes since v4:
> - Let serial core handle device_init_wakeup/device_set_wakeup_enable.
> Changes since v3:
> - Remove IMXUART_CANWAKE flag. Let userspace write in /sys/ file
> in order to enable UART wakeup source.
> Changes since v2:
> - Remove incorrect enable_irq_wake from serial_imx_resume
> Changes since v1:
> - Pass the can-wake property via DT correctly
> drivers/tty/serial/imx.c | 15 +++++++++++++++
> 1 files changed, 15 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
> index 163fc90..0022bbd 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -566,6 +566,9 @@ static irqreturn_t imx_int(int irq, void *dev_id)
> if (sts & USR1_RTSD)
> imx_rtsint(irq, dev_id);
>
> + if (sts & USR1_AWAKE)
> + writel(USR1_AWAKE, sport->port.membase + USR1);
> +
> return IRQ_HANDLED;
> }
>
> @@ -1269,6 +1272,12 @@ static struct uart_driver imx_reg = {
> static int serial_imx_suspend(struct platform_device *dev, pm_message_t state)
> {
> struct imx_port *sport = platform_get_drvdata(dev);
> + unsigned int val;
> +
> + /* enable wakeup from i.MX UART */
> + val = readl(sport->port.membase + UCR3);
> + val |= UCR3_AWAKEN;
> + writel(val, sport->port.membase + UCR3);
>
> if (sport)
> uart_suspend_port(&imx_reg, &sport->port);
> @@ -1279,7 +1288,13 @@ static int serial_imx_suspend(struct platform_device *dev, pm_message_t state)
> static int serial_imx_resume(struct platform_device *dev)
> {
> struct imx_port *sport = platform_get_drvdata(dev);
> + unsigned int val;
>
> + /* disable wakeup from i.MX UART */
> + val = readl(sport->port.membase + UCR3);
> + val &= ~UCR3_AWAKEN;
> + writel(val, sport->port.membase + UCR3);
> +
> if (sport)
> uart_resume_port(&imx_reg, &sport->port);
>
> --
> 1.7.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* Re: [PATCH v8 00/20] OMAP2+: UART: Runtime adaptation + cleanup
From: Kevin Hilman @ 2011-12-13 23:32 UTC (permalink / raw)
To: Govindraj
Cc: Tony Lindgren, linux-omap, linux-serial, linux-arm-kernel,
Partha Basak, Vishwanath Sripathy, Rajendra Nayak,
Santosh Shilimkar, Govindraj.R
In-Reply-To: <CAAL8m4wGN5ykm3-+xrGPe-WJUDBdterxAyZ=C3kH862+n1DprQ@mail.gmail.com>
Govindraj <govindraj.ti@gmail.com> writes:
[...]
> I have re-based this patch series against LO master
> commit id: deee6d5359969a0ce4e2760cfd7b9f379bd5698a
>
> Same is available here [1]
>
> I have tested this patch series along with:
>
> 1.) Tero's V11 irq chaining series
> http://www.spinics.net/lists/linux-omap/msg61445.html
> (This patch series is used for uart wakeup handling using
> prcm_irq chaining)
>
> 2.) Rajendra's hwmod change
> http://www.spinics.net/lists/arm-kernel/msg148632.html
> (This patch handles init_no_idle flag setting
> without this patch there will be boot warning however
> all pm features will work after boot up.)
Actually, without Rajendra's patch all features do not work. I don't
get UART console wakeups from idle (with runtime PM autosuspend enabled)
on 3430/n900 or 3530/Overo without Rajendra's patch.
Kevin
^ permalink raw reply
* Re: [PATCH v8 00/20] OMAP2+: UART: Runtime adaptation + cleanup
From: Kevin Hilman @ 2011-12-13 19:26 UTC (permalink / raw)
To: Govindraj
Cc: Tony Lindgren, linux-omap, linux-serial, linux-arm-kernel,
Partha Basak, Vishwanath Sripathy, Rajendra Nayak,
Santosh Shilimkar, Govindraj.R
In-Reply-To: <CAAL8m4wGN5ykm3-+xrGPe-WJUDBdterxAyZ=C3kH862+n1DprQ@mail.gmail.com>
Govindraj <govindraj.ti@gmail.com> writes:
[...]
> I have re-based this patch series against LO master
> commit id: deee6d5359969a0ce4e2760cfd7b9f379bd5698a
>
> Same is available here [1]
>
> I have tested this patch series along with:
>
> 1.) Tero's V11 irq chaining series
> http://www.spinics.net/lists/linux-omap/msg61445.html
> (This patch series is used for uart wakeup handling using
> prcm_irq chaining)
>
> 2.) Rajendra's hwmod change
> http://www.spinics.net/lists/arm-kernel/msg148632.html
> (This patch handles init_no_idle flag setting
> without this patch there will be boot warning however
> all pm features will work after boot up.)
>
> 3.) Vishwa's io daisy chain changes.
> http://permalink.gmane.org/gmane.linux.ports.arm.omap/65500
> (tested with and without this patch series pm features works).
>
> Same combination of patches based on above commit id
> used for testing is available here [2].
Please have a closer look at your branch.
The second commit[1] commits the .rej file from a failed patch apply,
so obviously doesn't do what was intended.
Kevin
[1]
>From ae5d13382a5784f35f5bfe05413fbec4632e58f0 Mon Sep 17 00:00:00 2001
From: "Govindraj.R" <govindraj.raja@ti.com>
Date: Tue, 13 Sep 2011 13:32:32 +0530
Subject: [PATCH] OMAP2+: UART: cleanup 8250 console driver support
We had been using traditional 8250 driver as uart console driver
prior to omap-serial driver. Since we have omap-serial driver
in mainline kernel for some time now it has been used as default
uart console driver on omap2+ platforms. Remove 8250 support for
omap-uarts.
Serial_in and serial_out override for 8250 serial driver is also
removed. Empty fifo read fix is already taken care with omap-serial
driver with data ready bit check from LSR reg before reading RX fifo.
Also waiting for THRE(transmit hold reg empty) is done with wait_for_xmitr
in omap-serial driver.
Serial_in/out overrides are not neceesary for omap-serial driver
and things that are taken with omap-serial driver are removed here.
Remove headers that were necessary to support 8250 support
and remove all config bindings done to keep 8250 backward compatibility
while adding omap-serial driver. Remove omap_uart_reset needed for
8250 autoconf.
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
---
arch/arm/mach-omap2/serial.c.rej | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/serial.c.rej
diff --git a/arch/arm/mach-omap2/serial.c.rej b/arch/arm/mach-omap2/serial.c.rej
new file mode 100644
index 0000000..2325897
--- /dev/null
+++ b/arch/arm/mach-omap2/serial.c.rej
@@ -0,0 +1,26 @@
+--- arch/arm/mach-omap2/serial.c
++++ arch/arm/mach-omap2/serial.c
+@@ -19,23 +19,17 @@
+ */
+ #include <linux/kernel.h>
+ #include <linux/init.h>
+-#include <linux/serial_reg.h>
+ #include <linux/clk.h>
+ #include <linux/io.h>
+ #include <linux/delay.h>
+ #include <linux/platform_device.h>
+ #include <linux/slab.h>
+-#include <linux/serial_8250.h>
+ #include <linux/pm_runtime.h>
+ #include <linux/console.h>
+
+-#ifdef CONFIG_SERIAL_OMAP
+ #include <plat/omap-serial.h>
+-#endif
+-
+ #include <plat/common.h>
+ #include <plat/board.h>
+-#include <plat/clock.h>
+ #include <plat/dma.h>
+ #include <plat/omap_hwmod.h>
+ #include <plat/omap_device.h>
--
1.7.6
^ permalink raw reply related
* Re: serial device name for smart card reader that is integrated to Anysee DVB USB device
From: Alan Cox @ 2011-12-13 17:41 UTC (permalink / raw)
To: Antti Palosaari
Cc: Greg KH, Oliver Neukum, linux-serial, linux-media, linux-usb,
Bjørn Mork, James Courtier-Dutton, HoP,
István Váradi
In-Reply-To: <4EE77DA9.9060102@iki.fi>
> Anyhow, I would like now ask how to proceed. Should I export four new
> functions as replacement of those leaving old functionality as
> currently. Or should I change existing ones like adding new pointer for
> struct usb_serial and use it instead of struct usb_interface when not NULL.
I think I would favour adding new ones. The new ones can be added,
debugged and then the old ones phased out afterwards if it is worth
cleaning them up. That saves having to fix everything else at the same
time.
Alan
^ permalink raw reply
* Re: [PATCH v8 00/20] OMAP2+: UART: Runtime adaptation + cleanup
From: Kevin Hilman @ 2011-12-13 17:35 UTC (permalink / raw)
To: Rajendra Nayak
Cc: Alan Cox, Greg KH, linux-omap, linux-serial, linux-arm-kernel,
Tony Lindgren, Partha Basak, Vishwanath Sripathy,
Santosh Shilimkar, Govindraj.R
In-Reply-To: <4EE75E1A.7080101@ti.com>
Rajendra Nayak <rnayak@ti.com> writes:
> Hi Kevin,
>
> On Wednesday 07 December 2011 05:51 AM, Kevin Hilman wrote:
>> "Govindraj.R"<govindraj.raja@ti.com> writes:
>>
>>> Converting uart driver to adapt to pm runtime API's.
>>> Code re-org + cleanup.
>>> Moving some functionality from serial.c to omap-serial.c
>>
>> Alan, can you confirm your Ack's are still valid on the drivers/tty
>> parts of this series? It has gone through quite a few changes since
>> your original ack.
>>
>> Greg, are you ok with this series merging via the OMAP tree since it is
>> changing arch/arm/mach-omap2/* code as well as the driver, and should go
>> together. If so, with your ack (on the drivers/tty/* parts), I'll
>> handle this series through the OMAP tree.
>
> I had a series to add DT support for omap-serial, which I did on top
> of the runtime series from Govindraj. Its already acked by Rob Herring
> for the DT parts. Would you be able to pick those up as well if its
> fine with Greg?
Yes, those should go on top of Govindraj's series.
I'm OK with taking them, but I'd like to see them rebased on Govidraj's
latest and see several Tested-by reports from various people since it is
pretty late in the merge cycle.
Kevin
^ permalink raw reply
* Re: serial device name for smart card reader that is integrated to Anysee DVB USB device
From: Antti Palosaari @ 2011-12-13 16:30 UTC (permalink / raw)
To: Greg KH
Cc: Oliver Neukum, linux-serial, linux-media, linux-usb,
Bjørn Mork, James Courtier-Dutton, HoP,
István Váradi
In-Reply-To: <201110141932.51378.oliver@neukum.org>
On 10/14/2011 08:32 PM, Oliver Neukum wrote:
> Am Mittwoch, 5. Oktober 2011, 10:16:06 schrieb Oliver Neukum:
>> Am Mittwoch, 5. Oktober 2011, 08:19:10 schrieb Antti Palosaari:
>>> On 10/05/2011 09:15 AM, Oliver Neukum wrote:
>>
>>>> But, Greg, Antti makes a very valid point here. The generic code assumes that
>>>> it owns intfdata, that is you cannot use it as is for access to anything that lacks
>>>> its own interface. But this is not a fatal flaw. We can alter the generic code to use
>>>> an accessor function the driver can provide and make it default to get/set_intfdata
>>>>
>>>> What do you think?
>>>
>>> Oliver, I looked your old thread reply but I didn't catch how you meant
>>> it to happen. Could you give some small example?
>
> here is the code I come up with at an early, extremely incomplete stage.
> Just for your information because I'll stop working on this for a few days.
I am back with that issue again. I just analysed both Oliver's code and
usb-serial.c.
Problem are only these functions:
extern int usb_serial_probe(struct usb_interface *iface, const struct
usb_device_id *id);
extern void usb_serial_disconnect(struct usb_interface *iface);
extern int usb_serial_suspend(struct usb_interface *intf, pm_message_t
message);
extern int usb_serial_resume(struct usb_interface *intf);
as all those takes struct usb_interface as parameter. For the
disconnect, suspend and resume it usb_interface param is used just for
getting pointer to struct usb_serial. That's easy. The probe is more
complex and needs some deeper changes. Main problem for probe seems to
be also it saves struct usb_serial pointer to struct usb_interface
usb_set_intfdata(interface, serial);
Anyhow, I would like now ask how to proceed. Should I export four new
functions as replacement of those leaving old functionality as
currently. Or should I change existing ones like adding new pointer for
struct usb_serial and use it instead of struct usb_interface when not NULL.
regards
Antti
--
http://palosaari.fi/
^ permalink raw reply
* Confirmation from Libyan embassy
From: J. Zakia @ 2011-12-13 15:46 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 177 bytes --]
In a brief introduction, I am an embassy attachй with the Libyan Government in the Hague, Netherlands.
Please kindly see the attachment for more details and respond immediately
[-- Attachment #2: attachment.rtf --]
[-- Type: application/octet-stream, Size: 3042 bytes --]
^ permalink raw reply
* Re: [PATCH v8 00/20] OMAP2+: UART: Runtime adaptation + cleanup
From: Rajendra Nayak @ 2011-12-13 14:15 UTC (permalink / raw)
To: Kevin Hilman
Cc: Alan Cox, Greg KH, linux-omap, linux-serial, linux-arm-kernel,
Tony Lindgren, Partha Basak, Vishwanath Sripathy,
Santosh Shilimkar, Govindraj.R
In-Reply-To: <874nxd5j0f.fsf@ti.com>
Hi Kevin,
On Wednesday 07 December 2011 05:51 AM, Kevin Hilman wrote:
> "Govindraj.R"<govindraj.raja@ti.com> writes:
>
>> Converting uart driver to adapt to pm runtime API's.
>> Code re-org + cleanup.
>> Moving some functionality from serial.c to omap-serial.c
>
> Alan, can you confirm your Ack's are still valid on the drivers/tty
> parts of this series? It has gone through quite a few changes since
> your original ack.
>
> Greg, are you ok with this series merging via the OMAP tree since it is
> changing arch/arm/mach-omap2/* code as well as the driver, and should go
> together. If so, with your ack (on the drivers/tty/* parts), I'll
> handle this series through the OMAP tree.
I had a series to add DT support for omap-serial, which I did on top
of the runtime series from Govindraj. Its already acked by Rob Herring
for the DT parts. Would you be able to pick those up as well if its
fine with Greg?
regards,
Rajendra
>
> Thanks,
>
> Kevin
>
>
>
>
>
^ permalink raw reply
* Re: [PATCH v8 00/20] OMAP2+: UART: Runtime adaptation + cleanup
From: Govindraj @ 2011-12-13 13:01 UTC (permalink / raw)
To: Kevin Hilman, Tony Lindgren
Cc: linux-omap, linux-serial, linux-arm-kernel, Partha Basak,
Vishwanath Sripathy, Rajendra Nayak, Santosh Shilimkar,
Govindraj.R
In-Reply-To: <1321005446-21741-1-git-send-email-govindraj.raja@ti.com>
Hi Tony/kevin,
On Fri, Nov 11, 2011 at 3:27 PM, Govindraj.R <govindraj.raja@ti.com> wrote:
> Converting uart driver to adapt to pm runtime API's.
> Code re-org + cleanup.
> Moving some functionality from serial.c to omap-serial.c
>
> Changes involves:
> ================
> 1.) Cleaning up certain uart calls from sram_idle func.
> 2.) Removed all types of uart clock handling code from serial.c
> 3.) Using hwmod_mux API enable wakeup capability for uart pad during
> hwmod_idle state i.e., when uart clocks are disabled we can enable
> io-pad wakeup capability for uart if mux_data is available for
> given uart. Also during during resume from idle call to uart we need
> to enable clocks back conditionally and this can be done only when io-pad
> wakeup event bit is set for uart_rx pad. So we need a hwmod API
> which can probe the uart pad and let us know whether a uart wakeup
> happened. So omap_hmwod_pad_wakeup_status API is added to meet this
> requirement.
> 3.) Adapted omap-serial driver to use runtime API's.
> 4.) Modify serial_init calls to accept uart parameters from board file.
> Like dma_usage, rx_timeout, dma_rx_pollrate, auto_suspend_timeout etc.
> 5.) Use the omap_prm driver with irq_chaining to wake up uart after clocks are
> cut.
>
> Patch series is based on 3.2-rc1.
>
> Patch series depends on *Tero's v9 Irq_chaining patches*.
> Dependent irq_chaining patches are as below.
>
> 89ac62b omap3+: add omap prm driver initialization
> 170431f OMAP3: pm: do not enable PRCM MPU interrupts manually
> 9aba1b0 omap3: pm: use prcm chain handler
> 435481f OMAP2+: mux: add support for PAD wakeup interrupts
> 5b2d361 mfd: omap-prm: added suspend prepare and complete callbacks
> aa55c41 mfd: omap-prm: added chain interrupt handler
> d1db904 mfd: omap-prm: add driver skeleton
> 31d056c TEMP: OMAP4xxx: hwmod data: add PRM hwmod
> 19ec3bc TEMP: OMAP3xxx: hwmod data: add PRM hwmod
> 9a89688 OMAP2+: hwmod: Add API to check IO PAD wakeup status
> 78e8b65 OMAP2+: hwmod: Add API to enable IO ring wakeup.
>
> Same combination is hosted at:
> git://gitorious.org/runtime_3-0/runtime_3-0.git 3.2-rc1_uart_runtime
>
> Ensure CONFIG_OMAP_PRM is set while testing irq_chaining with uart.
> And for pm_qos usage ensure CONFIG_CPU_IDLE is selected other wise
> console might be sluggish.
>
I have re-based this patch series against LO master
commit id: deee6d5359969a0ce4e2760cfd7b9f379bd5698a
Same is available here [1]
I have tested this patch series along with:
1.) Tero's V11 irq chaining series
http://www.spinics.net/lists/linux-omap/msg61445.html
(This patch series is used for uart wakeup handling using
prcm_irq chaining)
2.) Rajendra's hwmod change
http://www.spinics.net/lists/arm-kernel/msg148632.html
(This patch handles init_no_idle flag setting
without this patch there will be boot warning however
all pm features will work after boot up.)
3.) Vishwa's io daisy chain changes.
http://permalink.gmane.org/gmane.linux.ports.arm.omap/65500
(tested with and without this patch series pm features works).
Same combination of patches based on above commit id
used for testing is available here [2].
--
Thanks,
Govindraj.R
[1]:
git://gitorious.org/runtime_3-0/runtime_3-0.git
for_3_3/lo_rc4_uartruntime
[2]:
git://gitorious.org/runtime_3-0/runtime_3-0.git
for_3_3/tmp_rc4_uart_pm_intg
> Changes from v7:
> ---------------
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg57804.html
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg58209.html
> http://www.spinics.net/lists/linux-omap/msg59978.html
> http://www.spinics.net/lists/linux-serial/msg04772.html
>
> Testing updates:
> ----------------
> OMAP2420/2430SDP: Boot tested.
>
> OMAP3430SDP:
> retention, off_mode, system_wide suspend is tested.
> (earlyprintk & no_console_suspend checked)
>
> OMAP3630 - Zoom3:
> pm-retention checked with quart/omap-uart3
> [Also tested with uart3 as console uart and pm-ret checked]
>
> BeagleBoard XM Rev C(3630):
> retention, off_mode, system_wide suspend is tested.
>
> Deepak K (1):
> OMAP2+: UART: Allow UART parameters to be configured from board file.
>
> Govindraj.R (18):
> OMAP2+: UART: cleanup + remove uart pm specific API
> OMAP2+: UART: cleanup 8250 console driver support
> OMAP2+: UART: Cleanup part of clock gating mechanism for uart
> OMAP2+: UART: Add default mux for all uarts.
> OMAP2+: UART: Remove mapbase/membase fields from pdata.
> OMAP2+: UART: Add runtime pm support for omap-serial driver
> OMAP2+: UART: Remove context_save and move context restore to driver
> OMAP2+: UART: Ensure all reg values configured are available from
> port structure
> OMAP2+: UART: Remove uart reset function.
> OMAP2+: UART: Get context loss count to context restore
> OMAP2+: UART: Move errata handling from serial.c to omap-serial
> OMAP2+: UART: Add wakeup mechanism for omap-uarts
> OMAP2+: UART: Remove old and unused clocks handling funcs
> OMAP2+: UART: remove temporary variable used to count uart instance
> OMAP2+: UART: Use custom activate func for console uart.
> OMAP2+: UART: Avoid uart idling on suspend for no_console_suspend
> usecase
> OMAP2+: UART: Do not gate uart clocks if used for debug_prints
> OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos
>
> Jon Hunter (1):
> OMAP2+: UART: Make the RX_TIMEOUT for DMA configurable for each UART
>
> arch/arm/mach-omap2/board-3430sdp.c | 100 +---
> arch/arm/mach-omap2/board-4430sdp.c | 68 +--
> arch/arm/mach-omap2/board-n8x0.c | 6 +-
> arch/arm/mach-omap2/board-omap4panda.c | 68 +--
> arch/arm/mach-omap2/cpuidle34xx.c | 5 -
> arch/arm/mach-omap2/pm24xx.c | 20 -
> arch/arm/mach-omap2/pm34xx.c | 42 --
> arch/arm/mach-omap2/serial.c | 926 +++++++------------------
> arch/arm/plat-omap/include/plat/omap-serial.h | 36 +-
> arch/arm/plat-omap/include/plat/serial.h | 10 +-
> drivers/tty/serial/omap-serial.c | 341 ++++++++--
> 11 files changed, 607 insertions(+), 1015 deletions(-)
>
> --
> 1.7.4.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majordomo@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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 2/2 v3] serial: bfin-uart: Remove ASYNC_CTS_FLOW flag for hardware automatic CTS.
From: Sonic Zhang @ 2011-12-13 4:22 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-serial; +Cc: LKML, uclinux-dist-devel, Sonic Zhang
In-Reply-To: <1323750122-17698-1-git-send-email-sonic.adi@gmail.com>
From: Sonic Zhang <sonic.zhang@analog.com>
Blackfin uart supports automatic CTS trigger when hardware flow control is enabled.
No need to start and top tx in CTS interrupt. So, remote ASYNC_CTS_FLOW flag.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
---
drivers/tty/serial/bfin_uart.c | 17 ++++++++++++++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/bfin_uart.c b/drivers/tty/serial/bfin_uart.c
index dedd9ab..26953bf 100644
--- a/drivers/tty/serial/bfin_uart.c
+++ b/drivers/tty/serial/bfin_uart.c
@@ -116,11 +116,20 @@ static void bfin_serial_set_mctrl(struct uart_port *port, unsigned int mctrl)
static irqreturn_t bfin_serial_mctrl_cts_int(int irq, void *dev_id)
{
struct bfin_serial_port *uart = dev_id;
- unsigned int status;
-
- status = bfin_serial_get_mctrl(&uart->port);
+ unsigned int status = bfin_serial_get_mctrl(&uart->port);
#ifdef CONFIG_SERIAL_BFIN_HARD_CTSRTS
+ struct tty_struct *tty = uart->port.state->port.tty;
+
UART_CLEAR_SCTS(uart);
+ if (tty->hw_stopped) {
+ if (status) {
+ tty->hw_stopped = 0;
+ uart_write_wakeup(&uart->port);
+ }
+ } else {
+ if (!status)
+ tty->hw_stopped = 1;
+ }
#endif
uart_handle_cts_change(&uart->port, status & TIOCM_CTS);
@@ -1358,7 +1367,9 @@ static int bfin_serial_probe(struct platform_device *pdev)
uart->cts_pin = -1;
else {
uart->cts_pin = res->start;
+#ifdef CONFIG_SERIAL_BFIN_CTSRTS
uart->port.flags |= ASYNC_CTS_FLOW;
+#endif
}
res = platform_get_resource(pdev, IORESOURCE_IO, 1);
--
1.7.0.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox