* Re: [PATCH 0/7] powerpc: remove the legacy iSeries platform specific drivers
From: Greg Kroah-Hartman @ 2012-03-08 17:59 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Benjamin Herrenschmidt, ppc-dev, James E.J. Bottomley, netdev,
Alan Cox, Brian King, David Miller, linux-scsi, linux-serial,
Jens Axboe, LKML
In-Reply-To: <20120308152853.b5010336abbb8f90e8a2500c@canb.auug.org.au>
On Thu, Mar 08, 2012 at 03:28:53PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> This series of patches removes all the legacy iSeries platform specific
> drivers (and the iSeries specific part of one). The legacy iSeries
> platform main code has already bee removed along with CONFIG_PPC_ISERIES,
> so none of this code is selectable or needed any more.
>
> It would probably be easiest if all these patches were merged via the
> powerpc tree to eliminate any dependencies between them. Their impact on
> generic code is very small.
No objection from me at all.
greg k-h
^ permalink raw reply
* Re: bad serial port count when trying to login
From: Alan Cox @ 2012-03-08 11:24 UTC (permalink / raw)
To: Subodh Nijsure; +Cc: linux-serial
In-Reply-To: <CAMFeL9+jmN9GWfrhkbd+VP-CWH2VjHpUcWr4Sw4TOv+3YRKC7g@mail.gmail.com>
> I am running 3.1.0-rc5 kernel.
>
> Can someone give me clues as to why this might be and clues on fixing it.
So you have a bug in an older kernel snapshot that isn't a release. I'd
suggest trying to duplicate it in an actual final 3.2 kernel as a
starting point.
Alan
^ permalink raw reply
* Re: [PATCH 5/7] tty: powerpc: remove SERIAL_ICOM dependency on PPC_ISERIES
From: Alan Cox @ 2012-03-08 11:18 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Benjamin Herrenschmidt, Greg Kroah-Hartman, linux-serial, ppc-dev,
LKML
In-Reply-To: <20120308153931.b1b8b4f27d8e4a94b219bf4c@canb.auug.org.au>
On Thu, 8 Mar 2012 15:39:31 +1100
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> The PowerPC legacy iSeries platform is being removed so this is no
> longer selectable.
Fine by me
^ permalink raw reply
* Re: [PATCH 0/7] powerpc: remove the legacy iSeries platform specific drivers
From: Jens Axboe @ 2012-03-08 10:37 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Benjamin Herrenschmidt, ppc-dev, James E.J. Bottomley, netdev,
Alan Cox, Brian King, David Miller, Greg Kroah-Hartman,
linux-scsi, linux-serial, LKML
In-Reply-To: <20120308152853.b5010336abbb8f90e8a2500c@canb.auug.org.au>
On 03/08/2012 05:28 AM, Stephen Rothwell wrote:
> It would probably be easiest if all these patches were merged via the
> powerpc tree to eliminate any dependencies between them. Their impact on
> generic code is very small.
Go ahead, no point in doing otherwise.
--
Jens Axboe
^ permalink raw reply
* RE: [PATCH] Clear previous interrupts after fifo is disabled
From: Kim, Jong-Sung @ 2012-03-08 9:02 UTC (permalink / raw)
To: 'Chanho Min', 'Russell King', 'Alan Cox',
'Greg Kroah-Hartman', 'Linus Walleij',
'Shreshtha Kumar Sahu'
Cc: linux-kernel, linux-serial
In-Reply-To: <CAOAMb1ASB0zznSSOAU9HgPNW2e=Do+8hSJ6JZ00DxtAxqsXyXQ@mail.gmail.com>
> -----Original Message-----
> From: Chanho Min [mailto:chanho0207@gmail.com]
> Sent: Monday, February 27, 2012 6:30 PM
> To: Russell King; Alan Cox; Greg Kroah-Hartman; Linus Walleij; Shreshtha
> Kumar Sahu; Kim, Jong-Sung
> Cc: linux-kernel@vger.kernel.org; linux-serial@vger.kernel.org
> Subject: [PATCH] Clear previous interrupts after fifo is disabled
>
> This is another workaroud of 'https://lkml.org/lkml/2012/1/17/104'
> with additional analysis.Bootloader can transfer control to kernel and
there
> are some pending interrupts. In this case, RXFE of the flag register is
set
> by clearing FEN(LCRH) even if rx data remains in the fifo. It seems that
the
> fifo's status is initiailized. Interrupt handler can not get any data from
> data register because of the below break condtion.
>
> pl011_fifo_to_tty
> while (max_count--) {
> if (status & UART01x_FR_RXFE)
> break;
>
> Then, Rx interrupt is never cleared. cpu is looping in ISR. System is
hang.
> If we don't guarantee that no interrupt is pended until fifo is disabled
by
> calling 'writew(0, uap->port.membase + uap->lcrh_rx)', this misbehave of
the
> interrupt handelr can be occurred. So, All pending interrupts should be
> cleared just after fifo is disabled under the protection from interrupt.
> Also,'clear error interrupts' routine can be removed becuase all
interrupts
> are cleared before.
>
> Signed-off-by: Chanho Min <chanho.min@lge.com>
May I suggest another approach at this point? The problematic condition you
reported could be considered as an exceptional Rx interrupt status. So, we
can handle it in the Rx ISR. Simply:
diff --git a/drivers/tty/serial/amba-pl011.c
b/drivers/tty/serial/amba-pl011.c
index 6800f5f..5b5358705 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -224,6 +224,10 @@ static int pl011_fifo_to_tty(struct uart_amba_port
*uap)
uart_insert_char(&uap->port, ch, UART011_DR_OE, ch, flag);
}
+ /* RXIS but RXFE? Just clear the interrupt */
+ if(unlikely(fifotaken == 0))
+ writew(UART011_RXIS, uap->port.membase + UART01x_ICR);
+
return fifotaken;
}
^ permalink raw reply related
* Re: [PATCH 0/7] powerpc: remove the legacy iSeries platform specific drivers
From: David Miller @ 2012-03-08 6:53 UTC (permalink / raw)
To: sfr
Cc: benh, linuxppc-dev, JBottomley, netdev, alan, brking, gregkh,
linux-scsi, linux-serial, axboe, linux-kernel
In-Reply-To: <20120308152853.b5010336abbb8f90e8a2500c@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 8 Mar 2012 15:28:53 +1100
> It would probably be easiest if all these patches were merged via the
> powerpc tree to eliminate any dependencies between them. Their impact on
> generic code is very small.
No objections.
^ permalink raw reply
* [PATCH 5/7] tty: powerpc: remove SERIAL_ICOM dependency on PPC_ISERIES
From: Stephen Rothwell @ 2012-03-08 4:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Alan Cox, Greg Kroah-Hartman, linux-serial, ppc-dev, LKML
In-Reply-To: <20120308152853.b5010336abbb8f90e8a2500c@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 880 bytes --]
The PowerPC legacy iSeries platform is being removed so this is no
longer selectable.
Cc: Alan Cox <alan@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-serial@vger.kernel.org
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/tty/serial/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 2de9924..59e7983 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -853,7 +853,7 @@ config SERIAL_MPC52xx_CONSOLE_BAUD
config SERIAL_ICOM
tristate "IBM Multiport Serial Adapter"
- depends on PCI && (PPC_ISERIES || PPC_PSERIES)
+ depends on PCI && PPC_PSERIES
select SERIAL_CORE
select FW_LOADER
help
--
1.7.9.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* [PATCH 0/7] powerpc: remove the legacy iSeries platform specific drivers
From: Stephen Rothwell @ 2012-03-08 4:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: ppc-dev, James E.J. Bottomley, netdev, Alan Cox, Brian King,
David Miller, Greg Kroah-Hartman, linux-scsi, linux-serial,
Jens Axboe, LKML
[-- Attachment #1: Type: text/plain, Size: 1982 bytes --]
Hi all,
This series of patches removes all the legacy iSeries platform specific
drivers (and the iSeries specific part of one). The legacy iSeries
platform main code has already bee removed along with CONFIG_PPC_ISERIES,
so none of this code is selectable or needed any more.
It would probably be easiest if all these patches were merged via the
powerpc tree to eliminate any dependencies between them. Their impact on
generic code is very small.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
arch/powerpc/include/asm/iseries/hv_call_event.h | 201 ---
arch/powerpc/include/asm/iseries/hv_lp_event.h | 162 --
arch/powerpc/include/asm/iseries/iommu.h | 37 -
arch/powerpc/include/asm/iseries/vio.h | 265 ----
arch/powerpc/kernel/vio.c | 18 +-
drivers/base/driver.c | 30 -
drivers/block/viodasd.c | 809 ----------
drivers/cdrom/viocd.c | 739 ----------
drivers/char/viotape.c | 1041 -------------
drivers/net/ethernet/ibm/Kconfig | 4 -
drivers/net/ethernet/ibm/Makefile | 1 -
drivers/net/ethernet/ibm/iseries_veth.c | 1710 ----------------------
drivers/scsi/Kconfig | 3 +-
drivers/scsi/ibmvscsi/Makefile | 1 -
drivers/scsi/ibmvscsi/ibmvscsi.c | 12 +-
drivers/scsi/ibmvscsi/ibmvscsi.h | 1 -
drivers/scsi/ibmvscsi/iseries_vscsi.c | 173 ---
drivers/tty/hvc/Kconfig | 10 -
drivers/tty/hvc/Makefile | 1 -
drivers/tty/hvc/hvc_iseries.c | 599 --------
drivers/tty/serial/Kconfig | 2 +-
include/linux/device.h | 4 -
22 files changed, 5 insertions(+), 5818 deletions(-)
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* bad serial port count when trying to login
From: Subodh Nijsure @ 2012-03-07 19:48 UTC (permalink / raw)
To: linux-serial
Hello,
I have ARM based board (iMX28 processor) that has two serial ports one
of them runs console on port /dev/ttyAMA0 and I am able to login and
everything works fine.
However when I try to manually run getty on other serial port, using command:
nohup getty -l "/bin/login" 9600 /dev/ttyAPP3 &
my current login session on /dev/ttyAMA0 gets terminated I see following error,
uart_close: bad serial port count; tty->count is 1, port->count is 2
uart_close: bad serial port count; tty->count is 1, port->count is 0
I am running 3.1.0-rc5 kernel.
Can someone give me clues as to why this might be and clues on fixing it.
Thanks!
-Subodh
^ permalink raw reply
* Re: [PATCH 0/4 V2] pch_uart: Cleanups, board quirks, and user uartclk parameter
From: Greg Kroah-Hartman @ 2012-03-07 18:39 UTC (permalink / raw)
To: Darren Hart
Cc: Tomoya MORINAGA, Alan Cox, Linux Kernel Mailing List, Feng Tang,
linux-serial
In-Reply-To: <4F57A9B8.1030609@linux.intel.com>
On Wed, Mar 07, 2012 at 10:32:24AM -0800, Darren Hart wrote:
>
> On 02/29/2012 04:53 PM, Greg Kroah-Hartman wrote:
> > On Wed, Feb 29, 2012 at 04:47:58PM -0800, Darren Hart wrote:
> >>
> >>
> >> On 02/29/2012 04:38 PM, Tomoya MORINAGA wrote:
> >>> Hi
> >>>
> >>> Darren's patch series, I think OK.
> >>> However, need to proceed next step.
> >>
> >> Great, Greg are you happy with these as they are?
> >
> > I'll look them over in the next few days and let you know.
> >
>
> Hey Greg. Any thoughts on these?
Still in my "to-apply" queue, I was traveling yesterday and am trying to
catch up. Don't worry, they aren't lost :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 0/4 V2] pch_uart: Cleanups, board quirks, and user uartclk parameter
From: Darren Hart @ 2012-03-07 18:32 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Tomoya MORINAGA, Alan Cox, Linux Kernel Mailing List, Feng Tang,
linux-serial
In-Reply-To: <20120301005303.GA5070@kroah.com>
On 02/29/2012 04:53 PM, Greg Kroah-Hartman wrote:
> On Wed, Feb 29, 2012 at 04:47:58PM -0800, Darren Hart wrote:
>>
>>
>> On 02/29/2012 04:38 PM, Tomoya MORINAGA wrote:
>>> Hi
>>>
>>> Darren's patch series, I think OK.
>>> However, need to proceed next step.
>>
>> Great, Greg are you happy with these as they are?
>
> I'll look them over in the next few days and let you know.
>
Hey Greg. Any thoughts on these?
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply
* MAIL
From: RICHARD TANG @ 2012-03-07 15:46 UTC (permalink / raw)
Mail From Tang.
I work with the hang seng Bank Hong Kong.I have a business proposition
for you involving a trade in my bank which I know we will be of mutual
benefit to both of us, If interested mail me at:trichad@yahoo.cn
Regards,
Richard Tang.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* Re: [RFC PATCH] OMAP: UART: Enable tx wakeup bit in wer
From: Paul Walmsley @ 2012-03-07 5:57 UTC (permalink / raw)
To: Raja, Govindraj
Cc: linux-omap, linux-serial, Kevin Hilman, Partha Basak,
linux-arm-kernel
In-Reply-To: <CAMrsUdJqmJ75=X_Qg3vQCr7zezs0jOK8L1ri8p5K=+6ZKsRFcg@mail.gmail.com>
Hi
On Tue, 6 Mar 2012, Raja, Govindraj wrote:
> I see two ways of adding this tx wake-up flag.
>
> 1.) passing a feature flag from pdata and populating the feature value to wer.
>
> 2.) Duplicating the uart1/2/3 hwmod for omap3430 without dev attrib
> and uart1/2/3/4
> hwmod for omap3630 with dev attribs.
>
> Approach-2 adds unnecessary code duplication in hwmod file with and without
> dev_attribs, So right now here is the patch to follow approach [1],
>
> If its strongly recommended to use approach-2 will add it.
> (My concern is the diffstat it might produce with approach-2)
Both 1 and 2 are needed.
The current way that errata are handled in arch/arm/mach-omap2/serial.c
needs to be changed. Those should be flags that are passed from hwmod
dev_attr data. The presence of the TX wakeup bit should simply be another
dev_attr flag. These flags should be passed to the driver via the
omap_up.errata field for the time being.
The exception to this is if the IP block's revision register was changed
when TX wakeups became possible. If that's the case, then that mechanism
can be used in lieu of dev_attr and platform_data in this situation.
- Paul
^ permalink raw reply
* Re: [PATCH 05/68] TTY: remove re-assignments to tty_driver members
From: Tilman Schmidt @ 2012-03-06 23:49 UTC (permalink / raw)
To: Jiri Slaby; +Cc: gregkh, alan, linux-serial, linux-kernel, jirislaby
In-Reply-To: <1330955575-26641-6-git-send-email-jslaby@suse.cz>
[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]
Am 05.03.2012 14:51, schrieb Jiri Slaby:
> All num, magic and owner are set by alloc_tty_driver. No need to
> re-set them on each allocation site.
Nice.
> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
For drivers/isdn/gigaset:
Acked-by: Tilman Schmidt <tilman@imap.cc>
> diff --git a/drivers/isdn/gigaset/interface.c b/drivers/isdn/gigaset/interface.c
> index b826dac..7e54577 100644
> --- a/drivers/isdn/gigaset/interface.c
> +++ b/drivers/isdn/gigaset/interface.c
> @@ -669,17 +669,15 @@ EXPORT_SYMBOL_GPL(gigaset_if_receive);
> void gigaset_if_initdriver(struct gigaset_driver *drv, const char *procname,
> const char *devname)
> {
> - unsigned minors = drv->minors;
> int ret;
> struct tty_driver *tty;
>
> drv->have_tty = 0;
>
> - drv->tty = tty = alloc_tty_driver(minors);
> + drv->tty = tty = alloc_tty_driver(drv->minors);
> if (tty == NULL)
> goto enomem;
>
> - tty->magic = TTY_DRIVER_MAGIC;
> tty->type = TTY_DRIVER_TYPE_SERIAL;
> tty->subtype = SERIAL_TYPE_NORMAL;
> tty->flags = TTY_DRIVER_REAL_RAW | TTY_DRIVER_DYNAMIC_DEV;
> @@ -687,9 +685,6 @@ void gigaset_if_initdriver(struct gigaset_driver *drv, const char *procname,
> tty->driver_name = procname;
> tty->name = devname;
> tty->minor_start = drv->minor;
> - tty->num = drv->minors;
> -
> - tty->owner = THIS_MODULE;
>
> tty->init_termios = tty_std_termios;
> tty->init_termios.c_cflag = B9600 | CS8 | CREAD | HUPCL | CLOCAL;
Thanks,
Tilman
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] OMAP: UART: Enable tx wakeup bit in wer
From: Raja, Govindraj @ 2012-03-06 10:05 UTC (permalink / raw)
To: Paul Walmsley
Cc: linux-omap, linux-serial, Kevin Hilman, Partha Basak,
linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1203051321580.1430@utopia.booyaka.com>
On Tue, Mar 6, 2012 at 1:53 AM, Paul Walmsley <paul@pwsan.com> wrote:
>
> Hello Govindraj
>
> Do you intend to update and repost this serial patch? Or should someone
> else deal with it? It would be good to get support for this additional
> wakeup bit.
Thanks for reminding.
(I had got preempted with other activities, apologies for the delay)
I see two ways of adding this tx wake-up flag.
1.) passing a feature flag from pdata and populating the feature value to wer.
2.) Duplicating the uart1/2/3 hwmod for omap3430 without dev attrib
and uart1/2/3/4
hwmod for omap3630 with dev attribs.
Approach-2 adds unnecessary code duplication in hwmod file with and without
dev_attribs, So right now here is the patch to follow approach [1],
If its strongly recommended to use approach-2 will add it.
(My concern is the diffstat it might produce with approach-2)
--
Thanks,
Govindraj.R
[1]:
From 867dfa7328b4219be259a204555a6baae82ec4df Mon Sep 17 00:00:00 2001
From: "Govindraj.R" <govindraj.raja@ti.com>
Date: Tue, 6 Mar 2012 15:04:47 +0530
Subject: [PATCH] OMAP: UART: enable tx wake up capability for 3630 above socs
From omap3630 above UART wer(wakeup enable reg) has TX
wakeup capability, enable the tx wakeup bit by passing
the required feature flag from pdata.
Also add missing wer reg restore from context restore function.
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
---
arch/arm/mach-omap2/serial.c | 3 +++
arch/arm/plat-omap/include/plat/omap-serial.h | 7 +++++++
drivers/tty/serial/omap-serial.c | 8 +++++++-
3 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index f590afc..eb43996 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -357,6 +357,9 @@ void __init omap_serial_init_port(struct
omap_board_data *bdata,
omap_up.dma_rx_poll_rate = info->dma_rx_poll_rate;
omap_up.autosuspend_timeout = info->autosuspend_timeout;
+ if (!cpu_is_omap24xx() && !cpu_is_omap3430())
+ omap_up.has_feature = UART_FEATURE_TX_WAKEUP_EN;
+
/* Enable the MDR1 Errata i202 for OMAP2430/3xxx/44xx */
if (!cpu_is_omap2420() && !cpu_is_ti816x())
omap_up.errata |= UART_ERRATA_i202_MDR1_ACCESS;
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h
b/arch/arm/plat-omap/include/plat/omap-serial.h
index 9ff4444..b4f42dc 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -61,6 +61,11 @@
#define UART_ERRATA_i202_MDR1_ACCESS BIT(0)
#define UART_ERRATA_i291_DMA_FORCEIDLE BIT(1)
+#define OMAP_UART_TX_WAKEUP_EN BIT(7)
+
+/* Feature flags */
+#define UART_FEATURE_TX_WAKEUP_EN BIT(0)
+
struct omap_uart_port_info {
bool dma_enabled; /* To specify DMA Mode */
unsigned int uartclk; /* UART clock rate */
@@ -70,6 +75,7 @@ struct omap_uart_port_info {
unsigned int dma_rx_timeout;
unsigned int autosuspend_timeout;
unsigned int dma_rx_poll_rate;
+ unsigned int has_feature;
int (*get_context_loss_count)(struct device *);
void (*set_forceidle)(struct platform_device *);
@@ -117,6 +123,7 @@ struct uart_omap_port {
unsigned char dlh;
unsigned char mdr1;
unsigned char scr;
+ unsigned char wer;
int use_dma;
/*
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index f809041..5d7330f 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -577,8 +577,10 @@ static int serial_omap_startup(struct uart_port *port)
up->ier = UART_IER_RLSI | UART_IER_RDI;
serial_out(up, UART_IER, up->ier);
+ up->wer |= OMAP_UART_WER_MOD_WKUP;
+
/* Enable module level wake up */
- serial_out(up, UART_OMAP_WER, OMAP_UART_WER_MOD_WKUP);
+ serial_out(up, UART_OMAP_WER, up->wer);
pm_runtime_mark_last_busy(&up->pdev->dev);
pm_runtime_put_autosuspend(&up->pdev->dev);
@@ -1444,6 +1446,8 @@ static int serial_omap_probe(struct platform_device *pdev)
}
up->uart_dma.uart_base = mem->start;
up->errata = omap_up_info->errata;
+ if (omap_up_info->has_feature & UART_FEATURE_TX_WAKEUP_EN)
+ up->wer |= OMAP_UART_TX_WAKEUP_EN;
if (omap_up_info->dma_enabled) {
up->uart_dma.uart_dma_tx = dma_tx->start;
@@ -1569,6 +1573,8 @@ static void serial_omap_restore_context(struct
uart_omap_port *up)
serial_omap_mdr1_errataset(up, up->mdr1);
else
serial_out(up, UART_OMAP_MDR1, up->mdr1);
+
+ serial_out(up, UART_OMAP_WER, up->wer);
}
static int serial_omap_runtime_suspend(struct device *dev)
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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
* Partnership
From: Mr.Liu Tai Ling @ 2012-03-06 6:43 UTC (permalink / raw)
Good day,
I apology for contact you through this medium, It is due to the urgent nature as requested by our
client to liquidate his Bonds and Get them out of our bank for Investment.
My name is Mr. Ling Tia Liu; I work with Industrial and Commercial Bank of China, Hong
Kong. I have a business proposal in the tune of 21,300,000.00 US Dollars, to be transferred out
of my bank with your assistance.
After the successful transfer, we shall share in ratio of 40% for you and 60% for me. Should you
be interested, Indicate your interest by Providing me with your:
{1}Full Names{2}Contact Address{3}Contact
Telephone Number. I will furnish you with further
details on this project immediately I hear back
from you.
I look forward to hearing from you.
Kind Regards,
Mr. Liu.
^ permalink raw reply
* Partnership
From: Mr.Liu Tai Ling @ 2012-03-06 6:40 UTC (permalink / raw)
Good day,
I apology for contact you through this medium, It is due to the urgent nature as requested by our
client to liquidate his Bonds and Get them out of our bank for Investment.
My name is Mr. Ling Tia Liu; I work with Industrial and Commercial Bank of China, Hong
Kong. I have a business proposal in the tune of 21,300,000.00 US Dollars, to be transferred out
of my bank with your assistance.
After the successful transfer, we shall share in ratio of 40% for you and 60% for me. Should you
be interested, Indicate your interest by Providing me with your:
{1}Full Names{2}Contact Address{3}Contact
Telephone Number. I will furnish you with further
details on this project immediately I hear back
from you.
I look forward to hearing from you.
Kind Regards,
Mr. Liu.
^ permalink raw reply
* Re: [PATCH 0/9] [RFC] tty : make receive_room internal to N_TTY line discipline
From: Alan Cox @ 2012-03-05 23:42 UTC (permalink / raw)
To: matthieu castet; +Cc: linux-serial, Felipe Balbi, Toby Gray, Stefan Bigler
In-Reply-To: <20120304190513.0b7a881b@mat-laptop>
I had a bigger dig into this and I think the path to make it workable is
probably
- Finish getting rid of the tty_lock (ie the last remnants of the BKL)
- At that point we can rework the logic in tty_ldisc a bit and you can
then hold tty->ldisc_mutex across the entire ldisc_receive. That will
be a natural sane way to lock the ldisc.
- Once that is in place it is possible to fix TIOCSTI and selection using
that mutex to single thread.
- Which then lets you fix the receive_room logic because its all running
under a sensible locking model.
I don't see any shortcuts here.
Alan
^ permalink raw reply
* Re: [PATCH 01/68] USB: cdc-acm, use tty_standard_install
From: Alan Cox @ 2012-03-05 23:39 UTC (permalink / raw)
To: Jiri Slaby; +Cc: gregkh, alan, linux-serial, linux-kernel, jirislaby
In-Reply-To: <1330955575-26641-2-git-send-email-jslaby@suse.cz>
On Mon, 5 Mar 2012 14:51:48 +0100
Jiri Slaby <jslaby@suse.cz> wrote:
> This is a piece I missed the last time.
>
> Do not copy the functionality all over the tree. Instead, use the
> helper the tty layer provides us with.
All looks sane to me
^ permalink raw reply
* [GIT PATCH] TTY/serial patches for 3.3-rc6
From: Greg KH @ 2012-03-05 23:35 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton; +Cc: linux-kernel, linux-serial
The following changes since commit b01543dfe67bb1d191998e90d20534dc354de059:
Linux 3.3-rc4 (2012-02-18 15:53:33 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/ tty-3.3-rc6
for you to fetch changes up to f21c6d4a49179f91fd70a41382382f08c780d425:
tty/powerpc: early udbg consoles can't be modules (2012-02-24 16:11:50 -0800)
----------------------------------------------------------------
tty: build fix for 3.3-rc6
This contains one build fix for the powerpc udbg driver that was reported.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----------------------------------------------------------------
Stephen Rothwell (1):
tty/powerpc: early udbg consoles can't be modules
drivers/tty/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
^ permalink raw reply
* Re: [RFC PATCH] OMAP: UART: Enable tx wakeup bit in wer
From: Paul Walmsley @ 2012-03-05 20:23 UTC (permalink / raw)
To: Govindraj.R
Cc: linux-omap, linux-serial, Kevin Hilman, Partha Basak,
linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1201251217120.5324@utopia.booyaka.com>
Hello Govindraj
Do you intend to update and repost this serial patch? Or should someone
else deal with it? It would be good to get support for this additional
wakeup bit.
- Paul
^ permalink raw reply
* Re: [PATCH 67/68] TTY: isdn/gigaset, do not set tty->driver_data to NULL
From: Jiri Slaby @ 2012-03-05 17:12 UTC (permalink / raw)
To: Tilman Schmidt
Cc: Jiri Slaby, gregkh, alan, linux-serial, linux-kernel,
Hansjoerg Lipp, gigaset307x-common
In-Reply-To: <4F54F270.8030108@imap.cc>
On 03/05/2012 06:05 PM, Tilman Schmidt wrote:
> Am 05.03.2012 14:52, schrieb Jiri Slaby:
>> Close the window in open where driver_data is reset to NULL on
>> each open. It could cause other processes to get invalid retval
>> from the tty->ops operations because of the checks all over the
>> code.
>
>> With this change we may do other cleanups. Now, the only valid
>> check for tty->driver_data != NULL is in close. This can happen
>> only if open fails at gigaset_get_cs_by_tty or try_module_get.
>> The rest of checks in various tty->ops->* are invalid as
>> driver_data cannot be NULL there. The same holds for
>> cs->open_count. So remove them.
>
> Thanks for that nice cleanup. It's most welcome. Just one question
> and a small nit:
>
>> --- a/drivers/isdn/gigaset/interface.c +++
>> b/drivers/isdn/gigaset/interface.c
> [...]
>> @@ -178,12 +176,11 @@ static int if_open(struct tty_struct *tty,
>> struct file *filp)
>
>> static void if_close(struct tty_struct *tty, struct file *filp)
>> { - struct cardstate *cs; + struct cardstate *cs =
>> tty->driver_data; unsigned long flags;
>
>> - cs = (struct cardstate *) tty->driver_data; - if (!cs) { -
>> pr_err("%s: no cardstate\n", __func__); + if (!cs) { /* happens
>> if we didn't find cs in open */ + printk(KERN_DEBUG "%s: no
>> cardstate\n", __func__); return; }
>
>
> Why are you downgrading the error message from KERN_ERR to
> KERN_DEBUG here? I would think that condition would warrant a
> message with KERN_ERR severity. Also, the driver does KERN_DEBUG
> output uniformly through the gig_dbg macro, so if you are sure it
> should be turned into a debug message then please write it as
>
> gig_dbg(DEBUG_IF, "%s: no cardstate", __func__);
>
> like four lines later.
<citing myself from the commit log>
Now, the only valid check for tty->driver_data != NULL is in close.
This can happen only if open fails at gigaset_get_cs_by_tty or
try_module_get.
</citing>
I.e. when the module behind the device is going away, driver_data can
be NULL. In that case we don't want to threaten the user by ERR messages.
You are maybe right, that we should switch it to gig_dbg or remove the
print completely (as it is a legitimate path). I'll wait until the
patches settles down a bit and fix it. If I, by a chance, forget to do
so, poke me or feel free to do it yourself ;).
thanks,
--
js
suse labs
^ permalink raw reply
* Re: [PATCH 68/68] TTY: isdn/gigaset, use tty_port
From: Tilman Schmidt @ 2012-03-05 17:08 UTC (permalink / raw)
To: Jiri Slaby
Cc: gregkh, alan, linux-serial, linux-kernel, jirislaby,
Hansjoerg Lipp, gigaset307x-common
In-Reply-To: <1330955575-26641-69-git-send-email-jslaby@suse.cz>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am 05.03.2012 14:52, schrieb Jiri Slaby:
> Let us port the code to use tty_port. We now use open_count and tty
> from there. This allows us also to use tty_port_tty_set with tty
> refcounting instead of hand-written locking and logic.
>
> Note that tty and open_count are no longer protected by cs->lock. It is
> protected by tty_port->lock. But since all the places where they were
> used are now switched to the helpers, we are fine.
>
> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
> Cc: Hansjoerg Lipp <hjlipp@web.de>
> Cc: Tilman Schmidt <tilman@imap.cc>
> Cc: gigaset307x-common@lists.sourceforge.net
Very nice. Thanks!
Acked-by: Tilman Schmidt <tilman@imap.cc>
- --
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
iEYEARECAAYFAk9U8vAACgkQQ3+did9BuFv8RACeLMRSUGhjotg0il1LtWqtfrzR
sakAn0LJr66dYyUXteH44p5+KFQuS5v9
=Is+Q
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH 67/68] TTY: isdn/gigaset, do not set tty->driver_data to NULL
From: Tilman Schmidt @ 2012-03-05 17:05 UTC (permalink / raw)
To: Jiri Slaby
Cc: gregkh, alan, linux-serial, linux-kernel, jirislaby,
Hansjoerg Lipp, gigaset307x-common
In-Reply-To: <1330955575-26641-68-git-send-email-jslaby@suse.cz>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am 05.03.2012 14:52, schrieb Jiri Slaby:
> Close the window in open where driver_data is reset to NULL on each
> open. It could cause other processes to get invalid retval from the
> tty->ops operations because of the checks all over the code.
>
> With this change we may do other cleanups. Now, the only valid check
> for tty->driver_data != NULL is in close. This can happen only if open
> fails at gigaset_get_cs_by_tty or try_module_get. The rest of checks
> in various tty->ops->* are invalid as driver_data cannot be NULL
> there. The same holds for cs->open_count. So remove them.
Thanks for that nice cleanup. It's most welcome.
Just one question and a small nit:
> --- a/drivers/isdn/gigaset/interface.c
> +++ b/drivers/isdn/gigaset/interface.c
[...]
> @@ -178,12 +176,11 @@ static int if_open(struct tty_struct *tty, struct file *filp)
>
> static void if_close(struct tty_struct *tty, struct file *filp)
> {
> - struct cardstate *cs;
> + struct cardstate *cs = tty->driver_data;
> unsigned long flags;
>
> - cs = (struct cardstate *) tty->driver_data;
> - if (!cs) {
> - pr_err("%s: no cardstate\n", __func__);
> + if (!cs) { /* happens if we didn't find cs in open */
> + printk(KERN_DEBUG "%s: no cardstate\n", __func__);
> return;
> }
>
Why are you downgrading the error message from KERN_ERR to KERN_DEBUG
here? I would think that condition would warrant a message with
KERN_ERR severity.
Also, the driver does KERN_DEBUG output uniformly through the gig_dbg
macro, so if you are sure it should be turned into a debug message
then please write it as
gig_dbg(DEBUG_IF, "%s: no cardstate", __func__);
like four lines later.
Thanks,
Tilman
- --
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/
iEYEARECAAYFAk9U8nAACgkQQ3+did9BuFsaiwCeKiL8hghkVcjstG5azxYoIXOK
Yl0Anj2FWsaiE4zx3ioVvCo6xgFVKBTk
=i3+X
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH] mpc5200b/uart: select more tolerant uart prescaler on low baudrates
From: Frank Benkert @ 2012-03-05 15:14 UTC (permalink / raw)
To: alan; +Cc: gregkh, linux-serial, linux-kernel, Frank Benkert
In addition to the /32 prescaler, the MPC5200B supports a second baudrate
prescaler /4 to reach higher baudrates.
The current calculation (introduced with commit 0d1f22e4) in the kernel
preferes this low prescaler as often as possible, but with some imprecise
counterparts the communication on low baudrates fails.
According a support-mail from freescale the low prescaler (/4) allows just
1% tolerance in bittiming in contrast to 4% of the high prescaler (/32).
The prescaler not only affects the baudrate-calculation, but also the sampling
of the bits on the wire.
With this patch, we use the slightly less precise, but higher tolerant
prescaler calculation on low baudrates up to (and including) 115200 baud and
the more precise calculation above.
Tested on a custom MPC5200B board with "fsl,mpc5200b-psc-uart".
Signed-off-by: Frank Benkert <frank.benkert@avat.de>
---
Calculation Examples with prescaler (PS) 4 and 32 and divisor (DIV) on various
baudrates. Real stands for the real baudrate generated and Diff for the
differences between:
50 Baud PS 32 DIV 0xa122 Real 50 Diff 0.00%
75 Baud PS 32 DIV 0x6b6c Real 75 Diff 0.00%
110 Baud PS 32 DIV 0x493e Real 110 Diff 0.00%
134 Baud PS 32 DIV 0x3c20 Real 133 Diff 0.75%
150 Baud PS 32 DIV 0x35b6 Real 150 Diff 0.00%
200 Baud PS 32 DIV 0x2849 Real 199 Diff 0.50%
300 Baud PS 4 DIV 0xd6d8 Real 300 Diff 0.00%
PS 32 DIV 0x1adb Real 300 Diff 0.00%
600 Baud PS 4 DIV 0x6b6c Real 600 Diff 0.00%
PS 32 DIV 0x0d6e Real 599 Diff 0.17%
1200 Baud PS 4 DIV 0x35b6 Real 1200 Diff 0.00%
PS 32 DIV 0x06b7 Real 1199 Diff 0.08%
1800 Baud PS 4 DIV 0x23cf Real 1799 Diff 0.06%
PS 32 DIV 0x047a Real 1799 Diff 0.06%
2400 Baud PS 4 DIV 0x1adb Real 2400 Diff 0.00%
PS 32 DIV 0x035b Real 2401 Diff - 0.04%
4800 Baud PS 4 DIV 0x0d6e Real 4799 Diff 0.02%
PS 32 DIV 0x01ae Real 4796 Diff 0.08%
9600 Baud PS 4 DIV 0x06b7 Real 9598 Diff 0.02%
PS 32 DIV 0x00d7 Real 9593 Diff 0.07%
19200 Baud PS 4 DIV 0x035b Real 19208 Diff - 0.04%
PS 32 DIV 0x006b Real 19275 Diff - 0.39%
38400 Baud PS 4 DIV 0x01ae Real 38372 Diff 0.07%
PS 32 DIV 0x0036 Real 38194 Diff 0.54%
57600 Baud PS 4 DIV 0x011e Real 57692 Diff - 0.16%
PS 32 DIV 0x0024 Real 57291 Diff 0.54%
76800 Baud PS 4 DIV 0x00d7 Real 76744 Diff 0.07%
PS 32 DIV 0x001b Real 76388 Diff 0.54%
115200 Baud PS 4 DIV 0x008f Real 115384 Diff - 0.16%
PS 32 DIV 0x0012 Real 114583 Diff 0.54%
153600 Baud PS 4 DIV 0x006b Real 154205 Diff - 0.39%
PS 32 DIV 0x000d Real 158653 Diff - 3.29%
230400 Baud PS 4 DIV 0x0048 Real 229166 Diff 0.54%
PS 32 DIV 0x0009 Real 229166 Diff 0.54%
307200 Baud PS 4 DIV 0x0036 Real 305555 Diff 0.54%
PS 32 DIV 0x0007 Real 294642 Diff 4.09%
460800 Baud PS 4 DIV 0x0024 Real 458333 Diff 0.54%
PS 32 DIV 0x0005 Real 412500 Diff 10.48%
500000 Baud PS 4 DIV 0x0021 Real 500000 Diff 0.00%
PS 32 DIV 0x0004 Real 515625 Diff - 3.13%
576000 Baud PS 4 DIV 0x001d Real 568965 Diff 1.22%
PS 32 DIV 0x0004 Real 515625 Diff 10.48%
614400 Baud PS 4 DIV 0x001b Real 611111 Diff 0.54%
PS 32 DIV 0x0003 Real 687500 Diff -11.90%
921600 Baud PS 4 DIV 0x0012 Real 916666 Diff 0.54%
PS 32 DIV 0x0002 Real 1031250 Diff -11.90%
1000000 Baud PS 4 DIV 0x0011 Real 970588 Diff 2.94%
PS 32 DIV 0x0002 Real 1031250 Diff - 3.13%
1152000 Baud PS 4 DIV 0x000e Real 1178571 Diff - 2.31%
PS 32 DIV 0x0002 Real 1031250 Diff 10.48%
1500000 Baud PS 4 DIV 0x000b Real 1500000 Diff 0.00%
PS 32 DIV 0x0001 Real 2062500 Diff -37.50%
2000000 Baud PS 4 DIV 0x0008 Real 2062500 Diff - 3.13%
PS 32 DIV 0x0001 Real 2062500 Diff - 3.13%
2500000 Baud PS 4 DIV 0x0007 Real 2357142 Diff 5.71%
PS 32 DIV 0x0001 Real 2062500 Diff 17.50%
3000000 Baud PS 4 DIV 0x0006 Real 2750000 Diff 8.33%
PS 32 DIV 0x0001 Real 2062500 Diff 31.25%
3500000 Baud PS 4 DIV 0x0005 Real 3300000 Diff 5.71%
PS 32 DIV 0x0001 Real 2062500 Diff 41.07%
4000000 Baud PS 4 DIV 0x0004 Real 4125000 Diff - 3.13%
PS 32 DIV 0x0001 Real 2062500 Diff 48.44%
drivers/tty/serial/mpc52xx_uart.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/mpc52xx_uart.c b/drivers/tty/serial/mpc52xx_uart.c
index 1093a88..5e2c6fe 100644
--- a/drivers/tty/serial/mpc52xx_uart.c
+++ b/drivers/tty/serial/mpc52xx_uart.c
@@ -262,8 +262,9 @@ static unsigned int mpc5200b_psc_set_baudrate(struct uart_port *port,
port->uartclk / 4);
divisor = (port->uartclk + 2 * baud) / (4 * baud);
- /* select the proper prescaler and set the divisor */
- if (divisor > 0xffff) {
+ /* select the proper prescaler and set the divisor
+ * prefer high prescaler for more tolerance on low baudrates */
+ if (divisor > 0xffff || baud <= 115200) {
divisor = (divisor + 4) / 8;
prescaler = 0xdd00; /* /32 */
} else
--
1.5.2.1
^ 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