From: Timur Tabi <timur@freescale.com>
To: linux-fbdev@vger.kernel.org
Subject: Re: [PATCH] fb: split out framebuffer initialization from allocation
Date: Mon, 21 Nov 2011 18:37:48 +0000 [thread overview]
Message-ID: <4ECA9A7C.5040402@freescale.com> (raw)
In-Reply-To: <1321308088-6327-1-git-send-email-timur@freescale.com>
Bruno Prémont wrote:
> Exactly, thats why I would prefer to see all that initialization moved
> out of registrer_framebuffer() into a init_framebuffer().
I'm okay with that, but I'm not crazy about it.
>
> For simplicity any driver that uses framebuffer_alloc() should not need
> to additionally call init_framebuffer() - framebuffer_alloc() should
> call it just before returning.
My patch does that.
> All those drivers that don't call framebuffer_alloc() would then have to
> call init_framebuffer().
Well, that would then mean that it's easier to move initialization *into* register_framebuffer().
> I think register_framebuffer() is a bit too late to do the initialisation
> of mutexes and other class state because driver cannot use the same code
> for HW setup before registration and after registration as at least the lock
> is in undefined state.
How many drivers actually do that? The only thing that framebuffer_alloc() initializes in fb_info is the 'device' field, which is just a parameter passed into framebuffer_alloc(), so the driver already knows what that value is. I can't find any examples of a driver doing what you're talking about.
It should be easy to modify any driver to stop using the fields of fb_info before register_framebuffer() is called. In fact, I would say it's bad programming to use the fb_info object before the framebuffer is registered.
> In pseudo-code my though would be:
>
>
> // driver using their own memory allocation
>
> struct driver_data {
> ...
> struct fb_info fb;
> ...
> }
>
> int driver_init() {
> struct driver_data *data;
> ...
> memset(&data->fb, 0, sizeof(data->fb));
> init_framebuffer(&data->fb);
> // fill in driver's settings for fb
> ...
> register_framebuffer(&data->fb);
> ...
> }
>
> // driver using alloc_framebuffer()
>
> struct driver_data {
> ...
> struct fb_info *fb;
> ...
> }
>
> int driver_init() {
> struct driver_data *data;
> ...
> data->fb = alloc_framebuffer(0); // this implicitly calls init_framebuffer();
> // fill in driver's settings for fb
> ...
> register_framebuffer(&data->fb);
> ...
> }
This is pretty much what my patch does. But the more I think about it, the more I'm in favor of moving all initialization into register_framebuffer().
--
Timur Tabi
Linux kernel developer at Freescale
prev parent reply other threads:[~2011-11-21 18:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-14 22:01 [PATCH] fb: split out framebuffer initialization from allocation Timur Tabi
2011-11-17 20:19 ` Timur Tabi
2011-11-19 5:06 ` Florian Tobias Schandinat
2011-11-19 11:47 ` [PATCH] fb: split out framebuffer initialization from Bruno Prémont
2011-11-19 12:08 ` [PATCH] fb: split out framebuffer initialization from allocation Florian Tobias Schandinat
2011-11-19 12:35 ` [PATCH] fb: split out framebuffer initialization from Bruno Prémont
2011-11-21 16:22 ` [PATCH] fb: split out framebuffer initialization from allocation Timur Tabi
2011-11-21 16:28 ` Timur Tabi
2011-11-21 17:43 ` [PATCH] fb: split out framebuffer initialization from Bruno Prémont
2011-11-21 18:37 ` Timur Tabi [this message]
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=4ECA9A7C.5040402@freescale.com \
--to=timur@freescale.com \
--cc=linux-fbdev@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).