* Re: [PATCH] video: imxfb: Use regulator API w =?UTF-8?B?aXRoIExDRCBjbGFzc
From: Alexander Shiyan @ 2013-12-23 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20131223082107.GF26070@S2101-09.ap.freescale.net>
PiBPbiBTYXQsIERlYyAyMSwgMjAxMyBhdCAwMzowODowMFBNICswNDAwLCBBbGV4YW5kZXIgU2hp
eWFuIHdyb3RlOgo+ID4gVGhpcyBwYXRjaCByZXBsYWNlcyBjdXN0b20gbGNkX3Bvd2VyKCkgY2Fs
bGJhY2sgd2l0aAo+ID4gcmVndWxhdG9yIEFQSSBvdmVyIExDRCBjbGFzcy4KPiAKPiBGWUkuICBE
ZW5pcycgZWZmb3J0IG9uIHRoaXMgYWxyZWFkeSBnb2VzIHRvIHYxMy4KPiAKPiBodHRwOi8vdGhy
ZWFkLmdtYW5lLm9yZy9nbWFuZS5saW51eC5wb3J0cy5hcm0ua2VybmVsLzI4NTMyNgoKSG1tLCBP
SywgYnV0IGhhdmluZyBMQ0QgY2xhc3MgY291bGQgcmVzb2x2ZSBvdXIgcHJvYmxlbXMgd2l0aCBj
b250cmFzdCBjb250cm9sLgpodHRwczovL3d3dy5tYWlsLWFyY2hpdmUuY29tL2RldmljZXRyZWVA
dmdlci5rZXJuZWwub3JnL21zZzA3NjYwLmh0bWwKCi0tLQo
^ permalink raw reply
* Re: [PATCH] video: imxfb: Use regulator API with LCD class for powering
From: Shawn Guo @ 2013-12-23 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1387787053.605757144@f413.i.mail.ru>
On Mon, Dec 23, 2013 at 12:24:13PM +0400, Alexander Shiyan wrote:
> > On Sat, Dec 21, 2013 at 03:08:00PM +0400, Alexander Shiyan wrote:
> > > This patch replaces custom lcd_power() callback with
> > > regulator API over LCD class.
> >
> > FYI. Denis' effort on this already goes to v13.
> >
> > http://thread.gmane.org/gmane.linux.ports.arm.kernel/285326
>
> Hmm, OK, but having LCD class could resolve our problems with contrast control.
> https://www.mail-archive.com/devicetree@vger.kernel.org/msg07660.html
I just want to make sure you two are aware of each other's work.
Shawn
^ permalink raw reply
* [PATCH] video/imxfb: add more range-checking for right and left margin values
From: Paul Fertser @ 2013-12-24 9:43 UTC (permalink / raw)
To: linux-fbdev
A user not familiar with this LCD controller might assume it's
possible to use arbitrary short horizontal margins if the display
allows that. Make it clear it's not.
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
---
drivers/video/imxfb.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/imxfb.c b/drivers/video/imxfb.c
index 44ee678..103e175 100644
--- a/drivers/video/imxfb.c
+++ b/drivers/video/imxfb.c
@@ -671,10 +671,10 @@ static int imxfb_activate_var(struct fb_var_screeninfo *var, struct fb_info *inf
if (var->hsync_len < 1 || var->hsync_len > 64)
printk(KERN_ERR "%s: invalid hsync_len %d\n",
info->fix.id, var->hsync_len);
- if (var->left_margin > 255)
+ if (var->left_margin > 255 || var->left_margin < 3)
printk(KERN_ERR "%s: invalid left_margin %d\n",
info->fix.id, var->left_margin);
- if (var->right_margin > 255)
+ if (var->right_margin > 255 || var->right_margin < 1)
printk(KERN_ERR "%s: invalid right_margin %d\n",
info->fix.id, var->right_margin);
if (var->yres < 1 || var->yres > ymax_mask)
--
1.7.3.4
^ permalink raw reply related
* [PATCH] fbcon: Fix memory leak in fbcon_exit().
From: Masami Ichikawa @ 2013-12-25 14:47 UTC (permalink / raw)
To: plagnioj, tomi.valkeinen, linux-fbdev
Cc: airlied, udknight, gregkh, akpm, tiwai, linux-kernel, masami256
kmemleak reported a memory leak as below.
unreferenced object 0xffff880036ca84c0 (size 16):
comm "swapper/0", pid 1, jiffies 4294877407 (age 4434.633s)
hex dump (first 16 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ................
backtrace:
[<ffffffff814ed01e>] kmemleak_alloc+0x4e/0xb0
[<ffffffff8118913c>] __kmalloc+0x1fc/0x290
[<ffffffff81302c9e>] bit_cursor+0x24e/0x6c0
[<ffffffff812ff2f4>] fbcon_cursor+0x154/0x1d0
[<ffffffff813675d8>] hide_cursor+0x28/0xa0
[<ffffffff81368acf>] update_region+0x6f/0x90
[<ffffffff81300268>] fbcon_switch+0x518/0x550
[<ffffffff813695b9>] redraw_screen+0x189/0x240
[<ffffffff8136a0e0>] do_bind_con_driver+0x360/0x380
[<ffffffff8136a6e4>] do_take_over_console+0x114/0x1c0
[<ffffffff812fdc83>] do_fbcon_takeover+0x63/0xd0
[<ffffffff813023e5>] fbcon_event_notify+0x605/0x720
[<ffffffff81501dcc>] notifier_call_chain+0x4c/0x70
[<ffffffff81087f8d>] __blocking_notifier_call_chain+0x4d/0x70
[<ffffffff81087fc6>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff812f201b>] fb_notifier_call_chain+0x1b/0x20
In this case ops->cursor_state.mask is allocated in bit_cursor() but
not freed in fbcon_exit(). So, fbcon_exit() needs to free buffer in its
process.
In the case, fbcon_exit() was called from fbcon_deinit() when driver
called remove_conflicting_framebuffers().
Signed-off-by: Masami Ichikawa <masami256@gmail.com>
---
drivers/video/console/fbcon.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index cd8a802..4f02375 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -3561,6 +3561,7 @@ static void fbcon_exit(void)
fbcon_del_cursor_timer(info);
kfree(ops->cursor_src);
+ kfree(ops->cursor_state.mask);
kfree(info->fbcon_par);
info->fbcon_par = NULL;
}
--
1.8.4.2
^ permalink raw reply related
* Re: [PATCH] drivers: video: Remove unused function genericbl_limit_intensity() in generic_bl.c
From: Jingoo Han @ 2013-12-27 2:21 UTC (permalink / raw)
To: 'Rashika Kheria', 'Andrew Morton'
Cc: 'Josh Triplett', linux-kernel,
'Jean-Christophe Plagniol-Villard',
'Tomi Valkeinen', linux-fbdev, 'Jingoo Han',
'Eric Miao'
In-Reply-To: <20131216142423.GB24172@leaf>
On Monday, December 16, 2013 11:24 PM, Josh Triplett wrote:
> On Mon, Dec 16, 2013 at 04:51:10PM +0530, Rashika Kheria wrote:
> > Removes unused function genericbl_limit_intensity() in
> > backlight/generic_bl.c.
> >
> > This eliminates the following warning in backlight/generic_bl.c:
> > drivers/video/backlight/generic_bl.c:59:6: warning: no previous prototype for
> ‘genericbl_limit_intensity’ [-Wmissing-prototypes]
> >
> > Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
>
> Reviewed-by: Josh Triplett <josh@joshtriplett.org>
(+cc Andrew Morton, Eric Miao)
Acked-by: Jingoo Han <jg1.han@samsung.com>
Best regards,
Jingoo Han
>
> > drivers/video/backlight/generic_bl.c | 18 ------------------
> > 1 file changed, 18 deletions(-)
> >
> > diff --git a/drivers/video/backlight/generic_bl.c b/drivers/video/backlight/generic_bl.c
> > index 5d8d652..67dfb93 100644
> > --- a/drivers/video/backlight/generic_bl.c
> > +++ b/drivers/video/backlight/generic_bl.c
> > @@ -52,24 +52,6 @@ static int genericbl_get_intensity(struct backlight_device *bd)
> > return genericbl_intensity;
> > }
> >
> > -/*
> > - * Called when the battery is low to limit the backlight intensity.
> > - * If limit=0 clear any limit, otherwise limit the intensity
> > - */
> > -void genericbl_limit_intensity(int limit)
> > -{
> > - struct backlight_device *bd = generic_backlight_device;
> > -
> > - mutex_lock(&bd->ops_lock);
> > - if (limit)
> > - bd->props.state |= GENERICBL_BATTLOW;
> > - else
> > - bd->props.state &= ~GENERICBL_BATTLOW;
> > - backlight_update_status(generic_backlight_device);
> > - mutex_unlock(&bd->ops_lock);
> > -}
> > -EXPORT_SYMBOL(genericbl_limit_intensity);
> > -
> > static const struct backlight_ops genericbl_ops = {
> > .options = BL_CORE_SUSPENDRESUME,
> > .get_brightness = genericbl_get_intensity,
> > --
> > 1.7.9.5
> >
^ permalink raw reply
* [PATCH] fbcon: trivial optimization for fbcon_exit
From: Wang YanQing @ 2013-12-27 2:39 UTC (permalink / raw)
To: tomi.valkeinen
Cc: plagnioj, airlied, gregkh, akpm, kamal, linux-fbdev, linux-kernel
Break out as soon as we find a mapped entry con2fb_map.
Signed-off-by: Wang YanQing <udknight@gmail.com>
---
drivers/video/console/fbcon.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index cd8a802..f39931f 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -3547,8 +3547,10 @@ static void fbcon_exit(void)
"no"));
for (j = first_fb_vc; j <= last_fb_vc; j++) {
- if (con2fb_map[j] = i)
+ if (con2fb_map[j] = i) {
mapped = 1;
+ break;
+ }
}
if (mapped) {
--
1.8.3.4.8.g69490f3.dirty
^ permalink raw reply related
* [PATCH 1/4] video: ep93xx: Cleanup video-ep93xx.h header
From: Sachin Kamat @ 2013-12-30 6:34 UTC (permalink / raw)
To: linux-fbdev
Commit a3b2924547a7 ("ARM: ep93xx: move platform_data definitions")
moved the file to the current location but forgot to remove the pointer
to its previous location. Clean it up. While at it also change the header
file protection macros appropriately.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
include/linux/platform_data/video-ep93xx.h | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/include/linux/platform_data/video-ep93xx.h b/include/linux/platform_data/video-ep93xx.h
index d5ae11d7c453..92fc2b2232e7 100644
--- a/include/linux/platform_data/video-ep93xx.h
+++ b/include/linux/platform_data/video-ep93xx.h
@@ -1,9 +1,5 @@
-/*
- * arch/arm/mach-ep93xx/include/mach/fb.h
- */
-
-#ifndef __ASM_ARCH_EP93XXFB_H
-#define __ASM_ARCH_EP93XXFB_H
+#ifndef __VIDEO_EP93XX_H
+#define __VIDEO_EP93XX_H
struct platform_device;
struct fb_videomode;
@@ -53,4 +49,4 @@ struct ep93xxfb_mach_info {
void (*blank)(int blank_mode, struct fb_info *info);
};
-#endif /* __ASM_ARCH_EP93XXFB_H */
+#endif /* __VIDEO_EP93XX_H */
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/4] video: msm: Cleanup video-msm_fb.h header
From: Sachin Kamat @ 2013-12-30 6:34 UTC (permalink / raw)
To: linux-fbdev
Commit 1ef21f6343ff ("ARM: msm: move platform_data definitions")
moved the file to the current location but forgot to remove the pointer
to its previous location. Clean it up.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
include/linux/platform_data/video-msm_fb.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/platform_data/video-msm_fb.h b/include/linux/platform_data/video-msm_fb.h
index 1f4fc81b3d8f..31449be3eadb 100644
--- a/include/linux/platform_data/video-msm_fb.h
+++ b/include/linux/platform_data/video-msm_fb.h
@@ -1,5 +1,4 @@
-/* arch/arm/mach-msm/include/mach/msm_fb.h
- *
+/*
* Internal shared definitions for various MSM framebuffer parts.
*
* Copyright (C) 2007 Google Incorporated
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/4] video: pxa: Cleanup video-pxafb.h header
From: Sachin Kamat @ 2013-12-30 6:34 UTC (permalink / raw)
To: linux-fbdev
Commit 293b2da1b611 ("ARM: pxa: move platform_data definitions")
moved the file to the current location but forgot to remove the pointer
to its previous location. Clean it up.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
include/linux/platform_data/video-pxafb.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/linux/platform_data/video-pxafb.h b/include/linux/platform_data/video-pxafb.h
index 486b4c519ae2..07c6c1e153f8 100644
--- a/include/linux/platform_data/video-pxafb.h
+++ b/include/linux/platform_data/video-pxafb.h
@@ -1,6 +1,4 @@
/*
- * arch/arm/mach-pxa/include/mach/pxafb.h
- *
* Support for the xscale frame buffer.
*
* Author: Jean-Frederic Clere
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/4] video: pxa168fb: Cleanup pxa168fb.h file
From: Sachin Kamat @ 2013-12-30 6:34 UTC (permalink / raw)
To: linux-fbdev
Remove incorrect file reference in comments section.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Eric Miao <eric.y.miao@gmail.com>
---
include/video/pxa168fb.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/include/video/pxa168fb.h b/include/video/pxa168fb.h
index 8c2f385a90ea..84cbb1f69ea6 100644
--- a/include/video/pxa168fb.h
+++ b/include/video/pxa168fb.h
@@ -1,6 +1,4 @@
/*
- * linux/arch/arm/mach-mmp/include/mach/pxa168fb.h
- *
* Copyright (C) 2009 Marvell International Ltd.
*
* This program is free software; you can redistribute it and/or modify
--
1.7.9.5
^ permalink raw reply related
* [PATCH] fonts:Kconfig: fix default enable FONT_8x8 and FONT_8x16 at the same time
From: Wang YanQing @ 2013-12-30 6:53 UTC (permalink / raw)
To: linux-fbdev
FONT_8x8 and FONT_8x16 have the same default value line:
"default y if !SPARC && !FONTS"
I test run "make defconfig" for x86 will enable FONT_8x8 and FONT_8x16 at
the same time.
This patch fix it, because FONT_AUTOSELECT choice FONT_8x16, so
I decide to disable FONT_8x8, this patch will reduce size of kernel.
Signed-off-by: Wang YanQing <udknight@gmail.com>
---
lib/fonts/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/lib/fonts/Kconfig b/lib/fonts/Kconfig
index 34fd931..11d3758 100644
--- a/lib/fonts/Kconfig
+++ b/lib/fonts/Kconfig
@@ -23,7 +23,6 @@ config FONTS
config FONT_8x8
bool "VGA 8x8 font" if FONTS
depends on FRAMEBUFFER_CONSOLE || STI_CONSOLE
- default y if !SPARC && !FONTS
help
This is the "high resolution" font for the VGA frame buffer (the one
provided by the text console 80x50 (and higher) modes).
--
1.8.3.4.8.g69490f3.dirty
^ permalink raw reply related
* Re: [PATCH] fonts:Kconfig: fix default enable FONT_8x8 and FONT_8x16 at the same time
From: Geert Uytterhoeven @ 2013-12-30 8:51 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20131230065303.GA6640@udknight>
On Mon, Dec 30, 2013 at 7:53 AM, Wang YanQing <udknight@gmail.com> wrote:
> FONT_8x8 and FONT_8x16 have the same default value line:
> "default y if !SPARC && !FONTS"
>
> I test run "make defconfig" for x86 will enable FONT_8x8 and FONT_8x16 at
> the same time.
>
> This patch fix it, because FONT_AUTOSELECT choice FONT_8x16, so
> I decide to disable FONT_8x8, this patch will reduce size of kernel.
... at the expense of losing FONT_8x8...
In another email, you wrote:
| Sorry for confusion, the default behavior enable FONT_8x8 and FONT_8x16,
| FONT_8x8 eat ~50KB memory, but kernel never use it. I think this is not
| good default behavior.
Whether FONT_8x8 or FONT_8x16 is used depends on your screen resolution,
cfr. lib/fonts/font.c:get_default_font().
If you don't want to compile in FONT_8x8, then please enable CONFIG_FONTS,
and disable CONFIG_FONT_8x8.
> Signed-off-by: Wang YanQing <udknight@gmail.com>
> ---
> lib/fonts/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/lib/fonts/Kconfig b/lib/fonts/Kconfig
> index 34fd931..11d3758 100644
> --- a/lib/fonts/Kconfig
> +++ b/lib/fonts/Kconfig
> @@ -23,7 +23,6 @@ config FONTS
> config FONT_8x8
> bool "VGA 8x8 font" if FONTS
> depends on FRAMEBUFFER_CONSOLE || STI_CONSOLE
> - default y if !SPARC && !FONTS
> help
> This is the "high resolution" font for the VGA frame buffer (the one
> provided by the text console 80x50 (and higher) modes).
> --
> 1.8.3.4.8.g69490f3.dirty
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 0/2] omapfb: option to use coherent dma mem
From: Tomi Valkeinen @ 2013-12-30 13:19 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This is a bit refined version from the patch sent by Ivaylo.
So Ivaylo asked for an exclusive memory area for omapfb, so that the
allocations would not fail, and Vaibhav asked for reserving the fb at a
specified physical address, so that the bootloader can pass the fb to the
kernel. Those are a bit linked issues, and these patches try to accomplish
both.
This series is somewhat experimental, as I'm not so familiar with the dma api,
but, well, this seemed to work for the tests I did.
Tomi
Tomi Valkeinen (2):
ARM: omapfb: add coherent dma memory support
omapfb: add support to reserve fb at specified phys address
arch/arm/mach-omap2/common.c | 1 +
arch/arm/mach-omap2/common.h | 2 +
arch/arm/mach-omap2/fb.c | 77 +++++++++++++++++++++++++++++++-
drivers/video/omap2/omapfb/omapfb-main.c | 36 +++++++++++----
drivers/video/omap2/omapfb/omapfb.h | 1 +
5 files changed, 107 insertions(+), 10 deletions(-)
--
1.8.3.2
^ permalink raw reply
* [PATCH 1/2] ARM: omapfb: add coherent dma memory support
From: Tomi Valkeinen @ 2013-12-30 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1388409550-10720-1-git-send-email-tomi.valkeinen@ti.com>
The omapfb driver uses dma_alloc to reserve memory for the framebuffers.
However, on some use cases, even when CMA is in use, it's quite probable
that omapfb fails to allocate the fb, either due to not enough free dma
memory, fragmented dma memory, or CMA failing to make enough contiguous
space.
This patch adds a kernel cmdline parameter 'omapfb_vram' which can be
used to give the size of a memory area reserved exclusively for omapfb,
and optionally a physical address where the memory area is reserved.
The memory area is reserved with memblock, and assigned to omapfb with
dma_declare_coherent_memory. The dma_alloc function will first try to
allocate the fb from the coherent memory area, and if that fails, it'll
use the normal method of allocation.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Ivaylo Dimitrov <freemangordon@abv.bg>
---
arch/arm/mach-omap2/common.c | 1 +
arch/arm/mach-omap2/common.h | 2 ++
arch/arm/mach-omap2/fb.c | 77 +++++++++++++++++++++++++++++++++++++++++++-
3 files changed, 79 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 2dabb9ecb986..9beecded0380 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -33,4 +33,5 @@ void __init omap_reserve(void)
omap_dsp_reserve_sdram_memblock();
omap_secure_ram_reserve_memblock();
omap_barrier_reserve_memblock();
+ omap_fb_reserve_memblock();
}
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index e30ef6797c63..21afdc0fe15e 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -304,6 +304,8 @@ extern void omap_reserve(void);
struct omap_hwmod;
extern int omap_dss_reset(struct omap_hwmod *);
+extern void omap_fb_reserve_memblock(void);
+
/* SoC specific clock initializer */
extern int (*omap_clk_init)(void);
diff --git a/arch/arm/mach-omap2/fb.c b/arch/arm/mach-omap2/fb.c
index 26e28e94f625..80630329e508 100644
--- a/arch/arm/mach-omap2/fb.c
+++ b/arch/arm/mach-omap2/fb.c
@@ -30,9 +30,11 @@
#include <linux/dma-mapping.h>
#include <asm/mach/map.h>
+#include <asm/memblock.h>
#include "soc.h"
#include "display.h"
+#include "common.h"
#ifdef CONFIG_OMAP2_VRFB
@@ -106,10 +108,83 @@ static struct platform_device omap_fb_device = {
.num_resources = 0,
};
+static phys_addr_t omapfb_mem_base __initdata;
+static phys_addr_t omapfb_mem_size __initdata;
+
+static int __init early_omapfb_vram(char *p)
+{
+ omapfb_mem_size = memparse(p, &p);
+
+ if (!omapfb_mem_size) {
+ pr_err("omapfb: bad size for 'omapfb_vram' param\n");
+ return 0;
+ }
+
+ if (*p = '@') {
+ omapfb_mem_base = memparse(p + 1, NULL);
+
+ if (!omapfb_mem_base) {
+ pr_err("omapfb: bad addr for 'omapfb_vram' param\n");
+ omapfb_mem_size = 0;
+ return 0;
+ }
+ }
+
+ return 0;
+}
+early_param("omapfb_vram", early_omapfb_vram);
+
+void __init omap_fb_reserve_memblock(void)
+{
+ int r;
+
+ if (!omapfb_mem_size)
+ return;
+
+ if (omapfb_mem_base) {
+ r = memblock_reserve(omapfb_mem_base, omapfb_mem_size);
+
+ if (r) {
+ pr_err("omapfb: memblock_reserve failed: %d\n", r);
+ return;
+ }
+ } else {
+ omapfb_mem_base = memblock_alloc(omapfb_mem_size, SZ_1M);
+
+ if (!omapfb_mem_base) {
+ pr_err("omapfb: memblock_alloc failed\n");
+ return;
+ }
+ }
+
+ memblock_free(omapfb_mem_base, omapfb_mem_size);
+ memblock_remove(omapfb_mem_base, omapfb_mem_size);
+
+ pr_info("omapfb: reserved %pa bytes at %pa\n",
+ &omapfb_mem_size, &omapfb_mem_base);
+}
+
int __init omap_init_fb(void)
{
- return platform_device_register(&omap_fb_device);
+ int r;
+
+ r = platform_device_register(&omap_fb_device);
+
+ if (r)
+ return r;
+
+ if (!omapfb_mem_base)
+ return 0;
+
+ r = dma_declare_coherent_memory(&omap_fb_device.dev,
+ omapfb_mem_base, omapfb_mem_base,
+ omapfb_mem_size, DMA_MEMORY_MAP);
+ if (!(r & DMA_MEMORY_MAP))
+ pr_err("omapfb: dma_declare_coherent_memory failed\n");
+
+ return 0;
}
+
#else
int __init omap_init_fb(void) { return 0; }
#endif
--
1.8.3.2
^ permalink raw reply related
* [PATCH 2/2] omapfb: add support to reserve fb at specified phys address
From: Tomi Valkeinen @ 2013-12-30 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1388409550-10720-1-git-send-email-tomi.valkeinen@ti.com>
The previous patch added support to reserve an exclusive coherent area
for omapfb. This patch adds support to allocate a fb from a specified
physical address inside that coherent area.
This can be used to "pass" a framebuffer from the bootloader to the
kernel: the bootloader sets up the DSS hardware to display a piece of
memory, and gives the address and size of the used piece of memory to
the kernel via omapfb_vram and omapfb.vram cmdline parameters.
Note that the DSS driver itself does not yet support this, and the DSS
hardware is reset at kernel init. This means that the display will be
off until later omapfb is started, which will set up the DSS again.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
---
drivers/video/omap2/omapfb/omapfb-main.c | 36 ++++++++++++++++++++++++--------
drivers/video/omap2/omapfb/omapfb.h | 1 +
2 files changed, 28 insertions(+), 9 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 27d6905683f3..88c1fe92d2c6 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1383,18 +1383,36 @@ static int omapfb_alloc_fbmem(struct fb_info *fbi, unsigned long size,
rg->type = 0;
rg->alloc = false;
rg->map = false;
+ rg->noclear = 0;
size = PAGE_ALIGN(size);
- dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
+ if (paddr) {
+ DBG("reserving %#lx bytes at %#lx\n", size, paddr);
- if (ofbi->rotation_type = OMAP_DSS_ROT_VRFB)
- dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &attrs);
+ token = dma_mark_declared_memory_occupied(fbdev->dev,
+ paddr, size);
+
+ if (IS_ERR(token)) {
+ dev_err(fbdev->dev,
+ "dma_mark_declared_memory_occupied failed: %ld\n",
+ PTR_ERR(token));
+ return PTR_ERR(token);
+ }
+
+ dma_handle = paddr;
+ rg->noclear = 1;
+ } else {
+ dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
- DBG("allocating %lu bytes for fb %d\n", size, ofbi->id);
+ if (ofbi->rotation_type = OMAP_DSS_ROT_VRFB)
+ dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, &attrs);
- token = dma_alloc_attrs(fbdev->dev, size, &dma_handle,
- GFP_KERNEL, &attrs);
+ DBG("allocating %lu bytes for fb %d\n", size, ofbi->id);
+
+ token = dma_alloc_attrs(fbdev->dev, size, &dma_handle,
+ GFP_KERNEL, &attrs);
+ }
if (token = NULL) {
dev_err(fbdev->dev, "failed to allocate framebuffer\n");
@@ -1513,9 +1531,6 @@ static int omapfb_parse_vram_param(const char *param, int max_entries,
}
- WARN_ONCE(paddr,
- "reserving memory at predefined address not supported\n");
-
paddrs[fbnum] = paddr;
sizes[fbnum] = size;
@@ -1950,6 +1965,9 @@ static int omapfb_create_framebuffers(struct omapfb2_device *fbdev)
if (ofbi->region->size = 0)
continue;
+ if (ofbi->region->noclear)
+ continue;
+
omapfb_clear_fb(fbi);
}
diff --git a/drivers/video/omap2/omapfb/omapfb.h b/drivers/video/omap2/omapfb/omapfb.h
index 623cd872a367..69642944f453 100644
--- a/drivers/video/omap2/omapfb/omapfb.h
+++ b/drivers/video/omap2/omapfb/omapfb.h
@@ -64,6 +64,7 @@ struct omapfb2_mem_region {
atomic_t map_count;
struct rw_semaphore lock;
atomic_t lock_count;
+ bool noclear; /* don't clear the fb on alloc */
};
/* appended to fb_info */
--
1.8.3.2
^ permalink raw reply related
* [PATCH] ARM: OMAPFB: panel-sony-acx565akm: fix missing mutex unlocks
From: Ivaylo Dimitrov @ 2013-12-30 16:17 UTC (permalink / raw)
To: tomi.valkeinen
Cc: plagnioj, pali.rohar, pavel, linux-omap, linux-fbdev,
linux-kernel, Ivaylo Dimitrov
In-Reply-To: <1383773070-15114-1-git-send-email-aaro.koskinen@iki.fi>
From: Ivaylo Dimitrov <freemangordon@abv.bg>
Commit c37dd677988ca50bc8bc60ab5ab053720583c168 fixes the unbalanced
unlock in acx565akm_enable but introduces another problem - if
acx565akm_panel_power_on exits early, the mutex is not unlocked. Fix
that by unlocking the mutex on early return. Also add mutex protection in
acx565akm_panel_power_off and remove an unused variable
Signed-off-by: Ivaylo Dimitrov <freemangordon@abv.bg>
---
.../omap2/displays-new/panel-sony-acx565akm.c | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/displays-new/panel-sony-acx565akm.c b/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
index d94f35d..a093d3a 100644
--- a/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
+++ b/drivers/video/omap2/displays-new/panel-sony-acx565akm.c
@@ -535,6 +535,7 @@ static int acx565akm_panel_power_on(struct omap_dss_device *dssdev)
r = in->ops.sdi->enable(in);
if (r) {
+ mutex_unlock(&ddata->mutex);
pr_err("%s sdi enable failed\n", __func__);
return r;
}
@@ -546,6 +547,7 @@ static int acx565akm_panel_power_on(struct omap_dss_device *dssdev)
gpio_set_value(ddata->reset_gpio, 1);
if (ddata->enabled) {
+ mutex_unlock(&ddata->mutex);
dev_dbg(&ddata->spi->dev, "panel already enabled\n");
return 0;
}
@@ -578,10 +580,14 @@ static void acx565akm_panel_power_off(struct omap_dss_device *dssdev)
struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *in = ddata->in;
+ mutex_lock(&ddata->mutex);
+
dev_dbg(dssdev->dev, "%s\n", __func__);
- if (!ddata->enabled)
+ if (!ddata->enabled) {
+ mutex_unlock(&ddata->mutex);
return;
+ }
set_display_state(ddata, 0);
set_sleep_mode(ddata, 1);
@@ -601,11 +607,13 @@ static void acx565akm_panel_power_off(struct omap_dss_device *dssdev)
msleep(100);
in->ops.sdi->disable(in);
+
+ mutex_unlock(&ddata->mutex);
+
}
static int acx565akm_enable(struct omap_dss_device *dssdev)
{
- struct panel_drv_data *ddata = to_panel_data(dssdev);
int r;
dev_dbg(dssdev->dev, "%s\n", __func__);
--
1.5.6.1
^ permalink raw reply related
* Advise to invest in your Country
From: nkoffi396 @ 2013-12-30 18:06 UTC (permalink / raw)
To: linux-fbdev
Dear Friend,
I need someone in your Country I want to invest 30MillionEuros. For more info send me your telephone number for conversation to enable us have a concrete discussion and meeting.
Best Regards
Mr.Norbert Koffi
^ permalink raw reply
* Re: [PATCH] fonts:Kconfig: fix default enable FONT_8x8 and FONT_8x16 at the same time
From: Wang YanQing @ 2013-12-31 1:19 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20131230065303.GA6640@udknight>
On Mon, Dec 30, 2013 at 09:51:38AM +0100, Geert Uytterhoeven wrote:
> On Mon, Dec 30, 2013 at 7:53 AM, Wang YanQing <udknight@gmail.com> wrote:
> > FONT_8x8 and FONT_8x16 have the same default value line:
> > "default y if !SPARC && !FONTS"
> >
> > I test run "make defconfig" for x86 will enable FONT_8x8 and FONT_8x16 at
> > the same time.
> >
> > This patch fix it, because FONT_AUTOSELECT choice FONT_8x16, so
> > I decide to disable FONT_8x8, this patch will reduce size of kernel.
>
> ... at the expense of losing FONT_8x8...
>
> In another email, you wrote:
> | Sorry for confusion, the default behavior enable FONT_8x8 and FONT_8x16,
> | FONT_8x8 eat ~50KB memory, but kernel never use it. I think this is not
> | good default behavior.
>
> Whether FONT_8x8 or FONT_8x16 is used depends on your screen resolution,
> cfr. lib/fonts/font.c:get_default_font().
Thanks for point out get_default_font, I know where I am wrong now :)
^ permalink raw reply
* Re: [Xen-devel] [PATCH v3 1/2] xen/pvhvm: If xen_platform_pci=0 is set don't blow up (v3).
From: Konrad Rzeszutek Wilk @ 2013-12-31 14:32 UTC (permalink / raw)
To: Fabio Fantoni
Cc: axboe, stefano.stabellini, ian.campbell, xen-devel, linux-kernel,
boris.ostrovsky, david.vrabel, leosilva, ashley, peterhuewe, mail,
tpmdd, dmitry.torokhov, bhelgaas, plagnioj, tomi.valkeinen,
tpmdd-devel, linux-input, netdev, linux-pci, linux-fbdev
In-Reply-To: <20131217212333.GA31966@phenom.dumpdata.com>
> That is because 'disks' is incorrect. It should have been 'ide-disks'
>
> [ 0.000000] unrecognised option 'disks' in parameter 'xen_emul_unplug'
>
> With the 'ide-disks' it should work. I will update the description to
> mention 'ide-disks' instead of 'disks'. Thank you for finding this!
>
I've v4 with said update and will push it to Linus shortly.
Thanks!
P.S.
Here is v4:
From 275a81e7496d3532e5b4752703c50a7c8355a6c7 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 26 Nov 2013 15:05:40 -0500
Subject: [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don't blow up (v4).
The user has the option of disabling the platform driver:
00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
which is used to unplug the emulated drivers (IDE, Realtek 8169, etc)
and allow the PV drivers to take over. If the user wishes
to disable that they can set:
xen_platform_pci=0
(in the guest config file)
or
xen_emul_unplug=never
(on the Linux command line)
except it does not work properly. The PV drivers still try to
load and since the Xen platform driver is not run - and it
has not initialized the grant tables, most of the PV drivers
stumble upon:
input: Xen Virtual Keyboard as /devices/virtual/input/input5
input: Xen Virtual Pointer as /devices/virtual/input/input6M
------------[ cut here ]------------
kernel BUG at /home/konrad/ssd/konrad/linux/drivers/xen/grant-table.c:1206!
invalid opcode: 0000 [#1] SMP
Modules linked in: xen_kbdfront(+) xenfs xen_privcmd
CPU: 6 PID: 1389 Comm: modprobe Not tainted 3.13.0-rc1upstream-00021-ga6c892b-dirty #1
Hardware name: Xen HVM domU, BIOS 4.4-unstable 11/26/2013
RIP: 0010:[<ffffffff813ddc40>] [<ffffffff813ddc40>] get_free_entries+0x2e0/0x300
Call Trace:
[<ffffffff8150d9a3>] ? evdev_connect+0x1e3/0x240
[<ffffffff813ddd0e>] gnttab_grant_foreign_access+0x2e/0x70
[<ffffffffa0010081>] xenkbd_connect_backend+0x41/0x290 [xen_kbdfront]
[<ffffffffa0010a12>] xenkbd_probe+0x2f2/0x324 [xen_kbdfront]
[<ffffffff813e5757>] xenbus_dev_probe+0x77/0x130
[<ffffffff813e7217>] xenbus_frontend_dev_probe+0x47/0x50
[<ffffffff8145e9a9>] driver_probe_device+0x89/0x230
[<ffffffff8145ebeb>] __driver_attach+0x9b/0xa0
[<ffffffff8145eb50>] ? driver_probe_device+0x230/0x230
[<ffffffff8145eb50>] ? driver_probe_device+0x230/0x230
[<ffffffff8145cf1c>] bus_for_each_dev+0x8c/0xb0
[<ffffffff8145e7d9>] driver_attach+0x19/0x20
[<ffffffff8145e260>] bus_add_driver+0x1a0/0x220
[<ffffffff8145f1ff>] driver_register+0x5f/0xf0
[<ffffffff813e55c5>] xenbus_register_driver_common+0x15/0x20
[<ffffffff813e76b3>] xenbus_register_frontend+0x23/0x40
[<ffffffffa0015000>] ? 0xffffffffa0014fff
[<ffffffffa001502b>] xenkbd_init+0x2b/0x1000 [xen_kbdfront]
[<ffffffff81002049>] do_one_initcall+0x49/0x170
.. snip..
which is hardly nice. This patch fixes this by having each
PV driver check for:
- if running in PV, then it is fine to execute (as that is their
native environment).
- if running in HVM, check if user wanted 'xen_emul_unplug=never',
in which case bail out and don't load any PV drivers.
- if running in HVM, and if PCI device 5853:0001 (xen_platform_pci)
does not exist, then bail out and not load PV drivers.
- (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=ide-disks',
then bail out for all PV devices _except_ the block one.
Ditto for the network one ('nics').
- (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=unnecessary'
then load block PV driver, and also setup the legacy IDE paths.
In (v3) make it actually load PV drivers.
Reported-by: Sander Eikelenboom <linux@eikelenboom.it
Reported-by: Anthony PERARD <anthony.perard@citrix.com>
Reported-and-Tested-by: Fabio Fantoni <fabio.fantoni@m2r.biz>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
[v2: Add extra logic to handle the myrid ways 'xen_emul_unplug'
can be used per Ian and Stefano suggestion]
[v3: Make the unnecessary case work properly]
[v4: s/disks/ide-disks/ spotted by Fabio]
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com> [for PCI parts]
---
arch/x86/xen/platform-pci-unplug.c | 74 ++++++++++++++++++++++++++++++
drivers/block/xen-blkfront.c | 4 +-
drivers/char/tpm/xen-tpmfront.c | 4 ++
drivers/input/misc/xen-kbdfront.c | 4 ++
drivers/net/xen-netfront.c | 2 +-
drivers/pci/xen-pcifront.c | 4 ++
drivers/video/xen-fbfront.c | 4 ++
drivers/xen/xenbus/xenbus_probe_frontend.c | 2 +-
include/xen/platform_pci.h | 23 ++++++++++
9 files changed, 117 insertions(+), 4 deletions(-)
diff --git a/arch/x86/xen/platform-pci-unplug.c b/arch/x86/xen/platform-pci-unplug.c
index 0a78524..ab84ac1 100644
--- a/arch/x86/xen/platform-pci-unplug.c
+++ b/arch/x86/xen/platform-pci-unplug.c
@@ -69,6 +69,80 @@ static int check_platform_magic(void)
return 0;
}
+bool xen_has_pv_devices()
+{
+ if (!xen_domain())
+ return false;
+
+ /* PV domains always have them. */
+ if (xen_pv_domain())
+ return true;
+
+ /* And user has xen_platform_pci=0 set in guest config as
+ * driver did not modify the value. */
+ if (xen_platform_pci_unplug = 0)
+ return false;
+
+ if (xen_platform_pci_unplug & XEN_UNPLUG_NEVER)
+ return false;
+
+ if (xen_platform_pci_unplug & XEN_UNPLUG_ALL)
+ return true;
+
+ /* This is an odd one - we are going to run legacy
+ * and PV drivers at the same time. */
+ if (xen_platform_pci_unplug & XEN_UNPLUG_UNNECESSARY)
+ return true;
+
+ /* And the caller has to follow with xen_pv_{disk,nic}_devices
+ * to be certain which driver can load. */
+ return false;
+}
+EXPORT_SYMBOL_GPL(xen_has_pv_devices);
+
+static bool __xen_has_pv_device(int state)
+{
+ /* HVM domains might or might not */
+ if (xen_hvm_domain() && (xen_platform_pci_unplug & state))
+ return true;
+
+ return xen_has_pv_devices();
+}
+
+bool xen_has_pv_nic_devices(void)
+{
+ return __xen_has_pv_device(XEN_UNPLUG_ALL_NICS | XEN_UNPLUG_ALL);
+}
+EXPORT_SYMBOL_GPL(xen_has_pv_nic_devices);
+
+bool xen_has_pv_disk_devices(void)
+{
+ return __xen_has_pv_device(XEN_UNPLUG_ALL_IDE_DISKS |
+ XEN_UNPLUG_AUX_IDE_DISKS | XEN_UNPLUG_ALL);
+}
+EXPORT_SYMBOL_GPL(xen_has_pv_disk_devices);
+
+/*
+ * This one is odd - it determines whether you want to run PV _and_
+ * legacy (IDE) drivers together. This combination is only possible
+ * under HVM.
+ */
+bool xen_has_pv_and_legacy_disk_devices(void)
+{
+ if (!xen_domain())
+ return false;
+
+ /* N.B. This is only ever used in HVM mode */
+ if (xen_pv_domain())
+ return false;
+
+ if (xen_platform_pci_unplug & XEN_UNPLUG_UNNECESSARY)
+ return true;
+
+ return false;
+}
+EXPORT_SYMBOL_GPL(xen_has_pv_and_legacy_disk_devices);
+
void xen_unplug_emulated_devices(void)
{
int r;
diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index a4660bb..ed88b3c 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1278,7 +1278,7 @@ static int blkfront_probe(struct xenbus_device *dev,
char *type;
int len;
/* no unplug has been done: do not hook devices != xen vbds */
- if (xen_platform_pci_unplug & XEN_UNPLUG_UNNECESSARY) {
+ if (xen_has_pv_and_legacy_disk_devices()) {
int major;
if (!VDEV_IS_EXTENDED(vdevice))
@@ -2022,7 +2022,7 @@ static int __init xlblk_init(void)
if (!xen_domain())
return -ENODEV;
- if (xen_hvm_domain() && !xen_platform_pci_unplug)
+ if (!xen_has_pv_disk_devices())
return -ENODEV;
if (register_blkdev(XENVBD_MAJOR, DEV_NAME)) {
diff --git a/drivers/char/tpm/xen-tpmfront.c b/drivers/char/tpm/xen-tpmfront.c
index 06189e5..9c2cbd1 100644
--- a/drivers/char/tpm/xen-tpmfront.c
+++ b/drivers/char/tpm/xen-tpmfront.c
@@ -16,6 +16,7 @@
#include <xen/xenbus.h>
#include <xen/page.h>
#include "tpm.h"
+#include <xen/platform_pci.h>
struct tpm_private {
struct tpm_chip *chip;
@@ -422,6 +423,9 @@ static int __init xen_tpmfront_init(void)
if (!xen_domain())
return -ENODEV;
+ if (!xen_has_pv_devices())
+ return -ENODEV;
+
return xenbus_register_frontend(&tpmfront_driver);
}
module_init(xen_tpmfront_init);
diff --git a/drivers/input/misc/xen-kbdfront.c b/drivers/input/misc/xen-kbdfront.c
index e21c181..fbfdc10 100644
--- a/drivers/input/misc/xen-kbdfront.c
+++ b/drivers/input/misc/xen-kbdfront.c
@@ -29,6 +29,7 @@
#include <xen/interface/io/fbif.h>
#include <xen/interface/io/kbdif.h>
#include <xen/xenbus.h>
+#include <xen/platform_pci.h>
struct xenkbd_info {
struct input_dev *kbd;
@@ -380,6 +381,9 @@ static int __init xenkbd_init(void)
if (xen_initial_domain())
return -ENODEV;
+ if (!xen_has_pv_devices())
+ return -ENODEV;
+
return xenbus_register_frontend(&xenkbd_driver);
}
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 36808bf..eea2392 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -2106,7 +2106,7 @@ static int __init netif_init(void)
if (!xen_domain())
return -ENODEV;
- if (xen_hvm_domain() && !xen_platform_pci_unplug)
+ if (!xen_has_pv_nic_devices())
return -ENODEV;
pr_info("Initialising Xen virtual ethernet driver\n");
diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index f7197a7..eae7cd9 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -20,6 +20,7 @@
#include <linux/workqueue.h>
#include <linux/bitops.h>
#include <linux/time.h>
+#include <xen/platform_pci.h>
#include <asm/xen/swiotlb-xen.h>
#define INVALID_GRANT_REF (0)
@@ -1138,6 +1139,9 @@ static int __init pcifront_init(void)
if (!xen_pv_domain() || xen_initial_domain())
return -ENODEV;
+ if (!xen_has_pv_devices())
+ return -ENODEV;
+
pci_frontend_registrar(1 /* enable */);
return xenbus_register_frontend(&xenpci_driver);
diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
index cd005c2..4b2d3ab 100644
--- a/drivers/video/xen-fbfront.c
+++ b/drivers/video/xen-fbfront.c
@@ -35,6 +35,7 @@
#include <xen/interface/io/fbif.h>
#include <xen/interface/io/protocols.h>
#include <xen/xenbus.h>
+#include <xen/platform_pci.h>
struct xenfb_info {
unsigned char *fb;
@@ -699,6 +700,9 @@ static int __init xenfb_init(void)
if (xen_initial_domain())
return -ENODEV;
+ if (!xen_has_pv_devices())
+ return -ENODEV;
+
return xenbus_register_frontend(&xenfb_driver);
}
diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c b/drivers/xen/xenbus/xenbus_probe_frontend.c
index 34b20bf..6244f9c 100644
--- a/drivers/xen/xenbus/xenbus_probe_frontend.c
+++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
@@ -496,7 +496,7 @@ subsys_initcall(xenbus_probe_frontend_init);
#ifndef MODULE
static int __init boot_wait_for_devices(void)
{
- if (xen_hvm_domain() && !xen_platform_pci_unplug)
+ if (!xen_has_pv_devices())
return -ENODEV;
ready_to_wait_for_devices = 1;
diff --git a/include/xen/platform_pci.h b/include/xen/platform_pci.h
index 438c256..b49eeab 100644
--- a/include/xen/platform_pci.h
+++ b/include/xen/platform_pci.h
@@ -48,4 +48,27 @@ static inline int xen_must_unplug_disks(void) {
extern int xen_platform_pci_unplug;
+#if defined(CONFIG_XEN_PVHVM)
+extern bool xen_has_pv_devices(void);
+extern bool xen_has_pv_disk_devices(void);
+extern bool xen_has_pv_nic_devices(void);
+extern bool xen_has_pv_and_legacy_disk_devices(void);
+#else
+static inline bool xen_has_pv_devices(void)
+{
+ return IS_ENABLED(CONFIG_XEN);
+}
+static inline bool xen_has_pv_disk_devices(void)
+{
+ return IS_ENABLED(CONFIG_XEN);
+}
+static inline bool xen_has_pv_nic_devices(void)
+{
+ return IS_ENABLED(CONFIG_XEN);
+}
+static inline bool xen_has_pv_and_legacy_disk_devices(void)
+{
+ return false;
+}
+#endif
#endif /* _XEN_PLATFORM_PCI_H */
--
1.8.3.1
^ permalink raw reply related
* Re: [Xen-devel] [PATCH v3 1/2] xen/pvhvm: If xen_platform_pci=0 is set don't blow up (v3).
From: David Vrabel @ 2014-01-02 15:09 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Fabio Fantoni, axboe, leosilva, linux-fbdev, dmitry.torokhov,
ian.campbell, stefano.stabellini, linux-pci, netdev, ashley,
tpmdd, linux-kernel, mail, tpmdd-devel, tomi.valkeinen,
david.vrabel, linux-input, bhelgaas, xen-devel, boris.ostrovsky,
plagnioj, peterhuewe
In-Reply-To: <20131231143258.GA3018@phenom.dumpdata.com>
On 31/12/13 14:32, Konrad Rzeszutek Wilk wrote:
>> That is because 'disks' is incorrect. It should have been 'ide-disks'
>>
>> [ 0.000000] unrecognised option 'disks' in parameter 'xen_emul_unplug'
>>
>> With the 'ide-disks' it should work. I will update the description to
>> mention 'ide-disks' instead of 'disks'. Thank you for finding this!
>>
>
> I've v4 with said update and will push it to Linus shortly.
>
> Thanks!
>
> P.S.
> Here is v4:
>
>>From 275a81e7496d3532e5b4752703c50a7c8355a6c7 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Tue, 26 Nov 2013 15:05:40 -0500
> Subject: [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don't blow up (v4).
>
> The user has the option of disabling the platform driver:
> 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
>
> which is used to unplug the emulated drivers (IDE, Realtek 8169, etc)
> and allow the PV drivers to take over. If the user wishes
> to disable that they can set:
>
> xen_platform_pci=0
> (in the guest config file)
>
> or
> xen_emul_unplug=never
> (on the Linux command line)
>
> except it does not work properly. The PV drivers still try to
> load and since the Xen platform driver is not run - and it
> has not initialized the grant tables, most of the PV drivers
> stumble upon:
>
> input: Xen Virtual Keyboard as /devices/virtual/input/input5
> input: Xen Virtual Pointer as /devices/virtual/input/input6M
> ------------[ cut here ]------------
> kernel BUG at /home/konrad/ssd/konrad/linux/drivers/xen/grant-table.c:1206!
> invalid opcode: 0000 [#1] SMP
> Modules linked in: xen_kbdfront(+) xenfs xen_privcmd
> CPU: 6 PID: 1389 Comm: modprobe Not tainted 3.13.0-rc1upstream-00021-ga6c892b-dirty #1
> Hardware name: Xen HVM domU, BIOS 4.4-unstable 11/26/2013
> RIP: 0010:[<ffffffff813ddc40>] [<ffffffff813ddc40>] get_free_entries+0x2e0/0x300
> Call Trace:
> [<ffffffff8150d9a3>] ? evdev_connect+0x1e3/0x240
> [<ffffffff813ddd0e>] gnttab_grant_foreign_access+0x2e/0x70
> [<ffffffffa0010081>] xenkbd_connect_backend+0x41/0x290 [xen_kbdfront]
> [<ffffffffa0010a12>] xenkbd_probe+0x2f2/0x324 [xen_kbdfront]
> [<ffffffff813e5757>] xenbus_dev_probe+0x77/0x130
> [<ffffffff813e7217>] xenbus_frontend_dev_probe+0x47/0x50
> [<ffffffff8145e9a9>] driver_probe_device+0x89/0x230
> [<ffffffff8145ebeb>] __driver_attach+0x9b/0xa0
> [<ffffffff8145eb50>] ? driver_probe_device+0x230/0x230
> [<ffffffff8145eb50>] ? driver_probe_device+0x230/0x230
> [<ffffffff8145cf1c>] bus_for_each_dev+0x8c/0xb0
> [<ffffffff8145e7d9>] driver_attach+0x19/0x20
> [<ffffffff8145e260>] bus_add_driver+0x1a0/0x220
> [<ffffffff8145f1ff>] driver_register+0x5f/0xf0
> [<ffffffff813e55c5>] xenbus_register_driver_common+0x15/0x20
> [<ffffffff813e76b3>] xenbus_register_frontend+0x23/0x40
> [<ffffffffa0015000>] ? 0xffffffffa0014fff
> [<ffffffffa001502b>] xenkbd_init+0x2b/0x1000 [xen_kbdfront]
> [<ffffffff81002049>] do_one_initcall+0x49/0x170
>
> .. snip..
>
> which is hardly nice. This patch fixes this by having each
> PV driver check for:
> - if running in PV, then it is fine to execute (as that is their
> native environment).
> - if running in HVM, check if user wanted 'xen_emul_unplug=never',
> in which case bail out and don't load any PV drivers.
> - if running in HVM, and if PCI device 5853:0001 (xen_platform_pci)
> does not exist, then bail out and not load PV drivers.
> - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=ide-disks',
> then bail out for all PV devices _except_ the block one.
> Ditto for the network one ('nics').
> - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=unnecessary'
> then load block PV driver, and also setup the legacy IDE paths.
> In (v3) make it actually load PV drivers.
[...]
> --- a/arch/x86/xen/platform-pci-unplug.c
> +++ b/arch/x86/xen/platform-pci-unplug.c
> @@ -69,6 +69,80 @@ static int check_platform_magic(void)
> return 0;
> }
>
> +bool xen_has_pv_devices()
> +{
> + if (!xen_domain())
> + return false;
> +
> + /* PV domains always have them. */
> + if (xen_pv_domain())
> + return true;
> +
> + /* And user has xen_platform_pci=0 set in guest config as
> + * driver did not modify the value. */
> + if (xen_platform_pci_unplug = 0)
> + return false;
> +
> + if (xen_platform_pci_unplug & XEN_UNPLUG_NEVER)
> + return false;
> +
> + if (xen_platform_pci_unplug & XEN_UNPLUG_ALL)
> + return true;
> +
> + /* This is an odd one - we are going to run legacy
> + * and PV drivers at the same time. */
> + if (xen_platform_pci_unplug & XEN_UNPLUG_UNNECESSARY)
> + return true;
> +
> + /* And the caller has to follow with xen_pv_{disk,nic}_devices
> + * to be certain which driver can load. */
> + return false;
This may result in:
xen_has_pv_devices() = false
xen_has_pv_disk_devices() = true
which looks odd to me. Surely xen_has_pv_*_devices() is a subset of
xen_has_pv_devices()?
David
^ permalink raw reply
* Re: [Xen-devel] [PATCH v3 1/2] xen/pvhvm: If xen_platform_pci=0 is set don't blow up (v3).
From: Konrad Rzeszutek Wilk @ 2014-01-02 19:16 UTC (permalink / raw)
To: David Vrabel
Cc: Fabio Fantoni, axboe, leosilva, linux-fbdev, dmitry.torokhov,
ian.campbell, stefano.stabellini, linux-pci, netdev, ashley,
tpmdd, linux-kernel, mail, tpmdd-devel, tomi.valkeinen,
linux-input, bhelgaas, xen-devel, boris.ostrovsky, plagnioj,
peterhuewe
In-Reply-To: <52C58138.1030301@citrix.com>
On Thu, Jan 02, 2014 at 03:09:44PM +0000, David Vrabel wrote:
> On 31/12/13 14:32, Konrad Rzeszutek Wilk wrote:
> >> That is because 'disks' is incorrect. It should have been 'ide-disks'
> >>
> >> [ 0.000000] unrecognised option 'disks' in parameter 'xen_emul_unplug'
> >>
> >> With the 'ide-disks' it should work. I will update the description to
> >> mention 'ide-disks' instead of 'disks'. Thank you for finding this!
> >>
> >
> > I've v4 with said update and will push it to Linus shortly.
> >
> > Thanks!
> >
> > P.S.
> > Here is v4:
> >
> >>From 275a81e7496d3532e5b4752703c50a7c8355a6c7 Mon Sep 17 00:00:00 2001
> > From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Date: Tue, 26 Nov 2013 15:05:40 -0500
> > Subject: [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don't blow up (v4).
> >
> > The user has the option of disabling the platform driver:
> > 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)
> >
> > which is used to unplug the emulated drivers (IDE, Realtek 8169, etc)
> > and allow the PV drivers to take over. If the user wishes
> > to disable that they can set:
> >
> > xen_platform_pci=0
> > (in the guest config file)
> >
> > or
> > xen_emul_unplug=never
> > (on the Linux command line)
> >
> > except it does not work properly. The PV drivers still try to
> > load and since the Xen platform driver is not run - and it
> > has not initialized the grant tables, most of the PV drivers
> > stumble upon:
> >
> > input: Xen Virtual Keyboard as /devices/virtual/input/input5
> > input: Xen Virtual Pointer as /devices/virtual/input/input6M
> > ------------[ cut here ]------------
> > kernel BUG at /home/konrad/ssd/konrad/linux/drivers/xen/grant-table.c:1206!
> > invalid opcode: 0000 [#1] SMP
> > Modules linked in: xen_kbdfront(+) xenfs xen_privcmd
> > CPU: 6 PID: 1389 Comm: modprobe Not tainted 3.13.0-rc1upstream-00021-ga6c892b-dirty #1
> > Hardware name: Xen HVM domU, BIOS 4.4-unstable 11/26/2013
> > RIP: 0010:[<ffffffff813ddc40>] [<ffffffff813ddc40>] get_free_entries+0x2e0/0x300
> > Call Trace:
> > [<ffffffff8150d9a3>] ? evdev_connect+0x1e3/0x240
> > [<ffffffff813ddd0e>] gnttab_grant_foreign_access+0x2e/0x70
> > [<ffffffffa0010081>] xenkbd_connect_backend+0x41/0x290 [xen_kbdfront]
> > [<ffffffffa0010a12>] xenkbd_probe+0x2f2/0x324 [xen_kbdfront]
> > [<ffffffff813e5757>] xenbus_dev_probe+0x77/0x130
> > [<ffffffff813e7217>] xenbus_frontend_dev_probe+0x47/0x50
> > [<ffffffff8145e9a9>] driver_probe_device+0x89/0x230
> > [<ffffffff8145ebeb>] __driver_attach+0x9b/0xa0
> > [<ffffffff8145eb50>] ? driver_probe_device+0x230/0x230
> > [<ffffffff8145eb50>] ? driver_probe_device+0x230/0x230
> > [<ffffffff8145cf1c>] bus_for_each_dev+0x8c/0xb0
> > [<ffffffff8145e7d9>] driver_attach+0x19/0x20
> > [<ffffffff8145e260>] bus_add_driver+0x1a0/0x220
> > [<ffffffff8145f1ff>] driver_register+0x5f/0xf0
> > [<ffffffff813e55c5>] xenbus_register_driver_common+0x15/0x20
> > [<ffffffff813e76b3>] xenbus_register_frontend+0x23/0x40
> > [<ffffffffa0015000>] ? 0xffffffffa0014fff
> > [<ffffffffa001502b>] xenkbd_init+0x2b/0x1000 [xen_kbdfront]
> > [<ffffffff81002049>] do_one_initcall+0x49/0x170
> >
> > .. snip..
> >
> > which is hardly nice. This patch fixes this by having each
> > PV driver check for:
> > - if running in PV, then it is fine to execute (as that is their
> > native environment).
> > - if running in HVM, check if user wanted 'xen_emul_unplug=never',
> > in which case bail out and don't load any PV drivers.
> > - if running in HVM, and if PCI device 5853:0001 (xen_platform_pci)
> > does not exist, then bail out and not load PV drivers.
> > - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=ide-disks',
> > then bail out for all PV devices _except_ the block one.
> > Ditto for the network one ('nics').
> > - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=unnecessary'
> > then load block PV driver, and also setup the legacy IDE paths.
> > In (v3) make it actually load PV drivers.
> [...]
> > --- a/arch/x86/xen/platform-pci-unplug.c
> > +++ b/arch/x86/xen/platform-pci-unplug.c
> > @@ -69,6 +69,80 @@ static int check_platform_magic(void)
> > return 0;
> > }
> >
> > +bool xen_has_pv_devices()
> > +{
> > + if (!xen_domain())
> > + return false;
> > +
> > + /* PV domains always have them. */
> > + if (xen_pv_domain())
> > + return true;
> > +
> > + /* And user has xen_platform_pci=0 set in guest config as
> > + * driver did not modify the value. */
> > + if (xen_platform_pci_unplug = 0)
> > + return false;
> > +
> > + if (xen_platform_pci_unplug & XEN_UNPLUG_NEVER)
> > + return false;
> > +
> > + if (xen_platform_pci_unplug & XEN_UNPLUG_ALL)
> > + return true;
> > +
> > + /* This is an odd one - we are going to run legacy
> > + * and PV drivers at the same time. */
> > + if (xen_platform_pci_unplug & XEN_UNPLUG_UNNECESSARY)
> > + return true;
> > +
> > + /* And the caller has to follow with xen_pv_{disk,nic}_devices
> > + * to be certain which driver can load. */
> > + return false;
>
> This may result in:
>
> xen_has_pv_devices() = false
> xen_has_pv_disk_devices() = true
Yes.
>
> which looks odd to me. Surely xen_has_pv_*_devices() is a subset of
> xen_has_pv_devices()?
I wish, this thing drives me nuts and I couldn't come up with a sensible
way to make this work for those special ones that have their own
xen_emul_unplug parameter without special casing the
'xen_has_pv_devices'.
Perhaps it should be renamed to 'xen_has_pv_generic_devices' ?
>
> David
^ permalink raw reply
* [PATCH 6/7] Fix a warning pertaining to the aty128fb backlight variable
From: David Howells @ 2014-01-03 16:08 UTC (permalink / raw)
To: akpm; +Cc: dhowells, linux-fbdev, Paul Mackerras, linux-kernel
Fix the following warning in the aty128fb driver:
drivers/video/aty/aty128fb.c:363:12: warning: 'backlight' defined but not used [-Wunused-variable]
static int backlight = 0;
^
as the variable's value is only read if CONFIG_FB_ATY128_BACKLIGHT=y. The
variable is also set if MODULE is unset[*].
[*] I wonder if the conditional wrapper around aty128fb_setup() should be
using CONFIG_MODULE rather than MODULE.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Paul Mackerras <paulus@samba.org>
cc: linux-fbdev@vger.kernel.org
---
drivers/video/aty/aty128fb.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/video/aty/aty128fb.c b/drivers/video/aty/aty128fb.c
index 12ca031877d4..52108be69e77 100644
--- a/drivers/video/aty/aty128fb.c
+++ b/drivers/video/aty/aty128fb.c
@@ -357,11 +357,13 @@ static int default_lcd_on = 1;
static bool mtrr = true;
#endif
+#ifdef CONFIG_FB_ATY128_BACKLIGHT
#ifdef CONFIG_PMAC_BACKLIGHT
static int backlight = 1;
#else
static int backlight = 0;
#endif
+#endif
/* PLL constants */
struct aty128_constants {
@@ -1671,7 +1673,9 @@ static int aty128fb_setup(char *options)
default_crt_on = simple_strtoul(this_opt+4, NULL, 0);
continue;
} else if (!strncmp(this_opt, "backlight:", 10)) {
+#ifdef CONFIG_FB_ATY128_BACKLIGHT
backlight = simple_strtoul(this_opt+10, NULL, 0);
+#endif
continue;
}
#ifdef CONFIG_MTRR
^ permalink raw reply related
* Re: [RFC PATCH 0/5] Move IPUv3 core out of staging, add CSI support
From: Philipp Zabel @ 2014-01-03 16:59 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1387561966-31758-1-git-send-email-p.zabel@pengutronix.de>
Am Freitag, den 20.12.2013, 11:12 -0800 schrieb Greg Kroah-Hartman:
> On Fri, Dec 20, 2013 at 06:52:41PM +0100, Philipp Zabel wrote:
> > Hi,
> >
> > this is mostly about the first patch, which moves the IPUv3 core code
> > (drivers/staging/imx-drm/ipu-v3) to drivers/gpu. host1x, which
> > serves a similar purpose, already sits there.
> > The other four patches add the necessary code for CSI and SMFC handling,
> > which is used by the V4L2 CSI capture driver.
> >
> > Currently this is based on Russell's patch
> > [PATCH 62/64] imx-drm: pass an IPU ID to crtc and core
> >
> > I am aware that there are now quite a few other patches in the pipeline
> > that touch drivers/staging/imx-drm/ipu-v3/*, so I am happy to rebase this
> > (or them) as needed. I'd like to move the core code out of staging so that
> > we can start submitting V4L2 code for video capture and scaling / colorspace
> > conversion in parallel.
>
> I'd recommend doing the move (if the gpu/drm maintainer agrees) after
> 3.14-rc1 as then all of my pending patches would be applied and we would
> be synced up with everything.
Ok.
> Once this "core" is moved, what is keeping the rest in staging and why
> isn't it moving out as well?
Russell put a lot of work into fixing imx-drm issues, and I'd like to
make the change to a common device tree binding before this leaves
staging.
regards
Philipp
^ permalink raw reply
* [PATCH v2] allow xenfb initialization for hvm guests
From: Stefano Stabellini @ 2014-01-03 19:02 UTC (permalink / raw)
To: xen-devel
Cc: linux-kernel, konrad.wilk, stefano.stabellini, boris.ostrovsky,
plagnioj, tomi.valkeinen, linux-fbdev
There is no reasons why an HVM guest shouldn't be allowed to use xenfb.
As a matter of fact ARM guests, HVM from Linux POV, can use xenfb.
Given that no Xen toolstacks configure a xenfb backend for x86 HVM
guests, they are not affected.
Please note that at this time QEMU needs few outstanding fixes to
provide xenfb on ARM:
http://marc.info/?l=qemu-devel&m\x138739419700837&w=2
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: David Vrabel <david.vrabel@citrix.com>
CC: boris.ostrovsky@oracle.com
CC: plagnioj@jcrosoft.com
CC: tomi.valkeinen@ti.com
CC: linux-fbdev@vger.kernel.org
CC: konrad.wilk@oracle.com
---
drivers/video/xen-fbfront.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
index cd005c2..02e1c01 100644
--- a/drivers/video/xen-fbfront.c
+++ b/drivers/video/xen-fbfront.c
@@ -692,7 +692,7 @@ static DEFINE_XENBUS_DRIVER(xenfb, ,
static int __init xenfb_init(void)
{
- if (!xen_pv_domain())
+ if (!xen_domain())
return -ENODEV;
/* Nothing to do if running in dom0. */
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v2] allow xenfb initialization for hvm guests
From: Konrad Rzeszutek Wilk @ 2014-01-03 20:34 UTC (permalink / raw)
To: Stefano Stabellini
Cc: xen-devel, linux-kernel, boris.ostrovsky, plagnioj,
tomi.valkeinen, linux-fbdev
In-Reply-To: <1388775730-2984-1-git-send-email-stefano.stabellini@eu.citrix.com>
On Fri, Jan 03, 2014 at 07:02:09PM +0000, Stefano Stabellini wrote:
The title needs 'xen/fb' prefixed but that is easy enough.
> There is no reasons why an HVM guest shouldn't be allowed to use xenfb.
> As a matter of fact ARM guests, HVM from Linux POV, can use xenfb.
> Given that no Xen toolstacks configure a xenfb backend for x86 HVM
> guests, they are not affected.
>
> Please note that at this time QEMU needs few outstanding fixes to
> provide xenfb on ARM:
>
> http://marc.info/?l=qemu-devel&m\x138739419700837&w=2
Cool. Is the video maintainer OK with the Xen maintainers stashing it
in the Xen tree for Linus?
Thanks!
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Acked-by: David Vrabel <david.vrabel@citrix.com>
> CC: boris.ostrovsky@oracle.com
> CC: plagnioj@jcrosoft.com
> CC: tomi.valkeinen@ti.com
> CC: linux-fbdev@vger.kernel.org
> CC: konrad.wilk@oracle.com
> ---
> drivers/video/xen-fbfront.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c
> index cd005c2..02e1c01 100644
> --- a/drivers/video/xen-fbfront.c
> +++ b/drivers/video/xen-fbfront.c
> @@ -692,7 +692,7 @@ static DEFINE_XENBUS_DRIVER(xenfb, ,
>
> static int __init xenfb_init(void)
> {
> - if (!xen_pv_domain())
> + if (!xen_domain())
> return -ENODEV;
>
> /* Nothing to do if running in dom0. */
> --
> 1.7.10.4
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox