Re: [Freedreno] [PATCH 1/9] dt-bindings: msm/dp: drop extra p1 region
On Fri, 08 Jul 2022 00:31:56 +0300, Dmitry Baryshkov wrote:
> The p1 region was probably added by mistake, none of the DTS files
> provides one (and the driver source code also doesn't use one). Drop it
> now.
>
> Fixes: 687825c402f1 ("dt-bindings: msm/dp: Change reg definition")
> Signed-off-by: Dmitry Baryshkov
> ---
> Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 1 -
> 1 file changed, 1 deletion(-)
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/msm/dp-controller.example.dtb:
displayport-controller@ae9: reg: [[183042048, 512], [183042560, 512],
[183043072, 3072], [183046144, 1024], [183047168, 1024]] is too long
From schema:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/patch/
This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
Re: [Freedreno] [PATCH] drm/msm/dsi: Set panel orientation when directly connected
On 7/8/2022 1:58 PM, Dmitry Baryshkov wrote:
On Fri, 8 Jul 2022 at 22:42, Abhinav Kumar wrote:
On 7/8/2022 9:00 AM, Abhinav Kumar wrote:
On 7/8/2022 8:25 AM, Doug Anderson wrote:
Hi,
On Wed, Jul 6, 2022 at 12:14 PM Stephen Boyd wrote:
Set the panel orientation in drm when the panel is directly connected,
i.e. we're not using an external bridge. The external bridge case is
already handled by the panel bridge code, so we only update the path we
take when the panel is directly connected/internal. This silences a
warning splat coming from __drm_mode_object_add() on Wormdingler boards.
Cc: Hsin-Yi Wang
Cc: Douglas Anderson
Signed-off-by: Stephen Boyd
---
This relies on commit 5e41b01a7808 ("drm/panel: Add an API to allow drm
to set orientation from panel") which is in drm-misc
drivers/gpu/drm/msm/dsi/dsi_manager.c | 2 ++
1 file changed, 2 insertions(+)
I don't personally have objections to this, but (to my understanding)
"the future" is that everyone should use panel_bridge. If we made the
move to panel_bridge today then we wouldn't need to do this. In
general I think panel_bridge would end up letting us delete a bunch of
code...
See commit 4e5763f03e10 ("drm/bridge: ti-sn65dsi86: Wrap panel with
panel-bridge") for when this was done by ti-sn65dsi86.
Then again, I spent a small amount of time looking into this and it's
definitely non-trivial. Still likely worthwhile, but not worth
blocking a tiny fix like this. It also should be fairly obvious that
we should delete this when we switch to panel_bridge.
Right, from what I saw on IRC, panel_bridge is the way forward and
dmitry did push a change to do that
https://patchwork.freedesktop.org/patch/492585/
But I think we can go ahead with this change because its simple enough.
Regarding the panel_bridge migration, I am going to start reviewing that
as well.
I did some more digging up on the panel_bridge migration.
Dmitry has posted this towards december last year
https://patches.linaro.org/project/dri-devel/patch/20211207222901.988484-3-dmitry.barysh...@linaro.org/
and I had given my R-b on this already in Jan.
I am not sure why this change was dropped OR was not part of msm-next
already.
Dmitry, any reason this change was left out so long and why the R-b was
not retained and this was reposted?
From what i can see the change looks identical.
I don't remember if it is identical or not. Basically it was postponed
to allow DSC to flow in. We used drm_panel to pass DSC pps data. And
if we use panel-bridge, we don't get a handle of the panel.
Later on I have posted the series moving DSC pps pointer from
drm_panel to mipi_dsi_device (which is logical anyway, since it's not
only the panel, who can provide the DSC pps info, some bridges can
process DSC-compressed data). But since that time it received no
feedback.
Thanks for the details.
I will try to review the DRM core bits. But I guess for them to land, we
need some of the core maintainers to pitch in on that.
Re: [Freedreno] [PATCH] drm/msm/dsi: Set panel orientation when directly connected
On Fri, 8 Jul 2022 at 22:42, Abhinav Kumar wrote:
>
>
>
> On 7/8/2022 9:00 AM, Abhinav Kumar wrote:
> >
> >
> > On 7/8/2022 8:25 AM, Doug Anderson wrote:
> >> Hi,
> >>
> >> On Wed, Jul 6, 2022 at 12:14 PM Stephen Boyd wrote:
> >>>
> >>> Set the panel orientation in drm when the panel is directly connected,
> >>> i.e. we're not using an external bridge. The external bridge case is
> >>> already handled by the panel bridge code, so we only update the path we
> >>> take when the panel is directly connected/internal. This silences a
> >>> warning splat coming from __drm_mode_object_add() on Wormdingler boards.
> >>>
> >>> Cc: Hsin-Yi Wang
> >>> Cc: Douglas Anderson
> >>> Signed-off-by: Stephen Boyd
> >>> ---
> >>>
> >>> This relies on commit 5e41b01a7808 ("drm/panel: Add an API to allow drm
> >>> to set orientation from panel") which is in drm-misc
> >>>
> >>> drivers/gpu/drm/msm/dsi/dsi_manager.c | 2 ++
> >>> 1 file changed, 2 insertions(+)
> >>
> >> I don't personally have objections to this, but (to my understanding)
> >> "the future" is that everyone should use panel_bridge. If we made the
> >> move to panel_bridge today then we wouldn't need to do this. In
> >> general I think panel_bridge would end up letting us delete a bunch of
> >> code...
> >>
> >> See commit 4e5763f03e10 ("drm/bridge: ti-sn65dsi86: Wrap panel with
> >> panel-bridge") for when this was done by ti-sn65dsi86.
> >>
> >> Then again, I spent a small amount of time looking into this and it's
> >> definitely non-trivial. Still likely worthwhile, but not worth
> >> blocking a tiny fix like this. It also should be fairly obvious that
> >> we should delete this when we switch to panel_bridge.
> >
> > Right, from what I saw on IRC, panel_bridge is the way forward and
> > dmitry did push a change to do that
> >
> > https://patchwork.freedesktop.org/patch/492585/
> >
> > But I think we can go ahead with this change because its simple enough.
> >
> > Regarding the panel_bridge migration, I am going to start reviewing that
> > as well.
> >
>
> I did some more digging up on the panel_bridge migration.
>
> Dmitry has posted this towards december last year
>
> https://patches.linaro.org/project/dri-devel/patch/20211207222901.988484-3-dmitry.barysh...@linaro.org/
>
>
> and I had given my R-b on this already in Jan.
>
> I am not sure why this change was dropped OR was not part of msm-next
> already.
>
> Dmitry, any reason this change was left out so long and why the R-b was
> not retained and this was reposted?
>
> From what i can see the change looks identical.
I don't remember if it is identical or not. Basically it was postponed
to allow DSC to flow in. We used drm_panel to pass DSC pps data. And
if we use panel-bridge, we don't get a handle of the panel.
Later on I have posted the series moving DSC pps pointer from
drm_panel to mipi_dsi_device (which is logical anyway, since it's not
only the panel, who can provide the DSC pps info, some bridges can
process DSC-compressed data). But since that time it received no
feedback.
--
With best wishes
Dmitry
Re: [Freedreno] [PATCH 1/9] dt-bindings: msm/dp: drop extra p1 region
On 7/8/2022 12:51 PM, Stephen Boyd wrote: Quoting Abhinav Kumar (2022-07-08 12:38:09) + kuogee On 7/8/2022 12:27 PM, Stephen Boyd wrote: Yes I see the same address for P1 on sc7280. Maybe it's a typo? Abhinav, can you confirm? P1 block does exist on sc7280 and yes its address is same as the address mentioned in sc7180. So its not a typo. Thanks! Yes, we are not programming this today but I would prefer to keep this as optional. I did sync up with Kuogee on this change this morning, we will check a few things internally on the P1 block's usage as to which use-cases we need to program it for and update here. The idea behind having this register space listed in the yaml is thats how the software documents have the blocks listed so dropping P1 block just because its unused seemed wrong to me. Optional seems more appropriate. It doesn't sound optional on sc7180 or sc7280. It exists in the hardware, so we should list the reg property. My understanding of optional properties is for the case where something could be different in the hardware design, like an optionally connected pin on a device. Ack, if thats the purpose of optional, then we should keep it and yes lets drop this change.
Re: [Freedreno] [PATCH 1/9] dt-bindings: msm/dp: drop extra p1 region
Quoting Abhinav Kumar (2022-07-08 12:38:09) > + kuogee > > On 7/8/2022 12:27 PM, Stephen Boyd wrote: > > > > Yes I see the same address for P1 on sc7280. Maybe it's a typo? Abhinav, > > can you confirm? > > P1 block does exist on sc7280 and yes its address is same as the address > mentioned in sc7180. So its not a typo. Thanks! > > Yes, we are not programming this today but I would prefer to keep this > as optional. > > I did sync up with Kuogee on this change this morning, we will check a > few things internally on the P1 block's usage as to which use-cases we > need to program it for and update here. > > The idea behind having this register space listed in the yaml is thats > how the software documents have the blocks listed so dropping P1 block > just because its unused seemed wrong to me. Optional seems more appropriate. > It doesn't sound optional on sc7180 or sc7280. It exists in the hardware, so we should list the reg property. My understanding of optional properties is for the case where something could be different in the hardware design, like an optionally connected pin on a device.
Re: [Freedreno] [PATCH 1/9] dt-bindings: msm/dp: drop extra p1 region
On 7/8/2022 12:38 PM, Abhinav Kumar wrote:
+ kuogee
On 7/8/2022 12:27 PM, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-07-07 20:46:43)
On 08/07/2022 04:28, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-07-07 14:31:56)
The p1 region was probably added by mistake, none of the DTS files
provides one (and the driver source code also doesn't use one).
Drop it
now.
Yes, looks like the driver doesn't use it.
Fixes: 687825c402f1 ("dt-bindings: msm/dp: Change reg definition")
Signed-off-by: Dmitry Baryshkov
---
Documentation/devicetree/bindings/display/msm/dp-controller.yaml |
1 -
1 file changed, 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
index 94bc6e1b6451..d6bbe58ef9e8 100644
---
a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+++
b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -29,7 +29,6 @@ properties:
- description: aux register block
- description: link register block
- description: p0 register block
- - description: p1 register block
The p1 registers exist on sc7180. They start where the example starts,
at 0xae91400.
Do they exist on e.g. sc7280? In other words, should we add the region
to the DTS? For now I'm going to mark it as optional.
Yes I see the same address for P1 on sc7280. Maybe it's a typo? Abhinav,
can you confirm?
P1 block does exist on sc7280 and yes its address is same as the
address mentioned in sc7180. So its not a typo.
Yes, we are not programming this today but I would prefer to keep this
as optional.
I did sync up with Kuogee on this change this morning, we will check a
few things internally on the P1 block's usage as to which use-cases we
need to program it for and update here.
P1 block is for dp MST application. This allow two dp streams can be
mux into same DP phy.
We should keep it since we may support MST later.
The idea behind having this register space listed in the yaml is thats
how the software documents have the blocks listed so dropping P1 block
just because its unused seemed wrong to me. Optional seems more
appropriate.
Thanks
Abhinav
Re: [Freedreno] [PATCH] drm/msm/dsi: Set panel orientation when directly connected
On 7/8/2022 9:00 AM, Abhinav Kumar wrote:
On 7/8/2022 8:25 AM, Doug Anderson wrote:
Hi,
On Wed, Jul 6, 2022 at 12:14 PM Stephen Boyd wrote:
Set the panel orientation in drm when the panel is directly connected,
i.e. we're not using an external bridge. The external bridge case is
already handled by the panel bridge code, so we only update the path we
take when the panel is directly connected/internal. This silences a
warning splat coming from __drm_mode_object_add() on Wormdingler boards.
Cc: Hsin-Yi Wang
Cc: Douglas Anderson
Signed-off-by: Stephen Boyd
---
This relies on commit 5e41b01a7808 ("drm/panel: Add an API to allow drm
to set orientation from panel") which is in drm-misc
drivers/gpu/drm/msm/dsi/dsi_manager.c | 2 ++
1 file changed, 2 insertions(+)
I don't personally have objections to this, but (to my understanding)
"the future" is that everyone should use panel_bridge. If we made the
move to panel_bridge today then we wouldn't need to do this. In
general I think panel_bridge would end up letting us delete a bunch of
code...
See commit 4e5763f03e10 ("drm/bridge: ti-sn65dsi86: Wrap panel with
panel-bridge") for when this was done by ti-sn65dsi86.
Then again, I spent a small amount of time looking into this and it's
definitely non-trivial. Still likely worthwhile, but not worth
blocking a tiny fix like this. It also should be fairly obvious that
we should delete this when we switch to panel_bridge.
Right, from what I saw on IRC, panel_bridge is the way forward and
dmitry did push a change to do that
https://patchwork.freedesktop.org/patch/492585/
But I think we can go ahead with this change because its simple enough.
Regarding the panel_bridge migration, I am going to start reviewing that
as well.
I did some more digging up on the panel_bridge migration.
Dmitry has posted this towards december last year
https://patches.linaro.org/project/dri-devel/patch/20211207222901.988484-3-dmitry.barysh...@linaro.org/
and I had given my R-b on this already in Jan.
I am not sure why this change was dropped OR was not part of msm-next
already.
Dmitry, any reason this change was left out so long and why the R-b was
not retained and this was reposted?
From what i can see the change looks identical.
Thanks
Abhinav
Thus:
Reviewed-by: Douglas Anderson
I'll assume that we'll just snooze this commit until drm-misc-next
merges into a tree that msm-next is based on, which will probably be
the next -rc1. If desired and Acked I could land this in
drm-misc-next, but it's probably not worth it?
Re: [Freedreno] [PATCH 1/9] dt-bindings: msm/dp: drop extra p1 region
+ kuogee
On 7/8/2022 12:27 PM, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-07-07 20:46:43)
On 08/07/2022 04:28, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-07-07 14:31:56)
The p1 region was probably added by mistake, none of the DTS files
provides one (and the driver source code also doesn't use one). Drop it
now.
Yes, looks like the driver doesn't use it.
Fixes: 687825c402f1 ("dt-bindings: msm/dp: Change reg definition")
Signed-off-by: Dmitry Baryshkov
---
Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
index 94bc6e1b6451..d6bbe58ef9e8 100644
--- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
@@ -29,7 +29,6 @@ properties:
- description: aux register block
- description: link register block
- description: p0 register block
- - description: p1 register block
The p1 registers exist on sc7180. They start where the example starts,
at 0xae91400.
Do they exist on e.g. sc7280? In other words, should we add the region
to the DTS? For now I'm going to mark it as optional.
Yes I see the same address for P1 on sc7280. Maybe it's a typo? Abhinav,
can you confirm?
P1 block does exist on sc7280 and yes its address is same as the address
mentioned in sc7180. So its not a typo.
Yes, we are not programming this today but I would prefer to keep this
as optional.
I did sync up with Kuogee on this change this morning, we will check a
few things internally on the P1 block's usage as to which use-cases we
need to program it for and update here.
The idea behind having this register space listed in the yaml is thats
how the software documents have the blocks listed so dropping P1 block
just because its unused seemed wrong to me. Optional seems more appropriate.
Thanks
Abhinav
Re: [Freedreno] [PATCH 1/9] dt-bindings: msm/dp: drop extra p1 region
Quoting Dmitry Baryshkov (2022-07-07 20:46:43)
> On 08/07/2022 04:28, Stephen Boyd wrote:
> > Quoting Dmitry Baryshkov (2022-07-07 14:31:56)
> >> The p1 region was probably added by mistake, none of the DTS files
> >> provides one (and the driver source code also doesn't use one). Drop it
> >> now.
> >
> > Yes, looks like the driver doesn't use it.
> >
> >>
> >> Fixes: 687825c402f1 ("dt-bindings: msm/dp: Change reg definition")
> >> Signed-off-by: Dmitry Baryshkov
> >> ---
> >> Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 1 -
> >> 1 file changed, 1 deletion(-)
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> >> b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> >> index 94bc6e1b6451..d6bbe58ef9e8 100644
> >> --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> >> +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml
> >> @@ -29,7 +29,6 @@ properties:
> >> - description: aux register block
> >> - description: link register block
> >> - description: p0 register block
> >> - - description: p1 register block
> >
> > The p1 registers exist on sc7180. They start where the example starts,
> > at 0xae91400.
>
> Do they exist on e.g. sc7280? In other words, should we add the region
> to the DTS? For now I'm going to mark it as optional.
>
Yes I see the same address for P1 on sc7280. Maybe it's a typo? Abhinav,
can you confirm?
Re: [Freedreno] [PATCH 5/9] dt-bindings: msm/dp: account for clocks specific for qcom, sc7280-edp
Quoting Dmitry Baryshkov (2022-07-07 20:59:02) > On 08/07/2022 04:32, Stephen Boyd wrote: > > Quoting Dmitry Baryshkov (2022-07-07 14:32:00) > >> diff --git > >> a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > >> b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > >> index f00eae66196f..1ef845005b14 100644 > >> --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > >> +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml > >> @@ -119,6 +111,50 @@ required: > >> - power-domains > >> - ports > >> > >> +allOf: > >> + - if: > >> + properties: > >> +compatible: > >> + contains: > >> +enum: > >> + - qcom,sc7280-edp > >> +then: > >> + properties: > >> +clocks: > >> + items: > >> +- description: XO clock > > > > What is this for? I would guess it's for the eDP phy, but that isn't > > part of the eDP controller, so probably it can be removed. > > Good question. I was documenting what is present in the sc7280-edp > controller DT entry. Could you please check if we can drop them? I don't > have the hardware at hand. > eDP works fine without those two clks on CRD (hoglin). They can be dropped from the dtsi file.
[Freedreno] [PATCH] drm/msm/gpu: Drop qos request if devm_devfreq_add_device() fails
In the event that devm_devfreq_add_device() fails the device's qos freq
list is left referencing df->idle_freq and df->boost_freq. Attempting to
initialize devfreq again after a probe deferral will then cause invalid
memory accesses in dev_pm_qos_add_request().
Fix this by dropping the requests in the error path.
Fixes: 7c0ffcd40b16 ("drm/msm/gpu: Respect PM QoS constraints")
Signed-off-by: Bjorn Andersson
---
drivers/gpu/drm/msm/msm_gpu_devfreq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_gpu_devfreq.c
b/drivers/gpu/drm/msm/msm_gpu_devfreq.c
index c2ea978c8921..21e271a318ee 100644
--- a/drivers/gpu/drm/msm/msm_gpu_devfreq.c
+++ b/drivers/gpu/drm/msm/msm_gpu_devfreq.c
@@ -198,6 +198,8 @@ void msm_devfreq_init(struct msm_gpu *gpu)
if (IS_ERR(df->devfreq)) {
DRM_DEV_ERROR(>pdev->dev, "Couldn't initialize GPU
devfreq\n");
+ dev_pm_qos_remove_request(>idle_freq);
+ dev_pm_qos_remove_request(>boost_freq);
df->devfreq = NULL;
return;
}
--
2.35.1
Re: [Freedreno] [PATCH RESEND] drm/msm/dsi: fix the inconsistent indenting
On 7/7/2022 5:58 PM, sunliming wrote:
Fix the inconsistent indenting in function msm_dsi_dphy_timing_calc_v3().
Fix the following smatch warnings:
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c:350 msm_dsi_dphy_timing_calc_v3() warn:
inconsistent indenting
Reported-by: kernel test robot
Signed-off-by: sunliming
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index a39de3bdc7fa..56dfa2d24be1 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -347,7 +347,7 @@ int msm_dsi_dphy_timing_calc_v3(struct msm_dsi_dphy_timing
*timing,
} else {
timing->shared_timings.clk_pre =
linear_inter(tmax, tmin, pcnt2, 0, false);
- timing->shared_timings.clk_pre_inc_by_2 = 0;
+ timing->shared_timings.clk_pre_inc_by_2 = 0;
}
timing->ta_go = 3;
Re: [Freedreno] [PATCH] drm/msm/dsi: Set panel orientation when directly connected
On 7/8/2022 8:25 AM, Doug Anderson wrote:
Hi,
On Wed, Jul 6, 2022 at 12:14 PM Stephen Boyd wrote:
Set the panel orientation in drm when the panel is directly connected,
i.e. we're not using an external bridge. The external bridge case is
already handled by the panel bridge code, so we only update the path we
take when the panel is directly connected/internal. This silences a
warning splat coming from __drm_mode_object_add() on Wormdingler boards.
Cc: Hsin-Yi Wang
Cc: Douglas Anderson
Signed-off-by: Stephen Boyd
---
This relies on commit 5e41b01a7808 ("drm/panel: Add an API to allow drm
to set orientation from panel") which is in drm-misc
drivers/gpu/drm/msm/dsi/dsi_manager.c | 2 ++
1 file changed, 2 insertions(+)
I don't personally have objections to this, but (to my understanding)
"the future" is that everyone should use panel_bridge. If we made the
move to panel_bridge today then we wouldn't need to do this. In
general I think panel_bridge would end up letting us delete a bunch of
code...
See commit 4e5763f03e10 ("drm/bridge: ti-sn65dsi86: Wrap panel with
panel-bridge") for when this was done by ti-sn65dsi86.
Then again, I spent a small amount of time looking into this and it's
definitely non-trivial. Still likely worthwhile, but not worth
blocking a tiny fix like this. It also should be fairly obvious that
we should delete this when we switch to panel_bridge.
Right, from what I saw on IRC, panel_bridge is the way forward and
dmitry did push a change to do that
https://patchwork.freedesktop.org/patch/492585/
But I think we can go ahead with this change because its simple enough.
Regarding the panel_bridge migration, I am going to start reviewing that
as well.
Thus:
Reviewed-by: Douglas Anderson
I'll assume that we'll just snooze this commit until drm-misc-next
merges into a tree that msm-next is based on, which will probably be
the next -rc1. If desired and Acked I could land this in
drm-misc-next, but it's probably not worth it?
Re: [Freedreno] [PATCH] drm/msm/dsi: Set panel orientation when directly connected
Hi,
On Wed, Jul 6, 2022 at 12:14 PM Stephen Boyd wrote:
>
> Set the panel orientation in drm when the panel is directly connected,
> i.e. we're not using an external bridge. The external bridge case is
> already handled by the panel bridge code, so we only update the path we
> take when the panel is directly connected/internal. This silences a
> warning splat coming from __drm_mode_object_add() on Wormdingler boards.
>
> Cc: Hsin-Yi Wang
> Cc: Douglas Anderson
> Signed-off-by: Stephen Boyd
> ---
>
> This relies on commit 5e41b01a7808 ("drm/panel: Add an API to allow drm
> to set orientation from panel") which is in drm-misc
>
> drivers/gpu/drm/msm/dsi/dsi_manager.c | 2 ++
> 1 file changed, 2 insertions(+)
I don't personally have objections to this, but (to my understanding)
"the future" is that everyone should use panel_bridge. If we made the
move to panel_bridge today then we wouldn't need to do this. In
general I think panel_bridge would end up letting us delete a bunch of
code...
See commit 4e5763f03e10 ("drm/bridge: ti-sn65dsi86: Wrap panel with
panel-bridge") for when this was done by ti-sn65dsi86.
Then again, I spent a small amount of time looking into this and it's
definitely non-trivial. Still likely worthwhile, but not worth
blocking a tiny fix like this. It also should be fairly obvious that
we should delete this when we switch to panel_bridge.
Thus:
Reviewed-by: Douglas Anderson
I'll assume that we'll just snooze this commit until drm-misc-next
merges into a tree that msm-next is based on, which will probably be
the next -rc1. If desired and Acked I could land this in
drm-misc-next, but it's probably not worth it?
