From: "Michel Dänzer" <michel@daenzer.net>
To: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: "Bruno Prémont" <bonbons@linux-vserver.org>,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
"Bernie Thompson" <bernie@plugable.com>
Subject: Re: [Patch, RFC] Make struct fb_info ref-counted with kref
Date: Tue, 21 Sep 2010 10:44:35 +0000 [thread overview]
Message-ID: <1285065875.8555.233.camel@thor.local> (raw)
In-Reply-To: <4C97B079.8050707@gmx.de>
On Mon, 2010-09-20 at 21:05 +0200, Florian Tobias Schandinat wrote:
>
> Bruno Prémont schrieb:
> >
> > On Sun, 19 September 2010 Florian Tobias Schandinat <FlorianSchandinat@gmx.de> wrote:
> >>
> >> Bruno Prémont schrieb:
> >>> For USB-attached (or other hot-(un)pluggable) framebuffers the current
> >>> fbdev infrastructure is not very helpful. Each such driver currently
> >>> needs to perform the ref-counting on its own in .fbops.fb_open and
> >>> .fbops.fb_release callbacks.
> >> I agree. This is a great idea even for non-hot-(un)pluggable framebuffers.
> >
> > Yes, things like drmfb and drivers of multi-head capable framebuffer
> > drivers would certainly appreciate as well, but they will probably also
> > want to care about users (of fb_info.screen_base).
>
> I don't see any special users of fb_info.screen_base. It's only used for
> software fallbacks of acceleration functions and fb_read/fb_write (which I'd
> consider rare to fb_mmap). The bad thing of screen_base is that it can make
> viafb try to map up to 512MB on 32 bit systems...
> Much more painful IMHO are the mmaped areas in userspace which essentially
> prevent moving around of the screen framebuffer inside the video ram.
Actually, FWIW, when I tried to fix the framebuffer being pinned at a
fixed location in VRAM all the time in radeondrmfb, the userspace
mappings didn't seem to be any particular problem thanks to TTM. The
problem was the framebuffer CPU access by fbcon, as it can happen from
pretty much any context. The only possible solution at this point seems
to be to prevent fbcon CPU access completely by providing accelerated
versions of all its relevant hooks.
--
Earthling Michel Dänzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
next prev parent reply other threads:[~2010-09-21 10:44 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-19 15:28 [Patch, RFC] Make struct fb_info ref-counted with kref Bruno Prémont
2010-09-19 16:47 ` Florian Tobias Schandinat
2010-09-19 17:02 ` Bruno Prémont
2010-09-20 19:05 ` Florian Tobias Schandinat
2010-09-20 19:32 ` Bruno Prémont
2010-09-20 20:08 ` Florian Tobias Schandinat
2010-09-20 20:36 ` Bruno Prémont
2010-09-20 22:28 ` Florian Tobias Schandinat
2010-09-21 5:56 ` Bruno Prémont
2010-09-21 6:39 ` Florian Tobias Schandinat
2010-09-21 7:02 ` Bruno Prémont
2010-09-22 17:31 ` James Simmons
2010-09-22 18:39 ` Bruno Prémont
2010-09-22 19:14 ` James Simmons
2010-09-22 19:35 ` Bruno Prémont
2010-09-20 19:34 ` Guennadi Liakhovetski
2010-09-20 20:14 ` Bruno Prémont
2010-09-20 20:27 ` Guennadi Liakhovetski
2010-09-21 10:44 ` Michel Dänzer [this message]
2010-09-20 8:27 ` Geert Uytterhoeven
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=1285065875.8555.233.camel@thor.local \
--to=michel@daenzer.net \
--cc=FlorianSchandinat@gmx.de \
--cc=bernie@plugable.com \
--cc=bonbons@linux-vserver.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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 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).