- 07 Apr, 2023 28 commits
-
-
Dmitry Baryshkov authored
For sm8150+ the DPU_CTL_SPLIT_DISPLAY should be replaced with DPU_CTL_ACTIVE_CFG support (which supports having a single CTL for both interfaces in a split). Add comments where this conversion is required. Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/530871/ Link: https://lore.kernel.org/r/20230404130622.509628-31-dmitry.baryshkov@linaro.orgSigned-off-by:
-
Dmitry Baryshkov authored
Use defined name DEFAULT_DPU_OUTPUT_LINE_WIDTH instead of open coding the value. Reviewed-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
-
Dmitry Baryshkov authored
Duplicate sm8450 catalog entries to sm8550 to remove dependencies between DPU instances. Signed-off-by:
-
Dmitry Baryshkov authored
Duplicate qcm2290 catalog entries to sm6115 to remove dependencies between DPU instances. Signed-off-by:
-
Dmitry Baryshkov authored
Duplicate sm8250 catalog entries to sc7180 to remove dependencies between DPU instances. Signed-off-by:
-
Dmitry Baryshkov authored
Duplicate sm8150 catalog entries to sc8180x to remove dependencies between DPU instances. Signed-off-by:
-
Dmitry Baryshkov authored
Duplicate some of sm8350 catalog entries to remove dependencies between DPU major generations. Reviewed-by:
-
Dmitry Baryshkov authored
Duplicate some of sm8250 catalog entries to remove dependencies between DPU major generations. Reviewed-by:
-
Dmitry Baryshkov authored
Duplicate some of sm8150 catalog entries to remove dependencies between DPU major generations. Reviewed-by:
-
Dmitry Baryshkov authored
Duplicate some of sc7180 catalog entries to remove dependencies between DPU major generations. Reviewed-by:
-
Dmitry Baryshkov authored
Duplicate some of sdm845 catalog entries to remove dependencies between DPU major generations. 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
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:
-
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 12 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:
-
