fbdev: Switch back to struct platform_driver::remove()

After commit 0edb555a65d1 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
pla

fbdev: Switch back to struct platform_driver::remove()

After commit 0edb555a65d1 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.

Convert all platform drivers below drivers/video/fbdev to use .remove(),
with the eventual goal to drop struct platform_driver::remove_new(). As
.remove() and .remove_new() have the same prototypes, conversion is done
by just changing the structure member name in the driver initializer.

While touching these files, make indention of the struct initializer
consistent in several files.

Signed-off-by: Uwe Kleine-König <[email protected]>
Reviewed-by: Thomas Zimmermann <[email protected]>
Signed-off-by: Helge Deller <[email protected]>

show more ...

fbdev: vfb: add missing MODULE_DESCRIPTION() macro

With ARCH=x86, make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/video/fbdev/vfb.o

Add the miss

fbdev: vfb: add missing MODULE_DESCRIPTION() macro

With ARCH=x86, make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/video/fbdev/vfb.o

Add the missing invocation of the MODULE_DESCRIPTION() macro.

Signed-off-by: Jeff Johnson <[email protected]>
Signed-off-by: Helge Deller <[email protected]>

show more ...

fbdev: Push pgprot_decrypted() into mmap implementations

If a driver sets struct fb_ops.fb_mmap, the fbdev core automatically
calls pgprot_decrypted(). But the default fb_mmap code doesn't handle
pg

fbdev: Push pgprot_decrypted() into mmap implementations

If a driver sets struct fb_ops.fb_mmap, the fbdev core automatically
calls pgprot_decrypted(). But the default fb_mmap code doesn't handle
pgprot_decrypted().

Move the call to pgprot_decrypted() into each drivers' fb_mmap function.
This only concerns fb_mmap functions for system and DMA memory. For
I/O memory, which is the default case, nothing changes. The fb_mmap
for I/O-memory can later be moved into a helper as well.

DRM's fbdev emulation handles pgprot_decrypted() internally via the
Prime helpers. Fbdev doesn't have to do anything in this case. In
cases where DRM uses deferred I/O, this patch updates fb_mmap correctly.

Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

fbdev/vfb: Initialize fb_ops with fbdev macros

Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in virtual address space. Set the read/write,
draw and mmap cal

fbdev/vfb: Initialize fb_ops with fbdev macros

Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in virtual address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary helpers in Kconfig.

Fbdev drivers sometimes rely on the callbacks being NULL for a
default I/O-memory-based implementation to be invoked; hence
requiring the I/O helpers to be built in any case. Setting all
callbacks in all drivers explicitly will allow to make the I/O
helpers optional. This benefits systems that do not use these
functions.

Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

fbdev/vfb: Set FBINFO_VIRTFB flag

The vfb driver operates on system memory. Mark the framebuffer
accordingly. Helpers operating on the framebuffer memory will test
for the presence of this flag.

Si

fbdev/vfb: Set FBINFO_VIRTFB flag

The vfb driver operates on system memory. Mark the framebuffer
accordingly. Helpers operating on the framebuffer memory will test
for the presence of this flag.

Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

fbdev: Remove FBINFO_FLAG_DEFAULT from framebuffer_alloc()'ed structs

The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). S

fbdev: Remove FBINFO_FLAG_DEFAULT from framebuffer_alloc()'ed structs

The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So
do not set it.

Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.

v4:
* clarify commit message (Geert, Dan)
v2:
* fix commit message (Miguel)

Signed-off-by: Thomas Zimmermann <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Cc: Jaya Kumar <[email protected]>
Cc: Helge Deller <[email protected]>
Cc: Peter Jones <[email protected]>
Cc: Sascha Hauer <[email protected]>
Cc: Pengutronix Kernel Team <[email protected]>
Cc: Shawn Guo <[email protected]>
Cc: Fabio Estevam <[email protected]>
Cc: NXP Linux Team <[email protected]>
Cc: Maik Broemme <[email protected]>
Cc: Jingoo Han <[email protected]>
Cc: Sudip Mukherjee <[email protected]>
Cc: Teddy Wang <[email protected]>
Cc: Michal Januszewski <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

fbdev: vfb: Remove trailing whitespaces

Fix coding style. No functional changes.

Signed-off-by: Thomas Zimmermann <[email protected]>
Acked-by: Helge Deller <[email protected]>
Signed-off-by: Helge D

fbdev: vfb: Remove trailing whitespaces

Fix coding style. No functional changes.

Signed-off-by: Thomas Zimmermann <[email protected]>
Acked-by: Helge Deller <[email protected]>
Signed-off-by: Helge Deller <[email protected]>

show more ...

fbdev/vfb: Use struct fb_info.screen_buffer

Use info->screen_buffer when reading and writing framebuffers in
system memory. It's the correct pointer for this address space.

The struct fb_info has a

fbdev/vfb: Use struct fb_info.screen_buffer

Use info->screen_buffer when reading and writing framebuffers in
system memory. It's the correct pointer for this address space.

The struct fb_info has a union to store the framebuffer memory. This can
either be info->screen_base if the framebuffer is stored in I/O memory,
or info->screen_buffer if the framebuffer is stored in system memory.

As the driver operates on the latter address space, it is wrong to use
.screen_base and .screen_buffer must be used instead. This also gets
rid of casting needed due to not using the correct data type.

Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

fbdev: vfb: Init owner field of struct fb_ops

Initialize the owner field of struct fb_ops. Required to prevent
module unloading while the driver is in use.

Signed-off-by: Thomas Zimmermann <tzimmer

fbdev: vfb: Init owner field of struct fb_ops

Initialize the owner field of struct fb_ops. Required to prevent
module unloading while the driver is in use.

Signed-off-by: Thomas Zimmermann <[email protected]>
Signed-off-by: Helge Deller <[email protected]>

show more ...

fbdev: vfb: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error ha

fbdev: vfb: Convert to platform remove callback returning void

The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Helge Deller <[email protected]>

show more ...

video: constify fb ops across all drivers

Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.

This does not cover all drivers; some actually modify the

video: constify fb ops across all drivers

Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.

This does not cover all drivers; some actually modify the fbops struct,
for example to adjust for different configurations, and others do more
involved things that I'd rather not touch in practically obsolete
drivers. Mostly this is the low hanging fruit where we can add "const"
and be done with it.

v3:
- un-constify atyfb, mb862xx, nvidia and uvesabf (0day)

v2:
- fix typo (Christophe de Dinechin)
- use "static const" instead of "const static" in mx3fb.c
- also constify smscufx.c

Cc: [email protected]
Reviewed-by: Daniel Vetter <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/ce67f14435f3af498f2e8bf35ce4be11f7504132.1575390740.git.jani.nikula@intel.com

show more ...

vfb: fix video mode and line_length being set when loaded

Currently, when loading the vfb module, the newly created fbdev
has a line_length of 0, and its video mode would be PSEUDOCOLOR
regardless o

vfb: fix video mode and line_length being set when loaded

Currently, when loading the vfb module, the newly created fbdev
has a line_length of 0, and its video mode would be PSEUDOCOLOR
regardless of color depth. (The former could be worked around by
calling the FBIOPUT_VSCREENINFO ioctl with having the FBACTIVIATE_FORCE
flag set.) This patch automatically sets the line_length correctly,
and the video mode is derived from the bit depth now as well.

Thanks to Geert Uytterhoeven for confirming the bug and helping me with
the patch.

Output of `fbset -i' before the patch:
mode "1366x768-60"
# D: 72.432 MHz, H: 47.403 kHz, V: 60.004 Hz
geometry 1366 768 1366 768 32
timings 13806 120 10 14 3 32 5
rgba 8/0,8/8,8/16,8/24
endmode

Frame buffer device information:
Name : Virtual FB
Address : 0xffffaa1405d85000
Size : 4196352
Type : PACKED PIXELS
Visual : PSEUDOCOLOR
XPanStep : 1
YPanStep : 1
YWrapStep : 1
LineLength : 0 <-- note this
Accelerator : No

After:
mode "1366x768-60"
# D: 72.432 MHz, H: 47.403 kHz, V: 60.004 Hz
geometry 1366 768 1366 768 32
timings 13806 120 10 14 3 32 5
rgba 8/0,8/8,8/16,8/24
endmode

Frame buffer device information:
Name : Virtual FB
Address : 0xffffaa1405d85000
Size : 4196352
Type : PACKED PIXELS
Visual : TRUECOLOR
XPanStep : 1
YPanStep : 1
YWrapStep : 1
LineLength : 5464
Accelerator : No

Signed-off-by: "Pieter \"PoroCYon\" Sluys" <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
[b.zolnierkie: minor fixups]
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>

show more ...

fbdev: vfb: simplify memory management

Substitute home-brewed memory management for framebuffer memory with what
core mm provide us: vmalloc_32_user() and remap_vmalloc_range()

The former is design

fbdev: vfb: simplify memory management

Substitute home-brewed memory management for framebuffer memory with what
core mm provide us: vmalloc_32_user() and remap_vmalloc_range()

The former is designed to allocate virtually contiguous area which is
32bit addressable and zeroed so it can be mapped to userspace without
leaking data. The latter does the similar job to remap_pfn_range() but
additionally validate vmalloc'ed area and it's size.

Signed-off-by: Vladimir Murzin <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>

show more ...

fbdev: vfb: add option for video mode

Make vfb a bit more flexible in sense what it can represent and allow
the end user to specify video mode parameters via newly introduced module
option "mode". S

fbdev: vfb: add option for video mode

Make vfb a bit more flexible in sense what it can represent and allow
the end user to specify video mode parameters via newly introduced module
option "mode". Since it is test module it is still up to the end user
to make sure there is enough memory to satisfy video mode settings.

Signed-off-by: Vladimir Murzin <[email protected]>
[[email protected]: constified vfb_default]
Signed-off-by: Tomi Valkeinen <[email protected]>

show more ...

fbdev: vfb: add description to module parameters

Add description to "videomemorysize" and "vfb_enable" module parameters to
make them a bit friendly to the end user.

Signed-off-by: Vladimir Murzin

fbdev: vfb: add description to module parameters

Add description to "videomemorysize" and "vfb_enable" module parameters to
make them a bit friendly to the end user.

Signed-off-by: Vladimir Murzin <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>

show more ...

fbdev: remove unnecessary memset in vfb

In vfb_probe memory is allocated using rvmalloc which automatically
sets the allocated memory to zero. This patch removes the second
unnecessary memset in vfb

fbdev: remove unnecessary memset in vfb

In vfb_probe memory is allocated using rvmalloc which automatically
sets the allocated memory to zero. This patch removes the second
unnecessary memset in vfb_probe.

Signed-off-by: Marcin Chojnacki <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>

show more ...

video: move fbdev to drivers/video/fbdev

The drivers/video directory is a mess. It contains generic video related
files, directories for backlight, console, linux logo, lots of fbdev
device drivers,

video: move fbdev to drivers/video/fbdev

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 <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
Acked-by: Geert Uytterhoeven <[email protected]>
Acked-by: Rob Clark <[email protected]>
Acked-by: Jingoo Han <[email protected]>
Acked-by: Daniel Vetter <[email protected]>

show more ...