- 08 May, 2023 23 commits
-
-
Thomas Zimmermann authored
Push the test for info->screen_base from fb_read() and fb_write() into the implementations of struct fb_ops.{fb_read,fb_write}. In cases where the driver operates on info->screen_buffer, test this field instead. While bothi fields, screen_base and screen_buffer, are stored in the same location, they refer to different address spaces. For correctness, we want to test each field in exactly the code that uses it. v2: * also test screen_base in pvr2fb (Geert) * also test screen_buffer in ivtvfb, arcfb, broadsheetfb, hecubafb, metronomefb and ssd1307fb (Geert) * give a rational for the change (Geert) Signed-off-by:Thomas Zimmermann <tzimmermann@suse.de> Tested-by:
Sui Jingfeng <suijingfeng@loongson.cn> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Acked-by:
Helge Deller <deller@gmx.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230428122452.4856-18-tzimmermann@suse.de
-
Thomas Zimmermann authored
The file-op entry points fb_read() and fb_write() verify that info->state has been set to FBINFO_STATE_RUNNING. Remove the same test from the implementations of struct fb_ops.{fb_read,fb_write}. v2: * also remove test from ivtvfb, braodsheetfb, hecubafb and metronomefb (Geert) Signed-off-by:Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
-
Thomas Zimmermann authored
Use info->screen_buffer when reading and writing framebuffers in system memory. It's the correct pointer for this address space. The struct fb_info has a union to store the framebuffer memory. This can either be info->screen_base if the framebuffer is stored in I/O memory, or info->screen_buffer if the framebuffer is stored in system memory. Since the fb_sys_{read,write}() functions operate on the latter address space, it is wrong to use .screen_base and .screen_buffer must be used instead. This also gets rid of all the casting needed due to not using the correct data type. v2: * add detailed commit message (Javier) Signed-off-by: -
Thomas Zimmermann authored
Always return the number of bytes read or written within the framebuffer. Only return an errno code if framebuffer memory was not touched. This is the semantics required by POSIX and makes fb_read() and fb_write() compatible with IGT tests. [1] This bug has been fixed for fb_write() long ago by commit 6a2a8866 ("[PATCH] fbdev: Fix return error of fb_write"). The code in fb_read() and the corresponding fb_sys_() helpers was forgotten. It can happen that copy_{from, to}_user() only partially copies the given buffer. Take this into account when calculating the number of bytes. v2: * consider return value from copy_{from,to}_user() (Geert) Signed-off-by:
-
Thomas Zimmermann authored
Use info->screen_buffer when reading and writing framebuffers in system memory. It's the correct pointer for this address space. The struct fb_info has a union to store the framebuffer memory. This can either be info->screen_base if the framebuffer is stored in I/O memory, or info->screen_buffer if the framebuffer is stored in system memory. As the driver operates on the latter address space, it is wrong to use .screen_base and .screen_buffer must be used instead. Signed-off-by:
-
Thomas Zimmermann authored
Use info->screen_buffer when reading and writing framebuffers in system memory. It's the correct pointer for this address space. The struct fb_info has a union to store the framebuffer memory. This can either be info->screen_base if the framebuffer is stored in I/O memory, or info->screen_buffer if the framebuffer is stored in system memory. As the driver operates on the latter address space, it is wrong to use .screen_base and .screen_buffer must be used instead. This also gets rid of casting needed due to not using the correct data type. Signed-off-by:
-
Thomas Zimmermann authored
Use info->screen_buffer when reading and writing framebuffers in system memory. It's the correct pointer for this address space. The struct fb_info has a union to store the framebuffer memory. This can either be info->screen_base if the framebuffer is stored in I/O memory, or info->screen_buffer if the framebuffer is stored in system memory. As the driver operates on the latter address space, it is wrong to use .screen_base and .screen_buffer must be used instead. This also gets rid of casting needed due to not using the correct data type. Signed-off-by:
-
Thomas Zimmermann authored
Use info->screen_buffer when reading and writing framebuffers in system memory. It's the correct pointer for this address space. The struct fb_info has a union to store the framebuffer memory. This can either be info->screen_base if the framebuffer is stored in I/O memory, or info->screen_buffer if the framebuffer is stored in system memory. As the driver operates on the latter address space, it is wrong to use .screen_base and .screen_buffer must be used instead. Signed-off-by:
-
Thomas Zimmermann authored
Use info->screen_buffer when reading and writing framebuffers in system memory. It's the correct pointer for this address space. The struct fb_info has a union to store the framebuffer memory. This can either be info->screen_base if the framebuffer is stored in I/O memory, or info->screen_buffer if the framebuffer is stored in system memory. As the driver operates on the latter address space, it is wrong to use .screen_base and .screen_buffer must be used instead. This also gets rid of casting needed due to not using the correct data type. Signed-off-by:
-
Thomas Zimmermann authored
Use info->screen_buffer when reading and writing framebuffers in system memory. It's the correct pointer for this address space. The struct fb_info has a union to store the framebuffer memory. This can either be info->screen_base if the framebuffer is stored in I/O memory, or info->screen_buffer if the framebuffer is stored in system memory. As the driver operates on the latter address space, it is wrong to use .screen_base and .screen_buffer must be used instead. This also gets rid of casting needed due to not using the correct data type. Signed-off-by:
-
Thomas Zimmermann authored
Use info->screen_buffer when reading and writing framebuffers in system memory. It's the correct pointer for this address space. The struct fb_info has a union to store the framebuffer memory. This can either be info->screen_base if the framebuffer is stored in I/O memory, or info->screen_buffer if the framebuffer is stored in system memory. As the driver operates on the latter address space, it is wrong to use .screen_base and .screen_buffer must be used instead. This also gets rid of casting needed due to not using the correct data type. Signed-off-by:
-
Thomas Zimmermann authored
Use info->screen_buffer when reading and writing framebuffers in system memory. It's the correct pointer for this address space. The struct fb_info has a union to store the framebuffer memory. This can either be info->screen_base if the framebuffer is stored in I/O memory, or info->screen_buffer if the framebuffer is stored in system memory. As the driver operates on the latter address space, it is wrong to use .screen_base and .screen_buffer must be used instead. This also gets rid of casting needed due to not using the correct data type. Signed-off-by:
-
Thomas Zimmermann authored
Use info->screen_buffer when reading and writing framebuffers in system memory. It's the correct pointer for this address space. The struct fb_info has a union to store the framebuffer memory. This can either be info->screen_base if the framebuffer is stored in I/O memory, or info->screen_buffer if the framebuffer is stored in system memory. As the driver operates on the latter address space, it is wrong to use .screen_base and .screen_buffer must be used instead. This also gets rid of casting needed due to not using the correct data type. Signed-off-by:
-
Thomas Zimmermann authored
Use info->screen_buffer when reading and writing framebuffers in system memory. It's the correct pointer for this address space. The struct fb_info has a union to store the framebuffer memory. This can either be info->screen_base if the framebuffer is stored in I/O memory, or info->screen_buffer if the framebuffer is stored in system memory. As the driver operates on the latter address space, it is wrong to use .screen_base and .screen_buffer must be used instead. This also gets rid of casting needed due to not using the correct data type. Signed-off-by:
-
Thomas Zimmermann authored
Use info->screen_buffer when reading and writing framebuffers in system memory. It's the correct pointer for this address space. The struct fb_info has a union to store the framebuffer memory. This can either be info->screen_base if the framebuffer is stored in I/O memory, or info->screen_buffer if the framebuffer is stored in system memory. As the driver operates on the latter address space, it is wrong to use .screen_base and .screen_buffer must be used instead. This also gets rid of casting needed due to not using the correct data type. Signed-off-by:
-
Thomas Zimmermann authored
Use info->screen_buffer when reading and writing framebuffers in system memory. It's the correct pointer for this address space. The struct fb_info has a union to store the framebuffer memory. This can either be info->screen_base if the framebuffer is stored in I/O memory, or info->screen_buffer if the framebuffer is stored in system memory. As the driver operates on the latter address space, it is wrong to use .screen_base and .screen_buffer must be used instead. This also gets rid of casting needed due to not using the correct data type. Signed-off-by:
-
Thomas Zimmermann authored
Use info->screen_buffer when reading and writing framebuffers in system memory. It's the correct pointer for this address space. The struct fb_info has a union to store the framebuffer memory. This can either be info->screen_base if the framebuffer is stored in I/O memory, or info->screen_buffer if the framebuffer is stored in system memory. As the driver operates on the latter address space, it is wrong to use .screen_base and .screen_buffer must be used instead. This also gets rid of casting needed due to not using the correct data type. Signed-off-by:
-
Maíra Canal authored
Now that VKMS supports all values of rotation and reflection, drop the "Rotation" task from the TODO list. Signed-off-by:
Maíra Canal <mcanal@igalia.com> Reviewed-by:
Melissa Wen <mwen@igalia.com> Signed-off-by:
Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230418130525.128733-7-mcanal@igalia.com
-
Maíra Canal authored
Currently, vkms supports the rotate-90, rotate-180, reflect-x and reflect-y properties. Therefore, improve the vkms IGT test coverage by adding the rotate-270 property to vkms. The rotation was implement by software: rotate the way the blending occurs by making the source x axis be the destination y axis and the source y axis be the destination x axis and reverse-read the axis. Now, vkms supports all possible rotation values. Tested with igt@kms_rotation_crc@primary-rotation-270 [1], and igt@kms_rotation_crc@sprite-rotation-270 [1]. [1] https://patchwork.freedesktop.org/series/116025/Signed-off-by:
-
Maíra Canal authored
Currently, vkms only supports the rotate-180, reflect-x and reflect-y properties. Therefore, improve the vkms IGT test coverage by adding the rotate-90 property to vkms. The rotation was implement by software: rotate the way the blending occurs by making the source x axis be the destination y axis and the source y axis be the destination x axis. Tested with igt@kms_rotation_crc@primary-rotation-90 [1], igt@kms_rotation_crc@sprite-rotation-90 [1], and igt@kms_rotation_crc@sprite-rotation-90-pos-100-0 [1]. [1] https://patchwork.freedesktop.org/series/116025/Signed-off-by:
-
Maíra Canal authored
Currently, vkms only supports the reflect-x property. Therefore, add the reflect-y property to vkms through a software implementation of the operation. This is possible by reverse reading the y axis during the blending. Note that, by implementing the reflect-x and reflect-y properties, it is also possible to add the rotate-180 property, as it is a combination of those two properties. Tested with igt@kms_rotation_crc@primary-reflect-y [1], igt@kms_rotation_crc@sprite-reflect-y [1], igt@kms_rotation_crc@primary-rotation-180, igt@kms_rotation_crc@sprite-rotation-180, and igt@kms_rotation_crc@cursor-rotation-180. [1] https://patchwork.freedesktop.org/series/116025/Signed-off-by:
-
Maíra Canal authored
Currently, vkms doesn't support any reflection property. Therefore, add the reflect-x property to vkms through a software implementation of the operation. This is possible by reverse reading the x axis during the blending. Tested with igt@kms_rotation_crc@primary-reflect-x [1] and igt@kms_rotation_crc@sprite-reflect-x [1]. [1] https://patchwork.freedesktop.org/series/116025/Signed-off-by:
-
Luc Ma authored
Refer to drmm_vram_helper_init() instead of the non-existent drmm_vram_helper_alloc_mm(). Fixes: a5f23a72 ("drm/vram-helper: Managed vram helpers") Signed-off-by:
Luc Ma <luc@sietium.com> Reviewed-by:
-
- 06 May, 2023 2 commits
-
-
Marek Vasut authored
Do not generate the HS front and back porch gaps, the HSA gap and EOT packet, as these packets are not required. This makes the bridge work with Samsung DSIM on i.MX8MM and i.MX8MP. Signed-off-by:
Marek Vasut <marex@denx.de> Reviewed-by:
Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230403221233.500485-2-marex@denx.de
-
Marek Vasut authored
Do not generate the HS front and back porch gaps, the HSA gap and EOT packet, as these packets are not required. This makes the bridge work with Samsung DSIM on i.MX8MM and i.MX8MP. Signed-off-by:
-
- 05 May, 2023 11 commits
-
-
Francesco Dolcini authored
Remove the unused phy_delay_nsk variable, before it was wrongly used to compute some register value, the fixed computation is no longer using it and therefore can be removed. Signed-off-by:
Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by:
-
Francesco Dolcini authored
Correct computation of THS_TRAILCNT register. This register must be set to a value that ensure that THS_TRAIL > 60 ns + 4 x UI and THS_TRAIL > 8 x UI and THS_TRAIL < TEOT with TEOT = 105 ns + (12 x UI) with the actual value of THS_TRAIL being (1 + THS_TRAILCNT) x ByteClk cycle + ((1 to 2) + 2) xHSBYTECLK cycle + - (PHY output delay) with PHY output delay being about (8 + (5 to 6)) x MIPIBitClk cycle in the BitClk conversion. Fixes: ff1ca639 ("drm/bridge: Add tc358768 driver") Signed-off-by:
-
Francesco Dolcini authored
Correct computation of TXTAGOCNT register. This register must be set to a value that ensure that the TTA-GO period = (4 x TLPX) with the actual value of TTA-GO being 4 x (TXTAGOCNT + 1) x (HSByteClk cycle) Fixes: ff1ca639 ("drm/bridge: Add tc358768 driver") Signed-off-by:
-
Francesco Dolcini authored
Correct computation of THS_ZEROCNT register. This register must be set to a value that ensure that THS_PREPARE + THS_ZERO > 145ns + 10*UI with the actual value of (THS_PREPARE + THS_ZERO) being ((1 to 2) + 1 + (TCLK_ZEROCNT + 1) + (3 to 4)) x ByteClk cycle + + HSByteClk x (2 + (1 to 2)) + (PHY delay) with PHY delay being about (8 + (5 to 6)) x MIPIBitClk cycle in the BitClk conversion. Fixes: ff1ca639 ("drm/bridge: Add tc358768 driver") Signed-off-by:
-
Francesco Dolcini authored
Correct computation of TCLK_TRAILCNT register. The driver does not implement non-continuous clock mode, so the actual value doesn't make a practical difference yet. However this change also ensures that the value does not write to reserved registers bits in case of under/overflow. This register must be set to a value that ensures that TCLK-TRAIL > 60ns and TEOT <= (105 ns + 12 x UI) with the actual value of TCLK-TRAIL being (TCLK_TRAILCNT + (1 to 2)) xHSByteClkCycle + (2 + (1 to 2)) * HSBYTECLKCycle - (PHY output delay) with PHY output delay being about (2 to 3) x MIPIBitClk cycle in the BitClk conversion. Fixes: ff1ca639 ("drm/bridge: Add tc358768 driver") Signed-off-by:
-
Francesco Dolcini authored
Correct computation of TCLK_ZEROCNT register. This register must be set to a value that ensure that (TCLK-PREPARECNT + TCLK-ZERO) > 300ns with the actual value of (TCLK-PREPARECNT + TCLK-ZERO) being (1 to 2) + (TCLK_ZEROCNT + 1)) x HSByteClkCycle + (PHY output delay) with PHY output delay being about (2 to 3) x MIPIBitClk cycle in the BitClk conversion. Fixes: ff1ca639 ("drm/bridge: Add tc358768 driver") Signed-off-by:
-
Francesco Dolcini authored
Correctly compute the PLL target frequency, the current formula works correctly only when the input bus width is 24bit, actually to properly compute the PLL target frequency what is relevant is the bits-per-pixel on the DSI link. No regression expected since the DSI format is currently hard-coded as MIPI_DSI_FMT_RGB888. Fixes: ff1ca639 ("drm/bridge: Add tc358768 driver") Signed-off-by:
-
Francesco Dolcini authored
According to Toshiba documentation the PLL input clock after the divider should be not less than 4MHz, fix the PLL parameters computation accordingly. Fixes: ff1ca639 ("drm/bridge: Add tc358768 driver") Signed-off-by:
-
Francesco Dolcini authored
Always enable HS video mode setting the TXMD bit, without this change no video output is present with DSI sinks that are setting MIPI_DSI_MODE_LPM flag (tested with LT8912B DSI-HDMI bridge). Previously the driver was enabling HS mode only when the DSI sink was not explicitly setting the MIPI_DSI_MODE_LPM, however this is not correct. The MIPI_DSI_MODE_LPM is supposed to indicate that the sink is willing to receive data in low power mode, however clearing the TC358768_DSI_CONTROL_TXMD bit will make the TC358768 send video in LP mode that is not the intended behavior. Fixes: ff1ca639 ("drm/bridge: Add tc358768 driver") Signed-off-by:
-
Brian Norris authored
If we disable vblank when entering self-refresh, vblank APIs (like DRM_IOCTL_WAIT_VBLANK) no longer work. But user space is not aware when we enter self-refresh, so this appears to be an API violation -- that DRM_IOCTL_WAIT_VBLANK fails with EINVAL whenever the display is idle and enters self-refresh. The downstream driver used by many of these systems never used to disable vblank for PSR, and in fact, even upstream, we didn't do that until radically redesigning the state machine in commit 6c836d96 ("drm/rockchip: Use the helpers for PSR"). Thus, it seems like a reasonable API fix to simply restore that behavior, and leave vblank enabled. Note that this appears to potentially unbalance the drm_crtc_vblank_{off,on}() calls in some cases, but: (a) drm_crtc_vblank_on() documents this as OK and (b) if I do the naive balancing, I find state machine issues such that we're not in sync properly; so it's easier to take advantage of (a). This issue was exposed by IGT's kms_vblank tests, and reported by KernelCI. The bug has been around a while (longer than KernelCI noticed), but was only exposed once self-refresh was bugfixed more recently, and so KernelCI could properly test it. Some other notes in: https://lore.kernel.org/dri-devel/Y6OCg9BPnJvimQLT@google.com/ Re: renesas/master bisection: igt-kms-rockchip.kms_vblank.pipe-A-wait-forked on rk3399-gru-kevin == Backporting notes: == Marking as 'Fixes' commit 6c836d96 ("drm/rockchip: Use the helpers for PSR"), but it probably depends on commit bed030a4 ("drm/rockchip: Don't fully disable vop on self refresh") as well. We also need the previous patch ("drm/atomic: Allow vblank-enabled + self-refresh "disable""), of course. v3: * no update v2: * skip unnecessary lock/unlock Fixes: 6c836d96 ("drm/rockchip: Use the helpers for PSR") Cc: <stable@vger.kernel.org> Reported-by:
"kernelci.org bot" <bot@kernelci.org> Link: https://lore.kernel.org/dri-devel/Y5itf0+yNIQa6fU4@sirena.org.uk/Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230109171809.v3.2.Ic07cba4ab9a7bd3618a9e4258b8f92ea7d10ae5a@changeid
-
Brian Norris authored
The self-refresh helper framework overloads "disable" to sometimes mean "go into self-refresh mode," and this mode activates automatically (e.g., after some period of unchanging display output). In such cases, the display pipe is still considered "on", and user-space is not aware that we went into self-refresh mode. Thus, users may expect that vblank-related features (such as DRM_IOCTL_WAIT_VBLANK) still work properly. However, we trigger the WARN_ONCE() here if a CRTC driver tries to leave vblank enabled. Add a different expectation: that CRTCs *should* leave vblank enabled when going into self-refresh. This patch is preparation for another patch -- "drm/rockchip: vop: Leave vblank enabled in self-refresh" -- which resolves conflicts between the above self-refresh behavior and the API tests in IGT's kms_vblank test module. == Some alternatives discussed: == It's likely that on many display controllers, vblank interrupts will turn off when the CRTC is disabled, and so in some cases, self-refresh may not support vblank. To support such cases, we might consider additions to the generic helpers such that we fire vblank events based on a timer. However, there is currently only one driver using the common self-refresh helpers (i.e., rockchip), and at least as of commit bed030a4 ("drm/rockchip: Don't fully disable vop on self refresh"), the CRTC hardware is powered enough to continue to generate vblank interrupts. So we chose the simpler option of leaving vblank interrupts enabled. We can reevaluate this decision and perhaps augment the helpers if/when we gain a second driver that has different requirements. v3: * include discussion summary v2: * add 'ret != 0' warning case for self-refresh * describe failing test case and relation to drm/rockchip patch better Cc: <stable@vger.kernel.org> # dependency for "drm/rockchip: vop: Leave # vblank enabled in self-refresh" Signed-off-by:
-
- 04 May, 2023 1 commit
-
-
Alexander Stein authored
If PLL locking failed, the regulator needs to be disabled again. Fixes: 5664e3c9 ("drm/bridge: ti-sn65dsi83: Add vcc supply regulator support") Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
- 03 May, 2023 2 commits
-
-
Dan Carpenter authored
The "unode" pointer cannot be NULL here and checking for it causes Smatch warnings: drivers/gpu/drm/udl/udl_main.c:259 udl_get_urb_locked() warn: can 'unode' even be NULL? Fortunately, it's just harmless dead code which can be removed. It's left over from commit c5c354a3 ("drm/udl: Fix inconsistent urbs.count value during udl_free_urb_list()"). Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Christian König authored
When no hw fence is provided for a job that means that the job didn't executed. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Luben Tuikov <luben.tuikov@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230427122726.1290170-1-christian.koenig@amd.com
-
- 02 May, 2023 1 commit
-
-
Jani Nikula authored
Calling drm_connector_update_edid_property() should be done unconditionally instead of depending on the number of modes added. Also match the call order in inno_hdmi and rk3066_hdmi. Cc: Sandy Huang <hjc@rock-chips.com> Cc: Heiko Stübner <heiko@sntech.de> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/bb733eccfb389533cc6e207689be845164a1ed91.1662036058.git.jani.nikula@intel.com
-
