[BUG] simplefb not showing any output

[BUG] simplefb not showing any output

[Tom Gundersen]

Hi guys,

I have been trying simplefb from mainline (v3.11-5058-g57d7309), with
a couple of patches on top (one to make simplefb actually load on my
system, posted to x86 earlier today, and one to make it show some
output posted to this list earlier today).

The driver seems to load ok, but sadly it does not give any output. If
I boot via the gummiboot menu the screen remains black, and if I don't
enter the gummiboot menu the screen remains grey (it is a Mac).

Except for that the machine works (I can log on blindly in order to reboot).

Is this a known problem? Any suggestions on where to start debugging?
Any more info I could provide?

The output given during boot is

calling  simplefb_driver_init+0x0/0x14 @ 1
simple-framebuffer simple-framebuffer.0: simplefb: framebuffer at
0x90000000, mapped to 0xffffc90009b00000
simple-framebuffer simple-framebuffer.0: simplefb: format a8r8g8b8,
mode is 1366x768x32, linelengthV32
simple-framebuffer simple-framebuffer.0: fb0: simplefb registered!
initcall simplefb_driver_init+0x0/0x14 returned 0 after 1072 usecs

-t

Re: [BUG] simplefb not showing any output

[David Herrmann]

Hi Tom

( 2 more mails and you might get the fbdev ML right ;) )

On Fri, Sep 6, 2013 at 6:14 PM, Tom Gundersen <teg@jklm.no> wrote:
> Hi guys,
>
> I have been trying simplefb from mainline (v3.11-5058-g57d7309), with
> a couple of patches on top (one to make simplefb actually load on my
> system, posted to x86 earlier today, and one to make it show some
> output posted to this list earlier today).
>
> The driver seems to load ok, but sadly it does not give any output. If
> I boot via the gummiboot menu the screen remains black, and if I don't
> enter the gummiboot menu the screen remains grey (it is a Mac).
>
> Except for that the machine works (I can log on blindly in order to reboot).
>
> Is this a known problem? Any suggestions on where to start debugging?
> Any more info I could provide?
>
> The output given during boot is
>
> calling  simplefb_driver_init+0x0/0x14 @ 1
> simple-framebuffer simple-framebuffer.0: simplefb: framebuffer at
> 0x90000000, mapped to 0xffffc90009b00000
> simple-framebuffer simple-framebuffer.0: simplefb: format a8r8g8b8,
> mode is 1366x768x32, linelengthV32
> simple-framebuffer simple-framebuffer.0: fb0: simplefb registered!
> initcall simplefb_driver_init+0x0/0x14 returned 0 after 1072 usecs

Ok, this looks all good. Few questions:

- Is CONFIG_FB_EFI enabled? If not, please enable it and try again
(hint: CONFIG_FB_VESA doesn't hurt either)

- Could you try the _same_ kernel config but disable CONFIG_X86_SYSFB.
This will avoid creating simple-fb devices and instead load efifb
again. Does efifb work? Does efifb print the same offsets as your
simplefb printk()?

- Are you sure that it's an simplefb problem? Please make sure fbcon
is enabled (could you attach your dmesg output?). You could also try
SSH'ing into the machine and starting some fbdev program (like X with
xf86-video-fbdev installed). Or does fbcon with efifb work?

Thanks
David

Re: [BUG] simplefb not showing any output

[Tom Gundersen]

On Fri, Sep 6, 2013 at 6:57 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> ( 2 more mails and you might get the fbdev ML right ;) )

Modern technology...

> - Is CONFIG_FB_EFI enabled? If not, please enable it and try again
> (hint: CONFIG_FB_VESA doesn't hurt either)

FB_EFI was enabled, FB_VESA was not, but I'll enable it. Out of
interest, how could this affect the situation? If I understand
correctly these drivers won't be loaded as long as simple-framebuffer
is created, or am I missing something?

> - Could you try the _same_ kernel config but disable CONFIG_X86_SYSFB.
> This will avoid creating simple-fb devices and instead load efifb
> again. Does efifb work? Does efifb print the same offsets as your
> simplefb printk()?

Yeah, efifb works fine, I'll double-check everything and note down the offsets.

> - Are you sure that it's an simplefb problem? Please make sure fbcon
> is enabled (could you attach your dmesg output?). You could also try
> SSH'ing into the machine and starting some fbdev program (like X with
> xf86-video-fbdev installed). Or does fbcon with efifb work?

fbcon with efifb works fine (so I guess trying X is not necessary?).

Cheers,

Tom

Re: [BUG] simplefb not showing any output

[David Herrmann]

Hi

On Fri, Sep 6, 2013 at 7:12 PM, Tom Gundersen <teg@jklm.no> wrote:
> On Fri, Sep 6, 2013 at 6:57 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> ( 2 more mails and you might get the fbdev ML right ;) )
>
> Modern technology...
>
>> - Is CONFIG_FB_EFI enabled? If not, please enable it and try again
>> (hint: CONFIG_FB_VESA doesn't hurt either)
>
> FB_EFI was enabled, FB_VESA was not, but I'll enable it. Out of
> interest, how could this affect the situation? If I understand
> correctly these drivers won't be loaded as long as simple-framebuffer
> is created, or am I missing something?

In case you disable X86_SYSFB vesafb might still be used (I wasn't
sure you used efifb). And there might be some nasty Kconfig-select
logic that I overlooked (like FB_BOOT_VESA_SUPPORT).. Just to be sure.

>> - Could you try the _same_ kernel config but disable CONFIG_X86_SYSFB.
>> This will avoid creating simple-fb devices and instead load efifb
>> again. Does efifb work? Does efifb print the same offsets as your
>> simplefb printk()?
>
> Yeah, efifb works fine, I'll double-check everything and note down the offsets.

Just to be clear, efifb still with the new x86-sysfb infrastructure
works? Because I moved some efifb quirks from efifb.c to
x86/kernel/sysfb_efi.c. So even with CONFIG_X86_SYSFB=n the situation
is still different from pre-3.12.

>> - Are you sure that it's an simplefb problem? Please make sure fbcon
>> is enabled (could you attach your dmesg output?). You could also try
>> SSH'ing into the machine and starting some fbdev program (like X with
>> xf86-video-fbdev installed). Or does fbcon with efifb work?
>
> fbcon with efifb works fine (so I guess trying X is not necessary?).

Yeah, if fbcon+efifb works, no need to test X.

Regards
David

Re: [BUG] simplefb not showing any output

[Tom Gundersen]

On Fri, Sep 6, 2013 at 7:19 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> On Fri, Sep 6, 2013 at 7:12 PM, Tom Gundersen <teg@jklm.no> wrote:
>> On Fri, Sep 6, 2013 at 6:57 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>>> ( 2 more mails and you might get the fbdev ML right ;) )
>>
>> Modern technology...
>>
>>> - Is CONFIG_FB_EFI enabled? If not, please enable it and try again
>>> (hint: CONFIG_FB_VESA doesn't hurt either)
>>
>> FB_EFI was enabled, FB_VESA was not, but I'll enable it. Out of
>> interest, how could this affect the situation? If I understand
>> correctly these drivers won't be loaded as long as simple-framebuffer
>> is created, or am I missing something?
>
> In case you disable X86_SYSFB vesafb might still be used (I wasn't
> sure you used efifb). And there might be some nasty Kconfig-select
> logic that I overlooked (like FB_BOOT_VESA_SUPPORT).. Just to be sure.

Ok. All is now enabled and the behavior is the same.

>>> - Could you try the _same_ kernel config but disable CONFIG_X86_SYSFB.
>>> This will avoid creating simple-fb devices and instead load efifb
>>> again. Does efifb work? Does efifb print the same offsets as your
>>> simplefb printk()?
>>
>> Yeah, efifb works fine, I'll double-check everything and note down the offsets.
>
> Just to be clear, efifb still with the new x86-sysfb infrastructure
> works? Because I moved some efifb quirks from efifb.c to
> x86/kernel/sysfb_efi.c. So even with CONFIG_X86_SYSFB=n the situation
> is still different from pre-3.12.

Turns out I must have messed up my initial testing (maybe I only
tested with an old kernel on efifb). With the current kernel both
X86_SYSFB=y (i.e., simplefb) and X86_SYSFB=n (i.e., efifb) are broken.
Only when I log in and "modprobe i915" do I get an fbcon, before that
the screen is black.

For the record here is the relevant dmesg outputs (they appear to be ok):

efifb: probing for efifb
efifb: framebuffer at 0x90000000, mapped to 0xffffc90009b00000, using
4224k, total 4224k
efifb: mode is 1366x768x32, linelengthV32, pages=1
efifb: scrolling: redraw
efifb: Truecolor: size=8:8:8:8, shift$:16:8:0

simple-framebuffer simple-framebuffer.0: framebuffer at 0x90000000,
mapped to 0xffffc90009b00000
simple-framebuffer simple-framebuffer.0: format¨r8g8b8,
mode\x1366x768x32, linelengthV32
simple-framebuffer simple-framebuffer.0: fb0: simplefb registered!

>>> - Are you sure that it's an simplefb problem? Please make sure fbcon
>>> is enabled (could you attach your dmesg output?). You could also try
>>> SSH'ing into the machine and starting some fbdev program (like X with
>>> xf86-video-fbdev installed). Or does fbcon with efifb work?
>>
>> fbcon with efifb works fine (so I guess trying X is not necessary?).
>
> Yeah, if fbcon+efifb works, no need to test X.

Scratch this, I'll have to do some more testing. I'll get back to you.

-t

Re: [BUG] simplefb not showing any output

[Tom Gundersen]

On Sat, Sep 7, 2013 at 1:18 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> On Sat, Sep 7, 2013 at 11:26 AM, Tom Gundersen <teg@jklm.no> wrote:
>> On Fri, Sep 6, 2013 at 6:11 PM, Tom Gundersen <teg@jklm.no> wrote:
>>> The driver seems to load ok, but sadly it does not give any output. If
>>> I boot via the gummiboot menu the screen remains black, and if I don't
>>> enter the gummiboot menu the screen remains grey (it is a Mac).
>>
>> My apologies, this was a config error (I somehow ended up with
>> FRAMEBUFFER_CONSOLE=m, which works fine with inteldrmfb, but obviously
>> not with any of the compiled in ones).
>
> Good, I almost went crazy looking for an error. Does that mean
> simplefb works for you?

Sorry about that! Yes, it now works.

> I guess the x86-sysfb patch is still needed?

Yes, that is still needed.

> Now I only wonder why the i915 issue showed up. Is it also solved with
> a built-in fbcon?

Sadly, no, that problem persists.

A related question: is it expected that simplefb should be
significantly slower than efifb, or is that something worth looking
into? My boot with simplefb is roughly five seconds slower than with
efifb. Coincidentally, I notice the same (or similar slowdown) with
inteldrmfb when I see the oops (but not otherwise).

Cheers,

Tom

Re: [BUG] simplefb not showing any output

[David Herrmann]

[-- Attachment #1: Type: text/plain, Size: 4974 bytes --]

Hi Tom

On Sat, Sep 7, 2013 at 1:47 PM, Tom Gundersen <teg@jklm.no> wrote:
> On Sat, Sep 7, 2013 at 1:18 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> On Sat, Sep 7, 2013 at 11:26 AM, Tom Gundersen <teg@jklm.no> wrote:
>>> On Fri, Sep 6, 2013 at 6:11 PM, Tom Gundersen <teg@jklm.no> wrote:
>>>> The driver seems to load ok, but sadly it does not give any output. If
>>>> I boot via the gummiboot menu the screen remains black, and if I don't
>>>> enter the gummiboot menu the screen remains grey (it is a Mac).
>>>
>>> My apologies, this was a config error (I somehow ended up with
>>> FRAMEBUFFER_CONSOLE=m, which works fine with inteldrmfb, but obviously
>>> not with any of the compiled in ones).
>>
>> Good, I almost went crazy looking for an error. Does that mean
>> simplefb works for you?
>
> Sorry about that! Yes, it now works.

No worries. Going crazy is part of working on the kernel, I guess.

>> I guess the x86-sysfb patch is still needed?
>
> Yes, that is still needed.

Ok, I will keep watching it then.

>> Now I only wonder why the i915 issue showed up. Is it also solved with
>> a built-in fbcon?
>
> Sadly, no, that problem persists.

I will let Daniel know on IRC.

> A related question: is it expected that simplefb should be
> significantly slower than efifb, or is that something worth looking
> into? My boot with simplefb is roughly five seconds slower than with
> efifb. Coincidentally, I notice the same (or similar slowdown) with
> inteldrmfb when I see the oops (but not otherwise).

That is probably related to the missing write-combine tag in ioremap.
Stephen, any objections to this attached patch?
Tom, if this solves the speed-issues, I will send it out once I get home.

Thanks
David

(Patch also attached in case of new-lines issues)

From dbfb8e12166d494cd60823cbe84134d5d1a73ec8 Mon Sep 17 00:00:00 2001
From: David Herrmann <dh.herrmann@gmail.com>
Date: Sat, 7 Sep 2013 14:22:01 +0200
Subject: [PATCH] devm/simplefb: introduce and use devm_ioremap_wc()

We want to use devm_ioremap_nocache() or even devm_ioremap_wc() to speed
up fbdev writes _a lot_. As devm_ioremap_wc() doesn't exist, yet,
introduce it along the way. Note that ioremap_wc() is aliases to
ioremap_nocache() in asm-generic/{io,iomem}.h so we can safely expect all
architectures to either provide it or use the same alias.

Reported-by: Tom Gundersen <teg@jklm.no>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
 drivers/video/simplefb.c |  4 ++--
 include/linux/io.h       |  2 ++
 lib/devres.c             | 28 ++++++++++++++++++++++++++++
 3 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
index 8d78106..a29f1c4 100644
--- a/drivers/video/simplefb.c
+++ b/drivers/video/simplefb.c
@@ -212,8 +212,8 @@ static int simplefb_probe(struct platform_device *pdev)

  info->fbops = &simplefb_ops;
  info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE;
- info->screen_base = devm_ioremap(&pdev->dev, info->fix.smem_start,
- info->fix.smem_len);
+ info->screen_base = devm_ioremap_wc(&pdev->dev, info->fix.smem_start,
+    info->fix.smem_len);
  if (!info->screen_base) {
  framebuffer_release(info);
  return -ENODEV;
diff --git a/include/linux/io.h b/include/linux/io.h
index f4f42fa..c529410 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -62,6 +62,8 @@ void __iomem *devm_ioremap(struct device *dev,
resource_size_t offset,
     unsigned long size);
 void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
     unsigned long size);
+void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
+      unsigned long size);
 void devm_iounmap(struct device *dev, void __iomem *addr);
 int check_signature(const volatile void __iomem *io_addr,
  const unsigned char *signature, int length);
diff --git a/lib/devres.c b/lib/devres.c
index 8235331..34af7a9 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -72,6 +72,34 @@ void __iomem *devm_ioremap_nocache(struct device
*dev, resource_size_t offset,
 EXPORT_SYMBOL(devm_ioremap_nocache);

 /**
+ * devm_ioremap_wc - Managed ioremap_wc()
+ * @dev: Generic device to remap IO address for
+ * @offset: BUS offset to map
+ * @size: Size of map
+ *
+ * Managed ioremap_wc().  Map is automatically unmapped on driver detach.
+ */
+void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
+      unsigned long size)
+{
+ void __iomem **ptr, *addr;
+
+ ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return NULL;
+
+ addr = ioremap_wc(offset, size);
+ if (addr) {
+ *ptr = addr;
+ devres_add(dev, ptr);
+ } else
+ devres_free(ptr);
+
+ return addr;
+}
+EXPORT_SYMBOL(devm_ioremap_wc);
+
+/**
  * devm_iounmap - Managed iounmap()
  * @dev: Generic device to unmap for
  * @addr: Address to unmap
-- 
1.8.4

[-- Attachment #2: 0001-devm-simplefb-introduce-and-use-devm_ioremap_wc.patch --]
[-- Type: application/octet-stream, Size: 3229 bytes --]

From dbfb8e12166d494cd60823cbe84134d5d1a73ec8 Mon Sep 17 00:00:00 2001
From: David Herrmann <dh.herrmann@gmail.com>
Date: Sat, 7 Sep 2013 14:22:01 +0200
Subject: [PATCH] devm/simplefb: introduce and use devm_ioremap_wc()

We want to use devm_ioremap_nocache() or even devm_ioremap_wc() to speed
up fbdev writes _a lot_. As devm_ioremap_wc() doesn't exist, yet,
introduce it along the way. Note that ioremap_wc() is aliases to
ioremap_nocache() in asm-generic/{io,iomem}.h so we can safely expect all
architectures to either provide it or use the same alias.

Reported-by: Tom Gundersen <teg@jklm.no>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
 drivers/video/simplefb.c |  4 ++--
 include/linux/io.h       |  2 ++
 lib/devres.c             | 28 ++++++++++++++++++++++++++++
 3 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
index 8d78106..a29f1c4 100644
--- a/drivers/video/simplefb.c
+++ b/drivers/video/simplefb.c
@@ -212,8 +212,8 @@ static int simplefb_probe(struct platform_device *pdev)
 
 	info->fbops = &simplefb_ops;
 	info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE;
-	info->screen_base = devm_ioremap(&pdev->dev, info->fix.smem_start,
-					 info->fix.smem_len);
+	info->screen_base = devm_ioremap_wc(&pdev->dev, info->fix.smem_start,
+					    info->fix.smem_len);
 	if (!info->screen_base) {
 		framebuffer_release(info);
 		return -ENODEV;
diff --git a/include/linux/io.h b/include/linux/io.h
index f4f42fa..c529410 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -62,6 +62,8 @@ void __iomem *devm_ioremap(struct device *dev, resource_size_t offset,
 			    unsigned long size);
 void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
 				    unsigned long size);
+void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
+			      unsigned long size);
 void devm_iounmap(struct device *dev, void __iomem *addr);
 int check_signature(const volatile void __iomem *io_addr,
 			const unsigned char *signature, int length);
diff --git a/lib/devres.c b/lib/devres.c
index 8235331..34af7a9 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -72,6 +72,34 @@ void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
 EXPORT_SYMBOL(devm_ioremap_nocache);
 
 /**
+ * devm_ioremap_wc - Managed ioremap_wc()
+ * @dev: Generic device to remap IO address for
+ * @offset: BUS offset to map
+ * @size: Size of map
+ *
+ * Managed ioremap_wc().  Map is automatically unmapped on driver detach.
+ */
+void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
+			      unsigned long size)
+{
+	void __iomem **ptr, *addr;
+
+	ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
+	if (!ptr)
+		return NULL;
+
+	addr = ioremap_wc(offset, size);
+	if (addr) {
+		*ptr = addr;
+		devres_add(dev, ptr);
+	} else
+		devres_free(ptr);
+
+	return addr;
+}
+EXPORT_SYMBOL(devm_ioremap_wc);
+
+/**
  * devm_iounmap - Managed iounmap()
  * @dev: Generic device to unmap for
  * @addr: Address to unmap
-- 
1.8.4

Re: [BUG] simplefb not showing any output

[Tom Gundersen]

On Sat, Sep 7, 2013 at 2:25 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> On Sat, Sep 7, 2013 at 1:47 PM, Tom Gundersen <teg@jklm.no> wrote:
>> A related question: is it expected that simplefb should be
>> significantly slower than efifb, or is that something worth looking
>> into? My boot with simplefb is roughly five seconds slower than with
>> efifb. Coincidentally, I notice the same (or similar slowdown) with
>> inteldrmfb when I see the oops (but not otherwise).
>
> That is probably related to the missing write-combine tag in ioremap.
> Stephen, any objections to this attached patch?
> Tom, if this solves the speed-issues, I will send it out once I get home.

This solves the speed issues. Thanks!

Feel free to add my tested-by.

Cheers,

Tom

> From dbfb8e12166d494cd60823cbe84134d5d1a73ec8 Mon Sep 17 00:00:00 2001
> From: David Herrmann <dh.herrmann@gmail.com>
> Date: Sat, 7 Sep 2013 14:22:01 +0200
> Subject: [PATCH] devm/simplefb: introduce and use devm_ioremap_wc()
>
> We want to use devm_ioremap_nocache() or even devm_ioremap_wc() to speed
> up fbdev writes _a lot_. As devm_ioremap_wc() doesn't exist, yet,
> introduce it along the way. Note that ioremap_wc() is aliases to
> ioremap_nocache() in asm-generic/{io,iomem}.h so we can safely expect all
> architectures to either provide it or use the same alias.
>
> Reported-by: Tom Gundersen <teg@jklm.no>
> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> ---
>  drivers/video/simplefb.c |  4 ++--
>  include/linux/io.h       |  2 ++
>  lib/devres.c             | 28 ++++++++++++++++++++++++++++
>  3 files changed, 32 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/simplefb.c b/drivers/video/simplefb.c
> index 8d78106..a29f1c4 100644
> --- a/drivers/video/simplefb.c
> +++ b/drivers/video/simplefb.c
> @@ -212,8 +212,8 @@ static int simplefb_probe(struct platform_device *pdev)
>
>   info->fbops = &simplefb_ops;
>   info->flags = FBINFO_DEFAULT | FBINFO_MISC_FIRMWARE;
> - info->screen_base = devm_ioremap(&pdev->dev, info->fix.smem_start,
> - info->fix.smem_len);
> + info->screen_base = devm_ioremap_wc(&pdev->dev, info->fix.smem_start,
> +    info->fix.smem_len);
>   if (!info->screen_base) {
>   framebuffer_release(info);
>   return -ENODEV;
> diff --git a/include/linux/io.h b/include/linux/io.h
> index f4f42fa..c529410 100644
> --- a/include/linux/io.h
> +++ b/include/linux/io.h
> @@ -62,6 +62,8 @@ void __iomem *devm_ioremap(struct device *dev,
> resource_size_t offset,
>      unsigned long size);
>  void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
>      unsigned long size);
> +void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
> +      unsigned long size);
>  void devm_iounmap(struct device *dev, void __iomem *addr);
>  int check_signature(const volatile void __iomem *io_addr,
>   const unsigned char *signature, int length);
> diff --git a/lib/devres.c b/lib/devres.c
> index 8235331..34af7a9 100644
> --- a/lib/devres.c
> +++ b/lib/devres.c
> @@ -72,6 +72,34 @@ void __iomem *devm_ioremap_nocache(struct device
> *dev, resource_size_t offset,
>  EXPORT_SYMBOL(devm_ioremap_nocache);
>
>  /**
> + * devm_ioremap_wc - Managed ioremap_wc()
> + * @dev: Generic device to remap IO address for
> + * @offset: BUS offset to map
> + * @size: Size of map
> + *
> + * Managed ioremap_wc().  Map is automatically unmapped on driver detach.
> + */
> +void __iomem *devm_ioremap_wc(struct device *dev, resource_size_t offset,
> +      unsigned long size)
> +{
> + void __iomem **ptr, *addr;
> +
> + ptr = devres_alloc(devm_ioremap_release, sizeof(*ptr), GFP_KERNEL);
> + if (!ptr)
> + return NULL;
> +
> + addr = ioremap_wc(offset, size);
> + if (addr) {
> + *ptr = addr;
> + devres_add(dev, ptr);
> + } else
> + devres_free(ptr);
> +
> + return addr;
> +}
> +EXPORT_SYMBOL(devm_ioremap_wc);
> +
> +/**
>   * devm_iounmap - Managed iounmap()
>   * @dev: Generic device to unmap for
>   * @addr: Address to unmap
> --
> 1.8.4

Re: [BUG] simplefb not showing any output

[Alexandre Courbot]

On Sat, Sep 7, 2013 at 9:25 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> From dbfb8e12166d494cd60823cbe84134d5d1a73ec8 Mon Sep 17 00:00:00 2001
> From: David Herrmann <dh.herrmann@gmail.com>
> Date: Sat, 7 Sep 2013 14:22:01 +0200
> Subject: [PATCH] devm/simplefb: introduce and use devm_ioremap_wc()
>
> We want to use devm_ioremap_nocache() or even devm_ioremap_wc() to speed
> up fbdev writes _a lot_. As devm_ioremap_wc() doesn't exist, yet,
> introduce it along the way. Note that ioremap_wc() is aliases to
> ioremap_nocache() in asm-generic/{io,iomem}.h so we can safely expect all
> architectures to either provide it or use the same alias.
>
> Reported-by: Tom Gundersen <teg@jklm.no>
> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>

Tried this on SHIELD, and it dramatically increases performance.

Tested-by: Alexandre Courbot <acourbot@nvidia.com>

Alex.

Re: [BUG] simplefb not showing any output

[Alexandre Courbot]

On Mon, Sep 9, 2013 at 11:36 AM, Alexandre Courbot <gnurou@gmail.com> wrote:
> On Sat, Sep 7, 2013 at 9:25 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>> From dbfb8e12166d494cd60823cbe84134d5d1a73ec8 Mon Sep 17 00:00:00 2001
>> From: David Herrmann <dh.herrmann@gmail.com>
>> Date: Sat, 7 Sep 2013 14:22:01 +0200
>> Subject: [PATCH] devm/simplefb: introduce and use devm_ioremap_wc()
>>
>> We want to use devm_ioremap_nocache() or even devm_ioremap_wc() to speed
>> up fbdev writes _a lot_. As devm_ioremap_wc() doesn't exist, yet,
>> introduce it along the way. Note that ioremap_wc() is aliases to
>> ioremap_nocache() in asm-generic/{io,iomem}.h so we can safely expect all
>> architectures to either provide it or use the same alias.
>>
>> Reported-by: Tom Gundersen <teg@jklm.no>
>> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
>> Cc: Stephen Warren <swarren@wwwdotorg.org>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>
> Tried this on SHIELD, and it dramatically increases performance.
>
> Tested-by: Alexandre Courbot <acourbot@nvidia.com>

Maybe the patch should be split into two though, one that adds
devm_ioremap_wc() and another that takes advantage of it for simplefb.

Alex.

Re: [BUG] simplefb not showing any output

[David Herrmann]

Hi

On Mon, Sep 9, 2013 at 4:40 AM, Alexandre Courbot <gnurou@gmail.com> wrote:
> On Mon, Sep 9, 2013 at 11:36 AM, Alexandre Courbot <gnurou@gmail.com> wrote:
>> On Sat, Sep 7, 2013 at 9:25 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>>> From dbfb8e12166d494cd60823cbe84134d5d1a73ec8 Mon Sep 17 00:00:00 2001
>>> From: David Herrmann <dh.herrmann@gmail.com>
>>> Date: Sat, 7 Sep 2013 14:22:01 +0200
>>> Subject: [PATCH] devm/simplefb: introduce and use devm_ioremap_wc()
>>>
>>> We want to use devm_ioremap_nocache() or even devm_ioremap_wc() to speed
>>> up fbdev writes _a lot_. As devm_ioremap_wc() doesn't exist, yet,
>>> introduce it along the way. Note that ioremap_wc() is aliases to
>>> ioremap_nocache() in asm-generic/{io,iomem}.h so we can safely expect all
>>> architectures to either provide it or use the same alias.
>>>
>>> Reported-by: Tom Gundersen <teg@jklm.no>
>>> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
>>> Cc: Stephen Warren <swarren@wwwdotorg.org>
>>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>> Cc: Andrew Morton <akpm@linux-foundation.org>
>>
>> Tried this on SHIELD, and it dramatically increases performance.
>>
>> Tested-by: Alexandre Courbot <acourbot@nvidia.com>
>
> Maybe the patch should be split into two though, one that adds
> devm_ioremap_wc() and another that takes advantage of it for simplefb.

Thanks for testing! I added your tested-by. I also changed the patches
slightly to no longer use devm_*. The *_wc patch is now split off,
too. I will send it later today.

Thanks
David

Re: [BUG] simplefb not showing any output

[Stephen Warren]

On 09/07/2013 06:25 AM, David Herrmann wrote:
> On Sat, Sep 7, 2013 at 1:47 PM, Tom Gundersen <teg@jklm.no> wrote:
...
>> A related question: is it expected that simplefb should be
>> significantly slower than efifb, or is that something worth looking
>> into? My boot with simplefb is roughly five seconds slower than with
>> efifb. Coincidentally, I notice the same (or similar slowdown) with
>> inteldrmfb when I see the oops (but not otherwise).
> 
> That is probably related to the missing write-combine tag in ioremap.
> Stephen, any objections to this attached patch?
> Tom, if this solves the speed-issues, I will send it out once I get home.
> 
> Thanks
> David
> 
> (Patch also attached in case of new-lines issues)
> 
> From dbfb8e12166d494cd60823cbe84134d5d1a73ec8 Mon Sep 17 00:00:00 2001
> From: David Herrmann <dh.herrmann@gmail.com>
> Date: Sat, 7 Sep 2013 14:22:01 +0200
> Subject: [PATCH] devm/simplefb: introduce and use devm_ioremap_wc()
> 
> We want to use devm_ioremap_nocache() or even devm_ioremap_wc() to speed
> up fbdev writes _a lot_. As devm_ioremap_wc() doesn't exist, yet,
> introduce it along the way. Note that ioremap_wc() is aliases to
> ioremap_nocache() in asm-generic/{io,iomem}.h so we can safely expect all
> architectures to either provide it or use the same alias.

I'm fine with this so long as wc mappings are always possible, or
automatically fall back to uc if not. This certainly works on Tegra, and
I'll try to remember to test it on Raspberry Pi tonight.

Re: [BUG] simplefb not showing any output

[Stephen Warren]

On 09/07/2013 06:25 AM, David Herrmann wrote:
> On Sat, Sep 7, 2013 at 1:47 PM, Tom Gundersen <teg@jklm.no> wrote:
...
>> A related question: is it expected that simplefb should be
>> significantly slower than efifb, or is that something worth looking
>> into? My boot with simplefb is roughly five seconds slower than with
>> efifb. Coincidentally, I notice the same (or similar slowdown) with
>> inteldrmfb when I see the oops (but not otherwise).
> 
> That is probably related to the missing write-combine tag in ioremap.
> Stephen, any objections to this attached patch?
> Tom, if this solves the speed-issues, I will send it out once I get home.
> 
> Thanks
> David
> 
> (Patch also attached in case of new-lines issues)
> 
> From dbfb8e12166d494cd60823cbe84134d5d1a73ec8 Mon Sep 17 00:00:00 2001
> From: David Herrmann <dh.herrmann@gmail.com>
> Date: Sat, 7 Sep 2013 14:22:01 +0200
> Subject: [PATCH] devm/simplefb: introduce and use devm_ioremap_wc()
> 
> We want to use devm_ioremap_nocache() or even devm_ioremap_wc() to speed
> up fbdev writes _a lot_. As devm_ioremap_wc() doesn't exist, yet,
> introduce it along the way. Note that ioremap_wc() is aliases to
> ioremap_nocache() in asm-generic/{io,iomem}.h so we can safely expect all
> architectures to either provide it or use the same alias.

OK, that works fine on the Raspberry Pi too, so,
Tested-by: Stephen Warren <swarren@wwwdotorg.org>

Re: [BUG] simplefb not showing any output

[David Herrmann]

Hi

On Tue, Sep 10, 2013 at 4:34 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 09/07/2013 06:25 AM, David Herrmann wrote:
>> On Sat, Sep 7, 2013 at 1:47 PM, Tom Gundersen <teg@jklm.no> wrote:
> ...
>>> A related question: is it expected that simplefb should be
>>> significantly slower than efifb, or is that something worth looking
>>> into? My boot with simplefb is roughly five seconds slower than with
>>> efifb. Coincidentally, I notice the same (or similar slowdown) with
>>> inteldrmfb when I see the oops (but not otherwise).
>>
>> That is probably related to the missing write-combine tag in ioremap.
>> Stephen, any objections to this attached patch?
>> Tom, if this solves the speed-issues, I will send it out once I get home.
>>
>> Thanks
>> David
>>
>> (Patch also attached in case of new-lines issues)
>>
>> From dbfb8e12166d494cd60823cbe84134d5d1a73ec8 Mon Sep 17 00:00:00 2001
>> From: David Herrmann <dh.herrmann@gmail.com>
>> Date: Sat, 7 Sep 2013 14:22:01 +0200
>> Subject: [PATCH] devm/simplefb: introduce and use devm_ioremap_wc()
>>
>> We want to use devm_ioremap_nocache() or even devm_ioremap_wc() to speed
>> up fbdev writes _a lot_. As devm_ioremap_wc() doesn't exist, yet,
>> introduce it along the way. Note that ioremap_wc() is aliases to
>> ioremap_nocache() in asm-generic/{io,iomem}.h so we can safely expect all
>> architectures to either provide it or use the same alias.
>
> OK, that works fine on the Raspberry Pi too, so,
> Tested-by: Stephen Warren <swarren@wwwdotorg.org>

Back from the US and all patches sent out. Sorry for the delay. If I
missed something, please let me know.

Thanks for your feedback!
David