Re: framebuffer_{alloc,release}
From: Kronos <hidden>
Date: 2003-09-18 16:03:06
Hum, I don't see original email... James Simmons wrote:
The patch looks nice except for one thing. framebuffer_alloc is incorrect in assuming there is one struct xxx_par per strut fb_info. Struct xxx_par represents the physically hardware in a way independent of the framebuffer. The reason for this was to handle cards with more than one physical framebuffer. For example take a dual headed radeon card. You would have a design like this. |----------------- ____________ | | /dev/fb0 | | radeon_par | ----| ------------ |____________| | | |----------------- | /dev/fb1 | ------------ the reason for this design is simple. If fb0 video resolution changes it affects par. Now par's state affect fb1. We need to see if changes to either fb0 or fb1 affects the other display as well.
framebuffer_alloc doesn't assume anything. It allocates fb_info->par iff
it's told to. For dual head you can allocate par yourself (and do
whatever you want with it) or do something like this (matrox fb is doing
something similar):
if (seconday) {
fb_info = framebuffer_alloc(0, NULL);
fb_info->par = primary->par;
} else
fb_info = framebuffer_alloc(sizeof(struct foo_par), NULL);
release_fb_info won't touch fb_info->par unless it was created by
framebuffer_alloc. If secondary driver can work even when primary is
unloaded then you can use class_device_get (or a wrapper) to keep
primary fb data around:
if (secondary) {
if (!primary_fb_info)
secondary_fb_info = framebuffer_alloc(sizeof(struct foo_par), NULL);
else {
if (!class_device_get(&primary_fb_info->class_dev))
/* primary is going away */
else {
secondary_fb_info = framebuffer_alloc(0, NULL);
secondary_fb_info->par = primary_fb_info->par;
}
}
}
I've created a bk tree here:
bk://mesa3d.bkbits.net/fbdev-2.5
It's cloned from your tree and you can do a bk pull. You'll get the
following changesets:
[off-list ref] (03/09/17 1.1285)
Update sparc framebuffer drivers to the new API.
[off-list ref] (03/09/17 1.1281.1.1)
Add new API framebuffer_alloc and framebuffer_release.
Framebuffer info structure (ie. struct fb_info) must be obtained from
framebuffer_alloc. When it is no longer needed (after unregister_framebuffer
and clean up) it can be released using framebuffer_release.
If the framebuffer is not registered yet (eg. on error path) then fb_info must
be released via kfree.
David S. Miller has ack'ed sparc changes.
Luca
--
Reply-To: kronos@kronoz.cjb.net
Home: http://kronoz.cjb.net
Runtime error 6D at f000:a12f : user incompetente
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf