Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   "Deucher, Alexander" <Alexander.Deucher@amd.com>
To:     Sasha Levin <sashal@kernel.org>
CC:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "stable@vger.kernel.org" <stable@vger.kernel.org>,
        "Wentland, Harry" <Harry.Wentland@amd.com>,
        "Zhu, Rex" <Rex.Zhu@amd.com>,
        Sasha Levin <alexander.levin@microsoft.com>
Subject: RE: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for
 smu7/8
Thread-Topic: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC for
 smu7/8
Thread-Index: AQHUVARg2MOAZvRixUSipQEGskb4iKUVfsWAgAAFX4CAABRr8A==
Date:   Mon, 8 Oct 2018 16:17:46 +0000
Message-ID: <BN6PR12MB1809FA86B039B8EAE460BB49F7E60@BN6PR12MB1809.namprd12.prod.outlook.com>
References: <20180924113103.999624566@linuxfoundation.org>
 <20180924113125.488862921@linuxfoundation.org>
 <BN6PR12MB18092FFEF5BB3861912C8535F7E60@BN6PR12MB1809.namprd12.prod.outlook.com>
 <20181008144917.GE32006@sasha-vm>
In-Reply-To: <20181008144917.GE32006@sasha-vm>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: amd.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0a4c294b-c08f-4b8f-154c-08d62d39957a
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2018 16:17:46.2133
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR12MB1747
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> -----Original Message-----
> From: Sasha Levin <sashal@kernel.org>
> Sent: Monday, October 8, 2018 10:49 AM
> To: Deucher, Alexander <Alexander.Deucher@amd.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>; linux-
> kernel@vger.kernel.org; stable@vger.kernel.org; Wentland, Harry
> <Harry.Wentland@amd.com>; Zhu, Rex <Rex.Zhu@amd.com>; Sasha Levin
> <alexander.levin@microsoft.com>
> Subject: Re: [PATCH 4.18 222/235] drm/amd/pp: Send khz clock values to DC
> for smu7/8
>=20
> On Mon, Oct 08, 2018 at 02:33:56PM +0000, Deucher, Alexander wrote:
> >> -----Original Message-----
> >> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >> Sent: Monday, September 24, 2018 7:53 AM
> >> To: linux-kernel@vger.kernel.org
> >> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>;
> >> stable@vger.kernel.org; Wentland, Harry <Harry.Wentland@amd.com>;
> >> Deucher, Alexander <Alexander.Deucher@amd.com>; Zhu, Rex
> >> <Rex.Zhu@amd.com>; Sasha Levin <alexander.levin@microsoft.com>
> >> 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=3D201275
>=20
> Hi Alex,
>=20
> Thank you for the report.
>=20
> I'm working on improving this process, I'd be very grateful if you could
> answer a few questions about this:
>=20
> 1. Is the same breakage seen upstream? (if so, it should be reverted ther=
e 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 D=
P
> 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 th=
is patch fixed up some of that fallout due to the differences in units used=
 in each component.

>=20
>=20
> The algorithm I use was very confident about this patch being stable mate=
rial,
> 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 th=
e patch itself.  IIRC, they were a bit big for stable.

Alex