kernel/linux.git/include/video, branch v6.12.80Linux kernel stable tree (mirror)https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.802024-10-15T08:08:23+00:00fbdev: da8xx: remove the driver2024-10-15T08:08:23+00:00Bartosz Golaszewskibartosz.golaszewski@linaro.org2024-10-15T06:53:29+00:00urn:sha1:bb94f56b9cfa4a946a43492b2a13ecb5b9b571bc
This driver is no longer used on any platform. It has been replaced by
tilcdc on the two DaVinci boards we still support and can be removed.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
video: Handle HAS_IOPORT dependencies2024-07-29T08:16:11+00:00Niklas Schnelleschnelle@linux.ibm.com2024-05-14T13:08:58+00:00urn:sha1:8423895d456672736a278d64f86d8b434eef2b54
In a future patch HAS_IOPORT=n will disable inb()/outb() and friends at
compile time. We thus need to #ifdef functions and their callsites which
unconditionally use these I/O accessors. In the include/video/vga.h
these are conveniently all those functions with the vga_io_* prefix.
Co-developed-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Helge Deller <deller@gmx.de>
fbdev: mmp: Constify struct mmp_overlay_ops2024-06-25T12:40:01+00:00Christophe JAILLETchristophe.jaillet@wanadoo.fr2024-06-24T19:59:42+00:00urn:sha1:b65bd7874bc7dc709645fd8acb53603b73ae950a
'struct mmp_overlay_ops' is not modified in this driver.
Constifying this structure moves some data to a read-only section, so
increase overall security.
On a x86_64, with allmodconfig, as an example:
Before:
======
text data bss dec hex filename
11798 555 16 12369 3051 drivers/video/fbdev/mmp/hw/mmp_ctrl.o
After:
=====
text data bss dec hex filename
11834 507 16 12357 3045 drivers/video/fbdev/mmp/hw/mmp_ctrl.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Helge Deller <deller@gmx.de>
fbdev: omap2: replace of_graph_get_next_endpoint()2024-03-25T04:49:05+00:00Kuninori Morimotokuninori.morimoto.gx@renesas.com2024-03-25T02:57:29+00:00urn:sha1:ada5caa4e081b067736e872f2701e1c677290f22
From DT point of view, in general, drivers should be asking for a
specific port number because their function is fixed in the binding.
of_graph_get_next_endpoint() doesn't match to this concept.
Simply replace
- of_graph_get_next_endpoint(xxx, NULL);
+ of_graph_get_endpoint_by_regs(xxx, 0, -1);
Link: https://lore.kernel.org/r/20240202174941.GA310089-robh@kernel.org
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Helge Deller <deller@gmx.de>
Merge drm/drm-next into drm-misc-next2024-01-29T13:20:23+00:00Maxime Ripardmripard@kernel.org2024-01-29T13:20:23+00:00urn:sha1:4db102dcb0396a4ccf89b1eac0f4eb3fd167a080
Kickstart 6.9 development cycle.
Signed-off-by: Maxime Ripard <mripard@kernel.org>
video/cmdline: Hide __video_get_options() behind CONFIG_FB_CORE2024-01-23T09:11:34+00:00Thomas Zimmermanntzimmermann@suse.de2024-01-18T09:05:27+00:00urn:sha1:55ea87a4f9007a034bd72bc93408d8a579d04177
The function __video_get_options() only exists for compatibility
with old fbdev drivers that cannot be refactored easily. Hide it
behind CONFIG_FB_CORE.
v2:
* support CONFIG_FB_CORE=m via IS_ENABLED() (kernel test robot)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20240118090721.7995-3-tzimmermann@suse.de
video/cmdline: Introduce CONFIG_VIDEO for video= parameter2024-01-23T09:11:22+00:00Thomas Zimmermanntzimmermann@suse.de2024-01-18T09:05:26+00:00urn:sha1:a3b6792e990d63d47c4d2622a9704a01db50c3a2
Add CONFIG_VIDEO for common code in drivers/video/. Use the option to
select helpers for the video= parameter. Replaces CONFIG_VIDEO_CMDLINE.
Other common code in drivers/video/ can be moved behind CONFIG_VIDEO,
which will simplify the Kconfig rules.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20240118090721.7995-2-tzimmermann@suse.de
video/sticore: Remove info field from STI struct2024-01-12T11:38:37+00:00Thomas Zimmermanntzimmermann@suse.de2023-12-20T13:22:57+00:00urn:sha1:e2e0b838a1849f92612a8305c09aaf31bf824350
The info field in struct sti_struct was used to detect the default
display device. That test is now done with the respective Linux device
and the info field is unused. Remove it.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
video/sticore: Store ROM device in STI struct2024-01-12T11:38:37+00:00Thomas Zimmermanntzimmermann@suse.de2023-12-20T13:22:54+00:00urn:sha1:12b8de566fa9ec428e724f955735fd1ca278ca4c
Store the ROM's parent device in each STI struct, so we can associate
the STI framebuffer with a device.
The new field will eventually replace the fbdev subsystem's info field,
which the function fb_is_primary_device() currently requires to detect
the firmware's output. By using the device instead of the framebuffer
info, a later patch can generalize the helper for use in non-fbdev code.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
fbdev: stifb: Make the STI next font pointer a 32-bit signed offset2023-10-30T13:54:41+00:00Helge Dellerdeller@gmx.de2023-10-27T11:36:48+00:00urn:sha1:8a32aa17c1cd48df1ddaa78e45abcb8c7a2220d6
The pointer to the next STI font is actually a signed 32-bit
offset. With this change the 64-bit kernel will correctly subract
the (signed 32-bit) offset instead of adding a (unsigned 32-bit)
offset. It has no effect on 32-bit kernels.
This fixes the stifb driver with a 64-bit kernel on qemu.
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org