- 23 May, 2024 1 commit
-
-
Douglas Anderson authored
Back in the day, we used to need to list the exact panel in dts for eDP panels. This led to all sorts of problems including a large number of cases where people listed a bogus panel in their device tree because of the needs of second sourcing (and third sourcing, and fourth sourcing, ...). Back when we needed to add eDP panels to dts files we used to list them in "panel-simple.yaml". These days we have the new way of doing things as documented in "panel-edp.yaml". We can just list the compatible "edp-panel", add some timing info to the source code, and we're good to go. There's not really good reasons not to use this new method. To try to make it obvious that we shouldn't add new compatible strings for eDP panels, let's move them all out of the old "panel-simple.yaml" file to their own file: "panel-edp-legacy.yaml". This new file will have a description that makes it obvious that we shouldn't use it for new panels. While we're doing this: - We can remove eDP-specific properties from panel-simple.yaml since there are no more panels there. - We don't need to copy non-eDP properties to the "panel-edp-legacy.yaml". - We'll fork off a separate yaml file for "samsung,atna33xc20.yaml". This is an eDP panel which isn't _quite_ handled by the generic "edp-panel" compatible since it's not allowed to have an external backlight (it has one builtin) and it absolutely requires an "enable" GPIO. - We'll un-fork the "sharp,ld-d5116z01b.yaml" and put it in "panel-edp-legacy.yaml" since there doesn't appear to be any reason for it to be separate. Suggested-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Rob Herring (Arm) <robh@kernel.org> Link: https://lore.kernel.org/r/20240520153813.1.Iefaa5b93ca2faada269af77deecdd139261da7ec@changeidSigned-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240520153813.1.Iefaa5b93ca2faada269af77deecdd139261da7ec@changeid
-
- 22 May, 2024 2 commits
-
-
Haikun Zhou authored
Add support for the CMN N116BCJ-EAK, place the raw EDID here for subsequent reference. 00 ff ff ff ff ff ff 00 0d ae 60 11 00 00 00 00 04 22 01 04 95 1a 0e 78 02 67 75 98 59 53 90 27 1c 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 da 1d 56 e2 50 00 20 30 30 20 a6 00 00 90 10 00 00 18 00 00 00 fe 00 4e 31 31 36 42 43 4a 2d 45 41 4b 0a 20 00 00 00 fe 00 43 4d 4e 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe 00 4e 31 31 36 42 43 4a 2d 45 41 4b 0a 20 00 98 Signed-off-by:
Haikun Zhou <zhouhaikun5@huaqin.corp-partner.google.com> Reviewed-by:
-
Kuro Chung authored
When the system power resumes, the TTL input of IT6505 may experience some noise before the video signal stabilizes, necessitating a video reset. This patch is implemented to prevent a loop of video error interrupts, which can occur when a video reset in the video FIFO error interrupt triggers another such interrupt. The patch processes the SCDT and FIFO error interrupts simultaneously and ignores any video FIFO error interrupts caused by a video reset. Fixes: b5c84a9e ("drm/bridge: add it6505 driver") Signed-off-by:
Kuro Chung <kuro.chung@ite.com.tw> Signed-off-by:
Hermes Wu <hermes.wu@ite.com.tw> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240522065528.1053439-1-kuro.chung@ite.com.tw
-
- 21 May, 2024 13 commits
-
-
Ville Syrjälä authored
Make life easier for drivers by filtering out unwanted YCbCr 4:2:0 only modes prior to calling the connector->mode_valid() hook. Currently drivers will still see YCbCr 4:2:0 only modes in said hook, which will likely come as a suprise when the driver has declared no support for such modes (via setting connector->ycbcr_420_allowed to false). Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10992Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240516173324.18149-1-ville.syrjala@linux.intel.comReviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Wayne Lin authored
[Why] Commit: - commit 5aa1dfcd ("drm/mst: Refactor the flow for payload allocation/removement") accidently overwrite the commit - commit 54d21740 ("drm: use mgr->dev in drm_dbg_kms in drm_dp_add_payload_part2") which cause regression. [How] Recover the original NULL fix and remove the unnecessary input parameter 'state' for drm_dp_add_payload_part2(). Fixes: 5aa1dfcd ("drm/mst: Refactor the flow for payload allocation/removement") Reported-by:
Leon Weiß <leon.weiss@ruhr-uni-bochum.de> Link: https://lore.kernel.org/r/38c253ea42072cc825dc969ac4e6b9b600371cc8.camel@ruhr-uni-bochum.de/ Cc: lyude@redhat.com Cc: imre.deak@intel.com Cc: stable@vger.kernel.org Cc: regressions@lists.linux.dev Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Acked-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Wayne Lin <Wayne.Lin@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240307062957.2323620-1-Wayne.Lin@amd.com
-
Marek Vasut authored
TC9595 datasheet Video Path0 Control (VPCTRL0) Register bit FRMSYNC description says "This bit should be disabled only in video mode transmission where Host transmits video timing together with video data and where pixel clock source is from DSI clock." . This driver always sources pixel clock from external xtal, therefore the FRMSYNC bit must always be enabled, enable it. This fixes an actual issue with DSI-to-DPI mode, where the display would randomly show subtle pixel flickering, or wobble, or shimmering. This is visible on solid gray color, but the degree of the shimmering differs between boots, which makes it hard to debug. There is a caveat to the FRMSYNC and this bridge pixel PLL, which can only generate pixel clock with limited accuracy, it may therefore be necessary to reduce the HFP to fit into line length of input pixel data, to avoid any possible overflows, which make the output video look striped horizontally. Signed-off-by:
Marek Vasut <marex@denx.de> Reviewed-by:
-
Douglas Anderson authored
Take advantage of some of the new wrapped routines introduced by commit f79d6d28 ("drm/mipi-dsi: wrap more functions for streamline handling") to simplify the himax-hx83102 driver a bit more. This gets rid of some extra error prints (since the _multi functions all print errors for you) and simplifies the code a bit. One thing here that isn't just refactoring is that in a few places we now check with errors with "if (err)" instead of "if (err < 0)". All errors are expected to be negative so this is not expected to have any impact. The _multi code internally considers anything non-zero to be an error so this just makes things consistent. It can also be noted that hx83102_prepare() has a mix of things that can take advantage of _multi calls and things that can't. The cleanest seemed to be to use the multi_ctx still but consistently use the "accum_err" variable for error returns, though that's definitely a style decision with pros and cons. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240517143643.8.If761d37b5d511867ac8207fe8220ae48d444a04f@changeidSigned-off-by:
-
Douglas Anderson authored
The mipi_dsi_dcs_nop() function returns an error but we weren't checking it in hx83102_prepare(). Add a check. This is highly unlikely to matter in practice. If the NOP failed then likely later MIPI commands would fail too. Found by code inspection. Fixes: 0ef94554 ("drm/panel: himax-hx83102: Break out as separate driver") Signed-off-by:
-
Douglas Anderson authored
The enable GPIO should clearly be set low before turning off regulators. That matches both the inverse order that things were enabled and also the order in unprepare(). Fixes: 0ef94554 ("drm/panel: himax-hx83102: Break out as separate driver") Signed-off-by:
-
Douglas Anderson authored
The mipi_dsi_dcs_nop() function returns an error but we weren't checking it in ili9882t_prepare(). Add a check. This is highly unlikely to matter in practice. If the NOP failed then likely later MIPI commands would fail too. Found by code inspection. Fixes: e2450d32 ("drm/panel: ili9882t: Break out as separate driver") Signed-off-by:
-
Douglas Anderson authored
The enable GPIO should clearly be set low before turning off regulators. That matches both the inverse order that things were enabled and also the order in unprepare(). Fixes: e2450d32 ("drm/panel: ili9882t: Break out as separate driver") Signed-off-by:
-
Douglas Anderson authored
The mipi_dsi_dcs_nop() function returns an error but we weren't checking it in boe_panel_prepare(). Add a check. This is highly unlikely to matter in practice. If the NOP failed then likely later MIPI commands would fail too. Found by code inspection. Fixes: 812562b8 ("drm/panel: boe-tv101wum-nl6: Fine tune the panel power sequence") Signed-off-by:
-
Douglas Anderson authored
The enable GPIO should clearly be set low before turning off regulators. That matches both the inverse order that things were enabled and also the order in unprepare(). Fixes: a869b9db ("drm/panel: support for boe tv101wum-nl6 wuxga dsi video mode panel") Signed-off-by:
-
Douglas Anderson authored
If mipi_dsi_dcs_set_display_on() returned an error then we'd store that in the "ret" variable and jump to error handling. We'd then attempt an orderly poweroff. Unfortunately we then blew away the value stored in "ret". That means that if the orderly poweroff actually worked then we're return 0 (no error) from hx8394_enable() even though the panel wasn't enabled. Fix this by not blowing away "ret". Found by code inspection. Fixes: 65dc9360 ("drm: panel: Add Himax HX8394 panel controller driver") Signed-off-by:
-
Jocelyn Falempe authored
Unfortunately, the G200 ioburst workaround doesn't work on some servers like Dell poweredge XR11, XR5610, or HPE XL260. In this case completely disabling WC is the only option to achieve low-latency. So this adds a new Kconfig option to disable WC mapping of the G200. Signed-off-by:
Jocelyn Falempe <jfalempe@redhat.com> Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240517151050.624797-3-jfalempe@redhat.com
-
Jocelyn Falempe authored
This reverts commit bfa4437f. This workaround doesn't work reliably on all servers. I'll replace it with an option to disable Write-Combine, which has more impact on performance, but fix the latency issue on all hardware. Signed-off-by:
-
- 20 May, 2024 6 commits
-
-
Maíra Canal authored
The Performance Counters enum used to identify the index of each performance counter and provide the total number of performance counters (V3D_PERFCNT_NUM). But, this enum is only valid for V3D 4.2, not for V3D 7.1. As we implemented a new flexible structure to retrieve performance counters information, we can deprecate this enum. Signed-off-by:
Maíra Canal <mcanal@igalia.com> Reviewed-by:
Iago Toral Quiroga <itoral@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240512222655.2792754-7-mcanal@igalia.com
-
Maíra Canal authored
V3D_PERFCNT_NUM represents the maximum number of performance counters for V3D 4.2, but not for V3D 7.1. This means that, if we use V3D_PERFCNT_NUM, we might go out-of-bounds on V3D 7.1. Therefore, use the number of performance counters on V3D 7.1 as the maximum number of counters. This will allow us to create arrays on the stack with reasonable size. Note that userspace must use the value provided by DRM_V3D_PARAM_MAX_PERF_COUNTERS. Signed-off-by:
-
Maíra Canal authored
Userspace usually needs some information about the performance counters available. Although we could replicate this information in the kernel and user-space, let's use the kernel as the "single source of truth" to avoid issues in the future (e.g. list of performance counters is updated in user-space, but not in the kernel, generating invalid requests). Therefore, create a new IOCTL to expose the performance counters information, that is name, category, and description. Signed-off-by:
-
Maíra Canal authored
The maximum number of performance counters can change from version to version and it's important for userspace to know this value, as it needs to use the counters for performance queries. Therefore, expose the maximum number of performance counters to userspace as a parameter. Signed-off-by:
-
Maíra Canal authored
Currently, even though V3D 7.1 has 93 performance counters, it is not possible to create counters bigger than 87, as `v3d_perfmon_create_ioctl()` understands that counters bigger than 87 are invalid. Therefore, create a device variable to expose the maximum number of counters for a given V3D version and make `v3d_perfmon_create_ioctl()` check this variable. This commit fixes CTS failures in the performance queries tests `dEQP-VK.query_pool.performance_query.*` [1] Link: https://gitlab.freedesktop.org/mesa/mesa/-/commit/ea1f09a5f21839f4f3b93610b58507c4bd9b9b81 [1] Fixes: 6fd94871 ("drm/v3d: add brcm,2712-v3d as a compatible V3D device") Signed-off-by:
-
Maíra Canal authored
Add name, category and description for each one of the 93 performance counters available on V3D. Note that V3D 4.2 has 87 performance counters, while V3D 7.1 has 93. Therefore, there are two performance counters arrays. The index of the performance counter for each V3D version is represented by its position on the array. Signed-off-by:
-
- 17 May, 2024 18 commits
-
-
Dmitry Baryshkov authored
Use newer mipi_dsi_*_multi() functions in order to simplify and cleanup panel's prepare() and unprepare() functions. Reviewed-by:
-
Dmitry Baryshkov authored
Remove conditional code and always use mipi_dsi_dcs_*multi() wrappers to simplify driver's init/exit code. This also includes passing context to the init_sequence() function instead of passing the DSI device. Reviewed-by:
-
Dmitry Baryshkov authored
Remove conditional code and use mipi_dsi_dcs_nop_multi() wrapper to simplify driver code. Reviewed-by:
-
Dmitry Baryshkov authored
Remove conditional code and always use mipi_dsi_dcs_*multi() wrappers to simplify driver's init/exit code. Reviewed-by:
-
Dmitry Baryshkov authored
Remove conditional code and always use mipi_dsi_dcs_*multi() wrappers to simplify driver's init/exit code. Reviewed-by:
-
Dmitry Baryshkov authored
Follow the pattern of mipi_dsi_dcs_*_multi() and wrap several existing MIPI DSI functions to use the context for processing. This simplifies and streamlines driver code to use simpler code pattern. Note, msleep function is also wrapped in this way as it is frequently called inbetween other mipi_dsi_dcs_*() functions. Signed-off-by:
-
Dmitry Baryshkov authored
Add missing error handling for the mipi_dsi_ functions that actually return error code instead of silently ignoring it. Fixes: 069a6c0e ("drm: panel: Add LG sw43408 panel driver") Reviewed-by:
-
Thomas Zimmermann authored
Mgag200's .get_modes() function is identical to the common helper. Use the latter. Signed-off-by:
-
Thomas Zimmermann authored
The modeset lock protects the DDC code from concurrent modeset operations, which use the same registers. Move that code from the connector helpers into the DDC helpers .pre_xfer() and .post_xfer(). Both, .pre_xfer() and .post_xfer(), enclose the transfer of data blocks over the I2C channel in the internal I2C function bit_xfer(). Both calls are executed unconditionally if present. Invoking DDC transfers from any where within the driver now takes the lock. Signed-off-by:
-
Thomas Zimmermann authored
Align the names of the algo-bit helpers with mgag200's convention of using an mgag200 prefix plus the struct's name plus the callback's name for such function symbols. Signed-off-by:
-
Thomas Zimmermann authored
Rename the source file according to its content. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Rename struct mga_i2c_chan to struct mgag200_ddc, define it in the source file mgag200_i2c.c, and reorder its fields. Rename all related variables from i2c to ddc. Also rename the i2c adapter accordingly. Using the term 'ddc' documents the purpose of the code clearly. The old term 'i2c' could refer to any functionality on an i2c bus. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
The function mgag200_i2c_init() is an internal helper that sets up the i2c data structure. Inline its code into the only caller. Rearrange the individual steps to separate among i2c algorithm, adapter and fields in struct mga_i2c_chan. Signed-off-by:
-
Thomas Zimmermann authored
Allocate instances of struct mga_i2c_chan in mgag200_ddc_create() and return a pointer to the contained i2c adapter. The callers of the function are now independent from struct mga_i2c_chan. Signed-off-by:
-
Thomas Zimmermann authored
Avoid upcasting to struct mga_device in i2c code by storing the pointer directly. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Managed cleanup with devm_add_action_or_reset() will release the I2C adapter when the underlying Linux device goes away. But the connector still refers to it, so this cleanup leaves behind a stale pointer in struct drm_connector.ddc. Bind the lifetime of the I2C adapter to the connector's lifetime by using DRM's managed release. When the DRM device goes away (after the Linux device) DRM will first clean up the connector and then clean up the I2C adapter. Signed-off-by:
-
Thomas Zimmermann authored
Compute the i2c timeout in jiffies from a value in milliseconds. The original values of 2 jiffies equals 2 milliseconds if HZ has been configured to a value of 1000. This corresponds to 2.2 milliseconds used by most other DRM drivers. Update mgag200 accordingly. Signed-off-by:
-
Cong Yang authored
The IVO t109nw41 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller which fits in nicely with the existing panel-himax-hx83102 driver. Hence, we add a new compatible with panel specific config. Signed-off-by:
Cong Yang <yangcong5@huaqin.corp-partner.google.com> Reviewed-by:
-
