- 15 Oct, 2022 3 commits
-
-
Laurent Pinchart authored
Up to and including v1.3, HDMI supported limited quantization range only for YCbCr. HDMI v1.4 introduced selectable quantization ranges, but this feature isn't supported in the dw-hdmi driver that is used in conjunction with the LCDIF in the i.MX8MP. The HDMI YCbCr output is thus always advertised in the AVI infoframe as limited range. The LCDIF driver, on the other hand, configures the CSC to produce full range YCbCr. This mismatch results in loss of details and incorrect colours. Fix it by switching to limited range YCbCr. The coefficients are copied from drivers/media/platforms/nxp/imx-pxp.c for coherency, as the hardware is most likely identical. Fixes: 9db35bb3 ("drm: lcdif: Add support for i.MX8MP LCDIF variant") Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Marek Vasut <marex@denx.de> Reviewed-by:
Kieran Bingham <kieran.bingham@ideasonboard.com> Reviewed-by:
Liu Ying <victor.liu@nxp.com> Signed-off-by:
-
Laurent Pinchart authored
The BIT() macro is meant to represent a single bit. Don't use it for values of register fields that span multiple bits. Signed-off-by:
-
Laurent Pinchart authored
A couple of the register macro values are incorrectly indented. Fix them. Signed-off-by:
-
- 14 Oct, 2022 5 commits
-
-
Thomas Zimmermann authored
All DRM formats assume little-endian byte order. On big-endian systems, it is likely that the scanout buffer is in big endian as well. Update the format accordingly and add endianness conversion to the format-helper library. Also opt-in to allocated buffers in host format by default. Suggested-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221011150712.3928-6-tzimmermann@suse.de
-
Thomas Zimmermann authored
Support the CRTC's color-management property and implement each model's palette support. The OF hardware has different methods of setting the palette. The respective code has been taken from fbdev's offb and refactored into per-model device functions. The device functions integrate this functionality into the overall modesetting. As palette handling is a CRTC property that depends on the primary plane's color format, the plane's atomic_check helper now updates the format field in ofdrm's custom CRTC state. The CRTC's atomic_flush helper updates the palette for the format as needed. v4: * use cpu_to_be32() (Geert) v3: * lookup CRTC state with drm_atomic_get_new_crtc_state() * access HW palette with writeb(), writel(), and readl() (Ben) * declare register values as u32 Signed-off-by:
-
Thomas Zimmermann authored
Add a per-model device-function structure in preparation of adding color-management support. Detection of the individual models has been taken from fbdev's offb. v3: * define constants for PCI ids (Javier) Signed-off-by:
-
Thomas Zimmermann authored
Add a dedicated CRTC state to ofdrm to later store information for palette updates. v3: * rework CRTC state helpers (Javier) Signed-off-by:
-
Thomas Zimmermann authored
Open Firmware provides basic display output via the 'display' node. DT platform code already provides a device that represents the node's framebuffer. Add a DRM driver for the device. The display mode and color format is pre-initialized by the system's firmware. Runtime modesetting via DRM is not possible. The display is useful during early boot stages or as error fallback. Similar functionality is already provided by fbdev's offb driver, which is insufficient for modern userspace. The old driver includes support for BootX device tree, which can be found on old 32-bit PowerPC Macintosh systems. If these are still in use, the functionality can be added to ofdrm or implemented in a new driver. As with simpledrm, the fbdev driver cannot be selected if ofdrm is already enabled. Two notable points about the driver: * Reading the framebuffer aperture from the device tree is not reliable on all systems. Ofdrm takes the heuristics and a comment from offb to pick the correct range. * No resource management may be tied to the underlying PCI device. Otherwise the handover to the native driver will fail with a resource conflict. PCI management is therefore done as part of the platform device's cleanup. The driver has been tested on qemu's ppc64le emulation. The device hand-over has been tested with bochs. v5: * use drm_atomic_helper_check_crtc_primary_plane() v4: * set preferred depth to the correct value * set bpp value for console emulation * output scanout-buffer parameters with drm_dbg() v3: * reintegrate FWFB helpers into ofdrm * use damage iterator * sync GEM BOs with drm_gem_fb_{begin,end}_cpu_access() * fix various atomic_check helpers * remove CRTC atomic_{enable,disable} (Javier) * compute stride with drm_format_info_min_pitch() (Daniel) v2: * removed simple-pipe helpers * built driver on top of FWFB helpers * merged all init code into single function * make PCI support optional (Michal) * support COMPILE_TEST (Javier) Signed-off-by:
-
- 13 Oct, 2022 5 commits
-
-
Abhinav Kumar authored
adv7533 bridge tries to dynamically switch lanes based on the mode by detaching and attaching the mipi dsi device. This approach is incorrect because this method of dynamic switch of detaching and attaching the mipi dsi device also results in removing and adding the component which is not necessary. This approach is also prone to deadlocks. So for example, on the db410c whenever this path is executed with lockdep enabled, this results in a deadlock due to below ordering of locks. -> #1 (crtc_ww_class_acquire){+.+.}-{0:0}: lock_acquire+0x6c/0x90 drm_modeset_acquire_init+0xf4/0x150 drmm_mode_config_init+0x220/0x770 msm_drm_bind+0x13c/0x654 try_to_bring_up_aggregate_device+0x164/0x1d0 __component_add+0xa8/0x174 component_add+0x18/0x2c dsi_dev_attach+0x24/0x30 dsi_host_attach+0x98/0x14c devm_mipi_dsi_attach+0x38/0xb0 adv7533_attach_dsi+0x8c/0x110 adv7511_probe+0x5a0/0x930 i2c_device_probe+0x30c/0x350 really_probe.part.0+0x9c/0x2b0 __driver_probe_device+0x98/0x144 driver_probe_device+0xac/0x14c __device_attach_driver+0xbc/0x124 bus_for_each_drv+0x78/0xd0 __device_attach+0xa8/0x1c0 device_initial_probe+0x18/0x24 bus_probe_device+0xa0/0xac deferred_probe_work_func+0x90/0xd0 process_one_work+0x28c/0x6b0 worker_thread+0x240/0x444 kthread+0x110/0x114 ret_from_fork+0x10/0x20 -> #0 (component_mutex){+.+.}-{3:3}: __lock_acquire+0x1280/0x20ac lock_acquire.part.0+0xe0/0x230 lock_acquire+0x6c/0x90 __mutex_lock+0x84/0x400 mutex_lock_nested+0x3c/0x70 component_del+0x34/0x170 dsi_dev_detach+0x24/0x30 dsi_host_detach+0x20/0x64 mipi_dsi_detach+0x2c/0x40 adv7533_mode_set+0x64/0x90 adv7511_bridge_mode_set+0x210/0x214 drm_bridge_chain_mode_set+0x5c/0x84 crtc_set_mode+0x18c/0x1dc drm_atomic_helper_commit_modeset_disables+0x40/0x50 msm_atomic_commit_tail+0x1d0/0x6e0 commit_tail+0xa4/0x180 drm_atomic_helper_commit+0x178/0x3b0 drm_atomic_commit+0xa4/0xe0 drm_client_modeset_commit_atomic+0x228/0x284 drm_client_modeset_commit_locked+0x64/0x1d0 drm_client_modeset_commit+0x34/0x60 drm_fb_helper_lastclose+0x74/0xcc drm_lastclose+0x3c/0x80 drm_release+0xfc/0x114 __fput+0x70/0x224 ____fput+0x14/0x20 task_work_run+0x88/0x1a0 do_exit+0x350/0xa50 do_group_exit+0x38/0xa4 __wake_up_parent+0x0/0x34 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0x60/0x11c do_el0_svc+0x30/0xc0 el0_svc+0x58/0x100 el0t_64_sync_handler+0x1b0/0x1bc el0t_64_sync+0x18c/0x190 Due to above reasons, remove the dynamic lane switching code from adv7533 bridge chip and filter out the modes which would need different number of lanes as compared to the initialization time using the mode_valid callback. This can be potentially re-introduced by using the pre_enable() callback but this needs to be evaluated first whether such an approach will work so this will be done with a separate change. changes since RFC: - Fix commit text and add TODO comment changes in v2: - Fix checkpatch formatting errors Fixes: 62b2f026 ("drm/bridge: adv7533: Change number of DSI lanes dynamically") Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/16Suggested-by:Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by:
Robert Foss <robert.foss@linaro.org> Link: https://lore.kernel.org/r/1661797363-7564-1-git-send-email-quic_abhinavk@quicinc.comSigned-off-by:
-
Javier Martinez Canillas authored
Provides a default CRTC state check handler for CRTCs that only have one primary plane attached. There are some drivers that duplicate this logic in their helpers, such as simpledrm and ssd130x. Factor out this common code into a CRTC helper and make drivers use it. Signed-off-by:
-
Javier Martinez Canillas authored
There's no need to add planes to the atomic state. Remove the call to drm_atomic_add_affected_planes() from ssd130x. On full modesets, the DRM helpers already add a CRTC's planes to the atomic state; see drm_atomic_helper_check_modeset(). There's no reason to call drm_atomic_add_affected_planes() unconditionally in the CRTC's atomic_check() in ssd130x. It's also too late, as the atomic_check() of the added planes will not be called before the commit. Suggested-by:
-
Javier Martinez Canillas authored
There's no need to add planes to the atomic state. Remove the call to drm_atomic_add_affected_planes() from simpledrm. On full modesets, the DRM helpers already add a CRTC's planes to the atomic state; see drm_atomic_helper_check_modeset(). There's no reason to call drm_atomic_add_affected_planes() unconditionally in the CRTC's atomic_check() in simpledrm. It's also too late, as the atomic_check() of the added planes will not be called before the commit. Suggested-by:
-
Javier Martinez Canillas authored
There's no need to add planes to the atomic state. Remove the call to drm_atomic_add_affected_planes() from mgag200. On full modesets, the DRM helpers already add a CRTC's planes to the atomic state; see drm_atomic_helper_check_modeset(). There's no reason to call drm_atomic_add_affected_planes() unconditionally in the CRTC's atomic_check() in mgag200. It's also too late, as the atomic_check() of the added planes will not be called before the commit. Suggested-by:
-
- 12 Oct, 2022 2 commits
-
-
ruanjinjie authored
When build Linux kernel with 'make C=2', encounter the following warnings: ./drivers/gpu/drm/nouveau/dispnv50/disp.c:134:34: warning: cast removes address space '__iomem' of expression ./drivers/gpu/drm/nouveau/dispnv50/disp.c:197:34: warning: cast removes address space '__iomem' of expression The data type of dmac->_push.mem.object.map.ptr is 'void __iomem *', but converted to 'u32 *' directly and cause above warnings, now recover their data types to fix these warnings. Signed-off-by:
ruanjinjie <ruanjinjie@huawei.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Jani Nikula authored
While it takes more vertical space, sorted build lists with one object per line are arguably easier to manage, especially when there are conflicting changes. Split anything with more than one object file. v2: also split drm_cache.o and put it after drm_bridge.o (Andi) Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Acked-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221011140830.3257655-1-jani.nikula@intel.com
-
- 10 Oct, 2022 8 commits
-
-
Teresa Remmet authored
Soft reset during tc_bridge_enable() is triggered by setting all available reset control bits in the SYSRST register. But as noted in the data sheet resetting the i2c-slave controller should be only done over DSI and is only useful for chip debugging. So do not set RSTI2CS (bit0). Signed-off-by:
Teresa Remmet <t.remmet@phytec.de> Reviewed-by:
-
Mateusz Kwiatkowski authored
PAL-M is a Brazilian analog TV standard that uses a PAL-style chroma subcarrier at 3.575611[888111] MHz on top of 525-line (480i60) timings. This commit makes the driver actually use the proper VEC preset for this mode instead of just changing PAL subcarrier frequency. Acked-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Link: https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v4-25-60d38873f782@cerno.techSigned-off-by:
-
Geert Uytterhoeven authored
It is fairly common for named video modes to contain dashes (e.g. "tt-mid" on Atari, "dblntsc-ff" on Amiga). Currently such mode names are not recognized, as the dash is considered to be a separator between mode name and bpp. Fix this by skipping any dashes that are not followed immediately by a digit when looking for the separator. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v4-13-60d38873f782@cerno.techSigned-off-by:
-
Maxime Ripard authored
Some video= options might have a value that contains a dash. However, the command line parsing mode considers all dashes as the separator between the mode and the bpp count. Let's rework the parsing code a bit to only consider a dash as the bpp separator if it before a comma, the options separator. A follow-up patch will add a unit-test for this once such an option is introduced. Reviewed-by:
-
Maxime Ripard authored
The subconnector property was created by drm_mode_create_tv_properties(), but wasn't exposed to the userspace through the generic atomic_get/set_property implementation, and wasn't stored in any generic state structure. Let's solve this. Reviewed-by:
-
Maxime Ripard authored
There is two TV subconnector related properties registered by drm_mode_create_tv_properties(): subconnector and select subconnector. While the select subconnector property is stored in the kernel by the drm_tv_connector_state structure, the subconnector property isn't stored anywhere. Worse, the select subconnector property is stored in a field called subconnector, creating some ambiguity about which property content we're accessing. Let's rename that field to one called select_subconnector to make it move obvious what it's about. Acked-by:
-
Maxime Ripard authored
We currently have two sets of TV properties. The first one is there to deal with analog TV properties, creating properties such as the TV mode, subconnectors, saturation, hue and so on. It's created by calling the drm_mode_create_tv_properties() function. The second one is there to deal with properties that might be useful on a TV, creating the overscan margins for example. It's created by calling the drm_mode_create_tv_margin_properties(). However, we also have a drm_atomic_helper_connector_tv_reset() function that will reset the TV margin properties to their default values, and thus is supposed to be called for the latter set. This creates an ambiguity due to the inconsistent naming. We can thus rename the drm_atomic_helper_connector_tv_reset() function to drm_atomic_helper_connector_tv_margins_reset() to remove that ambiguity and hopefully make it more obvious. Acked-by:
-
Maxime Ripard authored
Since we've recently added a ton of tests, the list starts to be a bit of a mess and creates unneeded conflicts. Let's order it alphabetically. Acked-by:
-
- 08 Oct, 2022 2 commits
-
-
Thomas Zimmermann authored
Rename the atomic helper function drm_atomic_helper_check_crtc_state() to drm_atomic_helper_check_crtc_primary_plane() and only check for an attached primary plane. Adapt callers. Instead of having one big function to check for various CRTC state conditions, we rather want smaller functions that drivers can pick individually. v5: * rebase on top of udl changes Signed-off-by:
-
Thomas Zimmermann authored
In drm_atomic_helper_check_crtc_state(), do not add a new plane state to the global state if it does not exist already. Adding a new plane state will result in overhead for the plane during the atomic-commit step. For the test in drm_atomic_helper_check_crtc_state() to succeed, it is important that the CRTC has an enabled primary plane after the commit. Simply testing the CRTC state's plane_mask for a primary plane is sufficient. Note that the helper still only tests for an attached primary plane. Drivers have to ensure that the plane contains valid pixel information. v5: * fix commit description (Javier) v3: * test for a primary plane in plane_mask (Ville) v2: * remove unnecessary test for plane->crtc (Ville) * inline drm_atomic_get_next_plane_state() (Ville) * acquire plane lock before accessing plane->state (Ville) Signed-off-by:
-
- 07 Oct, 2022 15 commits
-
-
Thomas Zimmermann authored
Add constants for the various commands that the driver can send to the device and update the respective helper functions. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Add register constants for the framebuffer scanout addresses and update the related helper functions. No functional changes. v2: * extract address bytes with helper macros (Javier) * fix comments Signed-off-by:
-
Thomas Zimmermann authored
Add register constants for the video lock. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Add the register constants for setting the color depth. The driver only uses 16bpp. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Add constants for the registers the contain various display-mode parameters and update the mode-setting function. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Move the existing register constants to a new file in preparation of adding more of them. Renaming is intentional. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Use a damage iterator to process damage areas individually. Merging damage areas can result in large updates of unchanged framebuffer regions. As USB is rather slow, it's better to process damage areas individually and hence minimize USB-transfered data. As part of the change, move drm_gem_fb_{begin,end}_cpu_access() into the plane's atomic_update helper. To avoid overhead and intermediate writers, we want to synchronize buffers and reserve access only once before copying damage areas of the framebuffer. v2: * clarify commit message (Javier) Signed-off-by: -
Thomas Zimmermann authored
Add drm_dev_enter() and drm_dev_exit() to the various modesetting functions that interact with the device. After hot-unplugging the device, these functions will return early. So far, the udl driver relied on USB interfaces to handle unplugging of the device. Signed-off-by:
-
Thomas Zimmermann authored
Inline a modesetting helper in the CRTC's enable function. Build the command set directly in the USB URB's buffer and drop an intermediate buffer. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Replace simple-KMS helpers with regular atomic-modesetting helpers. The simple-KMS helpers introduce a mid-layer abstraction without added functionality. Using regular atomic helpers makes the driver's implementation more discoverable and simplifies code sharing. The conversion effectively open-codes the simple-KMS functions and data structure within udl. No functional changes. v2: * don't use the atomic_disable plane helper Signed-off-by:
-
Thomas Zimmermann authored
Remove the empty function udl_simple_display_pipe_mode_valid() and let simple-KMS helpers accept the modes. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Move the connector next to the rest of the modesetting code. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Add style fixes, better error handling and reporting, and minor clean-up changes to the connector code before moving the code to the rest of the modesetting pipeline. Signed-off-by:
-
Thomas Zimmermann authored
Set the USB control-message timeout to the USB default of 5 seconds. Done for consistency with other uses of usb_control_msg() in udl and other drivers. Signed-off-by:
-
Thomas Zimmermann authored
The sku_pixel_limit is a per-device property, similar to the amount of available video memory. Move the respective mode-valid test from the connector to the mode-config structure. Signed-off-by:
-
