* Re: possible typo in ancient radeon code
From: Geert Uytterhoeven @ 2015-03-19 12:52 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <20150319123021.GA12264@mwanda>
CC BenH
On Thu, Mar 19, 2015 at 1:30 PM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> Hello FB devs,
>
> This ancient code from 1da177e4c3f4: "Linux-2.6.12-rc2" from Apr 16,
> 2005, leads to the following static checker warning:
Nah, it's a little bit older (in full-history-linux ;-)
commit 9ff343f3d155aa35f79bae8607d7c4500d7ef848
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Thu Feb 10 16:03:30 2005 -0800
[PATCH] radeonfb update
>
> drivers/video/fbdev/aty/radeon_pm.c:417 radeon_pm_enable_dynamic_mode()
> warn: we tested 'tmp & (1 << 21)' before and it was 'true'
>
> include/video/radeon.h
> 1216 #define MCLK_CNTL__MRDCKA1_SOUTSEL_MASK 0x0c000000L
> 1217 #define MCLK_CNTL__MRDCKB0_SOUTSEL_MASK 0x30000000L
> 1218 #define MCLK_CNTL__MRDCKB1_SOUTSEL_MASK 0xc0000000L
> 1219 #define MCLK_CNTL__R300_DISABLE_MC_MCLKA (1 << 21)
> 1220 #define MCLK_CNTL__R300_DISABLE_MC_MCLKB (1 << 21)
>
> These are probably supposed to refer to different bits.
>
> 1221
> 1222 // MCLK_MISC
>
> drivers/video/fbdev/aty/radeon_pm.c
> 411 /* Some releases of vbios have set DISABLE_MC_MCLKA
> 412 * and DISABLE_MC_MCLKB bits in the vbios table. Setting these
> 413 * bits will cause H/W hang when reading video memory with dynamic
> 414 * clocking enabled.
> 415 */
> 416 if ((tmp & MCLK_CNTL__R300_DISABLE_MC_MCLKA) &&
> 417 (tmp & MCLK_CNTL__R300_DISABLE_MC_MCLKB)) {
>
> The duplicate check here causes a warning. I guess it probably doesn't
> matter if no one complains...
>
> 418 /* If both bits are set, then check the active channels */
> 419 tmp = INPLL(pllMCLK_CNTL);
> 420 if (rinfo->vram_width = 64) {
> 421 if (INREG(MEM_CNTL) & R300_MEM_USE_CD_CH_ONLY)
> 422 tmp &= ~MCLK_CNTL__R300_DISABLE_MC_MCLKB;
> 423 else
> 424 tmp &= ~MCLK_CNTL__R300_DISABLE_MC_MCLKA;
> 425 } else {
> 426 tmp &= ~(MCLK_CNTL__R300_DISABLE_MC_MCLKA |
> 427 MCLK_CNTL__R300_DISABLE_MC_MCLKB);
> 428 }
> 429 }
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* possible typo in ancient radeon code
From: Dan Carpenter @ 2015-03-19 12:30 UTC (permalink / raw)
To: linux-fbdev
Hello FB devs,
This ancient code from 1da177e4c3f4: "Linux-2.6.12-rc2" from Apr 16,
2005, leads to the following static checker warning:
drivers/video/fbdev/aty/radeon_pm.c:417 radeon_pm_enable_dynamic_mode()
warn: we tested 'tmp & (1 << 21)' before and it was 'true'
include/video/radeon.h
1216 #define MCLK_CNTL__MRDCKA1_SOUTSEL_MASK 0x0c000000L
1217 #define MCLK_CNTL__MRDCKB0_SOUTSEL_MASK 0x30000000L
1218 #define MCLK_CNTL__MRDCKB1_SOUTSEL_MASK 0xc0000000L
1219 #define MCLK_CNTL__R300_DISABLE_MC_MCLKA (1 << 21)
1220 #define MCLK_CNTL__R300_DISABLE_MC_MCLKB (1 << 21)
These are probably supposed to refer to different bits.
1221
1222 // MCLK_MISC
drivers/video/fbdev/aty/radeon_pm.c
411 /* Some releases of vbios have set DISABLE_MC_MCLKA
412 * and DISABLE_MC_MCLKB bits in the vbios table. Setting these
413 * bits will cause H/W hang when reading video memory with dynamic
414 * clocking enabled.
415 */
416 if ((tmp & MCLK_CNTL__R300_DISABLE_MC_MCLKA) &&
417 (tmp & MCLK_CNTL__R300_DISABLE_MC_MCLKB)) {
The duplicate check here causes a warning. I guess it probably doesn't
matter if no one complains...
418 /* If both bits are set, then check the active channels */
419 tmp = INPLL(pllMCLK_CNTL);
420 if (rinfo->vram_width = 64) {
421 if (INREG(MEM_CNTL) & R300_MEM_USE_CD_CH_ONLY)
422 tmp &= ~MCLK_CNTL__R300_DISABLE_MC_MCLKB;
423 else
424 tmp &= ~MCLK_CNTL__R300_DISABLE_MC_MCLKA;
425 } else {
426 tmp &= ~(MCLK_CNTL__R300_DISABLE_MC_MCLKA |
427 MCLK_CNTL__R300_DISABLE_MC_MCLKB);
428 }
429 }
regards,
dan carpenter
^ permalink raw reply
* [PATCH v3] video: mxsfb: Make sure axi clock is enabled when accessing registers
From: Liu Ying @ 2015-03-19 6:07 UTC (permalink / raw)
To: linux-fbdev
Cc: Peter Chen, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
Fabio Estevam, Greg Kroah-Hartman, linux-kernel, stable
The LCDIF engines embedded in i.MX6sl and i.MX6sx SoCs need the axi clock
as the engine's system clock. The clock should be enabled when accessing
LCDIF registers, otherwise the kernel would hang up. We should also keep
the clock enabled when the engine is being active to scan out frames from
memory. This patch makes sure the axi clock is enabled when accessing
registers so that the kernel hang up issue can be fixed.
Reported-by: Peter Chen <peter.chen@freescale.com>
Tested-by: Peter Chen <peter.chen@freescale.com>
Cc: <stable@vger.kernel.org> # 3.19+
Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
---
v2->v3:
* To address Tomi's comment, improve the commit message only.
v1->v2:
* Add 'Tested-by: Peter Chen <peter.chen@freescale.com>' tag.
* Add 'Cc: <stable@vger.kernel.org> # 3.19+' tag.
drivers/video/fbdev/mxsfb.c | 70 ++++++++++++++++++++++++++++++++++++---------
1 file changed, 56 insertions(+), 14 deletions(-)
diff --git a/drivers/video/fbdev/mxsfb.c b/drivers/video/fbdev/mxsfb.c
index f8ac4a4..a8cf3b2 100644
--- a/drivers/video/fbdev/mxsfb.c
+++ b/drivers/video/fbdev/mxsfb.c
@@ -316,6 +316,18 @@ static int mxsfb_check_var(struct fb_var_screeninfo *var,
return 0;
}
+static inline void mxsfb_enable_axi_clk(struct mxsfb_info *host)
+{
+ if (host->clk_axi)
+ clk_prepare_enable(host->clk_axi);
+}
+
+static inline void mxsfb_disable_axi_clk(struct mxsfb_info *host)
+{
+ if (host->clk_axi)
+ clk_disable_unprepare(host->clk_axi);
+}
+
static void mxsfb_enable_controller(struct fb_info *fb_info)
{
struct mxsfb_info *host = to_imxfb_host(fb_info);
@@ -333,14 +345,13 @@ static void mxsfb_enable_controller(struct fb_info *fb_info)
}
}
- if (host->clk_axi)
- clk_prepare_enable(host->clk_axi);
-
if (host->clk_disp_axi)
clk_prepare_enable(host->clk_disp_axi);
clk_prepare_enable(host->clk);
clk_set_rate(host->clk, PICOS2KHZ(fb_info->var.pixclock) * 1000U);
+ mxsfb_enable_axi_clk(host);
+
/* if it was disabled, re-enable the mode again */
writel(CTRL_DOTCLK_MODE, host->base + LCDC_CTRL + REG_SET);
@@ -380,11 +391,11 @@ static void mxsfb_disable_controller(struct fb_info *fb_info)
reg = readl(host->base + LCDC_VDCTRL4);
writel(reg & ~VDCTRL4_SYNC_SIGNALS_ON, host->base + LCDC_VDCTRL4);
+ mxsfb_disable_axi_clk(host);
+
clk_disable_unprepare(host->clk);
if (host->clk_disp_axi)
clk_disable_unprepare(host->clk_disp_axi);
- if (host->clk_axi)
- clk_disable_unprepare(host->clk_axi);
host->enabled = 0;
@@ -421,6 +432,8 @@ static int mxsfb_set_par(struct fb_info *fb_info)
mxsfb_disable_controller(fb_info);
}
+ mxsfb_enable_axi_clk(host);
+
/* clear the FIFOs */
writel(CTRL1_FIFO_CLEAR, host->base + LCDC_CTRL1 + REG_SET);
@@ -438,6 +451,7 @@ static int mxsfb_set_par(struct fb_info *fb_info)
ctrl |= CTRL_SET_WORD_LENGTH(3);
switch (host->ld_intf_width) {
case STMLCDIF_8BIT:
+ mxsfb_disable_axi_clk(host);
dev_err(&host->pdev->dev,
"Unsupported LCD bus width mapping\n");
return -EINVAL;
@@ -451,6 +465,7 @@ static int mxsfb_set_par(struct fb_info *fb_info)
writel(CTRL1_SET_BYTE_PACKAGING(0x7), host->base + LCDC_CTRL1);
break;
default:
+ mxsfb_disable_axi_clk(host);
dev_err(&host->pdev->dev, "Unhandled color depth of %u\n",
fb_info->var.bits_per_pixel);
return -EINVAL;
@@ -504,6 +519,8 @@ static int mxsfb_set_par(struct fb_info *fb_info)
fb_info->fix.line_length * fb_info->var.yoffset,
host->base + host->devdata->next_buf);
+ mxsfb_disable_axi_clk(host);
+
if (reenable)
mxsfb_enable_controller(fb_info);
@@ -582,10 +599,16 @@ static int mxsfb_pan_display(struct fb_var_screeninfo *var,
offset = fb_info->fix.line_length * var->yoffset;
+ if (!host->enabled)
+ mxsfb_enable_axi_clk(host);
+
/* update on next VSYNC */
writel(fb_info->fix.smem_start + offset,
host->base + host->devdata->next_buf);
+ if (!host->enabled)
+ mxsfb_disable_axi_clk(host);
+
return 0;
}
@@ -608,13 +631,17 @@ static int mxsfb_restore_mode(struct mxsfb_info *host,
unsigned line_count;
unsigned period;
unsigned long pa, fbsize;
- int bits_per_pixel, ofs;
+ int bits_per_pixel, ofs, ret = 0;
u32 transfer_count, vdctrl0, vdctrl2, vdctrl3, vdctrl4, ctrl;
+ mxsfb_enable_axi_clk(host);
+
/* Only restore the mode when the controller is running */
ctrl = readl(host->base + LCDC_CTRL);
- if (!(ctrl & CTRL_RUN))
- return -EINVAL;
+ if (!(ctrl & CTRL_RUN)) {
+ ret = -EINVAL;
+ goto err;
+ }
vdctrl0 = readl(host->base + LCDC_VDCTRL0);
vdctrl2 = readl(host->base + LCDC_VDCTRL2);
@@ -635,7 +662,8 @@ static int mxsfb_restore_mode(struct mxsfb_info *host,
break;
case 1:
default:
- return -EINVAL;
+ ret = -EINVAL;
+ goto err;
}
fb_info->var.bits_per_pixel = bits_per_pixel;
@@ -673,10 +701,14 @@ static int mxsfb_restore_mode(struct mxsfb_info *host,
pa = readl(host->base + host->devdata->cur_buf);
fbsize = fb_info->fix.line_length * vmode->yres;
- if (pa < fb_info->fix.smem_start)
- return -EINVAL;
- if (pa + fbsize > fb_info->fix.smem_start + fb_info->fix.smem_len)
- return -EINVAL;
+ if (pa < fb_info->fix.smem_start) {
+ ret = -EINVAL;
+ goto err;
+ }
+ if (pa + fbsize > fb_info->fix.smem_start + fb_info->fix.smem_len) {
+ ret = -EINVAL;
+ goto err;
+ }
ofs = pa - fb_info->fix.smem_start;
if (ofs) {
memmove(fb_info->screen_base, fb_info->screen_base + ofs, fbsize);
@@ -689,7 +721,11 @@ static int mxsfb_restore_mode(struct mxsfb_info *host,
clk_prepare_enable(host->clk);
host->enabled = 1;
- return 0;
+err:
+ if (ret)
+ mxsfb_disable_axi_clk(host);
+
+ return ret;
}
static int mxsfb_init_fbinfo_dt(struct mxsfb_info *host,
@@ -915,7 +951,9 @@ static int mxsfb_probe(struct platform_device *pdev)
}
if (!host->enabled) {
+ mxsfb_enable_axi_clk(host);
writel(0, host->base + LCDC_CTRL);
+ mxsfb_disable_axi_clk(host);
mxsfb_set_par(fb_info);
mxsfb_enable_controller(fb_info);
}
@@ -954,11 +992,15 @@ static void mxsfb_shutdown(struct platform_device *pdev)
struct fb_info *fb_info = platform_get_drvdata(pdev);
struct mxsfb_info *host = to_imxfb_host(fb_info);
+ mxsfb_enable_axi_clk(host);
+
/*
* Force stop the LCD controller as keeping it running during reboot
* might interfere with the BootROM's boot mode pads sampling.
*/
writel(CTRL_RUN, host->base + LCDC_CTRL + REG_CLR);
+
+ mxsfb_disable_axi_clk(host);
}
static struct platform_driver mxsfb_driver = {
--
2.1.0
^ permalink raw reply related
* Re: [PATCHv4 04/10] fbdev: ssd1307fb: Unify init code and obtain hw specific bits from DT
From: Maxime Ripard @ 2015-03-18 19:27 UTC (permalink / raw)
To: Thomas Niederprüm
Cc: plagnioj, tomi.valkeinen, kernel, shawn.guo, robh+dt, linux-fbdev,
linux-kernel
In-Reply-To: <1426525918-12745-5-git-send-email-niederp@physik.uni-kl.de>
[-- Attachment #1: Type: text/plain, Size: 15873 bytes --]
Hi Thomas,
On Mon, Mar 16, 2015 at 06:11:52PM +0100, Thomas Niederprüm wrote:
> The 130X controllers are very similar from the configuration point of view.
> The configuration registers for the SSD1305/6/7 are bit identical (except the
> the VHCOM register and the the default values for clock setup register). This
> patch unifies the init code of the controller and adds hardware specific
> properties to DT that are needed to correctly initialize the device.
>
> The SSD130X can be wired to the OLED panel in various ways. Even for the
> same controller this wiring can differ from one display module to another
> and can not be probed by software. The added DT properties reflect these
> hardware decisions of the display module manufacturer.
> The 'com-sequential', 'com-lrremap' and 'com-invdir' values define different
> possibilities for the COM signals pin configuration and readout direction
> of the video memory. The 'segment-no-remap' allows the inversion of the
> memory-to-pin mapping ultimately inverting the order of the controllers
> output pins. The 'prechargepX' values need to be adapted according the
> capacitance of the OLEDs pixel cells.
>
> So far these hardware specific bits are hard coded in the init code, making
> the driver usable only for one certain wiring of the controller. This patch
> makes the driver usable with all possible hardware setups, given a valid hw
> description in DT. If these values are not set in DT the default values,
> as they are set in the ssd1307 init code right now, are used. This implies
> that without the corresponding DT property "segment-no-remap" the segment
> remap of the ssd130X controller gets activated. Even though this is not the
> default behaviour according to the datasheet it maintains backward
> compatibility with older DTBs.
>
> Note that the SSD1306 does not seem to be using the configuration written to
> the registers at all. Therefore this patch does not try to maintain these
> values without changes in DT. For reference an example is added to the DT
> bindings documentation that reproduces the configuration that is set in the
> current init code.
>
> Signed-off-by: Thomas Niederprüm <niederp@physik.uni-kl.de>
This looks mostly fine, thanks for your effort on this.
> ---
> .../devicetree/bindings/video/ssd1307fb.txt | 21 +++
> drivers/video/fbdev/ssd1307fb.c | 195 ++++++++++++---------
> 2 files changed, 137 insertions(+), 79 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/ssd1307fb.txt b/Documentation/devicetree/bindings/video/ssd1307fb.txt
> index 7a12542..be27562 100644
> --- a/Documentation/devicetree/bindings/video/ssd1307fb.txt
> +++ b/Documentation/devicetree/bindings/video/ssd1307fb.txt
> @@ -15,6 +15,16 @@ Required properties:
>
> Optional properties:
> - reset-active-low: Is the reset gpio is active on physical low?
> + - solomon,segment-no-remap: Display needs normal (non-inverted) data column
> + to segment mapping
> + - solomon,com-sequential: Display uses sequential COM pin configuration
> + - solomon,com-lrremap: Display uses left-right COM pin remap
> + - solomon,com-invdir: Display uses inverted COM pin scan direction
> + - solomon,com-offset: Offset of the first COM pin wired to the panel
Documenting the offset unit would be fine.
> + - solomon,prechargep1: Length of deselect period (phase 1) in clock cycles.
> + - solomon,prechargep2: Length of precharge period (phase 2) in clock cycles.
> + This needs to be the higher, the higher the capacitance
> + of the OLED's pixels is
>
> [0]: Documentation/devicetree/bindings/pwm/pwm.txt
>
> @@ -26,3 +36,14 @@ ssd1307: oled@3c {
> reset-gpios = <&gpio2 7>;
> reset-active-low;
> };
> +
> +ssd1306: oled@3c {
> + compatible = "solomon,ssd1306fb-i2c";
> + reg = <0x3c>;
> + pwms = <&pwm 4 3000>;
> + reset-gpios = <&gpio2 7>;
> + reset-active-low;
> + solomon,com-lrremap;
> + solomon,com-invdir;
> + solomon,com-offset = <32>;
> +};
> diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
> index 8d34c56..9a66118 100644
> --- a/drivers/video/fbdev/ssd1307fb.c
> +++ b/drivers/video/fbdev/ssd1307fb.c
> @@ -16,6 +16,9 @@
> #include <linux/pwm.h>
> #include <linux/delay.h>
>
> +#define DEVID_SSD1306 6
> +#define DEVID_SSD1307 7
> +
> #define SSD1307FB_DATA 0x40
> #define SSD1307FB_COMMAND 0x80
>
> @@ -38,22 +41,38 @@
> #define SSD1307FB_SET_COM_PINS_CONFIG 0xda
> #define SSD1307FB_SET_VCOMH 0xdb
>
> +static u_int contrast = 128;
> +module_param(contrast, uint, S_IRUGO);
> +
Why is this patch adding a contrast parameter? You don't even mention
it in your commit log. This should be a separate patch.
> struct ssd1307fb_par;
>
> -struct ssd1307fb_ops {
> - int (*init)(struct ssd1307fb_par *);
> - int (*remove)(struct ssd1307fb_par *);
> +struct ssd1307fb_deviceinfo {
> + int device_id;
> + u32 default_vcomh;
> + u32 default_dclk_div;
> + u32 default_dclk_frq;
> };
>
> struct ssd1307fb_par {
> + u32 com_invdir;
> + u32 com_lrremap;
> + u32 com_offset;
> + u32 com_seq;
> + u32 contrast;
> + u32 dclk_div;
> + u32 dclk_frq;
> + struct ssd1307fb_deviceinfo *device_info;
> struct i2c_client *client;
> u32 height;
> struct fb_info *info;
> - struct ssd1307fb_ops *ops;
> u32 page_offset;
> + u32 prechargep1;
> + u32 prechargep2;
> struct pwm_device *pwm;
> u32 pwm_period;
> int reset;
> + u32 seg_remap;
> + u32 vcomh;
> u32 width;
> };
>
> @@ -254,69 +273,46 @@ static struct fb_deferred_io ssd1307fb_defio = {
> .deferred_io = ssd1307fb_deferred_io,
> };
>
> -static int ssd1307fb_ssd1307_init(struct ssd1307fb_par *par)
> +static int ssd1307fb_init(struct ssd1307fb_par *par)
> {
> int ret;
> + u32 precharge, dclk, com_invdir, compins;
>
> - par->pwm = pwm_get(&par->client->dev, NULL);
> - if (IS_ERR(par->pwm)) {
> - dev_err(&par->client->dev, "Could not get PWM from device tree!\n");
> - return PTR_ERR(par->pwm);
> - }
> -
> - par->pwm_period = pwm_get_period(par->pwm);
> - /* Enable the PWM */
> - pwm_config(par->pwm, par->pwm_period / 2, par->pwm_period);
> - pwm_enable(par->pwm);
> -
> - dev_dbg(&par->client->dev, "Using PWM%d with a %dns period.\n",
> - par->pwm->pwm, par->pwm_period);
> -
> - /* Map column 127 of the OLED to segment 0 */
> - ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SEG_REMAP_ON);
> - if (ret < 0)
> - return ret;
> -
> - /* Turn on the display */
> - ret = ssd1307fb_write_cmd(par->client, SSD1307FB_DISPLAY_ON);
> - if (ret < 0)
> - return ret;
> -
> - return 0;
> -}
> -
> -static int ssd1307fb_ssd1307_remove(struct ssd1307fb_par *par)
> -{
> - pwm_disable(par->pwm);
> - pwm_put(par->pwm);
> - return 0;
> -}
> + if (par->device_info->device_id == DEVID_SSD1307) {
> + par->pwm = pwm_get(&par->client->dev, NULL);
> + if (IS_ERR(par->pwm)) {
> + dev_err(&par->client->dev, "Could not get PWM from device tree!\n");
> + return PTR_ERR(par->pwm);
> + }
>
> -static struct ssd1307fb_ops ssd1307fb_ssd1307_ops = {
> - .init = ssd1307fb_ssd1307_init,
> - .remove = ssd1307fb_ssd1307_remove,
> -};
> + par->pwm_period = pwm_get_period(par->pwm);
> + /* Enable the PWM */
> + pwm_config(par->pwm, par->pwm_period / 2, par->pwm_period);
> + pwm_enable(par->pwm);
>
> -static int ssd1307fb_ssd1306_init(struct ssd1307fb_par *par)
> -{
> - int ret;
> + dev_dbg(&par->client->dev, "Using PWM%d with a %dns period.\n",
> + par->pwm->pwm, par->pwm_period);
> + };
>
> /* Set initial contrast */
> ret = ssd1307fb_write_cmd(par->client, SSD1307FB_CONTRAST);
> if (ret < 0)
> return ret;
>
> - ret = ssd1307fb_write_cmd(par->client, 0x7f);
> - if (ret < 0)
> - return ret;
> -
> - /* Set COM direction */
> - ret = ssd1307fb_write_cmd(par->client, 0xc8);
> + ret = ssd1307fb_write_cmd(par->client, par->contrast);
> if (ret < 0)
> return ret;
>
> /* Set segment re-map */
> - ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SEG_REMAP_ON);
> + if (par->seg_remap) {
> + ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SEG_REMAP_ON);
> + if (ret < 0)
> + return ret;
> + };
> +
> + /* Set COM direction */
> + com_invdir = 0xc0 | (par->com_invdir & 0xf) << 3;
> + ret = ssd1307fb_write_cmd(par->client, com_invdir);
> if (ret < 0)
> return ret;
>
> @@ -334,34 +330,38 @@ static int ssd1307fb_ssd1306_init(struct ssd1307fb_par *par)
> if (ret < 0)
> return ret;
>
> - ret = ssd1307fb_write_cmd(par->client, 0x20);
> + ret = ssd1307fb_write_cmd(par->client, par->com_offset);
> if (ret < 0)
> return ret;
>
> /* Set clock frequency */
> + dclk = (par->dclk_div & 0xf) | (par->dclk_frq & 0xf) << 4;
> ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_CLOCK_FREQ);
> if (ret < 0)
> return ret;
>
> - ret = ssd1307fb_write_cmd(par->client, 0xf0);
> + ret = ssd1307fb_write_cmd(par->client, dclk);
It would make more sense to assign the variable where you use it.
> if (ret < 0)
> return ret;
>
> /* Set precharge period in number of ticks from the internal clock */
> + precharge = (par->prechargep1 & 0xf) | (par->prechargep2 & 0xf) << 4;
> ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_PRECHARGE_PERIOD);
> if (ret < 0)
> return ret;
>
> - ret = ssd1307fb_write_cmd(par->client, 0x22);
> + ret = ssd1307fb_write_cmd(par->client, precharge);
Here too.
> if (ret < 0)
> return ret;
>
> /* Set COM pins configuration */
> + compins = 0x02 | (!par->com_seq & 0x1) << 4
> + | (par->com_lrremap & 0x1) << 5;
> ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_COM_PINS_CONFIG);
> if (ret < 0)
> return ret;
>
> - ret = ssd1307fb_write_cmd(par->client, 0x22);
> + ret = ssd1307fb_write_cmd(par->client, compins);
And here.
> if (ret < 0)
> return ret;
>
> @@ -370,18 +370,20 @@ static int ssd1307fb_ssd1306_init(struct ssd1307fb_par *par)
> if (ret < 0)
> return ret;
>
> - ret = ssd1307fb_write_cmd(par->client, 0x49);
> + ret = ssd1307fb_write_cmd(par->client, par->vcomh);
> if (ret < 0)
> return ret;
>
> - /* Turn on the DC-DC Charge Pump */
> - ret = ssd1307fb_write_cmd(par->client, SSD1307FB_CHARGE_PUMP);
> - if (ret < 0)
> - return ret;
> + if (par->device_info->device_id == DEVID_SSD1306) {
> + /* Turn on the DC-DC Charge Pump */
> + ret = ssd1307fb_write_cmd(par->client, SSD1307FB_CHARGE_PUMP);
> + if (ret < 0)
> + return ret;
>
> - ret = ssd1307fb_write_cmd(par->client, 0x14);
> - if (ret < 0)
> - return ret;
> + ret = ssd1307fb_write_cmd(par->client, 0x14);
> + if (ret < 0)
> + return ret;
> + };
>
> /* Switch to horizontal addressing mode */
> ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_ADDRESS_MODE);
> @@ -393,6 +395,7 @@ static int ssd1307fb_ssd1306_init(struct ssd1307fb_par *par)
> if (ret < 0)
> return ret;
>
> + /* Set column range */
The indentation is wrong.
> ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_COL_RANGE);
> if (ret < 0)
> return ret;
> @@ -405,6 +408,7 @@ static int ssd1307fb_ssd1306_init(struct ssd1307fb_par *par)
> if (ret < 0)
> return ret;
>
> + /* Set page range */
Here too.
> ret = ssd1307fb_write_cmd(par->client, SSD1307FB_SET_PAGE_RANGE);
> if (ret < 0)
> return ret;
> @@ -426,18 +430,28 @@ static int ssd1307fb_ssd1306_init(struct ssd1307fb_par *par)
> return 0;
> }
>
> -static struct ssd1307fb_ops ssd1307fb_ssd1306_ops = {
> - .init = ssd1307fb_ssd1306_init,
> +static struct ssd1307fb_deviceinfo ssd1307fb_ssd1306_deviceinfo = {
> + .device_id = DEVID_SSD1306,
> + .default_vcomh = 0x20,
> + .default_dclk_div = 0,
> + .default_dclk_frq = 8,
> +};
> +
> +static struct ssd1307fb_deviceinfo ssd1307fb_ssd1307_deviceinfo = {
> + .device_id = DEVID_SSD1307,
> + .default_vcomh = 0x20,
> + .default_dclk_div = 1,
> + .default_dclk_frq = 12,
> };
>
> static const struct of_device_id ssd1307fb_of_match[] = {
> {
> .compatible = "solomon,ssd1306fb-i2c",
> - .data = (void *)&ssd1307fb_ssd1306_ops,
> + .data = (void *)&ssd1307fb_ssd1306_deviceinfo,
> },
> {
> .compatible = "solomon,ssd1307fb-i2c",
> - .data = (void *)&ssd1307fb_ssd1307_ops,
> + .data = (void *)&ssd1307fb_ssd1307_deviceinfo,
Do we need this ID? Wouldn't it make more sense to pass the pointer to
the struct we need to use?
> },
> {},
> };
> @@ -468,8 +482,8 @@ static int ssd1307fb_probe(struct i2c_client *client,
> par->info = info;
> par->client = client;
>
> - par->ops = (struct ssd1307fb_ops *)of_match_device(ssd1307fb_of_match,
> - &client->dev)->data;
> + par->device_info = (struct ssd1307fb_deviceinfo *)of_match_device(
> + ssd1307fb_of_match, &client->dev)->data;
>
> par->reset = of_get_named_gpio(client->dev.of_node,
> "reset-gpios", 0);
> @@ -487,6 +501,27 @@ static int ssd1307fb_probe(struct i2c_client *client,
> if (of_property_read_u32(node, "solomon,page-offset", &par->page_offset))
> par->page_offset = 1;
>
> + if (of_property_read_u32(node, "solomon,com-offset", &par->com_offset))
> + par->com_offset = 0;
> +
> + if (of_property_read_u32(node, "solomon,prechargep1", &par->prechargep1))
> + par->prechargep1 = 2;
> +
> + if (of_property_read_u32(node, "solomon,prechargep2", &par->prechargep2))
> + par->prechargep2 = 0;
> +
> + par->seg_remap = !of_property_read_bool(node, "solomon,segment-no-remap");
> + par->com_seq = of_property_read_bool(node, "solomon,com-sequential");
> + par->com_lrremap = of_property_read_bool(node, "solomon,com-lrremap");
> + par->com_invdir = of_property_read_bool(node, "solomon,com-invdir");
> +
> + par->contrast = contrast;
> + par->vcomh = par->device_info->default_vcomh;
> +
> + /* Setup display timing */
> + par->dclk_div = par->device_info->default_dclk_div;
> + par->dclk_frq = par->device_info->default_dclk_frq;
> +
> vmem_size = par->width * par->height / 8;
>
> vmem = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
> @@ -539,11 +574,9 @@ static int ssd1307fb_probe(struct i2c_client *client,
> gpio_set_value(par->reset, 1);
> udelay(4);
>
> - if (par->ops->init) {
> - ret = par->ops->init(par);
> - if (ret)
> - goto reset_oled_error;
> - }
> + ret = ssd1307fb_init(par);
> + if (ret)
> + goto reset_oled_error;
>
> ret = register_framebuffer(info);
> if (ret) {
> @@ -556,8 +589,10 @@ static int ssd1307fb_probe(struct i2c_client *client,
> return 0;
>
> panel_init_error:
> - if (par->ops->remove)
> - par->ops->remove(par);
> + if (par->device_info->device_id == DEVID_SSD1307) {
> + pwm_disable(par->pwm);
> + pwm_put(par->pwm);
> + };
> reset_oled_error:
> fb_deferred_io_cleanup(info);
> fb_alloc_error:
> @@ -571,8 +606,10 @@ static int ssd1307fb_remove(struct i2c_client *client)
> struct ssd1307fb_par *par = info->par;
>
> unregister_framebuffer(info);
> - if (par->ops->remove)
> - par->ops->remove(par);
> + if (par->device_info->device_id == DEVID_SSD1307) {
> + pwm_disable(par->pwm);
> + pwm_put(par->pwm);
> + };
> fb_deferred_io_cleanup(info);
> __free_pages(__va(info->fix.smem_start), get_order(info->fix.smem_len));
> framebuffer_release(info);
> --
> 2.3.0
>
Thanks,
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
* Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
From: Lorenzo Stoakes @ 2015-03-18 19:10 UTC (permalink / raw)
To: Dan Carpenter
Cc: Vitaly Kuznetsov, devel, linux-fbdev, Teddy Wang, Greg KH,
linux-kernel, Sudip Mukherjee
In-Reply-To: <20150318112509.GP10964@mwanda>
On 18 March 2015 at 11:25, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> Could you read your patches again and find other similar white space
> issues.
Done.
Best,
--
Lorenzo Stoakes
https:/ljs.io
^ permalink raw reply
* Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
From: Lorenzo Stoakes @ 2015-03-18 19:09 UTC (permalink / raw)
To: Dan Carpenter
Cc: Sudip Mukherjee, Teddy Wang, Greg KH, devel, linux-fbdev,
linux-kernel
In-Reply-To: <20150318105920.GS16501@mwanda>
On 18 March 2015 at 10:59, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> Call it a v2 patch. Put a note under the --- cut off line:
> v2: updated to apply to latest linux-next
>
> http://kernelnewbies.org/PatchTipsAndTricks
Since each changed patch in the resend already incorporates changes to
update to apply to the latest linux-next, I instead referenced
whitespace/description changes (let me know if this isn't usually
something you'd reference) to avoid confusion, as otherwise I'd have
to resend other patches unchanged with just a v2 applied, then
additionally update the ones that need changes.
Let me know if you'd like this done differently!
Best,
--
Lorenzo Stoakes
https:/ljs.io
^ permalink raw reply
* [PATCH RESEND v2 4/5] staging: sm750fb: Fix __iomem pointer types
From: Lorenzo Stoakes @ 2015-03-18 19:04 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, devel, linux-kernel, Lorenzo Stoakes
In-Reply-To: <1426705493-26615-1-git-send-email-lstoakes@gmail.com>
This patch annotates pointers as referring to I/O mapped memory where they ought
to be, removes now unnecessary ugly casts, eliminates an incorrect deref on I/O
mapped memory by using iowrite16 instead, and updates the pointer arithmetic
accordingly to take into account that the pointers are now byte-sized. This
fixes the following sparse warnings:-
drivers/staging/sm750fb/sm750_cursor.c:113:19: warning: cast removes address space of expression
drivers/staging/sm750fb/sm750_cursor.c:204:19: warning: cast removes address space of expression
Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
---
v2: Whitespace fixups
drivers/staging/sm750fb/sm750_cursor.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_cursor.c b/drivers/staging/sm750fb/sm750_cursor.c
index 6cceef1..c2ff3bd 100644
--- a/drivers/staging/sm750fb/sm750_cursor.c
+++ b/drivers/staging/sm750fb/sm750_cursor.c
@@ -98,7 +98,7 @@ void hw_cursor_setData(struct lynx_cursor * cursor,
int i,j,count,pitch,offset;
u8 color,mask,opr;
u16 data;
- u16 * pbuffer,*pstart;
+ void __iomem *pbuffer, *pstart;
/* in byte*/
pitch = cursor->w >> 3;
@@ -106,11 +106,11 @@ void hw_cursor_setData(struct lynx_cursor * cursor,
/* in byte */
count = pitch * cursor->h;
- /* in ushort */
- offset = cursor->maxW * 2 / 8 / 2;
+ /* in byte */
+ offset = cursor->maxW * 2 / 8;
data = 0;
- pstart = (u16 *)cursor->vstart;
+ pstart = cursor->vstart;
pbuffer = pstart;
/*
@@ -161,7 +161,7 @@ void hw_cursor_setData(struct lynx_cursor * cursor,
}
}
#endif
- *pbuffer = data;
+ iowrite16(data, pbuffer);
/* assume pitch is 1,2,4,8,...*/
#if 0
@@ -174,7 +174,7 @@ void hw_cursor_setData(struct lynx_cursor * cursor,
pstart += offset;
pbuffer = pstart;
}else{
- pbuffer++;
+ pbuffer += sizeof(u16);
}
}
@@ -189,7 +189,7 @@ void hw_cursor_setData2(struct lynx_cursor * cursor,
int i,j,count,pitch,offset;
u8 color, mask;
u16 data;
- u16 * pbuffer,*pstart;
+ void __iomem *pbuffer, *pstart;
/* in byte*/
pitch = cursor->w >> 3;
@@ -197,11 +197,11 @@ void hw_cursor_setData2(struct lynx_cursor * cursor,
/* in byte */
count = pitch * cursor->h;
- /* in ushort */
- offset = cursor->maxW * 2 / 8 / 2;
+ /* in byte */
+ offset = cursor->maxW * 2 / 8;
data = 0;
- pstart = (u16 *)cursor->vstart;
+ pstart = cursor->vstart;
pbuffer = pstart;
for(i=0;i<count;i++)
@@ -234,7 +234,7 @@ void hw_cursor_setData2(struct lynx_cursor * cursor,
data |= ((color & (1<<j))?1:2)<<(j*2);
}
#endif
- *pbuffer = data;
+ iowrite16(data, pbuffer);
/* assume pitch is 1,2,4,8,...*/
if(!(i&(pitch-1)))
@@ -244,7 +244,7 @@ void hw_cursor_setData2(struct lynx_cursor * cursor,
pstart += offset;
pbuffer = pstart;
}else{
- pbuffer++;
+ pbuffer += sizeof(u16);
}
}
--
2.3.2
^ permalink raw reply related
* [PATCH RESEND v2 1/5] staging: sm750fb: Use memset_io instead of memset
From: Lorenzo Stoakes @ 2015-03-18 19:04 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, devel, linux-kernel, Lorenzo Stoakes
This patch takes into account that cursor->vstart, crtc->vScreen and
share->pvMem are pointers to memory-mapped I/O and thus we should use memset_io
to make this explicit. In addition, some architectures require special treatment
of memory-mapped I/O so the previous code could actually break without this
change.
This fixes the following sparse warnings:-
drivers/staging/sm750fb/sm750.c:489:17: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/sm750fb/sm750.c:490:17: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/sm750fb/sm750.c:501:17: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/sm750fb/sm750.c:502:17: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/sm750fb/sm750.c:833:5: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/sm750fb/sm750.c:1154:9: warning: incorrect type in argument 1 (different address spaces)
Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
---
v2: Whitespace fixups, updated commit message
drivers/staging/sm750fb/sm750.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index aa0888c..3e36b6a 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -486,8 +486,8 @@ static int lynxfb_resume(struct pci_dev* pdev)
par = info->par;
crtc = &par->crtc;
cursor = &crtc->cursor;
- memset(cursor->vstart, 0x0, cursor->size);
- memset(crtc->vScreen,0x0,crtc->vidmem_size);
+ memset_io(cursor->vstart, 0x0, cursor->size);
+ memset_io(crtc->vScreen, 0x0, crtc->vidmem_size);
lynxfb_ops_set_par(info);
fb_set_suspend(info, 0);
}
@@ -498,8 +498,8 @@ static int lynxfb_resume(struct pci_dev* pdev)
par = info->par;
crtc = &par->crtc;
cursor = &crtc->cursor;
- memset(cursor->vstart, 0x0, cursor->size);
- memset(crtc->vScreen,0x0,crtc->vidmem_size);
+ memset_io(cursor->vstart, 0x0, cursor->size);
+ memset_io(crtc->vScreen, 0x0, crtc->vidmem_size);
lynxfb_ops_set_par(info);
fb_set_suspend(info, 0);
}
@@ -830,7 +830,7 @@ static int lynxfb_set_fbinfo(struct fb_info* info,int index)
crtc->cursor.share = share;
- memset(crtc->cursor.vstart, 0, crtc->cursor.size);
+ memset_io(crtc->cursor.vstart, 0, crtc->cursor.size);
if(!g_hwcursor){
lynxfb_ops.fb_cursor = NULL;
crtc->cursor.disable(&crtc->cursor);
@@ -1151,7 +1151,7 @@ static int lynxfb_pci_probe(struct pci_dev * pdev,
}
#endif
- memset(share->pvMem,0,share->vidmem_size);
+ memset_io(share->pvMem, 0, share->vidmem_size);
pr_info("sm%3x mmio address = %p\n",share->devid,share->pvReg);
--
2.3.2
^ permalink raw reply related
* Re: [PATCHv4 02/10] fbdev: ssd1307fb: Allocate page aligned video memory.
From: Maxime Ripard @ 2015-03-18 17:38 UTC (permalink / raw)
To: Thomas Niederprüm
Cc: plagnioj, tomi.valkeinen, kernel, shawn.guo, robh+dt, linux-fbdev,
linux-kernel
In-Reply-To: <1426525918-12745-3-git-send-email-niederp@physik.uni-kl.de>
[-- Attachment #1: Type: text/plain, Size: 877 bytes --]
On Mon, Mar 16, 2015 at 06:11:50PM +0100, Thomas Niederprüm wrote:
> Currently the videomemory is allocated by kmalloc, making it a memory
> region that is not necessarily page aligend. This leads to problems
> upon mmap call, where the video memory's address gets aligned to the
> next page boundary. The result is that the userspace program that issued
> the mmap call is not able to access the video memory from the start to
> the next page boundary.
>
> This patch changes the allocation of the video memory to use
> __get_free_pages() in order to obtain memory that is aligned
> to page boundaries.
>
> Signed-off-by: Thomas Niederprüm <niederp@physik.uni-kl.de>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks!
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
* Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
From: Sudip Mukherjee @ 2015-03-18 13:41 UTC (permalink / raw)
To: Dan Carpenter
Cc: devel, linux-fbdev, Lorenzo Stoakes, Greg KH, linux-kernel,
Teddy Wang
In-Reply-To: <20150318132339.GR10964@mwanda>
On Wed, Mar 18, 2015 at 04:23:39PM +0300, Dan Carpenter wrote:
> > https://lkml.org/lkml/2015/3/10/685
> >
>
> You were making random white space changes and not on the same line. It
> was hard to review because you had to count how many u32 arguments there
> were (a million) and really look at it to see what the compile warning
> was. There was no compile warning in the end. Very annoying.
ok, now understood. Thanks.
like you said once - combining different changes in a single patch is
an art. :)
regards
sudip
>
> regards,
> dan carpenter
>
^ permalink raw reply
* Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
From: Dan Carpenter @ 2015-03-18 13:23 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: devel, linux-fbdev, Lorenzo Stoakes, Greg KH, linux-kernel,
Teddy Wang
In-Reply-To: <20150318130607.GB32758@sudip-PC>
On Wed, Mar 18, 2015 at 06:36:07PM +0530, Sudip Mukherjee wrote:
> On Wed, Mar 18, 2015 at 02:25:09PM +0300, Dan Carpenter wrote:
> > On Wed, Mar 18, 2015 at 11:12:20AM +0000, Lorenzo Stoakes wrote:
> > > On 18 March 2015 at 10:50, Vitaly Kuznetsov <vkuznets@redhat.com> wrote:
> > If it's a white space thing on the same line then it's generally ok to
> > fix it. The "one thing per patch" is meant to make patches easier to
> > review. If it's a trivial thing and it doesn't make it harder to review
> > then we are reasonable people.
> >
> but Greg K-H has explisitely mentiond not to do so.
> I did just that and fixed few whitespace things in the patch to fix the
> build failure.
>
> https://lkml.org/lkml/2015/3/10/685
>
You were making random white space changes and not on the same line. It
was hard to review because you had to count how many u32 arguments there
were (a million) and really look at it to see what the compile warning
was. There was no compile warning in the end. Very annoying.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
From: Sudip Mukherjee @ 2015-03-18 13:18 UTC (permalink / raw)
To: Dan Carpenter
Cc: Lorenzo Stoakes, Vitaly Kuznetsov, devel, linux-fbdev, Teddy Wang,
Greg KH, linux-kernel
In-Reply-To: <20150318112509.GP10964@mwanda>
On Wed, Mar 18, 2015 at 02:25:09PM +0300, Dan Carpenter wrote:
> On Wed, Mar 18, 2015 at 11:12:20AM +0000, Lorenzo Stoakes wrote:
> > On 18 March 2015 at 10:50, Vitaly Kuznetsov <vkuznets@redhat.com> wrote:
> If it's a white space thing on the same line then it's generally ok to
> fix it. The "one thing per patch" is meant to make patches easier to
> review. If it's a trivial thing and it doesn't make it harder to review
> then we are reasonable people.
>
but Greg K-H has explisitely mentiond not to do so.
I did just that and fixed few whitespace things in the patch to fix the
build failure.
https://lkml.org/lkml/2015/3/10/685
regards
sudip
^ permalink raw reply
* Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
From: Dan Carpenter @ 2015-03-18 11:25 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Vitaly Kuznetsov, devel, linux-fbdev, Teddy Wang, Greg KH,
linux-kernel, Sudip Mukherjee
In-Reply-To: <CAA5enKZYqmysuFqPPptgVvyBJAzX8UYBkod1t3Atvu3Q5TUEjQ@mail.gmail.com>
On Wed, Mar 18, 2015 at 11:12:20AM +0000, Lorenzo Stoakes wrote:
> On 18 March 2015 at 10:50, Vitaly Kuznetsov <vkuznets@redhat.com> wrote:
> > ERROR is reported by scripts/checkpatch.pl (spaces are missing after
> > ','). This coding style problem was there before your patch but I don't
> > think it makes sense to preserve it.
>
> [snip]
>
> > WARNING: please, no spaces at the start of a line
> > #137: FILE: drivers/staging/sm750fb/sm750.c:833:
>
> [snip]
>
> Hi Vitaly, these style issues have vexed me and I was not sure whether
> to make changes or preserve all the obvious errors so as not to blend
> the two changes inappropriately, however it does indeed make sense to
> fix these on the lines I'm changing, will fix these!
If it's a white space thing on the same line then it's generally ok to
fix it. The "one thing per patch" is meant to make patches easier to
review. If it's a trivial thing and it doesn't make it harder to review
then we are reasonable people.
Could you read your patches again and find other similar white space
issues.
+ void __iomem * pbuffer,*pstart;
Should be:
+ void __iomem *pbuffer, *pstart;
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
From: Lorenzo Stoakes @ 2015-03-18 11:14 UTC (permalink / raw)
To: Dan Carpenter
Cc: Sudip Mukherjee, Teddy Wang, Greg KH, devel, linux-fbdev,
linux-kernel
In-Reply-To: <20150318105920.GS16501@mwanda>
On 18 March 2015 at 10:59, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> Btw, sorry for coming down hard on you. You're a newbie and expected to
> make these mistakes. Your patches are good and appreciated.
Thanks and no problem, I expect to receive robust criticism given the
high standards in the kernel and see it as a means to improve my
contributions :)
>
> Call it a v2 patch. Put a note under the --- cut off line:
> v2: updated to apply to latest linux-next
>
> http://kernelnewbies.org/PatchTipsAndTricks
>
Great, thanks, will do! Very useful link!
Best,
--
Lorenzo Stoakes
https:/ljs.io
^ permalink raw reply
* Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
From: Lorenzo Stoakes @ 2015-03-18 11:12 UTC (permalink / raw)
To: Vitaly Kuznetsov
Cc: Sudip Mukherjee, Teddy Wang, Greg KH, devel, linux-fbdev,
linux-kernel
In-Reply-To: <87oanqo9zi.fsf@vitty.brq.redhat.com>
On 18 March 2015 at 10:50, Vitaly Kuznetsov <vkuznets@redhat.com> wrote:
> ERROR is reported by scripts/checkpatch.pl (spaces are missing after
> ','). This coding style problem was there before your patch but I don't
> think it makes sense to preserve it.
[snip]
> WARNING: please, no spaces at the start of a line
> #137: FILE: drivers/staging/sm750fb/sm750.c:833:
[snip]
Hi Vitaly, these style issues have vexed me and I was not sure whether
to make changes or preserve all the obvious errors so as not to blend
the two changes inappropriately, however it does indeed make sense to
fix these on the lines I'm changing, will fix these!
Best,
--
Lorenzo Stoakes
https:/ljs.io
^ permalink raw reply
* Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
From: Dan Carpenter @ 2015-03-18 10:59 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Sudip Mukherjee, Teddy Wang, Greg KH, devel, linux-fbdev,
linux-kernel
In-Reply-To: <CAA5enKZTjSsfX_4XkZFjbpDchZuBDfTNaK1_5GjFFwthjFZM7Q@mail.gmail.com>
On Wed, Mar 18, 2015 at 10:46:52AM +0000, Lorenzo Stoakes wrote:
> On 18 March 2015 at 10:17, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> > Why is there a RESEND in the subject.
>
> To avoid confusion (and Sudip explicitly mentioned there might be
> some), and in addition I had to update my patch series to take into
> account that it no longer applied due to another patch which applies
> the ANSI C function prototype fixes having already been applied.
Btw, sorry for coming down hard on you. You're a newbie and expected to
make these mistakes. Your patches are good and appreciated.
Call it a v2 patch. Put a note under the --- cut off line:
v2: updated to apply to latest linux-next
http://kernelnewbies.org/PatchTipsAndTricks
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
From: Lorenzo Stoakes @ 2015-03-18 10:55 UTC (permalink / raw)
To: Dan Carpenter
Cc: devel, linux-fbdev, Teddy Wang, Greg KH, linux-kernel,
Sudip Mukherjee
In-Reply-To: <20150318105256.GR16501@mwanda>
On 18 March 2015 at 10:52, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> I often say "don't resend" because something is minor and I don't want
> to slow you down but since you were resending it anyway then please fix
> it. Also changelogs are really easy to fix. In mutt, you can do it
> without leaving your email client. So I have revised my earlier
> statement, please fix it. :)
Will do!
I have experimented with mutt, I tend to just use git send-email
directly at the moment and edit patch files manually and use the gmail
web interface for reading/discussion, I am sure I will learn to do
things a little more sanely in time, the hard way :)
Best,
--
Lorenzo Stoakes
https:/ljs.io
^ permalink raw reply
* Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
From: Dan Carpenter @ 2015-03-18 10:52 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: devel, linux-fbdev, Teddy Wang, Greg KH, linux-kernel,
Sudip Mukherjee
In-Reply-To: <CAA5enKZqRPx8a9Kk7cX1GJih9=N+Wj_zPbhg+hbLDJoKNEau-Q@mail.gmail.com>
On Wed, Mar 18, 2015 at 10:44:53AM +0000, Lorenzo Stoakes wrote:
> On 18 March 2015 at 10:18, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> >>
> >> This changelog still sucks. It doesn't describe the effect of this
> >> behavior change for the user. It doesn't even make it clear that you
> >> are aware that this is a behavior change.
> >
> > It doesn't say to me that you have asked yourself if the sparse
> > annotations are correct. Many times they are wrong.
>
> My understanding, which as a new contributor is of course limited and
> likely simply wrong in many aspects, is - these memset's are referring
> to I/O mapped memory, which as far as I can tell is actually the case
> here, so in order to make it explicit that this is the case and we
> know it is, we use memset_io. As far as I understand the pointers
> simply have a modifier applied which marks them as I/O mapped memory
> for the purposes of sparse checking whether they are used consistently
> as such and are not treated like they are a normal kernel pointer.
>
> In this case the cursor->vstart and crtc->vScreen pointers, looking
> through the source, explicitly refer to memory which is I/O mapped,
> and is annotated as __iomem accordingly throughout.
>
> I will update the message accordingly, obviously if I'm
> misunderstanding something let me know.
This is all fine.
>
> > We have had this discussion before but you still sent the same exact
> > bad changelog.
>
> Actually you said:-
>
> > When I see a patch like this, then I worry, "What if the Sparse
> > annotations are wrong? The patch description doesn't say anything about
> > that." After review then I think the annotations are correct so that's
> > fine.
>
> And:-
The patch is fine. The changelog is not.
>
> > Yes. The patch is correct. I wasn't asking you to redo it. From later
> > patches it's actually clear that you know that this change is a bugfix
> > and a behavior change. But we get a lot of patches where people just
> > randomly change things to please Sparse and it maybe silences a warning
> > but it's not correct. I can think of a few recentish examples where
> > people used standard struct types which hold __iomem or __user pointers
> > but they used them in non-standard ways so the pointers were actually
> > normal kernel pointers.
>
> So it wasn't clear *to me* you wanted me to change that, given you
> asked me *not* to redo it explicitly (which I assumed applied to the
> message too) - apologies if I misinterpreted this!
I often say "don't resend" because something is minor and I don't want
to slow you down but since you were resending it anyway then please fix
it. Also changelogs are really easy to fix. In mutt, you can do it
without leaving your email client. So I have revised my earlier
statement, please fix it. :)
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
From: Vitaly Kuznetsov @ 2015-03-18 10:50 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: sudipm.mukherjee, teddy.wang, gregkh, devel, linux-fbdev,
linux-kernel
In-Reply-To: <1426669046-29935-1-git-send-email-lstoakes@gmail.com>
Lorenzo Stoakes <lstoakes@gmail.com> writes:
> This patch uses memset_io instead of memset when using memset on __iomem
> qualified pointers. This fixes the following sparse warnings:-
>
> drivers/staging/sm750fb/sm750.c:489:17: warning: incorrect type in argument 1 (different address spaces)
> drivers/staging/sm750fb/sm750.c:490:17: warning: incorrect type in argument 1 (different address spaces)
> drivers/staging/sm750fb/sm750.c:501:17: warning: incorrect type in argument 1 (different address spaces)
> drivers/staging/sm750fb/sm750.c:502:17: warning: incorrect type in argument 1 (different address spaces)
> drivers/staging/sm750fb/sm750.c:833:5: warning: incorrect type in argument 1 (different address spaces)
> drivers/staging/sm750fb/sm750.c:1154:9: warning: incorrect type in argument 1 (different address spaces)
>
> Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
> ---
> drivers/staging/sm750fb/sm750.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
> index aa0888c..3e36b6a 100644
> --- a/drivers/staging/sm750fb/sm750.c
> +++ b/drivers/staging/sm750fb/sm750.c
> @@ -486,8 +486,8 @@ static int lynxfb_resume(struct pci_dev* pdev)
> par = info->par;
> crtc = &par->crtc;
> cursor = &crtc->cursor;
> - memset(cursor->vstart, 0x0, cursor->size);
> - memset(crtc->vScreen,0x0,crtc->vidmem_size);
> + memset_io(cursor->vstart, 0x0, cursor->size);
> + memset_io(crtc->vScreen,0x0,crtc->vidmem_size);
ERROR is reported by scripts/checkpatch.pl (spaces are missing after
','). This coding style problem was there before your patch but I don't
think it makes sense to preserve it.
> lynxfb_ops_set_par(info);
> fb_set_suspend(info, 0);
> }
> @@ -498,8 +498,8 @@ static int lynxfb_resume(struct pci_dev* pdev)
> par = info->par;
> crtc = &par->crtc;
> cursor = &crtc->cursor;
> - memset(cursor->vstart, 0x0, cursor->size);
> - memset(crtc->vScreen,0x0,crtc->vidmem_size);
> + memset_io(cursor->vstart, 0x0, cursor->size);
> + memset_io(crtc->vScreen,0x0,crtc->vidmem_size);
the same
> lynxfb_ops_set_par(info);
> fb_set_suspend(info, 0);
> }
> @@ -830,7 +830,7 @@ static int lynxfb_set_fbinfo(struct fb_info* info,int index)
>
> crtc->cursor.share = share;
> - memset(crtc->cursor.vstart, 0, crtc->cursor.size);
> + memset_io(crtc->cursor.vstart, 0, crtc->cursor.size);
WARNING: please, no spaces at the start of a line
#137: FILE: drivers/staging/sm750fb/sm750.c:833:
+ memset_io(crtc->cursor.vstart, 0, crtc->cursor.size);$
> if(!g_hwcursor){
> lynxfb_ops.fb_cursor = NULL;
> crtc->cursor.disable(&crtc->cursor);
> @@ -1151,7 +1151,7 @@ static int lynxfb_pci_probe(struct pci_dev * pdev,
> }
> #endif
>
> - memset(share->pvMem,0,share->vidmem_size);
> + memset_io(share->pvMem,0,share->vidmem_size);
the same missing spaces
>
> pr_info("sm%3x mmio address = %p\n",share->devid,share->pvReg);
>
> --
> 2.3.2
> _______________________________________________
> devel mailing list
> devel@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
--
Vitaly
^ permalink raw reply
* Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
From: Lorenzo Stoakes @ 2015-03-18 10:46 UTC (permalink / raw)
To: Dan Carpenter
Cc: Sudip Mukherjee, Teddy Wang, Greg KH, devel, linux-fbdev,
linux-kernel
In-Reply-To: <20150318101717.GN10964@mwanda>
On 18 March 2015 at 10:17, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> Why is there a RESEND in the subject.
To avoid confusion (and Sudip explicitly mentioned there might be
some), and in addition I had to update my patch series to take into
account that it no longer applied due to another patch which applies
the ANSI C function prototype fixes having already been applied.
Best,
--
Lorenzo Stoakes
https:/ljs.io
^ permalink raw reply
* Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
From: Lorenzo Stoakes @ 2015-03-18 10:44 UTC (permalink / raw)
To: Dan Carpenter
Cc: devel, linux-fbdev, Teddy Wang, Greg KH, linux-kernel,
Sudip Mukherjee
In-Reply-To: <20150318101857.GO10964@mwanda>
On 18 March 2015 at 10:18, Dan Carpenter <dan.carpenter@oracle.com> wrote:
>>
>> This changelog still sucks. It doesn't describe the effect of this
>> behavior change for the user. It doesn't even make it clear that you
>> are aware that this is a behavior change.
>
> It doesn't say to me that you have asked yourself if the sparse
> annotations are correct. Many times they are wrong.
My understanding, which as a new contributor is of course limited and
likely simply wrong in many aspects, is - these memset's are referring
to I/O mapped memory, which as far as I can tell is actually the case
here, so in order to make it explicit that this is the case and we
know it is, we use memset_io. As far as I understand the pointers
simply have a modifier applied which marks them as I/O mapped memory
for the purposes of sparse checking whether they are used consistently
as such and are not treated like they are a normal kernel pointer.
In this case the cursor->vstart and crtc->vScreen pointers, looking
through the source, explicitly refer to memory which is I/O mapped,
and is annotated as __iomem accordingly throughout.
I will update the message accordingly, obviously if I'm
misunderstanding something let me know.
> We have had this discussion before but you still sent the same exact
> bad changelog.
Actually you said:-
> When I see a patch like this, then I worry, "What if the Sparse
> annotations are wrong? The patch description doesn't say anything about
> that." After review then I think the annotations are correct so that's
> fine.
And:-
> Yes. The patch is correct. I wasn't asking you to redo it. From later
> patches it's actually clear that you know that this change is a bugfix
> and a behavior change. But we get a lot of patches where people just
> randomly change things to please Sparse and it maybe silences a warning
> but it's not correct. I can think of a few recentish examples where
> people used standard struct types which hold __iomem or __user pointers
> but they used them in non-standard ways so the pointers were actually
> normal kernel pointers.
So it wasn't clear *to me* you wanted me to change that, given you
asked me *not* to redo it explicitly (which I assumed applied to the
message too) - apologies if I misinterpreted this!
Best,
--
Lorenzo Stoakes
https:/ljs.io
^ permalink raw reply
* Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
From: Dan Carpenter @ 2015-03-18 10:18 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: devel, linux-fbdev, teddy.wang, gregkh, linux-kernel,
sudipm.mukherjee
In-Reply-To: <20150318101717.GN10964@mwanda>
On Wed, Mar 18, 2015 at 01:17:17PM +0300, Dan Carpenter wrote:
> Why is there a RESEND in the subject.
>
> On Wed, Mar 18, 2015 at 08:57:22AM +0000, Lorenzo Stoakes wrote:
> > This patch uses memset_io instead of memset when using memset on __iomem
> > qualified pointers. This fixes the following sparse warnings:-
> >
> > drivers/staging/sm750fb/sm750.c:489:17: warning: incorrect type in argument 1 (different address spaces)
> > drivers/staging/sm750fb/sm750.c:490:17: warning: incorrect type in argument 1 (different address spaces)
> > drivers/staging/sm750fb/sm750.c:501:17: warning: incorrect type in argument 1 (different address spaces)
> > drivers/staging/sm750fb/sm750.c:502:17: warning: incorrect type in argument 1 (different address spaces)
> > drivers/staging/sm750fb/sm750.c:833:5: warning: incorrect type in argument 1 (different address spaces)
> > drivers/staging/sm750fb/sm750.c:1154:9: warning: incorrect type in argument 1 (different address spaces)
> >
>
> This changelog still sucks. It doesn't describe the effect of this
> behavior change for the user. It doesn't even make it clear that you
> are aware that this is a behavior change.
It doesn't say to me that you have asked yourself if the sparse
annotations are correct. Many times they are wrong.
We have had this discussion before but you still sent the same exact
bad changelog.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH RESEND 1/5] staging: sm750fb: Use memset_io instead of memset
From: Dan Carpenter @ 2015-03-18 10:17 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: sudipm.mukherjee, teddy.wang, gregkh, devel, linux-fbdev,
linux-kernel
In-Reply-To: <1426669046-29935-1-git-send-email-lstoakes@gmail.com>
Why is there a RESEND in the subject.
On Wed, Mar 18, 2015 at 08:57:22AM +0000, Lorenzo Stoakes wrote:
> This patch uses memset_io instead of memset when using memset on __iomem
> qualified pointers. This fixes the following sparse warnings:-
>
> drivers/staging/sm750fb/sm750.c:489:17: warning: incorrect type in argument 1 (different address spaces)
> drivers/staging/sm750fb/sm750.c:490:17: warning: incorrect type in argument 1 (different address spaces)
> drivers/staging/sm750fb/sm750.c:501:17: warning: incorrect type in argument 1 (different address spaces)
> drivers/staging/sm750fb/sm750.c:502:17: warning: incorrect type in argument 1 (different address spaces)
> drivers/staging/sm750fb/sm750.c:833:5: warning: incorrect type in argument 1 (different address spaces)
> drivers/staging/sm750fb/sm750.c:1154:9: warning: incorrect type in argument 1 (different address spaces)
>
This changelog still sucks. It doesn't describe the effect of this
behavior change for the user. It doesn't even make it clear that you
are aware that this is a behavior change.
regards,
dan carpenter
^ permalink raw reply
* [PATCH RESEND 5/5] staging: sm750fb: Remove spinlock helper function
From: Lorenzo Stoakes @ 2015-03-18 8:57 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, devel, linux-kernel, Lorenzo Stoakes
In-Reply-To: <1426669046-29935-1-git-send-email-lstoakes@gmail.com>
This patch removes the unnecessary spinlock helper function and instead
calls spin_lock and spin_unlock directly.
This does *not* resolve sparse warnings about context imbalances but these are
spurious.
Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
---
drivers/staging/sm750fb/sm750.c | 53 +++++++++++++++++++++++------------------
1 file changed, 30 insertions(+), 23 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index be35429..a6658e1 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -56,23 +56,6 @@ static char * g_settings = NULL;
static int g_dualview;
static char * g_option = NULL;
-/* if not use spin_lock,system will die if user load driver
- * and immediatly unload driver frequently (dual)*/
-static inline void myspin_lock(spinlock_t * sl){
- struct lynx_share * share;
- share = container_of(sl,struct lynx_share,slock);
- if(share->dual){
- spin_lock(sl);
- }
-}
-
-static inline void myspin_unlock(spinlock_t * sl){
- struct lynx_share * share;
- share = container_of(sl,struct lynx_share,slock);
- if(share->dual){
- spin_unlock(sl);
- }
-}
static const struct fb_videomode lynx750_ext[] = {
/* 1024x600-60 VESA [1.71:1] */
{NULL, 60, 1024, 600, 20423, 144, 40, 18, 1, 104, 3,
@@ -209,13 +192,21 @@ static void lynxfb_ops_fillrect(struct fb_info* info,const struct fb_fillrect* r
color = (Bpp = 1)?region->color:((u32*)info->pseudo_palette)[region->color];
rop = ( region->rop != ROP_COPY ) ? HW_ROP2_XOR:HW_ROP2_COPY;
- myspin_lock(&share->slock);
+ /*
+ * If not use spin_lock,system will die if user load driver
+ * and immediatly unload driver frequently (dual)
+ */
+ if (share->dual)
+ spin_lock(&share->slock);
+
share->accel.de_fillrect(&share->accel,
base,pitch,Bpp,
region->dx,region->dy,
region->width,region->height,
color,rop);
- myspin_unlock(&share->slock);
+
+ if (share->dual)
+ spin_unlock(&share->slock);
}
static void lynxfb_ops_copyarea(struct fb_info * info,const struct fb_copyarea * region)
@@ -233,12 +224,20 @@ static void lynxfb_ops_copyarea(struct fb_info * info,const struct fb_copyarea *
pitch = info->fix.line_length;
Bpp = info->var.bits_per_pixel >> 3;
- myspin_lock(&share->slock);
+ /*
+ * If not use spin_lock, system will die if user load driver
+ * and immediatly unload driver frequently (dual)
+ */
+ if (share->dual)
+ spin_lock(&share->slock);
+
share->accel.de_copyarea(&share->accel,
base,pitch,region->sx,region->sy,
base,pitch,Bpp,region->dx,region->dy,
region->width,region->height,HW_ROP2_COPY);
- myspin_unlock(&share->slock);
+
+ if (share->dual)
+ spin_unlock(&share->slock);
}
static void lynxfb_ops_imageblit(struct fb_info*info,const struct fb_image* image)
@@ -272,14 +271,22 @@ static void lynxfb_ops_imageblit(struct fb_info*info,const struct fb_image* imag
}
return;
_do_work:
- myspin_lock(&share->slock);
+ /*
+ * If not use spin_lock, system will die if user load driver
+ * and immediatly unload driver frequently (dual)
+ */
+ if (share->dual)
+ spin_lock(&share->slock);
+
share->accel.de_imageblit(&share->accel,
image->data,image->width>>3,0,
base,pitch,Bpp,
image->dx,image->dy,
image->width,image->height,
fgcol,bgcol,HW_ROP2_COPY);
- myspin_unlock(&share->slock);
+
+ if (share->dual)
+ spin_unlock(&share->slock);
}
static int lynxfb_ops_pan_display(struct fb_var_screeninfo *var,
--
2.3.3
^ permalink raw reply related
* [PATCH RESEND 4/5] staging: sm750fb: Fix __iomem pointer types
From: Lorenzo Stoakes @ 2015-03-18 8:57 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh
Cc: linux-fbdev, devel, linux-kernel, Lorenzo Stoakes
In-Reply-To: <1426669046-29935-1-git-send-email-lstoakes@gmail.com>
This patch annotates pointers as referring to I/O mapped memory where they ought
to be, removes now unnecessary ugly casts, eliminates an incorrect deref on I/O
mapped memory by using iowrite16 instead, and updates the pointer arithmetic
accordingly to take into account that the pointers are now byte-sized. This
fixes the following sparse warnings:-
drivers/staging/sm750fb/sm750_cursor.c:113:19: warning: cast removes address space of expression
drivers/staging/sm750fb/sm750_cursor.c:204:19: warning: cast removes address space of expression
Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
---
drivers/staging/sm750fb/sm750_cursor.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/sm750fb/sm750_cursor.c b/drivers/staging/sm750fb/sm750_cursor.c
index 6cceef1..c2ff3bd 100644
--- a/drivers/staging/sm750fb/sm750_cursor.c
+++ b/drivers/staging/sm750fb/sm750_cursor.c
@@ -98,7 +98,7 @@ void hw_cursor_setData(struct lynx_cursor * cursor,
int i,j,count,pitch,offset;
u8 color,mask,opr;
u16 data;
- u16 * pbuffer,*pstart;
+ void __iomem * pbuffer,*pstart;
/* in byte*/
pitch = cursor->w >> 3;
@@ -106,11 +106,11 @@ void hw_cursor_setData(struct lynx_cursor * cursor,
/* in byte */
count = pitch * cursor->h;
- /* in ushort */
- offset = cursor->maxW * 2 / 8 / 2;
+ /* in byte */
+ offset = cursor->maxW * 2 / 8;
data = 0;
- pstart = (u16 *)cursor->vstart;
+ pstart = cursor->vstart;
pbuffer = pstart;
/*
@@ -161,7 +161,7 @@ void hw_cursor_setData(struct lynx_cursor * cursor,
}
}
#endif
- *pbuffer = data;
+ iowrite16(data, pbuffer);
/* assume pitch is 1,2,4,8,...*/
#if 0
@@ -174,7 +174,7 @@ void hw_cursor_setData(struct lynx_cursor * cursor,
pstart += offset;
pbuffer = pstart;
}else{
- pbuffer++;
+ pbuffer += sizeof(u16);
}
}
@@ -189,7 +189,7 @@ void hw_cursor_setData2(struct lynx_cursor * cursor,
int i,j,count,pitch,offset;
u8 color, mask;
u16 data;
- u16 * pbuffer,*pstart;
+ void __iomem * pbuffer,*pstart;
/* in byte*/
pitch = cursor->w >> 3;
@@ -197,11 +197,11 @@ void hw_cursor_setData2(struct lynx_cursor * cursor,
/* in byte */
count = pitch * cursor->h;
- /* in ushort */
- offset = cursor->maxW * 2 / 8 / 2;
+ /* in byte */
+ offset = cursor->maxW * 2 / 8;
data = 0;
- pstart = (u16 *)cursor->vstart;
+ pstart = cursor->vstart;
pbuffer = pstart;
for(i=0;i<count;i++)
@@ -234,7 +234,7 @@ void hw_cursor_setData2(struct lynx_cursor * cursor,
data |= ((color & (1<<j))?1:2)<<(j*2);
}
#endif
- *pbuffer = data;
+ iowrite16(data, pbuffer);
/* assume pitch is 1,2,4,8,...*/
if(!(i&(pitch-1)))
@@ -244,7 +244,7 @@ void hw_cursor_setData2(struct lynx_cursor * cursor,
pstart += offset;
pbuffer = pstart;
}else{
- pbuffer++;
+ pbuffer += sizeof(u16);
}
}
--
2.3.2
^ 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