* Re: omapdss: Division by zero in kernel
From: Pali Rohár @ 2015-07-28 11:56 UTC (permalink / raw)
To: Tomi Valkeinen, Jean-Christophe Plagniol-Villard, Jyri Sarha
Cc: linux-omap, linux-fbdev, linux-kernel, Pavel Machek,
Sebastian Reichel, Aaro Koskinen, Tony Lindgren, Nishanth Menon
In-Reply-To: <201507241803.42891@pali>
On Friday 24 July 2015 18:03:42 Pali Rohár wrote:
> Hello,
>
> when on N900 (real HW or qemu) I run this command
>
> / # echo 0 > /sys/devices/platform/omapdss/overlay0/enabled && echo 0 > /sys/class/graphics/fb0/size
>
> then kernel crash with this error message
>
> / # [ 29.904113] Division by zero in kernel.
> ** 3375 printk messages dropped ** [ 29.963836] [<c01e0008>] (__aeabi_uidivmod) from [<c022071c>]
> (cfb_imageblit+0xac/0x464)
> ** 8426 printk messages dropped ** [ 30.111083] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 8380 printk messages dropped ** [ 30.258209] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 7813 printk messages dropped ** [ 30.400054] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 7666 printk messages dropped ** [ 30.538391] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 7687 printk messages dropped ** [ 30.676544] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 7960 printk messages dropped ** [ 30.819915] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 8317 printk messages dropped ** [ 30.966979] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 8590 printk messages dropped ** [ 31.122528] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 8885 printk messages dropped ** [ 31.287658] [<c0218ed0>] (fbcon_scroll) from [<c025af90>] (scrup+0x60/0x128)
> ** 9408 printk messages dropped ** [ 31.461425] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 9787 printk messages dropped ** [ 31.644287] [<c02187e8>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 10081 printk messages dropped ** [ 31.833984] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 10501 printk messages dropped ** [ 32.031066] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 10816 printk messages dropped ** [ 32.233001] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 10900 printk messages dropped ** [ 32.440490] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 10837 printk messages dropped ** [ 32.645233] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 10837 printk messages dropped ** [ 32.848999] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 10837 printk messages dropped ** [ 33.053833] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
> (fbcon_scroll+0x6a0/0xcbc)
> ** 10838 printk messages dropped ** [ 33.258361] [<c0218ed0>] (fbcon_scroll) from [<c025af90>] (scrup+0x60/0x128)
>
> I suspect that problem is in omapdss.
>
> I do not know if size 0 make sense, but Maemo userspace is calling above
> commands and on Nokia's 2.6.28 kernel there is no crash or error message.
>
> IMHO Division by zero in kernel should not be there even if userspace
> call "incorrect" command.
>
PING! Any idea what to do with Division by zero in kernel?
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply
* Re: [PATCH] video: fbdev: atmel: fix warning for const return value
From: Nicolas Ferre @ 2015-07-27 15:49 UTC (permalink / raw)
To: Rob Herring, Tomi Valkeinen
Cc: linux-kernel, linux-fbdev, Jean-Christophe Plagniol-Villard
In-Reply-To: <1438011701-18423-1-git-send-email-robh@kernel.org>
Le 27/07/2015 17:41, Rob Herring a écrit :
> A const on a return value is meaningless and generates a warning on some
> versions of gcc:
>
> drivers/video/fbdev/atmel_lcdfb.c:1003: warning: type qualifiers ignored on function return type
>
> This was found on 0-day with avr32 builds with CONFIG_OF enabled, but
> it doesn't seem to generate warnings for other arches.
>
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> Signed-off-by: Rob Herring <robh@kernel.org>
> Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Sure:
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Thanks Rob!
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/fbdev/atmel_lcdfb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/atmel_lcdfb.c b/drivers/video/fbdev/atmel_lcdfb.c
> index abadc49..66f4b70 100644
> --- a/drivers/video/fbdev/atmel_lcdfb.c
> +++ b/drivers/video/fbdev/atmel_lcdfb.c
> @@ -999,7 +999,7 @@ static const char *atmel_lcdfb_wiring_modes[] = {
> [ATMEL_LCDC_WIRING_RGB] = "RGB",
> };
>
> -const int atmel_lcdfb_get_of_wiring_modes(struct device_node *np)
> +int atmel_lcdfb_get_of_wiring_modes(struct device_node *np)
> {
> const char *mode;
> int err, i;
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH] video: fbdev: atmel: fix warning for const return value
From: Rob Herring @ 2015-07-27 15:41 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-kernel, linux-fbdev, Nicolas Ferre,
Jean-Christophe Plagniol-Villard
A const on a return value is meaningless and generates a warning on some
versions of gcc:
drivers/video/fbdev/atmel_lcdfb.c:1003: warning: type qualifiers ignored on function return type
This was found on 0-day with avr32 builds with CONFIG_OF enabled, but
it doesn't seem to generate warnings for other arches.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/fbdev/atmel_lcdfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/atmel_lcdfb.c b/drivers/video/fbdev/atmel_lcdfb.c
index abadc49..66f4b70 100644
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++ b/drivers/video/fbdev/atmel_lcdfb.c
@@ -999,7 +999,7 @@ static const char *atmel_lcdfb_wiring_modes[] = {
[ATMEL_LCDC_WIRING_RGB] = "RGB",
};
-const int atmel_lcdfb_get_of_wiring_modes(struct device_node *np)
+int atmel_lcdfb_get_of_wiring_modes(struct device_node *np)
{
const char *mode;
int err, i;
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] sm750fb: coding style fixes lines over 80 chars
From: Sudip Mukherjee @ 2015-07-27 5:36 UTC (permalink / raw)
To: Vinay Simha
Cc: Joe Perches, Teddy Wang, Greg Kroah-Hartman,
open list:STAGING - SILICON MOTION SM750 FRAME BUFFER DRIVER,
open list:STAGING SUBSYSTEM, open list
In-Reply-To: <CAGWqDJ4dgrsYAiWXMKi2j1-kGoFhQ_rZGxuDuqpbfTG2P7bnsw@mail.gmail.com>
On Tue, Jul 21, 2015 at 03:17:06PM +0530, Vinay Simha wrote:
> Joe,
>
> Just want to confirm, shall i delete this code in sm750_help.h, even the
> FIELD_START and FIELD_END is not required.
If they are not used anywhere feel free to send a patch to delete them.
regards
sudip
^ permalink raw reply
* Re: [PATCH v2 1/3] staging: sm7xxfb: move sm712fb out of staging
From: Sudip Mukherjee @ 2015-07-27 4:53 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Greg Kroah-Hartman
Cc: linux-kernel, linux-fbdev, devel
In-Reply-To: <1437192539-14150-1-git-send-email-sudipm.mukherjee@gmail.com>
On Sat, Jul 18, 2015 at 09:38:57AM +0530, Sudip Mukherjee wrote:
> Now since all cleanups are done and the code is ready to be merged lets
> move it out of staging into fbdev location.
Hi Tomi,
A gentle ping
regards
sudip
^ permalink raw reply
* [PATCH 5/5] gxt4500: enable panning
From: Ondrej Zary @ 2015-07-26 21:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-fbdev, Kernel development list
In-Reply-To: <1437945982-3021-1-git-send-email-linux@rainbow-software.org>
The driver implements pan_display but the corresponding flags are not set.
Add FBINFO_HWACCEL_XPAN and FBINFO_HWACCEL_YPAN to flags to allow HW
accelerated panning (for fast scrolling).
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
---
drivers/video/fbdev/gxt4500.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/gxt4500.c b/drivers/video/fbdev/gxt4500.c
index e0d1550..88a3cf6 100644
--- a/drivers/video/fbdev/gxt4500.c
+++ b/drivers/video/fbdev/gxt4500.c
@@ -685,7 +685,8 @@ static int gxt4500_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
#endif
info->fbops = &gxt4500_ops;
- info->flags = FBINFO_FLAG_DEFAULT;
+ info->flags = FBINFO_FLAG_DEFAULT | FBINFO_HWACCEL_XPAN |
+ FBINFO_HWACCEL_YPAN;
err = fb_alloc_cmap(&info->cmap, 256, 0);
if (err) {
--
Ondrej Zary
^ permalink raw reply related
* [PATCH 4/5] gxt4500: Use write-combining for framebuffer
From: Ondrej Zary @ 2015-07-26 21:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-fbdev, Kernel development list
In-Reply-To: <1437945982-3021-1-git-send-email-linux@rainbow-software.org>
Use write-combining for framebuffer to greatly improve performance on x86.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
---
drivers/video/fbdev/gxt4500.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/gxt4500.c b/drivers/video/fbdev/gxt4500.c
index 442b07c..e0d1550 100644
--- a/drivers/video/fbdev/gxt4500.c
+++ b/drivers/video/fbdev/gxt4500.c
@@ -142,7 +142,7 @@ static const unsigned char watfmt[] = {
struct gxt4500_par {
void __iomem *regs;
-
+ int wc_cookie;
int pixfmt; /* pixel format, see DFA_PIX_* values */
/* PLL parameters */
@@ -663,7 +663,7 @@ static int gxt4500_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
info->fix.smem_start = fb_phys;
info->fix.smem_len = pci_resource_len(pdev, 1);
- info->screen_base = pci_ioremap_bar(pdev, 1);
+ info->screen_base = ioremap_wc(fb_phys, info->fix.smem_len);
if (!info->screen_base) {
dev_err(&pdev->dev, "gxt4500: cannot map framebuffer\n");
goto err_unmap_regs;
@@ -671,6 +671,9 @@ static int gxt4500_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
pci_set_drvdata(pdev, info);
+ par->wc_cookie = arch_phys_wc_add(info->fix.smem_start,
+ info->fix.smem_len);
+
#ifdef __BIG_ENDIAN
/* Set byte-swapping for DFA aperture for all pixel sizes */
pci_write_config_dword(pdev, CFG_ENDIAN0, 0x333300);
@@ -735,6 +738,7 @@ static void gxt4500_remove(struct pci_dev *pdev)
return;
par = info->par;
unregister_framebuffer(info);
+ arch_phys_wc_del(par->wc_cookie);
fb_dealloc_cmap(&info->cmap);
iounmap(par->regs);
iounmap(info->screen_base);
--
Ondrej Zary
^ permalink raw reply related
* [PATCH 3/5] gxt4500: fix color order
From: Ondrej Zary @ 2015-07-26 21:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-fbdev, Kernel development list
In-Reply-To: <1437945982-3021-1-git-send-email-linux@rainbow-software.org>
The color order in truecolor modes is wrong. This does not affect console but
is visible e.g. in X11 which has wrong colors.
Swap blue and red colors to fix the problem.
Fixes https://forums.gentoo.org/viewtopic-t-692740-start-0.html
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
---
drivers/video/fbdev/gxt4500.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/gxt4500.c b/drivers/video/fbdev/gxt4500.c
index 1f2fd5b..442b07c 100644
--- a/drivers/video/fbdev/gxt4500.c
+++ b/drivers/video/fbdev/gxt4500.c
@@ -347,11 +347,12 @@ static void gxt4500_unpack_pixfmt(struct fb_var_screeninfo *var,
break;
}
if (pixfmt != DFA_PIX_8BIT) {
- var->green.offset = var->red.length;
- var->blue.offset = var->green.offset + var->green.length;
+ var->blue.offset = 0;
+ var->green.offset = var->blue.length;
+ var->red.offset = var->green.offset + var->green.length;
if (var->transp.length)
var->transp.offset - var->blue.offset + var->blue.length;
+ var->red.offset + var->red.length;
}
}
--
Ondrej Zary
^ permalink raw reply related
* [PATCH 2/5] gxt4500: fix 16bpp 565 mode
From: Ondrej Zary @ 2015-07-26 21:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-fbdev, Kernel development list
In-Reply-To: <1437945982-3021-1-git-send-email-linux@rainbow-software.org>
Fix wrong colors in 16bpp 565 mode.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
---
drivers/video/fbdev/gxt4500.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/gxt4500.c b/drivers/video/fbdev/gxt4500.c
index 1bf9894..1f2fd5b 100644
--- a/drivers/video/fbdev/gxt4500.c
+++ b/drivers/video/fbdev/gxt4500.c
@@ -525,7 +525,7 @@ static int gxt4500_setcolreg(unsigned int reg, unsigned int red,
u32 val = reg;
switch (par->pixfmt) {
case DFA_PIX_16BIT_565:
- val |= (reg << 11) | (reg << 6);
+ val |= (reg << 11) | (reg << 5);
break;
case DFA_PIX_16BIT_1555:
val |= (reg << 10) | (reg << 5);
--
Ondrej Zary
^ permalink raw reply related
* [PATCH 1/5] gxt4500: enable on non-PPC architectures
From: Ondrej Zary @ 2015-07-26 21:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-fbdev, Kernel development list
In-Reply-To: <1437945982-3021-1-git-send-email-linux@rainbow-software.org>
These chips can be present at least on x86 too - Fire GL2 AGP has GXT6000P but
this driver is currently limited to PPC.
Enable it for all architectures and add chip configuration for little-endian.
Tested on x86 with Fire GL2 AGP.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
---
drivers/video/fbdev/Kconfig | 5 +++--
drivers/video/fbdev/gxt4500.c | 7 +++++++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 2d98de5..78335bd 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2132,7 +2132,7 @@ config FB_UDL
config FB_IBM_GXT4500
tristate "Framebuffer support for IBM GXT4000P/4500P/6000P/6500P adaptors"
- depends on FB && PPC
+ depends on FB
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -2140,7 +2140,8 @@ config FB_IBM_GXT4500
Say Y here to enable support for the IBM GXT4000P/6000P and
GXT4500P/6500P display adaptor based on Raster Engine RC1000,
found on some IBM System P (pSeries) machines. This driver
- doesn't use Geometry Engine GT1000.
+ doesn't use Geometry Engine GT1000. This driver also supports
+ AGP Fire GL2/3/4 cards on x86.
config FB_PS3
tristate "PS3 GPU framebuffer driver"
diff --git a/drivers/video/fbdev/gxt4500.c b/drivers/video/fbdev/gxt4500.c
index 135d78a..1bf9894 100644
--- a/drivers/video/fbdev/gxt4500.c
+++ b/drivers/video/fbdev/gxt4500.c
@@ -670,8 +670,15 @@ static int gxt4500_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
pci_set_drvdata(pdev, info);
+#ifdef __BIG_ENDIAN
/* Set byte-swapping for DFA aperture for all pixel sizes */
pci_write_config_dword(pdev, CFG_ENDIAN0, 0x333300);
+#else /* __LITTLE_ENDIAN */
+ /* not sure what this means but fgl23 driver does that */
+ pci_write_config_dword(pdev, CFG_ENDIAN0, 0x2300);
+/* pci_write_config_dword(pdev, CFG_ENDIAN0 + 4, 0x400000);*/
+ pci_write_config_dword(pdev, CFG_ENDIAN0 + 8, 0x98530000);
+#endif
info->fbops = &gxt4500_ops;
info->flags = FBINFO_FLAG_DEFAULT;
--
Ondrej Zary
^ permalink raw reply related
* [PATCH 0/5] gxt4500: Make usable on x86 and fix some bugs
From: Ondrej Zary @ 2015-07-26 21:26 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-fbdev, Kernel development list
Fire GL2 AGP has GXT6000P and is a x86 card but the gxt4500 driver is
currently limited to PPC.
This patch series makes the driver work on x86 and fixes some color problems.
--
Ondrej Zary
^ permalink raw reply
* [RFC v5 18/26] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_wri
From: Finn Thain @ 2015-07-25 7:46 UTC (permalink / raw)
To: linux-kernel, linux-m68k, linuxppc-dev, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Arnd Bergmann,
Greg Kroah-Hartman, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, linux-fbdev
In-Reply-To: <20150725074559.543547894@telegraphics.com.au>
Make use of arch_nvram_ops in device drivers so that the nvram_* function
exports can be removed.
Since they are no longer global symbols, rename the PPC32 nvram_* functions
appropriately.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
---
Changed since v4:
- Split off the CONFIG_PPC32, CONFIG_PPC_PMAC and CONFIG_NVRAM tests into
a separate patch.
---
arch/powerpc/kernel/setup_32.c | 8 ++++----
drivers/char/generic_nvram.c | 4 ++--
drivers/video/fbdev/controlfb.c | 4 ++--
drivers/video/fbdev/imsttfb.c | 4 ++--
drivers/video/fbdev/matrox/matroxfb_base.c | 2 +-
drivers/video/fbdev/platinumfb.c | 4 ++--
drivers/video/fbdev/valkyriefb.c | 4 ++--
7 files changed, 15 insertions(+), 15 deletions(-)
Index: linux/arch/powerpc/kernel/setup_32.c
=================================--- linux.orig/arch/powerpc/kernel/setup_32.c 2015-07-25 17:45:42.000000000 +1000
+++ linux/arch/powerpc/kernel/setup_32.c 2015-07-25 17:45:45.000000000 +1000
@@ -170,20 +170,18 @@ __setup("l3cr=", ppc_setup_l3cr);
#ifdef CONFIG_GENERIC_NVRAM
-unsigned char nvram_read_byte(int addr)
+static unsigned char ppc_nvram_read_byte(int addr)
{
if (ppc_md.nvram_read_val)
return ppc_md.nvram_read_val(addr);
return 0xff;
}
-EXPORT_SYMBOL(nvram_read_byte);
-void nvram_write_byte(unsigned char val, int addr)
+static void ppc_nvram_write_byte(unsigned char val, int addr)
{
if (ppc_md.nvram_write_val)
ppc_md.nvram_write_val(addr, val);
}
-EXPORT_SYMBOL(nvram_write_byte);
static ssize_t ppc_nvram_get_size(void)
{
@@ -200,6 +198,8 @@ static long ppc_nvram_sync(void)
}
const struct nvram_ops arch_nvram_ops = {
+ .read_byte = ppc_nvram_read_byte,
+ .write_byte = ppc_nvram_write_byte,
.get_size = ppc_nvram_get_size,
.sync = ppc_nvram_sync,
};
Index: linux/drivers/char/generic_nvram.c
=================================--- linux.orig/drivers/char/generic_nvram.c 2015-07-25 17:45:42.000000000 +1000
+++ linux/drivers/char/generic_nvram.c 2015-07-25 17:45:45.000000000 +1000
@@ -63,7 +63,7 @@ static ssize_t read_nvram(struct file *f
if (*ppos >= nvram_len)
return 0;
for (i = *ppos; count > 0 && i < nvram_len; ++i, ++p, --count)
- if (__put_user(nvram_read_byte(i), p))
+ if (__put_user(arch_nvram_ops.read_byte(i), p))
return -EFAULT;
*ppos = i;
return p - buf;
@@ -83,7 +83,7 @@ static ssize_t write_nvram(struct file *
for (i = *ppos; count > 0 && i < nvram_len; ++i, ++p, --count) {
if (__get_user(c, p))
return -EFAULT;
- nvram_write_byte(c, i);
+ arch_nvram_ops.write_byte(c, i);
}
*ppos = i;
return p - buf;
Index: linux/drivers/video/fbdev/controlfb.c
=================================--- linux.orig/drivers/video/fbdev/controlfb.c 2015-07-25 17:42:34.000000000 +1000
+++ linux/drivers/video/fbdev/controlfb.c 2015-07-25 17:45:45.000000000 +1000
@@ -415,7 +415,7 @@ static int __init init_control(struct fb
/* Try to pick a video mode out of NVRAM if we have one. */
#ifdef CONFIG_NVRAM
if (default_cmode = CMODE_NVRAM) {
- cmode = nvram_read_byte(NV_CMODE);
+ cmode = arch_nvram_ops.read_byte(NV_CMODE);
if(cmode < CMODE_8 || cmode > CMODE_32)
cmode = CMODE_8;
} else
@@ -423,7 +423,7 @@ static int __init init_control(struct fb
cmodeÞfault_cmode;
#ifdef CONFIG_NVRAM
if (default_vmode = VMODE_NVRAM) {
- vmode = nvram_read_byte(NV_VMODE);
+ vmode = arch_nvram_ops.read_byte(NV_VMODE);
if (vmode < 1 || vmode > VMODE_MAX ||
control_mac_modes[vmode - 1].m[full] < cmode) {
sense = read_control_sense(p);
Index: linux/drivers/video/fbdev/imsttfb.c
=================================--- linux.orig/drivers/video/fbdev/imsttfb.c 2015-07-25 17:45:44.000000000 +1000
+++ linux/drivers/video/fbdev/imsttfb.c 2015-07-25 17:45:45.000000000 +1000
@@ -1393,12 +1393,12 @@ static void init_imstt(struct fb_info *i
int vmode = init_vmode, cmode = init_cmode;
if (vmode = -1) {
- vmode = nvram_read_byte(NV_VMODE);
+ vmode = arch_nvram_ops.read_byte(NV_VMODE);
if (vmode <= 0 || vmode > VMODE_MAX)
vmode = VMODE_640_480_67;
}
if (cmode = -1) {
- cmode = nvram_read_byte(NV_CMODE);
+ cmode = arch_nvram_ops.read_byte(NV_CMODE);
if (cmode < CMODE_8 || cmode > CMODE_32)
cmode = CMODE_8;
}
Index: linux/drivers/video/fbdev/matrox/matroxfb_base.c
=================================--- linux.orig/drivers/video/fbdev/matrox/matroxfb_base.c 2015-07-25 17:45:44.000000000 +1000
+++ linux/drivers/video/fbdev/matrox/matroxfb_base.c 2015-07-25 17:45:45.000000000 +1000
@@ -1878,7 +1878,7 @@ static int initMatrox2(struct matrox_fb_
default_vmode = VMODE_640_480_60;
#if defined(CONFIG_PPC32) && defined(CONFIG_NVRAM)
if (default_cmode = CMODE_NVRAM)
- default_cmode = nvram_read_byte(NV_CMODE);
+ default_cmode = arch_nvram_ops.read_byte(NV_CMODE);
#endif
if (default_cmode < CMODE_8 || default_cmode > CMODE_32)
default_cmode = CMODE_8;
Index: linux/drivers/video/fbdev/platinumfb.c
=================================--- linux.orig/drivers/video/fbdev/platinumfb.c 2015-07-25 17:42:34.000000000 +1000
+++ linux/drivers/video/fbdev/platinumfb.c 2015-07-25 17:45:45.000000000 +1000
@@ -349,7 +349,7 @@ static int platinum_init_fb(struct fb_in
printk(KERN_INFO "platinumfb: Monitor sense value = 0x%x, ", sense);
if (default_vmode = VMODE_NVRAM) {
#ifdef CONFIG_NVRAM
- default_vmode = nvram_read_byte(NV_VMODE);
+ default_vmode = arch_nvram_ops.read_byte(NV_VMODE);
if (default_vmode <= 0 || default_vmode > VMODE_MAX ||
!platinum_reg_init[default_vmode-1])
#endif
@@ -362,7 +362,7 @@ static int platinum_init_fb(struct fb_in
default_vmode = VMODE_640_480_60;
#ifdef CONFIG_NVRAM
if (default_cmode = CMODE_NVRAM)
- default_cmode = nvram_read_byte(NV_CMODE);
+ default_cmode = arch_nvram_ops.read_byte(NV_CMODE);
#endif
if (default_cmode < CMODE_8 || default_cmode > CMODE_32)
default_cmode = CMODE_8;
Index: linux/drivers/video/fbdev/valkyriefb.c
=================================--- linux.orig/drivers/video/fbdev/valkyriefb.c 2015-07-25 17:45:44.000000000 +1000
+++ linux/drivers/video/fbdev/valkyriefb.c 2015-07-25 17:45:45.000000000 +1000
@@ -285,7 +285,7 @@ static void __init valkyrie_choose_mode(
/* Try to pick a video mode out of NVRAM if we have one. */
#if defined(CONFIG_PPC_PMAC) && defined(CONFIG_NVRAM)
if (default_vmode = VMODE_NVRAM) {
- default_vmode = nvram_read_byte(NV_VMODE);
+ default_vmode = arch_nvram_ops.read_byte(NV_VMODE);
if (default_vmode <= 0
|| default_vmode > VMODE_MAX
|| !valkyrie_reg_init[default_vmode - 1])
@@ -298,7 +298,7 @@ static void __init valkyrie_choose_mode(
default_vmode = VMODE_640_480_67;
#if defined(CONFIG_PPC_PMAC) && defined(CONFIG_NVRAM)
if (default_cmode = CMODE_NVRAM)
- default_cmode = nvram_read_byte(NV_CMODE);
+ default_cmode = arch_nvram_ops.read_byte(NV_CMODE);
#endif
/*
^ permalink raw reply
* [RFC v5 17/26] powerpc, fbdev: Use NV_CMODE and NV_VMODE only when CONFIG_PPC32 and CONFIG_PPC_PMAC
From: Finn Thain @ 2015-07-25 7:46 UTC (permalink / raw)
To: linux-kernel, linux-m68k, linuxppc-dev,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, linux-fbdev
In-Reply-To: <20150725074559.543547894@telegraphics.com.au>
This patch addresses inconsistencies in Mac framebuffer drivers and their
use of Kconfig symbols relating to NVRAM, so PPC64 can use CONFIG_NVRAM.
Macintosh framebuffer drivers use default settings for color mode and
video mode that are found in NVRAM. On PCI Macs, MacOS stores display
settings in the Name Registry (NR) partition in NVRAM*. On NuBus Macs,
there is no NR partition and MacOS stores display mode settings in PRAM**.
Early model Macs are the ones most likely to benefit from these settings,
since they are more likely to have one display: a fixed-frequency monitor
connected to the built-in framebuffer device. Moreover, a single NV_CMODE
value and a single NV_VMODE value provide for only one display.
The NV_CMODE and NV_VMODE constants are apparently offsets into the NR
partition for Old World machines and not New World, which also suggests
that these defaults are not useful on later models.
All this argues for limiting NVRAM support in PowerMac fbdev drivers to
PPC32 and indeed this is already the case, since CONFIG_NVRAM cannot be
enabled on PPC64 at present.
For matroxfb, make the CONFIG_PPC32 condition explicit. That way the
driver won't crash on PPC64 when CONFIG_NVRAM becomes available there.
In imsttfb, add the missing CONFIG_NVRAM test to prevent a build failure,
since PPC64 does not implement nvram_read_byte(). Also add a missing
machine_is(powermac) check. Change the inconsistent CONFIG_PPC dependency
and the matching #ifdef tests to CONFIG_PPC_PMAC. Drop unused #includes.
In valkyriefb, for clarity and consistency with the other PowerMac fbdev
drivers, test for CONFIG_PPC_PMAC instead of !CONFIG_MAC. Remove a
bogus comment regarding PRAM.
* See GetPreferredConfiguration and SavePreferredConfiguration in
"Designing PCI Cards and Drivers for Power Macintosh Computers".
** See SetDefaultMode and GetDefaultMode in "Designing Cards and Drivers
for the Macintosh Family".
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
---
drivers/video/fbdev/Kconfig | 2 +-
drivers/video/fbdev/imsttfb.c | 13 +++++--------
drivers/video/fbdev/matrox/matroxfb_base.c | 2 +-
drivers/video/fbdev/valkyriefb.c | 14 ++++++--------
4 files changed, 13 insertions(+), 18 deletions(-)
Index: linux/drivers/video/fbdev/Kconfig
=================================--- linux.orig/drivers/video/fbdev/Kconfig 2015-07-25 17:42:34.000000000 +1000
+++ linux/drivers/video/fbdev/Kconfig 2015-07-25 17:45:44.000000000 +1000
@@ -544,7 +544,7 @@ config FB_IMSTT
bool "IMS Twin Turbo display support"
depends on (FB = y) && PCI
select FB_CFB_IMAGEBLIT
- select FB_MACMODES if PPC
+ select FB_MACMODES if PPC_PMAC
help
The IMS Twin Turbo is a PCI-based frame buffer card bundled with
many Macintosh and compatible computers.
Index: linux/drivers/video/fbdev/imsttfb.c
=================================--- linux.orig/drivers/video/fbdev/imsttfb.c 2015-07-25 17:42:34.000000000 +1000
+++ linux/drivers/video/fbdev/imsttfb.c 2015-07-25 17:45:44.000000000 +1000
@@ -30,10 +30,8 @@
#include <asm/io.h>
#include <linux/uaccess.h>
-#if defined(CONFIG_PPC)
+#if defined(CONFIG_PPC_PMAC)
#include <linux/nvram.h>
-#include <asm/prom.h>
-#include <asm/pci-bridge.h>
#include "macmodes.h"
#endif
@@ -328,14 +326,13 @@ enum {
TVP = 1
};
-#define USE_NV_MODES 1
#define INIT_BPP 8
#define INIT_XRES 640
#define INIT_YRES 480
static int inverse = 0;
static char fontname[40] __initdata = { 0 };
-#if defined(CONFIG_PPC)
+#if defined(CONFIG_PPC_PMAC)
static signed char init_vmode = -1, init_cmode = -1;
#endif
@@ -1391,8 +1388,8 @@ static void init_imstt(struct fb_info *i
}
}
-#if USE_NV_MODES && defined(CONFIG_PPC32)
- {
+#if defined(CONFIG_PPC_PMAC) && defined(CONFIG_PPC32) && defined(CONFIG_NVRAM)
+ if (machine_is(powermac)) {
int vmode = init_vmode, cmode = init_cmode;
if (vmode = -1) {
@@ -1566,7 +1563,7 @@ imsttfb_setup(char *options)
inverse = 1;
fb_invert_cmaps();
}
-#if defined(CONFIG_PPC)
+#if defined(CONFIG_PPC_PMAC)
else if (!strncmp(this_opt, "vmode:", 6)) {
int vmode = simple_strtoul(this_opt+6, NULL, 0);
if (vmode > 0 && vmode <= VMODE_MAX)
Index: linux/drivers/video/fbdev/matrox/matroxfb_base.c
=================================--- linux.orig/drivers/video/fbdev/matrox/matroxfb_base.c 2015-07-25 17:45:38.000000000 +1000
+++ linux/drivers/video/fbdev/matrox/matroxfb_base.c 2015-07-25 17:45:44.000000000 +1000
@@ -1876,7 +1876,7 @@ static int initMatrox2(struct matrox_fb_
struct fb_var_screeninfo var;
if (default_vmode <= 0 || default_vmode > VMODE_MAX)
default_vmode = VMODE_640_480_60;
-#ifdef CONFIG_NVRAM
+#if defined(CONFIG_PPC32) && defined(CONFIG_NVRAM)
if (default_cmode = CMODE_NVRAM)
default_cmode = nvram_read_byte(NV_CMODE);
#endif
Index: linux/drivers/video/fbdev/valkyriefb.c
=================================--- linux.orig/drivers/video/fbdev/valkyriefb.c 2015-07-25 17:42:34.000000000 +1000
+++ linux/drivers/video/fbdev/valkyriefb.c 2015-07-25 17:45:44.000000000 +1000
@@ -65,14 +65,12 @@
#include "macmodes.h"
#include "valkyriefb.h"
-#ifdef CONFIG_MAC
-/* We don't yet have functions to read the PRAM... perhaps we can
- adapt them from the PPC code? */
-static int default_vmode = VMODE_CHOOSE;
-static int default_cmode = CMODE_8;
-#else
+#ifdef CONFIG_PPC_PMAC
static int default_vmode = VMODE_NVRAM;
static int default_cmode = CMODE_NVRAM;
+#else
+static int default_vmode = VMODE_CHOOSE;
+static int default_cmode = CMODE_8;
#endif
struct fb_par_valkyrie {
@@ -285,7 +283,7 @@ static void __init valkyrie_choose_mode(
printk(KERN_INFO "Monitor sense value = 0x%x\n", p->sense);
/* Try to pick a video mode out of NVRAM if we have one. */
-#if !defined(CONFIG_MAC) && defined(CONFIG_NVRAM)
+#if defined(CONFIG_PPC_PMAC) && defined(CONFIG_NVRAM)
if (default_vmode = VMODE_NVRAM) {
default_vmode = nvram_read_byte(NV_VMODE);
if (default_vmode <= 0
@@ -298,7 +296,7 @@ static void __init valkyrie_choose_mode(
default_vmode = mac_map_monitor_sense(p->sense);
if (!valkyrie_reg_init[default_vmode - 1])
default_vmode = VMODE_640_480_67;
-#if !defined(CONFIG_MAC) && defined(CONFIG_NVRAM)
+#if defined(CONFIG_PPC_PMAC) && defined(CONFIG_NVRAM)
if (default_cmode = CMODE_NVRAM)
default_cmode = nvram_read_byte(NV_CMODE);
#endif
^ permalink raw reply
* [RFC v5 13/26] powerpc: Cleanup nvram includes
From: Finn Thain @ 2015-07-25 7:46 UTC (permalink / raw)
To: linux-kernel, linux-m68k, linuxppc-dev, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Arnd Bergmann,
Greg Kroah-Hartman, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, linux-fbdev
In-Reply-To: <20150725074559.543547894@telegraphics.com.au>
The nvram_read_byte() and nvram_write_byte() definitions in asm/nvram.h
duplicate those in linux/nvram.h. Get rid of the former to prepare for
adoption of struct arch_nvram_ops (which is defined in linux/nvram.h for
general use).
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
---
Changes since v4:
- Fix possible git bisect build failure with CONFIG_PPC_PMAC=n.
---
arch/powerpc/include/asm/nvram.h | 3 ---
arch/powerpc/kernel/setup_32.c | 1 +
drivers/char/generic_nvram.c | 1 +
drivers/video/fbdev/matrox/matroxfb_base.c | 2 +-
4 files changed, 3 insertions(+), 4 deletions(-)
Index: linux/arch/powerpc/include/asm/nvram.h
=================================--- linux.orig/arch/powerpc/include/asm/nvram.h 2015-07-25 17:42:34.000000000 +1000
+++ linux/arch/powerpc/include/asm/nvram.h 2015-07-25 17:45:38.000000000 +1000
@@ -101,7 +101,4 @@ extern int nvram_write_os_partition(stru
/* Determine NVRAM size */
extern ssize_t nvram_get_size(void);
-/* Normal access to NVRAM */
-extern unsigned char nvram_read_byte(int i);
-extern void nvram_write_byte(unsigned char c, int i);
#endif /* _ASM_POWERPC_NVRAM_H */
Index: linux/arch/powerpc/kernel/setup_32.c
=================================--- linux.orig/arch/powerpc/kernel/setup_32.c 2015-07-25 17:42:34.000000000 +1000
+++ linux/arch/powerpc/kernel/setup_32.c 2015-07-25 17:45:38.000000000 +1000
@@ -16,6 +16,7 @@
#include <linux/cpu.h>
#include <linux/console.h>
#include <linux/memblock.h>
+#include <linux/nvram.h>
#include <asm/io.h>
#include <asm/prom.h>
Index: linux/drivers/video/fbdev/matrox/matroxfb_base.c
=================================--- linux.orig/drivers/video/fbdev/matrox/matroxfb_base.c 2015-07-25 17:42:34.000000000 +1000
+++ linux/drivers/video/fbdev/matrox/matroxfb_base.c 2015-07-25 17:45:38.000000000 +1000
@@ -111,12 +111,12 @@
#include "matroxfb_g450.h"
#include <linux/matroxfb.h>
#include <linux/interrupt.h>
+#include <linux/nvram.h>
#include <linux/slab.h>
#include <linux/uaccess.h>
#ifdef CONFIG_PPC_PMAC
#include <asm/machdep.h>
-unsigned char nvram_read_byte(int);
static int default_vmode = VMODE_NVRAM;
static int default_cmode = CMODE_NVRAM;
#endif
Index: linux/drivers/char/generic_nvram.c
=================================--- linux.orig/drivers/char/generic_nvram.c 2015-07-25 17:42:34.000000000 +1000
+++ linux/drivers/char/generic_nvram.c 2015-07-25 17:45:38.000000000 +1000
@@ -20,6 +20,7 @@
#include <linux/fcntl.h>
#include <linux/init.h>
#include <linux/mutex.h>
+#include <linux/nvram.h>
#include <asm/uaccess.h>
#include <asm/nvram.h>
#ifdef CONFIG_PPC_PMAC
^ permalink raw reply
* Re: [PATCH v2 00/10] pwm: add support for atomic update
From: Boris Brezillon @ 2015-07-25 6:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1437406327-6207-1-git-send-email-boris.brezillon@free-electrons.com>
Hi Thierry,
Should I resend a new version rebased on Mark's pwm topic branch or
would you like to review this one first ?
Best Regards,
Boris
On Mon, 20 Jul 2015 17:31:57 +0200
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> Hello Thierry,
>
> This series adds support for atomic PWM update, or IOW, the capability
> to update all the parameters of a PWM device (enabled/disabled, period,
> duty and polarity) in one go.
>
> Best Regards,
>
> Boris
>
> Changes since v1:
> - dropped applied patches
> - squashed Heiko's fixes into the rockchip driver changes
> - made a few cosmetic changes
> - added kerneldoc comments
> - added Heiko's patch to display more information in debugfs
> - dropped pwm-regulator patches (should be submitted separately)
>
> Boris Brezillon (9):
> pwm: introduce default period and polarity concepts
> pwm: define a new pwm_state struct
> pwm: move the enabled/disabled info to pwm_state struct
> backlight: pwm_bl: remove useless call to pwm_set_period
> pwm: declare a default PWM state
> pwm: add the PWM initial state retrieval infra
> pwm: add the core infrastructure to allow atomic update
> pwm: rockchip: add initial state retrieval
> pwm: rockchip: add support for atomic update
>
> Heiko Stübner (1):
> pwm: add information about polarity, duty cycle and period to debugfs
>
> drivers/leds/leds-pwm.c | 2 +-
> drivers/pwm/core.c | 169 +++++++++++++++++++++++++++++++----
> drivers/pwm/pwm-pxa.c | 2 +-
> drivers/pwm/pwm-rockchip.c | 119 +++++++++++++++++++-----
> drivers/pwm/pwm-sun4i.c | 3 +-
> drivers/regulator/pwm-regulator.c | 2 +-
> drivers/video/backlight/lm3630a_bl.c | 4 +-
> drivers/video/backlight/pwm_bl.c | 10 ++-
> drivers/video/fbdev/ssd1307fb.c | 2 +-
> include/linux/pwm.h | 86 +++++++++++++++---
> 10 files changed, 336 insertions(+), 63 deletions(-)
>
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 21/25] fbdev: switch from ioremap_wt to memremap
From: Dan Williams @ 2015-07-25 2:39 UTC (permalink / raw)
To: tglx, mingo, hpa
Cc: linux-arch, linux-fbdev, toshi.kani, linux-nvdimm, linux-kernel,
Tomi Valkeinen, rmk+kernel, Jean-Christophe Plagniol-Villard, hch,
linux-arm-kernel
In-Reply-To: <20150725023649.8664.59145.stgit@dwillia2-desk3.amr.corp.intel.com>
In preparation for deprecating ioremap_wt() convert its usage in
drivers/video/fbdev to memremap.
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
drivers/video/fbdev/amifb.c | 5 +++--
drivers/video/fbdev/atafb.c | 5 +++--
drivers/video/fbdev/hpfb.c | 6 +++---
3 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/amifb.c b/drivers/video/fbdev/amifb.c
index 1d702e13aaff..0cde451046d0 100644
--- a/drivers/video/fbdev/amifb.c
+++ b/drivers/video/fbdev/amifb.c
@@ -52,6 +52,7 @@
#include <linux/ioport.h>
#include <linux/platform_device.h>
#include <linux/uaccess.h>
+#include <linux/io.h>
#include <asm/irq.h>
#include <asm/amigahw.h>
@@ -3705,8 +3706,8 @@ default_chipset:
* access the videomem with writethrough cache
*/
info->fix.smem_start = (u_long)ZTWO_PADDR(videomemory);
- videomemory = (u_long)ioremap_wt(info->fix.smem_start,
- info->fix.smem_len);
+ videomemory = (u_long)memremap(info->fix.smem_start, info->fix.smem_len,
+ MEMREMAP_WT);
if (!videomemory) {
dev_warn(&pdev->dev,
"Unable to map videomem cached writethrough\n");
diff --git a/drivers/video/fbdev/atafb.c b/drivers/video/fbdev/atafb.c
index d6ce613e12ad..5615e8c31ea2 100644
--- a/drivers/video/fbdev/atafb.c
+++ b/drivers/video/fbdev/atafb.c
@@ -55,12 +55,12 @@
#include <linux/delay.h>
#include <linux/init.h>
#include <linux/interrupt.h>
+#include <linux/io.h>
#include <asm/setup.h>
#include <linux/uaccess.h>
#include <asm/pgtable.h>
#include <asm/irq.h>
-#include <asm/io.h>
#include <asm/atarihw.h>
#include <asm/atariints.h>
@@ -3185,7 +3185,8 @@ int __init atafb_init(void)
/* Map the video memory (physical address given) to somewhere
* in the kernel address space.
*/
- external_screen_base = ioremap_wt(external_addr, external_len);
+ external_screen_base = memremap(external_addr, external_len,
+ MEMREMAP_WT);
if (external_vgaiobase)
external_vgaiobase (unsigned long)ioremap(external_vgaiobase, 0x10000);
diff --git a/drivers/video/fbdev/hpfb.c b/drivers/video/fbdev/hpfb.c
index 9476d196f510..d08c320b06fc 100644
--- a/drivers/video/fbdev/hpfb.c
+++ b/drivers/video/fbdev/hpfb.c
@@ -14,8 +14,8 @@
#include <linux/init.h>
#include <linux/fb.h>
#include <linux/dio.h>
+#include <linux/io.h>
-#include <asm/io.h>
#include <asm/uaccess.h>
static struct fb_info fb_info = {
@@ -241,8 +241,8 @@ static int hpfb_init_one(unsigned long phys_base, unsigned long virt_base)
fb_info.fix.line_length = fb_width;
fb_height = (in_8(fb_regs + HPFB_FBHMSB) << 8) | in_8(fb_regs + HPFB_FBHLSB);
fb_info.fix.smem_len = fb_width * fb_height;
- fb_start = (unsigned long)ioremap_wt(fb_info.fix.smem_start,
- fb_info.fix.smem_len);
+ fb_start = (unsigned long) memremap(fb_info.fix.smem_start,
+ fb_info.fix.smem_len, MEMREMAP_WT);
hpfb_defined.xres = (in_8(fb_regs + HPFB_DWMSB) << 8) | in_8(fb_regs + HPFB_DWLSB);
hpfb_defined.yres = (in_8(fb_regs + HPFB_DHMSB) << 8) | in_8(fb_regs + HPFB_DHLSB);
hpfb_defined.xres_virtual = hpfb_defined.xres;
^ permalink raw reply related
* [PATCH v2 00/25] replace ioremap_{cache|wt} with memremap
From: Dan Williams @ 2015-07-25 2:37 UTC (permalink / raw)
To: tglx, mingo, hpa
Cc: linux-fbdev, David Airlie, dri-devel, kbuild test robot, Lv Zheng,
Daniel Vetter, Benjamin Romer, hch, linux-arch, linux-nvdimm,
Joerg Roedel, Rafael J. Wysocki, Bob Moore, Mike Waychison,
Roland Dreier, Tomi Valkeinen, rmk+kernel, Ross Zwisler,
David Kershner, Jean-Christophe Plagniol-Villard, intel-gfx,
Len Brown, Joerg Roedel, Arnd Bergmann
Changes since v1 [1]:
1/ Drop the attempt at unifying ioremap() prototypes, just focus on
converting ioremap_cache and ioremap_wt over to memremap (Christoph)
2/ Drop the unrelated cleanups to use %pa in __ioremap_caller (Thomas)
3/ Add support for memremap() attempts on "System RAM" to simply return
the kernel virtual address for that range. ARM depends on this
functionality in ioremap_cache() and ACPI was open coding a similar
solution. (Mark)
4/ Split the conversions of ioremap_{cache|wt} into separate patches per
driver / arch.
5/ Fix bisection breakage and other reports from 0day-kbuild
---
While developing the pmem driver we noticed that the __iomem annotation
on the return value from ioremap_cache() was being mishandled by several
callers. We also observed that all of the call sites expected to be
able to treat the return value from ioremap_cache() as normal
(non-__iomem) pointer to memory.
This patchset takes the opportunity to clean up the above confusion as
well as a few issues with the ioremap_{cache|wt} interface, including:
1/ Eliminating the possibility of function prototypes differing between
architectures by defining a central memremap() prototype that takes
flags to determine the mapping type.
2/ Returning NULL rather than falling back silently to a different
mapping-type. This allows drivers to be stricter about the
mapping-type fallbacks that are permissible.
[1]: http://marc.info/?l=linux-arm-kernel&m\x143735199029255&w=2
---
Dan Williams (22):
mm: enhance region_is_ram() to distinguish 'unknown' vs 'mixed'
arch, drivers: don't include <asm/io.h> directly, use <linux/io.h> instead
cleanup IORESOURCE_CACHEABLE vs ioremap()
intel_iommu: fix leaked ioremap mapping
arch: introduce memremap()
arm: switch from ioremap_cache to memremap
x86: switch from ioremap_cache to memremap
gma500: switch from acpi_os_ioremap to ioremap
i915: switch from acpi_os_ioremap to ioremap
acpi: switch from ioremap_cache to memremap
toshiba laptop: replace ioremap_cache with ioremap
memconsole: fix __iomem mishandling, switch to memremap
visorbus: switch from ioremap_cache to memremap
intel-iommu: switch from ioremap_cache to memremap
libnvdimm, pmem: switch from ioremap_cache to memremap
pxa2xx-flash: switch from ioremap_cache to memremap
sfi: switch from ioremap_cache to memremap
fbdev: switch from ioremap_wt to memremap
pmem: switch from ioremap_wt to memremap
arch: remove ioremap_cache, replace with arch_memremap
arch: remove ioremap_wt, replace with arch_memremap
pmem: convert to generic memremap
Toshi Kani (3):
mm, x86: Fix warning in ioremap RAM check
mm, x86: Remove region_is_ram() call from ioremap
mm: Fix bugs in region_is_ram()
arch/arc/include/asm/io.h | 1
arch/arm/Kconfig | 1
arch/arm/include/asm/io.h | 13 +++-
arch/arm/include/asm/xen/page.h | 4 +
arch/arm/mach-clps711x/board-cdb89712.c | 2 -
arch/arm/mach-shmobile/pm-rcar.c | 2 -
arch/arm/mm/ioremap.c | 12 +++-
arch/arm/mm/nommu.c | 11 ++-
arch/arm64/Kconfig | 1
arch/arm64/include/asm/acpi.h | 10 +--
arch/arm64/include/asm/dmi.h | 8 +--
arch/arm64/include/asm/io.h | 8 ++-
arch/arm64/kernel/efi.c | 9 ++-
arch/arm64/kernel/smp_spin_table.c | 19 +++---
arch/arm64/mm/ioremap.c | 20 ++----
arch/avr32/include/asm/io.h | 1
arch/frv/Kconfig | 1
arch/frv/include/asm/io.h | 17 ++---
arch/frv/mm/kmap.c | 6 ++
arch/ia64/Kconfig | 1
arch/ia64/include/asm/io.h | 11 +++
arch/ia64/kernel/cyclone.c | 2 -
arch/m32r/include/asm/io.h | 1
arch/m68k/Kconfig | 1
arch/m68k/include/asm/io_mm.h | 14 +---
arch/m68k/include/asm/io_no.h | 12 ++--
arch/m68k/include/asm/raw_io.h | 4 +
arch/m68k/mm/kmap.c | 17 +++++
arch/m68k/mm/sun3kmap.c | 6 ++
arch/metag/include/asm/io.h | 3 -
arch/microblaze/include/asm/io.h | 1
arch/mn10300/include/asm/io.h | 1
arch/nios2/include/asm/io.h | 1
arch/powerpc/kernel/pci_of_scan.c | 2 -
arch/s390/include/asm/io.h | 1
arch/sh/Kconfig | 1
arch/sh/include/asm/io.h | 20 ++++--
arch/sh/mm/ioremap.c | 10 +++
arch/sparc/include/asm/io_32.h | 1
arch/sparc/include/asm/io_64.h | 1
arch/sparc/kernel/pci.c | 3 -
arch/tile/include/asm/io.h | 1
arch/x86/Kconfig | 1
arch/x86/include/asm/efi.h | 3 +
arch/x86/include/asm/io.h | 17 +++--
arch/x86/kernel/crash_dump_64.c | 6 +-
arch/x86/kernel/kdebugfs.c | 8 +--
arch/x86/kernel/ksysfs.c | 28 ++++-----
arch/x86/mm/ioremap.c | 76 ++++++++++--------------
arch/xtensa/Kconfig | 1
arch/xtensa/include/asm/io.h | 9 ++-
drivers/acpi/apei/einj.c | 9 ++-
drivers/acpi/apei/erst.c | 6 +-
drivers/acpi/nvs.c | 6 +-
drivers/acpi/osl.c | 70 ++++++----------------
drivers/char/toshiba.c | 2 -
drivers/firmware/google/memconsole.c | 7 +-
drivers/gpu/drm/gma500/opregion.c | 2 -
drivers/gpu/drm/i915/intel_opregion.c | 2 -
drivers/iommu/intel-iommu.c | 10 ++-
drivers/iommu/intel_irq_remapping.c | 4 +
drivers/isdn/icn/icn.h | 2 -
drivers/mtd/devices/slram.c | 2 -
drivers/mtd/maps/pxa2xx-flash.c | 4 +
drivers/mtd/nand/diskonchip.c | 2 -
drivers/mtd/onenand/generic.c | 2 -
drivers/nvdimm/Kconfig | 2 -
drivers/pci/probe.c | 3 -
drivers/pnp/manager.c | 2 -
drivers/scsi/aic94xx/aic94xx_init.c | 7 --
drivers/scsi/arcmsr/arcmsr_hba.c | 5 --
drivers/scsi/mvsas/mv_init.c | 15 +----
drivers/scsi/sun3x_esp.c | 2 -
drivers/sfi/sfi_core.c | 4 +
drivers/staging/comedi/drivers/ii_pci20kc.c | 1
drivers/staging/unisys/visorbus/visorchannel.c | 16 +++--
drivers/staging/unisys/visorbus/visorchipset.c | 17 +++--
drivers/tty/serial/8250/8250_core.c | 2 -
drivers/video/fbdev/Kconfig | 2 -
drivers/video/fbdev/amifb.c | 5 +-
drivers/video/fbdev/atafb.c | 5 +-
drivers/video/fbdev/hpfb.c | 6 +-
drivers/video/fbdev/ocfb.c | 1
drivers/video/fbdev/s1d13xxxfb.c | 3 -
drivers/video/fbdev/stifb.c | 1
include/acpi/acpi_io.h | 6 +-
include/asm-generic/io.h | 8 ---
include/asm-generic/iomap.h | 4 -
include/linux/io-mapping.h | 2 -
include/linux/io.h | 9 +++
include/linux/mtd/map.h | 2 -
include/linux/pmem.h | 26 +++++---
include/video/vga.h | 2 -
kernel/Makefile | 2 +
kernel/memremap.c | 74 +++++++++++++++++++++++
kernel/resource.c | 43 +++++++-------
lib/Kconfig | 5 +-
lib/devres.c | 13 +---
lib/pci_iomap.c | 7 +-
tools/testing/nvdimm/Kbuild | 4 +
tools/testing/nvdimm/test/iomap.c | 34 ++++++++---
101 files changed, 482 insertions(+), 398 deletions(-)
create mode 100644 kernel/memremap.c
^ permalink raw reply
* Re: [PATCH] backlight: pm8941-wled: Add default-brightness property
From: Rob Clark @ 2015-07-24 17:41 UTC (permalink / raw)
To: Rob Herring
Cc: Bjorn Andersson, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Jingoo Han, Lee Jones,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
devicetree@vger.kernel.org, Linux Kernel Mailing List,
Linux Fbdev development list, linux-arm-msm
In-Reply-To: <CAL_JsqKcNjsLJPxQiWsjVtwsX2nsYGLSzjmX0cwo1QsZ+JE4Hg@mail.gmail.com>
On Fri, Jul 24, 2015 at 11:39 AM, Rob Herring <robherring2@gmail.com> wrote:
> On Fri, Jul 24, 2015 at 8:10 AM, Rob Clark <robdclark@gmail.com> wrote:
>> On Thu, Jul 23, 2015 at 3:52 PM, Bjorn Andersson
>> <bjorn.andersson@sonymobile.com> wrote:
>>> Add the possibility of specifying the default brightness in DT.
>>>
>>> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
>>> ---
>>>
>>> This depends on the patch moving pm8941-wled to backlight [1]. The dt property
>>> is used by several other backlight drivers, so I considered this to be a
>>> "common" property and it's hence not prefixed with "qcom,".
>>>
>>> [1] https://lkml.org/lkml/2015/7/21/906
>>>
>>> Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt | 1 +
>>> drivers/video/backlight/pm8941-wled.c | 4 ++++
>>> 2 files changed, 5 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
>>> index 424f8444a6cd..37503f8c3620 100644
>>> --- a/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
>>> +++ b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
>>> @@ -5,6 +5,7 @@ Required properties:
>>> - reg: slave address
>>>
>>> Optional properties:
>>> +- default-brightness: value from: 0-4095
>>> - label: The name of the backlight device
>>> - qcom,cs-out: bool; enable current sink output
>>> - qcom,cabc: bool; enable content adaptive backlight control
>>> diff --git a/drivers/video/backlight/pm8941-wled.c b/drivers/video/backlight/pm8941-wled.c
>>> index c704c3236034..b875e58df0fc 100644
>>> --- a/drivers/video/backlight/pm8941-wled.c
>>> +++ b/drivers/video/backlight/pm8941-wled.c
>>> @@ -373,6 +373,7 @@ static int pm8941_wled_probe(struct platform_device *pdev)
>>> struct backlight_device *bl;
>>> struct pm8941_wled *wled;
>>> struct regmap *regmap;
>>> + u32 val = 0;
>>> int rc;
>>
>> as discussed on IRC, it would be better if the default read back the
>> current settings (so-as to inherit bootloader splash smoothly..
>> drm/msm supports a memory-region phandle, for example, so it can take
>> over the bootloader splash-screen as stolen-mem)
>>
>> and it would I think be useful to have a comment in the bindings file
>> explaining that you *should* use the default-brightness property to
>> set a sane default if bootloader isn't putting up a splash, and you
>> should *not* use the property if it is..
>
> +1
>
> What if you have neither? Set to max brightness? 75%?
I did chat w/ Bjorn a bit about that on irc.. his concern was some
arbitrary percentage (like 50%) might be more or less bright depending
on the device (although that implies to me that maybe we should have
min and max bindings as well, rather than just assuming hw limits?
idk)
my preference is the default is somehow at least not 0%.. possibly
motivated by the expectation that when people see a dark screen at
boot they assume the display driver is broken :-P
BR,
-R
> This could also be used for the bootloader to communicate to the
> kernel what the current level is if it is not readable. I've seen one
> backlight recently which you change the level by doing some number of
> pulses on a gpio and a long pulse to turn off. So there is no way to
> know current level without turning off the backlight (unless you
> hardcode the bootloader's level in the kernel like the vendor did).
>
> Rob
^ permalink raw reply
* RE: [PATCH] ARM/fb: ep93xx: switch framebuffer to use modedb only
From: Hartley Sweeten @ 2015-07-24 16:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1437744688-29915-1-git-send-email-linus.walleij@linaro.org>
On Friday, July 24, 2015 6:31 AM, Linus Walleij wrote:
> All the EP93xx boards exclusively use modedb to look up video
> modes from the command line. Root out the parametrization of
> custom video modes from the platform data and board files
> and simplify the driver.
>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com>
^ permalink raw reply
* omapdss: Division by zero in kernel
From: Pali Rohár @ 2015-07-24 16:03 UTC (permalink / raw)
To: Tomi Valkeinen, Jean-Christophe Plagniol-Villard, Jyri Sarha
Cc: linux-omap, linux-fbdev, linux-kernel, Pavel Machek,
Sebastian Reichel, Aaro Koskinen, Tony Lindgren, Nishanth Menon
[-- Attachment #1: Type: Text/Plain, Size: 3242 bytes --]
Hello,
when on N900 (real HW or qemu) I run this command
/ # echo 0 > /sys/devices/platform/omapdss/overlay0/enabled && echo 0 > /sys/class/graphics/fb0/size
then kernel crash with this error message
/ # [ 29.904113] Division by zero in kernel.
** 3375 printk messages dropped ** [ 29.963836] [<c01e0008>] (__aeabi_uidivmod) from [<c022071c>]
(cfb_imageblit+0xac/0x464)
** 8426 printk messages dropped ** [ 30.111083] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8380 printk messages dropped ** [ 30.258209] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7813 printk messages dropped ** [ 30.400054] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7666 printk messages dropped ** [ 30.538391] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7687 printk messages dropped ** [ 30.676544] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 7960 printk messages dropped ** [ 30.819915] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8317 printk messages dropped ** [ 30.966979] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8590 printk messages dropped ** [ 31.122528] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 8885 printk messages dropped ** [ 31.287658] [<c0218ed0>] (fbcon_scroll) from [<c025af90>] (scrup+0x60/0x128)
** 9408 printk messages dropped ** [ 31.461425] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 9787 printk messages dropped ** [ 31.644287] [<c02187e8>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10081 printk messages dropped ** [ 31.833984] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10501 printk messages dropped ** [ 32.031066] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10816 printk messages dropped ** [ 32.233001] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10900 printk messages dropped ** [ 32.440490] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10837 printk messages dropped ** [ 32.645233] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10837 printk messages dropped ** [ 32.848999] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10837 printk messages dropped ** [ 33.053833] [<c02187a4>] (fbcon_redraw.isra.12) from [<c0218ed0>]
(fbcon_scroll+0x6a0/0xcbc)
** 10838 printk messages dropped ** [ 33.258361] [<c0218ed0>] (fbcon_scroll) from [<c025af90>] (scrup+0x60/0x128)
I suspect that problem is in omapdss.
I do not know if size 0 make sense, but Maemo userspace is calling above
commands and on Nokia's 2.6.28 kernel there is no crash or error message.
IMHO Division by zero in kernel should not be there even if userspace
call "incorrect" command.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] backlight: pm8941-wled: Add default-brightness property
From: Rob Herring @ 2015-07-24 15:39 UTC (permalink / raw)
To: Rob Clark
Cc: Bjorn Andersson, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Jingoo Han, Lee Jones,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
devicetree@vger.kernel.org, Linux Kernel Mailing List,
Linux Fbdev development list, linux-arm-msm
In-Reply-To: <CAF6AEGsJdLYzCA_=M8hf1XfhRxFAaY6VFdSBRP+y56uKsnQHiA@mail.gmail.com>
On Fri, Jul 24, 2015 at 8:10 AM, Rob Clark <robdclark@gmail.com> wrote:
> On Thu, Jul 23, 2015 at 3:52 PM, Bjorn Andersson
> <bjorn.andersson@sonymobile.com> wrote:
>> Add the possibility of specifying the default brightness in DT.
>>
>> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
>> ---
>>
>> This depends on the patch moving pm8941-wled to backlight [1]. The dt property
>> is used by several other backlight drivers, so I considered this to be a
>> "common" property and it's hence not prefixed with "qcom,".
>>
>> [1] https://lkml.org/lkml/2015/7/21/906
>>
>> Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt | 1 +
>> drivers/video/backlight/pm8941-wled.c | 4 ++++
>> 2 files changed, 5 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
>> index 424f8444a6cd..37503f8c3620 100644
>> --- a/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
>> +++ b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
>> @@ -5,6 +5,7 @@ Required properties:
>> - reg: slave address
>>
>> Optional properties:
>> +- default-brightness: value from: 0-4095
>> - label: The name of the backlight device
>> - qcom,cs-out: bool; enable current sink output
>> - qcom,cabc: bool; enable content adaptive backlight control
>> diff --git a/drivers/video/backlight/pm8941-wled.c b/drivers/video/backlight/pm8941-wled.c
>> index c704c3236034..b875e58df0fc 100644
>> --- a/drivers/video/backlight/pm8941-wled.c
>> +++ b/drivers/video/backlight/pm8941-wled.c
>> @@ -373,6 +373,7 @@ static int pm8941_wled_probe(struct platform_device *pdev)
>> struct backlight_device *bl;
>> struct pm8941_wled *wled;
>> struct regmap *regmap;
>> + u32 val = 0;
>> int rc;
>
> as discussed on IRC, it would be better if the default read back the
> current settings (so-as to inherit bootloader splash smoothly..
> drm/msm supports a memory-region phandle, for example, so it can take
> over the bootloader splash-screen as stolen-mem)
>
> and it would I think be useful to have a comment in the bindings file
> explaining that you *should* use the default-brightness property to
> set a sane default if bootloader isn't putting up a splash, and you
> should *not* use the property if it is..
+1
What if you have neither? Set to max brightness? 75%?
This could also be used for the bootloader to communicate to the
kernel what the current level is if it is not readable. I've seen one
backlight recently which you change the level by doing some number of
pulses on a gpio and a long pulse to turn off. So there is no way to
know current level without turning off the backlight (unless you
hardcode the bootloader's level in the kernel like the vendor did).
Rob
^ permalink raw reply
* Re: [PATCH] backlight: pm8941-wled: Add default-brightness property
From: Rob Herring @ 2015-07-24 15:29 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Jingoo Han,
Lee Jones, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Rob Clark, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org,
linux-arm-msm
In-Reply-To: <1437681127-15760-1-git-send-email-bjorn.andersson@sonymobile.com>
On Thu, Jul 23, 2015 at 2:52 PM, Bjorn Andersson
<bjorn.andersson@sonymobile.com> wrote:
> Add the possibility of specifying the default brightness in DT.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> ---
>
> This depends on the patch moving pm8941-wled to backlight [1]. The dt property
> is used by several other backlight drivers, so I considered this to be a
> "common" property and it's hence not prefixed with "qcom,".
Well, we have "default-brightness" and "default-brightness-level" used
by 1 driver each. But default-brightness-level is much more commonly
used (in dts files) since it is in the pwm backlight binding, so we
should go with it. I'd like to see this moved to a common backlight
doc.
Really, I think all the backlight documentation should be merged with
LEDs docs. Things like "default-on" are common. But I won't ask to do
that here.
Rob
>
> [1] https://lkml.org/lkml/2015/7/21/906
>
> Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt | 1 +
> drivers/video/backlight/pm8941-wled.c | 4 ++++
> 2 files changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
> index 424f8444a6cd..37503f8c3620 100644
> --- a/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
> +++ b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
> @@ -5,6 +5,7 @@ Required properties:
> - reg: slave address
>
> Optional properties:
> +- default-brightness: value from: 0-4095
> - label: The name of the backlight device
> - qcom,cs-out: bool; enable current sink output
> - qcom,cabc: bool; enable content adaptive backlight control
> diff --git a/drivers/video/backlight/pm8941-wled.c b/drivers/video/backlight/pm8941-wled.c
> index c704c3236034..b875e58df0fc 100644
> --- a/drivers/video/backlight/pm8941-wled.c
> +++ b/drivers/video/backlight/pm8941-wled.c
> @@ -373,6 +373,7 @@ static int pm8941_wled_probe(struct platform_device *pdev)
> struct backlight_device *bl;
> struct pm8941_wled *wled;
> struct regmap *regmap;
> + u32 val = 0;
> int rc;
>
> regmap = dev_get_regmap(pdev->dev.parent, NULL);
> @@ -395,8 +396,11 @@ static int pm8941_wled_probe(struct platform_device *pdev)
> if (rc)
> return rc;
>
> + of_property_read_u32(pdev->dev.of_node, "default-brightness", &val);
> +
> memset(&props, 0, sizeof(struct backlight_properties));
> props.type = BACKLIGHT_RAW;
> + props.brightness = val;
> props.max_brightness = PM8941_WLED_REG_VAL_MAX;
> bl = devm_backlight_device_register(&pdev->dev, wled->name,
> &pdev->dev, wled,
> --
> 1.8.2.2
>
^ permalink raw reply
* [PATCH] ARM/fb: ep93xx: switch framebuffer to use modedb only
From: Linus Walleij @ 2015-07-24 13:31 UTC (permalink / raw)
To: linux-arm-kernel
All the EP93xx boards exclusively use modedb to look up video
modes from the command line. Root out the parametrization of
custom video modes from the platform data and board files
and simplify the driver.
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
J-C/Tomi: please ACK this if you're OK with it so I can take
it through the ARM SoC tree.
---
arch/arm/mach-ep93xx/edb93xx.c | 2 --
arch/arm/mach-ep93xx/simone.c | 2 --
arch/arm/mach-ep93xx/snappercl15.c | 2 --
arch/arm/mach-ep93xx/vision_ep9307.c | 2 --
drivers/video/fbdev/ep93xx-fb.c | 30 ++++--------------------------
include/linux/platform_data/video-ep93xx.h | 8 --------
6 files changed, 4 insertions(+), 42 deletions(-)
diff --git a/arch/arm/mach-ep93xx/edb93xx.c b/arch/arm/mach-ep93xx/edb93xx.c
index 27b14ae92c7e..ad92d9f7e4df 100644
--- a/arch/arm/mach-ep93xx/edb93xx.c
+++ b/arch/arm/mach-ep93xx/edb93xx.c
@@ -205,8 +205,6 @@ static void __init edb93xx_register_pwm(void)
* EDB93xx framebuffer
*************************************************************************/
static struct ep93xxfb_mach_info __initdata edb93xxfb_info = {
- .num_modes = EP93XXFB_USE_MODEDB,
- .bpp = 16,
.flags = 0,
};
diff --git a/arch/arm/mach-ep93xx/simone.c b/arch/arm/mach-ep93xx/simone.c
index d0938a219443..7bb540c421ee 100644
--- a/arch/arm/mach-ep93xx/simone.c
+++ b/arch/arm/mach-ep93xx/simone.c
@@ -40,8 +40,6 @@ static struct ep93xx_eth_data __initdata simone_eth_data = {
};
static struct ep93xxfb_mach_info __initdata simone_fb_info = {
- .num_modes = EP93XXFB_USE_MODEDB,
- .bpp = 16,
.flags = EP93XXFB_USE_SDCSN0 | EP93XXFB_PCLK_FALLING,
};
diff --git a/arch/arm/mach-ep93xx/snappercl15.c b/arch/arm/mach-ep93xx/snappercl15.c
index aa86f86638dd..c4904264256a 100644
--- a/arch/arm/mach-ep93xx/snappercl15.c
+++ b/arch/arm/mach-ep93xx/snappercl15.c
@@ -144,8 +144,6 @@ static struct i2c_board_info __initdata snappercl15_i2c_data[] = {
};
static struct ep93xxfb_mach_info __initdata snappercl15_fb_info = {
- .num_modes = EP93XXFB_USE_MODEDB,
- .bpp = 16,
};
static struct platform_device snappercl15_audio_device = {
diff --git a/arch/arm/mach-ep93xx/vision_ep9307.c b/arch/arm/mach-ep93xx/vision_ep9307.c
index ff22a6a6e2bf..5cced5988498 100644
--- a/arch/arm/mach-ep93xx/vision_ep9307.c
+++ b/arch/arm/mach-ep93xx/vision_ep9307.c
@@ -106,8 +106,6 @@ static void vision_lcd_blank(int blank_mode, struct fb_info *info)
}
static struct ep93xxfb_mach_info ep93xxfb_info __initdata = {
- .num_modes = EP93XXFB_USE_MODEDB,
- .bpp = 16,
.flags = EP93XXFB_USE_SDCSN0 | EP93XXFB_PCLK_FALLING,
.setup = vision_lcd_setup,
.teardown = vision_lcd_teardown,
diff --git a/drivers/video/fbdev/ep93xx-fb.c b/drivers/video/fbdev/ep93xx-fb.c
index 7ec251cc9c03..5b1081030cbb 100644
--- a/drivers/video/fbdev/ep93xx-fb.c
+++ b/drivers/video/fbdev/ep93xx-fb.c
@@ -419,36 +419,15 @@ static struct fb_ops ep93xxfb_ops = {
.fb_mmap = ep93xxfb_mmap,
};
-static int ep93xxfb_calc_fbsize(struct ep93xxfb_mach_info *mach_info)
-{
- int i, fb_size = 0;
-
- if (mach_info->num_modes = EP93XXFB_USE_MODEDB) {
- fb_size = EP93XXFB_MAX_XRES * EP93XXFB_MAX_YRES *
- mach_info->bpp / 8;
- } else {
- for (i = 0; i < mach_info->num_modes; i++) {
- const struct fb_videomode *mode;
- int size;
-
- mode = &mach_info->modes[i];
- size = mode->xres * mode->yres * mach_info->bpp / 8;
- if (size > fb_size)
- fb_size = size;
- }
- }
-
- return fb_size;
-}
-
static int ep93xxfb_alloc_videomem(struct fb_info *info)
{
- struct ep93xx_fbi *fbi = info->par;
char __iomem *virt_addr;
dma_addr_t phys_addr;
unsigned int fb_size;
- fb_size = ep93xxfb_calc_fbsize(fbi->mach_info);
+ /* Maximum 16bpp -> used memory is maximum x*y*2 bytes */
+ fb_size = EP93XXFB_MAX_XRES * EP93XXFB_MAX_YRES * 2;
+
virt_addr = dma_alloc_writecombine(info->dev, fb_size,
&phys_addr, GFP_KERNEL);
if (!virt_addr)
@@ -550,8 +529,7 @@ static int ep93xxfb_probe(struct platform_device *pdev)
fb_get_options("ep93xx-fb", &video_mode);
err = fb_find_mode(&info->var, info, video_mode,
- fbi->mach_info->modes, fbi->mach_info->num_modes,
- fbi->mach_info->default_mode, fbi->mach_info->bpp);
+ NULL, 0, NULL, 16);
if (err = 0) {
dev_err(info->dev, "No suitable video mode found\n");
err = -EINVAL;
diff --git a/include/linux/platform_data/video-ep93xx.h b/include/linux/platform_data/video-ep93xx.h
index 92fc2b2232e7..699ac4109366 100644
--- a/include/linux/platform_data/video-ep93xx.h
+++ b/include/linux/platform_data/video-ep93xx.h
@@ -2,11 +2,8 @@
#define __VIDEO_EP93XX_H
struct platform_device;
-struct fb_videomode;
struct fb_info;
-#define EP93XXFB_USE_MODEDB 0
-
/* VideoAttributes flags */
#define EP93XXFB_STATE_MACHINE_ENABLE (1 << 0)
#define EP93XXFB_PIXEL_CLOCK_ENABLE (1 << 1)
@@ -38,12 +35,7 @@ struct fb_info;
EP93XXFB_PIXEL_DATA_ENABLE)
struct ep93xxfb_mach_info {
- unsigned int num_modes;
- const struct fb_videomode *modes;
- const struct fb_videomode *default_mode;
- int bpp;
unsigned int flags;
-
int (*setup)(struct platform_device *pdev);
void (*teardown)(struct platform_device *pdev);
void (*blank)(int blank_mode, struct fb_info *info);
--
2.4.3
^ permalink raw reply related
* Re: [PATCH] backlight: pm8941-wled: Add default-brightness property
From: Rob Clark @ 2015-07-24 13:10 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Jingoo Han,
Lee Jones, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Kernel Mailing List, Linux Fbdev development list,
linux-arm-msm
In-Reply-To: <1437681127-15760-1-git-send-email-bjorn.andersson-/MT0OVThwyLZJqsBc5GL+g@public.gmane.org>
On Thu, Jul 23, 2015 at 3:52 PM, Bjorn Andersson
<bjorn.andersson@sonymobile.com> wrote:
> Add the possibility of specifying the default brightness in DT.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> ---
>
> This depends on the patch moving pm8941-wled to backlight [1]. The dt property
> is used by several other backlight drivers, so I considered this to be a
> "common" property and it's hence not prefixed with "qcom,".
>
> [1] https://lkml.org/lkml/2015/7/21/906
>
> Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt | 1 +
> drivers/video/backlight/pm8941-wled.c | 4 ++++
> 2 files changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
> index 424f8444a6cd..37503f8c3620 100644
> --- a/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
> +++ b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
> @@ -5,6 +5,7 @@ Required properties:
> - reg: slave address
>
> Optional properties:
> +- default-brightness: value from: 0-4095
> - label: The name of the backlight device
> - qcom,cs-out: bool; enable current sink output
> - qcom,cabc: bool; enable content adaptive backlight control
> diff --git a/drivers/video/backlight/pm8941-wled.c b/drivers/video/backlight/pm8941-wled.c
> index c704c3236034..b875e58df0fc 100644
> --- a/drivers/video/backlight/pm8941-wled.c
> +++ b/drivers/video/backlight/pm8941-wled.c
> @@ -373,6 +373,7 @@ static int pm8941_wled_probe(struct platform_device *pdev)
> struct backlight_device *bl;
> struct pm8941_wled *wled;
> struct regmap *regmap;
> + u32 val = 0;
> int rc;
as discussed on IRC, it would be better if the default read back the
current settings (so-as to inherit bootloader splash smoothly..
drm/msm supports a memory-region phandle, for example, so it can take
over the bootloader splash-screen as stolen-mem)
and it would I think be useful to have a comment in the bindings file
explaining that you *should* use the default-brightness property to
set a sane default if bootloader isn't putting up a splash, and you
should *not* use the property if it is..
BR,
-R
> regmap = dev_get_regmap(pdev->dev.parent, NULL);
> @@ -395,8 +396,11 @@ static int pm8941_wled_probe(struct platform_device *pdev)
> if (rc)
> return rc;
>
> + of_property_read_u32(pdev->dev.of_node, "default-brightness", &val);
> +
> memset(&props, 0, sizeof(struct backlight_properties));
> props.type = BACKLIGHT_RAW;
> + props.brightness = val;
> props.max_brightness = PM8941_WLED_REG_VAL_MAX;
> bl = devm_backlight_device_register(&pdev->dev, wled->name,
> &pdev->dev, wled,
> --
> 1.8.2.2
>
^ permalink raw reply
* Re: [PATCH] backlight: pm8941-wled: Add default-brightness property
From: Lee Jones @ 2015-07-24 8:22 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Jingoo Han,
Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Rob Clark,
devicetree, linux-kernel, linux-fbdev, linux-arm-msm
In-Reply-To: <1437681127-15760-1-git-send-email-bjorn.andersson@sonymobile.com>
On Thu, 23 Jul 2015, Bjorn Andersson wrote:
> Add the possibility of specifying the default brightness in DT.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> ---
>
> This depends on the patch moving pm8941-wled to backlight [1]. The dt property
> is used by several other backlight drivers, so I considered this to be a
> "common" property and it's hence not prefixed with "qcom,".
>
> [1] https://lkml.org/lkml/2015/7/21/906
>
> Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt | 1 +
This needs to be in a seperate patch.
> drivers/video/backlight/pm8941-wled.c | 4 ++++
You can't send patches on top of non-existent drivers.
> 2 files changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
> index 424f8444a6cd..37503f8c3620 100644
> --- a/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
> +++ b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
> @@ -5,6 +5,7 @@ Required properties:
> - reg: slave address
>
> Optional properties:
> +- default-brightness: value from: 0-4095
> - label: The name of the backlight device
> - qcom,cs-out: bool; enable current sink output
> - qcom,cabc: bool; enable content adaptive backlight control
> diff --git a/drivers/video/backlight/pm8941-wled.c b/drivers/video/backlight/pm8941-wled.c
> index c704c3236034..b875e58df0fc 100644
> --- a/drivers/video/backlight/pm8941-wled.c
> +++ b/drivers/video/backlight/pm8941-wled.c
> @@ -373,6 +373,7 @@ static int pm8941_wled_probe(struct platform_device *pdev)
> struct backlight_device *bl;
> struct pm8941_wled *wled;
> struct regmap *regmap;
> + u32 val = 0;
> int rc;
>
> regmap = dev_get_regmap(pdev->dev.parent, NULL);
> @@ -395,8 +396,11 @@ static int pm8941_wled_probe(struct platform_device *pdev)
> if (rc)
> return rc;
>
> + of_property_read_u32(pdev->dev.of_node, "default-brightness", &val);
> +
> memset(&props, 0, sizeof(struct backlight_properties));
> props.type = BACKLIGHT_RAW;
> + props.brightness = val;
> props.max_brightness = PM8941_WLED_REG_VAL_MAX;
> bl = devm_backlight_device_register(&pdev->dev, wled->name,
> &pdev->dev, wled,
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ 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