- 07 Apr, 2023 15 commits
-
-
Dmitry Baryshkov authored
Reviewed-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/530844/ Link: https://lore.kernel.org/r/20230404130622.509628-18-dmitry.baryshkov@linaro.orgSigned-off-by:
-
Dmitry Baryshkov authored
Reviewed-by:
-
Dmitry Baryshkov authored
Reviewed-by:
-
Dmitry Baryshkov authored
Reviewed-by:
-
Dmitry Baryshkov authored
Reviewed-by:
-
Dmitry Baryshkov authored
Reviewed-by:
-
Dmitry Baryshkov authored
Reviewed-by:
-
Dmitry Baryshkov authored
Reviewed-by:
-
Dmitry Baryshkov authored
Reviewed-by:
-
Dmitry Baryshkov authored
Reviewed-by:
-
Dmitry Baryshkov authored
UBWC and highest bank settings differ slightly between different DPU units of the same generation, while the dpu_caps and dpu_mdp_cfg are much more stable. To ease configuration reuse move ubwc_swizzle and highest_bank_bit data to separate structure. Reviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by:
-
Dmitry Baryshkov authored
Fix several leftover _pp strutures and mark them as const, making all hw catalog fit into the rodata section. Reviewed-by:
-
Dmitry Baryshkov authored
DSC hw catalog data is not supposed to be changed, so mark it as const data. Reviewed-by:
-
Konrad Dybcio authored
These blocks are of variable length on different SoCs. Set the correct values where I was able to retrieve it from downstream DTs and leave the old defaults (0x280) otherwise. Signed-off-by:
-
Konrad Dybcio authored
These blocks are of variable length on different SoCs. Set the correct values where I was able to retrieve it from downstream DTs and leave the old defaults (0x1c8) otherwise. Signed-off-by:
-
- 06 Apr, 2023 25 commits
-
-
Dmitry Baryshkov authored
Merge branches 'msm-next-lumag-dp', 'msm-next-lumag-dsi', 'msm-next-lumag-mdp5' and 'msm-next-lumag-mdp4' into msm-next-lumag Core: - Bugfixes for error handling during probe - rework UBWC decoder programming - prepare_commit cleanup - bindings for SM8550 (MDSS, DPU), SM8450 (DP) - uapi C++ compatibility fix - timeout calculation fixup - msm_fbdev conversion to drm_client DP: - interrupts cleanup DPU: - DSPP sub-block flush on sc7280 - support AR30 in addition to XR30 format - Allow using REC_0 and REC_1 to handle wide (4k) RGB planes DSI: - rework DSI instance ID detection on obscure platforms and misc small fixes as usual. Signed-off-by: -
Dmitry Baryshkov authored
Merge DPU changes, resolving conflicts between branches. Full changelog will be present in the final merge commit. DPU: - DSPP sub-block flush on sc7280 - support AR30 in addition to XR30 format - Allow using REC_0 and REC_1 to handle wide (4k) RGB planes Signed-off-by: -
Jessica Zhang authored
Remove empty prepare_commit() function from MDP4 driver. Signed-off-by:
Jessica Zhang <quic_jesszhan@quicinc.com> Reviewed-by:
Marijn Suijten <marijn.suijten@somainline.org> Patchwork: https://patchwork.freedesktop.org/patch/523608/ Link: https://lore.kernel.org/r/20230221184256.1436-5-quic_jesszhan@quicinc.comSigned-off-by:
-
Konrad Dybcio authored
Add a compatible for the DSI on SM6115. Acked-by:
Rob Herring <robh@kernel.org> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/527664/ Link: https://lore.kernel.org/r/20230307-topic-dsi_qcm-v6-8-70e13b1214fa@linaro.orgSigned-off-by:
-
Tom Rix authored
smatch reports drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c:658:26: warning: symbol 'msm8x76_config' was not declared. Should it be static? This variable is only used in one file so should be static. Signed-off-by:
Tom Rix <trix@redhat.com> Reviewed-by:
-
Konrad Dybcio authored
Now that the only user is handled by common code, remove the option to specify custom handlers through match data. This is effectively a revert of commit: 5ae15e76271 ("drm/msm/dsi: Allow to specify dsi config as pdata") Reviewed-by: -
Konrad Dybcio authored
Now that the logic can handle multiple sets of registers, move the QCM2290 to the common logic and mark it deprecated. This allows us to remove a couple of structs, saving some memory. Reviewed-by:
-
Colin Ian King authored
There is a spelling mistake in a drm_dbg_dp message. Fix it. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Reviewed-by:
-
Konrad Dybcio authored
The configs are identical, other than the number of *maximum* DSI hosts allowed. This isn't an issue, unless somebody deliberately tries to access the inexistent host by adding a dt node for it. Remove the SC7180 struct and point the hw revision match to the SDM845's one. On a note, this could have been done back when 7180 support was introduced. Reviewed-by:
-
Neil Armstrong authored
The SM8450 & SM350 shares the same DT TX IP version, use the SM8350 compatible as fallback for SM8450. Reviewed-by:
Neil Armstrong <neil.armstrong@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/527564/ Link: https://lore.kernel.org/r/20230206-topic-sm8450-upstream-dp-controller-v6-1-d78313cbc41d@linaro.orgSigned-off-by:
-
Konrad Dybcio authored
Some structs were defined multiple times for no apparent reason. Deduplicate them. Reviewed-by:
-
Douglas Anderson authored
If our interrupt handler gets called and we don't really handle the interrupt then we should return IRQ_NONE. The current interrupt handler didn't do this, so let's fix it. NOTE: for some of the cases it's clear that we should return IRQ_NONE and some cases it's clear that we should return IRQ_HANDLED. However, there are a few that fall somewhere in between. Specifically, the documentation for when to return IRQ_NONE vs. IRQ_HANDLED is probably best spelled out in the commit message of commit d9e4ad5b ("Document that IRQ_NONE should be returned when IRQ not actually handled"). That commit makes it clear that we should return IRQ_HANDLED if we've done something to make the interrupt stop happening. The case where it's unclear is, for instance, in dp_aux_isr() after we've read the interrupt using dp_catalog_aux_get_irq() and confirmed that "isr" is non-zero. The function dp_catalog_aux_get_irq() not only reads the interrupts but it also "ack"s all the interrupts that are returned. For an "unknown" interrupt this has a very good chance of actually stopping the interrupt from happening. That would mean we've identified that it's our device and done something to stop them from happening and should return IRQ_HANDLED. Specifically, it should be noted that most interrupts that need "ack"ing are ones that are one-time events and doing an "ack" is enough to clear them. However, since these interrupts are unknown then, by definition, it's unknown if "ack"ing them is truly enough to clear them. It's possible that we also need to remove the original source of the interrupt. In this case, IRQ_NONE would be a better choice. Given that returning an occasional IRQ_NONE isn't the absolute end of the world, however, let's choose that course of action. The IRQ framework will forgive a few IRQ_NONE returns now and again (and it won't even log them, which is why we have to log them ourselves). This means that if we _do_ end hitting an interrupt where "ack"ing isn't enough the kernel will eventually detect the problem and shut our device down. Signed-off-by:
Douglas Anderson <dianders@chromium.org> Tested-by:
Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by:
-
Konrad Dybcio authored
Currently, we allow for MAX_DSI entries in io_start to facilitate for MAX_DSI number of DSI hosts at different addresses. The configuration is matched against the DSI CTRL hardware revision read back from the component. We need a way to resolve situations where multiple SoCs with different register maps may use the same version of DSI CTRL. In preparation to do so, make msm_dsi_config a 2d array where each entry represents a set of configurations adequate for a given SoC. This is totally fine to do, as the only differentiating factors between same-version-different-SoCs configurations are the number of DSI hosts (1 or 2, at least as of today) and the set of base registers. The regulator setup is the same, because the DSI hardware is the same, regardless of the SoC it was implemented in. In addition to that, update the matching logic such that it will loop over VARIANTS_MAX variants, making sure they are all taken into account. Reviewed-by:
-
Douglas Anderson authored
The DP AUX interrupt handling was a bit of a mess. * There were two functions (one for "native" transfers and one for "i2c" transfers) that were quite similar. It was hard to say how many of the differences between the two functions were on purpose and how many of them were just an accident of how they were coded. * Each function sometimes used "else if" to test for error bits and sometimes didn't and again it was hard to say if this was on purpose or just an accident. * The two functions wouldn't notice whether "unknown" bits were set. For instance, there seems to be a bit "DP_INTR_PLL_UNLOCKED" and if it was set there would be no indication. * The two functions wouldn't notice if more than one error was set. Let's fix this by being more consistent / explicit about what we're doing. By design this could cause different handling for AUX transfers, though I'm not actually aware of any bug fixed as a result of this patch (this patch was created because we simply noticed how odd the old code was by code inspection). Specific notes here: 1. In the old native transfer case if we got "done + wrong address" we'd ignore the "wrong address" (because of the "else if"). Now we won't. 2. In the old native transfer case if we got "done + timeout" we'd ignore the "timeout" (because of the "else if"). Now we won't. 3. In the old native transfer case we'd see "nack_defer" and translate it to the error number for "nack". This differed from the i2c transfer case where "nack_defer" was given the error number for "nack_defer". This 100% can't matter because the only user of this error number treats "nack defer" the same as "nack", so it's clear that the difference between the "native" and "i2c" was pointless here. 4. In the old i2c transfer case if we got "done" plus any error besides "nack" or "defer" then we'd ignore the error. Now we don't. 5. If there is more than one error signaled by the hardware it's possible that we'll report a different one than we used to. I don't know if this matters. If someone is aware of a case this matters we should document it and change the code to make it explicit. 6. One quirk we keep (I don't know if this is important) is that in the i2c transfer case if we see "done + defer" we report that as a "nack". That seemed too intentional in the old code to just drop. After this change we will add extra logging, including: * A warning if we see more than one error bit set. * A warning if we see an unexpected interrupt. * A warning if we get an AUX transfer interrupt when shouldn't. It actually turns out that as a result of this change then at boot we sometimes see an error: [drm:dp_aux_isr] *ERROR* Unexpected DP AUX IRQ 0x01000000 when not busy That means that, during init, we are seeing DP_INTR_PLL_UNLOCKED. For now I'm going to say that leaving this error reported in the logs is OK-ish and hopefully it will encourage someone to track down what's going on at init time. One last note here is that this change renames one of the interrupt bits. The bit named "i2c done" clearly was used for native transfers being done too, so I renamed it to indicate this. Signed-off-by:
-
Konrad Dybcio authored
In preparation for supporting multiple sets of possible base registers, remove the num_dsi variable. We're comparing the io_start array contents with the reg value from the DTS, so it will either match one of the expected values or don't match against a zero (which we get from partial array initialization). Reviewed-by:
-
Konrad Dybcio authored
The point of the previous cleanup was to disallow "qcom,mdss-dsi-ctrl" alone. This however didn't quite work out and the property became undocumented instead of deprecated. Fix that. Additionally, the "qcom," prefix was missed previously. Fix it. Fixes: 0c0f65c6 ("dt-bindings: msm: dsi-controller-main: Add compatible strings for every current SoC") Acked-by:
-
Vinod Polimera authored
Certain flags like dirty_fb will be updated into the plane state during crtc atomic_check. Allow those updates during PSR commit. Reported-by:
Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/all/20230326162723.3lo6pnsfdwzsvbhj@ripper/Signed-off-by:
Vinod Polimera <quic_vpolimer@quicinc.com> Reviewed-by:
-
Vinod Polimera authored
While in virtual terminal mode with PSR enabled, there will be no atomic commits triggered without dirty_fb being set. This will create a notion of no screen update. Allow atomic commit when dirty_fb ioctl is issued, so that it can trigger a PSR exit and shows update on the screen. Reported-by:
-
Kalyan Thota authored
Allow modeset to be triggered during CTM enable/disable. In the modeset callbacks, DPU resources required for the CTM feature are managed appropriately. Signed-off-by:
Kalyan Thota <quic_kalyant@quicinc.com> Reviewed-by:
-
Kalyan Thota authored
Return immediately on failure, this will make dpu reservations part look cleaner. Signed-off-by:
-
Kalyan Thota authored
Add DSPP blocks into the topology for reservation, if there is a CTM request for that composition. Signed-off-by:
-
Geert Uytterhoeven authored
With gcc-5 and CONFIG_UBSAN_SHIFT=y: drivers/gpu/drm/msm/msm_mdss.c: In function 'msm_mdss_enable': drivers/gpu/drm/msm/msm_mdss.c:296:2: error: case label does not reduce to an integer constant case DPU_HW_VER_800: ^ drivers/gpu/drm/msm/msm_mdss.c:299:2: error: case label does not reduce to an integer constant case DPU_HW_VER_810: ^ drivers/gpu/drm/msm/msm_mdss.c:300:2: error: case label does not reduce to an integer constant case DPU_HW_VER_900: ^ This happens because for major revisions 8 or greather, the non-sign bit of the major revision number is shifted into bit 31 of a signed integer, which is undefined behavior. Fix this by casting the major revision number to unsigned int. Fixes: efcd0107 ("drm/msm/dpu: add support for SM8550") Fixes: 4a352c2f ("drm/msm/dpu: Introduce SC8280XP") Fixes: 100d7ef6 ("drm/msm/dpu: add support for SM8450") Signed-off-by:Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Randy Dunlap <rdunlap@infradead.org> Reviewed-by:
Rob Clark <robdclark@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/525152/ Link: https://lore.kernel.org/r/20230306090633.65918-1-geert+renesas@glider.beSigned-off-by:
-
Abhinav Kumar authored
After cleaning up the older multirect support the function dpu_plane_validate_multirect_v2() is unused. Lets remove it. Signed-off-by:
-
Abhinav Kumar authored
Lets print the multirect_index as well in _dpu_crtc_blend_setup_pipe() as it will give the complete information of the sw_pipe as well. Signed-off-by:
-
Dmitry Baryshkov authored
The code doesn't use dpu_caps::smart_dma_rev field. It checks if the corresponding feature is enabled in the SSPP features. Drop the smart_dma_rev field completely. Reviewed-by:
-
