linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


      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).