> -----Original Message----- > From: Sasha Levin <sashal@xxxxxxxxxx> > Sent: Monday, October 8, 2018 10:49 AM > To: Deucher, Alexander <Alexander.Deucher@xxxxxxx> > Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>; linux- > kernel@xxxxxxxxxxxxxxx; stable@xxxxxxxxxxxxxxx; Wentland, Harry > <Harry.Wentland@xxxxxxx>; Zhu, Rex <Rex.Zhu@xxxxxxx>; Sasha Levin > <alexander.levin@xxxxxxxxxxxxx> > Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC > for smu7/8 > > On Mon, Oct 08, 2018 at 02:33:56PM +0000, Deucher, Alexander wrote: > >> -----Original Message----- > >> From: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> > >> Sent: Monday, September 24, 2018 7:53 AM > >> To: linux-kernel@xxxxxxxxxxxxxxx > >> Cc: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>; > >> stable@xxxxxxxxxxxxxxx; Wentland, Harry <Harry.Wentland@xxxxxxx>; > >> Deucher, Alexander <Alexander.Deucher@xxxxxxx>; Zhu, Rex > >> <Rex.Zhu@xxxxxxx>; Sasha Levin <alexander.levin@xxxxxxxxxxxxx> > >> Subject: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC > >> for > >> smu7/8 > >> > >> 4.18-stable review patch. If anyone has any objections, please let me > know. > >> > > > >This regresses power usage on 4.18. Please revert. > >https://bugzilla.kernel.org/show_bug.cgi?id=201275 > > Hi Alex, > > Thank you for the report. > > I'm working on improving this process, I'd be very grateful if you could > answer a few questions about this: > > 1. Is the same breakage seen upstream? (if so, it should be reverted there as > well and we can grab the revert into -stable). No regression in 4.19 or -next. > 2. Does the issue reported by this patch ("pipes seem to hang with a 4k DP > and 1080p HDMI display") exist in the 4.18 stable tree? I don't think so, but I'm not 100% sure. Harry, Rex do you know if this is a general issue or was it just fall out from the changes to the interface? > 3. If not, could you briefly explain why? We refactored the interface between the power and display components and this patch fixed up some of that fallout due to the differences in units used in each component. > > > The algorithm I use was very confident about this patch being stable material, > and when I looked at it back then (and again now) I was very confident of the > same. If I can understand where I was wrong I could improve my process. There are some other dependent patches required that were not flagged in the patch itself. IIRC, they were a bit big for stable. Alex
