All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gregory CLEMENT <gregory.clement@free-electrons.com>
To: Juergen Beisert <jbe@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH 1/4] ARM STM/i.MX: Allocate memory for framebuffer during probe
Date: Tue, 04 Jan 2011 16:04:42 +0100	[thread overview]
Message-ID: <4D23370A.6040203@free-electrons.com> (raw)
In-Reply-To: <201101041546.53030.jbe@pengutronix.de>

On 01/04/2011 03:46 PM, Juergen Beisert wrote:
> Gregory CLEMENT wrote:
>> With current code when the framebuffer is register, screen_base is not
>> set yet. So when we want to access framebuffer from mmap we get a
>> pointer to 0x0 instead of getting the pointer to the framebuffer
>> address. This patch fix this bug by allocating memory for framebuffer
>> during probe just before registering framebuffer driver.
> 
> Are you sure? See below

It was the value I get at runtime at least.

> 
>> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
[...]
> 
> This probe function sets up the default mode. And register_framebuffer() 
> itself calls stmfb_activate_var() which calls stmfb_memory_mmgt(). So, when 
> the call to register_framebuffer() returns the 'screen_base' should no longer 
> be NULL.

But in register_framebuffer first map_base get its value from screen_base and
it is only after that fb_activate_var is called. And the problem is that mmap
will not get screen_base but map_base and this one is set too early.
Extract from  register_framebuffer() in fb.c:

	info->cdev.dev->map_base = (unsigned long)info->screen_base;
map_base get its value here ------^
	info->cdev.dev->size = info->cdev.size;

	dev = &info->dev;
	dev->priv = info;
	dev->id = id;

	sprintf(dev->name, "fb");

	register_device(&info->dev);
	dev_add_param(dev, "enable", fb_enable_set, NULL, 0);
	dev_set_param(dev, "enable", "0");

	if (info->num_modes && (info->mode_list != NULL) &&
			(info->fbops->fb_activate_var != NULL)) {
		dev_add_param(dev, "mode_name", fb_setup_mode, NULL, 0);
		dev_set_param(dev, "mode_name", info->mode_list[0].name);
fb_activate_var is called here ------------------------^


This code is new for me, maybe I missed something.

> 
> jbe
> 


-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2011-01-04 15:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-04 14:35 [PATCH 1/4] ARM STM/i.MX: Allocate memory for framebuffer during probe Gregory CLEMENT
2011-01-04 14:46 ` Juergen Beisert
2011-01-04 15:04   ` Gregory CLEMENT [this message]
2011-01-04 16:16     ` Juergen Beisert
2011-01-04 16:49       ` Gregory CLEMENT
2011-01-13 15:10         ` Gregory CLEMENT
2011-01-13 15:21           ` Juergen Beisert

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=4D23370A.6040203@free-electrons.com \
    --to=gregory.clement@free-electrons.com \
    --cc=barebox@lists.infradead.org \
    --cc=jbe@pengutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.