- 08 May, 2023 14 commits
-
-
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 <tzimmermann@suse.de> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230428122452.4856-9-tzimmermann@suse.de
-
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 2 commits
-
-
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
-
Jani Nikula authored
Prefer the parsed results for is_hdmi in display info over calling drm_detect_hdmi_monitor(). Remove the now redundant hdmi_monitor member from struct sti_hdmi. Cc: Alain Volmat <alain.volmat@foss.st.com> Signed-off-by:
Alain Volmat <avolmat@me.com> Link: https://patchwork.freedesktop.org/patch/msgid/74fbd7a83712009734534d92e5499d4d87f0c53b.1662036058.git.jani.nikula@intel.com
-
- 28 Apr, 2023 4 commits
-
-
Won Chung authored
Create a symlink pointing to USB Type-C connector for DRM connectors when they are created. The link will be created only if the firmware is able to describe the connection beween the two connectors. Currently, even if a display uses a USB Type-C port, there is no way for the userspace to find which port is used for which display. With the symlink, display information would be accessible from Type-C connectors and port information would be accessible from DRM connectors. Associating the two subsystems, userspace would have potential to expose and utilize more complex information. ChromeOS intend to use this information for metrics collection. For example, we want to tell which port is deriving which displays. Also, combined with USB PD information, we can tell whether user is charging their device through display. Chromium patch for parsing the symlink from the kernel is at http://crrev.com/c/4317207. We already have a framework in typec port-mapper.c where it goes through component devices and runs the bind functions for those with matching _PLD (physical location of device). https://elixir.bootlin.com/linux/v5.18.1/source/drivers/usb/typec/ port-mapper.c Since _PLD is ACPI specific field, this linking would only work on ACPI x86 as long as _PLD field for Type-C connectors and DRM connectors are correctly added to the firmware. Currently, USB ports and USB4 ports are added as components to create a symlink with Type C connector. USB: https://lore.kernel.org/all/20211223082349.45616-1-heikki.krogerus @linux.intel.com/ USB4: https://lore.kernel.org/all/20220418175932.1809770-3-wonchung@google.com/ So, we follow the same pattern in this patch. Signed-off-by:
Won Chung <wonchung@google.com> Acked-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by:
Manasi Navare <navaremanasi@chromium.org> Signed-off-by:
-
Won Chung authored
Expose DRM connector id in device sysfs so that we can map the connector id to the connector syspath. Currently, even if we can derive the connector id from modeset, we do not have a way to find the corresponding connector's syspath. This is helpful when determining the root connector of MST tree. When a tree of multiple MST hub is connected to the system, modeset describes the tree in the PATH blob. For example, consider the following scenario. +-------------+ | Source | +-------------+ | (Device) | | BranchX | | | | (MST) | | [conn6]--->| [port1]--->DisplayA +-------------+ | | | | +-------------+ | | | BranchY | | | | (MST) | | [port2]--->| [port1]----->DisplayB +-------------+ | | | [port2]----->DisplayC +-------------+ DPMST connector of DisplayA would have "mst:6-1" PATH. DPMST connector of DisplayB would have "mst:6-2-1" PATH. DPMST connector of DisplayC would have "mst:6-2-2" PATH. Given that connector id of 6 is the root of the MST connector tree, we can utilize this patch to parse through DRM connectors sysfs and find which connector syspath corresponds to the root connector (id == 6). ChromeOS intend to use this information for metrics collection. For example, we want to tell which port is deriving which displays even with a MST hub. Chromium patch for parsing DRM connector id from the kernel is at http://crrev.com/c/4317207. Signed-off-by: -
Markus Elfring authored
drm/bridge: it6505: Move a variable assignment behind a null pointer check in receive_timing_debugfs_show() The address of a data structure member was determined before a corresponding null pointer check in the implementation of the function “receive_timing_debugfs_show”. Thus avoid the risk for undefined behaviour by moving the assignment for the variable “vid” behind the null pointer check. This issue was detected by using the Coccinelle software. Fixes: b5c84a9e ("drm/bridge: add it6505 driver") Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Link: https://patchwork.freedesktop.org/patch/msgid/fa69384f-1485-142b-c4ee-3df54ac68a89@web.deReviewed-by:
-
Ville Syrjälä authored
Document in which order the CTM matrix elements are stored. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230411222931.15127-2-ville.syrjala@linux.intel.comReviewed-by:
Xaver Hugl <xaver.hugl@gmail.com> Acked-by:
Simon Ser <contact@emersion.fr>
-
- 27 Apr, 2023 4 commits
-
-
Tom Rix authored
smatch has several similar warnings to drivers/gpu/drm/meson/meson_venc.c:189:28: warning: symbol 'meson_hdmi_enci_mode_480i' was not declared. Should it be static? These variables are only used in their defining file so should be static Signed-off-by:
Tom Rix <trix@redhat.com> Acked-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230423145300.3937831-1-trix@redhat.com
-
Chris Morgan authored
The Anbernic RG353V-V2 is a 5 inch panel used in a new revision of the Anbernic RG353V handheld gaming device. Add support for it. Unfortunately it appears this controller is not able to support 120hz or 100hz mode like the first revision panel. Signed-off-by:
Chris Morgan <macromorgan@hotmail.com> Reviewed-by:
Guido Günther <agx@sigxcpu.org> Signed-off-by:
-
Chris Morgan authored
A later revision of the datasheet for the ST7703 refers to this command as "SETECO". Signed-off-by:
-
Chris Morgan authored
The Anbernic RG353V-V2 panel is a 3.5 inch 640x480 MIPI-DSI LCD panel. It's based on the ST7703 LCD controller just like rocktech,jh057n00900. It's used in a 2nd revision of the Anbernic RG353V handheld gaming device. Like the first revision of the RG353V the control chip is known but the panel itself is unknown, so name it for the device. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by:
-
