All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frans Klaver <frans.klaver@xsens.com>
To: Felipe Balbi <balbi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>,
	Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Alexey Pelykh <alexey.pelykh@gmail.com>,
	Jiri Slaby <jslaby@suse.cz>, Frans Klaver <fransklaver@gmail.com>,
	<linux-serial@vger.kernel.org>, <linux-omap@vger.kernel.org>,
	<devicetree@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler
Date: Thu, 21 Aug 2014 23:41:17 +0200	[thread overview]
Message-ID: <20140821214117.GA7076@ci00147.xsens-tech.local> (raw)
In-Reply-To: <20140820160604.GH24500@saruman.home>

On Wed, Aug 20, 2014 at 11:06:05AM -0500, Felipe Balbi wrote:
> On Wed, Aug 20, 2014 at 08:40:28AM +0200, Frans Klaver wrote:
> > On Tue, Aug 19, 2014 at 01:57:02PM -0500, Felipe Balbi wrote:
> > > On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
> > > > At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
> > > > rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
> > > > this to about 170 overflows in 10 minutes.
> > > 
> > > Can you try Sebastian Siewior's patches for 8250_omap and 8250 dma
> > > support ? That should help you a lot.
> > 
> > I'll have a look at that series. Thanks for pointing it out.

I have had a look at Sebastian's series, but I'm not convinced
yet that we should use it. So far the serial console seems to be
missing data every now and then. I haven't gotten around to testing our
high traffic application yet.


> > > >  drivers/tty/serial/omap-serial.c | 31 ++++++++++++++++++++++++-------
> > > >  1 file changed, 24 insertions(+), 7 deletions(-)
> > > > 
> > > > diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> > > > index 14a0167..57664b9 100644
> > > > --- a/drivers/tty/serial/omap-serial.c
> > > > +++ b/drivers/tty/serial/omap-serial.c
> > > > @@ -575,6 +575,21 @@ static void serial_omap_rdi(struct uart_omap_port *up, unsigned int lsr)
> > > >  }
> > > >  
> > > >  /**
> > > > + * serial_omap_fast_irq() - schedule interrupt handling
> > > > + */
> > > > +static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
> > > > +{
> > > > +	struct uart_omap_port *up = dev_id;
> > > > +	unsigned int iir = serial_in(up, UART_IIR);
> > > > +
> > > > +	if (iir & UART_IIR_NO_INT)
> > > > +		return IRQ_NONE;
> > > > +
> > > > +	disable_irq_nosync(up->port.irq);
> > > 
> > > NAK. Either use IRQF_ONESHOT or actually mask the IRQs at the device's
> > > registers (basically clearing IER).
> > 
> > Given the work that's been done on the 8250 based driver, what are the
> > short-term chances omap-serial will be dropped? I'd be happy to improve
> > here if it makes sense to do so. If the 8250 based driver is going to
> > replace omap-serial anyway on the short term, I don't see the point of
> > further developing this patch. The others would still make sense in my
> > opinion.
> 
> if we find a way to maintain the same ttyO* naming scheme and make it
> coexist with ttyS* naming, then we could drop as soon as 8250_omap is
> ready for prime time.

With that in mind, for now I'll be betting on two horses.

I'll cook up a new version using oneshot.

Thanks,
Frans

WARNING: multiple messages have this Message-ID (diff)
From: Frans Klaver <frans.klaver@xsens.com>
To: Felipe Balbi <balbi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>,
	Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Alexey Pelykh <alexey.pelykh@gmail.com>,
	Jiri Slaby <jslaby@suse.cz>, Frans Klaver <fransklaver@gmail.com>,
	linux-serial@vger.kernel.org, linux-omap@vger.kernel.org,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler
Date: Thu, 21 Aug 2014 23:41:17 +0200	[thread overview]
Message-ID: <20140821214117.GA7076@ci00147.xsens-tech.local> (raw)
In-Reply-To: <20140820160604.GH24500@saruman.home>

On Wed, Aug 20, 2014 at 11:06:05AM -0500, Felipe Balbi wrote:
> On Wed, Aug 20, 2014 at 08:40:28AM +0200, Frans Klaver wrote:
> > On Tue, Aug 19, 2014 at 01:57:02PM -0500, Felipe Balbi wrote:
> > > On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
> > > > At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
> > > > rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
> > > > this to about 170 overflows in 10 minutes.
> > > 
> > > Can you try Sebastian Siewior's patches for 8250_omap and 8250 dma
> > > support ? That should help you a lot.
> > 
> > I'll have a look at that series. Thanks for pointing it out.

I have had a look at Sebastian's series, but I'm not convinced
yet that we should use it. So far the serial console seems to be
missing data every now and then. I haven't gotten around to testing our
high traffic application yet.


> > > >  drivers/tty/serial/omap-serial.c | 31 ++++++++++++++++++++++++-------
> > > >  1 file changed, 24 insertions(+), 7 deletions(-)
> > > > 
> > > > diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> > > > index 14a0167..57664b9 100644
> > > > --- a/drivers/tty/serial/omap-serial.c
> > > > +++ b/drivers/tty/serial/omap-serial.c
> > > > @@ -575,6 +575,21 @@ static void serial_omap_rdi(struct uart_omap_port *up, unsigned int lsr)
> > > >  }
> > > >  
> > > >  /**
> > > > + * serial_omap_fast_irq() - schedule interrupt handling
> > > > + */
> > > > +static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
> > > > +{
> > > > +	struct uart_omap_port *up = dev_id;
> > > > +	unsigned int iir = serial_in(up, UART_IIR);
> > > > +
> > > > +	if (iir & UART_IIR_NO_INT)
> > > > +		return IRQ_NONE;
> > > > +
> > > > +	disable_irq_nosync(up->port.irq);
> > > 
> > > NAK. Either use IRQF_ONESHOT or actually mask the IRQs at the device's
> > > registers (basically clearing IER).
> > 
> > Given the work that's been done on the 8250 based driver, what are the
> > short-term chances omap-serial will be dropped? I'd be happy to improve
> > here if it makes sense to do so. If the 8250 based driver is going to
> > replace omap-serial anyway on the short term, I don't see the point of
> > further developing this patch. The others would still make sense in my
> > opinion.
> 
> if we find a way to maintain the same ttyO* naming scheme and make it
> coexist with ttyS* naming, then we could drop as soon as 8250_omap is
> ready for prime time.

With that in mind, for now I'll be betting on two horses.

I'll cook up a new version using oneshot.

Thanks,
Frans

WARNING: multiple messages have this Message-ID (diff)
From: frans.klaver@xsens.com (Frans Klaver)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler
Date: Thu, 21 Aug 2014 23:41:17 +0200	[thread overview]
Message-ID: <20140821214117.GA7076@ci00147.xsens-tech.local> (raw)
In-Reply-To: <20140820160604.GH24500@saruman.home>

On Wed, Aug 20, 2014 at 11:06:05AM -0500, Felipe Balbi wrote:
> On Wed, Aug 20, 2014 at 08:40:28AM +0200, Frans Klaver wrote:
> > On Tue, Aug 19, 2014 at 01:57:02PM -0500, Felipe Balbi wrote:
> > > On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
> > > > At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
> > > > rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
> > > > this to about 170 overflows in 10 minutes.
> > > 
> > > Can you try Sebastian Siewior's patches for 8250_omap and 8250 dma
> > > support ? That should help you a lot.
> > 
> > I'll have a look at that series. Thanks for pointing it out.

I have had a look at Sebastian's series, but I'm not convinced
yet that we should use it. So far the serial console seems to be
missing data every now and then. I haven't gotten around to testing our
high traffic application yet.


> > > >  drivers/tty/serial/omap-serial.c | 31 ++++++++++++++++++++++++-------
> > > >  1 file changed, 24 insertions(+), 7 deletions(-)
> > > > 
> > > > diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> > > > index 14a0167..57664b9 100644
> > > > --- a/drivers/tty/serial/omap-serial.c
> > > > +++ b/drivers/tty/serial/omap-serial.c
> > > > @@ -575,6 +575,21 @@ static void serial_omap_rdi(struct uart_omap_port *up, unsigned int lsr)
> > > >  }
> > > >  
> > > >  /**
> > > > + * serial_omap_fast_irq() - schedule interrupt handling
> > > > + */
> > > > +static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
> > > > +{
> > > > +	struct uart_omap_port *up = dev_id;
> > > > +	unsigned int iir = serial_in(up, UART_IIR);
> > > > +
> > > > +	if (iir & UART_IIR_NO_INT)
> > > > +		return IRQ_NONE;
> > > > +
> > > > +	disable_irq_nosync(up->port.irq);
> > > 
> > > NAK. Either use IRQF_ONESHOT or actually mask the IRQs at the device's
> > > registers (basically clearing IER).
> > 
> > Given the work that's been done on the 8250 based driver, what are the
> > short-term chances omap-serial will be dropped? I'd be happy to improve
> > here if it makes sense to do so. If the 8250 based driver is going to
> > replace omap-serial anyway on the short term, I don't see the point of
> > further developing this patch. The others would still make sense in my
> > opinion.
> 
> if we find a way to maintain the same ttyO* naming scheme and make it
> coexist with ttyS* naming, then we could drop as soon as 8250_omap is
> ready for prime time.

With that in mind, for now I'll be betting on two horses.

I'll cook up a new version using oneshot.

Thanks,
Frans

  reply	other threads:[~2014-08-21 21:41 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-29 14:52 [RFC PATCH 0/3] omap-serial high-speed fixes/improvements Frans Klaver
2014-07-29 14:52 ` Frans Klaver
2014-07-29 14:52 ` [PATCH 1/3] tty: omap-serial: prevent division by zero Frans Klaver
2014-07-29 15:00   ` Frans Klaver
2014-07-29 15:00     ` Frans Klaver
2014-07-29 14:52 ` [PATCH 2/3] tty: omap-serial: use threaded interrupt handler Frans Klaver
2014-07-29 14:52 ` [PATCH 3/3] tty: omap-serial: support setting of hardware flow control in dts Frans Klaver
2014-07-29 15:02 ` [RFC PATCH 0/3] omap-serial high-speed fixes/improvements Frans Klaver
2014-07-29 15:02   ` Frans Klaver
2014-07-29 15:02   ` [PATCH 1/3] tty: omap-serial: prevent division by zero Frans Klaver
2014-07-29 15:02     ` Frans Klaver
2014-07-29 15:02   ` [PATCH 2/3] tty: omap-serial: use threaded interrupt handler Frans Klaver
2014-07-29 15:02     ` Frans Klaver
2014-07-29 15:02   ` [PATCH 3/3] tty: omap-serial: support setting of hardware flow control in dts Frans Klaver
2014-07-29 15:02     ` Frans Klaver
2014-08-11 10:09   ` [RFC PATCH 0/3] omap-serial high-speed fixes/improvements Frans Klaver
2014-08-11 10:09     ` Frans Klaver
2014-08-18 13:45 ` Felipe Balbi
2014-08-18 13:45   ` Felipe Balbi
2014-08-18 14:45   ` Frans Klaver
2014-08-18 14:45     ` Frans Klaver
2014-08-19 12:14 ` [RFC PATCHv2 0/4] " Frans Klaver
2014-08-19 12:14   ` Frans Klaver
2014-08-19 12:14   ` Frans Klaver
2014-08-19 12:14   ` [PATCH 1/4] tty: omap-serial: pull out calculation from baud_is_mode16 Frans Klaver
2014-08-19 12:14     ` Frans Klaver
2014-08-19 12:14     ` Frans Klaver
2014-08-19 12:14   ` [PATCH 2/4] tty: omap-serial: prevent division by zero Frans Klaver
2014-08-19 12:14     ` Frans Klaver
2014-08-19 12:14     ` Frans Klaver
2014-08-19 12:14   ` [RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler Frans Klaver
2014-08-19 12:14     ` Frans Klaver
2014-08-19 12:14     ` Frans Klaver
2014-08-19 18:57     ` Felipe Balbi
2014-08-19 18:57       ` Felipe Balbi
2014-08-19 18:57       ` Felipe Balbi
2014-08-20  6:40       ` Frans Klaver
2014-08-20  6:40         ` Frans Klaver
2014-08-20  6:40         ` Frans Klaver
2014-08-20 16:06         ` Felipe Balbi
2014-08-20 16:06           ` Felipe Balbi
2014-08-20 16:06           ` Felipe Balbi
2014-08-21 21:41           ` Frans Klaver [this message]
2014-08-21 21:41             ` Frans Klaver
2014-08-21 21:41             ` Frans Klaver
2014-08-21 21:48             ` Felipe Balbi
2014-08-21 21:48               ` Felipe Balbi
2014-08-21 21:48               ` Felipe Balbi
2014-08-21 22:07               ` Frans Klaver
2014-08-21 22:07                 ` Frans Klaver
2014-08-22 14:02       ` Frans Klaver
2014-08-22 14:02         ` Frans Klaver
2014-08-22 14:02         ` Frans Klaver
2014-08-19 12:14   ` [PATCH 4/4] tty: omap-serial: support setting of hardware flow control in dts Frans Klaver
2014-08-19 12:14     ` Frans Klaver
2014-08-19 12:14     ` Frans Klaver

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140821214117.GA7076@ci00147.xsens-tech.local \
    --to=frans.klaver@xsens.com \
    --cc=alexey.pelykh@gmail.com \
    --cc=balbi@ti.com \
    --cc=devicetree@vger.kernel.org \
    --cc=fransklaver@gmail.com \
    --cc=galak@codeaurora.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=jslaby@suse.cz \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.