kernel/drivers/video/fbdev/da8xx-fb.c, branch linux-5.1.y

cross-tree: phase out dma_zalloc_coherent()

2019-01-08T12:58:37Z

We already need to zero out memory for dma_alloc_coherent(), as such using dma_zalloc_coherent() is superflous. Phase it out. This change was generated with the following Coccinelle SmPL patch: @ replace_dma_zalloc_coherent @ expression dev, size, data, handle, flags; @@ -dma_zalloc_coherent(dev, size, handle, flags) +dma_alloc_coherent(dev, size, handle, flags) Suggested-by: Christoph Hellwig Signed-off-by: Luis Chamberlain [hch: re-ran the script on the latest tree] Signed-off-by: Christoph Hellwig

fbdev: da8xx-fb: Drop unnecessary static

2017-08-01T15:20:39Z

Drop static on a local variable, when the variable is initialized before any possible use. Thus, the static has no benefit. The semantic patch that fixes this problem is as follows: (http://coccinelle.lip6.fr/) // @bad exists@ position p; identifier x; type T; @@ static T x@p; ... x = <+...x...+> @@ identifier x; expression e; type T; position p != bad.p; @@ -static T x@p; ... when != x when strict ?x = e; // Signed-off-by: Julia Lawall Cc: Kees Cook Signed-off-by: Bartlomiej Zolnierkiewicz

remove lots of IS_ERR_VALUE abuses

2016-05-27T22:26:11Z

Most users of IS_ERR_VALUE() in the kernel are wrong, as they pass an 'int' into a function that takes an 'unsigned long' argument. This happens to work because the type is sign-extended on 64-bit architectures before it gets converted into an unsigned type. However, anything that passes an 'unsigned short' or 'unsigned int' argument into IS_ERR_VALUE() is guaranteed to be broken, as are 8-bit integers and types that are wider than 'unsigned long'. Andrzej Hajda has already fixed a lot of the worst abusers that were causing actual bugs, but it would be nice to prevent any users that are not passing 'unsigned long' arguments. This patch changes all users of IS_ERR_VALUE() that I could find on 32-bit ARM randconfig builds and x86 allmodconfig. For the moment, this doesn't change the definition of IS_ERR_VALUE() because there are probably still architecture specific users elsewhere. Almost all the warnings I got are for files that are better off using 'if (err)' or 'if (err < 0)'. The only legitimate user I could find that we get a warning for is the (32-bit only) freescale fman driver, so I did not remove the IS_ERR_VALUE() there but changed the type to 'unsigned long'. For 9pfs, I just worked around one user whose calling conventions are so obscure that I did not dare change the behavior. I was using this definition for testing: #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \ unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO)) which ends up making all 16-bit or wider types work correctly with the most plausible interpretation of what IS_ERR_VALUE() was supposed to return according to its users, but also causes a compile-time warning for any users that do not pass an 'unsigned long' argument. I suggested this approach earlier this year, but back then we ended up deciding to just fix the users that are obviously broken. After the initial warning that caused me to get involved in the discussion (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus asked me to send the whole thing again. [ Updated the 9p parts as per Al Viro - Linus ] Signed-off-by: Arnd Bergmann Cc: Andrzej Hajda Cc: Andrew Morton Link: https://lkml.org/lkml/2016/1/7/363 Link: https://lkml.org/lkml/2016/5/27/486 Acked-by: Srinivas Kandagatla # For nvmem part Signed-off-by: Linus Torvalds

fbdev: da8xx-fb: fix videomodes of lcd panels

2016-02-29T16:29:52Z

Commit 028cd86b794f4a ("video: da8xx-fb: fix the polarities of the hsync/vsync pulse") fixes polarities of HSYNC/VSYNC pulse but forgot to update known_lcd_panels[] which had sync values according to old logic. This breaks LCD at least on DA850 EVM. This patch fixes this issue and I have tested this for panel "Sharp_LK043T1DG01" using DA850 EVM board. Fixes: 028cd86b794f4a ("video: da8xx-fb: fix the polarities of the hsync/vsync pulse") Signed-off-by: Sushaanth Srirangapathi Signed-off-by: Tomi Valkeinen

fbdev: da8xx-fb: remove incorrect type cast

2016-01-29T11:37:42Z

The probe function correct passes a dma_addr_t pointer into dma_alloc_coherent(), but has a cast to resource_size_t, which might be different from dma_addr_t: drivers/video/fbdev/da8xx-fb.c: In function 'fb_probe': drivers/video/fbdev/da8xx-fb.c:1431:10: error: passing argument 3 of 'dma_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types] This removes the cast, which avoids the warning. Signed-off-by: Arnd Bergmann Signed-off-by: Tomi Valkeinen

video: fbdev: drop owner assignment from platform_drivers

2014-10-20T14:21:51Z

A platform_driver does not need to set an owner, it will be populated by the driver core. Signed-off-by: Wolfram Sang

video: da8xx-fb: preserve display width when changing HSYNC

2014-08-26T12:36:51Z

When looking at this driver for a client, I noticed the code that configures the HSYNC pulse clobbers the display width in the same register. It only preserves the MS part of the width in bit 3 and zeros the LS part of the width in bits 9 to 4. This doesn't matter during initialization as the width is configured afterwards, but subsequent use of the FBIPUT_HSYNC ioctl would clobber the width. Preserve bits 9 to 0 of LCD_RASTER_TIMING_0_REG when configuring the horizontal sync. Signed-off-by: Ian Abbott Signed-off-by: Tomi Valkeinen

fbdev: da8xx-fb: Use dma_zalloc_coherent

2014-07-01T10:32:31Z

Use the zeroing function instead of dma_alloc_coherent & memset(,0,) Signed-off-by: Joe Perches Signed-off-by: Tomi Valkeinen

video: da8xx-fb: Add support for Densitron 84-0023-001T

2014-04-22T05:51:27Z

Signed-off-by: Jon Ringle Signed-off-by: Tomi Valkeinen

video: move fbdev to drivers/video/fbdev

2014-04-17T05:10:19Z

The drivers/video directory is a mess. It contains generic video related files, directories for backlight, console, linux logo, lots of fbdev device drivers, fbdev framework files. Make some order into the chaos by creating drivers/video/fbdev directory, and move all fbdev related files there. No functionality is changed, although I guess it is possible that some subtle Makefile build order related issue could be created by this patch. Signed-off-by: Tomi Valkeinen Acked-by: Laurent Pinchart Acked-by: Geert Uytterhoeven Acked-by: Rob Clark Acked-by: Jingoo Han Acked-by: Daniel Vetter