Re: [PATCH 06/10] drm/msm/dpu: Add SM6350 support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 13/02/2023 16:28, Marijn Suijten wrote:
On 2023-02-13 13:35:01, Dmitry Baryshkov wrote:
On 13/02/2023 13:30, Marijn Suijten wrote:
On 2023-02-13 12:15:19, Konrad Dybcio wrote:
[...]
@@ -1674,6 +1765,15 @@ static struct dpu_pingpong_cfg sc8280xp_pp[] = {
              DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 31), -1),
    };
    +static struct dpu_pingpong_cfg sm6350_pp[] = {
+    PP_BLK("pingpong_0", PINGPONG_0, 0x70000, 0, sdm845_pp_sblk,

No TE support?
It's.. complicated.. With just this patch, display refreshes, albeit
not at 60fps. Marijn is working on getting it going, though

https://github.com/SoMainline/linux/commits/marijn/longbois-next/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c

This branch hasn't been updated for the longest time.  I'm preparing v2
of the INTF TE series at:

https://github.com/SoMainline/linux/commits/marijn/dpu/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c

and it has about ±40% of Dmitry's review applied.  More to come now that
hiatus is over.

We should agree on landing order for my rework vs your changes. Can I
try persuading you to review that 50-patches beast? With the hope that
you'd agree to land your changes on top of it?

SM6115 unexpectedly landing in advance of SM8[345]0 was already an
unnecessary headache to deal with, and now we're "changing direction" on
landing SM6350/75 in advance of INTF TE too...  not to forget about
SM6125 which I also keep rebasing locally but planned on landing _after_
INTF TE.  Regardless of the extra effort it will take from me I'd be
happy to land my patches after everyone else's to have final say over
which setup gets what bitflags and interrupts, as these typically got
botched in our trees after rebases leading to broken INTF TE.
Perhaps I should resubmit the individual Fixes: commits though?

What is the current status of your INTF TE patchset? If it's mostly ready, I can rebase my patch-bomb on top of it.

I definitely do not want to merge new platforms before sorting out INTF TE and the catalog. Handling sc8280xp, sm8350, sm8450 and sm6115 was a nightmare. The restructure targets making addition of new platforms simpler.

Feel free to propose a merge order listing all the aforementioned SoCs,
your rework, my INTF TE patches and whatever else is in the pipeline.
As I've been away for a while, and only have limited hobby time (_and_
have to split that on various projects), I'm behind on what's currently
in swing for DPU (need additional time to catch back up) nor will be
able to rebase/resubmit my patches often (a set-in-stone merge order
will really help prioritise/plan ahead here).

We have several patchsets in the pipeline (PSR, color-transformation rework, wide planes) which do not touch the catalog, so the amount of conflicts should be pretty minimal. We are still waiting for DSC 1.2 v2, but it definitely will take time to mature even if v2 is posted today.

So, *possible* the merge order is the following:
- fixes from https://patchwork.freedesktop.org/series/113910/ go to msm-fixes
- fixes from your intf-te go to msm-fixes
- https://patchwork.freedesktop.org/series/111751/
- the rest of intf-te and catalog (*see below)
- DPU features
- new DPU platforms (might go together with DPU features)

* That really depends on the availability of the patchsets. Most probably, as your patchset also contains several fixups, it would be easier to land it before catalog split/rework.

So, if you have the available timeslot, could you please finish & send intf te on top of msm-next.

Sure, I will at least start looking at your 50-patch as part of catching
back up.  Do you want to process that on the mailing list or via
https://gitlab.freedesktop.org/drm/msm/-/merge_requests/44?

I'd prefer to use email. The MR was open to doublecheck that nothing got broken on sc7180.

--
With best wishes
Dmitry




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux