Lets rename the existing wb2_formats array wb2_formats_rgb to indicate
that it has only RGB formats and can be used on any chipset having a WB
block.
Introduce a new wb2_formats_rgb_yuv array to the catalog to
indicate support for YUV formats to writeback in addition to RGB.
Chipsets which have s
To setup and enable CDM block for the writeback pipeline, lets
add the pieces together to set the active bits and the flush
bits for the CDM block.
changes in v2:
- passed the cdm idx to update_pending_flush_cdm()
(have retained the R-b as its a minor change)
Signed-off-by: Abhi
Reserve CDM blocks for writeback if the format of the output fb
is YUV. At the moment, the reservation is done only for writeback
but can easily be extended by relaxing the checks once other
interfaces are ready to output YUV.
changes in v2:
- use needs_cdm from topology struct
- d
Now that CDM block support has been added to DPU lets also add its
entry to the DPU snapshot to help debugging.
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp
Add an API dpu_encoder_helper_phys_setup_cdm() which can be used by
the writeback encoder to setup the CDM block.
Currently, this is defined and used within the writeback's physical
encoder layer however, the function can be modified to be used to setup
the CDM block even for non-writeback interfa
CDM block will need its own logic to program the flush and active
bits in the dpu_hw_ctl layer.
Make necessary changes in dpu_hw_ctl to support CDM programming.
changes in v2:
- remove unused empty line
- pass in cdm_num to update_pending_flush_cdm()
Signed-off-by: Abhinav Kumar
In preparation of setting up CDM block, add the logic to disable it
properly during encoder cleanup.
changes in v2:
- call update_pending_flush_cdm even when bind_pingpong_blk
is not present
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 10
Even though there is usually only one CDM block, it can be
used by either HDMI, DisplayPort OR Writeback interfaces.
Hence its allocation needs to be tracked properly by the
resource manager to ensure appropriate availability of the
block.
changes in v2:
- move needs_cdm to topology struc
Add the RM APIs necessary to initialize and allocate CDM
blocks to be used by the rest of the DPU pipeline.
changes in v2:
- treat cdm_init() failure as fatal
- fixed the commit text
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 13 +
driv
CDM block comes with its own set of registers and operations
which can be done. In-line with other hardware sub-blocks, this
change adds the dpu_hw_cdm abstraction for the CDM block.
changes in v2:
- replace bit magic with relevant defines
- use drmm_kzalloc instead of kzalloc/free
For YUV cases, setting the required format bits was missed
out in the register programming. Lets fix it now in preparation
of adding YUV formats support for writeback.
changes in v2:
- dropped the fixes tag as its not a fix but adding
new functionality
Signed-off-by: Abhinav Kumar
---
Add CDM blocks to the sm8250 dpu_hw_catalog to support
YUV format output from writeback block.
changes in v2:
- re-use the cdm definition from sc7280
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 1 +
1 file changed, 1 insertion(+)
diff --git
Add CDM blocks to the sc7280 dpu_hw_catalog to support
YUV format output from writeback block.
changes in v2:
- remove explicit zero assignment for features
- move sc7280_cdm to dpu_hw_catalog from the sc7280
catalog file as its definition can be re-used
Signed-off-by: A
Since the type and usage of CSC matrices is spanning across DPU
lets introduce a helper to the dpu_hw_util to return the CSC
corresponding to the request type. This will help to add more
supported CSC types such as the RGB to YUV one which is used in
the case of CDM.
Signed-off-by: Abhinav Kumar
dpu_encoder_phys_wb_setup_cdp() is not programming the chroma down
prefetch block. Its setting up the display ctl path for writeback.
Hence rename it to dpu_encoder_phys_wb_setup_ctl() to match what its
actually doing.
Fixes: d7d0e73f7de3 ("drm/msm/dpu: introduce the dpu_encoder_phys_* for
write
In preparation for adding more formats to dpu writeback add
format validation to it to fail any unsupported formats.
changes in v2:
- correct some grammar in the commit text
Fixes: d7d0e73f7de3 ("drm/msm/dpu: introduce the dpu_encoder_phys_* for
writeback")
Signed-off-by: Abhinav Kumar
Chroma Down Sampling (CDM) block is a hardware block in the DPU pipeline
which among other things has a CSC block that can convert RGB input
from the DPU to YUV data.
This block can be used with either HDMI, DP or writeback interface.
In this series, lets first add the support for CDM block to be
On Thu, Dec 07, 2023 at 05:37:19PM +0100, Neil Armstrong wrote:
> diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi
> b/arch/arm64/boot/dts/qcom/sm8650.dtsi
[..]
> +
> + mdss_dp0: displayport-controller@af54000 {
> + compatible = "qcom,sm8650-dp";
>
On Mon, 20 Nov 2023 13:12:51 +0100, Konrad Dybcio wrote:
> as it says on the can
>
> drm/msm patches for Rob
> arm64 patches for linux-arm-msm
>
> for use with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25408
>
> [...]
Applied, thanks!
[1/4] arm64: dts: qcom: sc7280: Add ZAP s
On Thu, 07 Dec 2023 17:37:16 +0100, Neil Armstrong wrote:
> This adds support for the DisplayPort Controller found in the SM8650
> SoC, but it requires a specific compatible because the registers offsets
> has changed since SM8550.
>
> This also updates the SM8650 MDSS bindings to allow a displa
On Wed, 04 Oct 2023 06:19:03 +0300, Dmitry Baryshkov wrote:
> There are no in-kernel users of MSM_ENC_VBLANK wait type. Drop it
> together with the corresponding wait_for_vblank callback.
>
>
Applied, thanks!
[1/1] drm/msm/dpu: drop MSM_ENC_VBLANK support
https://gitlab.freedesktop.org/
On Wed, 06 Dec 2023 15:02:05 +0300, Dan Carpenter wrote:
> The platform_get_irq() function returns negative error codes. It never
> returns zero. Fix the check accordingly.
>
>
Applied, thanks!
[1/1] drm/msm/dp: Fix platform_get_irq() check
https://gitlab.freedesktop.org/lumag/msm/-/c
On 06/12/2023 14:02, Dan Carpenter wrote:
The platform_get_irq() function returns negative error codes. It never
returns zero. Fix the check accordingly.
Fixes: 82c2a5751227 ("drm/msm/dp: tie dp_display_irq_handler() with dp driver")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/msm/dp/d
As the renamed drm_atomic_helper_check_wb_connector_state() now accepts
drm_writeback_connector as the first argument (instead of drm_encoder),
move the VKMS writeback atomic_check from drm_encoder_helper_funcs to
drm_connector_helper_funcs. Also drop the vkms_wb_encoder_helper_funcs,
which have be
The drm_atomic_helper_check_wb_encoder_state() function doesn't use
encoder for anything other than getting the drm_device instance. The
function's description talks about checking the writeback connector
state, not the encoder state. Moreover, there is no such thing as an
encoder state, encoders g
The function drm_atomic_helper_check_wb_encoder_state() doesn't use
drm_encoder for anything sensible. Internally it checks
drm_writeback_connector's state. Thus it makes sense to let this
function accept drm_connector object and the drm_atomic_state
and rename it to drm_atomic_helper_check_wb_conn
On Thu, 7 Dec 2023 at 12:10, Maxime Ripard wrote:
>
> Hi,
>
> On Wed, Dec 06, 2023 at 01:14:54PM +0300, Dmitry Baryshkov wrote:
> > The drm_atomic_helper_check_wb_encoder_state() function doesn't use
> > encoder for anything other than getting the drm_device instance. The
> > function's descriptio
Split up calculating configuration parameters and programming them, so
that we can expose them to userspace.
Signed-off-by: Connor Abbott
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 21 ++---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 101 +---
drivers/gpu/drm/msm/adreno/ad
The highest bank bit is a parameter that influences the Adreno tiling
scheme. It is programmed by the kernel, and is supposed to be based on
the DRAM configuration. In order for Mesa to tile/until images itself,
it needs to know this parameter, and because it's programmed by the
kernel, the kernel
This parameter is programmed by the kernel and influences the tiling
layout of images. Exposing it to userspace will allow it to tile/untile
images correctly without guessing what value the kernel programmed, and
allow us to change it in the future without breaking userspace.
Signed-off-by: Connor
From: Rob Clark
We also want the default domain for the GMU to be an identy domain,
so it does not get a context bank assigned. Without this, both
of_dma_configure() and drm/msm's iommu_domain_attach() will trigger
allocating and configuring a context bank. So GMU ends up attached
to both cbndx
On 11/14/2023 2:58 PM, Jonathan Marek wrote:
The value returned by msm_dsi_wide_bus_enabled() doesn't match what the
driver is doing in video mode. Fix that by actually enabling widebus for
video mode.
Fixes: efcbd6f9cdeb ("drm/msm/dsi: Enable widebus for DSI")
Signed-off-by: Jonathan Marek
On 11/14/2023 2:58 PM, Jonathan Marek wrote:
Add a dsc_slice_per_pkt field to mipi_dsi_device struct and the necessary
changes to msm driver to support this field.
Note that the removed "pkt_per_line = slice_per_intf * slice_per_pkt"
comment is incorrect.
Hi John,
Thanks for catching the t
On 12/7/23 20:46, Akhil P Oommen wrote:
On Thu, Nov 23, 2023 at 12:03:56AM +0300, Danila Tikhonov wrote:
sc7180/sm7125 (atoll) expects speedbins from atoll.dtsi:
And has a parameter: /delete-property/ qcom,gpu-speed-bin;
107 for 504Mhz max freq, pwrlevel 4
130 for 610Mhz max freq, pwrlevel 3
On 12/7/23 17:37, Neil Armstrong wrote:
Declare the displayport controller present on the Qualcomm SM8650 SoC
and connected to the USB3/DP Combo PHY.
Signed-off-by: Neil Armstrong
---
[...]
+ clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
+
On Thu, Nov 23, 2023 at 12:03:56AM +0300, Danila Tikhonov wrote:
>
> sc7180/sm7125 (atoll) expects speedbins from atoll.dtsi:
> And has a parameter: /delete-property/ qcom,gpu-speed-bin;
> 107 for 504Mhz max freq, pwrlevel 4
> 130 for 610Mhz max freq, pwrlevel 3
> 159 for 750Mhz max freq, pwrlevel
On Thu, 7 Dec 2023 at 18:37, Neil Armstrong wrote:
>
> The Qualcomm SM8650 platform comes with a DisplayPort controller
> with a different base offset than the previous SM8550 SoC,
> add support for this in the DisplayPort driver.
>
> Signed-off-by: Neil Armstrong
Reviewed-by: Dmitry Baryshkov
On 07/12/2023 17:37, Neil Armstrong wrote:
> Document the DisplayPort controller found in the Qualcomm SM8650 SoC,
> the Controller base addresses and layout differ and thus cannot use
> the SM8350 compatible as fallback.
>
> Signed-off-by: Neil Armstrong
> ---
Reviewed-by: Krzysztof Kozlowski
Declare the displayport controller present on the Qualcomm SM8650 SoC
and connected to the USB3/DP Combo PHY.
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/qcom/sm8650.dtsi | 120 ++-
1 file changed, 118 insertions(+), 2 deletions(-)
diff --git a/arch/arm
The Qualcomm SM8650 platform comes with a DisplayPort controller
with a different base offset than the previous SM8550 SoC,
add support for this in the DisplayPort driver.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/msm/dp/dp_display.c | 6 ++
1 file changed, 6 insertions(+)
diff --gi
Document the DisplayPort controller found in the Qualcomm SM8650 SoC,
the Controller base addresses and layout differ and thus cannot use
the SM8350 compatible as fallback.
Signed-off-by: Neil Armstrong
---
Documentation/devicetree/bindings/display/msm/dp-controller.yaml| 1 +
Documentation/
-
drivers/gpu/drm/msm/dp/dp_display.c| 6 ++
4 files changed, 131 insertions(+), 2 deletions(-)
---
base-commit: 9ea914fd2cc702e8be88c0666d4df3e58ffe8131
change-id: 20231207-topic-sm8650-upstream-dp-ab1fc1bf0c76
Best regards,
--
Neil Armstrong
On 07/12/2023 12:54 pm, Dmitry Baryshkov wrote:
In preparation of dropping most of ARCH_QCOM subtypes, stop limiting the
driver just to those machines. Allow it to be built for any 32-bit
Qualcomm platform (ARCH_QCOM).
Acked-by: Robin Murphy
Unless Joerg disagrees, I think it should be fine i
Three remaining Qualcomm platforms have special handling of the
TEXT_OFFSET to reserve the memory at the beginnig of the system RAM, see
the commit 9e775ad19f52 ("ARM: 7012/1: Set proper TEXT_OFFSET for newer
MSMs"). This is required for older platforms like IPQ40xx, MSM8x60,
MSM8960 and APQ8064 an
The Kconfig for 32-bit Qualcomm arch predates DT and multi-machine
support. It still defines ARCH_MSM* types for some (but not all) 32-bit
Qualcomm machines. The MSM_IOMMU driver has a strict dependency on one
of such kinds.
With the DT support in place, this has become obsolete quite a while
ago.
In preparation of dropping most of ARCH_QCOM subtypes, stop limiting the
driver just to those machines. Allow it to be built for any 32-bit
Qualcomm platform (ARCH_QCOM).
Signed-off-by: Dmitry Baryshkov
---
drivers/iommu/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
Historically we had several subtypes of 32-bit Qualcomm platforms.
Nowadays they became just useless symbols in Kconfig. Drop them and pull
corresponding clocksource entries towards top-level ARCH_QCOM entry.
Note, I've left ARCH_IPQ40XX, ARCH_MSM8x60 and ARCH_MSM8960 in place,
since they have spe
Hi,
On Wed, Dec 06, 2023 at 01:14:54PM +0300, Dmitry Baryshkov wrote:
> The drm_atomic_helper_check_wb_encoder_state() function doesn't use
> encoder for anything other than getting the drm_device instance. The
> function's description talks about checking the writeback connector
> state, not the
48 matches
Mail list logo
