Re: [PATCH] serial: 8250: Make ISA ports optional

2015-01-08 Thread One Thousand Gnomes
One idea that has come up in the past but never saw an implementation is to make the ttyS namespace and minor numbers completely generic and let any serial port driver use it. This would be a major rework, but have the added advantage of cleaning up a number of other namespace issues as well.

Re: [PATCH] serial: 8250: Make ISA ports optional

2015-01-08 Thread One Thousand Gnomes
On Mon, 5 Jan 2015 22:09:45 -0500 Peter Hurley pe...@hurleysoftware.com wrote: Some arches have no need to create unprobed 8250 ports; these phantom ports are primarily required for ISA ports which have no probe mechanism or to provide non-operational ports for userspace to configure (via

Re: [PATCH] tty: serial: 8250: omap: add ttySx console if the user didn't

2015-01-05 Thread One Thousand Gnomes
On Thu, 18 Dec 2014 18:47:12 +0100 Sebastian Andrzej Siewior bige...@linutronix.de wrote: This patch invokes add_preferred_console() with ttyS based on ttyO arguments if the user didn't specify it on its own. This ensures that the user will see the kernel booting on his serial console in case

Re: [PATCH] tty: serial: serial-omap: depend on !8250_omap

2014-12-05 Thread One Thousand Gnomes
On Mon, 1 Dec 2014 19:51:18 -0600 Felipe Balbi ba...@ti.com wrote: On Tue, Dec 02, 2014 at 01:13:38AM +0200, Aaro Koskinen wrote: Hi, On Mon, Dec 01, 2014 at 02:09:14PM +, One Thousand Gnomes wrote: Well the nightmare userspace switch from ttyS to ttyO few years ago

Re: [PATCH] tty: serial: serial-omap: depend on !8250_omap

2014-12-01 Thread One Thousand Gnomes
Well the nightmare userspace switch from ttyS to ttyO few years ago is something we want to avoid.. I think the best solution would be to make serial-omap.c transparently provide support for ttyO using the new 8250 code so both ttyS and ttyO devices would just work. Otherwise it will be years

Re: [PATCH 07/15] tty: serial: 8250_dma: enqueue RX dma again on completion.

2014-08-18 Thread One Thousand Gnomes
if (!up-dma || dma_err) status = serial8250_rx_chars(up, status); + + if (dma_err port-type == PORT_OMAP_16750) + serial8250_rx_dma(up, 0); Can we stick to a 'has dma' flag and port-rx_dma() type usages so that we don't

Re: [PATCH 5/6] tty: serial: 8250-core: add rs485 support

2014-07-10 Thread One Thousand Gnomes
static inline void __stop_tx(struct uart_8250_port *p) { + if (p-rs485.flags SER_RS485_ENABLED) { + int ret; + + ret = (p-rs485.flags SER_RS485_RTS_AFTER_SEND) ? 1 : 0; + if (gpio_get_value(p-rts_gpio) != ret) { + if

Re: [PATCH 2/6] tty: serial: 8250 core: allow to overwrite export serial8250_startup()

2014-07-10 Thread One Thousand Gnomes
On Wed, 9 Jul 2014 19:49:33 +0200 Sebastian Andrzej Siewior bige...@linutronix.de wrote: The OMAP version of the 8250 can actually use 1:1 serial8250_startup(). However it needs to be extended by a wakeup irq which should to be requested enabled at -startup() time and disabled at -shutdown()

Re: [RFC PATCH 1/4] tty: serial: 8250 core: provide a function to export uart_8250_port

2014-07-07 Thread One Thousand Gnomes
On Fri, 4 Jul 2014 18:34:08 +0200 Sebastian Andrzej Siewior bige...@linutronix.de wrote: There is no access to access a struct uart_8250_port for a specific line. This is only required outside of the 8250/uart callbacks like for devices' suspend remove callbacks. For those the 8250-core

Re: [RFC PATCH 2/4] tty: serial: 8250 core: allow to overwrite export serial8250_startup()

2014-07-07 Thread One Thousand Gnomes
On Fri, 4 Jul 2014 18:34:09 +0200 Sebastian Andrzej Siewior bige...@linutronix.de wrote: The OMAP version of the 8250 can actually use 1:1 serial8250_startup(). However it needs to be extended by a wakeup irq which should to be requested enabled at -startup() time. Signed-off-by:

Re: [RFC PATCH 3/4] tty: serial: 8250 core: add runtime pm

2014-07-07 Thread One Thousand Gnomes
On Fri, 4 Jul 2014 18:34:10 +0200 Sebastian Andrzej Siewior bige...@linutronix.de wrote: While comparing the OMAP-serial and the 8250 part of this I noticed that the the latter does not use runtime-pm. Yes it does, but 8250 parts (generally - omap presumably is special here ?) need to be

Re: [RFC PATCH] tty: serial: Add 8250-core based omap driver

2014-07-07 Thread One Thousand Gnomes
On Fri, 4 Jul 2014 11:57:40 -0500 Robert Nelson robertcnel...@gmail.com wrote: On Fri, Jul 4, 2014 at 11:51 AM, Sebastian Andrzej Siewior bige...@linutronix.de wrote: On 07/03/2014 09:34 AM, Tony Lindgren wrote: Heh. Just to summarize the reason ttyO needs to be a separate name and device

Re: [PATCH 10/13] tty: serial: omap: remove some dead code

2014-04-25 Thread One Thousand Gnomes
As soon as this patch (http://www.spinics.net/lists/arm-kernel/msg325197.html) will be applied, we don't really need this DTR GPIO any more. For the omap specific case, not for the general case of sorting out power hierarchies. Alan -- To unsubscribe from this list: send the line unsubscribe

Re: [PATCH 10/13] tty: serial: omap: remove some dead code

2014-04-25 Thread One Thousand Gnomes
I had a quick look and I guess that uart_change_pm() is the most likely candidate for what you are referring to. I can see how that interfaces to the specific piece of uart hardware, such as omap-serial.c But I cannot see how you would plumb that though to the device that was plugged in to

Re: [PATCH 10/13] tty: serial: omap: remove some dead code

2014-04-24 Thread One Thousand Gnomes
But I don't have discrete hardware. I have a bunch of stuff soldered onto a board with ad-hoc connections chosen to make the life of the hardware builder easy rather than chosen to make the life of the software developer easy (which I think is the correct choice). So I need to