On Mon, Jun 12, 2023 at 09:30:30AM +0200, Henning Schild wrote: > Am Wed, 7 Jun 2023 20:09:58 +0200 > schrieb Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>: > > > On Fri, Jun 02, 2023 at 06:05:06PM +0200, Henning Schild wrote: > > > From: Matt Roper <matthew.d.roper@xxxxxxxxx> > > > > > > From: Matt Roper <matthew.d.roper@xxxxxxxxx> > > > > Twice? > > > > > > > > [ Upstream commit f9c730ede7d3f40900cb493890d94d868ff2f00f ] > > > > > > DG1 does some additional pcode/uncore handshaking at > > > boot time; this handshaking must complete before various other pcode > > > commands are effective and before general work is submitted to the > > > GPU. We need to poll a new pcode mailbox during startup until it > > > reports that this handshaking is complete. > > > > > > The bspec doesn't give guidance on how long we may need to wait for > > > this handshaking to complete. For now, let's just set a really > > > long timeout; if we still don't get a completion status by the end > > > of that timeout, we'll just continue on and hope for the best. > > > > > > v2 (Lucas): Rename macros to make clear the relation between > > > command and result (requested by José) > > > > > > Bspec: 52065 > > > Cc: Clinton Taylor <Clinton.A.Taylor@xxxxxxxxx> > > > Cc: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > Cc: Radhakrishna Sripada <radhakrishna.sripada@xxxxxxxxx> > > > Signed-off-by: Matt Roper <matthew.d.roper@xxxxxxxxx> > > > Signed-off-by: Lucas De Marchi <lucas.demarchi@xxxxxxxxx> > > > Reviewed-by: José Roberto de Souza <jose.souza@xxxxxxxxx> > > > Link: > > > https://patchwork.freedesktop.org/patch/msgid/20201001063917.3133475-2-lucas.demarchi@xxxxxxxxx > > > > > > > You also need to sign-off on a patch you submit for inclusion > > anywhere, right? > > I was not sure that was needed for a backport, but will add it once i > resend. > > > Please resend this series with that added so that we can queue them > > up. > > Will do. > > Matt would you agree? As i said i just googled/bisected and found this > one and it seems to help. But you seem to say that it does not fit. I > am guessing the patch might not be as atomic as could be, that is why > backporting it helps. Sorry for the slow response; I've been traveling and am just catching up on email now. Since you're running on a platform with integrated graphics, this patch can't have any functional impact. The function added in this patch only does something on discrete GPU platforms; on all others it bails out immediately: + if (!IS_DGFX(i915)) + return; The only Intel discrete devices that return true from IS_DGFX are DG1, DG2, and PVC, none of which were supported yet on the 5.10 kernel. The dmesg splat you pasted in your cover letter is coming from the DRAM detection code, which is what the other patch in your series ("drm/i915/gen11+: Only load DRAM information from pcode") is dealing with. So I think that other patch is the only one you should need; this pcode one isn't having any effect. Matt > > Henning > > > thanks, > > > > greg k-h > -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
