public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Timur Tabi <timur@freescale.com>
Cc: gregkh <gregkh@suse.de>, lkml <linux-kernel@vger.kernel.org>
Subject: Re: Writing a console/tty driver -- how to use tty_port?
Date: Fri, 29 Oct 2010 16:21:42 +0200	[thread overview]
Message-ID: <201010291621.42890.arnd@arndb.de> (raw)
In-Reply-To: <4CC9E646.6070405@freescale.com>

On Thursday 28 October 2010, Timur Tabi wrote:
> Arnd Bergmann wrote:
> > If the device is not a UART, the best option may be to make the driver
> > a backend to the hvc driver, like e.g. drivers/char/hvc_tile.c.
> 
> The current version *is* a backend to hvc, but I have to abandon that because of
> this thread:
> 
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-September/085664.html
> 
> I posted a patch that causes hvc to spin if the backend driver returns -EAGAIN,
> which is my driver does when the output buffer is full.
> 
> In other words, hvc does not support backend drivers that can detect full output
> buffers.

To be more specific, hvc does support retransmitting characters on the tty
but not on the console!

The backend drivers return 0 to notify the tty driver that output is busy
and should be retried, which will set the timer.

> > This works for all devices with or without interrupts that don't need
> > to set up the communication parameters but simply provide a read/write
> > character interface.
> 
> If my patch were accepted, I wouldn't need to do the rewrite.  Dropping
> characters during a printk() is not acceptable for us.

Why do you care about printk output overflowing more than others do? Most
of the hvc drivers block internally and never return 0, but those that
do probably all need the same solution.

Your original one-line patch from last year didn't seem too wrong, though
you might want to check with the iseries people, since that driver might
return zero in error cases.

The idea of adding a special return code from ->put_chars to distinguish
buffer full from other errors also seemed reasonable, as did the approach
to flag the hv_ops to tell the base layer wether you want retransmits
or drops.

	Arnd


  reply	other threads:[~2010-10-29 23:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-27 21:04 Writing a console/tty driver -- how to use tty_port? Timur Tabi
2010-10-27 22:19 ` Alan Cox
2010-10-28 19:35   ` Timur Tabi
2010-10-29 13:55     ` Timur Tabi
2010-10-29 14:14       ` Timur Tabi
2010-10-28 20:34   ` Timur Tabi
2010-10-28 20:47     ` Timur Tabi
2010-10-28 20:57 ` Arnd Bergmann
2010-10-28 21:08   ` Timur Tabi
2010-10-29 14:21     ` Arnd Bergmann [this message]
2010-10-28 22:11   ` Alan Cox
2010-10-29 23:55     ` Arnd Bergmann

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=201010291621.42890.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=timur@freescale.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox