* [PATCH 09/17] serial/8250: Limit the omap workarounds to omap1 [not found] <20120911052934.29637.9190.stgit@muffinssi.local> @ 2012-09-11 5:31 ` Tony Lindgren 2012-09-11 16:42 ` Alan Cox 0 siblings, 1 reply; 5+ messages in thread From: Tony Lindgren @ 2012-09-11 5:31 UTC (permalink / raw) To: linux-arm-kernel; +Cc: Greg Kroah-Hartman, linux-omap, linux-serial, Alan Cox These workarounds do not apply for CONFIG_ARCH_OMAP2PLUS at all, so let's make it just CONFIG_ARCH_OMAP1. This is needed to for ARM common zImage changes for omap2+ to avoid including plat and mach headers. Cc: Alan Cox <alan@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-serial@vger.kernel.org Signed-off-by: Tony Lindgren <tony@atomide.com> --- drivers/tty/serial/8250/8250.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/tty/serial/8250/8250.c b/drivers/tty/serial/8250/8250.c index 8123f78..5b3f2fe 100644 --- a/drivers/tty/serial/8250/8250.c +++ b/drivers/tty/serial/8250/8250.c @@ -2336,7 +2336,7 @@ serial8250_do_set_termios(struct uart_port *port, struct ktermios *termios, serial_port_out(port, UART_EFR, efr); } -#ifdef CONFIG_ARCH_OMAP +#ifdef CONFIG_ARCH_OMAP1 /* Workaround to enable 115200 baud on OMAP1510 internal ports */ if (cpu_is_omap1510() && is_omap_port(up)) { if (baud == 115200) { @@ -2426,7 +2426,7 @@ static unsigned int serial8250_port_size(struct uart_8250_port *pt) { if (pt->port.iotype == UPIO_AU) return 0x1000; -#ifdef CONFIG_ARCH_OMAP +#ifdef CONFIG_ARCH_OMAP1 if (is_omap_port(pt)) return 0x16 << pt->port.regshift; #endif ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH 09/17] serial/8250: Limit the omap workarounds to omap1 2012-09-11 5:31 ` [PATCH 09/17] serial/8250: Limit the omap workarounds to omap1 Tony Lindgren @ 2012-09-11 16:42 ` Alan Cox 2012-09-11 16:40 ` Tony Lindgren 0 siblings, 1 reply; 5+ messages in thread From: Alan Cox @ 2012-09-11 16:42 UTC (permalink / raw) To: Tony Lindgren Cc: linux-arm-kernel, Greg Kroah-Hartman, linux-omap, linux-serial On Mon, 10 Sep 2012 22:31:04 -0700 Tony Lindgren <tony@atomide.com> wrote: > These workarounds do not apply for CONFIG_ARCH_OMAP2PLUS at all, > so let's make it just CONFIG_ARCH_OMAP1. > > This is needed to for ARM common zImage changes for > omap2+ to avoid including plat and mach headers. > > Cc: Alan Cox <alan@linux.intel.com> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Cc: linux-serial@vger.kernel.org > Signed-off-by: Tony Lindgren <tony@atomide.com> > --- > drivers/tty/serial/8250/8250.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/tty/serial/8250/8250.c > b/drivers/tty/serial/8250/8250.c index 8123f78..5b3f2fe 100644 > --- a/drivers/tty/serial/8250/8250.c > +++ b/drivers/tty/serial/8250/8250.c > @@ -2336,7 +2336,7 @@ serial8250_do_set_termios(struct uart_port > *port, struct ktermios *termios, serial_port_out(port, UART_EFR, efr); > } > > -#ifdef CONFIG_ARCH_OMAP > +#ifdef CONFIG_ARCH_OMAP1 > /* Workaround to enable 115200 baud on OMAP1510 internal > ports */ if (cpu_is_omap1510() && is_omap_port(up)) { > if (baud == 115200) { > @@ -2426,7 +2426,7 @@ static unsigned int serial8250_port_size(struct > uart_8250_port *pt) { > if (pt->port.iotype == UPIO_AU) > return 0x1000; > -#ifdef CONFIG_ARCH_OMAP > +#ifdef CONFIG_ARCH_OMAP1 > if (is_omap_port(pt)) > return 0x16 << pt->port.regshift; > #endif > Acked-by: Alan Cox <alan@linux.intel.com> Even better would be if for other cases is_omap_port and friends returned 0... ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 09/17] serial/8250: Limit the omap workarounds to omap1 2012-09-11 16:42 ` Alan Cox @ 2012-09-11 16:40 ` Tony Lindgren 2012-09-11 19:19 ` Alan Cox 0 siblings, 1 reply; 5+ messages in thread From: Tony Lindgren @ 2012-09-11 16:40 UTC (permalink / raw) To: Alan Cox; +Cc: linux-arm-kernel, Greg Kroah-Hartman, linux-omap, linux-serial * Alan Cox <alan@linux.intel.com> [120911 09:25]: > On Mon, 10 Sep 2012 22:31:04 -0700 > Tony Lindgren <tony@atomide.com> wrote: > > > These workarounds do not apply for CONFIG_ARCH_OMAP2PLUS at all, > > so let's make it just CONFIG_ARCH_OMAP1. > > > > This is needed to for ARM common zImage changes for > > omap2+ to avoid including plat and mach headers. > > > > Cc: Alan Cox <alan@linux.intel.com> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > Cc: linux-serial@vger.kernel.org > > Signed-off-by: Tony Lindgren <tony@atomide.com> > > --- > > drivers/tty/serial/8250/8250.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/tty/serial/8250/8250.c > > b/drivers/tty/serial/8250/8250.c index 8123f78..5b3f2fe 100644 > > --- a/drivers/tty/serial/8250/8250.c > > +++ b/drivers/tty/serial/8250/8250.c > > @@ -2336,7 +2336,7 @@ serial8250_do_set_termios(struct uart_port > > *port, struct ktermios *termios, serial_port_out(port, UART_EFR, efr); > > } > > > > -#ifdef CONFIG_ARCH_OMAP > > +#ifdef CONFIG_ARCH_OMAP1 > > /* Workaround to enable 115200 baud on OMAP1510 internal > > ports */ if (cpu_is_omap1510() && is_omap_port(up)) { > > if (baud == 115200) { > > @@ -2426,7 +2426,7 @@ static unsigned int serial8250_port_size(struct > > uart_8250_port *pt) { > > if (pt->port.iotype == UPIO_AU) > > return 0x1000; > > -#ifdef CONFIG_ARCH_OMAP > > +#ifdef CONFIG_ARCH_OMAP1 > > if (is_omap_port(pt)) > > return 0x16 << pt->port.regshift; > > #endif > > > > Acked-by: Alan Cox <alan@linux.intel.com> Thanks. > Even better would be if for other cases is_omap_port and friends > returned 0... Yes it seems that those macros could be moved from plat-omap/serial.h to live in drivers/tty/serial/8250/8250.h? Or do you have some better place in mind? Regards, Tony ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 09/17] serial/8250: Limit the omap workarounds to omap1 2012-09-11 16:40 ` Tony Lindgren @ 2012-09-11 19:19 ` Alan Cox 2012-10-03 22:26 ` Tony Lindgren 0 siblings, 1 reply; 5+ messages in thread From: Alan Cox @ 2012-09-11 19:19 UTC (permalink / raw) To: Tony Lindgren Cc: linux-arm-kernel, Greg Kroah-Hartman, linux-omap, linux-serial > > Even better would be if for other cases is_omap_port and friends > > returned 0... > > Yes it seems that those macros could be moved from plat-omap/serial.h > to live in drivers/tty/serial/8250/8250.h? Or do you have some better > place in mind? I've not looked at it enough to decide if it's doable or not. I'm happy either way - both patches are progress the right way! ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 09/17] serial/8250: Limit the omap workarounds to omap1 2012-09-11 19:19 ` Alan Cox @ 2012-10-03 22:26 ` Tony Lindgren 0 siblings, 0 replies; 5+ messages in thread From: Tony Lindgren @ 2012-10-03 22:26 UTC (permalink / raw) To: Alan Cox; +Cc: linux-arm-kernel, Greg Kroah-Hartman, linux-omap, linux-serial * Alan Cox <alan@linux.intel.com> [120911 12:02]: > > > Even better would be if for other cases is_omap_port and friends > > > returned 0... > > > > Yes it seems that those macros could be moved from plat-omap/serial.h > > to live in drivers/tty/serial/8250/8250.h? Or do you have some better > > place in mind? > > I've not looked at it enough to decide if it's doable or not. I'm happy > either way - both patches are progress the right way! FYI, I'll send something along these lines as a separate patch as "[PATCH] tty/serial/8250: Make omap hardware workarounds local to 8250.h" Regards, Tony ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-10-03 22:26 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20120911052934.29637.9190.stgit@muffinssi.local>
2012-09-11 5:31 ` [PATCH 09/17] serial/8250: Limit the omap workarounds to omap1 Tony Lindgren
2012-09-11 16:42 ` Alan Cox
2012-09-11 16:40 ` Tony Lindgren
2012-09-11 19:19 ` Alan Cox
2012-10-03 22:26 ` Tony Lindgren
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).