- 27 Jan, 2022 25 commits
-
-
Javier Martinez Canillas authored
The macro calls to a DRM specific platform driver init handler that checks whether the driver is allowed to be registered or not. Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211217003752.3946210-15-javierm@redhat.com
-
Javier Martinez Canillas authored
The macro calls to a DRM specific platform driver init handler that checks whether the driver is allowed to be registered or not. Signed-off-by:
-
Javier Martinez Canillas authored
The macro calls to a DRM specific platform driver init handler that checks whether the driver is allowed to be registered or not. Signed-off-by:
-
Javier Martinez Canillas authored
The macro calls to a DRM specific platform driver init handler that checks whether the driver is allowed to be registered or not. Signed-off-by:
-
Javier Martinez Canillas authored
The macro calls to a DRM specific platform driver init handler that checks whether the driver is allowed to be registered or not. Signed-off-by:
-
Javier Martinez Canillas authored
The macro calls to a DRM specific platform driver init handler that checks whether the driver is allowed to be registered or not. Signed-off-by:
-
Javier Martinez Canillas authored
The macro calls to a DRM specific platform driver init handler that checks whether the driver is allowed to be registered or not. Signed-off-by:
-
Javier Martinez Canillas authored
The macro calls to a DRM specific platform driver init handler that checks whether the driver is allowed to be registered or not. Signed-off-by:
-
Thomas Zimmermann authored
Remove custom vmwgfx_init() and vmwgfx_exit() functions and initialize the module with DRM_module helpers. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
-
Thomas Zimmermann authored
Remove custom vbox_init() and vbox_exit() functions and initialize the module with DRM module helpers. Signed-off-by:
-
Thomas Zimmermann authored
Remove custom qxl_init() and qxl_exit() functions and initialize the module with DRM module helpers. Signed-off-by:
-
Thomas Zimmermann authored
Move the array qxl_ioctl to qxl_drv.c and initialize the num_ioctls field of struct drm_driver at runtime. Replaces the current fragile ioctl setup and allows for generating the module init/exit code. Signed-off-by:
-
Thomas Zimmermann authored
Remove custom mgag200_init() and mgag200_exit() functions and initialize the module with DRM_module helpers. Signed-off-by:
-
Javier Martinez Canillas authored
The commit feeb07d0 ("drm/hisilicon/hibmc: Make CONFIG_DRM_HISI_HIBMC depend on ARM64") made the driver Kconfig symbol to depend on ARM64 since it only supports that architecture and loading the module on others would lead to incorrect video modes being used. But it also prevented the driver to be built on other architectures which is useful to have compile test coverage when doing subsystem wide changes. Make the dependency instead to be (ARM64 || COMPILE_TEST), so the driver is buildable when the CONFIG_COMPILE_TEST option is enabled. Signed-off-by:
-
Marek Vasut authored
Add Multi-Inno Technology MI0700S4T-6 7" 800x480 DPI panel support. Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Sam Ravnborg <sam@ravnborg.org> To: dri-devel@lists.freedesktop.org Signed-off-by:
-
Marek Vasut authored
Add Multi-Inno Technology MI0700S4T-6 7" 800x480 DPI panel compatible string. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Marek Vasut authored
When the system shuts down or warm reboots, the display may be active. Implement the platform_driver .shutdown() operation and shut down the display. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Marek Vasut authored
When the device is unbound from the driver, the display may be active. Make sure it gets shut down. Signed-off-by:
-
Marek Vasut authored
Add compatible string for TI DS90CF364A, which is another LVDS to DPI decoder similar to DS90CF384A, except it is using smaller package and only provides 18bit DPI bus. Signed-off-by:
-
Thomas Zimmermann authored
Add a TODO item about requesting memory regions for each driver. The current DRM drivers don't do this consistently. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220125091222.21457-6-tzimmermann@suse.de
-
Thomas Zimmermann authored
Requesting the framebuffer memory in simpledrm marks the memory range as busy. This used to be done by the firmware sysfb code, but the driver is the correct place. v2: * store memory region in struct for later cleanup (Javier) Signed-off-by:
-
Thomas Zimmermann authored
Requesting the framebuffer memory in simpledrm marks the memory range as busy. This used to be done by the firmware sysfb code, but the driver is the correct place. v2: * use I/O memory if request_mem_region() fails (Jocelyn) Signed-off-by:
Jocelyn Falempe <jfalempe@redhat.com> Reviewed-by:
-
Javier Martinez Canillas authored
The sysfb_create_simplefb() function requests a IO memory resource for the simple-framebuffer platform device, but it also marks it as busy which can lead to drivers requesting the same memory resource to fail. Let's drop the IORESOURCE_BUSY flag and let drivers to request it as busy instead. Signed-off-by:
Zack Rusin <zackr@vmware.com> Reviewed-by:
-
Thomas Zimmermann authored
Hot-unplug all firmware-framebuffer devices as part of removing them via remove_conflicting_framebuffers() et al. Releases all memory regions to be acquired by native drivers. Firmware, such as EFI, install a framebuffer while posting the computer. After removing the firmware-framebuffer device from fbdev, a native driver takes over the hardware and the firmware framebuffer becomes invalid. Firmware-framebuffer drivers, specifically simplefb, don't release their device from Linux' device hierarchy. It still owns the firmware framebuffer and blocks the native drivers from loading. This has been observed in the vmwgfx driver. [1] Initiating a device removal (i.e., hot unplug) as part of remove_conflicting_framebuffers() removes the underlying device and returns the memory range to the system. [1] https://lore.kernel.org/dri-devel/20220117180359.18114-1-zack@kde.org/ v2: * rename variable 'dev' to 'device' (Javier) Signed-off-by:
-
Linus Walleij authored
The panel ACX424AKP seems to only be used in prototypes, whereas real products use the 10 pixels shorter ACX424AKM. Extend the ACX424AKP bindings to also cover the ACX424AKM. The ACX424AKM was used in a few different mobile phones from Sony Mobile. Cc: devicetree@vger.kernel.org Cc: phone-devel@vger.kernel.org Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Acked-by:
-
- 26 Jan, 2022 4 commits
-
-
Yunlong Jia authored
We have added corresponding information: [BOE]NV116WHM-N45 use delay_200_500_e50 [KDB]116N29-30NK-C007 use delay_200_500_e80_d50 [STA]2081116HHD028001-51D use delay_100_500_e200 Add 3 panels & 2 delay. Signed-off-by:Yunlong Jia <yunlong.jia@ecs.corp-partner.google.com> Signed-off-by:
Grace Mi <grace.mi@ecs.corp-partner.google.com> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Christian König authored
Keep track for which BO a resource was allocated. This is necessary to move the LRU handling into the resources. A bit problematic is i915 since it tries to use the resource interface without a BO which is illegal from the conceptional point of view. v2: Document that this is a weak reference and add a workaround for i915 v3: further document that this is protected by ttm_device::lru_lock and clarify the i915 workaround Signed-off-by:Christian König <christian.koenig@amd.com> Acked-by:
Huang Rui <ray.huang@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220124122514.1832-4-christian.koenig@amd.com
-
Christian König authored
It is simply a lot cleaner to have this around instead of adding the device throughout the call chain. Signed-off-by:
-
Christian König authored
Make sure we call the common cleanup function in all implementations of the resource manager. v2: fix missing case in i915, rudimentary kerneldoc, should be filled in more when we add more functionality Signed-off-by:
-
- 25 Jan, 2022 11 commits
-
-
Zhou Qingyang authored
In nvkm_acr_hsfw_load_bl(), the return value of kmalloc() is directly passed to memcpy(), which could lead to undefined behavior on failure of kmalloc(). Fix this bug by using kmemdup() instead of kmalloc()+memcpy(). This bug was found by a static analyzer. Builds with 'make allyesconfig' show no new warnings, and our static analyzer no longer warns about this code. Fixes: 22dcda45 ("drm/nouveau/acr: implement new subdev to replace "secure boot"") Signed-off-by:
Zhou Qingyang <zhou1615@umn.edu> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Yaroslav Bolyukin authored
Per VESA DisplayID Standard v2.0: Type VII Timing – Detailed Timing Data Definitions were already provided as type I, but not used Signed-off-by:
Yaroslav Bolyukin <iam@lach.pw> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Maxime Ripard authored
In order to support the YUV output, we'll need the atomic state to know what is the state of the associated property in the CSC setup callback. Let's change the prototype of that callback to allow us to access it. Acked-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-11-maxime@cerno.tech
-
Maxime Ripard authored
The current CSC setup code for the BCM2711 uses a sequence of register writes to configure the CSC depending on whether we output using a full or limited range. However, with the upcoming introduction of the YUV output, we're going to add new matrices to perform the conversions, so we should switch to something a bit more flexible that takes the matrix as an argument and programs the CSC accordingly. Acked-by:
-
Maxime Ripard authored
On BCM2711, the HDMI_CSC_CTL register value has been hardcoded to an opaque value. Let's replace it with properly defined values. Acked-by:
-
Maxime Ripard authored
On the BCM2711, the HDMI_VEC_INTERFACE_XBAR register configuration depends on whether we're using an RGB or YUV output. Let's move that configuration to the CSC setup. Acked-by:
-
Maxime Ripard authored
The CSC callbacks takes a boolean as an argument to tell whether we're using the full range or limited range RGB. However, with the upcoming YUV support, the logic will be a bit more complex. In order to address this, let's make the callbacks take the entire mode, and call our new helper to tell whether the full or limited range RGB should be used. Acked-by:
-
Maxime Ripard authored
We're going to need to tell whether we want to run with a full or limited range RGB output in multiple places in the code, so let's create a helper that will return whether we need with full range or not. Acked-by:
-
Maxime Ripard authored
The HDMI specification mentions YCbCr everywhere, but our enums have YCrCb. Let's rename it to match. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-5-maxime@cerno.tech
-
Maxime Ripard authored
The current code assumes that the RGB444 and YUV444 formats are the same, but the HDMI 2.0 specification states that: The three DC_XXbit bits above only indicate support for RGB 4:4:4 at that pixel size. Support for YCBCR 4:4:4 in Deep Color modes is indicated with the DC_Y444 bit. If DC_Y444 is set, then YCBCR 4:4:4 is supported for all modes indicated by the DC_XXbit flags. So if we have YUV444 support and any DC_XXbit flag set but the DC_Y444 flag isn't, we'll assume that we support that deep colour mode for YUV444 which breaks the specification. In order to fix this, let's split the edid_hdmi_dc_modes field in struct drm_display_info into two fields, one for RGB444 and one for YUV444. Suggested-by:
-
Maxime Ripard authored
The current code, when parsing the EDID Deep Color depths, that the YUV422 cannot be used, referring to the HDMI 1.3 Specification. This specification, in its section 6.2.4, indeed states: For each supported Deep Color mode, RGB 4:4:4 shall be supported and optionally YCBCR 4:4:4 may be supported. YCBCR 4:2:2 is not permitted for any Deep Color mode. This indeed can be interpreted like the code does, but the HDMI 1.4 specification further clarifies that statement in its section 6.2.4: For each supported Deep Color mode, RGB 4:4:4 shall be supported and optionally YCBCR 4:4:4 may be supported. YCBCR 4:2:2 is also 36-bit mode but does not require the further use of the Deep Color modes described in section 6.5.2 and 6.5.3. This means that, even though YUV422 can be used with 12 bit per color, it shouldn't be treated as a deep color mode. This is also broken with YUV444 if it's supported by the display, but DRM_EDID_HDMI_DC_Y444 isn't set. In such a case, the code will clear color_formats of the YUV444 support set previously in drm_parse_cea_ext(), but will not set it back. Since the formats supported are already setup properly in drm_parse_cea_ext(), let's just remove the code modifying the formats in drm_parse_hdmi_deep_color_info() Fixes: d0c94692 ("drm/edid: Parse and handle HDMI deep color modes.") Signed-off-by:
-
