Re: [PATCH] cyber2000fb: New framebuffer_alloc API and class_dev changes

On Tue, Sep 16, 2003 at 04:17:13PM +0200, Kronos wrote:

Good point. I  was thinking  at files  created by  the driver  itself, I
forgot about  dev attribute. I  can overwrite  .owner of  dev attribute,
fbmem can't be built as module. Sounds good?

How about we do the job properly first time around?

- fbmem.c is responsible for managing the lifetime of the fb_info structure,
  and the lifetime of the driver-private data is equal to the lifetime
  of the fb_info structure.

- framebuffer_alloc() creates the fb_info and the driver-private data
  in one object, as per your patch.
- fb_add_class_device creates the class device, as per your patch
  (don't you think it'd be a good idea to return the error to the
  driver if class_device_register() fails?)
- fb_remove_class_device unregisters the class device, as per your
  patch.  This should not cause the fb_info structures to be released.
- framebuffer_free() marks the structure available for freeing.
- at some point later, once all references have done, release_fb_info()
  is called.  This releases the memory space allocated by
  framebuffer_alloc().  This callback should _not_ call the driver
  code.

So far, this fits fairly nicely.  Now on to the driver.

- bus-specific ->probe function
  driver calls framebuffer_alloc(), initialises whatever it needs to.
  Driver then calls register_fb() which in turn eventually calls
  fb_add_class_device().

- bus-specific ->remove function
  driver calls unregister_framebuffer() which eventually calls
  fb_remove_class_device().  driver releases its resources, shuts down
  hardware, and generally cleans up.  The very last step that it does
  is call framebuffer_free().

I believe there was an issue concerning EDID stuff with the above method.
If this requires data from the fb_info or another structure whose lifetime
is directly connected to fb_info, then there isn't a problem.  If it
requires something from the driver module, things get a little more
complicated, and there is a solution to this.  I don't see any instances
of this from looking at your fbdev-class_dev-all patch though.

-- 
Russell King (rmk@arm.linux.org.uk)	http://www.arm.linux.org.uk/personal/
Linux kernel maintainer of:
  2.6 ARM Linux   - http://www.arm.linux.org.uk/
  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
  2.6 Serial core


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Il Tue, Sep 16, 2003 at 03:52:30PM +0100, Russell King ha scritto: 

- framebuffer_alloc() creates the fb_info and the driver-private data
  in one object, as per your patch.

- framebuffer_free() marks the structure available for freeing.

So framebuffer_alloc calls class_device_get and framebuffer_free calls
class_device_put. Ok, I'll rework the patch.

Luca
-- 
Reply-To: kronos@kronoz.cjb.net
Home: http://kronoz.cjb.net
Porc i' mond che cio' sott i piedi!
V. Catozzo


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

This is not always the case. For dual headed graphics cards you can have 
two struct fb_info and one driver-private data. If the fbdev driver
releases one framebuffer you still have one framebuffer left that is using 
the driver-private data.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf