On Mon, 19 Feb 2024 14:35:46 +0100, Konrad Dybcio wrote:
> The GPU SMMU on QCM2290 nicely fits into the description we already have
> for SM61[12]5. Add it.
>
> Signed-off-by: Konrad Dybcio
> ---
> Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 3 ++-
> 1 file changed, 2 insertions(+)
On 2/22/2024 1:56 PM, Dmitry Baryshkov wrote:
On Thu, 22 Feb 2024 at 23:28, Paloma Arellano wrote:
On 2/22/2024 1:18 PM, Dmitry Baryshkov wrote:
On Thu, 22 Feb 2024 at 21:40, Paloma Arellano wrote:
Add support to pack and send the VSC SDP packet for DP. This therefore
allows the transmisi
On Thu, 22 Feb 2024 at 23:53, Abhinav Kumar wrote:
>
>
>
> On 2/22/2024 1:47 PM, Dmitry Baryshkov wrote:
> > 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 writ
On Thu, 22 Feb 2024 at 23:28, Paloma Arellano wrote:
>
>
> On 2/22/2024 1:18 PM, Dmitry Baryshkov wrote:
> > On Thu, 22 Feb 2024 at 21:40, Paloma Arellano
> > wrote:
> >> Add support to pack and send the VSC SDP packet for DP. This therefore
> >> allows the transmision of format information to t
On 2/22/2024 1:47 PM, Dmitry Baryshkov wrote:
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 # # #
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 # # # # -
On 2/22/2024 1:18 PM, Dmitry Baryshkov wrote:
On Thu, 22 Feb 2024 at 21:40, Paloma Arellano wrote:
Add support to pack and send the VSC SDP packet for DP. This therefore
allows the transmision of format information to the sinks which is
needed for YUV420 support over DP.
Changes in v5:
On Thu, 22 Feb 2024 at 06:01, Dmitry Baryshkov
wrote:
>
> On Thu, 22 Feb 2024 at 05:47, Bjorn Andersson
> wrote:
> >
> > On Thu, Feb 22, 2024 at 01:38:45AM +0200, Dmitry Baryshkov wrote:
> > > On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson
> > > wrote:
> > > >
> > > > When upstreamed the SC7280
On Thu, 22 Feb 2024 at 21:40, Paloma Arellano wrote:
>
> Add support to pack and send the VSC SDP packet for DP. This therefore
> allows the transmision of format information to the sinks which is
> needed for YUV420 support over DP.
>
> Changes in v5:
> - Slightly modify use of drm_dp_vsc
On Sat, 17 Feb 2024 at 17:03, Johan Hovold wrote:
>
> Due to a long-standing issue in driver core, drivers may not probe defer
> after having registered child devices to avoid triggering a probe
> deferral loop (see fbc35b45f9f6 ("Add documentation on meaning of
> -EPROBE_DEFER")).
>
> Move regist
On Sat, 17 Feb 2024 at 17:03, Johan Hovold wrote:
>
> Due to a long-standing issue in driver core, drivers may not probe defer
> after having registered child devices to avoid triggering a probe
> deferral loop (see fbc35b45f9f6 ("Add documentation on meaning of
> -EPROBE_DEFER")).
>
> This could
On Sat, 17 Feb 2024 at 17:03, Johan Hovold wrote:
>
> From: Rob Clark
>
> We need to bail out before adding/removing devices if we are going to
> -EPROBE_DEFER. Otherwise boot can get stuck in a probe deferral loop due
> to a long-standing issue in driver core (see fbc35b45f9f6 ("Add
> documentat
On Sat, 17 Feb 2024 at 17:03, Johan Hovold wrote:
>
> A recent DRM series purporting to simplify support for "transparent
> bridges" and handling of probe deferrals ironically exposed a
> use-after-free issue on pmic_glink_altmode probe deferral.
>
> This has manifested itself as the display subsy
On Sat, 17 Feb 2024 at 17:03, Johan Hovold wrote:
>
> The two device node references taken during allocation need to be
> dropped when the auxiliary device is freed.
>
> Fixes: 6914968a0b52 ("drm/bridge: properly refcount DT nodes in aux bridge
> drivers")
> Cc: Dmitry Baryshkov
> Cc: Neil Armst
On Sat, 17 Feb 2024 at 17:03, Johan Hovold wrote:
>
> Combining allocation and registration is an anti-pattern that should be
> avoided. Add two new functions for allocating and registering an dp-hpd
> bridge with a proper 'devm' prefix so that it is clear that these are
> device managed interface
Adjust the encoder format programming in the case of video mode for DP
to accommodate CDM related changes.
Changes in v4:
- Remove hw_cdm check in dpu_encoder_needs_periph_flush()
- Remove hw_cdm check when getting the fmt_fourcc in
dpu_encoder_phys_vid_enable()
Changes
Change all relevant DP controller related programming for YUV420 cases.
Namely, change the pixel clock math to consider YUV420 and modify the
MVID programming to consider YUV420.
Changes in v2:
- Move configuration control programming to a different commit
- Slight code simplificat
Add support to pack and send the VSC SDP packet for DP. This therefore
allows the transmision of format information to the sinks which is
needed for YUV420 support over DP.
Changes in v5:
- Slightly modify use of drm_dp_vsc_sdp_pack()
- Remove dp_catalog NULL checks
- Modif
Adjust the encoder timing engine setup programming in the case of video
mode for YUV420 over DP to accommodate CDM.
Changes in v3:
- Move drm_display_mode's hskew division to another patch
- Minor cleanup
Changes in v2:
- Move timing engine programming to this patch
Signe
Widebus enablement is decided by the interfaces based on their specific
checks and that already happens with DSI/DP specific helpers. Let's
invoke these helpers from dpu_encoder_is_widebus_enabled() to make it
cleaner overall.
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
dri
Reserve CDM blocks for DP if the mode format is YUV420. Currently this
reservation only works for writeback and DP if the format is YUV420. But
this can be easily extented to other YUV formats for DP.
Changes in v2:
- Minor code simplification
Signed-off-by: Paloma Arellano
Reviewed-by:
All the components of YUV420 over DP are added. Therefore, let's mark the
connector property as true for DP connector when the DP type is not eDP
and when there is a CDM block available.
Changes in v3:
- Move setting the connector's ycbcr_420_allowed parameter so
that it is not d
In the DP driver, check if VSC SDP is supported and propagate this value
to dp_panel. In dp_display's dp_mode, the out_fmt_is_yuv_420 parameter
must also utilize this value since YUV420 is only allowed when VSC SDP
is supported.
Changes in v2:
- Move DP programming when VSC SDP is supporte
DP controller can be setup to operate in either SDP update flush mode or
peripheral flush mode based on the DP controller hardware version.
Starting in DP v1.2, the hardware documents require the use of
peripheral flush mode for SDP packets such as PPS OR VSC SDP packets.
In-line with this guidan
From: Kuogee Hsieh
Introduce a peripheral flushing mechanism to decouple peripheral
metadata flushing from timing engine related flush.
Changes in v2:
- Fixed some misalignment issues
Signed-off-by: Kuogee Hsieh
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
driver
Parity calculation is necessary for VSC SDP implementation. Therefore
create new files dp_utils.c and dp_utils.h and move the parity
calculating functions here. This ensures that they are usable by SDP
programming in both dp_catalog.c and dp_audio.c
Changes in v3:
- Change ordering of the
Change relevant DP controller related programming for YUV420 cases.
Program the configuration control register to indicate YUV420.
Changes in v2:
- Create a new patch only for configuration control programming
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu
Wide bus is not supported when the mode is YUV420 in DP. In preparation
for changing the DPU programming to reflect this, the value and
assignment location of wide_bus_en for the DP submodules must be
changed. Move it from boot time in dp_init_sub_modules() to run time in
dp_display_mode_set.
Sign
Rename wide_bus_en to wide_bus_supported in dp_display_private to
correctly establish that the parameter is referencing if wide bus is
supported instead of enabled.
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dp/dp_display.c | 42 ++--
Move dpu_encoder_helper_phys_setup_cdm to dpu_encoder in preparation for
implementing YUV420 over DP, which requires CDM compatibility.
Changes in v2:
- Slightly change the wording of the commit text to make clear
that YUV over DP requires CDM
Signed-off-by: Paloma Arellano
Rev
Generalize dpu_encoder_helper_phys_setup_cdm to be compatible with DP.
Changes in v2:
- Minor formatting changes
- Move the modification of the dimensions for CDM setup to a new
patch
Signed-off-by: Paloma Arellano
Reviewed-by: Dmitry Baryshkov
---
.../gpu/drm/msm/dis
Modify the output width and height parameters of hw_cdm to utilize the
physical encoder's data instead of obtaining the information from the
framebuffer. CDM is to be set up to utilize the actual output data since
at CDM setup, there is no difference between the two sources.
Changes in v2:
CDM block supports formats other than H1V2 for DP. Since we are now
adding support for CDM over DP, relax the checks to allow all other
formats for DP other than H1V2.
Changes in v2:
- Add fixes tag
- Move patch to top of series
Fixes: 0afac0ba6024 ("drm/msm/dpu: add dpu_hw_cdm ab
Setting up the timing engine when the physical encoder has a split role
neglects dividing the drm_display_mode's hskew parameter. Let's fix this
since this must also be done in preparation for implementing YUV420 over
DP.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Palom
The Chroma Down Sampling (CDM) block is a hardware component in the DPU
pipeline that includes a CSC block capable of converting RGB input from
the DPU to YUV data.
This block can be used with either HDMI, DP, or writeback interfaces.
This series adds support for the CDM block to be used with DP i
On Tue, Feb 20, 2024 at 11:53:47AM -0800, Abhinav Kumar wrote:
> Currently the size parameter of drm_dp_vsc_sdp_pack() is always
> the size of struct dp_sdp. Hence lets drop this parameter and
> use sizeof() directly.
>
> Suggested-by: Dmitry Baryshkov
> Signed-off-by: Abhinav Kumar
it looks in
On Tue, Feb 20, 2024 at 11:53:47AM -0800, Abhinav Kumar wrote:
> Currently the size parameter of drm_dp_vsc_sdp_pack() is always
> the size of struct dp_sdp. Hence lets drop this parameter and
> use sizeof() directly.
>
> Suggested-by: Dmitry Baryshkov
> Signed-off-by: Abhinav Kumar
> ---
> dri
On 2/22/2024 1:46 AM, Dmitry Baryshkov wrote:
On Thu, 22 Feb 2024 at 11:28, Konrad Dybcio wrote:
On 2/22/24 10:04, Dmitry Baryshkov wrote:
On Thu, 22 Feb 2024 at 10:56, Konrad Dybcio wrote:
On 2/22/24 00:41, Dmitry Baryshkov wrote:
On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson wro
On Fri, 16 Feb 2024 12:03:47 +0100, Neil Armstrong wrote:
> Unlike the the very close A740 GPU on the SM8550 SoC, the A750 GPU
> doesn't have an HWCFG block but a separate register set.
>
> The missing registers are added in the a6xx.xml.h file that would
> require a subsequent sync and the non-ex
On Mon, 19 Feb 2024 14:35:45 +0100, Konrad Dybcio wrote:
> Bit of a megaseries, bunched together for your testing convenience..
> Needs mesa!27665 [1] on the userland part, kmscube happily spins.
>
> I'm feeling quite lukewarm about the memory barriers in patch 3..
>
> Patch 1 for Will/smmu, 5-6
On Thu, 22 Feb 2024 at 17:04, Bjorn Andersson wrote:
>
> On Thu, Feb 22, 2024 at 11:46:26AM +0200, Dmitry Baryshkov wrote:
> > On Thu, 22 Feb 2024 at 11:28, Konrad Dybcio
> > wrote:
> > >
> > >
> > >
> > > On 2/22/24 10:04, Dmitry Baryshkov wrote:
> > > > On Thu, 22 Feb 2024 at 10:56, Konrad Dyb
On 2/22/2024 4:49 AM, Bjorn Andersson wrote:
With the ADSP remoteproc loaded pmic_glink can be introduced and wired
up to provide role and orientation switching signals.
Signed-off-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 48 +++-
1 fi
On Wed, Feb 21, 2024 at 08:06:41PM -0600, Bjorn Andersson wrote:
> On Sat, Feb 17, 2024 at 04:02:24PM +0100, Johan Hovold wrote:
> > diff --git a/drivers/gpu/drm/bridge/aux-hpd-bridge.c
> > b/drivers/gpu/drm/bridge/aux-hpd-bridge.c
> [..]
> > +/**
> > + * devm_drm_dp_hpd_bridge_add - register a HD
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 in devicetree via is-edp flag.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/dp/dp_display.c | 9 +
1 file cha
Instead of relying on different compatibles for eDP and DP, use
the is-edp property from DT to figure out the connector type and
then pass on that information to the PHY.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/dp/dp_ctrl.c| 11 +++
drivers/gpu
Add the X1E80100 to the list of compatibles and document the is-edp
flag. The controllers are expected to operate in DP mode by default,
and this flag can be used to select eDP mode.
Signed-off-by: Abel Vesa
---
Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 6 ++
1 file
Since this new platform supports both DP and eDP, it's the perfect time
to drop the dual compatible (eDP and DP) and figure out a different way
to specify the mode. After some off-list discussion, one suggested way
was to add a 'is-edp' property to the controller node and call
phy_set_mode to let t
On Thu, Feb 22, 2024 at 11:46:26AM +0200, Dmitry Baryshkov wrote:
> On Thu, 22 Feb 2024 at 11:28, Konrad Dybcio wrote:
> >
> >
> >
> > On 2/22/24 10:04, Dmitry Baryshkov wrote:
> > > On Thu, 22 Feb 2024 at 10:56, Konrad Dybcio
> > > wrote:
> > >>
> > >>
> > >>
> > >> On 2/22/24 00:41, Dmitry Bar
On 16/02/2024 12:03, Neil Armstrong wrote:
> Document the GPU SMMU found on the SM8650 platform.
>
> Signed-off-by: Neil Armstrong
> ---
> Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
Reviewed-by: Krzysztof Kozlowski
Best
On 16/02/2024 12:03, Neil Armstrong wrote:
> The if condition for the SM8[45]50 GPU SMMU is too large,
> add the other compatible strings to the condition to only
> allow the clocks for the GPU SMMU nodes.
>
> Fixes: 4fff78dc2490 ("dt-bindings: arm-smmu: Document SM8[45]50 GPU SMMU")
> Suggested-b
---
base-commit: ffa0c87f172bf7a0132aa960db412f8d63b2f533
change-id: 20240222-fd-dpu-yv16-yv24-6bf152dfa7f3
Best regards,
--
Dmitry Baryshkov
On 2/22/24 10:46, Dmitry Baryshkov wrote:
On Thu, 22 Feb 2024 at 11:28, Konrad Dybcio wrote:
On 2/22/24 10:04, Dmitry Baryshkov wrote:
On Thu, 22 Feb 2024 at 10:56, Konrad Dybcio wrote:
On 2/22/24 00:41, Dmitry Baryshkov wrote:
On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson wrote:
On Thu, 22 Feb 2024 at 11:28, Konrad Dybcio wrote:
>
>
>
> On 2/22/24 10:04, Dmitry Baryshkov wrote:
> > On Thu, 22 Feb 2024 at 10:56, Konrad Dybcio
> > wrote:
> >>
> >>
> >>
> >> On 2/22/24 00:41, Dmitry Baryshkov wrote:
> >>> On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson
> >>> wrote:
>
On 22/02/2024 00:19, Bjorn Andersson wrote:
With MDSS, pmic_glink, and the redriver in place, wire up the various
components to enable USB Type-C display on the RB3gen2.
Signed-off-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 63 +++-
1 file
On 2/22/24 10:04, Dmitry Baryshkov wrote:
On Thu, 22 Feb 2024 at 10:56, Konrad Dybcio wrote:
On 2/22/24 00:41, Dmitry Baryshkov wrote:
On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson wrote:
The max frequency listed in the DPU opp-table is 506MHz, this is not
sufficient to drive a 4k@60
On Thu, 22 Feb 2024 at 10:56, Konrad Dybcio wrote:
>
>
>
> On 2/22/24 00:41, Dmitry Baryshkov wrote:
> > On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson
> > wrote:
> >>
> >> The max frequency listed in the DPU opp-table is 506MHz, this is not
> >> sufficient to drive a 4k@60 display, resulting in
On 2/22/24 00:19, Bjorn Andersson wrote:
The RB3gen2 has a USB redriver on APPS_I2C, enable the bus and introduce
the redriver. The plumbing with other components is kept separate for
clarity.
Signed-off-by: Bjorn Andersson
---
Any chance you could add an alias for this I2C bus?
Or all of
On 2/22/24 00:41, Dmitry Baryshkov wrote:
On Thu, 22 Feb 2024 at 01:19, Bjorn Andersson wrote:
The max frequency listed in the DPU opp-table is 506MHz, this is not
sufficient to drive a 4k@60 display, resulting in constant underrun.
Add the missing MDP_CLK turbo frequency of 608MHz to the
On 2/22/24 00:19, Bjorn Andersson wrote:
The max frequency listed in the DPU opp-table is 506MHz, this is not
sufficient to drive a 4k@60 display, resulting in constant underrun.
Add the missing MDP_CLK turbo frequency of 608MHz to the opp-table to
fix this.
Signed-off-by: Bjorn Ander
On 2/22/24 00:19, Bjorn Andersson wrote:
The newly introduced mechanism for selecting eDP mode allow us to make a
DisplayPort controller operate in eDP mode, but not the other way
around. The qcom,sc7280-edp compatible is obviously tied to eDP, so this
would not allow us to select DisplayPort-
60 matches
Mail list logo
