Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220919105839.496f1b72@canb.auug.org.au>
In-Reply-To: <20220919105839.496f1b72@canb.auug.org.au>
From:   Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Mon, 19 Sep 2022 09:58:01 +0200
Message-ID: <CAMuHMdVQmG6hjyw0g8L2AAuUSoQ9xH=C9zrV=QUoVWp_HM62BQ@mail.gmail.com>
Subject: Re: linux-next: manual merge of the drm tree with Linus' tree
To:     Stephen Rothwell <sfr@canb.auug.org.au>
Cc:     Dave Airlie <airlied@redhat.com>,
        DRI <dri-devel@lists.freedesktop.org>,
        Alex Deucher <alexander.deucher@amd.com>,
        Hamza Mahfooz <hamza.mahfooz@amd.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux Next Mailing List <linux-next@vger.kernel.org>,
        Nathan Chancellor <nathan@kernel.org>,
        Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Stephen,

On Mon, Sep 19, 2022 at 3:07 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Today's linux-next merge of the drm tree got a conflict in:
>
>   drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
>
> between commit:
>
>   41012d715d5d ("drm/amd/display: Mark dml30's UseMinimumDCFCLK() as noinline for stack usage")
>
> from Linus' tree and commit:
>
>   a0f7e7f759cf ("drm/amd/display: fix i386 frame size warning")
>
> from the drm tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
> index 1cb858dd6ea0,b7fa003ffe06..000000000000
> --- a/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
> +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
> @@@ -6610,66 -6497,11 +6497,11 @@@ static double CalculateUrgentLatency
>         return ret;
>   }
>
>  -static void UseMinimumDCFCLK(
>  +static noinline_for_stack void UseMinimumDCFCLK(

While this looks like the correct merge resolution, it does mean that
both stack size mitigations are now applied, and probably one of them
can be dropped?

>                 struct display_mode_lib *mode_lib,
> -               int MaxInterDCNTileRepeaters,
> +               struct vba_vars_st *v,
>                 int MaxPrefetchMode,
> -               double FinalDRAMClockChangeLatency,
> -               double SREnterPlusExitTime,
> -               int ReturnBusWidth,
> -               int RoundTripPingLatencyCycles,
> -               int ReorderingBytes,
> -               int PixelChunkSizeInKByte,
> -               int MetaChunkSize,
> -               bool GPUVMEnable,
> -               int GPUVMMaxPageTableLevels,
> -               bool HostVMEnable,
> -               int NumberOfActivePlanes,
> -               double HostVMMinPageSize,
> -               int HostVMMaxNonCachedPageTableLevels,
> -               bool DynamicMetadataVMEnabled,
> -               enum immediate_flip_requirement ImmediateFlipRequirement,
> -               bool ProgressiveToInterlaceUnitInOPP,
> -               double MaxAveragePercentOfIdealSDPPortBWDisplayCanUseInNormalSystemOperation,
> -               double PercentOfIdealDRAMFabricAndSDPPortBWReceivedAfterUrgLatencyPixelMixedWithVMData,
> -               double PercentOfIdealDRAMFabricAndSDPPortBWReceivedAfterUrgLatencyVMDataOnly,
> -               double PercentOfIdealDRAMFabricAndSDPPortBWReceivedAfterUrgLatencyPixelDataOnly,
> -               int VTotal[],
> -               int VActive[],
> -               int DynamicMetadataTransmittedBytes[],
> -               int DynamicMetadataLinesBeforeActiveRequired[],
> -               bool Interlace[],
> -               double RequiredDPPCLK[][2][DC__NUM_DPP__MAX],
> -               double RequiredDISPCLK[][2],
> -               double UrgLatency[],
> -               unsigned int NoOfDPP[][2][DC__NUM_DPP__MAX],
> -               double ProjectedDCFCLKDeepSleep[][2],
> -               double MaximumVStartup[][2][DC__NUM_DPP__MAX],
> -               double TotalVActivePixelBandwidth[][2],
> -               double TotalVActiveCursorBandwidth[][2],
> -               double TotalMetaRowBandwidth[][2],
> -               double TotalDPTERowBandwidth[][2],
> -               unsigned int TotalNumberOfActiveDPP[][2],
> -               unsigned int TotalNumberOfDCCActiveDPP[][2],
> -               int dpte_group_bytes[],
> -               double PrefetchLinesY[][2][DC__NUM_DPP__MAX],
> -               double PrefetchLinesC[][2][DC__NUM_DPP__MAX],
> -               unsigned int swath_width_luma_ub_all_states[][2][DC__NUM_DPP__MAX],
> -               unsigned int swath_width_chroma_ub_all_states[][2][DC__NUM_DPP__MAX],
> -               int BytePerPixelY[],
> -               int BytePerPixelC[],
> -               int HTotal[],
> -               double PixelClock[],
> -               double PDEAndMetaPTEBytesPerFrame[][2][DC__NUM_DPP__MAX],
> -               double DPTEBytesPerRow[][2][DC__NUM_DPP__MAX],
> -               double MetaRowBytes[][2][DC__NUM_DPP__MAX],
> -               bool DynamicMetadataEnable[],
> -               double VActivePixelBandwidth[][2][DC__NUM_DPP__MAX],
> -               double VActiveCursorBandwidth[][2][DC__NUM_DPP__MAX],
> -               double ReadBandwidthLuma[],
> -               double ReadBandwidthChroma[],
> -               double DCFCLKPerState[],
> -               double DCFCLKState[][2])
> +               int ReorderingBytes)
>   {
>         double   NormalEfficiency = 0;
>         double   PTEEfficiency = 0;

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds