* [PATCH] staging/sm7xxfb: Make 'struct vgamode' static
From: Peter Senna Tschudin @ 2015-02-23 11:16 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, devel,
linux-kernel
Cc: Peter Senna Tschudin
sparse was complaining that symbol 'vgamode' was not declared.
Declaring vgamode as static.
Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
---
Tested by compilation only
drivers/staging/sm7xxfb/sm7xx.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/sm7xxfb/sm7xx.h b/drivers/staging/sm7xxfb/sm7xx.h
index 7cc1896..c5d6253 100644
--- a/drivers/staging/sm7xxfb/sm7xx.h
+++ b/drivers/staging/sm7xxfb/sm7xx.h
@@ -119,7 +119,7 @@ struct ModeInit {
/**********************************************************************
SM712 Mode table.
**********************************************************************/
-struct ModeInit vgamode[] = {
+static struct ModeInit vgamode[] = {
{
/* mode#0: 640 x 480 16Bpp 60Hz */
640, 480, 16, 60,
--
2.1.0
^ permalink raw reply related
* Re: [PATCH 2/8] fbdev: ssd1307fb: Unify init code and make controller configurable from device tree
From: Maxime Ripard @ 2015-02-23 9:43 UTC (permalink / raw)
To: Thomas Niederprüm
Cc: linux-fbdev, plagnioj, tomi.valkeinen, linux-kernel
In-Reply-To: <20150214171232.11ccb264@maestro.intranet>
[-- Attachment #1: Type: text/plain, Size: 9563 bytes --]
On Sat, Feb 14, 2015 at 05:12:32PM +0100, Thomas Niederprüm wrote:
> Am Thu, 12 Feb 2015 17:41:47 +0100
> schrieb Maxime Ripard <maxime.ripard@free-electrons.com>:
>
> > On Sat, Feb 07, 2015 at 03:59:33PM +0100, Thomas Niederprüm wrote:
> > > Am Sat, 7 Feb 2015 11:42:25 +0100
> > > schrieb Maxime Ripard <maxime.ripard@free-electrons.com>:
> > >
> > > > Hi,
> > > >
> > > > On Fri, Feb 06, 2015 at 11:28:08PM +0100, niederp@physik.uni-kl.de
> > > > wrote:
> > > > > From: Thomas Niederprüm <niederp@physik.uni-kl.de>
> > > > >
> > > > > This patches unifies the init code for the ssd130X chips and
> > > > > adds device tree bindings to describe the hardware configuration
> > > > > of the used controller. This gets rid of the magic bit values
> > > > > used in the init code so far.
> > > > >
> > > > > Signed-off-by: Thomas Niederprüm <niederp@physik.uni-kl.de>
> > > > > ---
> > > > > .../devicetree/bindings/video/ssd1307fb.txt | 11 +
> > > > > drivers/video/fbdev/ssd1307fb.c | 243
> > > > > ++++++++++++++------- 2 files changed, 174 insertions(+), 80
> > > > > deletions(-)
> > > > >
> > > > > diff --git
> > > > > a/Documentation/devicetree/bindings/video/ssd1307fb.txt
> > > > > b/Documentation/devicetree/bindings/video/ssd1307fb.txt index
> > > > > 7a12542..1230f68 100644 ---
> > > > > a/Documentation/devicetree/bindings/video/ssd1307fb.txt +++
> > > > > b/Documentation/devicetree/bindings/video/ssd1307fb.txt @@
> > > > > -15,6 +15,17 @@ Required properties: Optional properties:
> > > > > - reset-active-low: Is the reset gpio is active on physical
> > > > > low?
> > > > > + - solomon,segment-remap: Invert the order of data column to
> > > > > segment mapping
> > > > > + - solomon,offset: Map the display start line to one of COM0 -
> > > > > COM63
> > > > > + - solomon,contrast: Set initial contrast of the display
> > > > > + - solomon,prechargep1: Set the duration of the precharge
> > > > > period phase1
> > > > > + - solomon,prechargep2: Set the duration of the precharge
> > > > > period phase2
> > > > > + - solomon,com-alt: Enable/disable alternate COM pin
> > > > > configuration
> > > > > + - solomon,com-lrremap: Enable/disable left-right remap of COM
> > > > > pins
> > > > > + - solomon,com-invdir: Invert COM scan direction
> > > > > + - solomon,vcomh: Set VCOMH regulator voltage
> > > > > + - solomon,dclk-div: Set display clock divider
> > > > > + - solomon,dclk-frq: Set display clock frequency
> > > >
> > > > I'm sorry, but this is the wrong approach, for at least two
> > > > reasons: you broke all existing users of that driver, which is a
> > > > clear no-go,
> > >
> > > Unfortunately this is true. The problem is that the SSD130X
> > > controllers allow for a very versatile wiring of the display to the
> > > controller. It's over to the manufacturer of the OLED module
> > > (disp+controller) to decide how it's actually wired and during
> > > device initialization the driver has to take care to configure the
> > > SSD130X controller according to that wiring. If the driver fails to
> > > do so you will end up having your display showing
> > > garbage.
> >
> > How so?
>
> One good example is the segment remap. It basically allows to invert the
> order of the output pins connecting to the oled panel. This gives the
> manufacturer of the module the freedom wire it the one way or the
> other, depending on the PCB restrictions/panel layout (Section 10.1.12
> of [0], 10.1.8 in [1], 9.1.8 in [2]). However, once the panel is
> connected to the controller it's determined whether the segment remap
> is needed or not. Setting the segment remap as done in the current
> initialization code for ssd1306 and ssd1307 makes my display module
> show it's contents mirrored left to right, probably since the
> manufacturer decided not to connect the panel in an inverted order.
>
> The same applies to the com-alt, com-lrremap and com-invdir values,
> which define different possibilities for the COM signals pin
> configuration (Section 10.1.26 of [0], 10.1.18 in [1], 9.1.18 in [2])
> and readout direction of the video memory (Section 10.1.21 of [0],
> 10.1.14 in [1], 9.1.14 in [2]). Setting com-alt incorrectly leaves
> every other line of the display blank. Setting com-lrremap incorrectly
> produces a very distorted image. Setting com-invdir incorrectly flips
> the image upside down.
>
> IMHO at least these four hardware-specific properties need to be known
> to the driver in order to initialize the hardware correctly.
I'd agree then.
> > Does it depend on the X, or can it change from one same controller to
> > another? to what extent?
>
> Unfortunately I do not posses any hardware utilizing a ssd1306 or
> ssd1307 controller. My primary and only target device is a Newhaven
> NHD-3.12-25664UCB2 OLED display module using an SSD1305 controller. I
> just inferred from the datasheets of ssd1306/7 [1,2] that they should
> behave the same since the registers are bit to bit identical (except
> for the VHCOM register). Maybe that was a bit too naive :/
I would guess it's a rather safe assumption.
> > The 1306 for example seems to not be using these values at all, while
> > the 1307 does.
>
> That is surprising. In that case I would like to ask the guys from
> Solomon why they describe all these options in the SSD1306 datasheet
> [1]. But in any case, isn't that good news for the problem of setting
> the default values. When the 1306 isn't using these values anyway we can
> not break the initialization by setting different default values. In
> this case the problem of the default values boils down to the segment
> remap only since this is set in the init code of the 1307, while the
> default would be to leave it off.
Indeed.
> > > Unfortunately the current sate of the initialization code of the
> > > ssd1307fb driver is not very flexible in that respect. Taking a look
> > > at the initialization code for the ssd1306 shows that it was written
> > > with one very special display module in mind. Most of the magic bit
> > > values set there are non-default values according to the
> > > datasheet. The result is that the driver works with that one
> > > particular display module but many other (differently wired) display
> > > modules using a ssd1306 controller won't work without changing the
> > > hardcoded magic bit values.
> > >
> > > My idea here was to set all configuration to the default values (as
> > > given in the datasheet) unless it is overwritten by DT. Of course,
> > > without a change in DT, this breaks the driver for all existing
> > > users. The only alternative would be to set the current values as
> > > default. Somehow this feels wrong to me as these values look
> > > arbitrary when you don't know what exact display module they were
> > > set for. But if you insist, I will change the default values.
> >
> > Unfortunately, the DT bindings are to be considered an ABI, and we
> > should support booting with older DTs (not that I personally care
> > about it, but that's another issue). So we really don't have much
> > choice here.
> >
> > Moreover, that issue left aside, modifying bindings like this without
> > fixing up the in-tree users is considered quite rude :)
>
> I didn't intend to be rude, sorry. A quick search revealed that there
> is luckily only one in-tree user, which is imx28-cfa10036.dts. In case
> it will be necessary I will include a patch to fix this.
Please do (and fix the bindings Documentation too).
> > > > and the DT itself should not contain any direct mapping of the
> > > > registers.
> > > >
> > >
> > > I think I don't get what you mean here. Is it because I do no sanity
> > > checks of the numbers set in DT? I was just looking for a way to
> > > hand over the information about the wiring of display to the
> > > driver. How would you propose to solve this?
> >
> > What I meant was that replicating direct registers value is usually a
> > recipe for a later failure, especially if we can have the information
> > under a generic and easy to understand manner.
> >
> > For example, replacing the solomon,dclk-div and solomon,dclk-frq
> > properties by a clock-frequency property in Hz, and computing the
> > divider and that register in your driver is usually better, also
> > because it allows to have different requirements / algorithms to
> > compute that if some other chip needs it.
>
> I'll give that a try, even though that particular one is not trivial
> since the documentation on the actual frequency that is set by the
> dclk-freq is very poor (not present for 1306/1307 [1,2], just a graph
> for 1305 [0]).
>
> For the properties describing the hardware pin configuration (see above)
> I see no real alternative. Maybe they can all be covered by one DT
> property like:
> solomon,com-cfg = PINCFG_SEGREMAP | PINCFG_COMALT | PINCFG_COMINV |
> PINCFG_COMLRRM
> each PINCFG_* setting one bit. The driver will then translate this into
> the correct settings for the 130X registers. The only problem here is
> that this implicitly assumes the default values of each bit to be 0.
A property that would be here or not is better. You can have all the
defaults you want, it's more clear in the DT, and you don't need the
macros.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* CONTRACT SUPPLY.
From: Ets Alex Global @ 2015-02-21 15:20 UTC (permalink / raw)
To: linux-fbdev
Dear Sir/Madam,
We are here to introduce our company as a registered Importing company
based in Supplying and Distributing of all kind of goods.with
registration endorsement under the Togo Lome Commerce and Industry.
Our company has been into Importation and distribution of goods for
many years with our international business experience which has given
us the confident to open Three branches offices out side Togo
Republic.
Recently we have being ask by African Trade Union Organization to
source out a reliable firm who will be capable to handle a contract
supply of your products.
We came across your company contact information as a supplier
manufacturer and exporter of above mentioned in your region,With due
respect we request you to please send your prices quotation for our
study in proceedings.
Looking forward to establish a long lasting business with your company.
Regards
Alex Camara.
Alex Global Company Limited
232 Rue Tambina
Phone:+228-90715121.
Lome-Togo.
^ permalink raw reply
* imxfb does not turn on automatically
From: Fabio Estevam @ 2015-02-21 15:18 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Carlos Soto uses a Karo mx25 and he noticed that the LCD only works if we do:
echo 1 > /sys/class/graphics/fb0/blank
echo 0 > /sys/class/graphics/fb0/blank
I can confirm the same on mx25pdk running 3.19 [1], but I could not
understand why the display does not start turned on by default.
[1] http://www.spinics.net/lists/arm-kernel/msg399949.html
Any ideas?
Thanks,
Fabio Estevam
^ permalink raw reply
* [PATCH] video: fbdev-SIS: Deletion of unnecessary checks before three function calls
From: SF Markus Elfring @ 2015-02-21 13:26 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Thomas Winischhofer,
Tomi Valkeinen, linux-fbdev
Cc: LKML, kernel-janitors, Julia Lawall
In-Reply-To: <5317A59D.4@users.sourceforge.net>
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Sat, 21 Feb 2015 14:14:56 +0100
The functions sisfb_search_crt2type(), sisfb_search_specialtiming() and
sisfb_search_tvstd() test whether their argument is NULL and then
return immediately. Thus the test around their calls is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/video/fbdev/sis/sis_main.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/video/fbdev/sis/sis_main.c b/drivers/video/fbdev/sis/sis_main.c
index fcf610e..20ca80f 100644
--- a/drivers/video/fbdev/sis/sis_main.c
+++ b/drivers/video/fbdev/sis/sis_main.c
@@ -6605,12 +6605,9 @@ static int __init sisfb_init_module(void)
sisfb_scalelcd = scalelcd ^ 1;
/* Need to check crt2 type first for fstn/dstn */
+ sisfb_search_crt2type(forcecrt2type);
- if(forcecrt2type)
- sisfb_search_crt2type(forcecrt2type);
-
- if(tvstandard)
- sisfb_search_tvstd(tvstandard);
+ sisfb_search_tvstd(tvstandard);
if(mode)
sisfb_search_mode(mode, false);
@@ -6656,9 +6653,7 @@ static int __init sisfb_init_module(void)
sisfb_pdca = (pdc1 & 0x1f);
sisfb_nocrt2rate = nocrt2rate;
-
- if(specialtiming)
- sisfb_search_specialtiming(specialtiming);
+ sisfb_search_specialtiming(specialtiming);
if((lvdshl >= 0) && (lvdshl <= 3))
sisfb_lvdshl = lvdshl;
--
2.3.0
^ permalink raw reply related
* [PATCH] fbdev: goldfishfb: use devres api
From: Prabhakar Lad @ 2015-02-20 17:51 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard, Tomi Valkeinen
Cc: linux-fbdev, linux-kernel, Lad, Prabhakar
From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
this patch does the following:
a> uses devm_kzalloc() instead of kzalloc and cleanup the error path
b> uses devm_ioremap() instead of ioremap and cleanup the error path
c> uses devm_request_irq() instead of request_irq and cleanup the error path
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
---
Note: This patch is compile tested only and applies on linux-next.
drivers/video/fbdev/goldfishfb.c | 61 +++++++++++++++-------------------------
1 file changed, 22 insertions(+), 39 deletions(-)
diff --git a/drivers/video/fbdev/goldfishfb.c b/drivers/video/fbdev/goldfishfb.c
index 7f6c9e6..841514d 100644
--- a/drivers/video/fbdev/goldfishfb.c
+++ b/drivers/video/fbdev/goldfishfb.c
@@ -188,31 +188,25 @@ static int goldfish_fb_probe(struct platform_device *pdev)
u32 width, height;
dma_addr_t fbpaddr;
- fb = kzalloc(sizeof(*fb), GFP_KERNEL);
- if (fb = NULL) {
- ret = -ENOMEM;
- goto err_fb_alloc_failed;
- }
+ fb = devm_kzalloc(&pdev->dev, sizeof(*fb), GFP_KERNEL);
+ if (fb = NULL)
+ return -ENOMEM;
+
spin_lock_init(&fb->lock);
init_waitqueue_head(&fb->wait);
platform_set_drvdata(pdev, fb);
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (r = NULL) {
- ret = -ENODEV;
- goto err_no_io_base;
- }
- fb->reg_base = ioremap(r->start, PAGE_SIZE);
- if (fb->reg_base = NULL) {
- ret = -ENOMEM;
- goto err_no_io_base;
- }
+ if (r = NULL)
+ return -ENODEV;
+
+ fb->reg_base = devm_ioremap(&pdev->dev, r->start, PAGE_SIZE);
+ if (fb->reg_base = NULL)
+ return -ENOMEM;
fb->irq = platform_get_irq(pdev, 0);
- if (fb->irq <= 0) {
- ret = -ENODEV;
- goto err_no_irq;
- }
+ if (fb->irq <= 0)
+ return -ENODEV;
width = readl(fb->reg_base + FB_GET_WIDTH);
height = readl(fb->reg_base + FB_GET_HEIGHT);
@@ -249,43 +243,34 @@ static int goldfish_fb_probe(struct platform_device *pdev)
&fbpaddr, GFP_KERNEL);
pr_debug("allocating frame buffer %d * %d, got %p\n",
width, height, fb->fb.screen_base);
- if (fb->fb.screen_base = NULL) {
- ret = -ENOMEM;
- goto err_alloc_screen_base_failed;
- }
+ if (fb->fb.screen_base = NULL)
+ return -ENOMEM;
+
fb->fb.fix.smem_start = fbpaddr;
fb->fb.fix.smem_len = framesize;
ret = fb_set_var(&fb->fb, &fb->fb.var);
if (ret)
- goto err_fb_set_var_failed;
+ goto error;
- ret = request_irq(fb->irq, goldfish_fb_interrupt, IRQF_SHARED,
- pdev->name, fb);
+ ret = devm_request_irq(&pdev->dev, fb->irq, goldfish_fb_interrupt,
+ IRQF_SHARED, pdev->name, fb);
if (ret)
- goto err_request_irq_failed;
+ goto error;
writel(FB_INT_BASE_UPDATE_DONE, fb->reg_base + FB_INT_ENABLE);
goldfish_fb_pan_display(&fb->fb.var, &fb->fb); /* updates base */
ret = register_framebuffer(&fb->fb);
if (ret)
- goto err_register_framebuffer_failed;
+ goto error;
+
return 0;
-err_register_framebuffer_failed:
- free_irq(fb->irq, fb);
-err_request_irq_failed:
-err_fb_set_var_failed:
+error:
dma_free_coherent(&pdev->dev, framesize,
(void *)fb->fb.screen_base,
fb->fb.fix.smem_start);
-err_alloc_screen_base_failed:
-err_no_irq:
- iounmap(fb->reg_base);
-err_no_io_base:
- kfree(fb);
-err_fb_alloc_failed:
return ret;
}
@@ -296,11 +281,9 @@ static int goldfish_fb_remove(struct platform_device *pdev)
framesize = fb->fb.var.xres_virtual * fb->fb.var.yres_virtual * 2;
unregister_framebuffer(&fb->fb);
- free_irq(fb->irq, fb);
dma_free_coherent(&pdev->dev, framesize, (void *)fb->fb.screen_base,
fb->fb.fix.smem_start);
- iounmap(fb->reg_base);
return 0;
}
--
1.9.1
^ permalink raw reply related
* [PATCH v2] video: fbdev: use msecs_to_jiffies for time conversions
From: Nicholas Mc Guire @ 2015-02-20 14:34 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard
Cc: Tomi Valkeinen, Jingoo Han, Daniel Vetter, Fabian Frederick,
Laurent Pinchart, Nicholas Mc Guire, Wolfram Sang, linux-fbdev,
linux-kernel
This is only an API consolidation and should make things more readable by
replacing var * HZ / 1000 by msecs_to_jiffies(var).
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
---
v2: fixed missing closing parenthesis in pxafb_disable_controller.
Compile testing was missing part of the patched code due to
the missing CONFIG_FB_PXA_SMARTPANEL=y, so the missing closing
parenthesis reported by Tomi Valkeinen <tomi.valkeinen@ti.com>
pxafb_disable_controller went unnoticed.
Patch was only compile tested with viper_defconfig CONFIG_FB_PXA=m,
CONFIG_FB_PXA_SMARTPANEL=y
Patch is against 3.19.0 (localversion-next is -next-20150220)
drivers/video/fbdev/pxafb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
index da2431e..d8b4743 100644
--- a/drivers/video/fbdev/pxafb.c
+++ b/drivers/video/fbdev/pxafb.c
@@ -1285,7 +1285,7 @@ static int pxafb_smart_thread(void *arg)
mutex_unlock(&fbi->ctrlr_lock);
set_current_state(TASK_INTERRUPTIBLE);
- schedule_timeout(30 * HZ / 1000);
+ schedule_timeout(msecs_to_jiffies(30));
}
pr_debug("%s(): task ending\n", __func__);
@@ -1460,7 +1460,7 @@ static void pxafb_disable_controller(struct pxafb_info *fbi)
#ifdef CONFIG_FB_PXA_SMARTPANEL
if (fbi->lccr0 & LCCR0_LCDT) {
wait_for_completion_timeout(&fbi->refresh_done,
- 200 * HZ / 1000);
+ msecs_to_jiffies(200));
return;
}
#endif
@@ -1472,7 +1472,7 @@ static void pxafb_disable_controller(struct pxafb_info *fbi)
lcd_writel(fbi, LCCR0, lccr0);
lcd_writel(fbi, LCCR0, lccr0 | LCCR0_DIS);
- wait_for_completion_timeout(&fbi->disable_done, 200 * HZ / 1000);
+ wait_for_completion_timeout(&fbi->disable_done, msecs_to_jiffies(200));
/* disable LCD controller clock */
clk_disable_unprepare(fbi->clk);
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] video: fbdev: use msecs_to_jiffies for time conversion
From: Nicholas Mc Guire @ 2015-02-20 14:20 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Nicholas Mc Guire, Jean-Christophe Plagniol-Villard, Jingoo Han,
Daniel Vetter, Fabian Frederick, Laurent Pinchart, Wolfram Sang,
linux-fbdev, linux-kernel
In-Reply-To: <54E73F78.3050009@ti.com>
On Fri, 20 Feb 2015, Tomi Valkeinen wrote:
> On 20/02/15 16:01, Nicholas Mc Guire wrote:
>
> >>> pr_debug("%s(): task ending\n", __func__);
> >>> @@ -1460,7 +1460,7 @@ static void pxafb_disable_controller(struct pxafb_info *fbi)
> >>> #ifdef CONFIG_FB_PXA_SMARTPANEL
> >>> if (fbi->lccr0 & LCCR0_LCDT) {
> >>> wait_for_completion_timeout(&fbi->refresh_done,
> >>> - 200 * HZ / 1000);
> >>> + msecs_to_jiffies(200);
> >>
> >> That will not compile.
>
> > No compile warning or errors
> >
> > could you send me the compile error message and the toolchain you
> > are using - this change should not really have any noticable impact.
>
> I didn't compile it. It's missing a closing parenthesis.
>
> This is one reason I'm not very fond of cleanups to drivers that the
> patch sender cannot test... They may cause more problems than they help.
>
That was the intent of compile testing the patch but it seems
that it was not covered by the config in use - sorry for that, it was
missing the [*] PXA Smartpanel LCD support so
root@debian:~/linux-next# grep CONFIG_FB_PXA_SMARTPANEL .config
# CONFIG_FB_PXA_SMARTPANEL is not set
The motivation for the cleanup simply was code reasdability - will fix this up
and compile check with a proper config.
thx!
hofrat
^ permalink raw reply
* Re: [PATCH] video: fbdev: use msecs_to_jiffies for time conversion
From: Tomi Valkeinen @ 2015-02-20 14:06 UTC (permalink / raw)
To: Nicholas Mc Guire
Cc: Nicholas Mc Guire, Jean-Christophe Plagniol-Villard, Jingoo Han,
Daniel Vetter, Fabian Frederick, Laurent Pinchart, Wolfram Sang,
linux-fbdev, linux-kernel
In-Reply-To: <20150220140110.GA25767@opentech.at>
[-- Attachment #1: Type: text/plain, Size: 810 bytes --]
On 20/02/15 16:01, Nicholas Mc Guire wrote:
>>> pr_debug("%s(): task ending\n", __func__);
>>> @@ -1460,7 +1460,7 @@ static void pxafb_disable_controller(struct pxafb_info *fbi)
>>> #ifdef CONFIG_FB_PXA_SMARTPANEL
>>> if (fbi->lccr0 & LCCR0_LCDT) {
>>> wait_for_completion_timeout(&fbi->refresh_done,
>>> - 200 * HZ / 1000);
>>> + msecs_to_jiffies(200);
>>
>> That will not compile.
> No compile warning or errors
>
> could you send me the compile error message and the toolchain you
> are using - this change should not really have any noticable impact.
I didn't compile it. It's missing a closing parenthesis.
This is one reason I'm not very fond of cleanups to drivers that the
patch sender cannot test... They may cause more problems than they help.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] video: fbdev: use msecs_to_jiffies for time conversion
From: Nicholas Mc Guire @ 2015-02-20 14:01 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Nicholas Mc Guire, Jean-Christophe Plagniol-Villard, Jingoo Han,
Daniel Vetter, Fabian Frederick, Laurent Pinchart, Wolfram Sang,
linux-fbdev, linux-kernel
In-Reply-To: <54E72774.1070809@ti.com>
On Fri, 20 Feb 2015, Tomi Valkeinen wrote:
> On 06/02/15 11:14, Nicholas Mc Guire wrote:
> > This is only an API consolidation and should make things more readable
> > it replaces var * HZ / 1000 by msecs_to_jiffies(var).
> >
> > Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
> > ---
> >
> > Patch was only compile tested with viper_defconfig (implies CONFIG_FB_PXA=m)
> >
> > Patch is against 3.19.0-rc7 (localversion-next is -next-20150204)
> >
> > drivers/video/fbdev/pxafb.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
> > index da2431e..d8b4743 100644
> > --- a/drivers/video/fbdev/pxafb.c
> > +++ b/drivers/video/fbdev/pxafb.c
> > @@ -1285,7 +1285,7 @@ static int pxafb_smart_thread(void *arg)
> > mutex_unlock(&fbi->ctrlr_lock);
> >
> > set_current_state(TASK_INTERRUPTIBLE);
> > - schedule_timeout(30 * HZ / 1000);
> > + schedule_timeout(msecs_to_jiffies(30));
> > }
> >
> > pr_debug("%s(): task ending\n", __func__);
> > @@ -1460,7 +1460,7 @@ static void pxafb_disable_controller(struct pxafb_info *fbi)
> > #ifdef CONFIG_FB_PXA_SMARTPANEL
> > if (fbi->lccr0 & LCCR0_LCDT) {
> > wait_for_completion_timeout(&fbi->refresh_done,
> > - 200 * HZ / 1000);
> > + msecs_to_jiffies(200);
>
> That will not compile.
>
Just reran it on linux-next 3.19.0 -next-20150220
for viper_defconfig using gcc version 4.9.2 20140904 (prerelease)
(crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09)
root@debian:~/linux-next# patch -p1 < 0001-video-fbdev-use-msecs_to_jiffies-for-time-convrsion.patch
patching file drivers/video/fbdev/pxafb.c
root@debian:~/linux-next# make viper_defconfig ARCH=arm
#
# configuration written to .config
#
root@debian:~/linux-next# LANG=en_US make modules ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
...
CC [M] drivers/video/console/softcursor.o
CC [M] drivers/video/fbdev/pxafb.o
CC [M] drivers/video/fbdev/core/cfbfillrect.o
CC [M] drivers/video/fbdev/core/cfbcopyarea.o
CC [M] drivers/video/fbdev/core/cfbimgblt.o
CC [M] sound/sound_core.o
LD [M] sound/soundcore.o
...
CC drivers/video/console/softcursor.mod.o
LDFINAL [M] drivers/video/console/softcursor.ko
CC drivers/video/fbdev/core/cfbcopyarea.mod.o
LDFINAL [M] drivers/video/fbdev/core/cfbcopyarea.ko
CC drivers/video/fbdev/core/cfbfillrect.mod.o
LDFINAL [M] drivers/video/fbdev/core/cfbfillrect.ko
CC drivers/video/fbdev/core/cfbimgblt.mod.o
LDFINAL [M] drivers/video/fbdev/core/cfbimgblt.ko
CC drivers/video/fbdev/pxafb.mod.o
LDFINAL [M] drivers/video/fbdev/pxafb.ko
CC fs/configfs/configfs.mod.o
LDFINAL [M] fs/configfs/configfs.ko
...
No compile warning or errors
could you send me the compile error message and the toolchain you
are using - this change should not really have any noticable impact.
Is this a toolchain issue ?
thx!
hofrat
^ permalink raw reply
* Re: [PATCH] fbdev: via/via_clock: fix sparse warning
From: Tomi Valkeinen @ 2015-02-20 12:26 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Florian Tobias Schandinat, Jean-Christophe Plagniol-Villard,
linux-fbdev, linux-kernel
In-Reply-To: <1423140848-5989-1-git-send-email-prabhakar.csengg@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1153 bytes --]
On 05/02/15 14:54, Lad Prabhakar wrote:
> From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
>
> this patch fixes following sparse warning:
>
> via_clock.c:33:12: warning: symbol 'via_slap' was not declared. Should it be static?
>
> Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
> ---
> Found this issue on linux-next (gcc version 4.9.2,
> sparse version 0.4.5-rc1)and applies on top linux-next.
>
> drivers/video/fbdev/via/via_clock.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/via/via_clock.c b/drivers/video/fbdev/via/via_clock.c
> index db1e392..bf269fa 100644
> --- a/drivers/video/fbdev/via/via_clock.c
> +++ b/drivers/video/fbdev/via/via_clock.c
> @@ -30,7 +30,7 @@
> #include "global.h"
> #include "debug.h"
>
> -const char *via_slap = "Please slap VIA Technologies to motivate them "
> +static const char *via_slap = "Please slap VIA Technologies to motivate them "
> "releasing full documentation for your platform!\n";
>
> static inline u32 cle266_encode_pll(struct via_pll_config pll)
>
Thanks, queued for 3.21.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] video: fbdev: use msecs_to_jiffies for time conversion
From: Tomi Valkeinen @ 2015-02-20 12:24 UTC (permalink / raw)
To: Nicholas Mc Guire, Jean-Christophe Plagniol-Villard
Cc: Jingoo Han, Daniel Vetter, Fabian Frederick, Laurent Pinchart,
Wolfram Sang, linux-fbdev, linux-kernel
In-Reply-To: <1423214041-15818-1-git-send-email-hofrat@osadl.org>
[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]
On 06/02/15 11:14, Nicholas Mc Guire wrote:
> This is only an API consolidation and should make things more readable
> it replaces var * HZ / 1000 by msecs_to_jiffies(var).
>
> Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
> ---
>
> Patch was only compile tested with viper_defconfig (implies CONFIG_FB_PXA=m)
>
> Patch is against 3.19.0-rc7 (localversion-next is -next-20150204)
>
> drivers/video/fbdev/pxafb.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/pxafb.c b/drivers/video/fbdev/pxafb.c
> index da2431e..d8b4743 100644
> --- a/drivers/video/fbdev/pxafb.c
> +++ b/drivers/video/fbdev/pxafb.c
> @@ -1285,7 +1285,7 @@ static int pxafb_smart_thread(void *arg)
> mutex_unlock(&fbi->ctrlr_lock);
>
> set_current_state(TASK_INTERRUPTIBLE);
> - schedule_timeout(30 * HZ / 1000);
> + schedule_timeout(msecs_to_jiffies(30));
> }
>
> pr_debug("%s(): task ending\n", __func__);
> @@ -1460,7 +1460,7 @@ static void pxafb_disable_controller(struct pxafb_info *fbi)
> #ifdef CONFIG_FB_PXA_SMARTPANEL
> if (fbi->lccr0 & LCCR0_LCDT) {
> wait_for_completion_timeout(&fbi->refresh_done,
> - 200 * HZ / 1000);
> + msecs_to_jiffies(200);
That will not compile.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] video: fbdev: make of_device_id array const
From: Tomi Valkeinen @ 2015-02-20 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1423479747-17899-1-git-send-email-sanjeev_sharma@mentor.com>
[-- Attachment #1: Type: text/plain, Size: 798 bytes --]
On 09/02/15 13:02, Sanjeev Sharma wrote:
> Make of_device_id array const.
>
> Signed-off-by: Sanjeev Sharma <Sanjeev_Sharma@mentor.com>
> ---
> drivers/video/fbdev/imxfb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/imxfb.c b/drivers/video/fbdev/imxfb.c
> index 3b6a3c8..84d1d29 100644
> --- a/drivers/video/fbdev/imxfb.c
> +++ b/drivers/video/fbdev/imxfb.c
> @@ -183,7 +183,7 @@ static struct platform_device_id imxfb_devtype[] = {
> };
> MODULE_DEVICE_TABLE(platform, imxfb_devtype);
>
> -static struct of_device_id imxfb_of_dev_id[] = {
> +static const struct of_device_id imxfb_of_dev_id[] = {
> {
> .compatible = "fsl,imx1-fb",
> .data = &imxfb_devtype[IMX1_FB],
>
Thanks, queued for 3.21.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] video: fbdev: fix possible null dereference
From: Tomi Valkeinen @ 2015-02-20 12:13 UTC (permalink / raw)
To: Sudip Mukherjee, Jean-Christophe Plagniol-Villard
Cc: linux-fbdev, linux-kernel
In-Reply-To: <1423756056-15108-1-git-send-email-sudipm.mukherjee@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]
On 12/02/15 17:47, Sudip Mukherjee wrote:
> we were dereferencing edid first and the NULL check was after
> accessing that. now we are using edid only if we know that
> it is not NULL.
>
> Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
> ---
> drivers/video/fbdev/core/fbmon.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbmon.c b/drivers/video/fbdev/core/fbmon.c
> index 9533859..868facd 100644
> --- a/drivers/video/fbdev/core/fbmon.c
> +++ b/drivers/video/fbdev/core/fbmon.c
> @@ -624,9 +624,6 @@ static struct fb_videomode *fb_create_modedb(unsigned char *edid, int *dbsize,
> int num = 0, i, first = 1;
> int ver, rev;
>
> - ver = edid[EDID_STRUCT_VERSION];
> - rev = edid[EDID_STRUCT_REVISION];
> -
> mode = kzalloc(50 * sizeof(struct fb_videomode), GFP_KERNEL);
> if (mode == NULL)
> return NULL;
> @@ -637,6 +634,9 @@ static struct fb_videomode *fb_create_modedb(unsigned char *edid, int *dbsize,
> return NULL;
> }
>
> + ver = edid[EDID_STRUCT_VERSION];
> + rev = edid[EDID_STRUCT_REVISION];
> +
> *dbsize = 0;
>
> DPRINTK(" Detailed Timings\n");
>
Thanks, queued for 3.20.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] video: ARM CLCD: Add missing error check for devm_kzalloc
From: Tomi Valkeinen @ 2015-02-20 12:12 UTC (permalink / raw)
To: Kiran Padwal
Cc: Russell King, Jean-Christophe Plagniol-Villard, linux-fbdev,
linux-kernel, Kiran Padwal
In-Reply-To: <1423647406-858-1-git-send-email-kiran.padwal@smartplayin.com>
[-- Attachment #1: Type: text/plain, Size: 909 bytes --]
On 11/02/15 11:36, Kiran Padwal wrote:
> This patch add a missing check on the return value of devm_kzalloc,
> which would cause a NULL pointer dereference in a OOM situation.
>
> Signed-off-by: Kiran Padwal <kiran.padwal@smartplayin.com>
> ---
> drivers/video/fbdev/amba-clcd.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/video/fbdev/amba-clcd.c b/drivers/video/fbdev/amba-clcd.c
> index 32c0b6b..9362424 100644
> --- a/drivers/video/fbdev/amba-clcd.c
> +++ b/drivers/video/fbdev/amba-clcd.c
> @@ -599,6 +599,9 @@ static int clcdfb_of_get_mode(struct device *dev, struct device_node *endpoint,
>
> len = clcdfb_snprintf_mode(NULL, 0, mode);
> name = devm_kzalloc(dev, len + 1, GFP_KERNEL);
> + if (!name)
> + return -ENOMEM;
> +
> clcdfb_snprintf_mode(name, len + 1, mode);
> mode->name = name;
>
>
Thanks, queued for 3.20.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: sm501fb: use memset_io
From: Tomi Valkeinen @ 2015-02-20 12:10 UTC (permalink / raw)
To: Sudip Mukherjee, Jean-Christophe Plagniol-Villard
Cc: linux-fbdev, linux-kernel
In-Reply-To: <1423571852-14511-1-git-send-email-sudipm.mukherjee@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]
On 10/02/15 14:37, Sudip Mukherjee wrote:
> we should really be using memset_io() instead of using memset() as
> this is actually io space mapped into our memory.
>
> Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
> ---
> it has only been build tested. I only have the hardware of sm712 and sm750.
>
> drivers/video/fbdev/sm501fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/sm501fb.c b/drivers/video/fbdev/sm501fb.c
> index e8d4121..d0a4e2f 100644
> --- a/drivers/video/fbdev/sm501fb.c
> +++ b/drivers/video/fbdev/sm501fb.c
> @@ -1606,7 +1606,7 @@ static int sm501fb_start(struct sm501fb_info *info,
> info->fbmem_len = resource_size(res);
>
> /* clear framebuffer memory - avoids garbage data on unused fb */
> - memset(info->fbmem, 0, info->fbmem_len);
> + memset_io(info->fbmem, 0, info->fbmem_len);
>
> /* clear palette ram - undefined at power on */
> for (k = 0; k < (256 * 3); k++)
>
Thanks, queued for 3.21.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v6 2/2] fbcon: expose cursor blink interval via sysfs
From: Tomi Valkeinen @ 2015-02-20 12:04 UTC (permalink / raw)
To: Scot Doyle, Jean-Christophe Plagniol-Villard
Cc: Geert Uytterhoeven, Richard Weinberger, linux-fbdev, linux-kernel
In-Reply-To: <alpine.DEB.2.11.1501300938070.2359@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]
On 30/01/15 11:40, Scot Doyle wrote:
> fbcon toggles cursor display state every 200 milliseconds when blinking.
> Since users prefer different toggle intervals, expose the interval via
> /sys/class/graphics/fbcon/cursor_blink_ms so that it may be customized.
>
> Values written to the interface set the approximate time interval in
> milliseconds between cursor toggles, from 1 to 32767. Since the interval
> is stored internally as a number of jiffies, the millisecond value read
> from the interface may not exactly match the entered value.
>
> An outstanding blink timer is reset after a new value is entered.
>
> If the cursor blink is disabled, either via the 'cursor_blink' boolean
> setting or some other mechanism, the 'cursor_blink_ms' setting may still
> be modified. The new value will be used if the blink is reactivated.
>
> Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
> ---
> drivers/video/console/fbcon.c | 65 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 65 insertions(+)
>
> diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
> index 7a2030b..7baa333 100644
> --- a/drivers/video/console/fbcon.c
> +++ b/drivers/video/console/fbcon.c
> @@ -3495,11 +3495,76 @@ err:
> return count;
> }
>
> +static ssize_t show_cursor_blink_ms(struct device *device,
> + struct device_attribute *attr, char *buf)
> +{
> + struct fbcon_ops *ops;
> + int idx, ms = -1;
> +
> + if (fbcon_has_exited)
> + return -ENODEV;
> +
> + console_lock();
> + idx = con2fb_map[fg_console];
> +
> + if (idx != -1 && registered_fb[idx] != NULL) {
> + ops = ((struct fb_info *)registered_fb[idx])->fbcon_par;
I don't think the above typecast is needed. I can remove the typecast
when applying to my tree.
So queuing for 3.21. Thanks!
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] Printk() is replaced with pr_* respective functions in efifb.c
From: Parmeshwr Prasad @ 2015-02-18 9:51 UTC (permalink / raw)
To: Joe Perches
Cc: pjones@redhat.com, plagnioj@jcrosoft.com,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-efi
In-Reply-To: <1424249497.25416.23.camel@perches.com>
Thanks Joe for your suggestion.
I have changes patch as you said.
Signed-off-by: Parmeshwr Prasad <parmeshwr_prasad@dell.com>
---
drivers/video/fbdev/efifb.c | 26 ++++++++++++++------------
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 4bfff34..7557991 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -6,6 +6,8 @@
*
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
@@ -142,10 +144,10 @@ static int efifb_probe(struct platform_device *dev)
if (!screen_info.pages)
screen_info.pages = 1;
if (!screen_info.lfb_base) {
- printk(KERN_DEBUG "efifb: invalid framebuffer address\n");
+ pr_debug("invalid framebuffer address\n");
return -ENODEV;
}
- printk(KERN_INFO "efifb: probing for efifb\n");
+ pr_info("probing for efifb\n");
/* just assume they're all unset if any are */
if (!screen_info.blue_size) {
@@ -193,14 +195,14 @@ static int efifb_probe(struct platform_device *dev)
} else {
/* We cannot make this fatal. Sometimes this comes from magic
spaces our resource handlers simply don't know about */
- printk(KERN_WARNING
- "efifb: cannot reserve video memory at 0x%lx\n",
+ pr_warn(
+ "cannot reserve video memory at 0x%lx\n",
efifb_fix.smem_start);
}
info = framebuffer_alloc(sizeof(u32) * 16, &dev->dev);
if (!info) {
- printk(KERN_ERR "efifb: cannot allocate framebuffer\n");
+ pr_err("cannot allocate framebuffer\n");
err = -ENOMEM;
goto err_release_mem;
}
@@ -218,18 +220,18 @@ static int efifb_probe(struct platform_device *dev)
info->screen_base = ioremap_wc(efifb_fix.smem_start,
efifb_fix.smem_len);
if (!info->screen_base) {
- printk(KERN_ERR "efifb: abort, cannot ioremap video memory "
+ pr_err("abort, cannot ioremap video memory "
"0x%x @ 0x%lx\n",
efifb_fix.smem_len, efifb_fix.smem_start);
err = -EIO;
goto err_release_fb;
}
- printk(KERN_INFO "efifb: framebuffer at 0x%lx, mapped to 0x%p, "
+ pr_info("framebuffer at 0x%lx, mapped to 0x%p, "
"using %dk, total %dk\n",
efifb_fix.smem_start, info->screen_base,
size_remap/1024, size_total/1024);
- printk(KERN_INFO "efifb: mode is %dx%dx%d, linelength=%d, pages=%d\n",
+ pr_info("mode is %dx%dx%d, linelength=%d, pages=%d\n",
efifb_defined.xres, efifb_defined.yres,
efifb_defined.bits_per_pixel, efifb_fix.line_length,
screen_info.pages);
@@ -237,7 +239,7 @@ static int efifb_probe(struct platform_device *dev)
efifb_defined.xres_virtual = efifb_defined.xres;
efifb_defined.yres_virtual = efifb_fix.smem_len /
efifb_fix.line_length;
- printk(KERN_INFO "efifb: scrolling: redraw\n");
+ pr_info("scrolling: redraw\n");
efifb_defined.yres_virtual = efifb_defined.yres;
/* some dummy values for timing to make fbset happy */
@@ -255,7 +257,7 @@ static int efifb_probe(struct platform_device *dev)
efifb_defined.transp.offset = screen_info.rsvd_pos;
efifb_defined.transp.length = screen_info.rsvd_size;
- printk(KERN_INFO "efifb: %s: "
+ pr_info("%s: "
"size=%d:%d:%d:%d, shift=%d:%d:%d:%d\n",
"Truecolor",
screen_info.rsvd_size,
@@ -276,11 +278,11 @@ static int efifb_probe(struct platform_device *dev)
info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE;
if ((err = fb_alloc_cmap(&info->cmap, 256, 0)) < 0) {
- printk(KERN_ERR "efifb: cannot allocate colormap\n");
+ pr_err("cannot allocate colormap\n");
goto err_unmap;
}
if ((err = register_framebuffer(info)) < 0) {
- printk(KERN_ERR "efifb: cannot register framebuffer\n");
+ pr_err("cannot register framebuffer\n");
goto err_fb_dealoc;
}
fb_info(info, "%s frame buffer device\n", info->fix.id);
--
1.9.3
-Parmeshwr
On Wed, Feb 18, 2015 at 02:51:37AM -0600, Joe Perches wrote:
> On Wed, 2015-02-18 at 03:29 -0500, Parmeshwr Prasad wrote:
> > This is a trivial patch:
> >
> > I have replaced printk() with respective pr_* functions.
>
> Hi.
>
> A few suggestions:
>
> o Add this #define before any include
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> o Strip the embedded "efifb: " prefixes from the formats
> o Coalesce the formats
> o Don't change KERN_<LEVEL> uses unnecessarily
> If you do change logging levels, state why in the change log
> o Align the multiline arguments
>
> > diff --git a/drivers/video/fbdev/efifb.c b/diriveom rrs/video/fbdev/efifb.c
> []
> > @@ -142,10 +142,10 @@ static int efifb_probe(struct platform_device *dev)
> > if (!screen_info.pages)
> > screen_info.pages = 1;
> > if (!screen_info.lfb_base) {
> > - printk(KERN_DEBUG "efifb: invalid framebuffer address\n");
> > + pr_err("efifb: invalid framebuffer address\n");
>
> Strip the "efifb: " prefix from all the pr_<level> uses
>
> pr_err("invalid framebuffer address\n");
>
> > @@ -193,14 +193,14 @@ static int efifb_probe(struct platform_device *dev)
> > } else {
> > /* We cannot make this fatal. Sometimes this comes from magic
> > spaces our resource handlers simply don't know about */
> > - printk(KERN_WARNING
> > + pr_warn(
> > "efifb: cannot reserve video memory at 0x%lx\n",
> > efifb_fix.smem_start);
>
> Move the format to the same line as pr_warn
>
> pr_warn("cannot reserve video memory at 0x%lx\n",
>
> > @@ -218,18 +218,18 @@ static int efifb_probe(struct platform_device *dev)
> >
> > info->screen_base = ioremap_wc(efifb_fix.smem_start, efifb_fix.smem_len);
> > if (!info->screen_base) {
> > - printk(KERN_ERR "efifb: abort, cannot ioremap video memory "
> > + pr_err("efifb: abort, cannot ioremap video memory "
> > "0x%x @ 0x%lx\n",
> > efifb_fix.smem_len, efifb_fix.smem_start);
>
> Coalesce the format and align the arguments
>
> pr_err("abort, cannot ioremap video memory 0x%x @ 0x%lx\n"
> efifb_fix.smem_len, efifb_fix.smem_start);
>
> You should end up with something like:
>
> ---
> drivers/video/fbdev/efifb.c | 57 +++++++++++++++++++++------------------------
> 1 file changed, 27 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> index 4bfff34..2769bc9 100644
> --- a/drivers/video/fbdev/efifb.c
> +++ b/drivers/video/fbdev/efifb.c
> @@ -6,6 +6,8 @@
> *
> */
>
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> #include <linux/module.h>
> #include <linux/kernel.h>
> #include <linux/errno.h>
> @@ -142,10 +144,10 @@ static int efifb_probe(struct platform_device *dev)
> if (!screen_info.pages)
> screen_info.pages = 1;
> if (!screen_info.lfb_base) {
> - printk(KERN_DEBUG "efifb: invalid framebuffer address\n");
> + pr_debug("invalid framebuffer address\n");
> return -ENODEV;
> }
> - printk(KERN_INFO "efifb: probing for efifb\n");
> + pr_info("probing for efifb\n");
>
> /* just assume they're all unset if any are */
> if (!screen_info.blue_size) {
> @@ -193,14 +195,13 @@ static int efifb_probe(struct platform_device *dev)
> } else {
> /* We cannot make this fatal. Sometimes this comes from magic
> spaces our resource handlers simply don't know about */
> - printk(KERN_WARNING
> - "efifb: cannot reserve video memory at 0x%lx\n",
> + pr_warn("cannot reserve video memory at 0x%lx\n",
> efifb_fix.smem_start);
> }
>
> info = framebuffer_alloc(sizeof(u32) * 16, &dev->dev);
> if (!info) {
> - printk(KERN_ERR "efifb: cannot allocate framebuffer\n");
> + pr_err("cannot allocate framebuffer\n");
> err = -ENOMEM;
> goto err_release_mem;
> }
> @@ -218,26 +219,24 @@ static int efifb_probe(struct platform_device *dev)
>
> info->screen_base = ioremap_wc(efifb_fix.smem_start, efifb_fix.smem_len);
> if (!info->screen_base) {
> - printk(KERN_ERR "efifb: abort, cannot ioremap video memory "
> - "0x%x @ 0x%lx\n",
> - efifb_fix.smem_len, efifb_fix.smem_start);
> + pr_err("abort, cannot ioremap video memory 0x%x @ 0x%lx\n",
> + efifb_fix.smem_len, efifb_fix.smem_start);
> err = -EIO;
> goto err_release_fb;
> }
>
> - printk(KERN_INFO "efifb: framebuffer at 0x%lx, mapped to 0x%p, "
> - "using %dk, total %dk\n",
> - efifb_fix.smem_start, info->screen_base,
> - size_remap/1024, size_total/1024);
> - printk(KERN_INFO "efifb: mode is %dx%dx%d, linelength=%d, pages=%d\n",
> - efifb_defined.xres, efifb_defined.yres,
> - efifb_defined.bits_per_pixel, efifb_fix.line_length,
> - screen_info.pages);
> + pr_info("framebuffer at 0x%lx, mapped to 0x%p, using %dk, total %dk\n",
> + efifb_fix.smem_start, info->screen_base,
> + size_remap / 1024, size_total / 1024);
> + pr_info("mode is %dx%dx%d, linelength=%d, pages=%d\n",
> + efifb_defined.xres, efifb_defined.yres,
> + efifb_defined.bits_per_pixel, efifb_fix.line_length,
> + screen_info.pages);
>
> efifb_defined.xres_virtual = efifb_defined.xres;
> efifb_defined.yres_virtual = efifb_fix.smem_len /
> efifb_fix.line_length;
> - printk(KERN_INFO "efifb: scrolling: redraw\n");
> + pr_info("scrolling: redraw\n");
> efifb_defined.yres_virtual = efifb_defined.yres;
>
> /* some dummy values for timing to make fbset happy */
> @@ -255,17 +254,15 @@ static int efifb_probe(struct platform_device *dev)
> efifb_defined.transp.offset = screen_info.rsvd_pos;
> efifb_defined.transp.length = screen_info.rsvd_size;
>
> - printk(KERN_INFO "efifb: %s: "
> - "size=%d:%d:%d:%d, shift=%d:%d:%d:%d\n",
> - "Truecolor",
> - screen_info.rsvd_size,
> - screen_info.red_size,
> - screen_info.green_size,
> - screen_info.blue_size,
> - screen_info.rsvd_pos,
> - screen_info.red_pos,
> - screen_info.green_pos,
> - screen_info.blue_pos);
> + pr_info("Truecolor: size=%d:%d:%d:%d, shift=%d:%d:%d:%d\n",
> + screen_info.rsvd_size,
> + screen_info.red_size,
> + screen_info.green_size,
> + screen_info.blue_size,
> + screen_info.rsvd_pos,
> + screen_info.red_pos,
> + screen_info.green_pos,
> + screen_info.blue_pos);
>
> efifb_fix.ypanstep = 0;
> efifb_fix.ywrapstep = 0;
> @@ -276,11 +273,11 @@ static int efifb_probe(struct platform_device *dev)
> info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE;
>
> if ((err = fb_alloc_cmap(&info->cmap, 256, 0)) < 0) {
> - printk(KERN_ERR "efifb: cannot allocate colormap\n");
> + pr_err("cannot allocate colormap\n");
> goto err_unmap;
> }
> if ((err = register_framebuffer(info)) < 0) {
> - printk(KERN_ERR "efifb: cannot register framebuffer\n");
> + pr_err("cannot register framebuffer\n");
> goto err_fb_dealoc;
> }
> fb_info(info, "%s frame buffer device\n", info->fix.id);
>
>
^ permalink raw reply related
* Re: [PATCH 1/3] Printk() is replaced with pr_* respective functions in efifb.c
From: Joe Perches @ 2015-02-18 8:51 UTC (permalink / raw)
To: Parmeshwr Prasad; +Cc: pjones, plagnioj, linux-fbdev, linux-kernel
In-Reply-To: <20150218082942.GB9820@linuxteamdev.amer.dell.com>
On Wed, 2015-02-18 at 03:29 -0500, Parmeshwr Prasad wrote:
> This is a trivial patch:
>
> I have replaced printk() with respective pr_* functions.
Hi.
A few suggestions:
o Add this #define before any include
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
o Strip the embedded "efifb: " prefixes from the formats
o Coalesce the formats
o Don't change KERN_<LEVEL> uses unnecessarily
If you do change logging levels, state why in the change log
o Align the multiline arguments
> diff --git a/drivers/video/fbdev/efifb.c b/diriveom rrs/video/fbdev/efifb.c
[]
> @@ -142,10 +142,10 @@ static int efifb_probe(struct platform_device *dev)
> if (!screen_info.pages)
> screen_info.pages = 1;
> if (!screen_info.lfb_base) {
> - printk(KERN_DEBUG "efifb: invalid framebuffer address\n");
> + pr_err("efifb: invalid framebuffer address\n");
Strip the "efifb: " prefix from all the pr_<level> uses
pr_err("invalid framebuffer address\n");
> @@ -193,14 +193,14 @@ static int efifb_probe(struct platform_device *dev)
> } else {
> /* We cannot make this fatal. Sometimes this comes from magic
> spaces our resource handlers simply don't know about */
> - printk(KERN_WARNING
> + pr_warn(
> "efifb: cannot reserve video memory at 0x%lx\n",
> efifb_fix.smem_start);
Move the format to the same line as pr_warn
pr_warn("cannot reserve video memory at 0x%lx\n",
> @@ -218,18 +218,18 @@ static int efifb_probe(struct platform_device *dev)
>
> info->screen_base = ioremap_wc(efifb_fix.smem_start, efifb_fix.smem_len);
> if (!info->screen_base) {
> - printk(KERN_ERR "efifb: abort, cannot ioremap video memory "
> + pr_err("efifb: abort, cannot ioremap video memory "
> "0x%x @ 0x%lx\n",
> efifb_fix.smem_len, efifb_fix.smem_start);
Coalesce the format and align the arguments
pr_err("abort, cannot ioremap video memory 0x%x @ 0x%lx\n"
efifb_fix.smem_len, efifb_fix.smem_start);
You should end up with something like:
---
drivers/video/fbdev/efifb.c | 57 +++++++++++++++++++++------------------------
1 file changed, 27 insertions(+), 30 deletions(-)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 4bfff34..2769bc9 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -6,6 +6,8 @@
*
*/
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/errno.h>
@@ -142,10 +144,10 @@ static int efifb_probe(struct platform_device *dev)
if (!screen_info.pages)
screen_info.pages = 1;
if (!screen_info.lfb_base) {
- printk(KERN_DEBUG "efifb: invalid framebuffer address\n");
+ pr_debug("invalid framebuffer address\n");
return -ENODEV;
}
- printk(KERN_INFO "efifb: probing for efifb\n");
+ pr_info("probing for efifb\n");
/* just assume they're all unset if any are */
if (!screen_info.blue_size) {
@@ -193,14 +195,13 @@ static int efifb_probe(struct platform_device *dev)
} else {
/* We cannot make this fatal. Sometimes this comes from magic
spaces our resource handlers simply don't know about */
- printk(KERN_WARNING
- "efifb: cannot reserve video memory at 0x%lx\n",
+ pr_warn("cannot reserve video memory at 0x%lx\n",
efifb_fix.smem_start);
}
info = framebuffer_alloc(sizeof(u32) * 16, &dev->dev);
if (!info) {
- printk(KERN_ERR "efifb: cannot allocate framebuffer\n");
+ pr_err("cannot allocate framebuffer\n");
err = -ENOMEM;
goto err_release_mem;
}
@@ -218,26 +219,24 @@ static int efifb_probe(struct platform_device *dev)
info->screen_base = ioremap_wc(efifb_fix.smem_start, efifb_fix.smem_len);
if (!info->screen_base) {
- printk(KERN_ERR "efifb: abort, cannot ioremap video memory "
- "0x%x @ 0x%lx\n",
- efifb_fix.smem_len, efifb_fix.smem_start);
+ pr_err("abort, cannot ioremap video memory 0x%x @ 0x%lx\n",
+ efifb_fix.smem_len, efifb_fix.smem_start);
err = -EIO;
goto err_release_fb;
}
- printk(KERN_INFO "efifb: framebuffer at 0x%lx, mapped to 0x%p, "
- "using %dk, total %dk\n",
- efifb_fix.smem_start, info->screen_base,
- size_remap/1024, size_total/1024);
- printk(KERN_INFO "efifb: mode is %dx%dx%d, linelength=%d, pages=%d\n",
- efifb_defined.xres, efifb_defined.yres,
- efifb_defined.bits_per_pixel, efifb_fix.line_length,
- screen_info.pages);
+ pr_info("framebuffer at 0x%lx, mapped to 0x%p, using %dk, total %dk\n",
+ efifb_fix.smem_start, info->screen_base,
+ size_remap / 1024, size_total / 1024);
+ pr_info("mode is %dx%dx%d, linelength=%d, pages=%d\n",
+ efifb_defined.xres, efifb_defined.yres,
+ efifb_defined.bits_per_pixel, efifb_fix.line_length,
+ screen_info.pages);
efifb_defined.xres_virtual = efifb_defined.xres;
efifb_defined.yres_virtual = efifb_fix.smem_len /
efifb_fix.line_length;
- printk(KERN_INFO "efifb: scrolling: redraw\n");
+ pr_info("scrolling: redraw\n");
efifb_defined.yres_virtual = efifb_defined.yres;
/* some dummy values for timing to make fbset happy */
@@ -255,17 +254,15 @@ static int efifb_probe(struct platform_device *dev)
efifb_defined.transp.offset = screen_info.rsvd_pos;
efifb_defined.transp.length = screen_info.rsvd_size;
- printk(KERN_INFO "efifb: %s: "
- "size=%d:%d:%d:%d, shift=%d:%d:%d:%d\n",
- "Truecolor",
- screen_info.rsvd_size,
- screen_info.red_size,
- screen_info.green_size,
- screen_info.blue_size,
- screen_info.rsvd_pos,
- screen_info.red_pos,
- screen_info.green_pos,
- screen_info.blue_pos);
+ pr_info("Truecolor: size=%d:%d:%d:%d, shift=%d:%d:%d:%d\n",
+ screen_info.rsvd_size,
+ screen_info.red_size,
+ screen_info.green_size,
+ screen_info.blue_size,
+ screen_info.rsvd_pos,
+ screen_info.red_pos,
+ screen_info.green_pos,
+ screen_info.blue_pos);
efifb_fix.ypanstep = 0;
efifb_fix.ywrapstep = 0;
@@ -276,11 +273,11 @@ static int efifb_probe(struct platform_device *dev)
info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE;
if ((err = fb_alloc_cmap(&info->cmap, 256, 0)) < 0) {
- printk(KERN_ERR "efifb: cannot allocate colormap\n");
+ pr_err("cannot allocate colormap\n");
goto err_unmap;
}
if ((err = register_framebuffer(info)) < 0) {
- printk(KERN_ERR "efifb: cannot register framebuffer\n");
+ pr_err("cannot register framebuffer\n");
goto err_fb_dealoc;
}
fb_info(info, "%s frame buffer device\n", info->fix.id);
^ permalink raw reply related
* [PATCH 3/3] Moved assignment out of if() statement in efifb.c
From: Parmeshwr Prasad @ 2015-02-18 8:36 UTC (permalink / raw)
To: pjones, plagnioj, tomi.valkeinen; +Cc: linux-fbdev, linux-kernel
This patch depend on my earlier patchs.
Moving assignment out of if() statement.
Signed-off-by: Parmeshwr Prasad <parmeshwr_prasad@dell.com>
---
drivers/video/fbdev/efifb.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index cc1a156..9124ba9 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -275,11 +275,13 @@ static int efifb_probe(struct platform_device *dev)
info->fix = efifb_fix;
info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE;
- if ((err = fb_alloc_cmap(&info->cmap, 256, 0)) < 0) {
+ err = fb_alloc_cmap(&info->cmap, 256, 0);
+ if (err < 0) {
pr_err("efifb: cannot allocate colormap\n");
goto err_unmap;
}
- if ((err = register_framebuffer(info)) < 0) {
+ err = register_framebuffer(info);
+ if (err < 0) {
pr_err("efifb: cannot register framebuffer\n");
goto err_fb_dealoc;
}
--
1.9.3
-Parmeshwr
^ permalink raw reply related
* [PATCH 2/3] Static should not be initialize so removing static initialization from efifb.c
From: Parmeshwr Prasad @ 2015-02-18 8:33 UTC (permalink / raw)
To: pjones, plagnioj, tomi.valkeinen; +Cc: linux-kernel, linux-fbdev
This patch depend on my earlier patch.
Static should not be initialize so removing initialization.
Signed-off-by: Parmeshwr Prasad <parmeshwr_prasad@dell.com>
---
drivers/video/fbdev/efifb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index facfbb3..cc1a156 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -17,7 +17,7 @@
#include <video/vga.h>
#include <asm/sysfb.h>
-static bool request_mem_succeeded = false;
+static bool request_mem_succeeded;
static struct fb_var_screeninfo efifb_defined = {
.activate = FB_ACTIVATE_NOW,
--
1.9.3
^ permalink raw reply related
* [PATCH 1/3] Printk() is replaced with pr_* respective functions in efifb.c
From: Parmeshwr Prasad @ 2015-02-18 8:29 UTC (permalink / raw)
To: pjones, plagnioj; +Cc: linux-fbdev, linux-kernel
This is a trivial patch:
I have replaced printk() with respective pr_* functions.
Signed-off-by: Parmeshwr Prasad <parmeshwr_prasad@dell.com>
---
drivers/video/fbdev/efifb.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 4bfff34..facfbb3 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -142,10 +142,10 @@ static int efifb_probe(struct platform_device *dev)
if (!screen_info.pages)
screen_info.pages = 1;
if (!screen_info.lfb_base) {
- printk(KERN_DEBUG "efifb: invalid framebuffer address\n");
+ pr_err("efifb: invalid framebuffer address\n");
return -ENODEV;
}
- printk(KERN_INFO "efifb: probing for efifb\n");
+ pr_info("efifb: probing for efifb\n");
/* just assume they're all unset if any are */
if (!screen_info.blue_size) {
@@ -193,14 +193,14 @@ static int efifb_probe(struct platform_device *dev)
} else {
/* We cannot make this fatal. Sometimes this comes from magic
spaces our resource handlers simply don't know about */
- printk(KERN_WARNING
+ pr_warn(
"efifb: cannot reserve video memory at 0x%lx\n",
efifb_fix.smem_start);
}
info = framebuffer_alloc(sizeof(u32) * 16, &dev->dev);
if (!info) {
- printk(KERN_ERR "efifb: cannot allocate framebuffer\n");
+ pr_err("efifb: cannot allocate framebuffer\n");
err = -ENOMEM;
goto err_release_mem;
}
@@ -218,18 +218,18 @@ static int efifb_probe(struct platform_device *dev)
info->screen_base = ioremap_wc(efifb_fix.smem_start,
efifb_fix.smem_len);
if (!info->screen_base) {
- printk(KERN_ERR "efifb: abort, cannot ioremap video memory "
+ pr_err("efifb: abort, cannot ioremap video memory "
"0x%x @ 0x%lx\n",
efifb_fix.smem_len, efifb_fix.smem_start);
err = -EIO;
goto err_release_fb;
}
- printk(KERN_INFO "efifb: framebuffer at 0x%lx, mapped to 0x%p, "
+ pr_info("efifb: framebuffer at 0x%lx, mapped to 0x%p, "
"using %dk, total %dk\n",
efifb_fix.smem_start, info->screen_base,
size_remap/1024, size_total/1024);
- printk(KERN_INFO "efifb: mode is %dx%dx%d, linelength=%d, pages=%d\n",
+ pr_info("efifb: mode is %dx%dx%d, linelength=%d, pages=%d\n",
efifb_defined.xres, efifb_defined.yres,
efifb_defined.bits_per_pixel, efifb_fix.line_length,
screen_info.pages);
@@ -237,7 +237,7 @@ static int efifb_probe(struct platform_device *dev)
efifb_defined.xres_virtual = efifb_defined.xres;
efifb_defined.yres_virtual = efifb_fix.smem_len /
efifb_fix.line_length;
- printk(KERN_INFO "efifb: scrolling: redraw\n");
+ pr_info("efifb: scrolling: redraw\n");
efifb_defined.yres_virtual = efifb_defined.yres;
/* some dummy values for timing to make fbset happy */
@@ -255,7 +255,7 @@ static int efifb_probe(struct platform_device *dev)
efifb_defined.transp.offset = screen_info.rsvd_pos;
efifb_defined.transp.length = screen_info.rsvd_size;
- printk(KERN_INFO "efifb: %s: "
+ pr_info("efifb: %s: "
"size=%d:%d:%d:%d, shift=%d:%d:%d:%d\n",
"Truecolor",
screen_info.rsvd_size,
@@ -276,11 +276,11 @@ static int efifb_probe(struct platform_device *dev)
info->flags = FBINFO_FLAG_DEFAULT | FBINFO_MISC_FIRMWARE;
if ((err = fb_alloc_cmap(&info->cmap, 256, 0)) < 0) {
- printk(KERN_ERR "efifb: cannot allocate colormap\n");
+ pr_err("efifb: cannot allocate colormap\n");
goto err_unmap;
}
if ((err = register_framebuffer(info)) < 0) {
- printk(KERN_ERR "efifb: cannot register framebuffer\n");
+ pr_err("efifb: cannot register framebuffer\n");
goto err_fb_dealoc;
}
fb_info(info, "%s frame buffer device\n", info->fix.id);
--
1.9.3
-Parmeshwr
^ permalink raw reply related
* [PATCH 5/5] gxt4500: enable panning
From: Ondrej Zary @ 2015-02-17 22:33 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-fbdev, Kernel development list
In-Reply-To: <1424212434-12614-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 f278c82..7f97c89 100644
--- a/drivers/video/fbdev/gxt4500.c
+++ b/drivers/video/fbdev/gxt4500.c
@@ -699,7 +699,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 (PAT and MTRR)
From: Ondrej Zary @ 2015-02-17 22:33 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-fbdev, Kernel development list
In-Reply-To: <1424212434-12614-1-git-send-email-linux@rainbow-software.org>
Use write-combining for framebuffer to greatly improve performance on x86.
Add both ioremap_wc (for systems with PAT) and MTRR setup for non-PAT systems.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
---
drivers/video/fbdev/gxt4500.c | 32 ++++++++++++++++++++++++++++++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/gxt4500.c b/drivers/video/fbdev/gxt4500.c
index 442b07c..f278c82 100644
--- a/drivers/video/fbdev/gxt4500.c
+++ b/drivers/video/fbdev/gxt4500.c
@@ -13,6 +13,9 @@
#include <linux/pci_ids.h>
#include <linux/delay.h>
#include <linux/string.h>
+#ifdef CONFIG_MTRR
+#include <asm/mtrr.h>
+#endif
#define PCI_DEVICE_ID_IBM_GXT4500P 0x21c
#define PCI_DEVICE_ID_IBM_GXT6500P 0x21b
@@ -142,7 +145,9 @@ static const unsigned char watfmt[] = {
struct gxt4500_par {
void __iomem *regs;
-
+#ifdef CONFIG_MTRR
+ int mtrr_reg;
+#endif
int pixfmt; /* pixel format, see DFA_PIX_* values */
/* PLL parameters */
@@ -158,6 +163,10 @@ struct gxt4500_par {
/* mode requested by user */
static char *mode_option;
+#ifdef CONFIG_MTRR
+static int mtrr = 1;
+#endif
+
/* default mode: 1280x1024 @ 60 Hz, 8 bpp */
static const struct fb_videomode defaultmode = {
.refresh = 60,
@@ -663,7 +672,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 +680,14 @@ static int gxt4500_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
pci_set_drvdata(pdev, info);
+#ifdef CONFIG_MTRR
+ if (mtrr) {
+ par->mtrr_reg = -1;
+ par->mtrr_reg = mtrr_add(info->fix.smem_start,
+ info->fix.smem_len, MTRR_TYPE_WRCOMB, 1);
+ }
+#endif
+
#ifdef __BIG_ENDIAN
/* Set byte-swapping for DFA aperture for all pixel sizes */
pci_write_config_dword(pdev, CFG_ENDIAN0, 0x333300);
@@ -735,6 +752,12 @@ static void gxt4500_remove(struct pci_dev *pdev)
return;
par = info->par;
unregister_framebuffer(info);
+#ifdef CONFIG_MTRR
+ if (par->mtrr_reg >= 0) {
+ mtrr_del(par->mtrr_reg, 0, 0);
+ par->mtrr_reg = -1;
+ }
+#endif
fb_dealloc_cmap(&info->cmap);
iounmap(par->regs);
iounmap(info->screen_base);
@@ -789,3 +812,8 @@ MODULE_DESCRIPTION("FBDev driver for IBM GXT4500P/6500P and GXT4000P/6000P");
MODULE_LICENSE("GPL");
module_param(mode_option, charp, 0);
MODULE_PARM_DESC(mode_option, "Specify resolution as \"<xres>x<yres>[-<bpp>][@<refresh>]\"");
+
+#ifdef CONFIG_MTRR
+module_param(mtrr, int, 0444);
+MODULE_PARM_DESC(mtrr, "Enable write-combining with MTRR (1=enable, 0=disable, default=1)");
+#endif
--
Ondrej Zary
^ permalink raw reply related
* [PATCH 3/5] gxt4500: fix color order
From: Ondrej Zary @ 2015-02-17 22:33 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-fbdev, Kernel development list
In-Reply-To: <1424212434-12614-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
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