dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	DRI <dri-devel@lists.freedesktop.org>,
	Nathan Chancellor <nathan@kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Hamza Mahfooz <hamza.mahfooz@amd.com>,
	Alex Deucher <alexander.deucher@amd.com>,
	Dave Airlie <airlied@redhat.com>
Subject: Re: linux-next: manual merge of the drm tree with Linus' tree
Date: Mon, 19 Sep 2022 09:58:01 +0200	[thread overview]
Message-ID: <CAMuHMdVQmG6hjyw0g8L2AAuUSoQ9xH=C9zrV=QUoVWp_HM62BQ@mail.gmail.com> (raw)
In-Reply-To: <20220919105839.496f1b72@canb.auug.org.au>

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

  reply	other threads:[~2022-09-19  7:58 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-19  0:58 linux-next: manual merge of the drm tree with Linus' tree Stephen Rothwell
2022-09-19  7:58 ` Geert Uytterhoeven [this message]
2022-09-19 14:23   ` Nathan Chancellor
  -- strict thread matches above, loose matches on Subject: below --
2024-03-04  1:08 Stephen Rothwell
2024-03-04  0:47 Stephen Rothwell
2024-01-08  0:14 Stephen Rothwell
2023-06-19  1:17 Stephen Rothwell
2022-11-30 22:57 Stephen Rothwell
2022-11-27 23:58 Stephen Rothwell
2022-11-29  9:07 ` Geert Uytterhoeven
2022-11-17  2:13 Stephen Rothwell
2022-02-28  3:17 Stephen Rothwell
2021-10-29  0:48 Stephen Rothwell
2021-10-29  6:52 ` Joonas Lahtinen
2021-10-11  0:37 Stephen Rothwell
2021-08-23  2:41 Stephen Rothwell
2021-08-24  0:12 ` Stephen Rothwell
2021-08-12  1:20 Stephen Rothwell
2021-07-01  0:52 Stephen Rothwell
2021-03-29  2:14 Stephen Rothwell
2021-03-30  7:36 ` Geert Uytterhoeven
2021-03-30 23:41   ` Stephen Rothwell
2021-02-01  1:30 Stephen Rothwell
2021-02-14 22:07 ` Stephen Rothwell
2021-01-18  0:56 Stephen Rothwell
2020-10-02  3:42 Stephen Rothwell
2020-05-25  3:51 Stephen Rothwell
2020-03-23  0:50 Stephen Rothwell
2019-11-13  1:38 Stephen Rothwell
2019-11-13  1:38 ` Stephen Rothwell
2019-11-13  1:13 Stephen Rothwell
2019-11-13  1:13 ` Stephen Rothwell
2019-11-13  0:58 Stephen Rothwell
2019-11-13  0:58 ` Stephen Rothwell
2019-11-13  0:50 Stephen Rothwell
2019-11-13  0:50 ` Stephen Rothwell
2019-11-13  0:46 Stephen Rothwell
2019-11-13  0:46 ` Stephen Rothwell
2019-11-13  0:40 Stephen Rothwell
2019-11-13  0:40 ` Stephen Rothwell
2019-08-26  3:12 Stephen Rothwell
2019-06-11  2:19 Stephen Rothwell
2018-06-04  3:09 Stephen Rothwell
2018-03-26  3:38 Stephen Rothwell
2018-03-22  6:37 Stephen Rothwell
2018-03-26  3:45 ` Stephen Rothwell
2018-03-13  1:15 Stephen Rothwell
2018-02-18 23:10 Stephen Rothwell
2018-02-20 20:15 ` Rodrigo Vivi
2018-02-18 23:02 Stephen Rothwell
2018-01-15  1:08 Stephen Rothwell
2017-11-23 23:37 Stephen Rothwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMuHMdVQmG6hjyw0g8L2AAuUSoQ9xH=C9zrV=QUoVWp_HM62BQ@mail.gmail.com' \
    --to=geert@linux-m68k.org \
    --cc=Rodrigo.Siqueira@amd.com \
    --cc=airlied@redhat.com \
    --cc=alexander.deucher@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hamza.mahfooz@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=nathan@kernel.org \
    --cc=sfr@canb.auug.org.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).