- 17 May, 2022 3 commits
-
-
Xin Ji authored
As V4L2_FWNODE_BUS_TYPE_PARALLEL not properly descript for DPI interface, this patch use new defined V4L2_FWNODE_BUS_TYPE_DPI for it. Fixes: fd0310b6 ("drm/bridge: anx7625: add MIPI DPI input feature") Signed-off-by:
Xin Ji <xji@analogixsemi.com> Tested-by:
Chen-Yu Tsai <wenst@chromium.org> Acked-by:
Robert Foss <robert.foss@linaro.org> Reviewed-by:
-
Xin Ji authored
Add 'bus-type' and 'data-lanes' define, bus-type 7 for MIPI DPI input, others for DSI input. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
Dmitry Osipenko authored
Interrupt context can't sleep. Drivers like Panfrost and MSM are taking mutex when job is released, and thus, that code can sleep. This results into "BUG: scheduling while atomic" if locks are contented while job is freed. There is no good reason for releasing scheduler's jobs in IRQ context, hence use normal context to fix the trouble. Cc: stable@vger.kernel.org Fixes: 542cff78 ("drm/sched: Avoid lockdep spalt on killing a processes") Signed-off-by:
Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220411221536.283312-1-dmitry.osipenko@collabora.com
-
- 16 May, 2022 6 commits
-
-
Geert Uytterhoeven authored
The Freescale i.MX8MP LDB bridge is only present on Freescale i.MX8MP SoCs. Hence add a dependency on ARCH_MXC, to prevent asking the user about this driver when configuring a kernel without i.MX SoC support. Fixes: 463db5c2 ("drm: bridge: ldb: Implement simple Freescale i.MX8MP LDB bridge") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Marek Vasut <marex@denx.de> Signed-off-by:
-
Marek Vasut authored
Drop two unused register macros, ICN6211_MAX_REGISTER and MIPI_ATE_STATUS_1, neither of which is used and where the later should be specified using macro MIPI_ATE_STATUS(1) instead. Drop the _(n) underscore and keep only the (n) part of register macros. No functional change. Signed-off-by:
-
Jocelyn Falempe authored
Add support for atomic update of gamma lut. With this patch the "Night light" feature of gnome3 is working properly on mgag200. v2: - Add a default linear gamma function - renamed functions with mgag200 prefix - use format's 4cc code instead of bit depth - use better interpolation for 16bits gamma - remove legacy function mga_crtc_load_lut() - can't remove the call to drm_mode_crtc_set_gamma_size() because it doesn't work with userspace. - other small refactors v3: - change mgag200_crtc_set_gamma*() argument to struct drm_format_info *format - fix printk format to %p4cc for 4cc and %zu for size_t - rebased to drm-misc-next. Signed-off-by:Jocelyn Falempe <jfalempe@redhat.com> Tested-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
-
Thomas Zimmermann authored
Don't add a mode for the kernel's command-line parameters from within the DRM client code. Doing so can result in an unusable display. If there's no compatible command-line mode, the client will use one of the connector's preferred modes. All mode creation and validation has to be performed by the connector. When clients run, the connector's fill_modes callback has already processed the kernel parameters and validated each mode before adding it. The connector's mode list does not contain invalid modes. v2: * grammar in commit message (Javier) Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220511183125.14294-4-tzimmermann@suse.de
-
Thomas Zimmermann authored
When picking a mode, first look for modes that have been specified by the user on the kernel's command line. Only if that fails, use the existing heuristic of picking a nearby mode from it's various parameters. Signed-off-by:
-
Thomas Zimmermann authored
Print a warning if a user-specifed display mode is not supported by the display pipeline. Users specified the display mode on the kernel command line with the use of the video= parameter. Setting an unsupported mode will leave the console blank, so we should at least let the user know why. Signed-off-by:
-
- 15 May, 2022 3 commits
-
-
Dan Carpenter authored
This error path needs an unlock before returning. Fixes: 604be855 ("drm/rockchip: Add VOP2 driver") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/YnjZQRV9lpub2ET8@kili
-
Peter Geis authored
Some implementations do not use the reset signal, instead tying it to dvdd. Make the reset gpio optional to permit this. Signed-off-by:
Peter Geis <pgwipeout@gmail.com> Signed-off-by:
-
Peter Geis authored
Some implementations do not use the reset signal, instead tying it to dvdd. Make the reset gpio optional to permit this. Signed-off-by:
-
- 13 May, 2022 27 commits
-
-
Jani Nikula authored
We'll need to propagate drm_edid everywhere. Also make version_greater() a function for type safety. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f1835a86294b392d075570001ed9009a48352670.1652097712.git.jani.nikula@intel.com
-
Jani Nikula authored
We'll need to propagate drm_edid everywhere. v2: Rebase Signed-off-by:
-
Jani Nikula authored
We'll need to propagate drm_edid everywhere. v2: Handle NULL EDID pointer (Ville, CI) Signed-off-by:
-
Jani Nikula authored
We'll need to propagate drm_edid everywhere. v2: Rebase Signed-off-by:
-
Jani Nikula authored
We'll need to propagate drm_edid everywhere. v2: Handle NULL drm_edid Signed-off-by:
-
Jani Nikula authored
We'll need to propagate drm_edid everywhere. v2: Handle NULL EDID pointer (Ville, CI) Signed-off-by:
-
Jani Nikula authored
We'll need to propagate drm_edid everywhere. v2: Handle NULL EDID pointer (Ville, CI) Signed-off-by:
-
Jani Nikula authored
We'll need to propagate drm_edid everywhere.' v2: Handle NULL EDID pointer (Ville, CI) Signed-off-by:
-
Jani Nikula authored
We'll need to propagate drm_edid everywhere. v2: Handle NULL EDID pointer (Ville, CI) Signed-off-by:
-
Jani Nikula authored
We'll need to propagate drm_edid everywhere. v2: Fix checkpatch warning on superfluous parens Signed-off-by:
-
Jani Nikula authored
We'll need to propagate drm_edid everywhere. v2: Drop incorrect NULL name check (Dan Carpenter) Signed-off-by:
-
Jani Nikula authored
We'll need to propagate drm_edid everywhere. Signed-off-by:
-
Jani Nikula authored
We'll need to propagate drm_edid everywhere. Signed-off-by:
-
Jani Nikula authored
We'll need to propagate drm_edid everywhere. Signed-off-by:
-
Jani Nikula authored
We'll need to propagate drm_edid everywhere. Signed-off-by:
-
Jani Nikula authored
We'll need to propagate drm_edid everywhere. Signed-off-by:
-
Jani Nikula authored
We'll need to propagate drm_edid everywhere. Signed-off-by:
-
Jani Nikula authored
We'll need to propagate drm_edid everywhere. Signed-off-by:
-
Jani Nikula authored
We'll need to propagate drm_edid everywhere. v3: s/edid/drm_edid/ in comment too (Ankit) Signed-off-by:
-
Jani Nikula authored
We'll need to propagate drm_edid everywhere. v3: Rebase Signed-off-by:
-
Jani Nikula authored
We'll need to propagate drm_edid everywhere. v3: Update comment to refer to update_display_info() (Ankit) v2: Use drm_edid_legacy_init() Signed-off-by:
-
Jani Nikula authored
We'll need to propagate drm_edid everywhere. This is a clunky start, but a start nonetheless. We'll eventually convert all of the EDID parsing to struct drm_edid. Initially, we'll just create the struct drm_edid in stack. This will be the compat layer for legacy struct edid code. In the future, we'll have EDID read return drm_edid objects. v2: Add legacy init helper. Signed-off-by:
-
Jani Nikula authored
Introduce new opaque type struct drm_edid to encapsulate the EDID data and the size allocated for it. The contents will be private to drm_edid.c. There are a number of reasons for adding a container around struct edid: * struct edid is a raw blob pointer to data that usually originates outside of the kernel. Its size is contained within the structure. * There's no way to attach meta information (such as allocated memory size) to struct edid. * Validation of the EDID blob and its size become crucial, and it's spread all over the subsystem, with varying levels of accuracy. * HDMI Forum has introduced an HF-EEODB extension that defines an override EDID size within an EDID extension. The size allocated for an EDID depends on whether the allocator understands the HF-EEODB extension. Given a struct edid *, it's impossible to know how much memory was actually allocated for it. There are also some reasons for making the container type struct drm_edid opaque and private to drm_edid.c: * Have only one place for creating and parsing the EDID, to avoid duplicating bugs. * Prepare for reading a pure DisplayID 2.0 from its own DDC address, and adding it within the same struct drm_edid container, transparently, and for all drivers. * With the idea that the drm_edid objects are immutable during their lifetimes, it will be possible to refcount them and reduce EDID copying everywhere (this is left for future work). Initially, just add the type. In follow-up, we'll start converting the guts of drm_edid.c to use it, and finally add interfaces around it. Signed-off-by:
-
Jani Nikula authored
We have an iterator for this, use it. It does include the base block, but its tag is 0 and will be skipped. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/a68718819a3dbfbdaaaddca7f73afa5ac6b33d07.1652097712.git.jani.nikula@intel.com
-
Jani Nikula authored
Only one of the conditions can be true. Suggested-by:
-
Javier Martinez Canillas authored
The driver has runtime but no build time dependency with X86, so it can be built for testing purposes if the COMPILE_TEST option is enabled. This is useful to have more build coverage and make sure that the driver is not affected by changes that could cause build regressions. Signed-off-by:
-
Javier Martinez Canillas authored
Drivers that want to remove registered conflicting framebuffers prior to register their own framebuffer, call to remove_conflicting_framebuffers(). This function takes the registration_lock mutex, to prevent a race when drivers register framebuffer devices. But if a conflicting framebuffer device is found, the underlaying platform device is unregistered and this will lead to the platform driver .remove callback to be called. Which in turn will call to unregister_framebuffer() that takes the same lock. To prevent this, a struct fb_info.forced_out field was used as indication to unregister_framebuffer() whether the mutex has to be grabbed or not. But this could be unsafe, since the fbdev core is making assumptions about what drivers may or may not do in their .remove callbacks. Allowing to run these callbacks with the registration_lock held can cause deadlocks, since the fbdev core has no control over what drivers do in their removal path. A better solution is to drop the lock before platform_device_unregister(), so unregister_framebuffer() can take it when called from the fbdev driver. The lock is acquired again after the device has been unregistered and at this point the removal loop can be restarted. Since the conflicting framebuffer device has already been removed, the loop would just finish when no more conflicting framebuffers are found. Suggested-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
- 12 May, 2022 1 commit
-
-
Marek Vasut authored
Implement DSI-to-e(DP) mode, which is a mix of currently supported DSI-to-DPI and DPI-to-(e)DP modes. The input side is configured as either DSI or DPI, the DP AUX channel is registered for both input side options, and the DSI host is attached for both DPI and (e)DP output side options. One notable detail is that the DSI-to-(e)DP mode requires the Pixel PLL to be always enabled, which is not needed for DPI-to-(e)DP mode which gets the matching clock direct from DPI Pixel Clock instead. Signed-off-by:
-
