* Re: [PATCH v4 3/3] video: fbdev: vesafb: use arch_phys_wc_add()
From: Tomi Valkeinen @ 2015-06-12 9:04 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: plagnioj, bp, hpa, linux-fbdev, luto, toshi.kani, sbsiddha, mingo,
tglx, jgross, daniel.vetter, airlied, adaplas, robdclark, jg1.han,
wsa, linux-kernel, Luis R. Rodriguez
In-Reply-To: <1433436288-16792-4-git-send-email-mcgrof@do-not-panic.com>
[-- Attachment #1: Type: text/plain, Size: 5383 bytes --]
On 04/06/15 19:44, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> This driver uses the same area for MTRR as for the ioremap_wc(), if
> anything it just uses a smaller size in case MTRR reservation fails.
> ioremap_wc() API is already used to take advantage of architecture
> write-combining when available.
>
> Convert the driver from using the x86 specific MTRR code to
> the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
> will avoid MTRR if write-combining is available.
>
> There are a few motivations for this:
>
> a) Take advantage of PAT when available
>
> b) Help bury MTRR code away, MTRR is architecture specific and on
> x86 its replaced by PAT
>
> c) Help with the goal of eventually using _PAGE_CACHE_UC over
> _PAGE_CACHE_UC_MINUS on x86 on ioremap_nocache() (see commit
> de33c442e titled "x86 PAT: fix performance drop for glx,
> use UC minus for ioremap(), ioremap_nocache() and
> pci_mmap_page_range()")
>
> The conversion done is expressed by the following Coccinelle
> SmPL patch, it additionally required manual intervention to
> address all the #ifdery and removal of redundant things which
> arch_phys_wc_add() already addresses such as verbose message
> about when MTRR fails and doing nothing when we didn't get
> an MTRR.
>
> @ mtrr_found @
> expression index, base, size;
> @@
>
> -index = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
> +index = arch_phys_wc_add(base, size);
>
> @ mtrr_rm depends on mtrr_found @
> expression mtrr_found.index, mtrr_found.base, mtrr_found.size;
> @@
>
> -mtrr_del(index, base, size);
> +arch_phys_wc_del(index);
>
> @ mtrr_rm_zero_arg depends on mtrr_found @
> expression mtrr_found.index;
> @@
>
> -mtrr_del(index, 0, 0);
> +arch_phys_wc_del(index);
>
> @ mtrr_rm_fb_info depends on mtrr_found @
> struct fb_info *info;
> expression mtrr_found.index;
> @@
>
> -mtrr_del(index, info->fix.smem_start, info->fix.smem_len);
> +arch_phys_wc_del(index);
>
> @ ioremap_replace_nocache depends on mtrr_found @
> struct fb_info *info;
> expression base, size;
> @@
>
> -info->screen_base = ioremap_nocache(base, size);
> +info->screen_base = ioremap_wc(base, size);
>
> @ ioremap_replace_default depends on mtrr_found @
> struct fb_info *info;
> expression base, size;
> @@
>
> -info->screen_base = ioremap(base, size);
> +info->screen_base = ioremap_wc(base, size);
>
> Generated-by: Coccinelle SmPL
> Cc: Toshi Kani <toshi.kani@hp.com>
> Cc: Suresh Siddha <sbsiddha@gmail.com>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Juergen Gross <jgross@suse.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Andy Lutomirski <luto@amacapital.net>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Antonino Daplas <adaplas@gmail.com>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
> Cc: Rob Clark <robdclark@gmail.com>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: linux-fbdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> ---
> drivers/video/fbdev/vesafb.c | 29 ++++++++---------------------
> 1 file changed, 8 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/video/fbdev/vesafb.c b/drivers/video/fbdev/vesafb.c
> index 3db3908..528fe91 100644
> --- a/drivers/video/fbdev/vesafb.c
> +++ b/drivers/video/fbdev/vesafb.c
> @@ -19,10 +19,9 @@
> #include <linux/init.h>
> #include <linux/platform_device.h>
> #include <linux/screen_info.h>
> +#include <linux/io.h>
>
> #include <video/vga.h>
> -#include <asm/io.h>
> -#include <asm/mtrr.h>
>
> #define dac_reg (0x3c8)
> #define dac_val (0x3c9)
> @@ -180,16 +179,10 @@ static int vesafb_setcolreg(unsigned regno, unsigned red, unsigned green,
>
> static void vesafb_destroy(struct fb_info *info)
> {
> -#ifdef CONFIG_MTRR
> struct vesafb_par *par = info->par;
> -#endif
>
> fb_dealloc_cmap(&info->cmap);
> -
> -#ifdef CONFIG_MTRR
> - if (par->wc_cookie >= 0)
> - mtrr_del(par->wc_cookie, 0, 0);
> -#endif
> + arch_phys_wc_del(par->wc_cookie);
> if (info->screen_base)
> iounmap(info->screen_base);
> release_mem_region(info->apertures->ranges[0].base, info->apertures->ranges[0].size);
> @@ -420,7 +413,6 @@ static int vesafb_probe(struct platform_device *dev)
> request_region(0x3c0, 32, "vesafb");
>
> if (mtrr == 3) {
> -#ifdef CONFIG_MTRR
> unsigned int temp_size = size_total;
>
> /* Find the largest power-of-two */
> @@ -428,18 +420,16 @@ static int vesafb_probe(struct platform_device *dev)
>
> /* Try and find a power of two to add */
> do {
> - par->wc_cookie = mtrr_add(vesafb_fix.smem_start,
> - temp_size,
> - MTRR_TYPE_WRCOMB, 1);
> + par->wc_cookie =
> + arch_phys_wc_add(vesafb_fix.smem_start,
> + temp_size);
> temp_size >>= 1;
> - } while (temp_size >= PAGE_SIZE && par->wc_cookie == -EINVAL);
> -#endif
> + } while (temp_size >= PAGE_SIZE && par->wc_cookie < 0);
> +
Looks like arch_phys_wc_add prints a warning if it fails, and the above
loop may retry it many (?) times. Probably not a big issue, but may be
somewhat confusing.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] staging: sm750fb: fix c99 comments
From: Konrad Zapalowicz @ 2015-06-12 9:21 UTC (permalink / raw)
To: Juston Li
Cc: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, devel,
linux-kernel
In-Reply-To: <1434092837-10290-1-git-send-email-juston.h.li@gmail.com>
On 06/12, Juston Li wrote:
> fixed all checkpatch.pl ERROR: do not use C99 // comments
>
> Any C99 comments used to comment out code are simply removed.
> Also some of the errors occur inside '#if 0' blocks which I
> might as well fix since checkpatch.pl caught them but the blocks
> themselves should probably be cleaned up later.
>
> Signed-off-by: Juston Li <juston.h.li@gmail.com>
> ---
> drivers/staging/sm750fb/ddk750_chip.c | 11 ++------
> drivers/staging/sm750fb/ddk750_dvi.c | 4 +--
> drivers/staging/sm750fb/ddk750_help.c | 2 --
> drivers/staging/sm750fb/ddk750_sii164.c | 11 --------
> drivers/staging/sm750fb/sm750.h | 10 +++----
> drivers/staging/sm750fb/sm750_accel.c | 49 ++++++++++++++++-----------------
> drivers/staging/sm750fb/sm750_accel.h | 2 +-
> drivers/staging/sm750fb/sm750_cursor.c | 9 +++---
> drivers/staging/sm750fb/sm750_help.h | 28 +++----------------
> drivers/staging/sm750fb/sm750_hw.c | 4 +--
> drivers/staging/sm750fb/sm750_hw.h | 3 --
> 11 files changed, 41 insertions(+), 92 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/ddk750_chip.c b/drivers/staging/sm750fb/ddk750_chip.c
> index 8b47c1b..b2137c8 100644
> --- a/drivers/staging/sm750fb/ddk750_chip.c
> +++ b/drivers/staging/sm750fb/ddk750_chip.c
> @@ -17,7 +17,7 @@ logical_chip_type_t getChipType(void)
> char physicalRev;
> logical_chip_type_t chip;
>
> - physicalID = devId750;//either 0x718 or 0x750
> + physicalID = devId750; /* either 0x718 or 0x750 /
Does the code compile? I'm worried that the above line will produce
error as the comment block is not properly closed.
- konrad
> physicalRev = revId750;
>
> if (physicalID = 0x718)
> @@ -257,7 +257,7 @@ int ddk750_initHw(initchip_param_t *pInitParam)
>
> unsigned int ulReg;
> #if 0
> - //move the code to map regiter function.
> + /* move the code to map regiter function. */
> if (getChipType() = SM718) {
> /* turn on big endian bit*/
> ulReg = PEEK32(0x74);
> @@ -487,8 +487,6 @@ unsigned int calcPllValue(unsigned int request_orig, pll_value_t *pll)
> }
> }
> }
> -
> - //printk("Finally: pll->n[%lu],m[%lu],od[%lu],pod[%lu]\n",pll->N,pll->M,pll->OD,pll->POD);
> return ret;
> }
>
> @@ -580,14 +578,9 @@ pll_value_t *pPLL /* Structure to hold the value to be set in PLL */
> }
>
> /* Restore input frequency from Khz to hz unit */
> -// pPLL->inputFreq *= 1000;
> ulRequestClk *= 1000;
> pPLL->inputFreq = DEFAULT_INPUT_CLOCK; /* Default reference clock */
>
> - /* Output debug information */
> - //DDKDEBUGPRINT((DISPLAY_LEVEL, "calcPllValue: Requested Frequency = %d\n", ulRequestClk));
> - //DDKDEBUGPRINT((DISPLAY_LEVEL, "calcPllValue: Input CLK = %dHz, M=%d, N=%d, OD=%d, POD=%d\n", pPLL->inputFreq, pPLL->M, pPLL->N, pPLL->OD, pPLL->POD));
> -
> /* Return actual frequency that the PLL can set */
> ret = calcPLL(pPLL);
> return ret;
> diff --git a/drivers/staging/sm750fb/ddk750_dvi.c b/drivers/staging/sm750fb/ddk750_dvi.c
> index f5932bb..b2bf7e6 100644
> --- a/drivers/staging/sm750fb/ddk750_dvi.c
> +++ b/drivers/staging/sm750fb/ddk750_dvi.c
> @@ -51,7 +51,7 @@ int dviInit(
> vsyncEnable, deskewEnable, deskewSetting, continuousSyncEnable,
> pllFilterEnable, pllFilterValue);
> }
> - return -1;//error
> + return -1; /* error */
> }
>
>
> @@ -66,7 +66,6 @@ unsigned short dviGetVendorID(void)
> {
> dvi_ctrl_device_t *pCurrentDviCtrl;
>
> - //pCurrentDviCtrl = getDviCtrl();
> pCurrentDviCtrl = g_dcftSupportedDviController;
> if (pCurrentDviCtrl != (dvi_ctrl_device_t *)0)
> return pCurrentDviCtrl->pfnGetVendorId();
> @@ -86,7 +85,6 @@ unsigned short dviGetDeviceID(void)
> {
> dvi_ctrl_device_t *pCurrentDviCtrl;
>
> -// pCurrentDviCtrl = getDviCtrl();
> pCurrentDviCtrl = g_dcftSupportedDviController;
> if (pCurrentDviCtrl != (dvi_ctrl_device_t *)0)
> return pCurrentDviCtrl->pfnGetDeviceId();
> diff --git a/drivers/staging/sm750fb/ddk750_help.c b/drivers/staging/sm750fb/ddk750_help.c
> index 647004d..96c18eb 100644
> --- a/drivers/staging/sm750fb/ddk750_help.c
> +++ b/drivers/staging/sm750fb/ddk750_help.c
> @@ -1,5 +1,3 @@
> -//#include "ddk750_reg.h"
> -//#include "ddk750_chip.h"
> #include "ddk750_help.h"
>
> void __iomem * mmio750 = NULL;
> diff --git a/drivers/staging/sm750fb/ddk750_sii164.c b/drivers/staging/sm750fb/ddk750_sii164.c
> index 84464c1..b6395b8 100644
> --- a/drivers/staging/sm750fb/ddk750_sii164.c
> +++ b/drivers/staging/sm750fb/ddk750_sii164.c
> @@ -125,10 +125,7 @@ long sii164InitChip(
> unsigned char pllFilterValue
> )
> {
> - //unsigned char ucRegIndex, ucRegValue;
> - //unsigned char ucDeviceAddress,
> unsigned char config;
> - //unsigned long delayCount;
>
> /* Initialize the i2c bus */
> #ifdef USE_HW_I2C
> @@ -141,10 +138,6 @@ long sii164InitChip(
> /* Check if SII164 Chip exists */
> if ((sii164GetVendorID() = SII164_VENDOR_ID) && (sii164GetDeviceID() = SII164_DEVICE_ID))
> {
> -
> -#ifdef DDKDEBUG
> - //sii164PrintRegisterValues();
> -#endif
> /*
> * Initialize SII164 controller chip.
> */
> @@ -241,10 +234,6 @@ long sii164InitChip(
> config |= SII164_CONFIGURATION_POWER_NORMAL;
> i2cWriteReg(SII164_I2C_ADDRESS, SII164_CONFIGURATION, config);
>
> -#ifdef DDKDEBUG
> - //sii164PrintRegisterValues();
> -#endif
> -
> return 0;
> }
>
> diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
> index 30aa312..273882f 100644
> --- a/drivers/staging/sm750fb/sm750.h
> +++ b/drivers/staging/sm750fb/sm750.h
> @@ -7,8 +7,6 @@
> /* please use revision id to distinguish sm750le and sm750*/
> #define SPC_SM750 0
>
> -//#define SPC_SM750LE 8
> -
> #define MB(x) ((x)<<20)
> #define MHZ(x) ((x) * 1000000)
> /* align should be 2,4,8,16 */
> @@ -95,10 +93,10 @@ struct lynx_cursor{
> };
>
> struct lynxfb_crtc{
> - unsigned char __iomem * vCursor;//virtual address of cursor
> - unsigned char __iomem * vScreen;//virtual address of on_screen
> - int oCursor;//cursor address offset in vidmem
> - int oScreen;//onscreen address offset in vidmem
> + unsigned char __iomem * vCursor; /* virtual address of cursor */
> + unsigned char __iomem * vScreen; /* virtual address of on_screen */
> + int oCursor; /* cursor address offset in vidmem */
> + int oScreen; /* onscreen address offset in vidmem */
> int channel;/* which channel this crtc stands for*/
> resource_size_t vidmem_size;/* this view's video memory max size */
>
> diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
> index 001e980..a2baffd 100644
> --- a/drivers/staging/sm750fb/sm750_accel.c
> +++ b/drivers/staging/sm750fb/sm750_accel.c
> @@ -57,10 +57,10 @@ void hw_de_init(struct lynx_accel * accel)
> write_dpr(accel, DE_STRETCH_FORMAT, (read_dpr(accel, DE_STRETCH_FORMAT) & clr) | reg);
>
> /* disable clipping and transparent */
> - write_dpr(accel, DE_CLIP_TL, 0);//dpr2c
> - write_dpr(accel, DE_CLIP_BR, 0);//dpr30
> + write_dpr(accel, DE_CLIP_TL, 0); /* dpr2c */
> + write_dpr(accel, DE_CLIP_BR, 0); /* dpr30 */
>
> - write_dpr(accel, DE_COLOR_COMPARE_MASK, 0);//dpr24
> + write_dpr(accel, DE_COLOR_COMPARE_MASK, 0); /* dpr24 */
> write_dpr(accel, DE_COLOR_COMPARE, 0);
>
> reg = FIELD_SET(0, DE_CONTROL, TRANSPARENCY, DISABLE)|
> @@ -104,25 +104,25 @@ int hw_fillrect(struct lynx_accel * accel,
> return -1;
> }
>
> - write_dpr(accel, DE_WINDOW_DESTINATION_BASE, base);//dpr40
> + write_dpr(accel, DE_WINDOW_DESTINATION_BASE, base); /* dpr40 */
> write_dpr(accel, DE_PITCH,
> FIELD_VALUE(0, DE_PITCH, DESTINATION, pitch/Bpp)|
> - FIELD_VALUE(0, DE_PITCH, SOURCE, pitch/Bpp));//dpr10
> + FIELD_VALUE(0, DE_PITCH, SOURCE, pitch/Bpp)); /* dpr10 */
>
> write_dpr(accel, DE_WINDOW_WIDTH,
> FIELD_VALUE(0, DE_WINDOW_WIDTH, DESTINATION, pitch/Bpp)|
> - FIELD_VALUE(0, DE_WINDOW_WIDTH, SOURCE, pitch/Bpp));//dpr44
> + FIELD_VALUE(0, DE_WINDOW_WIDTH, SOURCE, pitch/Bpp)); /* dpr44 */
>
> - write_dpr(accel, DE_FOREGROUND, color);//DPR14
> + write_dpr(accel, DE_FOREGROUND, color); /* DPR14 */
>
> write_dpr(accel, DE_DESTINATION,
> FIELD_SET(0, DE_DESTINATION, WRAP, DISABLE)|
> FIELD_VALUE(0, DE_DESTINATION, X, x)|
> - FIELD_VALUE(0, DE_DESTINATION, Y, y));//dpr4
> + FIELD_VALUE(0, DE_DESTINATION, Y, y)); /* dpr4 */
>
> write_dpr(accel, DE_DIMENSION,
> FIELD_VALUE(0, DE_DIMENSION, X, width)|
> - FIELD_VALUE(0, DE_DIMENSION, Y_ET, height));//dpr8
> + FIELD_VALUE(0, DE_DIMENSION, Y_ET, height)); /* dpr8 */
>
> deCtrl > FIELD_SET(0, DE_CONTROL, STATUS, START)|
> @@ -130,7 +130,7 @@ int hw_fillrect(struct lynx_accel * accel,
> FIELD_SET(0, DE_CONTROL, LAST_PIXEL, ON)|
> FIELD_SET(0, DE_CONTROL, COMMAND, RECTANGLE_FILL)|
> FIELD_SET(0, DE_CONTROL, ROP_SELECT, ROP2)|
> - FIELD_VALUE(0, DE_CONTROL, ROP, rop);//dpr0xc
> + FIELD_VALUE(0, DE_CONTROL, ROP, rop); /* dpr0xc */
>
> write_dpr(accel, DE_CONTROL, deCtrl);
> return 0;
> @@ -236,12 +236,12 @@ unsigned int rop2) /* ROP value */
> /* 2D Source Base.
> It is an address offset (128 bit aligned) from the beginning of frame buffer.
> */
> - write_dpr(accel, DE_WINDOW_SOURCE_BASE, sBase);//dpr40
> + write_dpr(accel, DE_WINDOW_SOURCE_BASE, sBase); /* dpr40 */
>
> /* 2D Destination Base.
> It is an address offset (128 bit aligned) from the beginning of frame buffer.
> */
> - write_dpr(accel, DE_WINDOW_DESTINATION_BASE, dBase);//dpr44
> + write_dpr(accel, DE_WINDOW_DESTINATION_BASE, dBase); /* dpr44 */
>
> #if 0
> /* Program pitch (distance between the 1st points of two adjacent lines).
> @@ -254,14 +254,14 @@ unsigned int rop2) /* ROP value */
> width *= 3;
> write_dpr(accel, DE_PITCH,
> FIELD_VALUE(0, DE_PITCH, DESTINATION, dPitch) |
> - FIELD_VALUE(0, DE_PITCH, SOURCE, sPitch));//dpr10
> + FIELD_VALUE(0, DE_PITCH, SOURCE, sPitch)); /* dpr10 */
> }
> else
> #endif
> {
> write_dpr(accel, DE_PITCH,
> FIELD_VALUE(0, DE_PITCH, DESTINATION, (dPitch/Bpp)) |
> - FIELD_VALUE(0, DE_PITCH, SOURCE, (sPitch/Bpp)));//dpr10
> + FIELD_VALUE(0, DE_PITCH, SOURCE, (sPitch/Bpp))); /* dpr10 */
> }
>
> /* Screen Window width in Pixels.
> @@ -269,7 +269,7 @@ unsigned int rop2) /* ROP value */
> */
> write_dpr(accel, DE_WINDOW_WIDTH,
> FIELD_VALUE(0, DE_WINDOW_WIDTH, DESTINATION, (dPitch/Bpp)) |
> - FIELD_VALUE(0, DE_WINDOW_WIDTH, SOURCE, (sPitch/Bpp)));//dpr3c
> + FIELD_VALUE(0, DE_WINDOW_WIDTH, SOURCE, (sPitch/Bpp))); /* dpr3c */
>
> if (accel->de_wait() != 0){
> return -1;
> @@ -280,14 +280,14 @@ unsigned int rop2) /* ROP value */
> write_dpr(accel, DE_SOURCE,
> FIELD_SET (0, DE_SOURCE, WRAP, DISABLE) |
> FIELD_VALUE(0, DE_SOURCE, X_K1, sx) |
> - FIELD_VALUE(0, DE_SOURCE, Y_K2, sy));//dpr0
> + FIELD_VALUE(0, DE_SOURCE, Y_K2, sy)); /* dpr0 */
> write_dpr(accel, DE_DESTINATION,
> FIELD_SET (0, DE_DESTINATION, WRAP, DISABLE) |
> FIELD_VALUE(0, DE_DESTINATION, X, dx) |
> - FIELD_VALUE(0, DE_DESTINATION, Y, dy));//dpr04
> + FIELD_VALUE(0, DE_DESTINATION, Y, dy)); /* dpr04 */
> write_dpr(accel, DE_DIMENSION,
> FIELD_VALUE(0, DE_DIMENSION, X, width) |
> - FIELD_VALUE(0, DE_DIMENSION, Y_ET, height));//dpr08
> + FIELD_VALUE(0, DE_DIMENSION, Y_ET, height)); /* dpr08 */
>
> de_ctrl > FIELD_VALUE(0, DE_CONTROL, ROP, rop2) |
> @@ -297,7 +297,7 @@ unsigned int rop2) /* ROP value */
> FIELD_SET(0, DE_CONTROL, DIRECTION, RIGHT_TO_LEFT)
> : FIELD_SET(0, DE_CONTROL, DIRECTION, LEFT_TO_RIGHT)) |
> FIELD_SET(0, DE_CONTROL, STATUS, START);
> - write_dpr(accel, DE_CONTROL, de_ctrl);//dpr0c
> + write_dpr(accel, DE_CONTROL, de_ctrl); /* dpr0c */
> }
>
> return 0;
> @@ -346,7 +346,6 @@ int hw_imageblit(struct lynx_accel *accel,
>
> if(accel->de_wait() != 0)
> {
> -// inf_msg("*** ImageBlit return -1 ***\n");
> return -1;
> }
>
> @@ -370,7 +369,7 @@ int hw_imageblit(struct lynx_accel *accel,
> startBit *= 3;
> write_dpr(accel, DE_PITCH,
> FIELD_VALUE(0, DE_PITCH, DESTINATION, dPitch) |
> - FIELD_VALUE(0, DE_PITCH, SOURCE, dPitch));//dpr10
> + FIELD_VALUE(0, DE_PITCH, SOURCE, dPitch)); /* dpr10 */
>
> }
> else
> @@ -378,7 +377,7 @@ int hw_imageblit(struct lynx_accel *accel,
> {
> write_dpr(accel, DE_PITCH,
> FIELD_VALUE(0, DE_PITCH, DESTINATION, dPitch/bytePerPixel) |
> - FIELD_VALUE(0, DE_PITCH, SOURCE, dPitch/bytePerPixel));//dpr10
> + FIELD_VALUE(0, DE_PITCH, SOURCE, dPitch/bytePerPixel)); /* dpr10 */
> }
>
> /* Screen Window width in Pixels.
> @@ -392,16 +391,16 @@ int hw_imageblit(struct lynx_accel *accel,
> For mono bitmap, use startBit for X_K1. */
> write_dpr(accel, DE_SOURCE,
> FIELD_SET (0, DE_SOURCE, WRAP, DISABLE) |
> - FIELD_VALUE(0, DE_SOURCE, X_K1_MONO, startBit));//dpr00
> + FIELD_VALUE(0, DE_SOURCE, X_K1_MONO, startBit)); /* dpr00 */
>
> write_dpr(accel, DE_DESTINATION,
> FIELD_SET (0, DE_DESTINATION, WRAP, DISABLE) |
> FIELD_VALUE(0, DE_DESTINATION, X, dx) |
> - FIELD_VALUE(0, DE_DESTINATION, Y, dy));//dpr04
> + FIELD_VALUE(0, DE_DESTINATION, Y, dy)); /* dpr04 */
>
> write_dpr(accel, DE_DIMENSION,
> FIELD_VALUE(0, DE_DIMENSION, X, width) |
> - FIELD_VALUE(0, DE_DIMENSION, Y_ET, height));//dpr08
> + FIELD_VALUE(0, DE_DIMENSION, Y_ET, height)); /* dpr08 */
>
> write_dpr(accel, DE_FOREGROUND, fColor);
> write_dpr(accel, DE_BACKGROUND, bColor);
> diff --git a/drivers/staging/sm750fb/sm750_accel.h b/drivers/staging/sm750fb/sm750_accel.h
> index e9d217b..57e20fb 100644
> --- a/drivers/staging/sm750fb/sm750_accel.h
> +++ b/drivers/staging/sm750fb/sm750_accel.h
> @@ -113,7 +113,7 @@
> #define DE_CONTROL_TRANSPARENCY_ENABLE 1
> #define DE_CONTROL_ROP 7:0
>
> -// Pseudo fields.
> +/* Pseudo fields. */
>
> #define DE_CONTROL_SHORT_STROKE_DIR 27:24
> #define DE_CONTROL_SHORT_STROKE_DIR_225 0
> diff --git a/drivers/staging/sm750fb/sm750_cursor.c b/drivers/staging/sm750fb/sm750_cursor.c
> index b145285..cb37ea3 100644
> --- a/drivers/staging/sm750fb/sm750_cursor.c
> +++ b/drivers/staging/sm750fb/sm750_cursor.c
> @@ -141,10 +141,10 @@ void hw_cursor_setData(struct lynx_cursor * cursor,
> {
>
> if(opr & (0x80 >> j))
> - { //use fg color,id = 2
> + { /* use fg color,id = 2 */
> data |= 2 << (j*2);
> }else{
> - //use bg color,id = 1
> + /* use bg color,id = 1 */
> data |= 1 << (j*2);
> }
> }
> @@ -221,10 +221,10 @@ void hw_cursor_setData2(struct lynx_cursor * cursor,
> {
>
> if(opr & (0x80 >> j))
> - { //use fg color,id = 2
> + { /* use fg color,id = 2 */
> data |= 2 << (j*2);
> }else{
> - //use bg color,id = 1
> + /* use bg color,id = 1 */
> data |= 1 << (j*2);
> }
> }
> @@ -238,7 +238,6 @@ void hw_cursor_setData2(struct lynx_cursor * cursor,
>
> /* assume pitch is 1,2,4,8,...*/
> if(!(i&(pitch-1)))
> - //if((i+1) % pitch = 0)
> {
> /* need a return */
> pstart += offset;
> diff --git a/drivers/staging/sm750fb/sm750_help.h b/drivers/staging/sm750fb/sm750_help.h
> index ebc946c..05777f7 100644
> --- a/drivers/staging/sm750fb/sm750_help.h
> +++ b/drivers/staging/sm750fb/sm750_help.h
> @@ -1,9 +1,7 @@
> #ifndef LYNX_HELP_H__
> #define LYNX_HELP_H__
> -/*****************************************************************************\
> - * FIELD MACROS *
> -\*****************************************************************************/
>
> +/* FIELD MACROS */
> #define _LSB(f) (0 ? f)
> #define _MSB(f) (1 ? f)
> #define _COUNT(f) (_MSB(f) - _LSB(f) + 1)
> @@ -17,13 +15,7 @@
> #define SET_FIELDV(d, f, v) (((d) & ~GET_MASK(f)) | \
> (((v) & RAW_MASK(f)) << _LSB(f)))
>
> -
> -////////////////////////////////////////////////////////////////////////////////
> -// //
> -// Internal macros //
> -// //
> -////////////////////////////////////////////////////////////////////////////////
> -
> +/* Internal macros */
> #define _F_START(f) (0 ? f)
> #define _F_END(f) (1 ? f)
> #define _F_SIZE(f) (1 + _F_END(f) - _F_START(f))
> @@ -31,13 +23,7 @@
> #define _F_NORMALIZE(v, f) (((v) & _F_MASK(f)) >> _F_START(f))
> #define _F_DENORMALIZE(v, f) (((v) << _F_START(f)) & _F_MASK(f))
>
> -
> -////////////////////////////////////////////////////////////////////////////////
> -// //
> -// Global macros //
> -// //
> -////////////////////////////////////////////////////////////////////////////////
> -
> +/* Global macros */
> #define FIELD_GET(x, reg, field) \
> ( \
> _F_NORMALIZE((x), reg ## _ ## field) \
> @@ -60,13 +46,7 @@
> ~ _F_MASK(reg ## _ ## field) \
> )
>
> -
> -////////////////////////////////////////////////////////////////////////////////
> -// //
> -// Field Macros //
> -// //
> -////////////////////////////////////////////////////////////////////////////////
> -
> +/* Field Macros */
> #define FIELD_START(field) (0 ? field)
> #define FIELD_END(field) (1 ? field)
> #define FIELD_SIZE(field) (1 + FIELD_END(field) - FIELD_START(field))
> diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
> index 131125c..e70961e 100644
> --- a/drivers/staging/sm750fb/sm750_hw.c
> +++ b/drivers/staging/sm750fb/sm750_hw.c
> @@ -193,7 +193,6 @@ int hw_sm750_inithw(struct lynx_share* share, struct pci_dev * pdev)
> /* init 2d engine */
> if(!share->accel_off){
> hw_sm750_initAccel(share);
> -// share->accel.de_wait = hw_sm750_deWait;
> }
>
> return 0;
> @@ -328,7 +327,6 @@ int hw_sm750_crtc_setMode(struct lynxfb_crtc* crtc,
> #endif
>
> /* set timing */
> -// modparm.pixel_clock = PS_TO_HZ(var->pixclock);
> modparm.pixel_clock = ps_to_hz(var->pixclock);
> modparm.vertical_sync_polarity = (var->sync & FB_SYNC_HOR_HIGH_ACT) ? POS:NEG;
> modparm.horizontal_sync_polarity = (var->sync & FB_SYNC_VERT_HIGH_ACT) ? POS:NEG;
> @@ -618,7 +616,7 @@ int hw_sm750_pan_display(struct lynxfb_crtc *crtc,
> const struct fb_info *info)
> {
> uint32_t total;
> - //check params
> + /* check params */
> if ((var->xoffset + var->xres > var->xres_virtual) ||
> (var->yoffset + var->yres > var->yres_virtual)) {
> return -EINVAL;
> diff --git a/drivers/staging/sm750fb/sm750_hw.h b/drivers/staging/sm750fb/sm750_hw.h
> index 4fee28d..93288b3 100644
> --- a/drivers/staging/sm750fb/sm750_hw.h
> +++ b/drivers/staging/sm750fb/sm750_hw.h
> @@ -8,9 +8,6 @@
> #define SM750LE_REVISION_ID (unsigned char)0xfe
> #endif
>
> -//#define DEFAULT_MEM_CLOCK (DEFAULT_SM750_CHIP_CLOCK/1)
> -//#define DEFAULT_MASTER_CLOCK (DEFAULT_SM750_CHIP_CLOCK/3)
> -
>
> enum sm750_pnltype{
>
> --
> 2.4.3
>
> _______________________________________________
> devel mailing list
> devel@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
^ permalink raw reply
* Re: [PATCH] video: sm501fb: fixing static checker warning
From: Tomi Valkeinen @ 2015-06-12 9:34 UTC (permalink / raw)
To: Heiko Schocher, linux-fbdev
Cc: devicetree, Rasmus Villemoes, linux-kernel, Grant Likely,
Rob Herring, Jean-Christophe Plagniol-Villard, Andrew Morton
In-Reply-To: <1434028393-32224-1-git-send-email-hs@denx.de>
[-- Attachment #1: Type: text/plain, Size: 1737 bytes --]
On 11/06/15 16:13, Heiko Schocher wrote:
> Dan Carpenter reported the static checker warning:
>
> drivers/video/fbdev/sm501fb.c:1958 sm501fb_probe()
> warn: strcpy() 'cp' of unknown size might be too large for 'fb_mode'
>
> Fix it, as the SM501 datasheet says the SM501 can "200 MHz
> DAC support 1280x1024 resolution", which would result in a
> too long mode string for current fb_mode var.
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Heiko Schocher <hs@denx.de>
> ---
>
> drivers/video/fbdev/sm501fb.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/sm501fb.c b/drivers/video/fbdev/sm501fb.c
> index 9e74e8f..ea50df3 100644
> --- a/drivers/video/fbdev/sm501fb.c
> +++ b/drivers/video/fbdev/sm501fb.c
> @@ -43,7 +43,9 @@
>
> #include "edid.h"
>
> -static char *fb_mode = "640x480-16@60";
> +static char *fb_default_mode = "640x480-16@60";
> +static char fb_mode[20];
> +static char *fb_mode_cmdline;
> static unsigned long default_bpp = 16;
>
> static struct fb_videomode sm501_default_mode = {
> @@ -1963,6 +1965,12 @@ static int sm501fb_probe(struct platform_device *pdev)
> if (info->edid_data)
> found = 1;
> }
> + } else {
> + if (fb_mode_cmdline)
> + strncpy(fb_mode, fb_mode_cmdline,
> + sizeof(fb_mode) - 1);
> + else
> + strcpy(fb_mode, fb_default_mode);
> }
> #endif
I didn't look at this very closely, but it doesn't look correct to me.
The above code will only be ran if !np. Shouldn't the kernel cmdline
parameter override anything from the .dts?
Then again, that's how it works at the moment, so I guess this is ok.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] drivers/video/fbdev/sis/sis_main.c: avoid repeated strlen() calls
From: Tomi Valkeinen @ 2015-06-12 9:36 UTC (permalink / raw)
To: Rasmus Villemoes, Thomas Winischhofer,
Jean-Christophe Plagniol-Villard
Cc: linux-fbdev, linux-kernel
In-Reply-To: <1433855066-20260-1-git-send-email-linux@rasmusvillemoes.dk>
[-- Attachment #1: Type: text/plain, Size: 374 bytes --]
On 09/06/15 16:04, Rasmus Villemoes wrote:
> gcc is not smart enough to realize that strlen(strbuf1) cannot be
> changed by the loop body, so it is forced to recompute it, at least in
> the branch containing the assignment. Avoid this by using an
> equivalent stopping condition.
Does it matter? Is sisfb calling sisfb_search_mode thousands of times?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: omap2: remove potential format string leak
From: Tomi Valkeinen @ 2015-06-12 9:38 UTC (permalink / raw)
To: Kees Cook, linux-kernel
Cc: Jean-Christophe Plagniol-Villard, linux-omap, linux-fbdev
In-Reply-To: <20150608223053.GA28939@www.outflux.net>
[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]
On 09/06/15 01:30, Kees Cook wrote:
> Since kobject_init_and_add takes a format string, make sure that the
> passed in name cannot be accidentally parsed.
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> drivers/video/fbdev/omap2/dss/display-sysfs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/omap2/dss/display-sysfs.c b/drivers/video/fbdev/omap2/dss/display-sysfs.c
> index 12186557a9d4..6ad0991f8259 100644
> --- a/drivers/video/fbdev/omap2/dss/display-sysfs.c
> +++ b/drivers/video/fbdev/omap2/dss/display-sysfs.c
> @@ -324,7 +324,7 @@ int display_init_sysfs(struct platform_device *pdev)
>
> for_each_dss_dev(dssdev) {
> r = kobject_init_and_add(&dssdev->kobj, &display_ktype,
> - &pdev->dev.kobj, dssdev->alias);
> + &pdev->dev.kobj, "%s", dssdev->alias);
> if (r) {
> DSSERR("failed to create sysfs files\n");
> omap_dss_put_device(dssdev);
>
Thanks, queued for 4.2.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] staging: sm750fb: fix c99 comments
From: Juston Li @ 2015-06-12 10:08 UTC (permalink / raw)
To: Konrad Zapalowicz
Cc: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, devel,
linux-kernel
In-Reply-To: <20150612092103.GB18158@patagonia>
On Fri, Jun 12, 2015 at 2:21 AM, Konrad Zapalowicz
<bergo.torino@gmail.com> wrote:
>> diff --git a/drivers/staging/sm750fb/ddk750_chip.c b/drivers/staging/sm750fb/ddk750_chip.c
>> index 8b47c1b..b2137c8 100644
>> --- a/drivers/staging/sm750fb/ddk750_chip.c
>> +++ b/drivers/staging/sm750fb/ddk750_chip.c
>> @@ -17,7 +17,7 @@ logical_chip_type_t getChipType(void)
>> char physicalRev;
>> logical_chip_type_t chip;
>>
>> - physicalID = devId750;//either 0x718 or 0x750
>> + physicalID = devId750; /* either 0x718 or 0x750 /
>
> Does the code compile? I'm worried that the above line will produce
> error as the comment block is not properly closed.
>
> - konrad
Good catch, can't believe I missed that. I'll fix, actually test compile
this time and resend.
Regards
Juston
^ permalink raw reply
* [PATCH v2] staging: sm750fb: fix c99 comments
From: Juston Li @ 2015-06-12 10:17 UTC (permalink / raw)
To: sudipm.mukherjee, teddy.wang, gregkh, linux-fbdev, devel,
linux-kernel, bergo.torino
Cc: Juston Li
fixed all checkpatch.pl ERROR: do not use C99 // comments
Any C99 comments used to comment out code are simply removed.
Also some of the errors occur inside '#if 0' blocks which I
might as well fix since checkpatch.pl caught them but the blocks
themselves should probably be cleaned up later.
Changes since v1: close a comment block
Signed-off-by: Juston Li <juston.h.li@gmail.com>
---
drivers/staging/sm750fb/ddk750_chip.c | 11 ++------
drivers/staging/sm750fb/ddk750_dvi.c | 4 +--
drivers/staging/sm750fb/ddk750_help.c | 2 --
drivers/staging/sm750fb/ddk750_sii164.c | 11 --------
drivers/staging/sm750fb/sm750.h | 10 +++----
drivers/staging/sm750fb/sm750_accel.c | 49 ++++++++++++++++-----------------
drivers/staging/sm750fb/sm750_accel.h | 2 +-
drivers/staging/sm750fb/sm750_cursor.c | 9 +++---
drivers/staging/sm750fb/sm750_help.h | 28 +++----------------
drivers/staging/sm750fb/sm750_hw.c | 4 +--
drivers/staging/sm750fb/sm750_hw.h | 3 --
11 files changed, 41 insertions(+), 92 deletions(-)
diff --git a/drivers/staging/sm750fb/ddk750_chip.c b/drivers/staging/sm750fb/ddk750_chip.c
index 8b47c1b..981736f 100644
--- a/drivers/staging/sm750fb/ddk750_chip.c
+++ b/drivers/staging/sm750fb/ddk750_chip.c
@@ -17,7 +17,7 @@ logical_chip_type_t getChipType(void)
char physicalRev;
logical_chip_type_t chip;
- physicalID = devId750;//either 0x718 or 0x750
+ physicalID = devId750; /* either 0x718 or 0x750 */
physicalRev = revId750;
if (physicalID = 0x718)
@@ -257,7 +257,7 @@ int ddk750_initHw(initchip_param_t *pInitParam)
unsigned int ulReg;
#if 0
- //move the code to map regiter function.
+ /* move the code to map regiter function. */
if (getChipType() = SM718) {
/* turn on big endian bit*/
ulReg = PEEK32(0x74);
@@ -487,8 +487,6 @@ unsigned int calcPllValue(unsigned int request_orig, pll_value_t *pll)
}
}
}
-
- //printk("Finally: pll->n[%lu],m[%lu],od[%lu],pod[%lu]\n",pll->N,pll->M,pll->OD,pll->POD);
return ret;
}
@@ -580,14 +578,9 @@ pll_value_t *pPLL /* Structure to hold the value to be set in PLL */
}
/* Restore input frequency from Khz to hz unit */
-// pPLL->inputFreq *= 1000;
ulRequestClk *= 1000;
pPLL->inputFreq = DEFAULT_INPUT_CLOCK; /* Default reference clock */
- /* Output debug information */
- //DDKDEBUGPRINT((DISPLAY_LEVEL, "calcPllValue: Requested Frequency = %d\n", ulRequestClk));
- //DDKDEBUGPRINT((DISPLAY_LEVEL, "calcPllValue: Input CLK = %dHz, M=%d, N=%d, OD=%d, POD=%d\n", pPLL->inputFreq, pPLL->M, pPLL->N, pPLL->OD, pPLL->POD));
-
/* Return actual frequency that the PLL can set */
ret = calcPLL(pPLL);
return ret;
diff --git a/drivers/staging/sm750fb/ddk750_dvi.c b/drivers/staging/sm750fb/ddk750_dvi.c
index f5932bb..b2bf7e6 100644
--- a/drivers/staging/sm750fb/ddk750_dvi.c
+++ b/drivers/staging/sm750fb/ddk750_dvi.c
@@ -51,7 +51,7 @@ int dviInit(
vsyncEnable, deskewEnable, deskewSetting, continuousSyncEnable,
pllFilterEnable, pllFilterValue);
}
- return -1;//error
+ return -1; /* error */
}
@@ -66,7 +66,6 @@ unsigned short dviGetVendorID(void)
{
dvi_ctrl_device_t *pCurrentDviCtrl;
- //pCurrentDviCtrl = getDviCtrl();
pCurrentDviCtrl = g_dcftSupportedDviController;
if (pCurrentDviCtrl != (dvi_ctrl_device_t *)0)
return pCurrentDviCtrl->pfnGetVendorId();
@@ -86,7 +85,6 @@ unsigned short dviGetDeviceID(void)
{
dvi_ctrl_device_t *pCurrentDviCtrl;
-// pCurrentDviCtrl = getDviCtrl();
pCurrentDviCtrl = g_dcftSupportedDviController;
if (pCurrentDviCtrl != (dvi_ctrl_device_t *)0)
return pCurrentDviCtrl->pfnGetDeviceId();
diff --git a/drivers/staging/sm750fb/ddk750_help.c b/drivers/staging/sm750fb/ddk750_help.c
index 647004d..96c18eb 100644
--- a/drivers/staging/sm750fb/ddk750_help.c
+++ b/drivers/staging/sm750fb/ddk750_help.c
@@ -1,5 +1,3 @@
-//#include "ddk750_reg.h"
-//#include "ddk750_chip.h"
#include "ddk750_help.h"
void __iomem * mmio750 = NULL;
diff --git a/drivers/staging/sm750fb/ddk750_sii164.c b/drivers/staging/sm750fb/ddk750_sii164.c
index 84464c1..b6395b8 100644
--- a/drivers/staging/sm750fb/ddk750_sii164.c
+++ b/drivers/staging/sm750fb/ddk750_sii164.c
@@ -125,10 +125,7 @@ long sii164InitChip(
unsigned char pllFilterValue
)
{
- //unsigned char ucRegIndex, ucRegValue;
- //unsigned char ucDeviceAddress,
unsigned char config;
- //unsigned long delayCount;
/* Initialize the i2c bus */
#ifdef USE_HW_I2C
@@ -141,10 +138,6 @@ long sii164InitChip(
/* Check if SII164 Chip exists */
if ((sii164GetVendorID() = SII164_VENDOR_ID) && (sii164GetDeviceID() = SII164_DEVICE_ID))
{
-
-#ifdef DDKDEBUG
- //sii164PrintRegisterValues();
-#endif
/*
* Initialize SII164 controller chip.
*/
@@ -241,10 +234,6 @@ long sii164InitChip(
config |= SII164_CONFIGURATION_POWER_NORMAL;
i2cWriteReg(SII164_I2C_ADDRESS, SII164_CONFIGURATION, config);
-#ifdef DDKDEBUG
- //sii164PrintRegisterValues();
-#endif
-
return 0;
}
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index 30aa312..273882f 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -7,8 +7,6 @@
/* please use revision id to distinguish sm750le and sm750*/
#define SPC_SM750 0
-//#define SPC_SM750LE 8
-
#define MB(x) ((x)<<20)
#define MHZ(x) ((x) * 1000000)
/* align should be 2,4,8,16 */
@@ -95,10 +93,10 @@ struct lynx_cursor{
};
struct lynxfb_crtc{
- unsigned char __iomem * vCursor;//virtual address of cursor
- unsigned char __iomem * vScreen;//virtual address of on_screen
- int oCursor;//cursor address offset in vidmem
- int oScreen;//onscreen address offset in vidmem
+ unsigned char __iomem * vCursor; /* virtual address of cursor */
+ unsigned char __iomem * vScreen; /* virtual address of on_screen */
+ int oCursor; /* cursor address offset in vidmem */
+ int oScreen; /* onscreen address offset in vidmem */
int channel;/* which channel this crtc stands for*/
resource_size_t vidmem_size;/* this view's video memory max size */
diff --git a/drivers/staging/sm750fb/sm750_accel.c b/drivers/staging/sm750fb/sm750_accel.c
index 001e980..a2baffd 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -57,10 +57,10 @@ void hw_de_init(struct lynx_accel * accel)
write_dpr(accel, DE_STRETCH_FORMAT, (read_dpr(accel, DE_STRETCH_FORMAT) & clr) | reg);
/* disable clipping and transparent */
- write_dpr(accel, DE_CLIP_TL, 0);//dpr2c
- write_dpr(accel, DE_CLIP_BR, 0);//dpr30
+ write_dpr(accel, DE_CLIP_TL, 0); /* dpr2c */
+ write_dpr(accel, DE_CLIP_BR, 0); /* dpr30 */
- write_dpr(accel, DE_COLOR_COMPARE_MASK, 0);//dpr24
+ write_dpr(accel, DE_COLOR_COMPARE_MASK, 0); /* dpr24 */
write_dpr(accel, DE_COLOR_COMPARE, 0);
reg = FIELD_SET(0, DE_CONTROL, TRANSPARENCY, DISABLE)|
@@ -104,25 +104,25 @@ int hw_fillrect(struct lynx_accel * accel,
return -1;
}
- write_dpr(accel, DE_WINDOW_DESTINATION_BASE, base);//dpr40
+ write_dpr(accel, DE_WINDOW_DESTINATION_BASE, base); /* dpr40 */
write_dpr(accel, DE_PITCH,
FIELD_VALUE(0, DE_PITCH, DESTINATION, pitch/Bpp)|
- FIELD_VALUE(0, DE_PITCH, SOURCE, pitch/Bpp));//dpr10
+ FIELD_VALUE(0, DE_PITCH, SOURCE, pitch/Bpp)); /* dpr10 */
write_dpr(accel, DE_WINDOW_WIDTH,
FIELD_VALUE(0, DE_WINDOW_WIDTH, DESTINATION, pitch/Bpp)|
- FIELD_VALUE(0, DE_WINDOW_WIDTH, SOURCE, pitch/Bpp));//dpr44
+ FIELD_VALUE(0, DE_WINDOW_WIDTH, SOURCE, pitch/Bpp)); /* dpr44 */
- write_dpr(accel, DE_FOREGROUND, color);//DPR14
+ write_dpr(accel, DE_FOREGROUND, color); /* DPR14 */
write_dpr(accel, DE_DESTINATION,
FIELD_SET(0, DE_DESTINATION, WRAP, DISABLE)|
FIELD_VALUE(0, DE_DESTINATION, X, x)|
- FIELD_VALUE(0, DE_DESTINATION, Y, y));//dpr4
+ FIELD_VALUE(0, DE_DESTINATION, Y, y)); /* dpr4 */
write_dpr(accel, DE_DIMENSION,
FIELD_VALUE(0, DE_DIMENSION, X, width)|
- FIELD_VALUE(0, DE_DIMENSION, Y_ET, height));//dpr8
+ FIELD_VALUE(0, DE_DIMENSION, Y_ET, height)); /* dpr8 */
deCtrl FIELD_SET(0, DE_CONTROL, STATUS, START)|
@@ -130,7 +130,7 @@ int hw_fillrect(struct lynx_accel * accel,
FIELD_SET(0, DE_CONTROL, LAST_PIXEL, ON)|
FIELD_SET(0, DE_CONTROL, COMMAND, RECTANGLE_FILL)|
FIELD_SET(0, DE_CONTROL, ROP_SELECT, ROP2)|
- FIELD_VALUE(0, DE_CONTROL, ROP, rop);//dpr0xc
+ FIELD_VALUE(0, DE_CONTROL, ROP, rop); /* dpr0xc */
write_dpr(accel, DE_CONTROL, deCtrl);
return 0;
@@ -236,12 +236,12 @@ unsigned int rop2) /* ROP value */
/* 2D Source Base.
It is an address offset (128 bit aligned) from the beginning of frame buffer.
*/
- write_dpr(accel, DE_WINDOW_SOURCE_BASE, sBase);//dpr40
+ write_dpr(accel, DE_WINDOW_SOURCE_BASE, sBase); /* dpr40 */
/* 2D Destination Base.
It is an address offset (128 bit aligned) from the beginning of frame buffer.
*/
- write_dpr(accel, DE_WINDOW_DESTINATION_BASE, dBase);//dpr44
+ write_dpr(accel, DE_WINDOW_DESTINATION_BASE, dBase); /* dpr44 */
#if 0
/* Program pitch (distance between the 1st points of two adjacent lines).
@@ -254,14 +254,14 @@ unsigned int rop2) /* ROP value */
width *= 3;
write_dpr(accel, DE_PITCH,
FIELD_VALUE(0, DE_PITCH, DESTINATION, dPitch) |
- FIELD_VALUE(0, DE_PITCH, SOURCE, sPitch));//dpr10
+ FIELD_VALUE(0, DE_PITCH, SOURCE, sPitch)); /* dpr10 */
}
else
#endif
{
write_dpr(accel, DE_PITCH,
FIELD_VALUE(0, DE_PITCH, DESTINATION, (dPitch/Bpp)) |
- FIELD_VALUE(0, DE_PITCH, SOURCE, (sPitch/Bpp)));//dpr10
+ FIELD_VALUE(0, DE_PITCH, SOURCE, (sPitch/Bpp))); /* dpr10 */
}
/* Screen Window width in Pixels.
@@ -269,7 +269,7 @@ unsigned int rop2) /* ROP value */
*/
write_dpr(accel, DE_WINDOW_WIDTH,
FIELD_VALUE(0, DE_WINDOW_WIDTH, DESTINATION, (dPitch/Bpp)) |
- FIELD_VALUE(0, DE_WINDOW_WIDTH, SOURCE, (sPitch/Bpp)));//dpr3c
+ FIELD_VALUE(0, DE_WINDOW_WIDTH, SOURCE, (sPitch/Bpp))); /* dpr3c */
if (accel->de_wait() != 0){
return -1;
@@ -280,14 +280,14 @@ unsigned int rop2) /* ROP value */
write_dpr(accel, DE_SOURCE,
FIELD_SET (0, DE_SOURCE, WRAP, DISABLE) |
FIELD_VALUE(0, DE_SOURCE, X_K1, sx) |
- FIELD_VALUE(0, DE_SOURCE, Y_K2, sy));//dpr0
+ FIELD_VALUE(0, DE_SOURCE, Y_K2, sy)); /* dpr0 */
write_dpr(accel, DE_DESTINATION,
FIELD_SET (0, DE_DESTINATION, WRAP, DISABLE) |
FIELD_VALUE(0, DE_DESTINATION, X, dx) |
- FIELD_VALUE(0, DE_DESTINATION, Y, dy));//dpr04
+ FIELD_VALUE(0, DE_DESTINATION, Y, dy)); /* dpr04 */
write_dpr(accel, DE_DIMENSION,
FIELD_VALUE(0, DE_DIMENSION, X, width) |
- FIELD_VALUE(0, DE_DIMENSION, Y_ET, height));//dpr08
+ FIELD_VALUE(0, DE_DIMENSION, Y_ET, height)); /* dpr08 */
de_ctrl FIELD_VALUE(0, DE_CONTROL, ROP, rop2) |
@@ -297,7 +297,7 @@ unsigned int rop2) /* ROP value */
FIELD_SET(0, DE_CONTROL, DIRECTION, RIGHT_TO_LEFT)
: FIELD_SET(0, DE_CONTROL, DIRECTION, LEFT_TO_RIGHT)) |
FIELD_SET(0, DE_CONTROL, STATUS, START);
- write_dpr(accel, DE_CONTROL, de_ctrl);//dpr0c
+ write_dpr(accel, DE_CONTROL, de_ctrl); /* dpr0c */
}
return 0;
@@ -346,7 +346,6 @@ int hw_imageblit(struct lynx_accel *accel,
if(accel->de_wait() != 0)
{
-// inf_msg("*** ImageBlit return -1 ***\n");
return -1;
}
@@ -370,7 +369,7 @@ int hw_imageblit(struct lynx_accel *accel,
startBit *= 3;
write_dpr(accel, DE_PITCH,
FIELD_VALUE(0, DE_PITCH, DESTINATION, dPitch) |
- FIELD_VALUE(0, DE_PITCH, SOURCE, dPitch));//dpr10
+ FIELD_VALUE(0, DE_PITCH, SOURCE, dPitch)); /* dpr10 */
}
else
@@ -378,7 +377,7 @@ int hw_imageblit(struct lynx_accel *accel,
{
write_dpr(accel, DE_PITCH,
FIELD_VALUE(0, DE_PITCH, DESTINATION, dPitch/bytePerPixel) |
- FIELD_VALUE(0, DE_PITCH, SOURCE, dPitch/bytePerPixel));//dpr10
+ FIELD_VALUE(0, DE_PITCH, SOURCE, dPitch/bytePerPixel)); /* dpr10 */
}
/* Screen Window width in Pixels.
@@ -392,16 +391,16 @@ int hw_imageblit(struct lynx_accel *accel,
For mono bitmap, use startBit for X_K1. */
write_dpr(accel, DE_SOURCE,
FIELD_SET (0, DE_SOURCE, WRAP, DISABLE) |
- FIELD_VALUE(0, DE_SOURCE, X_K1_MONO, startBit));//dpr00
+ FIELD_VALUE(0, DE_SOURCE, X_K1_MONO, startBit)); /* dpr00 */
write_dpr(accel, DE_DESTINATION,
FIELD_SET (0, DE_DESTINATION, WRAP, DISABLE) |
FIELD_VALUE(0, DE_DESTINATION, X, dx) |
- FIELD_VALUE(0, DE_DESTINATION, Y, dy));//dpr04
+ FIELD_VALUE(0, DE_DESTINATION, Y, dy)); /* dpr04 */
write_dpr(accel, DE_DIMENSION,
FIELD_VALUE(0, DE_DIMENSION, X, width) |
- FIELD_VALUE(0, DE_DIMENSION, Y_ET, height));//dpr08
+ FIELD_VALUE(0, DE_DIMENSION, Y_ET, height)); /* dpr08 */
write_dpr(accel, DE_FOREGROUND, fColor);
write_dpr(accel, DE_BACKGROUND, bColor);
diff --git a/drivers/staging/sm750fb/sm750_accel.h b/drivers/staging/sm750fb/sm750_accel.h
index e9d217b..57e20fb 100644
--- a/drivers/staging/sm750fb/sm750_accel.h
+++ b/drivers/staging/sm750fb/sm750_accel.h
@@ -113,7 +113,7 @@
#define DE_CONTROL_TRANSPARENCY_ENABLE 1
#define DE_CONTROL_ROP 7:0
-// Pseudo fields.
+/* Pseudo fields. */
#define DE_CONTROL_SHORT_STROKE_DIR 27:24
#define DE_CONTROL_SHORT_STROKE_DIR_225 0
diff --git a/drivers/staging/sm750fb/sm750_cursor.c b/drivers/staging/sm750fb/sm750_cursor.c
index b145285..cb37ea3 100644
--- a/drivers/staging/sm750fb/sm750_cursor.c
+++ b/drivers/staging/sm750fb/sm750_cursor.c
@@ -141,10 +141,10 @@ void hw_cursor_setData(struct lynx_cursor * cursor,
{
if(opr & (0x80 >> j))
- { //use fg color,id = 2
+ { /* use fg color,id = 2 */
data |= 2 << (j*2);
}else{
- //use bg color,id = 1
+ /* use bg color,id = 1 */
data |= 1 << (j*2);
}
}
@@ -221,10 +221,10 @@ void hw_cursor_setData2(struct lynx_cursor * cursor,
{
if(opr & (0x80 >> j))
- { //use fg color,id = 2
+ { /* use fg color,id = 2 */
data |= 2 << (j*2);
}else{
- //use bg color,id = 1
+ /* use bg color,id = 1 */
data |= 1 << (j*2);
}
}
@@ -238,7 +238,6 @@ void hw_cursor_setData2(struct lynx_cursor * cursor,
/* assume pitch is 1,2,4,8,...*/
if(!(i&(pitch-1)))
- //if((i+1) % pitch = 0)
{
/* need a return */
pstart += offset;
diff --git a/drivers/staging/sm750fb/sm750_help.h b/drivers/staging/sm750fb/sm750_help.h
index ebc946c..05777f7 100644
--- a/drivers/staging/sm750fb/sm750_help.h
+++ b/drivers/staging/sm750fb/sm750_help.h
@@ -1,9 +1,7 @@
#ifndef LYNX_HELP_H__
#define LYNX_HELP_H__
-/*****************************************************************************\
- * FIELD MACROS *
-\*****************************************************************************/
+/* FIELD MACROS */
#define _LSB(f) (0 ? f)
#define _MSB(f) (1 ? f)
#define _COUNT(f) (_MSB(f) - _LSB(f) + 1)
@@ -17,13 +15,7 @@
#define SET_FIELDV(d, f, v) (((d) & ~GET_MASK(f)) | \
(((v) & RAW_MASK(f)) << _LSB(f)))
-
-////////////////////////////////////////////////////////////////////////////////
-// //
-// Internal macros //
-// //
-////////////////////////////////////////////////////////////////////////////////
-
+/* Internal macros */
#define _F_START(f) (0 ? f)
#define _F_END(f) (1 ? f)
#define _F_SIZE(f) (1 + _F_END(f) - _F_START(f))
@@ -31,13 +23,7 @@
#define _F_NORMALIZE(v, f) (((v) & _F_MASK(f)) >> _F_START(f))
#define _F_DENORMALIZE(v, f) (((v) << _F_START(f)) & _F_MASK(f))
-
-////////////////////////////////////////////////////////////////////////////////
-// //
-// Global macros //
-// //
-////////////////////////////////////////////////////////////////////////////////
-
+/* Global macros */
#define FIELD_GET(x, reg, field) \
( \
_F_NORMALIZE((x), reg ## _ ## field) \
@@ -60,13 +46,7 @@
~ _F_MASK(reg ## _ ## field) \
)
-
-////////////////////////////////////////////////////////////////////////////////
-// //
-// Field Macros //
-// //
-////////////////////////////////////////////////////////////////////////////////
-
+/* Field Macros */
#define FIELD_START(field) (0 ? field)
#define FIELD_END(field) (1 ? field)
#define FIELD_SIZE(field) (1 + FIELD_END(field) - FIELD_START(field))
diff --git a/drivers/staging/sm750fb/sm750_hw.c b/drivers/staging/sm750fb/sm750_hw.c
index 131125c..e70961e 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -193,7 +193,6 @@ int hw_sm750_inithw(struct lynx_share* share, struct pci_dev * pdev)
/* init 2d engine */
if(!share->accel_off){
hw_sm750_initAccel(share);
-// share->accel.de_wait = hw_sm750_deWait;
}
return 0;
@@ -328,7 +327,6 @@ int hw_sm750_crtc_setMode(struct lynxfb_crtc* crtc,
#endif
/* set timing */
-// modparm.pixel_clock = PS_TO_HZ(var->pixclock);
modparm.pixel_clock = ps_to_hz(var->pixclock);
modparm.vertical_sync_polarity = (var->sync & FB_SYNC_HOR_HIGH_ACT) ? POS:NEG;
modparm.horizontal_sync_polarity = (var->sync & FB_SYNC_VERT_HIGH_ACT) ? POS:NEG;
@@ -618,7 +616,7 @@ int hw_sm750_pan_display(struct lynxfb_crtc *crtc,
const struct fb_info *info)
{
uint32_t total;
- //check params
+ /* check params */
if ((var->xoffset + var->xres > var->xres_virtual) ||
(var->yoffset + var->yres > var->yres_virtual)) {
return -EINVAL;
diff --git a/drivers/staging/sm750fb/sm750_hw.h b/drivers/staging/sm750fb/sm750_hw.h
index 4fee28d..93288b3 100644
--- a/drivers/staging/sm750fb/sm750_hw.h
+++ b/drivers/staging/sm750fb/sm750_hw.h
@@ -8,9 +8,6 @@
#define SM750LE_REVISION_ID (unsigned char)0xfe
#endif
-//#define DEFAULT_MEM_CLOCK (DEFAULT_SM750_CHIP_CLOCK/1)
-//#define DEFAULT_MASTER_CLOCK (DEFAULT_SM750_CHIP_CLOCK/3)
-
enum sm750_pnltype{
--
2.4.3
^ permalink raw reply related
* Re: [PATCH 00/21] On-demand device registration
From: Alexander Holler @ 2015-06-12 11:19 UTC (permalink / raw)
To: Linus Walleij
Cc: Tomeu Vizoso, Grant Likely, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-samsung-soc,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Dmitry Torokhov,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
linux-pwm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
DRM PANEL DRIVERS, dmaengine-u79uwXL29TY76Z2rM5mHXA, Dan Williams,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CACRpkdbDSS0yw=q_cR17Bvg+kgTfU3Vcd2gSjx1p4V-CzOZ_SA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Am 12.06.2015 um 09:25 schrieb Linus Walleij:
> On Thu, Jun 11, 2015 at 6:40 PM, Alexander Holler <holler@ahsoftware.de> wrote:
>> Am 11.06.2015 um 14:30 schrieb Linus Walleij:
>
>>> Certainly it is possible to create deadlocks in this scenario, but the
>>> scope is not to create an ubreakable system.
>>
>> IAnd what happens if you run into a deadlock? Do you print "you've lost, try
>> changing your kernel config" in some output hidden by a splash-screen? ;)
>
> Sorry it sounds like a blanket argument, the fact that there are
> mutexes in the kernel makes it possible to deadlock, it doesn't
> mean we don't use mutexes. Some programming problems are
> just like such.
I'm not talking about specific deadlocks through mutexes. I'm talking
about what happens when driver A needs driver B which needs driver A.
How do you recognise and handle that with your instrumented on-demand
device initialization? Such a circular dependency might happen by just
adding a new fucntion call or by changing the kernel configuration. And
with the on-demand stuff, the possibility that the developer introducing
this new (maybe optional) call will never hit such a circular dependency
is high. So you will end up with a never ending stream of problem
reports whenever someone introduced such a circular dependecy without
having noticed it.
And to come back to specific deadlocks, if you are extending function
calls from something former simple to something which might initialize a
whole bunch of drivers, needing maybe seconds, I wouldn't say this is a
blanket argument, but a real thread.
Alexander Holler
^ permalink raw reply
* Re: [PATCH 1/2] backlight: pwm: don't call legacy pwm request for device defined in dt
From: Thierry Reding @ 2015-06-12 11:31 UTC (permalink / raw)
To: Vladimir Zapolskiy
Cc: linux-fbdev, linux-pwm, Jingoo Han, Bryan Wu, Lee Jones, stable
In-Reply-To: <1413035186-11771-2-git-send-email-vladimir_zapolskiy@mentor.com>
[-- Attachment #1: Type: text/plain, Size: 2450 bytes --]
On Sat, Oct 11, 2014 at 04:46:25PM +0300, Vladimir Zapolskiy wrote:
> Platform PWM backlight data provided by board's device tree should be
> complete enough to successfully request a pwm device using pwm_get() API.
>
> Based on initial implementation done by Dmitry Eremin-Solenikov.
>
> Reported-by: Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Jingoo Han <jg1.han@samsung.com>
> Cc: Bryan Wu <cooloney@gmail.com>
> Cc: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/video/backlight/pwm_bl.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
This fell off my radar, but I think it's good. I used to have a local
patch somewhere that solved the same problem by initializing the pwm_id
field of platform_pwm_backlight_data to -1 in pwm_backlight_parse_dt(),
but I like this variant better because it's more explicit and doesn't
even attempt to request using the legacy API (which will inevitably fail
in the DT case anyway).
Vladimir, do you think you'd have the time to rebase this patch on top
of something recent and perhaps extend the commit message with some of
the arguments that you brought forth in this thread? Specifically it'd
be useful to mention that this enforces the DT binding and fixes a real
bug where the legacy path would try to request a PWM that's not
necessarily the right one.
Thierry
> diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> index cb5ae4c..dd7aaf7 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -272,15 +272,15 @@ static int pwm_backlight_probe(struct platform_device *pdev)
> }
>
> pb->pwm = devm_pwm_get(&pdev->dev, NULL);
> - if (IS_ERR(pb->pwm)) {
> + if (IS_ERR(pb->pwm) && !pdev->dev.of_node) {
> dev_err(&pdev->dev, "unable to request PWM, trying legacy API\n");
> -
> pb->pwm = pwm_request(data->pwm_id, "pwm-backlight");
> - if (IS_ERR(pb->pwm)) {
> - dev_err(&pdev->dev, "unable to request legacy PWM\n");
> - ret = PTR_ERR(pb->pwm);
> - goto err_alloc;
> - }
> + }
> +
> + if (IS_ERR(pb->pwm)) {
> + dev_err(&pdev->dev, "unable to request PWM\n");
> + ret = PTR_ERR(pb->pwm);
> + goto err_alloc;
> }
>
> dev_dbg(&pdev->dev, "got pwm for backlight\n");
> --
> 1.7.10.4
>
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 00/21] On-demand device registration
From: Alexander Holler @ 2015-06-12 11:36 UTC (permalink / raw)
To: Linus Walleij
Cc: Tomeu Vizoso, Grant Likely, Mark Rutland,
devicetree@vger.kernel.org, linux-fbdev@vger.kernel.org,
linux-samsung-soc, linux-tegra@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-pm@vger.kernel.org,
Dmitry Torokhov, linux-kernel@vger.kernel.org, Rob Herring,
linux-pwm@vger.kernel.org, DRM PANEL DRIVERS, dmaengine,
Dan Williams, linux-usb, linux-i2c
In-Reply-To: <557AC040.40803@ahsoftware.de>
Am 12.06.2015 um 13:19 schrieb Alexander Holler:
> Am 12.06.2015 um 09:25 schrieb Linus Walleij:
>> On Thu, Jun 11, 2015 at 6:40 PM, Alexander Holler
>> <holler@ahsoftware.de> wrote:
>>> Am 11.06.2015 um 14:30 schrieb Linus Walleij:
>>
>>>> Certainly it is possible to create deadlocks in this scenario, but the
>>>> scope is not to create an ubreakable system.
>>>
>>> IAnd what happens if you run into a deadlock? Do you print "you've
>>> lost, try
>>> changing your kernel config" in some output hidden by a
>>> splash-screen? ;)
>>
>> Sorry it sounds like a blanket argument, the fact that there are
>> mutexes in the kernel makes it possible to deadlock, it doesn't
>> mean we don't use mutexes. Some programming problems are
>> just like such.
>
> I'm not talking about specific deadlocks through mutexes. I'm talking
> about what happens when driver A needs driver B which needs driver A.
> How do you recognise and handle that with your instrumented on-demand
> device initialization? Such a circular dependency might happen by just
> adding a new fucntion call or by changing the kernel configuration. And
> with the on-demand stuff, the possibility that the developer introducing
> this new (maybe optional) call will never hit such a circular dependency
> is high. So you will end up with a never ending stream of problem
> reports whenever someone introduced such a circular dependecy without
> having noticed it.
>
> And to come back to specific deadlocks, if you are extending function
> calls from something former simple to something which might initialize a
> whole bunch of drivers, needing maybe seconds, I wouldn't say this is a
> blanket argument, but a real thread.
Keep in mind, that the possibility that a function call ends up with
initializing a whole bunch of other drivers, is not determined
statically, but depends on the configuration and runtime behaviour of
the actual system the on-demand stuff actually happens.
E.g. if driver A is faster one system that driver B, the whole bunch of
drivers might become initialized by a call in driver A. But if driver B
was faster on the developers system (or the system is configured to
first init driver B), than the whole bunch of drivers might have become
initialized by driver B on the developers system. Thus he never might
have hit a possible problem when the whole bunch of drivers got
initialized in driver A.
That means it isn't always a good idea to create dynamic systems (like
on-demand device initialization), because it's very hard to foresee and
correctly handle their runtime behaviour.
> Alexander Holler
^ permalink raw reply
* Re: [PATCH 1/2] backlight: pwm: don't call legacy pwm request for device defined in dt
From: Vladimir Zapolskiy @ 2015-06-12 12:57 UTC (permalink / raw)
To: Thierry Reding
Cc: linux-fbdev, linux-pwm, Jingoo Han, Bryan Wu, Lee Jones, stable
In-Reply-To: <20150612113114.GK19400@ulmo.nvidia.com>
Hi Thierry,
On 12.06.2015 14:31, Thierry Reding wrote:
> On Sat, Oct 11, 2014 at 04:46:25PM +0300, Vladimir Zapolskiy wrote:
>> Platform PWM backlight data provided by board's device tree should be
>> complete enough to successfully request a pwm device using pwm_get() API.
>>
>> Based on initial implementation done by Dmitry Eremin-Solenikov.
>>
>> Reported-by: Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
>> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
>> Cc: Thierry Reding <thierry.reding@gmail.com>
>> Cc: Jingoo Han <jg1.han@samsung.com>
>> Cc: Bryan Wu <cooloney@gmail.com>
>> Cc: Lee Jones <lee.jones@linaro.org>
>> ---
>> drivers/video/backlight/pwm_bl.c | 14 +++++++-------
>> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> This fell off my radar, but I think it's good. I used to have a local
> patch somewhere that solved the same problem by initializing the pwm_id
> field of platform_pwm_backlight_data to -1 in pwm_backlight_parse_dt(),
> but I like this variant better because it's more explicit and doesn't
> even attempt to request using the legacy API (which will inevitably fail
> in the DT case anyway).
>
> Vladimir, do you think you'd have the time to rebase this patch on top
> of something recent and perhaps extend the commit message with some of
> the arguments that you brought forth in this thread? Specifically it'd
> be useful to mention that this enforces the DT binding and fixes a real
> bug where the legacy path would try to request a PWM that's not
> necessarily the right one.
sure, no problem, I'll find time to rebase on top of Lee's
backlight/for-backlight-next and resend the change this weekend.
Thank you for reviewing :)
--
With best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH 1/2] backlight: pwm: don't call legacy pwm request for device defined in dt
From: Thierry Reding @ 2015-06-12 13:19 UTC (permalink / raw)
To: Vladimir Zapolskiy
Cc: linux-fbdev, linux-pwm, Jingoo Han, Bryan Wu, Lee Jones, stable
In-Reply-To: <557AD755.5050409@mentor.com>
[-- Attachment #1: Type: text/plain, Size: 2001 bytes --]
On Fri, Jun 12, 2015 at 03:57:57PM +0300, Vladimir Zapolskiy wrote:
> Hi Thierry,
>
> On 12.06.2015 14:31, Thierry Reding wrote:
> > On Sat, Oct 11, 2014 at 04:46:25PM +0300, Vladimir Zapolskiy wrote:
> >> Platform PWM backlight data provided by board's device tree should be
> >> complete enough to successfully request a pwm device using pwm_get() API.
> >>
> >> Based on initial implementation done by Dmitry Eremin-Solenikov.
> >>
> >> Reported-by: Dmitry Eremin-Solenikov <dmitry_eremin@mentor.com>
> >> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> >> Cc: Thierry Reding <thierry.reding@gmail.com>
> >> Cc: Jingoo Han <jg1.han@samsung.com>
> >> Cc: Bryan Wu <cooloney@gmail.com>
> >> Cc: Lee Jones <lee.jones@linaro.org>
> >> ---
> >> drivers/video/backlight/pwm_bl.c | 14 +++++++-------
> >> 1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > This fell off my radar, but I think it's good. I used to have a local
> > patch somewhere that solved the same problem by initializing the pwm_id
> > field of platform_pwm_backlight_data to -1 in pwm_backlight_parse_dt(),
> > but I like this variant better because it's more explicit and doesn't
> > even attempt to request using the legacy API (which will inevitably fail
> > in the DT case anyway).
> >
> > Vladimir, do you think you'd have the time to rebase this patch on top
> > of something recent and perhaps extend the commit message with some of
> > the arguments that you brought forth in this thread? Specifically it'd
> > be useful to mention that this enforces the DT binding and fixes a real
> > bug where the legacy path would try to request a PWM that's not
> > necessarily the right one.
>
> sure, no problem, I'll find time to rebase on top of Lee's
> backlight/for-backlight-next and resend the change this weekend.
>
> Thank you for reviewing :)
I'll be away for two weeks, but feel free to add my:
Acked-by: Thierry Reding <thierry.reding@gmail.com>
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] fbdev: propagate result of fb_videomode_from_videomode()
From: Vladimir Murzin @ 2015-06-12 13:59 UTC (permalink / raw)
To: linux-fbdev
fb_videomode_from_videomode() may fail, but of_get_fb_videomode()
silently covers this fact. Instead, trow the error code to the
caller.
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
drivers/video/fbdev/core/fbmon.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/core/fbmon.c b/drivers/video/fbdev/core/fbmon.c
index 01ef1b9..d787533 100644
--- a/drivers/video/fbdev/core/fbmon.c
+++ b/drivers/video/fbdev/core/fbmon.c
@@ -1475,7 +1475,9 @@ int of_get_fb_videomode(struct device_node *np, struct fb_videomode *fb,
if (ret)
return ret;
- fb_videomode_from_videomode(&vm, fb);
+ ret = fb_videomode_from_videomode(&vm, fb);
+ if (ret)
+ return ret;
pr_debug("%s: got %dx%d display mode from %s\n",
of_node_full_name(np), vm.hactive, vm.vactive, np->name);
--
1.7.9.5
^ permalink raw reply related
* [PATCH] pwm-backlight: Avoid backlight flicker when probed from DT
From: Philipp Zabel @ 2015-06-12 16:26 UTC (permalink / raw)
To: Thierry Reding
Cc: Jingoo Han, Lee Jones, Ajay Kumar, linux-pwm, linux-fbdev,
linux-kernel, kernel, Philipp Zabel
If the driver is probed from the device tree, and there is a phandle
property set on it, and the enable GPIO is already configured as output,
and the backlight is currently disabled, keep it disabled.
If all these conditions are met, assume there will be some other driver
that can enable the backlight at the appropriate time.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
I have seen the thread at https://lkml.org/lkml/2014/7/31/259, but I'm not
sure if it has come to a resolution. This is what I think could be useful
to keep the current default behaviour of enabling the backlight while at the
same time allowing to keep it disabled if we are absolutely certain that the
backlight is currently off, and we think there is some other driver that will
control it:
---
drivers/video/backlight/pwm_bl.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 6897f1c..dcb6bfb 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -199,6 +199,7 @@ static int pwm_backlight_probe(struct platform_device *pdev)
struct backlight_properties props;
struct backlight_device *bl;
struct pwm_bl_data *pb;
+ int initial_blank = FB_BLANK_UNBLANK;
int ret;
if (!data) {
@@ -263,8 +264,21 @@ static int pwm_backlight_probe(struct platform_device *pdev)
pb->enable_gpio = gpio_to_desc(data->enable_gpio);
}
- if (pb->enable_gpio)
- gpiod_direction_output(pb->enable_gpio, 1);
+ if (pb->enable_gpio) {
+ /*
+ * If the driver is probed from the device tree and there is a
+ * phandle link pointing to the backlight node, it is safe to
+ * assume that another driver will enable the backlight at the
+ * appropriate time. Therefore, if it is disabled, keep it so.
+ */
+ if (of_find_property(pdev->dev.of_node, "phandle", NULL) &&
+ gpiod_get_direction(pb->enable_gpio) = GPIOF_DIR_OUT &&
+ gpiod_get_value(pb->enable_gpio) = 0) {
+ initial_blank = FB_BLANK_POWERDOWN;
+ } else {
+ gpiod_direction_output(pb->enable_gpio, 1);
+ }
+ }
pb->power_supply = devm_regulator_get(&pdev->dev, "power");
if (IS_ERR(pb->power_supply)) {
@@ -323,6 +337,7 @@ static int pwm_backlight_probe(struct platform_device *pdev)
}
bl->props.brightness = data->dft_brightness;
+ bl->props.power = initial_blank;
backlight_update_status(bl);
platform_set_drvdata(pdev, bl);
--
2.1.4
^ permalink raw reply related
* Re: RIP MTRR - status update for upcoming v4.2
From: Toshi Kani @ 2015-06-12 16:42 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis R. Rodriguez, Tomi Valkeinen, Borislav Petkov, Bjorn Helgaas,
Jej B, Ville Syrjälä, Ville Syrjälä,
Andrew Morton, linux-kernel@vger.kernel.org, linux-media,
linux-fbdev, linux-pci@vger.kernel.org, Andy Lutomirski, X86 ML,
Juergen Gross, Dave Airlie, xen-devel, Julia Lawall
In-Reply-To: <20150612005221.GD23057@wotan.suse.de>
On Fri, 2015-06-12 at 02:52 +0200, Luis R. Rodriguez wrote:
> On Thu, Jun 11, 2015 at 05:23:16PM -0600, Toshi Kani wrote:
> > On Thu, 2015-06-11 at 13:36 -0700, Luis R. Rodriguez wrote:
> > :
> > > Pending RIP MTRR patches
> > > ==========
> > >
> > > There are a few pending series so I wanted to provide a status update
> > > on those series.
> > >
> > > mtrr: bury MTRR - unexport mtrr_add() and mtrr_del()
> > >
> > > This is the nail on the MTRR coffin, it will prevent future direct
> > > access to MTRR code. This will not be posted until all of the below
> > > patches are in and merged. A possible next step here might be to
> > > consider separating PAT code from MTRR code and making PAT a first
> > > class citizen, enabling distributions to disable MTRR code in the
> > > future. I thought this was possible but for some reason I recently
> > > thought that there was one possible issue to make this happen. I
> > > suppose we won't know unless we try, unless of course someone already
> > > knows, Toshi?
> >
> > There are two usages on MTRRs:
> > 1) MTRR entries set by firmware
> > 2) MTRR entries set by OS drivers
> >
> > We can obsolete 2), but we have no control over 1). As UEFI firmwares
> > also set this up, this usage will continue to stay. So, we should not
> > get rid of the MTRR code that looks up the MTRR entries, while we have
> > no need to modify them.
> >
> > Such MTRR entries provide safe guard to /dev/mem, which allows
> > privileged user to access a range that may require UC mapping while
> > the /dev/mem driver blindly maps it with WB. MTRRs converts WB to UC in
> > such a case.
> >
> > UEFI memory table has memory attribute, which describes cache types
> > supported in physical memory ranges. However, this information gets
> > lost when it it is converted to e820 table.
>
> Is there no way to modify CPU capability bits upon boot and kick UEFI
> to re-evaluate ? In such UEFI cases what happens for instance when
> Xen is used which does not support MTRR?
EFI GetMemoryMap() is a boot service, and won't be available after
ExitBootServices() is called. But we should be able to keep the
attribute information copied into some table if necessary.
Xen provides virtual firmware on their guests, right? If this firmware
does not set up MTRRs today, then I do not think it needs to set up for
UEFI, either. Assuming the guest physical address is virtualized, it
does not have to carry the same platform attribute & restriction.
Thanks,
-Toshi
^ permalink raw reply
* Re: [Xen-devel] RIP MTRR - status update for upcoming v4.2
From: Toshi Kani @ 2015-06-12 16:58 UTC (permalink / raw)
To: Jan Beulich
Cc: Andy Lutomirski, Luis R. Rodriguez, Bjorn Helgaas, Jej B, X86 ML,
Andrew Morton, ville.syrjala, Julia Lawall, xen-devel,
Dave Airlie, syrjala, Juergen Gross, Luis Rodriguez,
Borislav Petkov, Tomi Valkeinen, linux-fbdev,
linux-kernel@vger.kernel.org, linux-media,
linux-pci@vger.kernel.org
In-Reply-To: <557AAD910200007800084014@mail.emea.novell.com>
On Fri, 2015-06-12 at 08:59 +0100, Jan Beulich wrote:
> >>> On 12.06.15 at 01:23, <toshi.kani@hp.com> wrote:
> > There are two usages on MTRRs:
> > 1) MTRR entries set by firmware
> > 2) MTRR entries set by OS drivers
> >
> > We can obsolete 2), but we have no control over 1). As UEFI firmwares
> > also set this up, this usage will continue to stay. So, we should not
> > get rid of the MTRR code that looks up the MTRR entries, while we have
> > no need to modify them.
> >
> > Such MTRR entries provide safe guard to /dev/mem, which allows
> > privileged user to access a range that may require UC mapping while
> > the /dev/mem driver blindly maps it with WB. MTRRs converts WB to UC in
> > such a case.
>
> But it wouldn't be impossible to simply read the MTRRs upon boot,
> store the information, disable MTRRs, and correctly use PAT to
> achieve the same effect (i.e. the "blindly maps" part of course
> would need fixing).
It could be done, but I do not see much benefit of doing it. One of the
reasons platform vendors set MTRRs is so that a system won't hit a
machine check when an OS bug leads an access with a wrong cache type. A
machine check is hard to analyze and can be seen as a hardware issue by
customers. Emulating MTRRs with PAT won't protect from such a bug.
> > UEFI memory table has memory attribute, which describes cache types
> > supported in physical memory ranges. However, this information gets
> > lost when it it is converted to e820 table.
>
> I'm afraid you rather don't want to trust that information, as
> firmware vendors frequently screw it up.
Could be, but we need to use firmware info when necessary...
Thanks,
-Toshi
^ permalink raw reply
* Re: [Xen-devel] RIP MTRR - status update for upcoming v4.2
From: Andy Lutomirski @ 2015-06-12 23:15 UTC (permalink / raw)
To: Jan Beulich
Cc: Juergen Gross, Tomi Valkeinen, Ville Syrjälä,
Dave Airlie, xen-devel@lists.xenproject.org, linux-fbdev, X86 ML,
Andrew Morton, Jej B, Bjorn Helgaas, Luis R. Rodriguez,
linux-media, Luis Rodriguez, linux-pci@vger.kernel.org,
Toshi Kani, Borislav Petkov, Julia Lawall,
linux-kernel@vger.kernel.org, ville.syrjala
In-Reply-To: <557AAD910200007800084014@mail.emea.novell.com>
On Jun 12, 2015 12:59 AM, "Jan Beulich" <JBeulich@suse.com> wrote:
>
> >>> On 12.06.15 at 01:23, <toshi.kani@hp.com> wrote:
> > There are two usages on MTRRs:
> > 1) MTRR entries set by firmware
> > 2) MTRR entries set by OS drivers
> >
> > We can obsolete 2), but we have no control over 1). As UEFI firmwares
> > also set this up, this usage will continue to stay. So, we should not
> > get rid of the MTRR code that looks up the MTRR entries, while we have
> > no need to modify them.
> >
> > Such MTRR entries provide safe guard to /dev/mem, which allows
> > privileged user to access a range that may require UC mapping while
> > the /dev/mem driver blindly maps it with WB. MTRRs converts WB to UC in
> > such a case.
>
> But it wouldn't be impossible to simply read the MTRRs upon boot,
> store the information, disable MTRRs, and correctly use PAT to
> achieve the same effect (i.e. the "blindly maps" part of course
> would need fixing).
This may crash and burn badly when we call a UEFI function or an SMI
happens. I think we should just leave the MTRRs alone.
--Andy
^ permalink raw reply
* Re: [Xen-devel] RIP MTRR - status update for upcoming v4.2
From: James Bottomley @ 2015-06-12 23:29 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Jan Beulich, Juergen Gross, Tomi Valkeinen,
Ville Syrjälä, Dave Airlie,
xen-devel@lists.xenproject.org, linux-fbdev, X86 ML,
Andrew Morton, Bjorn Helgaas, Luis R. Rodriguez, linux-media,
Luis Rodriguez, linux-pci@vger.kernel.org, Toshi Kani,
Borislav Petkov, Julia Lawall, linux-kernel@vger.kernel.org,
ville.syrjala
In-Reply-To: <CALCETrXWZU2NZRZy7b74z54Tt5aKmTOmgMmf5WYG1OZtEmjw7A@mail.gmail.com>
On Fri, 2015-06-12 at 16:15 -0700, Andy Lutomirski wrote:
> On Jun 12, 2015 12:59 AM, "Jan Beulich" <JBeulich@suse.com> wrote:
> >
> > >>> On 12.06.15 at 01:23, <toshi.kani@hp.com> wrote:
> > > There are two usages on MTRRs:
> > > 1) MTRR entries set by firmware
> > > 2) MTRR entries set by OS drivers
> > >
> > > We can obsolete 2), but we have no control over 1). As UEFI firmwares
> > > also set this up, this usage will continue to stay. So, we should not
> > > get rid of the MTRR code that looks up the MTRR entries, while we have
> > > no need to modify them.
> > >
> > > Such MTRR entries provide safe guard to /dev/mem, which allows
> > > privileged user to access a range that may require UC mapping while
> > > the /dev/mem driver blindly maps it with WB. MTRRs converts WB to UC in
> > > such a case.
> >
> > But it wouldn't be impossible to simply read the MTRRs upon boot,
> > store the information, disable MTRRs, and correctly use PAT to
> > achieve the same effect (i.e. the "blindly maps" part of course
> > would need fixing).
>
> This may crash and burn badly when we call a UEFI function or an SMI
> happens. I think we should just leave the MTRRs alone.
Wholeheartedly agree: PAT only works when the given memory map is in
operation but MTRRs function everywhere. Anything that goes into real
mode or installs its own memory map won't see the Linux page attributes.
James
^ permalink raw reply
* Re: [Xen-devel] RIP MTRR - status update for upcoming v4.2
From: Ingo Molnar @ 2015-06-13 6:37 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Jan Beulich, Juergen Gross, Tomi Valkeinen,
Ville Syrjälä, Dave Airlie,
xen-devel@lists.xenproject.org, linux-fbdev, X86 ML,
Andrew Morton, Jej B, Bjorn Helgaas, Luis R. Rodriguez,
linux-media, Luis Rodriguez, linux-pci@vger.kernel.org,
Toshi Kani, Borislav Petkov, Julia Lawall,
linux-kernel@vger.kernel.org, ville.syrjala
In-Reply-To: <CALCETrXWZU2NZRZy7b74z54Tt5aKmTOmgMmf5WYG1OZtEmjw7A@mail.gmail.com>
* Andy Lutomirski <luto@amacapital.net> wrote:
> On Jun 12, 2015 12:59 AM, "Jan Beulich" <JBeulich@suse.com> wrote:
> >
> > >>> On 12.06.15 at 01:23, <toshi.kani@hp.com> wrote:
> > > There are two usages on MTRRs:
> > > 1) MTRR entries set by firmware
> > > 2) MTRR entries set by OS drivers
> > >
> > > We can obsolete 2), but we have no control over 1). As UEFI firmwares
> > > also set this up, this usage will continue to stay. So, we should not
> > > get rid of the MTRR code that looks up the MTRR entries, while we have
> > > no need to modify them.
> > >
> > > Such MTRR entries provide safe guard to /dev/mem, which allows privileged
> > > user to access a range that may require UC mapping while the /dev/mem driver
> > > blindly maps it with WB. MTRRs converts WB to UC in such a case.
> >
> > But it wouldn't be impossible to simply read the MTRRs upon boot, store the
> > information, disable MTRRs, and correctly use PAT to achieve the same effect
> > (i.e. the "blindly maps" part of course would need fixing).
>
> This may crash and burn badly when we call a UEFI function or an SMI happens. I
> think we should just leave the MTRRs alone.
Not to mention suspend/resume, reboot and other goodies where the firmware might
pop up expecting intact MTRRs.
Btw., doesn't a lack of MTRRs imply UC? So is 'crash and burn' possible in most
cases? Isn't it just 'executes slower than before'?
Thanks,
Ingo
^ permalink raw reply
* doubt about sm7xxfb (was: Re: [PATCH v4 0/7] staging: fsl-mc: New functionality to the MC bus driver
From: Sudip Mukherjee @ 2015-06-13 8:58 UTC (permalink / raw)
To: Greg KH; +Cc: devel, linux-kernel, dan.carpenter, tomi.valkeinen, linux-fbdev
In-Reply-To: <20150613001849.GB5234@kroah.com>
On Fri, Jun 12, 2015 at 05:18:49PM -0700, Greg KH wrote:
> On Tue, Jun 09, 2015 at 04:59:01PM -0500, J. German Rivera wrote:
> > This patch series includes new functionality for the Freescale fsl-mc
> > bus driver.
>
> Why are people working on "new functionality" instead of working on
> getting this out of the staging tree? I really hate adding new
> functions to staging drivers, as this is not the correct place for
> drivers to be in the tree. People should be working to get them out of
> this location, and then you can add new functions to them.
Hi Greg,
Your reply above was for a different thread but my doubt started from
this. I was working on adding the Dual-Head support to sm7xxfb. So that
is also a new functionality which is not in the current driver as of now.
Then should i instead concentrate on getting that out of staging? If yes,
can you please have a look (when you are free) at it to see if anything
else needs to be done.
regards
sudip
^ permalink raw reply
* Re: doubt about sm7xxfb (was: Re: [PATCH v4 0/7] staging: fsl-mc: New functionality to the MC bus dr
From: Greg KH @ 2015-06-13 16:28 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: devel, linux-fbdev, tomi.valkeinen, linux-kernel, dan.carpenter
In-Reply-To: <20150613084618.GA6492@sudip-PC>
On Sat, Jun 13, 2015 at 02:16:18PM +0530, Sudip Mukherjee wrote:
> On Fri, Jun 12, 2015 at 05:18:49PM -0700, Greg KH wrote:
> > On Tue, Jun 09, 2015 at 04:59:01PM -0500, J. German Rivera wrote:
> > > This patch series includes new functionality for the Freescale fsl-mc
> > > bus driver.
> >
> > Why are people working on "new functionality" instead of working on
> > getting this out of the staging tree? I really hate adding new
> > functions to staging drivers, as this is not the correct place for
> > drivers to be in the tree. People should be working to get them out of
> > this location, and then you can add new functions to them.
> Hi Greg,
> Your reply above was for a different thread but my doubt started from
> this. I was working on adding the Dual-Head support to sm7xxfb. So that
> is also a new functionality which is not in the current driver as of now.
> Then should i instead concentrate on getting that out of staging? If yes,
> can you please have a look (when you are free) at it to see if anything
> else needs to be done.
Yes, please work on getting it out of staging.
If you think it's ready, then submit a patch that moves it, copying the
proper maintainers, and I'll be glad to review it.
thanks,
greg k-h
^ permalink raw reply
* Re: doubt about sm7xxfb (was: Re: [PATCH v4 0/7] staging: fsl-mc: New functionality to the MC bus dr
From: Joe Perches @ 2015-06-13 16:57 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: Greg KH, devel, linux-fbdev, tomi.valkeinen, linux-kernel,
dan.carpenter
In-Reply-To: <20150613162839.GA14842@kroah.com>
On Sat, 2015-06-13 at 09:28 -0700, Greg KH wrote:
> On Sat, Jun 13, 2015 at 02:16:18PM +0530, Sudip Mukherjee wrote:
[]
> > Your reply above was for a different thread but my doubt started from
> > this. I was working on adding the Dual-Head support to sm7xxfb. So that
> > is also a new functionality which is not in the current driver as of now.
> > Then should i instead concentrate on getting that out of staging? If yes,
> > can you please have a look (when you are free) at it to see if anything
> > else needs to be done.
>
> Yes, please work on getting it out of staging.
>
> If you think it's ready, then submit a patch that moves it, copying the
> proper maintainers, and I'll be glad to review it.
It seems ready to me.
As far as I can tell, there's just a few niggles
that could be done:
Something like (too lazy to separate them into multiple patches)
o reduce indentation a couple of places
o add newlines to logging messages
o add const to static array
o use consistent function declaration style
It's unfortunate there are so many #ifdef __BIG_ENDIAN uses.
---
drivers/staging/sm7xxfb/sm7xxfb.c | 203 ++++++++++++++++++--------------------
1 file changed, 96 insertions(+), 107 deletions(-)
diff --git a/drivers/staging/sm7xxfb/sm7xxfb.c b/drivers/staging/sm7xxfb/sm7xxfb.c
index 5db26f1..5be2560 100644
--- a/drivers/staging/sm7xxfb/sm7xxfb.c
+++ b/drivers/staging/sm7xxfb/sm7xxfb.c
@@ -94,7 +94,7 @@ struct vesa_mode {
u16 lfb_depth;
};
-static struct vesa_mode vesa_mode_table[] = {
+static const struct vesa_mode vesa_mode_table[] = {
{"0x301", 640, 480, 8},
{"0x303", 800, 600, 8},
{"0x305", 1024, 768, 8},
@@ -255,37 +255,32 @@ static int smtc_setcolreg(unsigned regno, unsigned red, unsigned green,
/*
* 16/32 bit true-colour, use pseudo-palette for 16 base color
*/
- if (regno < 16) {
- if (sfb->fb->var.bits_per_pixel = 16) {
- u32 *pal = sfb->fb->pseudo_palette;
-
- val = chan_to_field(red, &sfb->fb->var.red);
- val |= chan_to_field(green,
- &sfb->fb->var.green);
- val |= chan_to_field(blue, &sfb->fb->var.blue);
+ if (regno >= 16)
+ break;
+ if (sfb->fb->var.bits_per_pixel = 16) {
+ u32 *pal = sfb->fb->pseudo_palette;
+
+ val = chan_to_field(red, &sfb->fb->var.red);
+ val |= chan_to_field(green, &sfb->fb->var.green);
+ val |= chan_to_field(blue, &sfb->fb->var.blue);
#ifdef __BIG_ENDIAN
- pal[regno] - ((red & 0xf800) >> 8) |
- ((green & 0xe000) >> 13) |
- ((green & 0x1c00) << 3) |
- ((blue & 0xf800) >> 3);
+ pal[regno] = (((red & 0xf800) >> 8) |
+ ((green & 0xe000) >> 13) |
+ ((green & 0x1c00) << 3) |
+ ((blue & 0xf800) >> 3));
#else
- pal[regno] = val;
+ pal[regno] = val;
#endif
- } else {
- u32 *pal = sfb->fb->pseudo_palette;
+ } else {
+ u32 *pal = sfb->fb->pseudo_palette;
- val = chan_to_field(red, &sfb->fb->var.red);
- val |= chan_to_field(green,
- &sfb->fb->var.green);
- val |= chan_to_field(blue, &sfb->fb->var.blue);
+ val = chan_to_field(red, &sfb->fb->var.red);
+ val |= chan_to_field(green, &sfb->fb->var.green);
+ val |= chan_to_field(blue, &sfb->fb->var.blue);
#ifdef __BIG_ENDIAN
- val - (val & 0xff00ff00 >> 8) |
- (val & 0x00ff00ff << 8);
+ val = (val & 0xff00ff00 >> 8) | (val & 0x00ff00ff << 8);
#endif
- pal[regno] = val;
- }
+ pal[regno] = val;
}
break;
@@ -302,8 +297,8 @@ static int smtc_setcolreg(unsigned regno, unsigned red, unsigned green,
}
#ifdef __BIG_ENDIAN
-static ssize_t smtcfb_read(struct fb_info *info, char __user *buf, size_t
- count, loff_t *ppos)
+static ssize_t smtcfb_read(struct fb_info *info, char __user *buf,
+ size_t count, loff_t *ppos)
{
unsigned long p = *ppos;
@@ -346,9 +341,8 @@ static ssize_t smtcfb_read(struct fb_info *info, char __user *buf, size_t
dst = buffer;
for (i = c >> 2; i--;) {
*dst = fb_readl(src++);
- *dst - (*dst & 0xff00ff00 >> 8) |
- (*dst & 0x00ff00ff << 8);
+ *dst = (*dst & 0xff00ff00 >> 8) |
+ (*dst & 0x00ff00ff << 8);
dst++;
}
if (c & 3) {
@@ -381,9 +375,8 @@ static ssize_t smtcfb_read(struct fb_info *info, char __user *buf, size_t
return (err) ? err : cnt;
}
-static ssize_t
-smtcfb_write(struct fb_info *info, const char __user *buf, size_t count,
- loff_t *ppos)
+static ssize_t smtcfb_write(struct fb_info *info, const char __user *buf,
+ size_t count, loff_t *ppos)
{
unsigned long p = *ppos;
@@ -478,72 +471,69 @@ static void sm7xx_set_timing(struct smtcfb_info *sfb)
sfb->width, sfb->height, sfb->fb->var.bits_per_pixel, sfb->hz);
for (j = 0; j < numvgamodes; j++) {
- if (vgamode[j].mmsizex = sfb->width &&
- vgamode[j].mmsizey = sfb->height &&
- vgamode[j].bpp = sfb->fb->var.bits_per_pixel &&
- vgamode[j].hz = sfb->hz) {
- dev_dbg(&sfb->pdev->dev,
- "vgamode[j].mmsizex=%d vgamode[j].mmSizeY=%d vgamode[j].bpp=%d vgamode[j].hz=%d\n",
- vgamode[j].mmsizex, vgamode[j].mmsizey,
- vgamode[j].bpp, vgamode[j].hz);
-
- dev_dbg(&sfb->pdev->dev, "vgamode index=%d\n", j);
-
- smtc_mmiowb(0x0, 0x3c6);
-
- smtc_seqw(0, 0x1);
-
- smtc_mmiowb(vgamode[j].init_misc, 0x3c2);
-
- /* init SEQ register SR00 - SR04 */
- for (i = 0; i < SIZE_SR00_SR04; i++)
- smtc_seqw(i, vgamode[j].init_sr00_sr04[i]);
-
- /* init SEQ register SR10 - SR24 */
- for (i = 0; i < SIZE_SR10_SR24; i++)
- smtc_seqw(i + 0x10,
- vgamode[j].init_sr10_sr24[i]);
-
- /* init SEQ register SR30 - SR75 */
- for (i = 0; i < SIZE_SR30_SR75; i++)
- if ((i + 0x30) != 0x62 &&
- (i + 0x30) != 0x6a &&
- (i + 0x30) != 0x6b)
- smtc_seqw(i + 0x30,
- vgamode[j].init_sr30_sr75[i]);
-
- /* init SEQ register SR80 - SR93 */
- for (i = 0; i < SIZE_SR80_SR93; i++)
- smtc_seqw(i + 0x80,
- vgamode[j].init_sr80_sr93[i]);
-
- /* init SEQ register SRA0 - SRAF */
- for (i = 0; i < SIZE_SRA0_SRAF; i++)
- smtc_seqw(i + 0xa0,
- vgamode[j].init_sra0_sraf[i]);
-
- /* init Graphic register GR00 - GR08 */
- for (i = 0; i < SIZE_GR00_GR08; i++)
- smtc_grphw(i, vgamode[j].init_gr00_gr08[i]);
-
- /* init Attribute register AR00 - AR14 */
- for (i = 0; i < SIZE_AR00_AR14; i++)
- smtc_attrw(i, vgamode[j].init_ar00_ar14[i]);
-
- /* init CRTC register CR00 - CR18 */
- for (i = 0; i < SIZE_CR00_CR18; i++)
- smtc_crtcw(i, vgamode[j].init_cr00_cr18[i]);
-
- /* init CRTC register CR30 - CR4D */
- for (i = 0; i < SIZE_CR30_CR4D; i++)
- smtc_crtcw(i + 0x30,
- vgamode[j].init_cr30_cr4d[i]);
-
- /* init CRTC register CR90 - CRA7 */
- for (i = 0; i < SIZE_CR90_CRA7; i++)
- smtc_crtcw(i + 0x90,
- vgamode[j].init_cr90_cra7[i]);
+ if (vgamode[j].mmsizex != sfb->width ||
+ vgamode[j].mmsizey != sfb->height ||
+ vgamode[j].bpp != sfb->fb->var.bits_per_pixel ||
+ vgamode[j].hz != sfb->hz)
+ continue;
+
+ dev_dbg(&sfb->pdev->dev,
+ "vgamode[j].mmsizex=%d vgamode[j].mmSizeY=%d vgamode[j].bpp=%d vgamode[j].hz=%d\n",
+ vgamode[j].mmsizex, vgamode[j].mmsizey,
+ vgamode[j].bpp, vgamode[j].hz);
+
+ dev_dbg(&sfb->pdev->dev, "vgamode index=%d\n", j);
+
+ smtc_mmiowb(0x0, 0x3c6);
+
+ smtc_seqw(0, 0x1);
+
+ smtc_mmiowb(vgamode[j].init_misc, 0x3c2);
+
+ /* init SEQ register SR00 - SR04 */
+ for (i = 0; i < SIZE_SR00_SR04; i++)
+ smtc_seqw(i, vgamode[j].init_sr00_sr04[i]);
+
+ /* init SEQ register SR10 - SR24 */
+ for (i = 0; i < SIZE_SR10_SR24; i++)
+ smtc_seqw(i + 0x10, vgamode[j].init_sr10_sr24[i]);
+
+ /* init SEQ register SR30 - SR75 */
+ for (i = 0; i < SIZE_SR30_SR75; i++) {
+ if ((i + 0x30) != 0x62 &&
+ (i + 0x30) != 0x6a &&
+ (i + 0x30) != 0x6b)
+ smtc_seqw(i + 0x30,
+ vgamode[j].init_sr30_sr75[i]);
}
+
+ /* init SEQ register SR80 - SR93 */
+ for (i = 0; i < SIZE_SR80_SR93; i++)
+ smtc_seqw(i + 0x80, vgamode[j].init_sr80_sr93[i]);
+
+ /* init SEQ register SRA0 - SRAF */
+ for (i = 0; i < SIZE_SRA0_SRAF; i++)
+ smtc_seqw(i + 0xa0, vgamode[j].init_sra0_sraf[i]);
+
+ /* init Graphic register GR00 - GR08 */
+ for (i = 0; i < SIZE_GR00_GR08; i++)
+ smtc_grphw(i, vgamode[j].init_gr00_gr08[i]);
+
+ /* init Attribute register AR00 - AR14 */
+ for (i = 0; i < SIZE_AR00_AR14; i++)
+ smtc_attrw(i, vgamode[j].init_ar00_ar14[i]);
+
+ /* init CRTC register CR00 - CR18 */
+ for (i = 0; i < SIZE_CR00_CR18; i++)
+ smtc_crtcw(i, vgamode[j].init_cr00_cr18[i]);
+
+ /* init CRTC register CR30 - CR4D */
+ for (i = 0; i < SIZE_CR30_CR4D; i++)
+ smtc_crtcw(i + 0x30, vgamode[j].init_cr30_cr4d[i]);
+
+ /* init CRTC register CR90 - CRA7 */
+ for (i = 0; i < SIZE_CR90_CRA7; i++)
+ smtc_crtcw(i + 0x90, vgamode[j].init_cr90_cra7[i]);
}
smtc_mmiowb(0x67, 0x3c2);
@@ -552,8 +542,7 @@ static void sm7xx_set_timing(struct smtcfb_info *sfb)
writel(0x0, sfb->vp_regs + 0x40);
/* set data width */
- m_nscreenstride - (sfb->width * sfb->fb->var.bits_per_pixel) / 64;
+ m_nscreenstride = (sfb->width * sfb->fb->var.bits_per_pixel) / 64;
switch (sfb->fb->var.bits_per_pixel) {
case 8:
writel(0x0, sfb->vp_regs + 0x0);
@@ -741,7 +730,7 @@ static int smtcfb_pci_probe(struct pci_dev *pdev,
int err;
unsigned long mmio_base;
- dev_info(&pdev->dev, "Silicon Motion display driver.");
+ dev_info(&pdev->dev, "Silicon Motion display driver\n");
err = pci_enable_device(pdev); /* enable SMTC chip */
if (err)
@@ -815,12 +804,12 @@ static int smtcfb_pci_probe(struct pci_dev *pdev,
#ifdef __BIG_ENDIAN
if (sfb->fb->var.bits_per_pixel = 32) {
sfb->lfb += 0x800000;
- dev_info(&pdev->dev, "sfb->lfb=%p", sfb->lfb);
+ dev_info(&pdev->dev, "sfb->lfb=%p\n", sfb->lfb);
}
#endif
if (!smtc_regbaseaddress) {
dev_err(&pdev->dev,
- "%s: unable to map memory mapped IO!",
+ "%s: unable to map memory mapped IO!\n",
sfb->fb->fix.id);
err = -ENOMEM;
goto failed_fb;
@@ -854,7 +843,7 @@ static int smtcfb_pci_probe(struct pci_dev *pdev,
break;
default:
dev_err(&pdev->dev,
- "No valid Silicon Motion display chip was detected!");
+ "No valid Silicon Motion display chip was detected!\n");
goto failed_fb;
}
@@ -876,14 +865,14 @@ static int smtcfb_pci_probe(struct pci_dev *pdev,
goto failed;
dev_info(&pdev->dev,
- "Silicon Motion SM%X Rev%X primary display mode %dx%d-%d Init Complete.",
+ "Silicon Motion SM%X Rev%X primary display mode %dx%d-%d Init Complete\n",
sfb->chip_id, sfb->chip_rev_id, sfb->fb->var.xres,
sfb->fb->var.yres, sfb->fb->var.bits_per_pixel);
return 0;
failed:
- dev_err(&pdev->dev, "Silicon Motion, Inc. primary display init fail.");
+ dev_err(&pdev->dev, "Silicon Motion, Inc. primary display init failed\n");
smtc_unmap_smem(sfb);
smtc_unmap_mmio(sfb);
^ permalink raw reply related
* Re: [PATCH 00/21] On-demand device registration
From: Alexander Holler @ 2015-06-13 18:27 UTC (permalink / raw)
To: Linus Walleij
Cc: Mark Rutland, devicetree@vger.kernel.org,
linux-fbdev@vger.kernel.org, linux-samsung-soc, dmaengine,
Tomeu Vizoso, linux-gpio@vger.kernel.org,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pwm@vger.kernel.org, linux-tegra@vger.kernel.org,
Rob Herring, DRM PANEL DRIVERS, Grant Likely, Dan Williams,
Dmitry Torokhov, linux-usb, linux-i2c
In-Reply-To: <557AC437.9000607@ahsoftware.de>
Am 12.06.2015 um 13:36 schrieb Alexander Holler:
> Am 12.06.2015 um 13:19 schrieb Alexander Holler:
>> Am 12.06.2015 um 09:25 schrieb Linus Walleij:
>>> On Thu, Jun 11, 2015 at 6:40 PM, Alexander Holler
>>> <holler@ahsoftware.de> wrote:
>>>> Am 11.06.2015 um 14:30 schrieb Linus Walleij:
>>>
>>>>> Certainly it is possible to create deadlocks in this scenario, but the
>>>>> scope is not to create an ubreakable system.
>>>>
>>>> IAnd what happens if you run into a deadlock? Do you print "you've
>>>> lost, try
>>>> changing your kernel config" in some output hidden by a
>>>> splash-screen? ;)
>>>
>>> Sorry it sounds like a blanket argument, the fact that there are
>>> mutexes in the kernel makes it possible to deadlock, it doesn't
>>> mean we don't use mutexes. Some programming problems are
>>> just like such.
>>
>> I'm not talking about specific deadlocks through mutexes. I'm talking
>> about what happens when driver A needs driver B which needs driver A.
>> How do you recognise and handle that with your instrumented on-demand
>> device initialization? Such a circular dependency might happen by just
>> adding a new fucntion call or by changing the kernel configuration. And
>> with the on-demand stuff, the possibility that the developer introducing
>> this new (maybe optional) call will never hit such a circular dependency
>> is high. So you will end up with a never ending stream of problem
>> reports whenever someone introduced such a circular dependecy without
>> having noticed it.
>>
>> And to come back to specific deadlocks, if you are extending function
>> calls from something former simple to something which might initialize a
>> whole bunch of drivers, needing maybe seconds, I wouldn't say this is a
>> blanket argument, but a real thread.
>
> Keep in mind, that the possibility that a function call ends up with
> initializing a whole bunch of other drivers, is not determined
> statically, but depends on the configuration and runtime behaviour of
> the actual system the on-demand stuff actually happens.
>
> E.g. if driver A is faster one system that driver B, the whole bunch of
> drivers might become initialized by a call in driver A. But if driver B
> was faster on the developers system (or the system is configured to
> first init driver B), than the whole bunch of drivers might have become
> initialized by driver B on the developers system. Thus he never might
> have hit a possible problem when the whole bunch of drivers got
> initialized in driver A.
>
> That means it isn't always a good idea to create dynamic systems (like
> on-demand device initialization), because it's very hard to foresee and
> correctly handle their runtime behaviour.
And because you've said that "problem space is a bit convoluted" and I
disagree, here's a summary from my point of view:
1. All the necessary information (dependencies between drivers) already
exists at compile time. The set of dependencies between drivers might
become smaller by configuration, but will not become larger. So there
should be NO need to collect them at runtime, e.g. by instrumenting
function calls. I've described the problems I see with that above. I've
choosen DT as source of dependencies because it offers an easy
accessible and almost complete set of dependencies. I just had to add
some type information to the dtb in order to identify the dependencies
(phandles). But other ways to collect the dependencies would work too.
Even the most simple way to add a static list of dependencies to each
driver (which later on might be automated by some more clever stuff than
adding them manually) would do the trick.
2. The problem to sort a set of nodes (drivers) with dependencies is
solved since a long time and almost any developers uses it regularly in
form of make. And everyone who used make -jN knows that the possible
parallel initialization of drivers I've talked about, is already solved too.
3. In order to initialize the drivers in some specific order, their
initcalls must be identified. I've offered a possible solution to that
without much changes, but many other, even better ways, are possible
too. It just depends on how much you want to change and on how much of
these changes you will be able to feed into mainline kernel (which
depends on your connections/relations inside the core kernel crew). E.g.
instead of still just relying on one-dimensional arrays with (anonymous)
pointers to initcalls, a multidimensional array of initcalls and
drivername (and maybe more information) might be thinkable.
4. x86/amd64/ACPI-people, so most longtime and core kernel maintainers
obviously don't have much interest until you've solved 1. in a way they
can use too. So the necessary changes for 2. or 3. will have a big
hurdle to take if 1. isn't solved usable for them too.
>> Alexander Holler
^ permalink raw reply
* [RFC v2 13/24] powerpc: Cleanup nvram includes
From: Finn Thain @ 2015-06-14 7:46 UTC (permalink / raw)
To: linux-kernel, linux-m68k, linuxppc-dev, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Arnd Bergmann,
Greg Kroah-Hartman, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, linux-fbdev
In-Reply-To: <20150614074607.242676098@telegraphics.com.au>
The nvram_read_byte() and nvram_write_byte() definitions in asm/nvram.h
duplicate those in linux/nvram.h. Get rid of the former to prepare for
adoption of struct arch_nvram_ops (which is defined in linux/nvram.h for
general use).
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
---
arch/powerpc/include/asm/nvram.h | 3 ---
arch/powerpc/kernel/setup_32.c | 1 +
drivers/char/generic_nvram.c | 4 +++-
drivers/video/fbdev/matrox/matroxfb_base.c | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
Index: linux/arch/powerpc/include/asm/nvram.h
=================================--- linux.orig/arch/powerpc/include/asm/nvram.h 2015-06-14 17:45:34.000000000 +1000
+++ linux/arch/powerpc/include/asm/nvram.h 2015-06-14 17:45:49.000000000 +1000
@@ -101,7 +101,4 @@ extern int nvram_write_os_partition(stru
/* Determine NVRAM size */
extern ssize_t nvram_get_size(void);
-/* Normal access to NVRAM */
-extern unsigned char nvram_read_byte(int i);
-extern void nvram_write_byte(unsigned char c, int i);
#endif /* _ASM_POWERPC_NVRAM_H */
Index: linux/arch/powerpc/kernel/setup_32.c
=================================--- linux.orig/arch/powerpc/kernel/setup_32.c 2015-06-14 17:45:34.000000000 +1000
+++ linux/arch/powerpc/kernel/setup_32.c 2015-06-14 17:45:49.000000000 +1000
@@ -16,6 +16,7 @@
#include <linux/cpu.h>
#include <linux/console.h>
#include <linux/memblock.h>
+#include <linux/nvram.h>
#include <asm/io.h>
#include <asm/prom.h>
Index: linux/drivers/char/generic_nvram.c
=================================--- linux.orig/drivers/char/generic_nvram.c 2015-06-14 17:45:34.000000000 +1000
+++ linux/drivers/char/generic_nvram.c 2015-06-14 17:45:49.000000000 +1000
@@ -20,9 +20,11 @@
#include <linux/fcntl.h>
#include <linux/init.h>
#include <linux/mutex.h>
+#include <linux/nvram.h>
#include <asm/uaccess.h>
-#include <asm/nvram.h>
+
#ifdef CONFIG_PPC_PMAC
+#include <asm/nvram.h>
#include <asm/machdep.h>
#endif
Index: linux/drivers/video/fbdev/matrox/matroxfb_base.c
=================================--- linux.orig/drivers/video/fbdev/matrox/matroxfb_base.c 2015-06-14 17:45:34.000000000 +1000
+++ linux/drivers/video/fbdev/matrox/matroxfb_base.c 2015-06-14 17:45:49.000000000 +1000
@@ -111,12 +111,12 @@
#include "matroxfb_g450.h"
#include <linux/matroxfb.h>
#include <linux/interrupt.h>
+#include <linux/nvram.h>
#include <linux/slab.h>
#include <linux/uaccess.h>
#ifdef CONFIG_PPC_PMAC
#include <asm/machdep.h>
-unsigned char nvram_read_byte(int);
static int default_vmode = VMODE_NVRAM;
static int default_cmode = CMODE_NVRAM;
#endif
^ permalink raw reply
* [RFC v2 17/24] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_wri
From: Finn Thain @ 2015-06-14 7:46 UTC (permalink / raw)
To: linux-kernel, linux-m68k, linuxppc-dev, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Arnd Bergmann,
Greg Kroah-Hartman, Jean-Christophe Plagniol-Villard,
Tomi Valkeinen, linux-fbdev
In-Reply-To: <20150614074607.242676098@telegraphics.com.au>
Make use of arch_nvram_ops in device drivers so that the nvram_*
function exports can be removed.
Since they are no longer global symbols, rename the PPC32 nvram_* functions
appropriately.
Add the missing CONFIG_NVRAM test to imsttfb to avoid a build failure.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
---
arch/powerpc/kernel/setup_32.c | 8 ++++----
drivers/char/generic_nvram.c | 4 ++--
drivers/video/fbdev/controlfb.c | 4 ++--
drivers/video/fbdev/imsttfb.c | 7 +++----
drivers/video/fbdev/matrox/matroxfb_base.c | 2 +-
drivers/video/fbdev/platinumfb.c | 4 ++--
drivers/video/fbdev/valkyriefb.c | 4 ++--
7 files changed, 16 insertions(+), 17 deletions(-)
Index: linux/arch/powerpc/kernel/setup_32.c
=================================--- linux.orig/arch/powerpc/kernel/setup_32.c 2015-06-14 17:45:53.000000000 +1000
+++ linux/arch/powerpc/kernel/setup_32.c 2015-06-14 17:45:54.000000000 +1000
@@ -170,20 +170,18 @@ __setup("l3cr=", ppc_setup_l3cr);
#ifdef CONFIG_GENERIC_NVRAM
-unsigned char nvram_read_byte(int addr)
+static unsigned char ppc_nvram_read_byte(int addr)
{
if (ppc_md.nvram_read_val)
return ppc_md.nvram_read_val(addr);
return 0xff;
}
-EXPORT_SYMBOL(nvram_read_byte);
-void nvram_write_byte(unsigned char val, int addr)
+static void ppc_nvram_write_byte(unsigned char val, int addr)
{
if (ppc_md.nvram_write_val)
ppc_md.nvram_write_val(addr, val);
}
-EXPORT_SYMBOL(nvram_write_byte);
static ssize_t ppc_nvram_get_size(void)
{
@@ -200,6 +198,8 @@ static long ppc_nvram_sync(void)
}
const struct nvram_ops arch_nvram_ops = {
+ .read_byte = ppc_nvram_read_byte,
+ .write_byte = ppc_nvram_write_byte,
.get_size = ppc_nvram_get_size,
.sync = ppc_nvram_sync,
};
Index: linux/drivers/char/generic_nvram.c
=================================--- linux.orig/drivers/char/generic_nvram.c 2015-06-14 17:45:53.000000000 +1000
+++ linux/drivers/char/generic_nvram.c 2015-06-14 17:45:54.000000000 +1000
@@ -64,7 +64,7 @@ static ssize_t read_nvram(struct file *f
if (*ppos >= nvram_len)
return 0;
for (i = *ppos; count > 0 && i < nvram_len; ++i, ++p, --count)
- if (__put_user(nvram_read_byte(i), p))
+ if (__put_user(arch_nvram_ops.read_byte(i), p))
return -EFAULT;
*ppos = i;
return p - buf;
@@ -84,7 +84,7 @@ static ssize_t write_nvram(struct file *
for (i = *ppos; count > 0 && i < nvram_len; ++i, ++p, --count) {
if (__get_user(c, p))
return -EFAULT;
- nvram_write_byte(c, i);
+ arch_nvram_ops.write_byte(c, i);
}
*ppos = i;
return p - buf;
Index: linux/drivers/video/fbdev/controlfb.c
=================================--- linux.orig/drivers/video/fbdev/controlfb.c 2015-06-14 17:45:34.000000000 +1000
+++ linux/drivers/video/fbdev/controlfb.c 2015-06-14 17:45:54.000000000 +1000
@@ -415,7 +415,7 @@ static int __init init_control(struct fb
/* Try to pick a video mode out of NVRAM if we have one. */
#ifdef CONFIG_NVRAM
if (default_cmode = CMODE_NVRAM) {
- cmode = nvram_read_byte(NV_CMODE);
+ cmode = arch_nvram_ops.read_byte(NV_CMODE);
if(cmode < CMODE_8 || cmode > CMODE_32)
cmode = CMODE_8;
} else
@@ -423,7 +423,7 @@ static int __init init_control(struct fb
cmodeÞfault_cmode;
#ifdef CONFIG_NVRAM
if (default_vmode = VMODE_NVRAM) {
- vmode = nvram_read_byte(NV_VMODE);
+ vmode = arch_nvram_ops.read_byte(NV_VMODE);
if (vmode < 1 || vmode > VMODE_MAX ||
control_mac_modes[vmode - 1].m[full] < cmode) {
sense = read_control_sense(p);
Index: linux/drivers/video/fbdev/matrox/matroxfb_base.c
=================================--- linux.orig/drivers/video/fbdev/matrox/matroxfb_base.c 2015-06-14 17:45:49.000000000 +1000
+++ linux/drivers/video/fbdev/matrox/matroxfb_base.c 2015-06-14 17:45:54.000000000 +1000
@@ -1888,7 +1888,7 @@ static int initMatrox2(struct matrox_fb_
default_vmode = VMODE_640_480_60;
#ifdef CONFIG_NVRAM
if (default_cmode = CMODE_NVRAM)
- default_cmode = nvram_read_byte(NV_CMODE);
+ default_cmode = arch_nvram_ops.read_byte(NV_CMODE);
#endif
if (default_cmode < CMODE_8 || default_cmode > CMODE_32)
default_cmode = CMODE_8;
Index: linux/drivers/video/fbdev/platinumfb.c
=================================--- linux.orig/drivers/video/fbdev/platinumfb.c 2015-06-14 17:45:34.000000000 +1000
+++ linux/drivers/video/fbdev/platinumfb.c 2015-06-14 17:45:54.000000000 +1000
@@ -349,7 +349,7 @@ static int platinum_init_fb(struct fb_in
printk(KERN_INFO "platinumfb: Monitor sense value = 0x%x, ", sense);
if (default_vmode = VMODE_NVRAM) {
#ifdef CONFIG_NVRAM
- default_vmode = nvram_read_byte(NV_VMODE);
+ default_vmode = arch_nvram_ops.read_byte(NV_VMODE);
if (default_vmode <= 0 || default_vmode > VMODE_MAX ||
!platinum_reg_init[default_vmode-1])
#endif
@@ -362,7 +362,7 @@ static int platinum_init_fb(struct fb_in
default_vmode = VMODE_640_480_60;
#ifdef CONFIG_NVRAM
if (default_cmode = CMODE_NVRAM)
- default_cmode = nvram_read_byte(NV_CMODE);
+ default_cmode = arch_nvram_ops.read_byte(NV_CMODE);
#endif
if (default_cmode < CMODE_8 || default_cmode > CMODE_32)
default_cmode = CMODE_8;
Index: linux/drivers/video/fbdev/valkyriefb.c
=================================--- linux.orig/drivers/video/fbdev/valkyriefb.c 2015-06-14 17:45:34.000000000 +1000
+++ linux/drivers/video/fbdev/valkyriefb.c 2015-06-14 17:45:54.000000000 +1000
@@ -287,7 +287,7 @@ static void __init valkyrie_choose_mode(
/* Try to pick a video mode out of NVRAM if we have one. */
#if !defined(CONFIG_MAC) && defined(CONFIG_NVRAM)
if (default_vmode = VMODE_NVRAM) {
- default_vmode = nvram_read_byte(NV_VMODE);
+ default_vmode = arch_nvram_ops.read_byte(NV_VMODE);
if (default_vmode <= 0
|| default_vmode > VMODE_MAX
|| !valkyrie_reg_init[default_vmode - 1])
@@ -300,7 +300,7 @@ static void __init valkyrie_choose_mode(
default_vmode = VMODE_640_480_67;
#if !defined(CONFIG_MAC) && defined(CONFIG_NVRAM)
if (default_cmode = CMODE_NVRAM)
- default_cmode = nvram_read_byte(NV_CMODE);
+ default_cmode = arch_nvram_ops.read_byte(NV_CMODE);
#endif
/*
Index: linux/drivers/video/fbdev/imsttfb.c
=================================--- linux.orig/drivers/video/fbdev/imsttfb.c 2015-06-14 17:45:34.000000000 +1000
+++ linux/drivers/video/fbdev/imsttfb.c 2015-06-14 17:45:54.000000000 +1000
@@ -328,7 +328,6 @@ enum {
TVP = 1
};
-#define USE_NV_MODES 1
#define INIT_BPP 8
#define INIT_XRES 640
#define INIT_YRES 480
@@ -1391,17 +1390,17 @@ static void init_imstt(struct fb_info *i
}
}
-#if USE_NV_MODES && defined(CONFIG_PPC32)
+#if defined(CONFIG_NVRAM) && defined(CONFIG_PPC32)
{
int vmode = init_vmode, cmode = init_cmode;
if (vmode = -1) {
- vmode = nvram_read_byte(NV_VMODE);
+ vmode = arch_nvram_ops.read_byte(NV_VMODE);
if (vmode <= 0 || vmode > VMODE_MAX)
vmode = VMODE_640_480_67;
}
if (cmode = -1) {
- cmode = nvram_read_byte(NV_CMODE);
+ cmode = arch_nvram_ops.read_byte(NV_CMODE);
if (cmode < CMODE_8 || cmode > CMODE_32)
cmode = CMODE_8;
}
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox