All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Bastien Armand <armand.bastien@laposte.net>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
	Willy Tarreau <willy@meta-x.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Monam Agarwal <monamagarwal123@gmail.com>,
	Jake Champlin <jake.champlin.27@gmail.com>,
	Arnd Bergmann <arnd@arndb.de>,
	devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] staging: panel: fix sparse warnings in lcd_write
Date: Fri, 25 Apr 2014 07:56:09 +0200	[thread overview]
Message-ID: <20140425055609.GF19929@1wt.eu> (raw)
In-Reply-To: <20140423173435.GB10879@plop.dartybox.com>

On Wed, Apr 23, 2014 at 07:35:02PM +0200, Bastien Armand wrote:
> On Tue, Apr 22, 2014 at 01:01:45PM +0300, Dan Carpenter wrote:
> > Btw, this whole function is terrible.  It should be reading larger
> > chunks at once instead of get_user() for each character.

Just for the record, very small character counts may be sent to an LCD
panel, in general these are 2 lines of 16 characters, and at most 2x40,
and changes are very rare. The worst case will be if someone displays
the time of day, it will change every second.

> > > +	if (lcd_enabled && lcd_initialized) {
> > > +		for (; count-- > 0; tmp++) {
> > > +			if (!in_interrupt() && (((count + 1) & 0x1f) == 0))
> > > +				/* let's be a little nice with other processes
> > > +				   that need some CPU */
> > > +				schedule();
> > 
> > This schedule() isn't needed.  It just prints a line or two at start up
> > and some other debug output or something.  Small small.
> > 
> 
> I hesitated to remove it. I leave it here as it was allready in lcd_write.
> Perhaps, I could send another patch to remove it.

I believe it can go. I have some memories of it when I was developing the
driver because I didn't know if some LCDs would need long pauses between
each character. Hmmm well, thinking about it after re-reading the code,
we could wait up to 20+40+120 = 180 microseconds when sending one command
(eg: position change), or 20+40+45 = 105 microseconds when sending one
char. That's basically 180+40*105 = 4.185 milliseconds for one full line,
or 8 milliseconds for two lines of 40 chars. So maybe we should keep the
schedule() in the end...

Best regards,
Willy


      parent reply	other threads:[~2014-04-25  5:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-18 16:10 [PATCH v2 2/2] staging: panel: fix sparse warnings in lcd_write Bastien Armand
2014-04-22 10:01 ` Dan Carpenter
2014-04-23 17:35   ` Bastien Armand
2014-04-23 19:21     ` Dan Carpenter
2014-04-25  5:56     ` Willy Tarreau [this message]

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=20140425055609.GF19929@1wt.eu \
    --to=w@1wt.eu \
    --cc=armand.bastien@laposte.net \
    --cc=arnd@arndb.de \
    --cc=dan.carpenter@oracle.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jake.champlin.27@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=monamagarwal123@gmail.com \
    --cc=willy@meta-x.org \
    /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.