* Re: [PATCH] serial: 8250: Add cpufreq support
From: Alan Cox @ 2012-04-05 10:53 UTC (permalink / raw)
To: Shankarmurthy, Akshay
Cc: linux-serial@vger.kernel.org, alan@linux.intel.com,
gregkh@linuxfoundation.org, paul.gortmaker@windriver.com,
jamie@jamieiles.com, swarren@nvidia.com, dianders@chromium.org,
davinci-linux-open-source@linux.davincidsp.com,
linux-kernel@vger.kernel.org
In-Reply-To: <6F6B80BD2E18844D97BB4B51FE3705C831790EA0@DBDE01.ent.ti.com>
On Thu, 5 Apr 2012 10:40:55 +0000
"Shankarmurthy, Akshay" <akshay.s@ti.com> wrote:
> Hi,
>
> On Tue, Apr 03, 2012 at 15:25:30, Alan Cox wrote:
> > > This patch was submitted 2 years ago but didn't make it to the mainline. Now i am reposting it.
> >
> > Can you fix it instead of just reposting it ?
> >
> >
> > > +#ifdef CONFIG_CPU_FREQ
> > > +static int serial8250_cpufreq_transition(struct notifier_block *nb,
> > > + unsigned long val, void *data)
> > > +{
> > > + struct uart_8250_port *p;
> > > + struct uart_port *uport;
> >
> > What is your locking model ?
> >
>
> I will have a look at this and add the lock if necessary.
At the very least you need reference counts held on the tty struct and to
allow for the tty having vanished under you.
> >
> > > +static inline void serial8250_cpufreq_deregister(struct uart_8250_port *p)
> >
> > unregister
>
> Ok. I will change it.
>
> >
> > > + ret = serial8250_cpufreq_register(uart);
> > > + if (ret < 0)
> > > + printk(KERN_ERR "Failed to add cpufreq notifier\n");
> >
> > Why do this for devices that don't care.
>
> This is taken care in the code. If the device's frequency doesn't change after the
> change in the cpu frequency then it doesn't go for execution of the function "serial8250_set_termios".
But you still call each function and walk the list for each port on each
CPU transition. There are people with 128 ports in their systems and the
cpu frequency change is latency critical.
Nothing should even be getting registered in such cases.
^ permalink raw reply
* RE: [PATCH] serial: 8250: Add cpufreq support
From: Shankarmurthy, Akshay @ 2012-04-05 10:40 UTC (permalink / raw)
To: Alan Cox
Cc: davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org,
swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org,
linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
jamie-wmLquQDDieKakBO8gow8eQ@public.gmane.org,
alan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org
In-Reply-To: <20120403105530.7fa3bce7-38n7/U1jhRXW96NNrWNlrekiAK3p4hvP@public.gmane.org>
Hi,
On Tue, Apr 03, 2012 at 15:25:30, Alan Cox wrote:
> > This patch was submitted 2 years ago but didn't make it to the mainline. Now i am reposting it.
>
> Can you fix it instead of just reposting it ?
>
>
> > +#ifdef CONFIG_CPU_FREQ
> > +static int serial8250_cpufreq_transition(struct notifier_block *nb,
> > + unsigned long val, void *data)
> > +{
> > + struct uart_8250_port *p;
> > + struct uart_port *uport;
>
> What is your locking model ?
>
I will have a look at this and add the lock if necessary.
>
> > +static inline void serial8250_cpufreq_deregister(struct uart_8250_port *p)
>
> unregister
Ok. I will change it.
>
> > + ret = serial8250_cpufreq_register(uart);
> > + if (ret < 0)
> > + printk(KERN_ERR "Failed to add cpufreq notifier\n");
>
> Why do this for devices that don't care.
This is taken care in the code. If the device's frequency doesn't change after the
change in the cpu frequency then it doesn't go for execution of the function "serial8250_set_termios".
It does execute only if the uart clk frequency is changed with a change in the cpu frequency.
So registering this for the devices that doesn't care will not affect the system.
Regards,
Akshay
^ permalink raw reply
* Re: [PATCH v3] OMAP2+: UART: Remove cpu checks for populating errata flags
From: Jon Hunter @ 2012-04-04 14:10 UTC (permalink / raw)
To: Govindraj.R
Cc: linux-omap, linux-serial, linux-arm-kernel, Paul Walmsley,
Kevin Hilman, Felipe Balbi
In-Reply-To: <1333460554-7356-1-git-send-email-govindraj.raja@ti.com>
Hi Govindraj,
On 04/03/2012 08:42 AM, Govindraj.R wrote:
> From: "Govindraj.R"<govindraj.raja@ti.com>
>
> Currently the errata is populated based on cpu checks this can
> be removed and replaced with module version check of uart ip block.
> MVR reg is provided within the uart reg map use the same
> to populate the errata and thus now errata population and handling
> can be managed within the driver itself.
>
> Cc: Jon Hunter<jon-hunter@ti.com>
> Cc: Paul Walmsley<paul@pwsan.com>
> Cc: Kevin Hilman<khilman@ti.com>
> Signed-off-by: Felipe Balbi<balbi@ti.com>
> Signed-off-by: Govindraj.R<govindraj.raja@ti.com>
> ---
> arch/arm/mach-omap2/serial.c | 8 ---
> arch/arm/plat-omap/include/plat/omap-serial.h | 1 -
> drivers/tty/serial/omap-serial.c | 74 ++++++++++++++++++++++++-
> 3 files changed, 73 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
> index 0cdd359..6affdd4 100644
> --- a/arch/arm/mach-omap2/serial.c
> +++ b/arch/arm/mach-omap2/serial.c
> @@ -355,14 +355,6 @@ void __init omap_serial_init_port(struct omap_board_data *bdata,
> omap_up.dma_rx_poll_rate = info->dma_rx_poll_rate;
> omap_up.autosuspend_timeout = info->autosuspend_timeout;
>
> - /* Enable the MDR1 Errata i202 for OMAP2430/3xxx/44xx */
> - if (!cpu_is_omap2420()&& !cpu_is_ti816x())
> - omap_up.errata |= UART_ERRATA_i202_MDR1_ACCESS;
> -
> - /* Enable DMA Mode Force Idle Errata i291 for omap34xx/3630 */
> - if (cpu_is_omap34xx() || cpu_is_omap3630())
> - omap_up.errata |= UART_ERRATA_i291_DMA_FORCEIDLE;
> -
> pdata =&omap_up;
> pdata_size = sizeof(struct omap_uart_port_info);
>
> diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h
> index 9ff4444..1a52725 100644
> --- a/arch/arm/plat-omap/include/plat/omap-serial.h
> +++ b/arch/arm/plat-omap/include/plat/omap-serial.h
> @@ -65,7 +65,6 @@ struct omap_uart_port_info {
> bool dma_enabled; /* To specify DMA Mode */
> unsigned int uartclk; /* UART clock rate */
> upf_t flags; /* UPF_* flags */
> - u32 errata;
> unsigned int dma_rx_buf_size;
> unsigned int dma_rx_timeout;
> unsigned int autosuspend_timeout;
> diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> index 0121486..0555c96 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -44,6 +44,13 @@
> #include<plat/dmtimer.h>
> #include<plat/omap-serial.h>
>
> +#define UART_BUILD_REVISION(x, y) (((x)<< 8) | (y))
> +
> +#define OMAP_UART_REV_42 0x0402
> +#define OMAP_UART_REV_46 0x0406
> +#define OMAP_UART_REV_52 0x0502
> +#define OMAP_UART_REV_63 0x0603
> +
> #define DEFAULT_CLK_SPEED 48000000 /* 48Mhz*/
>
> /* SCR register bitmasks */
> @@ -53,6 +60,17 @@
> #define OMAP_UART_FCR_RX_FIFO_TRIG_SHIFT 6
> #define OMAP_UART_FCR_RX_FIFO_TRIG_MASK (0x3<< 6)
>
> +/* MVR register bitmasks */
> +#define OMAP_UART_MVR_SCHEME_SHIFT 30
> +
> +#define OMAP_UART_LEGACY_MVR_MAJ_MASK 0xf0
> +#define OMAP_UART_LEGACY_MVR_MAJ_SHIFT 4
> +#define OMAP_UART_LEGACY_MVR_MIN_MASK 0x0f
> +
> +#define OMAP_UART_MVR_MAJ_MASK 0x700
> +#define OMAP_UART_MVR_MAJ_SHIFT 8
> +#define OMAP_UART_MVR_MIN_MASK 0x3f
> +
> static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
>
> /* Forward declaration of functions */
> @@ -1346,6 +1364,59 @@ static void uart_tx_dma_callback(int lch, u16 ch_status, void *data)
> return;
> }
>
> +static void omap_serial_fill_features_erratas(struct uart_omap_port *up)
> +{
> + u32 mvr, scheme;
> + u16 revision, major, minor;
> +
> + mvr = serial_in(up, UART_OMAP_MVER);
> +
> + /* Check revision register scheme */
> + scheme = mvr>> OMAP_UART_MVR_SCHEME_SHIFT;
> +
> + switch (scheme) {
> + case 0: /* Legacy Scheme: OMAP2/3 */
> + /* MINOR_REV[0:4], MAJOR_REV[4:7] */
> + major = (mvr& OMAP_UART_LEGACY_MVR_MAJ_MASK)>>
> + OMAP_UART_LEGACY_MVR_MAJ_SHIFT;
> + minor = (mvr& OMAP_UART_LEGACY_MVR_MIN_MASK);
> + break;
> + case 1:
> + /* New Scheme: OMAP4+ */
> + /* MINOR_REV[0:5], MAJOR_REV[8:10] */
> + major = (mvr& OMAP_UART_MVR_MAJ_MASK)>>
> + OMAP_UART_MVR_MAJ_SHIFT;
> + minor = (mvr& OMAP_UART_MVR_MIN_MASK);
> + break;
> + default:
> + dev_warn(&up->pdev->dev,
> + "Unknown %s revision, defaulting to highest\n",
> + up->name);
> + /* highest possible revision */
> + major = 0xff;
> + minor = 0xff;
> + }
> +
> + /* normalize revision for the driver */
> + revision = UART_BUILD_REVISION(major, minor);
> +
> + switch (revision) {
> + case OMAP_UART_REV_46:
> + up->errata |= (UART_ERRATA_i202_MDR1_ACCESS |
> + UART_ERRATA_i291_DMA_FORCEIDLE);
> + break;
> + case OMAP_UART_REV_52:
> + up->errata |= (UART_ERRATA_i202_MDR1_ACCESS |
> + UART_ERRATA_i291_DMA_FORCEIDLE);
> + break;
> + case OMAP_UART_REV_63:
> + up->errata |= UART_ERRATA_i202_MDR1_ACCESS;
> + break;
> + default:
> + break;
> + }
> +}
> +
> static struct omap_uart_port_info *of_get_uart_port_info(struct device *dev)
> {
> struct omap_uart_port_info *omap_up_info;
> @@ -1443,7 +1514,6 @@ static int serial_omap_probe(struct platform_device *pdev)
> "%d\n", DEFAULT_CLK_SPEED);
> }
> up->uart_dma.uart_base = mem->start;
> - up->errata = omap_up_info->errata;
>
> if (omap_up_info->dma_enabled) {
> up->uart_dma.uart_dma_tx = dma_tx->start;
> @@ -1473,6 +1543,8 @@ static int serial_omap_probe(struct platform_device *pdev)
> pm_runtime_enable(&pdev->dev);
> pm_runtime_get_sync(&pdev->dev);
>
> + omap_serial_fill_features_erratas(up);
> +
> ui[up->port.line] = up;
> serial_omap_add_console_port(up);
>
Thanks!
Reviewed-by: Jon Hunter <jon-hunter@ti.com>
Cheers
Jon
^ permalink raw reply
* [PATCH] serial: samsung: fix omission initialize ulcon in reset port fn()
From: Kukjin Kim @ 2012-04-04 1:14 UTC (permalink / raw)
To: linux-serial, linux-samsung-soc; +Cc: gregkh, alan, Kukjin Kim
Fix omission initialize ulcon in s3c24xx_serial_resetport(),
reset port function in drivers/tty/serial/samsung.c. It has
been happened from commit 0dfb3b41("serial: samsung: merge
all SoC specific port reset functions")
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
---
drivers/tty/serial/samsung.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index de249d2..d8b0aee 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -982,6 +982,7 @@ static void s3c24xx_serial_resetport(struct uart_port *port,
ucon &= ucon_mask;
wr_regl(port, S3C2410_UCON, ucon | cfg->ucon);
+ wr_regl(port, S3C2410_ULCON, cfg->ulcon);
/* reset both fifos */
wr_regl(port, S3C2410_UFCON, cfg->ufcon | S3C2410_UFCON_RESETBOTH);
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH 1/2] 8250_pci: Replace commits 448ac154 and e86ff4a
From: Alan Cox @ 2012-04-03 20:58 UTC (permalink / raw)
To: sudhakar
Cc: linux-serial, alan, gregkh, dan.j.williams, nhan.h.mai,
linux-kernel
In-Reply-To: <4F7B52D8.101@fb.com>
On Tue, 3 Apr 2012 12:43:20 -0700
sudhakar <sudhakar@fb.com> wrote:
>
> From: Sudhakar Mamillapalli <sudhakar@fb.com>
>
>
> The following commits don't completely fix the KT serial missing
> interrupt problems. So they have been replaced instead by
> enabling serial backup timer. The iir-once + msi tried approach tried
> to enforce one read of the iir per THRE event, but its defeated by any
> other event occurring at the wrong time, particularly MSR events.
>
> 448ac15 serial/8250_pci: setup-quirk workaround for the kt serial controller
> e86ff4a serial/8250_pci: init-quirk msi support for kt serial controller
These are already in tree. If you are reversing them and adding a
different fix then please post the series as
- two revert patches exactly reverting the two commits
- a follow on patch or two adding the replacement
That makes it much easier to review and much more obvious. It also helps
make testing simpler.
Alan
^ permalink raw reply
* Re: [PATCH 1/2] 8250_pci: Replace commits 448ac154 and e86ff4a
From: Williams, Dan J @ 2012-04-03 20:09 UTC (permalink / raw)
To: sudhakar; +Cc: linux-serial, alan, gregkh, nhan.h.mai, linux-kernel
In-Reply-To: <4F7B52D8.101@fb.com>
On Tue, Apr 3, 2012 at 12:43 PM, sudhakar <sudhakar@fb.com> wrote:
>
> From: Sudhakar Mamillapalli <sudhakar@fb.com>
>
>
> The following commits don't completely fix the KT serial missing
> interrupt problems. So they have been replaced instead by
> enabling serial backup timer. The iir-once + msi tried approach tried
> to enforce one read of the iir per THRE event, but its defeated by any
> other event occurring at the wrong time, particularly MSR events.
>
> 448ac15 serial/8250_pci: setup-quirk workaround for the kt serial controller
> e86ff4a serial/8250_pci: init-quirk msi support for kt serial controller
>
> Signed-off-by: Sudhakar Mamillapalli <sudhakar@fb.com>
> Acked-by: Dan Williams <dan.j.williams@intel.com>
> Acked-by: Nhan H Mai <nhan.h.mai@intel.com>
Just a note that this should also be tagged for 3.3-stable since the
msi setup hack in e86ff4a breaks suspend/resume like this:
[ 365.250523] sysfs: cannot create duplicate filename
'/devices/pci0000:00/0000:00:16.3/msi_irqs'
--
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 2/2] serial/8250_pci: Need to clear FIFOs for KT serial on BI
From: Alan Cox @ 2012-04-03 20:03 UTC (permalink / raw)
To: sudhakar
Cc: linux-serial, alan, gregkh, dan.j.williams, nhan.h.mai,
linux-kernel
In-Reply-To: <4F7B53C9.4040509@fb.com>
On Tue, 3 Apr 2012 12:47:21 -0700
sudhakar <sudhakar@fb.com> wrote:
>
> From: Sudhakar Mamillapalli <sudhakar@fb.com>
>
> When using SOL thru a KT serial device and Intel ME gets reset
> the serial FIFOs need to be cleared for sane SOL output. On
Acronym failure.
Please remember that people looking at a patch and even more so people in
future maintaining the code will not have any idea wtf you are talking
about !
Expand the acronyms in a patch and include a bit of context.
> @@ -1385,6 +1393,16 @@ serial8250_rx_chars(struct uart_8250_port *up, unsigned char lsr)
> lsr |= up->lsr_saved_flags;
> up->lsr_saved_flags = 0;
>
> + if ((up->port.type == PORT_KT_SERIAL) && (lsr & UART_LSR_BI)) {
> + /*
> + * For KT serial device if break interrupt then got
> + * to clear the fifos for sane SOL output.
> + */
> + serial8250_clear_fifos(up);
> + fcr = uart_config[up->port.type].fcr;
> + serial_port_out(port, UART_FCR, fcr);
> + }
> +
This wants to be some kind of call back handled case not more stuff in
the core 8250.c which we are trying to drive all the special cases back
out of.
> if (unlikely(lsr & UART_LSR_BRK_ERROR_BITS)) {
> /*
> * For statistics only
> @@ -1729,7 +1747,12 @@ static void serial8250_backup_timeout(unsigned long data)
> * based handler.
> */
> if (up->port.irq) {
> - ier = serial_in(up, UART_IER);
> + /*
> + * Get the ier value from up->ier rather than reading the
> + * register, since some SOL uarts(for e.g. KT serial) it
> + * goes to 0 momentarily on BMC reset.
> + */
> + ier = up->ier;
> serial_out(up, UART_IER, 0);
Surely you do this fixup in your own private serial_in method as various
other chips do for all sorts of brain damage.
> }
>
> @@ -1896,8 +1919,12 @@ static void serial8250_put_poll_char(struct uart_port *port,
>
> /*
> * First save the IER then disable the interrupts
> + *
> + * Get the ier value from up->ier rather than reading the
> + * register, since some SOL uarts(for e.g. KT serial) it
> + * goes to 0 momentarily on BMC reset.
> */
> - ier = serial_port_in(port, UART_IER);
> + ier = up->ier;
> if (up->capabilities & UART_CAP_UUE)
Ditto
> serial_port_out(port, UART_IER, UART_IER_UUE);
> else
> @@ -2818,8 +2845,12 @@ serial8250_console_write(struct console *co, const char *s, unsigned int count)
>
> /*
> * First save the IER then disable the interrupts
> + *
> + * Get the ier value from up->ier rather than reading the
> + * register, since some SOL uarts(for e.g. KT serial) it
> + * goes to 0 momentarily on BMC reset.
> */
> - ier = serial_port_in(port, UART_IER);
> + ier = up->ier;
>
Ditto
In fact as far as I can see this boils down to
- a private serial_in method
- possibly adding a callback for special break handling. You may even be
able to hide that in serial_in methods, but its probably better
explicit.
Alan
^ permalink raw reply
* [PATCH 2/2] serial/8250_pci: Need to clear FIFOs for KT serial on BI
From: sudhakar @ 2012-04-03 19:47 UTC (permalink / raw)
To: linux-serial; +Cc: alan, gregkh, dan.j.williams, nhan.h.mai, linux-kernel
From: Sudhakar Mamillapalli <sudhakar@fb.com>
When using SOL thru a KT serial device and Intel ME gets reset
the serial FIFOs need to be cleared for sane SOL output. On
a reset the device assertes BI, so using that as a cue FIFOs
are cleared. One other problem is that the serial registers
might temporarily go to 0 on reset for this device. So
instead of restoring IER register from read value in
poll_char and other functions we get the value from
uart_8250_port which should have the same value.
Signed-off-by: Sudhakar Mamillapalli <sudhakar@fb.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Nhan H Mai <nhan.h.mai@intel.com>
---
drivers/tty/serial/8250/8250.c | 37 +++++++++++++++++++++++++++++++++--
drivers/tty/serial/8250/8250_pci.c | 3 +-
include/linux/serial_core.h | 3 +-
3 files changed, 38 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.c b/drivers/tty/serial/8250/8250.c
index 5fb0157..c61799e 100644
--- a/drivers/tty/serial/8250/8250.c
+++ b/drivers/tty/serial/8250/8250.c
@@ -282,6 +282,13 @@ static const struct serial8250_config uart_config[] = {
.fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
.flags = UART_CAP_FIFO | UART_CAP_AFE | UART_CAP_EFR,
},
+ [PORT_KT_SERIAL] = {
+ .name = "KTSERIAL",
+ .fifo_size = 16,
+ .tx_loadsz = 16,
+ .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10,
+ .flags = UART_CAP_FIFO,
+ },
};
#if defined(CONFIG_MIPS_ALCHEMY)
@@ -1363,6 +1370,7 @@ serial8250_rx_chars(struct uart_8250_port *up, unsigned char lsr)
struct uart_port *port = &up->port;
struct tty_struct *tty = port->state->port.tty;
unsigned char ch;
+ unsigned char fcr;
int max_count = 256;
char flag;
@@ -1385,6 +1393,16 @@ serial8250_rx_chars(struct uart_8250_port *up, unsigned char lsr)
lsr |= up->lsr_saved_flags;
up->lsr_saved_flags = 0;
+ if ((up->port.type == PORT_KT_SERIAL) && (lsr & UART_LSR_BI)) {
+ /*
+ * For KT serial device if break interrupt then got
+ * to clear the fifos for sane SOL output.
+ */
+ serial8250_clear_fifos(up);
+ fcr = uart_config[up->port.type].fcr;
+ serial_port_out(port, UART_FCR, fcr);
+ }
+
if (unlikely(lsr & UART_LSR_BRK_ERROR_BITS)) {
/*
* For statistics only
@@ -1729,7 +1747,12 @@ static void serial8250_backup_timeout(unsigned long data)
* based handler.
*/
if (up->port.irq) {
- ier = serial_in(up, UART_IER);
+ /*
+ * Get the ier value from up->ier rather than reading the
+ * register, since some SOL uarts(for e.g. KT serial) it
+ * goes to 0 momentarily on BMC reset.
+ */
+ ier = up->ier;
serial_out(up, UART_IER, 0);
}
@@ -1896,8 +1919,12 @@ static void serial8250_put_poll_char(struct uart_port *port,
/*
* First save the IER then disable the interrupts
+ *
+ * Get the ier value from up->ier rather than reading the
+ * register, since some SOL uarts(for e.g. KT serial) it
+ * goes to 0 momentarily on BMC reset.
*/
- ier = serial_port_in(port, UART_IER);
+ ier = up->ier;
if (up->capabilities & UART_CAP_UUE)
serial_port_out(port, UART_IER, UART_IER_UUE);
else
@@ -2818,8 +2845,12 @@ serial8250_console_write(struct console *co, const char *s, unsigned int count)
/*
* First save the IER then disable the interrupts
+ *
+ * Get the ier value from up->ier rather than reading the
+ * register, since some SOL uarts(for e.g. KT serial) it
+ * goes to 0 momentarily on BMC reset.
*/
- ier = serial_port_in(port, UART_IER);
+ ier = up->ier;
if (up->capabilities & UART_CAP_UUE)
serial_port_out(port, UART_IER, UART_IER_UUE);
diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
index 858dca8..1aebe63 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1096,7 +1096,8 @@ static int kt_serial_setup(struct serial_private *priv,
const struct pciserial_board *board,
struct uart_port *port, int idx)
{
- port->flags |= UPF_BUG_THRE;
+ port->flags |= UPF_BUG_THRE | UPF_FIXED_TYPE;
+ port->type = PORT_KT_SERIAL;
return skip_tx_en_setup(priv, board, port, idx);
}
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 2db407a..efd7d0d 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -47,7 +47,8 @@
#define PORT_U6_16550A 19 /* ST-Ericsson U6xxx internal UART */
#define PORT_TEGRA 20 /* NVIDIA Tegra internal UART */
#define PORT_XR17D15X 21 /* Exar XR17D15x UART */
-#define PORT_MAX_8250 21 /* max port ID */
+#define PORT_KT_SERIAL 22 /* KT Serial SOL device */
+#define PORT_MAX_8250 22 /* max port ID */
/*
* ARM specific type numbers. These are not currently guaranteed
--
1.7.8.4
^ permalink raw reply related
* [PATCH 1/2] 8250_pci: Replace commits 448ac154 and e86ff4a
From: sudhakar @ 2012-04-03 19:43 UTC (permalink / raw)
To: linux-serial; +Cc: alan, gregkh, dan.j.williams, nhan.h.mai, linux-kernel
From: Sudhakar Mamillapalli <sudhakar@fb.com>
The following commits don't completely fix the KT serial missing
interrupt problems. So they have been replaced instead by
enabling serial backup timer. The iir-once + msi tried approach tried
to enforce one read of the iir per THRE event, but its defeated by any
other event occurring at the wrong time, particularly MSR events.
448ac15 serial/8250_pci: setup-quirk workaround for the kt serial controller
e86ff4a serial/8250_pci: init-quirk msi support for kt serial controller
Signed-off-by: Sudhakar Mamillapalli <sudhakar@fb.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Nhan H Mai <nhan.h.mai@intel.com>
---
drivers/tty/serial/8250/8250.c | 12 ++++++------
drivers/tty/serial/8250/8250_pci.c | 16 +---------------
include/linux/serial_core.h | 2 +-
3 files changed, 8 insertions(+), 22 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.c b/drivers/tty/serial/8250/8250.c
index 5b149b4..5fb0157 100644
--- a/drivers/tty/serial/8250/8250.c
+++ b/drivers/tty/serial/8250/8250.c
@@ -1572,13 +1572,11 @@ static irqreturn_t serial8250_interrupt(int irq, void *dev_id)
do {
struct uart_8250_port *up;
struct uart_port *port;
- bool skip;
up = list_entry(l, struct uart_8250_port, list);
port = &up->port;
- skip = pass_counter && up->port.flags & UPF_IIR_ONCE;
- if (!skip && port->handle_irq(port)) {
+ if (port->handle_irq(port)) {
handled = 1;
end = NULL;
} else if (end == NULL)
@@ -2037,10 +2035,12 @@ static int serial8250_startup(struct uart_port *port)
spin_unlock_irqrestore(&port->lock, flags);
/*
- * If the interrupt is not reasserted, setup a timer to
- * kick the UART on a regular basis.
+ * If the interrupt is not reasserted, or we otherwise
+ * don't trust the iir, setup a timer to kick the UART
+ * on a regular basis.
*/
- if (!(iir1 & UART_IIR_NO_INT) && (iir & UART_IIR_NO_INT)) {
+ if ((!(iir1 & UART_IIR_NO_INT) && (iir & UART_IIR_NO_INT)) ||
+ up->port.flags & UPF_BUG_THRE) {
up->bugs |= UART_BUG_THRE;
pr_debug("ttyS%d - using backup timer\n",
serial_index(port));
diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
index da2b0b0..858dca8 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1096,7 +1096,7 @@ static int kt_serial_setup(struct serial_private *priv,
const struct pciserial_board *board,
struct uart_port *port, int idx)
{
- port->flags |= UPF_IIR_ONCE;
+ port->flags |= UPF_BUG_THRE;
return skip_tx_en_setup(priv, board, port, idx);
}
@@ -1118,18 +1118,6 @@ pci_xr17c154_setup(struct serial_private *priv,
return pci_default_setup(priv, board, port, idx);
}
-static int try_enable_msi(struct pci_dev *dev)
-{
- /* use msi if available, but fallback to legacy otherwise */
- pci_enable_msi(dev);
- return 0;
-}
-
-static void disable_msi(struct pci_dev *dev)
-{
- pci_disable_msi(dev);
-}
-
#define PCI_VENDOR_ID_SBSMODULARIO 0x124B
#define PCI_SUBVENDOR_ID_SBSMODULARIO 0x124B
#define PCI_DEVICE_ID_OCTPRO 0x0001
@@ -1249,9 +1237,7 @@ static struct pci_serial_quirk pci_serial_quirks[] __refdata = {
.device = PCI_DEVICE_ID_INTEL_PATSBURG_KT,
.subvendor = PCI_ANY_ID,
.subdevice = PCI_ANY_ID,
- .init = try_enable_msi,
.setup = kt_serial_setup,
- .exit = disable_msi,
},
/*
* ITE
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index f51bf2e..2db407a 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -357,7 +357,7 @@ struct uart_port {
#define UPF_CONS_FLOW ((__force upf_t) (1 << 23))
#define UPF_SHARE_IRQ ((__force upf_t) (1 << 24))
#define UPF_EXAR_EFR ((__force upf_t) (1 << 25))
-#define UPF_IIR_ONCE ((__force upf_t) (1 << 26))
+#define UPF_BUG_THRE ((__force upf_t) (1 << 26))
/* The exact UART type is known and should not be probed. */
#define UPF_FIXED_TYPE ((__force upf_t) (1 << 27))
#define UPF_BOOT_AUTOCONF ((__force upf_t) (1 << 28))
--
1.7.8.4
^ permalink raw reply related
* Re: [PATCH] serial: PL011: move interrupt clearing
From: Greg Kroah-Hartman @ 2012-04-03 16:19 UTC (permalink / raw)
To: Paul Gortmaker
Cc: Grant Likely, Linus Walleij, linux-serial, Russell King,
Jong-Sung Kim, stable, Chanho Min, linux-arm-kernel,
Shreshtha Kumar Sahu
In-Reply-To: <CAP=VYLrbZNxYWT-TQt6SzXc3OpYnFVgiQqW-2pM+9V=z4LREow@mail.gmail.com>
On Tue, Apr 03, 2012 at 11:36:23AM -0400, Paul Gortmaker wrote:
> On Thu, Mar 29, 2012 at 5:33 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Thu, Mar 29, 2012 at 02:49:37PM -0600, Grant Likely wrote:
> >> On Wed, Mar 21, 2012 at 1:15 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> >> > Commit 360f748b204275229f8398cb2f9f53955db1503b
> >> > "serial: PL011: clear pending interrupts"
> >> > attempts to clear interrupts by writing to a
> >> > yet-unassigned memory address. This fixes the issue.
> >> >
> >> > The breaking patch is marked for stable so should be
> >> > carried along with the other patch.
> >> >
> >> > Cc: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
> >> > Cc: Russell King <linux@arm.linux.org.uk>
> >> > Cc: stable <stable@vger.kernel.org>
> >> > Reported-by: Viresh Kumar <viresh.kumar@st.com>
> >> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> >>
> >> Ugh; the original patch is obviously broken. How did it get applied
> >> without testing?
> >>
> >> Greg, can you get this out to Linus ASAP please? I have one comment
> >> below, but I don't think it should block merging this patch.
> >>
> >> Tested-by: Grant Likely <grant.likely@secretlab.ca>
> >
> > Thanks, I'll get it to him after 3.4-rc1 is out, in a few days, along
> > with other tty fixes being queued up.
>
> Hi Greg,
>
> Just wanted to check this didn't fall through the cracks, as I don't
> see it in your tty-next or tty-linus branches.
>
> The original bad commit causes Silent Boot Death on qemu ARM
> versatile, which is kind of nasty. It pretty much forces a bisection,
> which I did, which then led me here.
It's still in my "to-apply" queue, don't worry, it's not lost.
greg k-h
--
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] serial: PL011: move interrupt clearing
From: Paul Gortmaker @ 2012-04-03 15:36 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Grant Likely, Linus Walleij, linux-serial, Russell King,
Jong-Sung Kim, stable, Chanho Min, linux-arm-kernel,
Shreshtha Kumar Sahu
In-Reply-To: <20120329213333.GA15231@kroah.com>
On Thu, Mar 29, 2012 at 5:33 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Thu, Mar 29, 2012 at 02:49:37PM -0600, Grant Likely wrote:
>> On Wed, Mar 21, 2012 at 1:15 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> > Commit 360f748b204275229f8398cb2f9f53955db1503b
>> > "serial: PL011: clear pending interrupts"
>> > attempts to clear interrupts by writing to a
>> > yet-unassigned memory address. This fixes the issue.
>> >
>> > The breaking patch is marked for stable so should be
>> > carried along with the other patch.
>> >
>> > Cc: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
>> > Cc: Russell King <linux@arm.linux.org.uk>
>> > Cc: stable <stable@vger.kernel.org>
>> > Reported-by: Viresh Kumar <viresh.kumar@st.com>
>> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>>
>> Ugh; the original patch is obviously broken. How did it get applied
>> without testing?
>>
>> Greg, can you get this out to Linus ASAP please? I have one comment
>> below, but I don't think it should block merging this patch.
>>
>> Tested-by: Grant Likely <grant.likely@secretlab.ca>
>
> Thanks, I'll get it to him after 3.4-rc1 is out, in a few days, along
> with other tty fixes being queued up.
Hi Greg,
Just wanted to check this didn't fall through the cracks, as I don't
see it in your tty-next or tty-linus branches.
The original bad commit causes Silent Boot Death on qemu ARM
versatile, which is kind of nasty. It pretty much forces a bisection,
which I did, which then led me here.
Thanks,
Paul.
--
>
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-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
* [PATCH v3] OMAP2+: UART: Remove cpu checks for populating errata flags
From: Govindraj.R @ 2012-04-03 13:42 UTC (permalink / raw)
To: linux-omap
Cc: linux-serial, linux-arm-kernel, Govindraj.R, Jon Hunter,
Paul Walmsley, Kevin Hilman, Felipe Balbi
In-Reply-To: <1333356489-5816-1-git-send-email-govindraj.raja@ti.com>
From: "Govindraj.R" <govindraj.raja@ti.com>
Currently the errata is populated based on cpu checks this can
be removed and replaced with module version check of uart ip block.
MVR reg is provided within the uart reg map use the same
to populate the errata and thus now errata population and handling
can be managed within the driver itself.
Cc: Jon Hunter <jon-hunter@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Govindraj.R <govindraj.raja@ti.com>
---
arch/arm/mach-omap2/serial.c | 8 ---
arch/arm/plat-omap/include/plat/omap-serial.h | 1 -
drivers/tty/serial/omap-serial.c | 74 ++++++++++++++++++++++++-
3 files changed, 73 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0cdd359..6affdd4 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -355,14 +355,6 @@ void __init omap_serial_init_port(struct omap_board_data *bdata,
omap_up.dma_rx_poll_rate = info->dma_rx_poll_rate;
omap_up.autosuspend_timeout = info->autosuspend_timeout;
- /* Enable the MDR1 Errata i202 for OMAP2430/3xxx/44xx */
- if (!cpu_is_omap2420() && !cpu_is_ti816x())
- omap_up.errata |= UART_ERRATA_i202_MDR1_ACCESS;
-
- /* Enable DMA Mode Force Idle Errata i291 for omap34xx/3630 */
- if (cpu_is_omap34xx() || cpu_is_omap3630())
- omap_up.errata |= UART_ERRATA_i291_DMA_FORCEIDLE;
-
pdata = &omap_up;
pdata_size = sizeof(struct omap_uart_port_info);
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h
index 9ff4444..1a52725 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -65,7 +65,6 @@ struct omap_uart_port_info {
bool dma_enabled; /* To specify DMA Mode */
unsigned int uartclk; /* UART clock rate */
upf_t flags; /* UPF_* flags */
- u32 errata;
unsigned int dma_rx_buf_size;
unsigned int dma_rx_timeout;
unsigned int autosuspend_timeout;
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 0121486..0555c96 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -44,6 +44,13 @@
#include <plat/dmtimer.h>
#include <plat/omap-serial.h>
+#define UART_BUILD_REVISION(x, y) (((x) << 8) | (y))
+
+#define OMAP_UART_REV_42 0x0402
+#define OMAP_UART_REV_46 0x0406
+#define OMAP_UART_REV_52 0x0502
+#define OMAP_UART_REV_63 0x0603
+
#define DEFAULT_CLK_SPEED 48000000 /* 48Mhz*/
/* SCR register bitmasks */
@@ -53,6 +60,17 @@
#define OMAP_UART_FCR_RX_FIFO_TRIG_SHIFT 6
#define OMAP_UART_FCR_RX_FIFO_TRIG_MASK (0x3 << 6)
+/* MVR register bitmasks */
+#define OMAP_UART_MVR_SCHEME_SHIFT 30
+
+#define OMAP_UART_LEGACY_MVR_MAJ_MASK 0xf0
+#define OMAP_UART_LEGACY_MVR_MAJ_SHIFT 4
+#define OMAP_UART_LEGACY_MVR_MIN_MASK 0x0f
+
+#define OMAP_UART_MVR_MAJ_MASK 0x700
+#define OMAP_UART_MVR_MAJ_SHIFT 8
+#define OMAP_UART_MVR_MIN_MASK 0x3f
+
static struct uart_omap_port *ui[OMAP_MAX_HSUART_PORTS];
/* Forward declaration of functions */
@@ -1346,6 +1364,59 @@ static void uart_tx_dma_callback(int lch, u16 ch_status, void *data)
return;
}
+static void omap_serial_fill_features_erratas(struct uart_omap_port *up)
+{
+ u32 mvr, scheme;
+ u16 revision, major, minor;
+
+ mvr = serial_in(up, UART_OMAP_MVER);
+
+ /* Check revision register scheme */
+ scheme = mvr >> OMAP_UART_MVR_SCHEME_SHIFT;
+
+ switch (scheme) {
+ case 0: /* Legacy Scheme: OMAP2/3 */
+ /* MINOR_REV[0:4], MAJOR_REV[4:7] */
+ major = (mvr & OMAP_UART_LEGACY_MVR_MAJ_MASK) >>
+ OMAP_UART_LEGACY_MVR_MAJ_SHIFT;
+ minor = (mvr & OMAP_UART_LEGACY_MVR_MIN_MASK);
+ break;
+ case 1:
+ /* New Scheme: OMAP4+ */
+ /* MINOR_REV[0:5], MAJOR_REV[8:10] */
+ major = (mvr & OMAP_UART_MVR_MAJ_MASK) >>
+ OMAP_UART_MVR_MAJ_SHIFT;
+ minor = (mvr & OMAP_UART_MVR_MIN_MASK);
+ break;
+ default:
+ dev_warn(&up->pdev->dev,
+ "Unknown %s revision, defaulting to highest\n",
+ up->name);
+ /* highest possible revision */
+ major = 0xff;
+ minor = 0xff;
+ }
+
+ /* normalize revision for the driver */
+ revision = UART_BUILD_REVISION(major, minor);
+
+ switch (revision) {
+ case OMAP_UART_REV_46:
+ up->errata |= (UART_ERRATA_i202_MDR1_ACCESS |
+ UART_ERRATA_i291_DMA_FORCEIDLE);
+ break;
+ case OMAP_UART_REV_52:
+ up->errata |= (UART_ERRATA_i202_MDR1_ACCESS |
+ UART_ERRATA_i291_DMA_FORCEIDLE);
+ break;
+ case OMAP_UART_REV_63:
+ up->errata |= UART_ERRATA_i202_MDR1_ACCESS;
+ break;
+ default:
+ break;
+ }
+}
+
static struct omap_uart_port_info *of_get_uart_port_info(struct device *dev)
{
struct omap_uart_port_info *omap_up_info;
@@ -1443,7 +1514,6 @@ static int serial_omap_probe(struct platform_device *pdev)
"%d\n", DEFAULT_CLK_SPEED);
}
up->uart_dma.uart_base = mem->start;
- up->errata = omap_up_info->errata;
if (omap_up_info->dma_enabled) {
up->uart_dma.uart_dma_tx = dma_tx->start;
@@ -1473,6 +1543,8 @@ static int serial_omap_probe(struct platform_device *pdev)
pm_runtime_enable(&pdev->dev);
pm_runtime_get_sync(&pdev->dev);
+ omap_serial_fill_features_erratas(up);
+
ui[up->port.line] = up;
serial_omap_add_console_port(up);
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] serial: 8250: Add cpufreq support
From: Alan Cox @ 2012-04-03 9:55 UTC (permalink / raw)
To: Shankarmurthy, Akshay
Cc: linux-serial, alan, gregkh, paul.gortmaker, jamie, swarren,
dianders, davinci-linux-open-source, linux-kernel, Chaithrika U S
In-Reply-To: <1333433022-5455-1-git-send-email-akshay.s@ti.com>
> This patch was submitted 2 years ago but didn't make it to the mainline. Now i am reposting it.
Can you fix it instead of just reposting it ?
> +#ifdef CONFIG_CPU_FREQ
> +static int serial8250_cpufreq_transition(struct notifier_block *nb,
> + unsigned long val, void *data)
> +{
> + struct uart_8250_port *p;
> + struct uart_port *uport;
What is your locking model ?
> +static inline void serial8250_cpufreq_deregister(struct uart_8250_port *p)
unregister
> + ret = serial8250_cpufreq_register(uart);
> + if (ret < 0)
> + printk(KERN_ERR "Failed to add cpufreq notifier\n");
Why do this for devices that don't care.
Alan
^ permalink raw reply
* [PATCH] serial: 8250: Add cpufreq support
From: Shankarmurthy, Akshay @ 2012-04-03 6:03 UTC (permalink / raw)
To: linux-serial
Cc: alan, gregkh, paul.gortmaker, jamie, swarren, dianders,
davinci-linux-open-source, linux-kernel, akshay.s, Chaithrika U S
From: Chaithrika U S <chaithrika@ti.com>
On DA850/OMAP-L138 SoC, the PLL which supplies the clock to CPU also
feeds the UART and the UART input frequency can change when the CPU
frequency is scaled.
This patch adds cpufreq support for 8250 serial driver. A clk structure
member has been added to the platform and port data structures.This
member is used by the cpufreq notifier callback to get the updated
clock rate. The implementation is based on the cpufreq implementation
for Samsung serial driver.
Tested on TI DA850/OMAP-L138 EVM.
Signed-off-by: Chaithrika U S <chaithrika@ti.com>
Signed-off-by: Shankarmurthy, Akshay <akshay.s@ti.com>
---
This patch was submitted 2 years ago but didn't make it to the mainline. Now i am reposting it.
drivers/tty/serial/8250/8250.c | 74 ++++++++++++++++++++++++++++++++++++++++
drivers/tty/serial/8250/8250.h | 5 +++
include/linux/serial_8250.h | 1 +
3 files changed, 80 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.c b/drivers/tty/serial/8250/8250.c
index 9b7336f..b7cfe6c 100644
--- a/drivers/tty/serial/8250/8250.c
+++ b/drivers/tty/serial/8250/8250.c
@@ -38,6 +38,8 @@
#include <linux/nmi.h>
#include <linux/mutex.h>
#include <linux/slab.h>
+#include <linux/cpufreq.h>
+#include <linux/clk.h>
#include <asm/io.h>
#include <asm/irq.h>
@@ -3015,6 +3017,70 @@ void serial8250_resume_port(int line)
uart_resume_port(&serial8250_reg, &up->port);
}
+#ifdef CONFIG_CPU_FREQ
+static int serial8250_cpufreq_transition(struct notifier_block *nb,
+ unsigned long val, void *data)
+{
+ struct uart_8250_port *p;
+ struct uart_port *uport;
+
+ p = container_of(nb, struct uart_8250_port, freq_transition);
+ uport = &p->port;
+
+ if (IS_ERR(p->clk))
+ goto cpu_freq_exit;
+
+ if (p->port.uartclk == clk_get_rate(p->clk))
+ goto cpu_freq_exit;
+
+ p->port.uartclk = clk_get_rate(p->clk);
+ if (val == CPUFREQ_POSTCHANGE) {
+ struct ktermios *termios;
+ struct tty_struct *tty;
+ if (uport->state == NULL)
+ goto cpu_freq_exit;
+
+ tty = uport->state->port.tty;
+ if (tty == NULL)
+ goto cpu_freq_exit;
+
+ termios = tty->termios;
+ if (termios == NULL) {
+ printk(KERN_WARNING "%s: no termios?\n", __func__);
+ goto cpu_freq_exit;
+ }
+
+ serial8250_set_termios(uport, termios, NULL);
+ }
+
+cpu_freq_exit:
+ return 0;
+}
+
+static inline int serial8250_cpufreq_register(struct uart_8250_port *p)
+{
+ p->freq_transition.notifier_call = serial8250_cpufreq_transition;
+
+ return cpufreq_register_notifier(&p->freq_transition,
+ CPUFREQ_TRANSITION_NOTIFIER);
+}
+
+static inline void serial8250_cpufreq_deregister(struct uart_8250_port *p)
+{
+ cpufreq_unregister_notifier(&p->freq_transition,
+ CPUFREQ_TRANSITION_NOTIFIER);
+}
+#else
+static inline int serial8250_cpufreq_register(struct uart_8250_port *p)
+{
+ return 0;
+}
+
+static inline void serial8250_cpufreq_deregister(struct uart_8250_port *p)
+{
+}
+#endif
+
/*
* Register a set of serial devices attached to a platform device. The
* list is terminated with a zero flags entry, which means we expect
@@ -3051,6 +3117,9 @@ static int __devinit serial8250_probe(struct platform_device *dev)
port.pm = p->pm;
port.dev = &dev->dev;
port.irqflags |= irqflag;
+ if (p->clk)
+ serial8250_ports[i].clk = p->clk;
+
ret = serial8250_register_port(&port);
if (ret < 0) {
dev_err(&dev->dev, "unable to register port at index %d "
@@ -3227,6 +3296,10 @@ int serial8250_register_port(struct uart_port *port)
ret = uart_add_one_port(&serial8250_reg, &uart->port);
if (ret == 0)
ret = uart->port.line;
+
+ ret = serial8250_cpufreq_register(uart);
+ if (ret < 0)
+ printk(KERN_ERR "Failed to add cpufreq notifier\n");
}
mutex_unlock(&serial_mutex);
@@ -3246,6 +3319,7 @@ void serial8250_unregister_port(int line)
struct uart_8250_port *uart = &serial8250_ports[line];
mutex_lock(&serial_mutex);
+ serial8250_cpufreq_deregister(uart);
uart_remove_one_port(&serial8250_reg, &uart->port);
if (serial8250_isa_devs) {
uart->port.flags &= ~UPF_BOOT_AUTOCONF;
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index ae027be..be05a03 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -37,6 +37,11 @@ struct uart_8250_port {
unsigned char lsr_saved_flags;
#define MSR_SAVE_FLAGS UART_MSR_ANY_DELTA
unsigned char msr_saved_flags;
+ struct clk *clk;
+#ifdef CONFIG_CPU_FREQ
+ struct notifier_block freq_transition;
+#endif
+
};
struct old_serial_port {
diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
index 8f012f8..c2e1ce5 100644
--- a/include/linux/serial_8250.h
+++ b/include/linux/serial_8250.h
@@ -23,6 +23,7 @@ struct plat_serial8250_port {
resource_size_t mapbase; /* resource base */
unsigned int irq; /* interrupt number */
unsigned long irqflags; /* request_irq flags */
+ struct clk *clk;
unsigned int uartclk; /* UART clock rate */
void *private_data;
unsigned char regshift; /* register shift */
--
1.7.1
^ permalink raw reply related
* [PATCH 5/9] tty/serial/omap: console can only be built-in
From: mathieu.poirier @ 2012-04-02 22:32 UTC (permalink / raw)
To: linux-serial; +Cc: arnd, tony
From: Arnd Bergmann <arnd@arndb.de>
When the omap serial driver is built as a module, we must
not allow the console driver to be selected, because consoles
can not be loadable modules.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Acked-by: Govindraj.R <govindraj.raja@ti.com>
---
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..bcf7e24 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1041,7 +1041,7 @@ config SERIAL_OMAP
config SERIAL_OMAP_CONSOLE
bool "Console on OMAP serial port"
- depends on SERIAL_OMAP
+ depends on SERIAL_OMAP=y
select SERIAL_CORE_CONSOLE
help
Select this option if you would like to use omap serial port as
--
1.7.5.4
^ permalink raw reply related
* [PATCH] pch_uart: Fix MSI setting issue
From: Tomoya MORINAGA @ 2012-04-02 5:36 UTC (permalink / raw)
To: Alan Cox, Greg Kroah-Hartman, linux-serial, linux-kernel
Cc: qi.wang, yong.y.wang, joel.clark, kok.howg.ewe, Tomoya MORINAGA,
Alexander Stein
The following patch (MSI setting) is not enough.
commit e463595fd9c752fa4bf06b47df93ef9ade3c7cf0
Author: Alexander Stein <alexander.stein@systec-electronic.com>
Date: Mon Jul 4 08:58:31 2011 +0200
pch_uart: Add MSI support
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
To enable MSI mode, PCI bus-mastering must be enabled.
This patch enables the setting.
cc: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
---
drivers/tty/serial/pch_uart.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/pch_uart.c b/drivers/tty/serial/pch_uart.c
index 5928877..ae8f848 100644
--- a/drivers/tty/serial/pch_uart.c
+++ b/drivers/tty/serial/pch_uart.c
@@ -1586,6 +1586,7 @@ static struct eg20t_port *pch_uart_init_port(struct pci_dev *pdev,
}
pci_enable_msi(pdev);
+ pci_set_master(pdev);
iobase = pci_resource_start(pdev, 0);
mapbase = pci_resource_start(pdev, 1);
--
1.7.7.6
^ permalink raw reply related
* Re: [PATCH] tty: serial: altera_uart: Check for NULL platform_data in probe.
From: Tobias Klauser @ 2012-03-30 6:32 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Yuriy Kozlov, Alan Cox, linux-serial
In-Reply-To: <20120329213957.GC15231@kroah.com>
On 2012-03-29 at 23:39:57 +0200, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Thu, Mar 29, 2012 at 04:02:07PM -0400, Yuriy Kozlov wrote:
> > On Thursday, March 29, 2012 12:47:11 Greg Kroah-Hartman wrote:
> > > On Thu, Mar 29, 2012 at 09:38:55PM +0200, Tobias Klauser wrote:
> > > > On 2012-03-29 at 18:13:37 +0200, Greg Kroah-Hartman
> > <gregkh@linuxfoundation.org> wrote:
> > > > > On Thu, Mar 29, 2012 at 09:55:27AM +0200, Tobias Klauser wrote:
> > > > > > From: Yuriy Kozlov <ykozlov@ptcusa.com>
> > > > > >
> > > > > > Follow altera_jtag_uart. This fixes a crash if there is a mistake in
> > > > > > the DTS.> >
> > > > > Is this something you have seen in the wild? Is this something to be
> > > > > backported to stable kernels?
> > > >
> > > > Not that I know of. But nevertheless it might be worthwhile. Shall I
> > > > send the patch again with Cc: stable@kernel.org?
> > >
> > > Nope, I can add it.
> > >
> > > But, if this isn't something that you have seen, why is it needed to be
> > > checked for? What is this making work properly that isn't working
> > > properly now?
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > The driver is designed to use Device Tree to get hardware information, so
> > platp (platform_data) is usually NULL. platform_data is still used as a
> > fallback mechanism. The problem arises when the device is in the DT, but is
> > missing a required property (address or irq). The driver falls back to
> > looking for it in the null platp and panics. The function actually already
> > checks platp for other properties later on, but under this condition it tried
> > to dereference it before the null checks.
>
> And again, does this happen today in the 3.4-rc1 kernel? 3.3? 3.2?
> 3.0? Something else?
It's present in all of them, since 2.6.37 when devicetree support for
the driver was added. So it could potentially be triggered in all of
them.
> If not, then why make this change? If so, it needs to go to older
> kernels, right?
If Yuriy has seen this in the wild, I'd suggest it should got in then.
Please let me know if I should redo the patch against the older version.
Thanks a lot
Tobias
^ permalink raw reply
* Re: [PATCH] tty: serial: altera_uart: Check for NULL platform_data in probe.
From: Greg Kroah-Hartman @ 2012-03-29 21:39 UTC (permalink / raw)
To: Yuriy Kozlov; +Cc: Tobias Klauser, Alan Cox, linux-serial
In-Reply-To: <2271072.B4UpndiPVz@hyrum>
On Thu, Mar 29, 2012 at 04:02:07PM -0400, Yuriy Kozlov wrote:
> On Thursday, March 29, 2012 12:47:11 Greg Kroah-Hartman wrote:
> > On Thu, Mar 29, 2012 at 09:38:55PM +0200, Tobias Klauser wrote:
> > > On 2012-03-29 at 18:13:37 +0200, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > > > On Thu, Mar 29, 2012 at 09:55:27AM +0200, Tobias Klauser wrote:
> > > > > From: Yuriy Kozlov <ykozlov@ptcusa.com>
> > > > >
> > > > > Follow altera_jtag_uart. This fixes a crash if there is a mistake in
> > > > > the DTS.> >
> > > > Is this something you have seen in the wild? Is this something to be
> > > > backported to stable kernels?
> > >
> > > Not that I know of. But nevertheless it might be worthwhile. Shall I
> > > send the patch again with Cc: stable@kernel.org?
> >
> > Nope, I can add it.
> >
> > But, if this isn't something that you have seen, why is it needed to be
> > checked for? What is this making work properly that isn't working
> > properly now?
> >
> > thanks,
> >
> > greg k-h
>
> The driver is designed to use Device Tree to get hardware information, so
> platp (platform_data) is usually NULL. platform_data is still used as a
> fallback mechanism. The problem arises when the device is in the DT, but is
> missing a required property (address or irq). The driver falls back to
> looking for it in the null platp and panics. The function actually already
> checks platp for other properties later on, but under this condition it tried
> to dereference it before the null checks.
And again, does this happen today in the 3.4-rc1 kernel? 3.3? 3.2?
3.0? Something else?
If not, then why make this change? If so, it needs to go to older
kernels, right?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] serial: PL011: move interrupt clearing
From: Greg Kroah-Hartman @ 2012-03-29 21:33 UTC (permalink / raw)
To: Grant Likely
Cc: Linus Walleij, linux-serial, Russell King, Jong-Sung Kim, stable,
Chanho Min, linux-arm-kernel, Shreshtha Kumar Sahu
In-Reply-To: <CACxGe6u+KeYzWwiJ7MK7pWG444Y99CQ1LLCZP4m3R=zdYFR_pg@mail.gmail.com>
On Thu, Mar 29, 2012 at 02:49:37PM -0600, Grant Likely wrote:
> On Wed, Mar 21, 2012 at 1:15 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> > Commit 360f748b204275229f8398cb2f9f53955db1503b
> > "serial: PL011: clear pending interrupts"
> > attempts to clear interrupts by writing to a
> > yet-unassigned memory address. This fixes the issue.
> >
> > The breaking patch is marked for stable so should be
> > carried along with the other patch.
> >
> > Cc: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
> > Cc: Russell King <linux@arm.linux.org.uk>
> > Cc: stable <stable@vger.kernel.org>
> > Reported-by: Viresh Kumar <viresh.kumar@st.com>
> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>
> Ugh; the original patch is obviously broken. How did it get applied
> without testing?
>
> Greg, can you get this out to Linus ASAP please? I have one comment
> below, but I don't think it should block merging this patch.
>
> Tested-by: Grant Likely <grant.likely@secretlab.ca>
Thanks, I'll get it to him after 3.4-rc1 is out, in a few days, along
with other tty fixes being queued up.
greg k-h
^ permalink raw reply
* Re: [PATCH] serial: PL011: move interrupt clearing
From: Linus Walleij @ 2012-03-29 21:22 UTC (permalink / raw)
To: Grant Likely
Cc: linux-serial, Greg Kroah-Hartman, Russell King, Jong-Sung Kim,
stable, Chanho Min, linux-arm-kernel, Shreshtha Kumar Sahu
In-Reply-To: <CACxGe6u+KeYzWwiJ7MK7pWG444Y99CQ1LLCZP4m3R=zdYFR_pg@mail.gmail.com>
On Thu, Mar 29, 2012 at 10:49 PM, Grant Likely
<grant.likely@secretlab.ca> wrote:
>> Commit 360f748b204275229f8398cb2f9f53955db1503b
>> "serial: PL011: clear pending interrupts"
>> attempts to clear interrupts by writing to a
>> yet-unassigned memory address. This fixes the issue.
>
> Ugh; the original patch is obviously broken. How did it get applied
> without testing?
I've felt bad about that for a while, but to the best of my knowledge I did
test it. Either I did some manual slip with the boot images or there was
something else causing it to actually work as it looked... Chanho also
had it working IIRC.
> Greg, can you get this out to Linus ASAP please? I have one comment
> below, but I don't think it should block merging this patch.
>
> Tested-by: Grant Likely <grant.likely@secretlab.ca>
Thanks.
>> - /* Ensure interrupts from this UART are masked and cleared */
>> - writew(0, uap->port.membase + UART011_IMSC);
>> - writew(0xffff, uap->port.membase + UART011_ICR);
>> -
>> uap->vendor = vendor;
>> uap->lcrh_rx = vendor->lcrh_rx;
>> uap->lcrh_tx = vendor->lcrh_tx;
>> @@ -1951,6 +1947,10 @@ static int pl011_probe(struct amba_device *dev, const struct amba_id *id)
>> uap->port.line = i;
>> pl011_dma_probe(uap);
>>
>> + /* Ensure interrupts from this UART are masked and cleared */
>> + writew(0, uap->port.membase + UART011_IMSC);
>> + writew(0xffff, uap->port.membase + UART011_ICR);
>> +
>
> Is it correct to move the interrupt clearing below the
> pl011_dma_probe() call? I've tested the fix with the interrupt
> clearing both above and below the pl011_dma_probe() call and versatile
> qemu boots in both cases.
pl011_dma_probe() basically just make logical setup so we do the
clear-out as the last step of setup.
Yours,
Linus Walleij
--
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] tty: serial: altera_uart: Check for NULL platform_data in probe.
From: Yuriy Kozlov @ 2012-03-29 20:02 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Tobias Klauser, Alan Cox, linux-serial
In-Reply-To: <20120329194711.GB12194@kroah.com>
On Thursday, March 29, 2012 12:47:11 Greg Kroah-Hartman wrote:
> On Thu, Mar 29, 2012 at 09:38:55PM +0200, Tobias Klauser wrote:
> > On 2012-03-29 at 18:13:37 +0200, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> > > On Thu, Mar 29, 2012 at 09:55:27AM +0200, Tobias Klauser wrote:
> > > > From: Yuriy Kozlov <ykozlov@ptcusa.com>
> > > >
> > > > Follow altera_jtag_uart. This fixes a crash if there is a mistake in
> > > > the DTS.> >
> > > Is this something you have seen in the wild? Is this something to be
> > > backported to stable kernels?
> >
> > Not that I know of. But nevertheless it might be worthwhile. Shall I
> > send the patch again with Cc: stable@kernel.org?
>
> Nope, I can add it.
>
> But, if this isn't something that you have seen, why is it needed to be
> checked for? What is this making work properly that isn't working
> properly now?
>
> thanks,
>
> greg k-h
The driver is designed to use Device Tree to get hardware information, so
platp (platform_data) is usually NULL. platform_data is still used as a
fallback mechanism. The problem arises when the device is in the DT, but is
missing a required property (address or irq). The driver falls back to
looking for it in the null platp and panics. The function actually already
checks platp for other properties later on, but under this condition it tried
to dereference it before the null checks.
--
~ Yuriy Kozlov
Pyramid Technical Consultants, Inc.
---------------------------------------------------------
^ permalink raw reply
* Re: [PATCH] serial: PL011: move interrupt clearing
From: Grant Likely @ 2012-03-29 20:49 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-serial, Greg Kroah-Hartman, Russell King, Jong-Sung Kim,
stable, Chanho Min, linux-arm-kernel, Shreshtha Kumar Sahu
In-Reply-To: <1332357318-8017-1-git-send-email-linus.walleij@linaro.org>
On Wed, Mar 21, 2012 at 1:15 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> Commit 360f748b204275229f8398cb2f9f53955db1503b
> "serial: PL011: clear pending interrupts"
> attempts to clear interrupts by writing to a
> yet-unassigned memory address. This fixes the issue.
>
> The breaking patch is marked for stable so should be
> carried along with the other patch.
>
> Cc: Shreshtha Kumar Sahu <shreshthakumar.sahu@stericsson.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: stable <stable@vger.kernel.org>
> Reported-by: Viresh Kumar <viresh.kumar@st.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Ugh; the original patch is obviously broken. How did it get applied
without testing?
Greg, can you get this out to Linus ASAP please? I have one comment
below, but I don't think it should block merging this patch.
Tested-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> drivers/tty/serial/amba-pl011.c | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
> index 7e01399..4ed35c5 100644
> --- a/drivers/tty/serial/amba-pl011.c
> +++ b/drivers/tty/serial/amba-pl011.c
> @@ -1930,10 +1930,6 @@ static int pl011_probe(struct amba_device *dev, const struct amba_id *id)
> goto unmap;
> }
>
> - /* Ensure interrupts from this UART are masked and cleared */
> - writew(0, uap->port.membase + UART011_IMSC);
> - writew(0xffff, uap->port.membase + UART011_ICR);
> -
> uap->vendor = vendor;
> uap->lcrh_rx = vendor->lcrh_rx;
> uap->lcrh_tx = vendor->lcrh_tx;
> @@ -1951,6 +1947,10 @@ static int pl011_probe(struct amba_device *dev, const struct amba_id *id)
> uap->port.line = i;
> pl011_dma_probe(uap);
>
> + /* Ensure interrupts from this UART are masked and cleared */
> + writew(0, uap->port.membase + UART011_IMSC);
> + writew(0xffff, uap->port.membase + UART011_ICR);
> +
Is it correct to move the interrupt clearing below the
pl011_dma_probe() call? I've tested the fix with the interrupt
clearing both above and below the pl011_dma_probe() call and versatile
qemu boots in both cases.
g.
--
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] tty: serial: altera_uart: Check for NULL platform_data in probe.
From: Tobias Klauser @ 2012-03-29 19:38 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Alan Cox, linux-serial, Yuriy Kozlov
In-Reply-To: <20120329161337.GA28858@kroah.com>
On 2012-03-29 at 18:13:37 +0200, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Thu, Mar 29, 2012 at 09:55:27AM +0200, Tobias Klauser wrote:
> > From: Yuriy Kozlov <ykozlov@ptcusa.com>
> >
> > Follow altera_jtag_uart. This fixes a crash if there is a mistake in the DTS.
>
> Is this something you have seen in the wild? Is this something to be
> backported to stable kernels?
Not that I know of. But nevertheless it might be worthwhile. Shall I
send the patch again with Cc: stable@kernel.org?
Thanks
Tobias
^ permalink raw reply
* Re: [PATCH] tty: serial: altera_uart: Check for NULL platform_data in probe.
From: Greg Kroah-Hartman @ 2012-03-29 19:47 UTC (permalink / raw)
To: Tobias Klauser; +Cc: Alan Cox, linux-serial, Yuriy Kozlov
In-Reply-To: <20120329193855.GW21503@distanz.ch>
On Thu, Mar 29, 2012 at 09:38:55PM +0200, Tobias Klauser wrote:
> On 2012-03-29 at 18:13:37 +0200, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > On Thu, Mar 29, 2012 at 09:55:27AM +0200, Tobias Klauser wrote:
> > > From: Yuriy Kozlov <ykozlov@ptcusa.com>
> > >
> > > Follow altera_jtag_uart. This fixes a crash if there is a mistake in the DTS.
> >
> > Is this something you have seen in the wild? Is this something to be
> > backported to stable kernels?
>
> Not that I know of. But nevertheless it might be worthwhile. Shall I
> send the patch again with Cc: stable@kernel.org?
Nope, I can add it.
But, if this isn't something that you have seen, why is it needed to be
checked for? What is this making work properly that isn't working
properly now?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] tty: serial: altera_uart: Check for NULL platform_data in probe.
From: Greg Kroah-Hartman @ 2012-03-29 16:13 UTC (permalink / raw)
To: Tobias Klauser; +Cc: Alan Cox, linux-serial, Yuriy Kozlov
In-Reply-To: <1333007727-24045-1-git-send-email-tklauser@distanz.ch>
On Thu, Mar 29, 2012 at 09:55:27AM +0200, Tobias Klauser wrote:
> From: Yuriy Kozlov <ykozlov@ptcusa.com>
>
> Follow altera_jtag_uart. This fixes a crash if there is a mistake in the DTS.
Is this something you have seen in the wild? Is this something to be
backported to stable kernels?
thanks,
greg k-h
^ 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