From: Andrew Morton <andrewm@uow.edu.au>
To: linuxconsole-dev@lists.sourceforge.net,
FrameBuffer List <linux-fbdev@vuser.vu.union.edu>,
lkml <linux-kernel@vger.kernel.org>
Subject: fbdev cursor management
Date: Sun, 11 Mar 2001 21:40:38 +1100 [thread overview]
Message-ID: <3AAB5626.A01EEF8F@uow.edu.au> (raw)
Guys,
I've been taking a look at the cursor flashing code,
from the point of view of how it's affected by the
recent enabling of interrupts across the console code.
Pretty much all of the cursor-blink stuff is racy,
and has always been racy on SMP. Enabling the
interrupts has made it racy on UP as well.
It all happens in timer handlers and interrupt handlers,
with no protection against mainline code accessing the
hardware simultaneously. As far as I can see, the
races will be harmless - the worst they can do is to
leave some snailtrails on the screen, which will soon
scroll away. So unless someone feels strongly about it,
or can pick a problem which I've missed I'd propose that
we leave it as it is for now.
vgacon looks OK.
Some things which I'd propose for future work:
- Collapse all the various per-driver cursor flashing
routines into a single place - manage the timer from
drivers/video/fbcon.c and from there, call into the
driver layer if requested.
- The cursor flash code should do the actual flash stuff
from within process context, not interrupt context. This
way, it can do acquire_console_sem() to serialise
everything properly.
The only way we have of doing this at present is to call
schedule_task() from within the timer handler. This works
fine, but it complicates the device close and module unload
problem somewhat. del_timer_sync + flush_scheduled_tasks
will be needed in the right places.
There are lots of places in the kernel which would benefit
from a process-context timer callback mechanism - ethernet
drivers in particular. So this is a piece of infrastructure
which we should develop for 2.5. It'll be just fine for
use in das blinkencursor code.
- With rivafb, I note that fbcon_vbl_handler() is being
called at 50 Hz, and it doesn't actually *do* anything.
All the work is being done by riva_cursor_timer_handler().
Seems a little inefficient?
- riva_cursor_timer_handler() is being called at 100Hz,
which is also more costly than it needs to be. Also,
it does this:
rinfo->cursor->timer->expires = jiffies + (HZ / 100);
so if the system has HZ < 100, the machine locks
up - run_timer_list() never returns. Minor point, but
it's another argument in favour of using, say, HZ/10.
-
next reply other threads:[~2001-03-11 10:40 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-11 10:40 Andrew Morton [this message]
2001-03-12 8:42 fbdev cursor management James Simmons
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=3AAB5626.A01EEF8F@uow.edu.au \
--to=andrewm@uow.edu.au \
--cc=linux-fbdev@vuser.vu.union.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxconsole-dev@lists.sourceforge.net \
/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;
as well as URLs for NNTP newsgroup(s).