* Re: [PATCH v3 0/4] OMAP serial device tree support
From: Rob Herring @ 2011-12-16 22:02 UTC (permalink / raw)
To: Tony Lindgren
Cc: Rajendra Nayak, linux-serial, linux-omap, devicetree-discuss,
khilman, govindraj.raja, b-cousson, linux-arm-kernel, linaro-dev,
patches
In-Reply-To: <20111216215731.GQ32251@atomide.com>
Tony,
On 12/16/2011 03:57 PM, Tony Lindgren wrote:
> Rob,
>
> * Rob Herring <robherring2@gmail.com> [111214 05:16]:
>> 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>
>
> Care to check if your Reviewed-by can also be applied
> to the additional patch "[PATCH] arm/dts: Add minimal device
> tree support for omap2420 and omap2430" that's needed
> to keep serial port working for omap2 with this series?
It looks fine.
Rob
^ permalink raw reply
* Re: [PATCH v3 0/4] OMAP serial device tree support
From: Tony Lindgren @ 2011-12-16 21:57 UTC (permalink / raw)
To: Rob Herring
Cc: Rajendra Nayak, linux-serial, linux-omap, devicetree-discuss,
khilman, govindraj.raja, b-cousson, linux-arm-kernel, linaro-dev,
patches
In-Reply-To: <4EE8A90A.10206@gmail.com>
Rob,
* Rob Herring <robherring2@gmail.com> [111214 05:16]:
> 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>
Care to check if your Reviewed-by can also be applied
to the additional patch "[PATCH] arm/dts: Add minimal device
tree support for omap2420 and omap2430" that's needed
to keep serial port working for omap2 with this series?
Regards,
Tony
^ permalink raw reply
* Re: [GIT PULL] OMAP: UART cleanup and runtime PM conversion for v3.3
From: Tony Lindgren @ 2011-12-16 18:24 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-omap, linux-arm-kernel, linux-serial, Govindraj Raja
In-Reply-To: <878vmeodsx.fsf@ti.com>
* Kevin Hilman <khilman@ti.com> [111214 16:22]:
> Tony,
>
> Please pull the OMAP UART cleanup and conversion to runtime PM. I had
> to rebase it onto your soc branch due to the serial.c changes there.
>
> This includes changes to drivers/tty/serial/omap-serial.c and those
> changes have Acks from Greg KH and Alan Cox and I got the OK from them
> to merge this all together via the OMAP tree.
>
> Thanks to Govindraj for his persistence with this series.
>
> Boot tested on 2420/n810, 4430/Blaze, 4430/Panda
> Additional PM testing on 3430/n900, 3530/Overo, 3630/Zoom3.
>
> NOTE: while normal UART behavior works fine with this series, including
> suspend/resume, in order for wakeups from runtime PM to work, this
> series depends on the PRCM IRQ chaining series from Tero and the
> the new hwmod init state from Rajendra[1]. However, since runtime
> PM is disabled by default for the UARTs, they will behave normally
> even without those dependencies.
>
> Kevin
>
> [1] http://marc.info/?l=linux-omap&m=132187766930901&w=2
Thanks pulling this into uart branch.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH v3 4/4] ARM: omap: pass minimal SoC/board data for UART from dt
From: Cousson, Benoit @ 2011-12-16 15:21 UTC (permalink / raw)
To: Rajendra Nayak
Cc: linux-serial, linux-omap, devicetree-discuss, khilman, tony,
govindraj.raja, linux-arm-kernel, linaro-dev, patches,
robherring2
In-Reply-To: <1323863746-18145-5-git-send-email-rnayak@ti.com>
Hi Rajendra,
Just one minor comment if you plan to repost.
On 12/14/2011 12:55 PM, Rajendra Nayak wrote:
> 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>
Tested-by: Benoit Cousson <b-cousson@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 {
Could you get rid of the 0x prefix for consistency?
This is applicable for the omap4.dtsi as well.
Thanks,
Benoit
^ permalink raw reply
* Re: [PATCH] atmel_serial: fix spinlock lockup in RS485 code
From: Claudio Scordino @ 2011-12-16 14:08 UTC (permalink / raw)
To: Greg KH
Cc: Alan Cox, Nicolas Ferre, Linux Kernel,
linux-serial@vger.kernel.org, Dave Bender, stable
In-Reply-To: <20111215185814.GD18791@kroah.com>
Il 15/12/2011 19:58, Greg KH ha scritto:
> On Thu, Dec 15, 2011 at 12:04:42PM +0100, Claudio Scordino wrote:
>> Il 15/12/2011 11:00, Nicolas Ferre ha scritto:
>>> On 12/15/2011 09:47 AM, Claudio Scordino :
>>>> Hi all.
>>>>
>>>> We have encountered a spinlock lockup in the RS485 part of the
>>>> atmel_serial driver.
>>>>
>>>> Here is the trace:
>>>>
>>>> [ 68.030000] BUG: spinlock lockup on CPU#0, dnp_master/244, c07e82c0
>>>> [ 68.040000] [<c002a790>] (unwind_backtrace+0x0/0xf0) from
>>>> [<c012f8f0>] (do_raw_spin_lock+0x10c/0x148)
>>>> [ 68.050000] [<c012f8f0>] (do_raw_spin_lock+0x10c/0x148) from
>>>> [<c015152c>] (atmel_tasklet_func+0x10/0x708)
>>>> [ 68.060000] [<c015152c>] (atmel_tasklet_func+0x10/0x708) from
>>>> [<c003bfd4>] (tasklet_action+0x8c/0xf4)
>>>> [ 68.070000] [<c003bfd4>] (tasklet_action+0x8c/0xf4) from [<c003c630>]
>>>> (__do_softirq+0xa4/0x180)
>>>> [ 68.080000] [<c003c630>] (__do_softirq+0xa4/0x180) from [<c003c764>]
>>>> (irq_exit+0x58/0xb0)
>>>> [ 68.090000] [<c003c764>] (irq_exit+0x58/0xb0) from [<c0021084>]
>>>> (asm_do_IRQ+0x84/0xa4)
>>>> [ 68.100000] [<c0021084>] (asm_do_IRQ+0x84/0xa4) from [<c002622c>]
>>>> (__irq_svc+0x4c/0x98)
>>>> [ 68.110000] Exception stack(0xc341fdc8 to 0xc341fe10)
>>>> [ 68.110000] fdc0: c07e82c0 00000000 00000200
>>>> c4818000 c341fe10 c07e82c0
>>>> [ 68.120000] fde0: 00000000 c07e82c0 c38d3318 c341e000 bebcee00
>>>> 010a0b60 c07e83fc c341fe10
>>>> [ 68.130000] fe00: c0151d54 c023d9c0 60000013 ffffffff
>>>> [ 68.140000] [<c002622c>] (__irq_svc+0x4c/0x98) from [<c023d9c0>]
>>>> (_raw_spin_unlock+0x0/0x48)
>>>> [ 68.140000] [<c023d9c0>] (_raw_spin_unlock+0x0/0x48) from
>>>> [<00000000>] ( (null))
>>>>
>>>> The soft lockup occurs later
>>>>
>>>> [ 126.750000] BUG: soft lockup - CPU#0 stuck for 61s! [dnp_master:244]
>>>> [ 126.750000] irq event stamp: 0
>>>> [ 126.750000] hardirqs last enabled at (0): [< (null)>] (null)
>>>> [ 126.750000] hardirqs last disabled at (0): [<c0035e30>]
>>>> copy_process+0x308/0xe78
>>>> [ 126.750000] softirqs last enabled at (0): [<c0035e30>]
>>>> copy_process+0x308/0xe78
>>>> [ 126.750000] softirqs last disabled at (0): [< (null)>] (null)
>>>>
>>>>
>>>> The following patch (already tested by Dave, who also reported the bug)
>>>> fixes the problem.
>>>>
>>>> Regards,
>>>>
>>>> Claudio
>>>>
>>>>
>>>>
>>>>
>>>> Subject: atmel_serial: fix spinlock lockup in RS485 code
>>>>
>>>> Patch to fix a spinlock lockup in the driver that sometimes happens when
>>>> the
>>>> tasklet starts.
>>>>
>>>> Signed-off-by: Claudio Scordino<claudio@evidence.eu.com>
>>>> Signed-off-by: Dave Bender<codehero@gmail.com>
>>>> Tested-by: Dave Bender<codehero@gmail.com>
>>>
>>> Acked-by: Nicolas Ferre<nicolas.ferre@atmel.com>
>>>
>>> Claudio, can you please send the patch to Alan with my "Acked-by" and an
>>> addition to Linux stable just after the signature lines:
>>>
>>> Cc: stable<stable@kernel.org>
>
> That address has been invalid since August, please use
> stable@vger.kernel.org now.
Hi Greg,
here is the patch with the right address.
Many thanks for taking care of it.
Best regards,
Claudio
Subject: atmel_serial: fix spinlock lockup in RS485 code
Patch to fix a spinlock lockup in the driver that sometimes happens when the
tasklet starts.
Signed-off-by: Claudio Scordino <claudio@evidence.eu.com>
Signed-off-by: Dave Bender <codehero@gmail.com>
Tested-by: Dave Bender <codehero@gmail.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
---
drivers/tty/serial/atmel_serial.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 4c823f3..90c8e3a 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -212,8 +212,9 @@ void atmel_config_rs485(struct uart_port *port, struct serial_rs485 *rs485conf)
{
struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
unsigned int mode;
+ unsigned long flags;
- spin_lock(&port->lock);
+ spin_lock_irqsave(&port->lock, flags);
/* Disable interrupts */
UART_PUT_IDR(port, atmel_port->tx_done_mask);
@@ -244,7 +245,7 @@ void atmel_config_rs485(struct uart_port *port, struct serial_rs485 *rs485conf)
/* Enable interrupts */
UART_PUT_IER(port, atmel_port->tx_done_mask);
- spin_unlock(&port->lock);
+ spin_unlock_irqrestore(&port->lock, flags);
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] arm/dts: Add minimal device tree support for omap2420 and omap2430
From: Rajendra Nayak @ 2011-12-16 4:01 UTC (permalink / raw)
To: Tony Lindgren
Cc: Cousson, Benoit, linux-serial, linux-omap, devicetree-discuss,
khilman, govindraj.raja, linux-arm-kernel, linaro-dev, patches,
robherring2
In-Reply-To: <20111215213940.GW32251@atomide.com>
On Friday 16 December 2011 03:09 AM, Tony Lindgren wrote:
> Add minimal device tree support for omap2420 and omap2430
Looks good to me.
>
> Signed-off-by: Tony Lindgren<tony@atomide.com>
>
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap2.dtsi
> @@ -0,0 +1,67 @@
> +/*
> + * Device Tree Source for OMAP2 SoC
> + *
> + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +/include/ "skeleton.dtsi"
> +
> +/ {
> + compatible = "ti,omap2430", "ti,omap2420", "ti,omap2";
> +
> + aliases {
> + serial0 =&uart1;
> + serial1 =&uart2;
> + serial2 =&uart3;
> + };
> +
> + cpus {
> + cpu@0 {
> + compatible = "arm,arm1136jf-s";
> + };
> + };
> +
> + soc {
> + compatible = "ti,omap-infra";
> + mpu {
> + compatible = "ti,omap2-mpu";
> + ti,hwmods = "mpu";
> + };
> + };
> +
> + ocp {
> + compatible = "simple-bus";
> + #address-cells =<1>;
> + #size-cells =<1>;
> + ranges;
> + ti,hwmods = "l3_main";
> +
> + intc: interrupt-controller@1 {
> + compatible = "ti,omap2-intc";
> + interrupt-controller;
> + #interrupt-cells =<1>;
> + };
> +
> + uart1: serial@4806a000 {
> + compatible = "ti,omap2-uart";
> + ti,hwmods = "uart1";
> + clock-frequency =<48000000>;
> + };
> +
> + uart2: serial@4806c000 {
> + compatible = "ti,omap2-uart";
> + ti,hwmods = "uart2";
> + clock-frequency =<48000000>;
> + };
> +
> + uart3: serial@4806e000 {
> + compatible = "ti,omap2-uart";
> + ti,hwmods = "uart3";
> + clock-frequency =<48000000>;
> + };
> + };
> +};
^ permalink raw reply
* [PATCH] arm/dts: Add minimal device tree support for omap2420 and omap2430
From: Tony Lindgren @ 2011-12-15 21:39 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Rajendra Nayak, linux-serial, linux-omap, devicetree-discuss,
khilman, govindraj.raja, linux-arm-kernel, linaro-dev, patches,
robherring2
In-Reply-To: <20111215213722.GV32251@atomide.com>
Add minimal device tree support for omap2420 and omap2430
Signed-off-by: Tony Lindgren <tony@atomide.com>
--- /dev/null
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -0,0 +1,67 @@
+/*
+ * Device Tree Source for OMAP2 SoC
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+ compatible = "ti,omap2430", "ti,omap2420", "ti,omap2";
+
+ aliases {
+ serial0 = &uart1;
+ serial1 = &uart2;
+ serial2 = &uart3;
+ };
+
+ cpus {
+ cpu@0 {
+ compatible = "arm,arm1136jf-s";
+ };
+ };
+
+ soc {
+ compatible = "ti,omap-infra";
+ mpu {
+ compatible = "ti,omap2-mpu";
+ ti,hwmods = "mpu";
+ };
+ };
+
+ ocp {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ ti,hwmods = "l3_main";
+
+ intc: interrupt-controller@1 {
+ compatible = "ti,omap2-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+
+ uart1: serial@4806a000 {
+ compatible = "ti,omap2-uart";
+ ti,hwmods = "uart1";
+ clock-frequency = <48000000>;
+ };
+
+ uart2: serial@4806c000 {
+ compatible = "ti,omap2-uart";
+ ti,hwmods = "uart2";
+ clock-frequency = <48000000>;
+ };
+
+ uart3: serial@4806e000 {
+ compatible = "ti,omap2-uart";
+ ti,hwmods = "uart3";
+ clock-frequency = <48000000>;
+ };
+ };
+};
^ permalink raw reply
* Re: [PATCH v3 4/4] ARM: omap: pass minimal SoC/board data for UART from dt
From: Tony Lindgren @ 2011-12-15 21:37 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Rajendra Nayak, linux-serial, linux-omap, devicetree-discuss,
khilman, govindraj.raja, linux-arm-kernel, linaro-dev, patches,
robherring2
In-Reply-To: <4EEA6686.3010504@ti.com>
* Cousson, Benoit <b-cousson@ti.com> [111215 12:56]:
>
> Nit: The convention is without the 0x prefix.
OK will post an updated version as a reply to this
email.
> Beside that, that looks good top me. But I'll not be able to try it :-)
Boots fine with the following n8x0.dts patch. Currently
MMC of course won't mount and the file should be separate
for n800 and and n810.. So this patch is not yet quite
ready to go.
Regards,
Tony
From: Tony Lindgren <tony@atomide.com>
Date: Thu, 15 Dec 2011 13:04:31 -0800
Subject: [PATCH] arm/dts: Add minimal n8x0 device tree support
Add minimal n8x0 device tree support
Not-Signed-off-by: Tony Lindgren <tony@atomide.com>
--- /dev/null
+++ b/arch/arm/boot/dts/nokia-n8x0.dts
@@ -0,0 +1,17 @@
+/dts-v1/;
+
+/include/ "omap2.dtsi"
+
+/ {
+ model = "Nokia N8x0";
+ compatible = "nokia,n8x0", "ti,omap2420", "ti,omap2";
+
+ chosen {
+ bootargs = "root=/dev/mmcblk2p2 rw console=ttyO2,115200n8 debug earlyprintk";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x80000000 0x08000000>; /* 128 MB */
+ };
+};
^ permalink raw reply
* Re: [PATCH v3 4/4] ARM: omap: pass minimal SoC/board data for UART from dt
From: Cousson, Benoit @ 2011-12-15 21:28 UTC (permalink / raw)
To: Tony Lindgren
Cc: Rajendra Nayak, linux-serial, linux-omap, devicetree-discuss,
khilman, govindraj.raja, linux-arm-kernel, linaro-dev, patches,
robherring2
In-Reply-To: <20111215211320.GU32251@atomide.com>
On 12/15/2011 10:13 PM, Tony Lindgren wrote:
> * Cousson, Benoit<b-cousson@ti.com> [111215 01:34]:
>> Hi Tony,
>>
>> On 12/15/2011 7:52 AM, Rajendra Nayak wrote:
>>> On Thursday 15 December 2011 12:55 AM, Tony Lindgren wrote:
>>>> * Rajendra Nayak<rnayak@ti.com> [111214 03:24]:
>>>>> 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>
>>>>
>>>> This we can't merge because this breaks serial console for
>>>> omap2 because you're not adding the omap2 specific dtsi
>>>> entries for omap2..
>>>
>>> But we never had omap2 working with DT, because we never added
>>> a .dtsi file for omap2 or a .dts file for any omap2 board variants.
>>>
>>> Until now the DT support on OMAP has been limited to OMAP3 and OMAP4
>>> with boards limited to omap3beagle/omap4Panda and omap4sdp.
>>>
>>> So when we do add base support for omap2, we could update those
>>> with the serial entries.
>>
>> I'm quite confused as well... Have you tried the current 3.2 kernel
>> on an OMAP2 board?
>>
>> So far I've been taking care of keeping the OMAP2 support into the
>> board-generic.c file, but I've never added any omap2.dtsi or
>> omap2-board.dts file to support it.
>
> Yeah adding it is trivial, so let's just add it :)
Well, why not :-)
> How about we just add the following patch before the last patch
> in this series?
>
> I don't have iva there as that's different between 2420 and 2430.
> But omap2.dtsi can be included later on into omap2420.dtsi and
> omap2430.dtsi.
>
> Regards,
>
> Tony
>
>
> From: Tony Lindgren<tony@atomide.com>
> Date: Thu, 15 Dec 2011 12:48:43 -0800
> Subject: [PATCH] arm/dts: Add minimal device tree support for omap2420 and omap2430
>
> Add minimal device tree support for omap2420 and omap2430
>
> Signed-off-by: Tony Lindgren<tony@atomide.com>
>
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap2.dtsi
> @@ -0,0 +1,67 @@
> +/*
> + * Device Tree Source for OMAP2 SoC
> + *
> + * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +/include/ "skeleton.dtsi"
> +
> +/ {
> + compatible = "ti,omap2430", "ti,omap2420", "ti,omap2";
> +
> + aliases {
> + serial0 =&uart1;
> + serial1 =&uart2;
> + serial2 =&uart3;
> + };
> +
> + cpus {
> + cpu@0 {
> + compatible = "arm,arm1136jf-s";
> + };
> + };
> +
> + soc {
> + compatible = "ti,omap-infra";
> + mpu {
> + compatible = "ti,omap2-mpu";
> + ti,hwmods = "mpu";
> + };
> + };
> +
> + ocp {
> + compatible = "simple-bus";
> + #address-cells =<1>;
> + #size-cells =<1>;
> + ranges;
> + ti,hwmods = "l3_main";
> +
> + intc: interrupt-controller@1 {
> + compatible = "ti,omap2-intc";
> + interrupt-controller;
> + #interrupt-cells =<1>;
> + };
> +
> + uart1: serial@0x4806a000 {
Nit: The convention is without the 0x prefix.
Beside that, that looks good top me. But I'll not be able to try it :-)
Regards,
Benoit
^ permalink raw reply
* Re: [PATCH v3 4/4] ARM: omap: pass minimal SoC/board data for UART from dt
From: Tony Lindgren @ 2011-12-15 21:13 UTC (permalink / raw)
To: Cousson, Benoit
Cc: Rajendra Nayak, linux-serial, linux-omap, devicetree-discuss,
khilman, govindraj.raja, linux-arm-kernel, linaro-dev, patches,
robherring2
In-Reply-To: <4EE9C697.4010604@ti.com>
* Cousson, Benoit <b-cousson@ti.com> [111215 01:34]:
> Hi Tony,
>
> On 12/15/2011 7:52 AM, Rajendra Nayak wrote:
> >On Thursday 15 December 2011 12:55 AM, Tony Lindgren wrote:
> >>* Rajendra Nayak<rnayak@ti.com> [111214 03:24]:
> >>>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>
> >>
> >>This we can't merge because this breaks serial console for
> >>omap2 because you're not adding the omap2 specific dtsi
> >>entries for omap2..
> >
> >But we never had omap2 working with DT, because we never added
> >a .dtsi file for omap2 or a .dts file for any omap2 board variants.
> >
> >Until now the DT support on OMAP has been limited to OMAP3 and OMAP4
> >with boards limited to omap3beagle/omap4Panda and omap4sdp.
> >
> >So when we do add base support for omap2, we could update those
> >with the serial entries.
>
> I'm quite confused as well... Have you tried the current 3.2 kernel
> on an OMAP2 board?
>
> So far I've been taking care of keeping the OMAP2 support into the
> board-generic.c file, but I've never added any omap2.dtsi or
> omap2-board.dts file to support it.
Yeah adding it is trivial, so let's just add it :)
How about we just add the following patch before the last patch
in this series?
I don't have iva there as that's different between 2420 and 2430.
But omap2.dtsi can be included later on into omap2420.dtsi and
omap2430.dtsi.
Regards,
Tony
From: Tony Lindgren <tony@atomide.com>
Date: Thu, 15 Dec 2011 12:48:43 -0800
Subject: [PATCH] arm/dts: Add minimal device tree support for omap2420 and omap2430
Add minimal device tree support for omap2420 and omap2430
Signed-off-by: Tony Lindgren <tony@atomide.com>
--- /dev/null
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -0,0 +1,67 @@
+/*
+ * Device Tree Source for OMAP2 SoC
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+ compatible = "ti,omap2430", "ti,omap2420", "ti,omap2";
+
+ aliases {
+ serial0 = &uart1;
+ serial1 = &uart2;
+ serial2 = &uart3;
+ };
+
+ cpus {
+ cpu@0 {
+ compatible = "arm,arm1136jf-s";
+ };
+ };
+
+ soc {
+ compatible = "ti,omap-infra";
+ mpu {
+ compatible = "ti,omap2-mpu";
+ ti,hwmods = "mpu";
+ };
+ };
+
+ ocp {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ ti,hwmods = "l3_main";
+
+ intc: interrupt-controller@1 {
+ compatible = "ti,omap2-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+
+ uart1: serial@0x4806a000 {
+ compatible = "ti,omap2-uart";
+ ti,hwmods = "uart1";
+ clock-frequency = <48000000>;
+ };
+
+ uart2: serial@0x4806c000 {
+ compatible = "ti,omap2-uart";
+ ti,hwmods = "uart2";
+ clock-frequency = <48000000>;
+ };
+
+ uart3: serial@0x4806e000 {
+ compatible = "ti,omap2-uart";
+ ti,hwmods = "uart3";
+ clock-frequency = <48000000>;
+ };
+ };
+};
^ permalink raw reply
* Re: [PATCH] atmel_serial: fix spinlock lockup in RS485 code
From: Greg KH @ 2011-12-15 18:58 UTC (permalink / raw)
To: Claudio Scordino
Cc: Alan Cox, Nicolas Ferre, Linux Kernel,
linux-serial@vger.kernel.org, Dave Bender
In-Reply-To: <4EE9D44A.6010300@evidence.eu.com>
On Thu, Dec 15, 2011 at 12:04:42PM +0100, Claudio Scordino wrote:
> Il 15/12/2011 11:00, Nicolas Ferre ha scritto:
> >On 12/15/2011 09:47 AM, Claudio Scordino :
> >>Hi all.
> >>
> >>We have encountered a spinlock lockup in the RS485 part of the
> >>atmel_serial driver.
> >>
> >>Here is the trace:
> >>
> >>[ 68.030000] BUG: spinlock lockup on CPU#0, dnp_master/244, c07e82c0
> >>[ 68.040000] [<c002a790>] (unwind_backtrace+0x0/0xf0) from
> >>[<c012f8f0>] (do_raw_spin_lock+0x10c/0x148)
> >>[ 68.050000] [<c012f8f0>] (do_raw_spin_lock+0x10c/0x148) from
> >>[<c015152c>] (atmel_tasklet_func+0x10/0x708)
> >>[ 68.060000] [<c015152c>] (atmel_tasklet_func+0x10/0x708) from
> >>[<c003bfd4>] (tasklet_action+0x8c/0xf4)
> >>[ 68.070000] [<c003bfd4>] (tasklet_action+0x8c/0xf4) from [<c003c630>]
> >>(__do_softirq+0xa4/0x180)
> >>[ 68.080000] [<c003c630>] (__do_softirq+0xa4/0x180) from [<c003c764>]
> >>(irq_exit+0x58/0xb0)
> >>[ 68.090000] [<c003c764>] (irq_exit+0x58/0xb0) from [<c0021084>]
> >>(asm_do_IRQ+0x84/0xa4)
> >>[ 68.100000] [<c0021084>] (asm_do_IRQ+0x84/0xa4) from [<c002622c>]
> >>(__irq_svc+0x4c/0x98)
> >>[ 68.110000] Exception stack(0xc341fdc8 to 0xc341fe10)
> >>[ 68.110000] fdc0: c07e82c0 00000000 00000200
> >>c4818000 c341fe10 c07e82c0
> >>[ 68.120000] fde0: 00000000 c07e82c0 c38d3318 c341e000 bebcee00
> >>010a0b60 c07e83fc c341fe10
> >>[ 68.130000] fe00: c0151d54 c023d9c0 60000013 ffffffff
> >>[ 68.140000] [<c002622c>] (__irq_svc+0x4c/0x98) from [<c023d9c0>]
> >>(_raw_spin_unlock+0x0/0x48)
> >>[ 68.140000] [<c023d9c0>] (_raw_spin_unlock+0x0/0x48) from
> >>[<00000000>] ( (null))
> >>
> >>The soft lockup occurs later
> >>
> >>[ 126.750000] BUG: soft lockup - CPU#0 stuck for 61s! [dnp_master:244]
> >>[ 126.750000] irq event stamp: 0
> >>[ 126.750000] hardirqs last enabled at (0): [< (null)>] (null)
> >>[ 126.750000] hardirqs last disabled at (0): [<c0035e30>]
> >>copy_process+0x308/0xe78
> >>[ 126.750000] softirqs last enabled at (0): [<c0035e30>]
> >>copy_process+0x308/0xe78
> >>[ 126.750000] softirqs last disabled at (0): [< (null)>] (null)
> >>
> >>
> >>The following patch (already tested by Dave, who also reported the bug)
> >>fixes the problem.
> >>
> >>Regards,
> >>
> >> Claudio
> >>
> >>
> >>
> >>
> >>Subject: atmel_serial: fix spinlock lockup in RS485 code
> >>
> >>Patch to fix a spinlock lockup in the driver that sometimes happens when
> >>the
> >>tasklet starts.
> >>
> >>Signed-off-by: Claudio Scordino<claudio@evidence.eu.com>
> >>Signed-off-by: Dave Bender<codehero@gmail.com>
> >>Tested-by: Dave Bender<codehero@gmail.com>
> >
> >Acked-by: Nicolas Ferre<nicolas.ferre@atmel.com>
> >
> >Claudio, can you please send the patch to Alan with my "Acked-by" and an
> >addition to Linux stable just after the signature lines:
> >
> >Cc: stable<stable@kernel.org>
That address has been invalid since August, please use
stable@vger.kernel.org now.
> Dear Alan,
>
> here is the patch with all the acked-bys.
I'll take care of this.
thanks,
greg k-h
^ permalink raw reply
* Hello my dear
From: Miss victoria @ 2011-12-15 16:20 UTC (permalink / raw)
Hello my dear,
How are you doing? I came across you contact why search on Google, how was there, hope fine? Mine is cold over here in Senegal, it will be of my pleasure to know you, I have being seeking a way to express my inner mind, I am Ms Victoria from Zimbabwe, i am seeking for friendship or future partner, i love to know who you are and your country, Cheers Victoria
^ permalink raw reply
* Re: [PATCH] atmel_serial: fix spinlock lockup in RS485 code
From: Claudio Scordino @ 2011-12-15 11:04 UTC (permalink / raw)
To: Alan Cox
Cc: Nicolas Ferre, Linux Kernel, linux-serial@vger.kernel.org,
Dave Bender
In-Reply-To: <4EE9C532.5050607@atmel.com>
Il 15/12/2011 11:00, Nicolas Ferre ha scritto:
> On 12/15/2011 09:47 AM, Claudio Scordino :
>> Hi all.
>>
>> We have encountered a spinlock lockup in the RS485 part of the
>> atmel_serial driver.
>>
>> Here is the trace:
>>
>> [ 68.030000] BUG: spinlock lockup on CPU#0, dnp_master/244, c07e82c0
>> [ 68.040000] [<c002a790>] (unwind_backtrace+0x0/0xf0) from
>> [<c012f8f0>] (do_raw_spin_lock+0x10c/0x148)
>> [ 68.050000] [<c012f8f0>] (do_raw_spin_lock+0x10c/0x148) from
>> [<c015152c>] (atmel_tasklet_func+0x10/0x708)
>> [ 68.060000] [<c015152c>] (atmel_tasklet_func+0x10/0x708) from
>> [<c003bfd4>] (tasklet_action+0x8c/0xf4)
>> [ 68.070000] [<c003bfd4>] (tasklet_action+0x8c/0xf4) from [<c003c630>]
>> (__do_softirq+0xa4/0x180)
>> [ 68.080000] [<c003c630>] (__do_softirq+0xa4/0x180) from [<c003c764>]
>> (irq_exit+0x58/0xb0)
>> [ 68.090000] [<c003c764>] (irq_exit+0x58/0xb0) from [<c0021084>]
>> (asm_do_IRQ+0x84/0xa4)
>> [ 68.100000] [<c0021084>] (asm_do_IRQ+0x84/0xa4) from [<c002622c>]
>> (__irq_svc+0x4c/0x98)
>> [ 68.110000] Exception stack(0xc341fdc8 to 0xc341fe10)
>> [ 68.110000] fdc0: c07e82c0 00000000 00000200
>> c4818000 c341fe10 c07e82c0
>> [ 68.120000] fde0: 00000000 c07e82c0 c38d3318 c341e000 bebcee00
>> 010a0b60 c07e83fc c341fe10
>> [ 68.130000] fe00: c0151d54 c023d9c0 60000013 ffffffff
>> [ 68.140000] [<c002622c>] (__irq_svc+0x4c/0x98) from [<c023d9c0>]
>> (_raw_spin_unlock+0x0/0x48)
>> [ 68.140000] [<c023d9c0>] (_raw_spin_unlock+0x0/0x48) from
>> [<00000000>] ( (null))
>>
>> The soft lockup occurs later
>>
>> [ 126.750000] BUG: soft lockup - CPU#0 stuck for 61s! [dnp_master:244]
>> [ 126.750000] irq event stamp: 0
>> [ 126.750000] hardirqs last enabled at (0): [< (null)>] (null)
>> [ 126.750000] hardirqs last disabled at (0): [<c0035e30>]
>> copy_process+0x308/0xe78
>> [ 126.750000] softirqs last enabled at (0): [<c0035e30>]
>> copy_process+0x308/0xe78
>> [ 126.750000] softirqs last disabled at (0): [< (null)>] (null)
>>
>>
>> The following patch (already tested by Dave, who also reported the bug)
>> fixes the problem.
>>
>> Regards,
>>
>> Claudio
>>
>>
>>
>>
>> Subject: atmel_serial: fix spinlock lockup in RS485 code
>>
>> Patch to fix a spinlock lockup in the driver that sometimes happens when
>> the
>> tasklet starts.
>>
>> Signed-off-by: Claudio Scordino<claudio@evidence.eu.com>
>> Signed-off-by: Dave Bender<codehero@gmail.com>
>> Tested-by: Dave Bender<codehero@gmail.com>
>
> Acked-by: Nicolas Ferre<nicolas.ferre@atmel.com>
>
> Claudio, can you please send the patch to Alan with my "Acked-by" and an
> addition to Linux stable just after the signature lines:
>
> Cc: stable<stable@kernel.org>
Dear Alan,
here is the patch with all the acked-bys.
Many thanks,
Claudio
Subject: atmel_serial: fix spinlock lockup in RS485 code
Patch to fix a spinlock lockup in the driver that sometimes happens when the
tasklet starts.
Signed-off-by: Claudio Scordino <claudio@evidence.eu.com>
Signed-off-by: Dave Bender <codehero@gmail.com>
Tested-by: Dave Bender <codehero@gmail.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Cc: stable <stable@kernel.org>
---
drivers/tty/serial/atmel_serial.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 4c823f3..90c8e3a 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -212,8 +212,9 @@ void atmel_config_rs485(struct uart_port *port, struct serial_rs485 *rs485conf)
{
struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
unsigned int mode;
+ unsigned long flags;
- spin_lock(&port->lock);
+ spin_lock_irqsave(&port->lock, flags);
/* Disable interrupts */
UART_PUT_IDR(port, atmel_port->tx_done_mask);
@@ -244,7 +245,7 @@ void atmel_config_rs485(struct uart_port *port, struct serial_rs485 *rs485conf)
/* Enable interrupts */
UART_PUT_IER(port, atmel_port->tx_done_mask);
- spin_unlock(&port->lock);
+ spin_unlock_irqrestore(&port->lock, flags);
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] atmel_serial: fix spinlock lockup in RS485 code
From: Alan Cox @ 2011-12-15 10:22 UTC (permalink / raw)
To: Claudio Scordino
Cc: Nicolas Ferre, Linux Kernel, linux-serial@vger.kernel.org,
Dave Bender
In-Reply-To: <4EE9B42F.50004@evidence.eu.com>
On Thu, 15 Dec 2011 09:47:43 +0100
Claudio Scordino <claudio@evidence.eu.com> wrote:
> Subject: atmel_serial: fix spinlock lockup in RS485 code
>
> Patch to fix a spinlock lockup in the driver that sometimes happens
> when the tasklet starts.
>
> Signed-off-by: Claudio Scordino <claudio@evidence.eu.com>
> Signed-off-by: Dave Bender <codehero@gmail.com>
> Tested-by: Dave Bender <codehero@gmail.com>
Acked-by: Alan Cox <alan@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v3 4/4] ARM: omap: pass minimal SoC/board data for UART from dt
From: Cousson, Benoit @ 2011-12-15 10:06 UTC (permalink / raw)
To: Rajendra Nayak, Tony Lindgren
Cc: linux-serial, linux-omap, devicetree-discuss, khilman,
govindraj.raja, linux-arm-kernel, linaro-dev, patches,
robherring2
In-Reply-To: <4EE99923.4030902@ti.com>
Hi Tony,
On 12/15/2011 7:52 AM, Rajendra Nayak wrote:
> On Thursday 15 December 2011 12:55 AM, Tony Lindgren wrote:
>> * Rajendra Nayak<rnayak@ti.com> [111214 03:24]:
>>> 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>
>>
>> This we can't merge because this breaks serial console for
>> omap2 because you're not adding the omap2 specific dtsi
>> entries for omap2..
>
> But we never had omap2 working with DT, because we never added
> a .dtsi file for omap2 or a .dts file for any omap2 board variants.
>
> Until now the DT support on OMAP has been limited to OMAP3 and OMAP4
> with boards limited to omap3beagle/omap4Panda and omap4sdp.
>
> So when we do add base support for omap2, we could update those
> with the serial entries.
I'm quite confused as well... Have you tried the current 3.2 kernel on
an OMAP2 board?
So far I've been taking care of keeping the OMAP2 support into the
board-generic.c file, but I've never added any omap2.dtsi or
omap2-board.dts file to support it.
Regards,
Benoit
^ permalink raw reply
* Re: [PATCH] atmel_serial: fix spinlock lockup in RS485 code
From: Nicolas Ferre @ 2011-12-15 10:00 UTC (permalink / raw)
To: Claudio Scordino
Cc: Alan Cox, Linux Kernel, linux-serial@vger.kernel.org, Dave Bender
In-Reply-To: <4EE9B42F.50004@evidence.eu.com>
On 12/15/2011 09:47 AM, Claudio Scordino :
> Hi all.
>
> We have encountered a spinlock lockup in the RS485 part of the
> atmel_serial driver.
>
> Here is the trace:
>
> [ 68.030000] BUG: spinlock lockup on CPU#0, dnp_master/244, c07e82c0
> [ 68.040000] [<c002a790>] (unwind_backtrace+0x0/0xf0) from
> [<c012f8f0>] (do_raw_spin_lock+0x10c/0x148)
> [ 68.050000] [<c012f8f0>] (do_raw_spin_lock+0x10c/0x148) from
> [<c015152c>] (atmel_tasklet_func+0x10/0x708)
> [ 68.060000] [<c015152c>] (atmel_tasklet_func+0x10/0x708) from
> [<c003bfd4>] (tasklet_action+0x8c/0xf4)
> [ 68.070000] [<c003bfd4>] (tasklet_action+0x8c/0xf4) from [<c003c630>]
> (__do_softirq+0xa4/0x180)
> [ 68.080000] [<c003c630>] (__do_softirq+0xa4/0x180) from [<c003c764>]
> (irq_exit+0x58/0xb0)
> [ 68.090000] [<c003c764>] (irq_exit+0x58/0xb0) from [<c0021084>]
> (asm_do_IRQ+0x84/0xa4)
> [ 68.100000] [<c0021084>] (asm_do_IRQ+0x84/0xa4) from [<c002622c>]
> (__irq_svc+0x4c/0x98)
> [ 68.110000] Exception stack(0xc341fdc8 to 0xc341fe10)
> [ 68.110000] fdc0: c07e82c0 00000000 00000200
> c4818000 c341fe10 c07e82c0
> [ 68.120000] fde0: 00000000 c07e82c0 c38d3318 c341e000 bebcee00
> 010a0b60 c07e83fc c341fe10
> [ 68.130000] fe00: c0151d54 c023d9c0 60000013 ffffffff
> [ 68.140000] [<c002622c>] (__irq_svc+0x4c/0x98) from [<c023d9c0>]
> (_raw_spin_unlock+0x0/0x48)
> [ 68.140000] [<c023d9c0>] (_raw_spin_unlock+0x0/0x48) from
> [<00000000>] ( (null))
>
> The soft lockup occurs later
>
> [ 126.750000] BUG: soft lockup - CPU#0 stuck for 61s! [dnp_master:244]
> [ 126.750000] irq event stamp: 0
> [ 126.750000] hardirqs last enabled at (0): [< (null)>] (null)
> [ 126.750000] hardirqs last disabled at (0): [<c0035e30>]
> copy_process+0x308/0xe78
> [ 126.750000] softirqs last enabled at (0): [<c0035e30>]
> copy_process+0x308/0xe78
> [ 126.750000] softirqs last disabled at (0): [< (null)>] (null)
>
>
> The following patch (already tested by Dave, who also reported the bug)
> fixes the problem.
>
> Regards,
>
> Claudio
>
>
>
>
> Subject: atmel_serial: fix spinlock lockup in RS485 code
>
> Patch to fix a spinlock lockup in the driver that sometimes happens when
> the
> tasklet starts.
>
> Signed-off-by: Claudio Scordino <claudio@evidence.eu.com>
> Signed-off-by: Dave Bender <codehero@gmail.com>
> Tested-by: Dave Bender <codehero@gmail.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Claudio, can you please send the patch to Alan with my "Acked-by" and an
addition to Linux stable just after the signature lines:
Cc: stable <stable@kernel.org>
Thanks, best regards,
> ---
> drivers/tty/serial/atmel_serial.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/atmel_serial.c
> b/drivers/tty/serial/atmel_serial.c
> index 4c823f3..90c8e3a 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -212,8 +212,9 @@ void atmel_config_rs485(struct uart_port *port,
> struct serial_rs485 *rs485conf)
> {
> struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
> unsigned int mode;
> + unsigned long flags;
>
> - spin_lock(&port->lock);
> + spin_lock_irqsave(&port->lock, flags);
>
> /* Disable interrupts */
> UART_PUT_IDR(port, atmel_port->tx_done_mask);
> @@ -244,7 +245,7 @@ void atmel_config_rs485(struct uart_port *port,
> struct serial_rs485 *rs485conf)
> /* Enable interrupts */
> UART_PUT_IER(port, atmel_port->tx_done_mask);
>
> - spin_unlock(&port->lock);
> + spin_unlock_irqrestore(&port->lock, flags);
>
> }
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH] atmel_serial: fix spinlock lockup in RS485 code
From: Claudio Scordino @ 2011-12-15 8:47 UTC (permalink / raw)
To: Nicolas Ferre, Alan Cox
Cc: Linux Kernel, linux-serial@vger.kernel.org, Dave Bender
Hi all.
We have encountered a spinlock lockup in the RS485 part of the atmel_serial driver.
Here is the trace:
[ 68.030000] BUG: spinlock lockup on CPU#0, dnp_master/244, c07e82c0
[ 68.040000] [<c002a790>] (unwind_backtrace+0x0/0xf0) from [<c012f8f0>] (do_raw_spin_lock+0x10c/0x148)
[ 68.050000] [<c012f8f0>] (do_raw_spin_lock+0x10c/0x148) from [<c015152c>] (atmel_tasklet_func+0x10/0x708)
[ 68.060000] [<c015152c>] (atmel_tasklet_func+0x10/0x708) from [<c003bfd4>] (tasklet_action+0x8c/0xf4)
[ 68.070000] [<c003bfd4>] (tasklet_action+0x8c/0xf4) from [<c003c630>] (__do_softirq+0xa4/0x180)
[ 68.080000] [<c003c630>] (__do_softirq+0xa4/0x180) from [<c003c764>] (irq_exit+0x58/0xb0)
[ 68.090000] [<c003c764>] (irq_exit+0x58/0xb0) from [<c0021084>] (asm_do_IRQ+0x84/0xa4)
[ 68.100000] [<c0021084>] (asm_do_IRQ+0x84/0xa4) from [<c002622c>] (__irq_svc+0x4c/0x98)
[ 68.110000] Exception stack(0xc341fdc8 to 0xc341fe10)
[ 68.110000] fdc0: c07e82c0 00000000 00000200 c4818000 c341fe10 c07e82c0
[ 68.120000] fde0: 00000000 c07e82c0 c38d3318 c341e000 bebcee00 010a0b60 c07e83fc c341fe10
[ 68.130000] fe00: c0151d54 c023d9c0 60000013 ffffffff
[ 68.140000] [<c002622c>] (__irq_svc+0x4c/0x98) from [<c023d9c0>] (_raw_spin_unlock+0x0/0x48)
[ 68.140000] [<c023d9c0>] (_raw_spin_unlock+0x0/0x48) from [<00000000>] ( (null))
The soft lockup occurs later
[ 126.750000] BUG: soft lockup - CPU#0 stuck for 61s! [dnp_master:244]
[ 126.750000] irq event stamp: 0
[ 126.750000] hardirqs last enabled at (0): [< (null)>] (null)
[ 126.750000] hardirqs last disabled at (0): [<c0035e30>] copy_process+0x308/0xe78
[ 126.750000] softirqs last enabled at (0): [<c0035e30>] copy_process+0x308/0xe78
[ 126.750000] softirqs last disabled at (0): [< (null)>] (null)
The following patch (already tested by Dave, who also reported the bug) fixes the problem.
Regards,
Claudio
Subject: atmel_serial: fix spinlock lockup in RS485 code
Patch to fix a spinlock lockup in the driver that sometimes happens when the
tasklet starts.
Signed-off-by: Claudio Scordino <claudio@evidence.eu.com>
Signed-off-by: Dave Bender <codehero@gmail.com>
Tested-by: Dave Bender <codehero@gmail.com>
---
drivers/tty/serial/atmel_serial.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 4c823f3..90c8e3a 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -212,8 +212,9 @@ void atmel_config_rs485(struct uart_port *port, struct serial_rs485 *rs485conf)
{
struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
unsigned int mode;
+ unsigned long flags;
- spin_lock(&port->lock);
+ spin_lock_irqsave(&port->lock, flags);
/* Disable interrupts */
UART_PUT_IDR(port, atmel_port->tx_done_mask);
@@ -244,7 +245,7 @@ void atmel_config_rs485(struct uart_port *port, struct serial_rs485 *rs485conf)
/* Enable interrupts */
UART_PUT_IER(port, atmel_port->tx_done_mask);
- spin_unlock(&port->lock);
+ spin_unlock_irqrestore(&port->lock, flags);
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v3 4/4] ARM: omap: pass minimal SoC/board data for UART from dt
From: Rajendra Nayak @ 2011-12-15 6:52 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-serial, linux-omap, devicetree-discuss, khilman,
govindraj.raja, b-cousson, linux-arm-kernel, linaro-dev, patches,
robherring2
In-Reply-To: <20111214192509.GH32251@atomide.com>
On Thursday 15 December 2011 12:55 AM, Tony Lindgren wrote:
> * Rajendra Nayak<rnayak@ti.com> [111214 03:24]:
>> 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>
>
> This we can't merge because this breaks serial console for
> omap2 because you're not adding the omap2 specific dtsi
> entries for omap2..
But we never had omap2 working with DT, because we never added
a .dtsi file for omap2 or a .dts file for any omap2 board variants.
Until now the DT support on OMAP has been limited to OMAP3 and OMAP4
with boards limited to omap3beagle/omap4Panda and omap4sdp.
So when we do add base support for omap2, we could update those
with the serial entries.
>
>> --- 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);
>
> ..and you're removing the call for omap_serial_init.
>
> Please just update this patch with the omap2 entries
> as well. Other than that looks good to me.
>
> Tony
^ permalink raw reply
* [GIT PULL] OMAP: UART cleanup and runtime PM conversion for v3.3
From: Kevin Hilman @ 2011-12-15 0:53 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-arm-kernel, linux-serial, Govindraj Raja
Tony,
Please pull the OMAP UART cleanup and conversion to runtime PM. I had
to rebase it onto your soc branch due to the serial.c changes there.
This includes changes to drivers/tty/serial/omap-serial.c and those
changes have Acks from Greg KH and Alan Cox and I got the OK from them
to merge this all together via the OMAP tree.
Thanks to Govindraj for his persistence with this series.
Boot tested on 2420/n810, 4430/Blaze, 4430/Panda
Additional PM testing on 3430/n900, 3530/Overo, 3630/Zoom3.
NOTE: while normal UART behavior works fine with this series, including
suspend/resume, in order for wakeups from runtime PM to work, this
series depends on the PRCM IRQ chaining series from Tero and the
the new hwmod init state from Rajendra[1]. However, since runtime
PM is disabled by default for the UARTs, they will behave normally
even without those dependencies.
Kevin
[1] http://marc.info/?l=linux-omap&m=132187766930901&w=2
The following changes since commit 4390f5b2cb1f568c1d4b3e5bbf57158f6809627a:
ARM: OMAP: TI814X: Add cpu type macros and detection support (2011-12-13 10:46:45 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.3/uart/runtime-pm
Deepak K (1):
ARM: OMAP2+: UART: Allow UART parameters to be configured from board file.
Govindraj.R (19):
ARM: OMAP2+: UART: cleanup + remove uart pm specific API
ARM: OMAP2+: UART: cleanup 8250 console driver support
ARM: OMAP2+: UART: Cleanup part of clock gating mechanism for uart
ARM: OMAP2+: UART: Add default mux for all uarts.
ARM: OMAP2+: UART: Remove mapbase/membase fields from pdata.
ARM: OMAP2+: UART: Add runtime pm support for omap-serial driver
ARM: OMAP2+: UART: Remove context_save and move context restore to driver
ARM: OMAP2+: UART: Ensure all reg values configured are available from port structure
ARM: OMAP2+: UART: Remove uart reset function.
ARM: OMAP2+: UART: Get context loss count to context restore
ARM: OMAP2+: UART: Move errata handling from serial.c to omap-serial
ARM: OMAP2+: UART: Add wakeup mechanism for omap-uarts
ARM: OMAP2+: UART: Remove old and unused clocks handling funcs
ARM: OMAP2+: UART: remove temporary variable used to count uart instance
ARM: OMAP2+: UART: Avoid console uart idling during bootup
ARM: OMAP2+: UART: Avoid uart idling on suspend for no_console_suspend usecase
ARM: OMAP2+: UART: Do not gate uart clocks if used for debug_prints
ARM: OMAP2+: UART: Remove omap_uart_can_sleep and add pm_qos
ARM: OMAP2+: UART: Fix compilation/sparse warnings
Jon Hunter (1):
ARM: 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 | 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 | 350 +++++++++--
11 files changed, 588 insertions(+), 1027 deletions(-)
^ permalink raw reply
* Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore
From: Tony Lindgren @ 2011-12-14 22:10 UTC (permalink / raw)
To: Janusz Krzysztofik
Cc: Mark Brown, Liam Girdwood, Grant Likely, linux-omap,
linux-arm-kernel, linux-kernel, Greg Kroah-Hartman, linux-serial
In-Reply-To: <201112142107.20055.jkrzyszt@tis.icnet.pl>
* Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [111214 11:36]:
> (adding Mark Brown and Liam Girdwood - regulator experts - to Cc:)
>
> On Wednesday 14 of December 2011 at 19:21:49, Tony Lindgren wrote:
> > * 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 :)
>
> Hmm, better doesn't necessarily mean good enough...
>
> I forgot about the sound device, which shares its latch based GPIO pins
> with the modem, so should be registered after the modem.
>
> To make things still more complicated, one of those GPIO pins provides
> power to both devices, so a still better solution I'd like to introduce
> would be a GPIO controlled regulator device which feeds both the modem
> and the sound card with power.
>
> I've had a look at both generic regulator drivers, fixed.c and gpio-
> regulator.c, both controlling devices over GPIO pins, and found those
> drivers registered at subsys_initcall level, calling gpio_request*() at
> probe time. Then again, we would need that base_mmio_gpio driver already
> registered before subsys_initcall.
>
> Any suggestions?
Sounds like yet another case for the deferred probe patches posted
few weeks ago?
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore
From: Janusz Krzysztofik @ 2011-12-14 20:07 UTC (permalink / raw)
To: Tony Lindgren
Cc: Mark Brown, Liam Girdwood, Grant Likely, linux-omap,
linux-arm-kernel, linux-kernel, Greg Kroah-Hartman, linux-serial
In-Reply-To: <20111214182149.GF32251@atomide.com>
(adding Mark Brown and Liam Girdwood - regulator experts - to Cc:)
On Wednesday 14 of December 2011 at 19:21:49, Tony Lindgren wrote:
> * 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 :)
Hmm, better doesn't necessarily mean good enough...
I forgot about the sound device, which shares its latch based GPIO pins
with the modem, so should be registered after the modem.
To make things still more complicated, one of those GPIO pins provides
power to both devices, so a still better solution I'd like to introduce
would be a GPIO controlled regulator device which feeds both the modem
and the sound card with power.
I've had a look at both generic regulator drivers, fixed.c and gpio-
regulator.c, both controlling devices over GPIO pins, and found those
drivers registered at subsys_initcall level, calling gpio_request*() at
probe time. Then again, we would need that base_mmio_gpio driver already
registered before subsys_initcall.
Any suggestions?
Thanks,
Janusz
^ permalink raw reply
* Re: [PATCH v3 4/4] ARM: omap: pass minimal SoC/board data for UART from dt
From: Tony Lindgren @ 2011-12-14 19:25 UTC (permalink / raw)
To: Rajendra Nayak
Cc: linux-serial, linux-omap, devicetree-discuss, khilman,
govindraj.raja, b-cousson, linux-arm-kernel, linaro-dev, patches,
robherring2
In-Reply-To: <1323863746-18145-5-git-send-email-rnayak@ti.com>
* Rajendra Nayak <rnayak@ti.com> [111214 03:24]:
> 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>
This we can't merge because this breaks serial console for
omap2 because you're not adding the omap2 specific dtsi
entries for omap2..
> --- 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);
..and you're removing the call for omap_serial_init.
Please just update this patch with the omap2 entries
as well. Other than that looks good to me.
Tony
^ permalink raw reply
* Re: [PATCH v3 0/4] OMAP serial device tree support
From: Greg KH @ 2011-12-14 18:27 UTC (permalink / raw)
To: Alan Cox
Cc: Kevin Hilman, Rajendra Nayak, linux-serial, linux-omap,
devicetree-discuss, tony, govindraj.raja, b-cousson,
linux-arm-kernel, linaro-dev, patches, robherring2
In-Reply-To: <20111214171843.5f638874@bob.linux.org.uk>
On Wed, Dec 14, 2011 at 05:18:43PM +0000, Alan Cox wrote:
> 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
Fine with me as well.
greg k-h
^ permalink raw reply
* Re: [PATCH v8 00/20] OMAP2+: UART: Runtime adaptation + cleanup
From: Kevin Hilman @ 2011-12-14 18:56 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: <CAAL8m4x6ToG5uuKebqSvJaYg6YQjwFK017AiOFVm0-6BtmiCCA@mail.gmail.com>
Govindraj <govindraj.ti@gmail.com> writes:
> 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!
Kevin
--
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 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
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