Re: framebuffer_{alloc,release}

[Kronos <kronos@kronoz.cjb.net>]

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:

<kronos@kronoz.cjb.net> (03/09/17 1.1285)
   Update sparc framebuffer drivers to the new API.

<kronos@kronoz.cjb.net> (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