On 22/12/2022 17:22, Kuogee Hsieh wrote:
>
> On 12/22/2022 2:47 AM, Krzysztof Kozlowski wrote:
>> On 16/12/2022 20:11, Kuogee Hsieh wrote:
>>> Move data-lanes property from mdss_dp node to dp_out endpoint. Also
>>> add link-frequencies property into dp_out endpoint as well. The last
>>> frequency
On 23/12/2022 00:14, Jessica Zhang wrote:
Initialize and use the color_fill properties for planes in DPU driver. In
addition, relax framebuffer requirements within atomic commit path and
add checks for NULL framebuffers. Finally, drop DPU_PLANE_COLOR_FILL_FLAG
as it's unused.
Changes since V2:
On 23/12/2022 00:14, Jessica Zhang wrote:
Loosen the requirements for atomic and legacy commit so that, in cases
where solid fill planes is enabled (and FB_ID is NULL), the commit can
still go through.
In addition, add framebuffer NULL checks in other areas to account for
FB being NULL when
The sdm630 can use the sdm660 mdss-dsi-ctrl compat. Currently it has the
same set of binding dependencies as sdm660.
Suggested-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sdm630.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Add silicon specific compatible qcom,sdm845-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sdm845 against the yaml documentation.
Reviewed-by: Douglas Anderson
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
Add silicon specific compatible qcom,sc7180-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sc7180 against the yaml documentation.
Reviewed-by: Douglas Anderson
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
Add silicon specific compatible qcom,sm8250-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sm8250 against the yaml documentation.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 6 --
1
Add silicon specific compatible qcom,msm8996-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for msm8996 against the yaml documentation.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 6 --
Add silicon specific compatible qcom,msm8974-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for msm8974 against the yaml documentation.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 3 ++-
1
power-domain is required for the sc7180 dispcc GDSC but not every qcom SoC
has a similar dependency for example the apq8064.
Most Qcom SoC's using mdss-dsi-ctrl seem to have the ability to
power-collapse the MDP without collapsing DSI.
For example the qcom vendor kernel commit for apq8084,
Add silicon specific compatible qcom,sdm660-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sdm660 against the yaml documentation.
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/sdm660.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1
Each compatible has a different set of clocks which are associated with it.
Add in the list of clocks for each compatible.
Acked-by: Rob Herring
Acked-by: Krzysztof Kozlowski
Signed-off-by: Bryan O'Donoghue
---
.../display/msm/dsi-controller-main.yaml | 209 --
1 file
Add silicon specific compatible qcom,sc7280-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for sc7280 against the yaml documentation.
Reviewed-by: Douglas Anderson
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
Add silicon specific compatible qcom,msm8953-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for msm8953 against the yaml documentation.
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/msm8953.dtsi | 4 ++--
1 file changed, 2
Add silicon specific compatible qcom,msm8916-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for msm8916 against the yaml documentation.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 3 ++-
1
Add the list of current compats absent the deprecated qcm2290 to the list
of dsi compats listed here.
Several MDSS yaml files exist which document the dsi sub-node.
For each existing SoC MDSS yaml, provide the right dsi compat string.
Signed-off-by: Bryan O'Donoghue
---
Currently we do not differentiate between the various users of the
qcom,mdss-dsi-ctrl. The driver is flexible enough to operate from one
compatible string but, the hardware does have some significant differences
in the number of clocks.
To facilitate documenting the clocks add the following
Append silicon specific compatible qcom,apq8064-dsi-ctrl to the
mdss-dsi-ctrl block. This allows us to differentiate the specific bindings
for apq8064 against the yaml documentation.
Reviewed-by: David Heidelberg
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bryan O'Donoghue
---
When converting from .txt to .yaml we didn't include descriptions for the
existing regulator supplies.
- vdd
- vdda
- vddio
Add those descriptions into the yaml now as they were prior to the
conversion. In the .txt description we marked these regulators as required,
however, that requirement
The existing msm8916.dtsi does not depend on nor require operating points.
Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI bindings")
Reviewed-by: Dmitry Baryshkov
Acked-by: Krzysztof Kozlowski
Signed-off-by: Bryan O'Donoghue
---
There's a typo in describing the core clock as an 'escape' clock. The
accurate description is 'core'.
Fixes: 4dbe55c97741 ("dt-bindings: msm: dsi: add yaml schemas for DSI bindings")
Reviewed-by: Dmitry Baryshkov
Acked-by: Krzysztof Kozlowski
Signed-off-by: Bryan O'Donoghue
---
V6:
- Squashes a number of patches per Krzysztof's comments on bisectability
- Adds in Acked-by Rob and Krzysztof
V5:
- Adds compat strings to bindings/display/msm/qcom,SoC-mdss.yaml - Dmitry
- Re-orders simple fixes to the start of the series to allow backports - Dmitry
- VDDA and drop of
Every user of this function either uses component_compare_of or
something equivalent. Most of them immediately put the device node as
well. Convert these users to component_match_add_of and remove
drm_of_component_match_add.
Signed-off-by: Sean Anderson
Acked-by: Jyri Sarha
Tested-by: Jyri
This series adds a new function component_match_add_of to simplify the
common case of calling component_match_add_release with
component_release_of and component_compare_of. There is already
drm_of_component_match_add, which allows for a custom compare function.
However, all existing users just
Initialize and use the color_fill properties for planes in DPU driver. In
addition, relax framebuffer requirements within atomic commit path and
add checks for NULL framebuffers. Finally, drop DPU_PLANE_COLOR_FILL_FLAG
as it's unused.
Changes since V2:
- Fixed dropped 'const' warning
- Dropped
Introduce and add support for a solid_fill property. When the solid_fill
property is set, and the framebuffer is set to NULL, memory fetch will be
disabled.
In addition, loosen the NULL FB checks within the atomic commit callstack
to allow a NULL FB when the solid_fill property is set and add FB
Add support for solid_fill property to drm_plane. In addition, add
support for setting and getting the values for solid_fill.
solid_fill holds data for supporting solid fill planes. The property
accepts an RGB323232 value and the driver data is formatted as such:
struct drm_solid_fill {
Loosen the requirements for atomic and legacy commit so that, in cases
where solid fill planes is enabled (and FB_ID is NULL), the commit can
still go through.
In addition, add framebuffer NULL checks in other areas to account for
FB being NULL when solid fill is enabled.
Changes in V2:
-
Hi Robin,
On 12/16/22 12:41, Robin Murphy wrote:
> On 2022-12-16 17:08, Sean Anderson wrote:
>> On 11/3/22 14:22, Sean Anderson wrote:
>>> This series adds a new function component_match_add_of to simplify the
>>> common case of calling component_match_add_release with
>>> component_release_of
On 12/22/2022 2:47 AM, Krzysztof Kozlowski wrote:
On 16/12/2022 20:11, Kuogee Hsieh wrote:
Move data-lanes property from mdss_dp node to dp_out endpoint. Also
add link-frequencies property into dp_out endpoint as well. The last
frequency specified at link-frequencies will be the max link rate
On Wed, 21 Dec 2022 at 18:14, Akhil P Oommen wrote:
>
> When a device has multiple power domains, dev->power_domain is left
> empty during probe. That didn't cause any issue so far because we are
> freeloading on smmu driver's vote on cx gdsc. Instead of that, create
> a device_link between cx
On Wed, 21 Dec 2022 at 18:14, Akhil P Oommen wrote:
>
> As per the recommended recovery sequence of adreno gpu, cx gdsc should
> collapse at hardware before it is turned back ON. This helps to clear
> out the stale states in hardware before it is reinitialized. Use the
> genpd notifier along with
On Wed, 21 Dec 2022 at 18:14, Akhil P Oommen wrote:
>
> Remove the unused 'reset' interface which was supposed to help to ensure
> that cx gdsc has collapsed during gpu recovery. This is was not enabled
> so far due to missing gpucc driver support. Similar functionality using
> genpd framework
On Wed, 21 Dec 2022 at 18:14, Akhil P Oommen wrote:
>
> Add support for the newly added 'synced_poweroff' genpd flag. This allows
> some clients (like adreno gpu driver) to request gdsc driver to ensure
> a votable gdsc (like gpucc cx gdsc) has collapsed at hardware.
>
> Signed-off-by: Akhil P
Clear interface active register from the datapath for a clean shutdown of
the datapath.
Signed-off-by: Vinod Polimera
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
Reset the datapath after disabling the timing gen, such that
it can start on a clean slate when the intf is enabled back.
This was a recommended sequence from the DPU HW programming guide.
Signed-off-by: Vinod Polimera
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 1 +
1 file
There can be a race between timing gen disable and vblank irq. The
wait post timing gen disable may return early but intf disable sequence
might not be completed. Ensure that, intf status is disabled before
we retire the function.
Signed-off-by: Vinod Polimera
---
Recommended way of reading the interface timing gen status is via
status register. Timing gen status register will give a reliable status
of the interface especially during ON/OFF transitions. This support was
added from DPU version 5.0.0.
Signed-off-by: Vinod Polimera
---
Use atomic variants for panel bridge callback functions such that
certain states like self-refresh can be accessed as part of
enable/disable sequence.
Signed-off-by: Sankeerth Billakanti
Signed-off-by: Vinod Polimera
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/panel.c | 20
From: Sankeerth Billakanti
Updated frames get queued if self_refresh_aware is set when the
sink is in psr. To support bridge enable and avoid queuing of update
frames, reset the self_refresh_aware state after entering psr.
Signed-off-by: Sankeerth Billakanti
Signed-off-by: Vinod Polimera
---
Enable PSR on eDP interface using drm self-refresh librabry.
This patch uses a trigger from self-refresh library to enter/exit
into PSR, when there are no updates from framework.
Signed-off-by: Kalyan Thota
Signed-off-by: Vinod Polimera
Reviewed-by: Dmitry Baryshkov
---
According to KMS documentation, The driver must not release any shared
resources if active is set to false but enable still true.
Fixes: ccc862b957c6 ("drm/msm/dpu: Fix reservation failures in modeset")
Signed-off-by: Vinod Polimera
Reviewed-by: Dmitry Baryshkov
---
Use atomic variants for encoder callback functions such that
certain states like self-refresh can be accessed as part of
enable/disable sequence.
Signed-off-by: Kalyan Thota
Signed-off-by: Vinod Polimera
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 10
This change will handle the psr entry exit cases in the panel
bridge atomic callback functions. For example, the panel power
should not turn off if the panel is entering psr.
Signed-off-by: Sankeerth Billakanti
Signed-off-by: Vinod Polimera
---
drivers/gpu/drm/bridge/panel.c | 48
Changes in v2:
- Use dp bridge to set psr entry/exit instead of dpu_enocder.
- Don't modify whitespaces.
- Set self refresh aware from atomic_check.
- Set self refresh aware only if psr is supported.
- Provide a stub for msm_dp_display_set_psr.
- Move dp functions to bridge code.
The eDP and DP interfaces shared the bridge operations and
the eDP specific changes were implemented under is_edp check.
To add psr support for eDP, we started using a new set of eDP
bridge ops. We are moving the eDP specific code in the
dp_bridge_mode_valid function to a new eDP function,
Add support for basic panel self refresh (PSR) feature for eDP.
Add a new interface to set PSR state in the sink from DPU.
Program the eDP controller to issue PSR enter and exit SDP to
the sink.
Signed-off-by: Sankeerth Billakanti
Signed-off-by: Vinod Polimera
Reviewed-by: Dmitry Baryshkov
---
Use atomic variants for DP bridge callback functions so that
the atomic state can be accessed in the interface drivers.
The atomic state will help the driver find out if the display
is in self refresh state.
Signed-off-by: Sankeerth Billakanti
Signed-off-by: Vinod Polimera
Reviewed-by: Dmitry
Add new helper functions, drm_atomic_get_old_crtc_for_encoder
and drm_atomic_get_new_crtc_for_encoder to retrieve the
corresponding crtc for the encoder.
Signed-off-by: Sankeerth Billakanti
Signed-off-by: Vinod Polimera
Reviewed-by: Douglas Anderson
---
drivers/gpu/drm/drm_atomic.c | 60
Cache crtc obj in the dpu encoder during initialization.
This will avoid extracting crtc from connector state there by
simplifying the obj access whenever it is required.
This patch is dependent on the series:
https://patchwork.freedesktop.org/series/110969/
Signed-off-by: Vinod Polimera
---
On 22/12/2022 11:50, Krzysztof Kozlowski wrote:
On 20/12/2022 13:36, Bryan O'Donoghue wrote:
Deprecate qcom,dsi-ctrl-6g-qcm2290 in favour of the desired format
qcom,qcm2290-dsi-ctrl.
Signed-off-by: Bryan O'Donoghue
---
.../display/msm/dsi-controller-main.yaml | 36 +++
On 20/12/2022 13:36, Bryan O'Donoghue wrote:
> Several MDSS yaml files exist which document the dsi sub-node.
> For each existing SoC MDSS yaml, provide the right dsi compat string.
>
> Signed-off-by: Bryan O'Donoghue
Same concerns about bisectability.
Best regards,
Krzysztof
On 20/12/2022 13:36, Bryan O'Donoghue wrote:
> Add the list of current compats absent the deprecated qcm2290 to the list
> of dsi compats listed here.
>
> Signed-off-by: Bryan O'Donoghue
> ---
> .../bindings/display/msm/qcom,mdss.yaml | 16 +++-
> 1 file changed, 15
On 20/12/2022 13:36, Bryan O'Donoghue wrote:
> When converting from .txt to .yaml we didn't include descriptions for the
> existing regulator supplies.
>
> - vdd
> - vdda
> - vddio
>
> Add those descriptions into the yaml now as they were prior to the
> conversion. In the .txt description we
On 20/12/2022 13:36, Bryan O'Donoghue wrote:
> When converting from .txt to .yaml dt-binding descriptions we appear to
> have missed some of the previous detail on the number and names of
> permissible clocks.
>
> Fix this by listing the clock descriptions against the clock names at a
> high
On 20/12/2022 13:36, Bryan O'Donoghue wrote:
> Each compatible has a different set of clocks which are associated with it.
> Add in the list of clocks for each compatible.
>
> Signed-off-by: Bryan O'Donoghue
> ---
> .../display/msm/dsi-controller-main.yaml | 189 +-
> 1
On 20/12/2022 13:36, Bryan O'Donoghue wrote:
> Deprecate qcom,dsi-ctrl-6g-qcm2290 in favour of the desired format
> qcom,qcm2290-dsi-ctrl.
>
> Signed-off-by: Bryan O'Donoghue
> ---
> .../display/msm/dsi-controller-main.yaml | 36 +++
> 1 file changed, 21 insertions(+), 15
On 22/12/2022 12:47, Krzysztof Kozlowski wrote:
> On 20/12/2022 13:36, Bryan O'Donoghue wrote:
>> Currently we do not differentiate between the various users of the
>> qcom,mdss-dsi-ctrl. The driver is flexible enough to operate from one
>> compatible string but, the hardware does have some
On 20/12/2022 13:36, Bryan O'Donoghue wrote:
> Currently we do not differentiate between the various users of the
> qcom,mdss-dsi-ctrl. The driver is flexible enough to operate from one
> compatible string but, the hardware does have some significant differences
> in the number of clocks.
>
> To
On 16/12/2022 22:44, Kuogee Hsieh wrote:
> Move data-lanes property from mdss_dp node to dp_out endpoint. Also
> add link-frequencies property into dp_out endpoint as well. The last
> frequency specified at link-frequencies will be the max link rate
> supported by DP.
>
> Changes in v5:
> --
On 16/12/2022 20:11, Kuogee Hsieh wrote:
> Move data-lanes property from mdss_dp node to dp_out endpoint. Also
> add link-frequencies property into dp_out endpoint as well. The last
> frequency specified at link-frequencies will be the max link rate
> supported by DP.
>
> Changes in v5:
> --
61 matches
Mail list logo
