[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230213151413.qhpzzcz4c6m6rynk@SoMainline.org>
Date: Mon, 13 Feb 2023 16:14:13 +0100
From: Marijn Suijten <marijn.suijten@...ainline.org>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: Konrad Dybcio <konrad.dybcio@...aro.org>,
linux-arm-msm@...r.kernel.org, andersson@...nel.org,
agross@...nel.org, krzysztof.kozlowski@...aro.org,
Konrad Dybcio <konrad.dybcio@...ainline.org>,
Rob Clark <robdclark@...il.com>,
Abhinav Kumar <quic_abhinavk@...cinc.com>,
Sean Paul <sean@...rly.run>, David Airlie <airlied@...il.com>,
Daniel Vetter <daniel@...ll.ch>,
Robert Foss <rfoss@...nel.org>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@...ainline.org>,
Vinod Koul <vkoul@...nel.org>,
Vinod Polimera <quic_vpolimer@...cinc.com>,
Stephen Boyd <swboyd@...omium.org>,
Liu Shixin <liushixin2@...wei.com>,
dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 06/10] drm/msm/dpu: Add SM6350 support
On 2023-02-13 16:58:00, Dmitry Baryshkov wrote:
> 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.
The catalog part is ready [1] and was rebased on -next a "week" ago, and
does not depend on any of the SM6125/6350/75 series. All that remains
is addressing review comments regarding restructuring function and
function pointer layout.
[1]: https://github.com/SoMainline/linux/commits/marijn/dpu/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> 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.
Ack, totally agree here, massive rebase conflict nightmare not to
mention fixups/followups.
> > 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.
Sounds good.
> We are still waiting for DSC 1.2 v2,
> but it definitely will take time to mature even if v2 is posted today.
That'll hit the catalog to a minimal extent (I guess, to describe new
blocks / with a feature flag) but should be easy to delay / rebase.
> 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.
Ack, I'll get to that immediately. You might even pull in the
intermediate patches linked above (that touch the catalog) to see how it
integrates, if I remember correctly (it has been a while) the catalog
changes should now be independent of driver changes...?
> > 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.
Ack; will try providing feedback on the 50-patch series via email in
parallel to getting INTF TE v2 out ASAP. As discussed before I should
probably add myself as reviewer to the drm/msm subsystem to have these
patches in my inbox from the get-go though...
- Marijn
Powered by blists - more mailing lists