- 22 Apr, 2024 21 commits
-
-
Dmitry Baryshkov authored
Import the gen_headers.py script from Mesa, commit b5414e716684 ("freedreno/registers: Add license header"). This script will be used to generate MSM register files on the fly during compilation. Signed-off-by:Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/585864/ Link: https://lore.kernel.org/r/20240401-fd-xml-shipped-v5-10-4bdb277a85a1@linaro.org
-
Dmitry Baryshkov authored
Import Adreno registers database for A6xx from the Mesa, commit 639488f924d9 ("freedreno/registers: limit the rules schema"). Signed-off-by: -
Dmitry Baryshkov authored
Import Adreno registers database for A5xx from the Mesa, commit 639488f924d9 ("freedreno/registers: limit the rules schema"). Signed-off-by: -
Dmitry Baryshkov authored
Import Adreno registers database for A2xx-A4xx from the Mesa, commit 639488f924d9 ("freedreno/registers: limit the rules schema"). Signed-off-by: -
Dmitry Baryshkov authored
Import display-related registers database from the Mesa, commit 639488f924d9 ("freedreno/registers: limit the rules schema"). The msm.xml and mdp_common.xml files were adjusted to drop subdirectory paths. Signed-off-by: -
Dmitry Baryshkov authored
Two core driver files include headers from Adreno subdir, which also brings dependency on the Adreno register headers. Rework those includes to remove unnecessary dependency. Signed-off-by:
-
Dmitry Baryshkov authored
The msm_gpummu.c implementation is used only on A2xx and it is tied to the A2xx registers. Rename the source file accordingly. Reviewed-by:
Akhil P Oommen <quic_akhilpo@quicinc.com> Signed-off-by:
-
Dmitry Baryshkov authored
The mmss_cc.xml.h file describes bits of the MMSS clock controller on APQ8064 / MSM8960 platforms. They are not used by the driver and do not belong to the DRM MSM driver. Drop the file. Reviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by:
-
Dmitry Baryshkov authored
The qfprom.xml.h contains definitions for the nvmem code. They are not used in the existing code. Also if we were to use them later, we should have used nvmem cell API instead of using these defs. Drop the file. Reviewed-by:
-
Dmitry Baryshkov authored
In order to stop patching the mdp5 headers, import definitions for the writeback blocks. This part is extracted from the old Rob's patch. Co-developed-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
-
Bjorn Andersson authored
The dp_audio read and write operations uses members in struct dp_catalog for passing arguments and return values. This adds unnecessary complexity to the implementation, as it turns out after detangling the logic that no state is actually held in these variables. Clean this up by using function arguments and return values for passing the data. Reviewed-by:
Bjorn Andersson <quic_bjorande@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/585350/ Link: https://lore.kernel.org/r/20240328-msm-dp-cleanup-v2-6-a5aed9798d32@quicinc.comSigned-off-by:
-
Bjorn Andersson authored
dp_catalog_panel_timing_cfg() takes 4 arguments, which are passed from the calling function through members of struct dp_catalog. No state is maintained other than across this call, so switch to function arguments to clean up the code. Reviewed-by:
-
Bjorn Andersson authored
The dp_aux write operations takes the data to be operated on through a member of struct dp_catalog, rather than as an argument to the function. No state is maintained other than across the calling of the functions, so replace this member with a function argument. Reviewed-by:
-
Bjorn Andersson authored
Throughout the Qualcomm Displayport driver a number of defines and struct members has become unused, but lingers in the code. Remove these. Reviewed-by:
-
Bjorn Andersson authored
The "desc" member of struct dp_panel is zero-initialized during allocation and never assigned, resulting in dp_ctrl_use_fixed_nvid() never returning true. This returned boolean value is passed around but never acted upon. Perform constant propagation and remove the traces of "fixed nvid". Reviewed-by:
-
Bjorn Andersson authored
The members of struct dp_debug are no longer used, so the only purpose of this struct is as a type of the return value of dp_debug_get(), to signal success/error. Drop the struct in favor of signalling the result of initialization using an int, then merge dp_debug_get() with dp_debug_init() to avoid the unnecessar boilerplate code. Signed-off-by:
-
Andy Shevchenko authored
of_gpio.h is deprecated and subject to remove. The driver doesn't use it directly, replace it with what is really being used. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Logging u32 pixel formats using %4.4s format string with a pointer to the u32 is somewhat questionable, as well as dependent on byte order. There's a kernel extension format specifier %p4cc to format 4cc codes. Use it across the board in msm for pixel format logging. This should also fix the reported build warning: include/drm/drm_print.h:536:35: warning: '%4.4s' directive argument is null [-Wformat-overflow=] Reported-by:
Aishwarya TCV <aishwarya.tcv@arm.com> Closes: https://lore.kernel.org/r/2ac758ce-a196-4e89-a397-488ba31014c4@arm.comSigned-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Luca Weiss authored
Document the displayport controller subnode of the SM6350 MDSS. Signed-off-by:
Luca Weiss <luca.weiss@fairphone.com> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/585468/ Link: https://lore.kernel.org/r/20240329-sm6350-dp-v2-2-e46dceb32ef5@fairphone.comSigned-off-by:
-
Luca Weiss authored
Add the compatible string for the DisplayPort controller on SM6350 which is compatible with the one on SM8350. Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Douglas Anderson authored
Before the introduction of the wait_hpd_asserted() callback in commit 841d742f ("drm/dp: Add wait_hpd_asserted() callback to struct drm_dp_aux") the API between panel drivers and DP AUX bus drivers was that it was up to the AUX bus driver to wait for HPD in the transfer() function. Now wait_hpd_asserted() has been added. The two panel drivers that are DP AUX endpoints use it. See commit 2327b13d ("drm/panel-edp: Take advantage of wait_hpd_asserted() in struct drm_dp_aux") and commit 3b5765df ("drm/panel: atna33xc20: Take advantage of wait_hpd_asserted() in struct drm_dp_aux"). We've implemented wait_hpd_asserted() in the MSM DP driver as of commit e2969ee3 ("drm/msm/dp: move of_dp_aux_populate_bus() to eDP probe()"). There is no longer any reason for long wait in the AUX transfer() function. Remove it. NOTE: the wait_hpd_asserted() is listed as "optional". That means it's optional for the DP AUX bus to implement. In the case of the MSM DP driver we implement it so we can assume it will be called. ALSO NOTE: the wait wasn't actually _hurting_ anything and wasn't even causing long timeouts, but it's still nice to get rid of unneeded code. Specificaly it's not truly needed because to handle other DP drivers that can't power on as quickly (specifically parade-ps8640) we already avoid DP AUX transfers for eDP panels that aren't powered on. See commit 8df1ddb5 ("drm/dp: Don't attempt AUX transfers when eDP panels are not powered"). Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
-
- 08 Apr, 2024 8 commits
-
-
Douglas Anderson authored
The DP wait_hpd_asserted() callback is passed a timeout which indicates how long we should wait for HPD. This timeout was being ignored in the MSM DP implementation and instead a hardcoded 500 ms timeout was used. Fix it to use the proper timeout. As part of this we move the hardcoded 500 ms number into the AUX transfer function, which isn't given a timeout. The wait in the AUX transfer function will be removed in a future commit. Fixes: e2969ee3 ("drm/msm/dp: move of_dp_aux_populate_bus() to eDP probe()") Signed-off-by:
-
Douglas Anderson authored
As documented in the description of the transfer() function of "struct drm_dp_aux", the transfer() function can be called at any time regardless of the state of the DP port. Specifically if the kernel has the DP AUX character device enabled and userspace accesses "/dev/drm_dp_auxN" directly then the AUX transfer function will be called regardless of whether a DP device is connected. For eDP panels we have a special rule where we wait (with a 5 second timeout) for HPD to go high. This rule was important before all panels drivers were converted to call wait_hpd_asserted() and actually can be removed in a future commit. For external DP devices we never checked for HPD. That means that trying to access the DP AUX character device (AKA `hexdump -C /dev/drm_dp_auxN`) would very, very slowly timeout. Specifically on my system: $ time hexdump -C /dev/drm_dp_aux0 hexdump: /dev/drm_dp_aux0: Connection timed out real 0m8.200s We want access to the drm_dp_auxN character device to fail faster than 8 seconds when no DP cable is plugged in. Let's add a test to make transfers fail right away if a device isn't plugged in. Rather than testing the HPD line directly, we have the dp_display module tell us when AUX transfers should be enabled so we can handle cases where HPD is signaled out of band like with Type C. Fixes: c943b494 ("drm/msm/dp: add displayPort driver support") Signed-off-by:
Guenter Roeck <groeck@chromium.org> Reviewed-by:
-
Dmitry Baryshkov authored
Provide atomic_print_state callback to the DPU's private object. This way the debugfs/dri/0/state will also include RM's internal state. Example output (RB5 board, HDMI and writeback encoder enabled) resource mapping: pingpong=31 36 # # # # - - - - - mixer=31 36 # # # # - ctl=# # 31 36 # # dspp=# # # # dsc=# # # # - - cdm=# Signed-off-by:
-
Dmitry Baryshkov authored
Both dp_link_adjust_levels() and dp_ctrl_update_vx_px() limit swing and pre-emphasis to 2, while the real maximum value for the sum of the voltage swing and pre-emphasis is 3. Fix the DP code to remove this limitation. Fixes: c943b494 ("drm/msm/dp: add displayPort driver support") Signed-off-by:
Kuogee Hsieh <quic_khsieh@quicinc.com> Tested-by:
-
Bjorn Andersson authored
Now that the connector_type is dynamically determined, the connector_type of the struct msm_dp_desc is unused. Clean it up. Remaining duplicate entries are squashed. Signed-off-by:
Abel Vesa <abel.vesa@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/588020/ Link: https://lore.kernel.org/r/20240405-dp-connector-type-cleanup-v2-1-0f47d5462ab9@quicinc.comSigned-off-by:
-
Abel Vesa authored
Add the X1E80100 DP descs and compatible. This platform will be using a single compatible for both eDP and DP mode. The actual mode will be set based on the presence of the panel node in DT. Reviewed-by:
-
Abel Vesa authored
Instead of relying on different compatibles for eDP and DP, lookup the panel node in devicetree to figure out the connector type and then pass on that information to the PHY. External DP doesn't have a panel described in DT, therefore, assume it's eDP if panel node is present. Signed-off-by:
-
Dmitry Baryshkov authored
Merge DisplayPort subnode API in order to allow DisplayPort driver to configure the PHYs either to the DP or eDP mode, depending on hardware configuration. Signed-off-by:
-
- 05 Apr, 2024 2 commits
-
-
Luca Weiss authored
The default highest_bank_bit of 15 didn't seem to cause issues so far but downstream defines it to be 14. But similar to [0] leaving it on 14 (or 15 for that matter) causes some corruption issues with some resolutions with DisplayPort, like 1920x1200. So set it to 13 for now so that there's no screen corruption. [0] commit 6a0dbcd2 ("drm/msm/a6xx: set highest_bank_bit to 13 for a610") Fixes: b7616b5c ("drm/msm/adreno: Add A619 support") Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Miguel Ojeda authored
Clang 14 in an (essentially) defconfig arm64 build for next-20240326 reports [1]: drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:843:6: error: variable 'out' set but not used [-Werror,-Wunused-but-set-variable] The variable `out` in these functions is meant to compute the `target` of `CRASHDUMP_READ()`, but in this case only the initial value (`dumper->iova + A6XX_CD_DATA_OFFSET`) was being passed. Thus use `out` as it was intended by Connor [2]. There was an alternative patch at [3] that removed the variable altogether, but that would only use the initial value. Fixes: 64d62556 ("drm/msm: More fully implement devcoredump for a7xx") Closes: https://lore.kernel.org/lkml/CANiq72mjc5t4n25SQvYSrOEhxxpXYPZ4pPzneSJHEnc3qApu2Q@mail.gmail.com/ [1] Link: https://lore.kernel.org/lkml/CACu1E7HhCKMJd6fixZSPiNAz6ekoZnkMTHTcLFVmbZ-9VoLxKg@mail.gmail.com/ [2] Link: https://lore.kernel.org/lkml/20240307093727.1978126-1-colin.i.king@gmail.com/ [3] Signed-off-by:Miguel Ojeda <ojeda@kernel.org> Reviewed-by:
-
- 02 Apr, 2024 2 commits
-
-
Dmitry Baryshkov authored
As Qualcomm SM8150 got support for the DisplayPort, add displayport@ node as a valid child to the MDSS node. Fixes: 88806318 ("dt-bindings: display: msm: dp: declare compatible string for sm8150") Reviewed-by:
-
Abhinav Kumar authored
Fix the typo in the name of dp_display_handle_port_status_changed(). Fixes: c58eb1b5 ("drm/msm/dp: fix connect/disconnect handled at irq_hpd") Signed-off-by:
-
- 01 Apr, 2024 1 commit
-
-
Dmitry Baryshkov authored
There is little point in using %ps to print a value known to be NULL. On the other hand it makes sense to print the callback symbol in the 'invalid IRQ' message. Correct those two error messages to make more sense. Fixes: 68931991 ("drm/msm/dpu: stop using raw IRQ indices in the kernel output") Signed-off-by:
Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by:
-
- 29 Mar, 2024 5 commits
-
-
Kuogee Hsieh authored
At current x1e80100 interface table, interface #3 is wrongly connected to DP controller #0 and interface #4 wrongly connected to DP controller #2. Fix this problem by connect Interface #3 to DP controller #0 and interface #4 connect to DP controller #1. Also add interface #6, #7 and #8 connections to DP controller to complete x1e80100 interface table. Changs in V3: -- add v2 changes log Changs in V2: -- add x1e80100 to subject -- add Fixes Fixes: e3b1f369 ("drm/msm/dpu: Add X1E80100 support") Signed-off-by:
-
Dmitry Baryshkov authored
The data from catalog is marked as const, so it is a part of the RO segment. Allowing userspace to write to it through debugfs can cause protection faults. Set debugfs file mode to read-only for debug entries corresponding to perf_cfg coming from catalog. Fixes: abda0d92 ("drm/msm/dpu: Mark various data tables as const") Signed-off-by:
-
Stephen Boyd authored
These debug prints are missing newlines, leading to multiple messages being printed on one line and hard to read logs. Add newlines to have the debug prints on separate lines. The DBG macro used to add a newline, but I missed that while migrating to drm_dbg wrappers. Fixes: 7cb017db ("drm/msm: Move FB debug prints to drm_dbg_state()") Fixes: 721c6e0c ("drm/msm: Move vblank debug prints to drm_dbg_vbl()") Signed-off-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
-
Johan Hovold authored
Make sure to balance the runtime PM usage counter (and suspend) before returning on connect failures (e.g. DPCD read failures after a spurious connect event or if link training fails). Fixes: 5814b8bf ("drm/msm/dp: incorporate pm_runtime framework into DP driver") Cc: stable@vger.kernel.org # 6.8 Cc: Kuogee Hsieh <quic_khsieh@quicinc.com> Signed-off-by:
Johan Hovold <johan+linaro@kernel.org> Reviewed-by:
-
Johan Hovold authored
Make sure to put the runtime PM usage count (and suspend) also when receiving a disconnect event while in the ST_MAINLINK_READY state. This specifically avoids leaking a runtime PM usage count on every disconnect with display servers that do not automatically enable external displays when receiving a hotplug notification. Fixes: 5814b8bf ("drm/msm/dp: incorporate pm_runtime framework into DP driver") Cc: stable@vger.kernel.org # 6.8 Cc: Kuogee Hsieh <quic_khsieh@quicinc.com> Signed-off-by:
-
- 28 Mar, 2024 1 commit
-
-
Abel Vesa authored
Future platforms should not use different compatibles to differentiate between eDP and DP mode. Instead, they should use a single compatible as the IP block is the same. It will be the job of the controller to set the submode of the PHY accordingly. The existing platforms will remain with separate compatibles for each mode. Signed-off-by:
Vinod Koul <vkoul@kernel.org>
-
