- 09 Jul, 2022 12 commits
-
-
Geert Uytterhoeven authored
Introduce fourcc codes for single-channel frame buffer formats with two, four, and sixteen brightness levels, where there is a direct relationship between channel value and brightness. As the number of bits per pixel is less than eight, these rely on proper block handling for the calculation of bits per pixel and pitch. The fill order (the order in which multiple pixels are packed in a byte) is the same order as used for grayscale (2, 4, and 16 levels) images in the PNG specification, Version 1.2. This order is also the recommended and default order (FillOrder = 1) for bilevel and grayscale (16 levels) images in the TIFF 6.0 Specification, and is also used for monochrome images in the PBM file format, monochrome Linux frame buffer logos, and BDF and PSF (Linux kernel) font files. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/96561a88e53c59cac72e66642bf4c097aacefd18.1657294931.git.geert@linux-m68k.org
-
Geert Uytterhoeven authored
Traditionally, the first channel has been called the "red" channel, but the fourcc values for single-channel "red" formats can also be used for other single-channel formats with a direct relationship between channel value and brightness, like grayscale. Signed-off-by:
-
Geert Uytterhoeven authored
The AFBC helpers derive the number of bits per pixel from the deprecated drm_format_info.cpp[] field, which does not take into account block sizes. Fix this by using the actual number of bits per pixel instead. Signed-off-by:
-
Geert Uytterhoeven authored
Add support for color-indexed frame buffer formats with two, four, and sixteen colors to the DRM framebuffer helper functions: 1. Add support for 1, 2, and 4 bits per pixel to the damage helper, 2. For color-indexed modes, the length of the color bitfields must be set to the color depth, else the logo code may pick a logo with too many colors. Drop the incorrect DAC width comment, which originates from the i915 driver. 3. Accept C[124] modes when validating or filling in struct fb_var_screeninfo, and use the correct number of bits per pixel. 4. Set the visual to FB_VISUAL_PSEUDOCOLOR for all color-indexed modes. Signed-off-by: -
Geert Uytterhoeven authored
Introduce fourcc codes for color-indexed frame buffer formats with two, four, and sixteen colors, and provide a mapping from bits per pixel and depth to fourcc codes. As the number of bits per pixel is less than eight, these rely on proper block handling for the calculation of bits per pixel and pitch. The fill order (the order in which multiple pixels are packed in a byte) is the same order as used for indexed-color (2, 4, and 16 colors) images in the PNG specification, Version 1.2. This order is also the recommended and default order (FillOrder = 1) for palette-color (16 colors) images in the TIFF 6.0 Specification, and is also used for 16-color Linux frame buffer logos. Signed-off-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by:
-
Geert Uytterhoeven authored
When userspace queries the properties of a frame buffer, the number of bits per pixel is derived from the deprecated drm_format_info.cpp[] field, which does not take into account block sizes. Fix this by using the actual number of bits per pixel instead. Signed-off-by:
-
Geert Uytterhoeven authored
When allocating a frame buffer, the number of bits per pixel needed is derived from the deprecated drm_format_info.cpp[] field. While this may work for formats using less than 8 bits per pixel, it does lead to a large overallocation. Reduce memory consumption by using the actual number of bits per pixel instead. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
-
Geert Uytterhoeven authored
Add a flag to struct drm_format_info to indicate if a format is color-indexed, similar to the existing .is_yuv flag. This way generic code and drivers can just check this flag, instead of checking against a list of fourcc formats. Signed-off-by:
-
Geert Uytterhoeven authored
Add a helper to retrieve the actual number of bits per pixel for a plane, taking into account the number of characters and pixels per block for tiled formats. Signed-off-by:
-
Uwe Kleine-König authored
All implementations return 0 and the return value of mipi_dsi_drv_remove() is ignored anyhow. So change the prototype of the remove function to return no value. This way driver authors are not tempted to assume that passing an error to the upper layer is a good idea. All drivers are adapted accordingly. There is no intended change of behaviour. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
-
Uwe Kleine-König authored
Returning an error code from a mipi_dsi remove callback fails, this is silently ignored. (mipi_dsi_drv_remove() propagates the return value to device_remove() which ignores it.) So emit an error code in the driver remove function and return 0. Signed-off-by:
-
Uwe Kleine-König authored
panel_simple_remove() returns zero unconditionally. Make it return no value instead making more obvious what happens in the callers. This is a preparation for making platform and mipi-dsi remove callbacks return void. Signed-off-by:
-
- 08 Jul, 2022 4 commits
-
-
Dan Carpenter authored
This code works, but technically it uses "num_in_bus_fmts" before it has been initialized so it leads to static checker warnings and probably KMEMsan warnings at run time. Initialize the variable to zero to silence the warning. Fixes: f32df58a ("drm/bridge: Add the necessary bits to support bus format negotiation") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/YrrIs3hoGcPVmXc5@kili
-
Samuel Holland authored
Allwinner display drivers are split roughly into two generations. The first generation was found on early 32-bit ARM SoCs and contains DE1.0 and a custom HDMI controller. Clarify that these options only apply to a specific list of SoCs, and limit selecting them to 32-bit ARM, to avoid confusion. The second generation, found in A83T and newer SoCs (both 32-bit and 64-bit), contains a DE2.0 and a DesignWare HDMI controller. Since this is the most widely-used generation, enable it by default. The previous default condition (MACH_SUN8I) was limited to 32-bit SoCs. Also enable the DSI controller by default, which is found on 64-bit SoCs as well. Signed-off-by:
Samuel Holland <samuel@sholland.org> Signed-off-by:
-
Maxime Ripard authored
The current code tries to handle the case where CONFIG_PM isn't selected by first calling our runtime_resume implementation and then properly report the power state to the runtime_pm core. This allows to have a functionning device even if pm_runtime_get_* functions are nops. However, the device power state if CONFIG_PM is enabled is RPM_SUSPENDED, and thus our vc4_hdmi_write() and vc4_hdmi_read() calls in the runtime_pm hooks will now report a warning since the device might not be properly powered. Even more so, we need CONFIG_PM enabled since the previous RaspberryPi have a power domain that needs to be powered up for the HDMI controller to be usable. The previous patch has created a dependency on CONFIG_PM, now we can just assume it's there and only call pm_runtime_resume_and_get() to make sure our device is powered in bind. Link: https://lore.kernel.org/r/20220629123510.1915022-39-maxime@cerno.techAcked-by:
Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by:
-
Maxime Ripard authored
We already depend on runtime PM to get the power domains and clocks for most of the devices supported by the vc4 driver, so let's just select it to make sure it's there. Link: https://lore.kernel.org/r/20220629123510.1915022-38-maxime@cerno.techAcked-by:
-
- 07 Jul, 2022 4 commits
-
-
Jianglei Nie authored
nouveau_bo_alloc() allocates a memory chunk for "nvbo" with kzalloc(). When some error occurs, "nvbo" should be released. But when WARN_ON(pi < 0)) equals true, the function return ERR_PTR without releasing the "nvbo", which will lead to a memory leak. We should release the "nvbo" with kfree() if WARN_ON(pi < 0)) equals true. Signed-off-by:
Jianglei Nie <niejianglei2021@163.com> Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
-
Jianglei Nie authored
nouveau_bo_init() is backed by ttm_bo_init() and ferries its return code back to the caller. On failures, ttm will call nouveau_bo_del_ttm() and free the memory.Thus, when nouveau_bo_init() returns an error, the gem object has already been released. Then the call to nouveau_bo_ref() will use the freed "nvbo->bo" and lead to a use-after-free bug. We should delete the call to nouveau_bo_ref() to avoid the use-after-free. Signed-off-by:
-
Alvin Šipraga authored
cec_unregister_adapter() assumes that the underlying adapter ops are callable. For example, if the CEC adapter currently has a valid physical address, then the unregistration procedure will invalidate the physical address by setting it to f.f.f.f. Whence the following kernel oops observed after removing the adv7511 module: Unable to handle kernel execution of user memory at virtual address 0000000000000000 Internal error: Oops: 86000004 [#1] PREEMPT_RT SMP Call trace: 0x0 adv7511_cec_adap_log_addr+0x1ac/0x1c8 [adv7511] cec_adap_unconfigure+0x44/0x90 [cec] __cec_s_phys_addr.part.0+0x68/0x230 [cec] __cec_s_phys_addr+0x40/0x50 [cec] cec_unregister_adapter+0xb4/0x118 [cec] adv7511_remove+0x60/0x90 [adv7511] i2c_device_remove+0x34/0xe0 device_release_driver_internal+0x114/0x1f0 driver_detach+0x54/0xe0 bus_remove_driver+0x60/0xd8 driver_unregister+0x34/0x60 i2c_del_driver+0x2c/0x68 adv7511_exit+0x1c/0x67c [adv7511] __arm64_sys_delete_module+0x154/0x288 invoke_syscall+0x48/0x100 el0_svc_common.constprop.0+0x48/0xe8 do_el0_svc+0x28/0x88 el0_svc+0x1c/0x50 el0t_64_sync_handler+0xa8/0xb0 el0t_64_sync+0x15c/0x160 Code: bad PC value ---[ end trace 0000000000000000 ]--- Protect against this scenario by unregistering i2c_cec after unregistering the CEC adapter. Duly disable the CEC clock afterwards too. Fixes: 3b1b9750 ("drm: adv7511/33: add HDMI CEC support") Signed-off-by:Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by:
Robert Foss <robert.foss@linaro.org> Signed-off-by:
-
Alvin Šipraga authored
The ADV7511_REG_CEC_CTRL = 0xE2 register is part of the main register map - not the CEC register map. As such, we shouldn't apply an offset to the register address. Doing so will cause us to address a bogus register for chips with a CEC register map offset (e.g. ADV7533). Fixes: 3b1b9750 ("drm: adv7511/33: add HDMI CEC support") Signed-off-by:
-
- 06 Jul, 2022 9 commits
-
-
Randy Dunlap authored
Add a header file to prevent build errors: ../drivers/gpu/drm/xlnx/zynqmp_dp.c: In function ‘zynqmp_dp_write’: ../drivers/gpu/drm/xlnx/zynqmp_dp.c:335:9: error: implicit declaration of function ‘writel’ [-Werror=implicit-function-declaration] 335 | writel(val, dp->iomem + offset); ../drivers/gpu/drm/xlnx/zynqmp_dp.c: In function ‘zynqmp_dp_read’: ../drivers/gpu/drm/xlnx/zynqmp_dp.c:340:16: error: implicit declaration of function ‘readl’ [-Werror=implicit-function-declaration] 340 | return readl(dp->iomem + offset); Fixes: a204f974 ("drm: Remove linux/i2c.h from drm_crtc.h") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Hyun Kwon <hyun.kwon@xilinx.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Michal Simek <michal.simek@xilinx.com> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220706184224.29116-1-rdunlap@infradead.org
-
Sam Ravnborg authored
Move away from the deprecated enable/disable operations in drm_bridge_funcs and enable atomic use. v3: - Drop use of DRM_BRIDGE_STATE_OPS v2: - fix build (kernel test robot <lkp@intel.com>) Signed-off-by:
-
Liu Ying authored
When LVDS dual link is used, we have to enable the LDB_CTRL_SPLIT_MODE bit. Fixes: 463db5c2 ("drm: bridge: ldb: Implement simple Freescale i.MX8MP LDB bridge") Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Marek Vasut <marex@denx.de> Cc: NXP Linux Team <linux-imx@nxp.com> Signed-off-by:
Liu Ying <victor.liu@nxp.com> Reviewed-by:
Marek Vasut <marex@denx.de> Signed-off-by:
-
Liu Ying authored
With LVDS dual link, up to 160MHz mode clock rate is supported. With LVDS single link, up to 80MHz mode clock rate is supported. Fix mode clock rate validation by swapping the maximum mode clock rates of the two link modes. Fixes: 463db5c2 ("drm: bridge: ldb: Implement simple Freescale i.MX8MP LDB bridge") Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Marek Vasut <marex@denx.de> Cc: NXP Linux Team <linux-imx@nxp.com> Signed-off-by:
-
Marek Vasut authored
The DE inversion is implemented in LCDIFv3 driver and is no longer needed in the LDB bridge which does not invert the DE signal. Drop the inversion. Fixes: 463db5c2 ("drm: bridge: ldb: Implement simple Freescale i.MX8MP LDB bridge") Signed-off-by:
-
Hsin-Yi Wang authored
Move hpd polling check into wait_hpd_asserted() callback. For the cases that aux transfer function wasn't used, do hpd polling check after pm runtime resume, which will power on the bridge. Signed-off-by:
Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by:
Xin Ji <xji@analogixsemi.com> Signed-off-by:
-
Hsin-Yi Wang authored
Move devm_of_dp_aux_populate_ep_devices() after pm runtime and i2c setup to avoid NULL pointer crash. edp-panel probe (generic_edp_panel_probe) calls pm_runtime_get_sync() to read EDID. At this time, bridge should have pm runtime enabled and i2c clients ready. Fixes: adca62ec ("drm/bridge: anx7625: Support reading edid through aux channel") Signed-off-by:
-
Hsin-Yi Wang authored
There's no need to check for IRQ or disable it in suspend. Use pm_runtime_force_suspend(resume) to make sure anx7625 is powered off correctly. Make the system suspend/resume and pm runtime suspend/resume more consistent. Signed-off-by:
-
Hsin-Yi Wang authored
Simplify the resource management. Signed-off-by:
-
- 05 Jul, 2022 4 commits
-
-
Ville Syrjälä authored
drm_crtc.h has no need for linux/i2c.h, so don't include it. Avoids useless rebuilds of the entire universe when touching linux/i2c.h. Quite a few placs do currently depend on linux/i2c.h without actually including it directly. All of those need to be fixed up. v2: imx and mcde need linux/io.h for readl()/etc. Acked-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Ville Syrjälä authored
drm_crtc.h has no need for linux/media-bus-format.h, so don't include it. Avoids useless rebuilds of the entire universe when touching linux/media-bus-format.h. Quite a few placs do currently depend on linux/media-bus-format.h without actually including it directly. All of those need to be fixed up. v2: Deal with ingenic as well v3: Fix up mxsfb and remaining parts of imx Acked-by:
-
Ville Syrjälä authored
drm_crtc.h has no need for linux/fb.h, so don't include it. Avoids useless rebuilds of the entire universe when touching linux/fb.h. Quite a few placs do currently depend on linux/fb.h or other headers pulled in by it without actually including any of it directly. All of those need to be fixed up. v2: Split the vmwgfx change out Acked-by:
-
Ville Syrjälä authored
Stop using the 'TRUE' define. This ultimately gets defined by acpi/actypes.h that gets included here via a convoluted chain of other headers. drm_crtc.h is part of that chain, and I'm trying to eliminate all unnecessary includes from it to avoid pointless rebuilds. v2: Split out from the bigger patch Cc: Zack Rusin <zackr@vmware.com> Cc: VMware Graphics Reviewers <linux-graphics-maintainer@vmware.com> Acked-by:
-
- 04 Jul, 2022 2 commits
-
-
Hangyu Hua authored
The next call to sii8620_burst_get_tx_buf will result in off-by-one When ctx->burst.tx_count + size == ARRAY_SIZE(ctx->burst.tx_buf). The same thing happens in sii8620_burst_get_rx_buf. This patch also change tx_count and tx_buf to rx_count and rx_buf in sii8620_burst_get_rx_buf. It is unreasonable to check tx_buf's size and use rx_buf. Fixes: e19e9c69 ("drm/bridge/sii8620: add support for burst eMSC transmissions") Signed-off-by:
Hangyu Hua <hbh25y@gmail.com> Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by:
-
Paul Cercueil authored
Until now, when running at the maximum resolution of 1280x720 at 32bpp on the JZ4770 SoC the output was garbled, the X/Y position of the top-left corner of the framebuffer warping to a random position with the whole image being offset accordingly, every time a new frame was being submitted. This problem can be eliminated by using a bigger burst size for the DMA. Set in each soc_info structure the maximum burst size supported by the corresponding SoC, and use it in the driver. Set the new value using regmap_update_bits() instead of regmap_set_bits(), since we do want to override the old value of the burst size. (Note that regmap_set_bits() wasn't really valid before for the same reason, but it never seemed to be a problem). Cc: <stable@vger.kernel.org> Fixes: 90b86fcc ("DRM: Add KMS driver for the Ingenic JZ47xx SoCs") Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20220702230727.66704-1-paul@crapouillou.netAcked-by:
Christophe Branchereau <cbranchereau@gmail.com>
-
- 03 Jul, 2022 5 commits
-
-
Marco Felsch authored
Add support for the 1024x600 LVDS panel. Signed-off-by:
Marco Felsch <m.felsch@pengutronix.de> Signed-off-by:
-
Marco Felsch authored
Add binding for the Emerging Display Technology ETML0700Y5DHA panel. It is a 7" WSVGA (1024x600) TFT LCD panel with: - LVDS data interface, - backlight and - capacitive touch. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Svyatoslav Ryhel authored
Add definition of the HannStar HSD101PWW2 Rev0-A00/A01 LCD SuperIPS+ HD panel. Signed-off-by:
Svyatoslav Ryhel <clamor95@gmail.com> Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Signed-off-by:
-
Svyatoslav Ryhel authored
Add HannStar HSD101PWW2 10.1" WXGA (1280x800) TFT-LCD LVDS panel to the list of compatibles. Acked-by:
-
Anton Bambura authored
LQ101R1SX03 is compatible with LQ101R1SX01 from software perspective, document it. The LQ101R1SX03 is a newer revision of LQ101R1SX01, it has minor differences in hardware pins in comparison to the older version. The newer version of the panel can be found on Android tablets, like ASUS TF701T. Reviewed-by:
Anton Bambura <jenneron@protonmail.com> Signed-off-by:
-
