The Sony IMX415 is the sensor on the Radxa Camera 4K and on several
other MIPI CSI-2 modules, and the driver is in the kernel already. Add
kmod-video-imx415 so a board with a camera connector has a sensor to
go with its capture driver.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Package the H.264, VP9 and JPEG helper modules on their own so several
stateless codec drivers can share them, and add the Hantro VPU driver
used by i.MX8M, Rockchip, Allwinner, Microchip and ST SoCs. The i.MX
CODA package takes the JPEG helper from the new package.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Package the Synopsys DW DisplayPort, HDMI, HDMI QP, MIPI DSI and MIPI
DSI2 bridges, the Analogix DisplayPort bridge with the DP AUX bus, the
GPUVM helper and the Panthor driver for ARM Mali CSF GPUs. The HDMI QP
bridge depends on the HDMI codec module for its audio path.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
CONFIG_VIDEO_DEV builds v4l2-dv-timings.ko next to videodev.ko, but the
package only installs the latter, so a driver that needs the DV timings
helpers, such as the Synopsys HDMI receiver, cannot be packaged.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
AutoProbe places a module in etc/modules.d, which kmodloader loads
from /etc/init.d/boot once preinit has finished, so a MIPI DBI panel
only lights up late in the boot. With the boot flag the module is
linked into etc/modules-boot.d as well, which is loaded before the
preinit scripts, together with its dependencies.
Set the flag on the panel driver and on pwm_bl, because the panel
defers its probe until the backlight it references has registered.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
A Xen guest without emulated graphics has two ways to be given a display,
and the kernel drivers for them are unrelated: xen-fbfront speaks the vfb
protocol through legacy fbdev, while xen_drm_front speaks displif on a
vdispl xenbus device. Only the second has a DRM driver, and nothing in
the tree packaged it.
Package it for the three targets whose kernels have Xen guest support. It
needs xen-front-pgdir-shbuf, a hidden tristate with no package of its
own, so both modules ship together.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
kmod-drm pulled kmod-fb in unconditionally and kmod-drm-kms-helper pulled
in six fbdev helper packages, so any target that shipped a DRM kmod got
CONFIG_FB, the framebuffer console, the fonts and CONFIG_VT switched on
whatever its kernel fragment said. Drop those dependencies, along with
the fbdev emulation that kmod-drm-imx and kmod-drm-panel-mipi-dbi forced
on and the DRM_KMS_FB_HELPER, DRM_IMX_FB_HELPER and FB_INTEL symbols that
no kernel in the tree defines.
kmod-fb and the fbdev helpers stay selectable on bcm27xx, sunxi, x86
legacy and geode, whose kernels keep fbdev, and fbtft narrows to bcm27xx,
the only target with in-tree users. kmod-drm-client-lib goes: the targets
that keep fbdev emulation build DRM into the kernel, so DRM_CLIENT_LIB is
built in there, and on a target with DRM as modules nothing selects it,
where drm_client_setup() is an empty inline.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The sound and DRM modules carry a dependency on audio-support and
video-support, which is what decides whether an image handles those
devices. The AUDIO_SUPPORT and DISPLAY_SUPPORT tokens beside them add a
second, per-SoC-family condition that a board cannot influence, and that
DISPLAY_SUPPORT is half derived from whatever kernel configuration was
copied into a target's fragment.
Drop the tokens from the module dependencies and from fbtest.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
The display target feature gates every DRM module, but it says nothing
useful: it is set on ten targets, so a mediatek/mt7623 board can have a
display while a filogic board with a MIPI DBI panel cannot, and rockchip
claims it for a NanoPi R2S as much as for a Rock 5B. Whether a board
drives a panel is a per-device choice, not a property of the SoC family.
The DRM and V4L2 nodes also end up 0600 root:root, so a display server
runs as root or not at all.
Add a video-support package which allocates the video and video-capture
groups and installs the hotplug rules for the DRM and V4L2 nodes, and
make the modules depend on it. The dependency is a plain one, not a
select, so the modules are offered once the feature is chosen. Targets
whose display drivers are built into the kernel carry the package in
DEFAULT_PACKAGES, since no module pulls it in for them, and the one
device profile that ships a DRM module on another target lists it
directly. DISPLAY_SUPPORT stays for now, so this changes no existing
selection.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
videobuf2-vmalloc.ko was listed unconditionally in video-videobuf2's
FILES, but CONFIG_VIDEOBUF2_VMALLOC is only reliably built when a
driver that needs a vmalloc-backed allocator (e.g. pwc, uvc, gspca)
is itself selected. Any build where none of those drivers happen to
be enabled (e.g. under CONFIG_ALL_KMODS=y on a target where those USB
webcam drivers aren't selected) fails hard while packaging
kmod-video-videobuf2, since the .ko it expects to copy was never
built:
ERROR: module '.../videobuf2-vmalloc.ko' is missing.
Split it out into its own kmod-video-vmalloc package, following the
same pattern already used for video-dma-contig and video-dma-sg.
videobuf2-vmalloc.c calls dma_buf_vmap_unlocked/dma_buf_vunmap_unlocked
directly, so the new package depends on kmod-dma-buf explicitly rather
than only transitively through kmod-video-videobuf2.
Adjust the DEPENDS of all six in-tree drivers that previously got the
module for free from kmod-video-videobuf2: video-pwc, video-uvc,
video-gspca-core, video-coda, video-tw686x and camera-bcm2835.
camera-bcm2835's AUTOLOAD priority also moves from 66 to 67, matching
its siblings bcm2835-codec/bcm2835-isp/rp1-cfe*, which already sit one
priority above the videobuf2 allocator helper (65/66) they depend on.
Fix also two dead entries in video-videobuf2's AUTOLOAD that never
matched a built module (videobuf2-core and videobuf-v4l2, vs. the actual
videobuf2-common.ko/videobuf2-v4l2.ko), which caused kmodloader to
complain on every boot; pre-existing, unrelated to the split itself.
Signed-off-by: Joshua Covington <joshuacov@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/24647
Signed-off-by: Robert Marko <robimarko@gmail.com>
Since 6.18, fb.ko calls into the backlight class rather than the
reverse, so it depends on backlight.ko when CONFIG_FB_BACKLIGHT is set,
which in-tree only happens via FB_TFT's select. Building kmod-fb-tft on
a 6.18 target with DISPLAY_SUPPORT therefore fails with:
Package kmod-fb is missing dependencies for the following libraries:
backlight.ko
Declare the dependency on kmod-fb, conditional on kmod-backlight being
built. An unconditional +kmod-backlight would form a recursive
dependency with KernelPackage/backlight's +kmod-fb, both as a kconfig
select cycle and as a circular PACK_ prerequisite that make resolves by
dropping an edge.
backlight.ko only references fb.ko on 6.12, so narrow that reverse
dependency to +LINUX_6_12:kmod-fb, which leaves a single edge on 6.18.
Signed-off-by: Matt Eaton <git@divinehawk.com>
Link: https://github.com/openwrt/openwrt/pull/24765
Signed-off-by: Robert Marko <robimarko@gmail.com>
Add support for the GPIO-based backlight driver, which allows controlling
display backlights connected via GPIO pins. This is commonly used on
embedded boards and SBCs where a display backlight is toggled through
a GPIO line rather than a dedicated backlight IC.
Enables CONFIG_BACKLIGHT_GPIO.
Signed-off-by: Matt Eaton <git@divinehawk.com>
Link: https://github.com/openwrt/openwrt/pull/22740
Signed-off-by: Robert Marko <robimarko@gmail.com>
These path names are unlikely to change. There is no need for variables.
Tested on Turris Omnia, but not all of these drivers were tested. Variables
were replaced automatically (search-and-replace in text editor). There
shouldn't be any problems.
Signed-off-by: Marius Dinu <m95d+git@psihoexpert.ro>
Create a package for ov5645 kernel module, required to support camera on
PICO-PI-IMX7D board.
Currently limit the visibility to imx_cortexa7 subtarget, but this can
be enabled on other platforms if needed.
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/17606
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Fix dependency for kmod-drm-client-lib module:
error: recursive dependency detected!
symbol LINUX_6_18 is selected by PACKAGE_kmod-drm-client-lib
symbol PACKAGE_kmod-drm-client-lib is selected by LINUX_6_18
Fixes: e75ba35ed8 ("modules: video: introduce DRM client setup module")
Signed-off-by: Paweł Owoc <frut3k7@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/23124
Signed-off-by: Robert Marko <robimarko@gmail.com>
6.14 has introduced a DRM client setup library. Add kmod-drm-client-lib
to support it, and add it as a dependency to DRM modules which depend on it.
Link: https://github.com/openwrt/openwrt/pull/22975
Signed-off-by: Zoltan HERPAI <wigyori@uid0.hu>
Select the kmod-drm-display-helper package instead of depending on it.
kmod-drm-display-helper is hidden now, so the user can not manually
select it.
This fixes the build of the imx target.
Fixes: 8bcc6d1894 ("kernel: kmod-drm-display-helper: Mark hidden")
Link: https://github.com/openwrt/openwrt/pull/19532
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The Kernel config option CONFIG_DRM_DISPLAY_HELPER has no title and can
not be directly selected. Do the same for this kmod and make it hidden.
Link: https://github.com/openwrt/openwrt/pull/19480
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
The DRM modules for simple (ie. raw, non-eDP) panels can be used also
by platforms others than Freescale i.MX.
Create an individual package for it.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Define define fb-io-fops module - Fbdev helpers for framebuffers in I/O memory
By creating a hidden module it is possible to load fb_io_fops.ko
according to the kernel version.
Fixes: 5048c9d ("kernel: modules: adjust the object files of kmod-fb ")
Package kmod-drm-radeon is missing dependencies for the following libraries:
fb_io_fops.ko
make[2]: *** [modules/video.mk:620: /__w/openwrt/openwrt/openwrt/bin/targets/x86/geode/packages/kmod-drm-radeon-6.12.28-r1.apk] Error 1
time: package/kernel/linux/compile#45.35#40.01#75.34
Signed-off-by: Mieczyslaw Nalewaj <namiltd@yahoo.com>
Link: https://github.com/openwrt/openwrt/pull/18771
Signed-off-by: Robert Marko <robimarko@gmail.com>
i915 driver requires to load correct firmware to work on latest x86
GPU, it is more reasonable to make it as a kernel module, so that
initramfs is not required, and it can also save some space from the
kernel image comparing being a built-in driver
Signed-off-by: Joe Zheng <joe.zheng@intel.com>
Link: https://github.com/openwrt/openwrt/pull/16276
Signed-off-by: Robert Marko <robimarko@gmail.com>
Package kmod-drm-panel-mipi-dbi as well as modules it depends on in
order to support a wide range of MIPI DBI complaint SPI-connected
TFT panels.
See https://github.com/notro/panel-mipi-dbi/ for more information on
how to use specific panels.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Daniel Golle
Joshua Covington
Matt Eaton
Marius Dinu
Lech Perczak
Paweł Owoc
Zoltan HERPAI
John Audia
Michel Promonet
Mieczyslaw Nalewaj
Hauke Mehrtens
Tim Harvey
Joe Zheng
Álvaro Fernández Rojas
Shiji Yang
Thomas Richard
Luiz Angelo Daros de Luca