Received: by 2002:a17:90b:8d0:0:0:0:0 with SMTP id ds16csp4871067pjb; Mon, 27 Jul 2020 07:16:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz4M3oY5coD75UOXB7aqIKlL7S+kk0Xvww8wRJ8QQVp0z6392AzRNr0U4q/q5/Xf5647BwY X-Received: by 2002:a17:906:3756:: with SMTP id e22mr6658492ejc.487.1595859396515; Mon, 27 Jul 2020 07:16:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595859396; cv=none; d=google.com; s=arc-20160816; b=SU6MxVQoEN32PmeUh5UiMxkBownbZSiIaK4STrBBIi4WSc5St49KZIZqcfn6Bj8Bdk 39CaptnZJUd7R/joDqC1SydX9Gq7uMXu6UAOH4nLWMjavh+dn9p6HYkUqY6oA2j9xuwC 2kusRv6ELmZ2xRLZ98yuxZoEgGNgdqUDW5lDC2p0QdY1J5jwqVAmRmCvgazrkaj84zvX 0xs2D63Rfm5Y1rGLpDHE0rkM+00Cp15GPuZ9pQSjqnbkMDkGLo08Y56XE018/L6r7iFh lGx+Kgq4GGL/6rXb0wlkFwTFKMmaSGVxoNlKacJVtxjzIp26qEu23hwWz/USqwbBsWXf 9F7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:message-id:subject:cc:to:from:date:dkim-signature; bh=sDzLa5+rLE2+mvqB0zu03u67+d3KLrQCeFrYz5Y/Z1w=; b=LtmcK2kn6ZfNSWHoJsSf8yrMSYqGk87OnSZ84f3VrkxDQhODlXUjt5HuqoEOjtIUR8 PMNB97SLEB0ycy5iwz6Xzov/ELmPUEQEQHv/ILAM0YVDotTn2SEbl9CUn1FakKa13Eq0 uV7iVpMNXQmP7MS5Sem0J9NOEcf4iGChUz8HjGS2n1Vm9E/CA+n9eTMR65dPfK8dC/D+ Fhk/ULZcy+bATdh02JxNiZI+XNYs8vadzq8+P5u+wlyj2BCEvrsNbVFPZ2/P9B00w/rw l3sUFgWNyaYOUsYHVgeuiDShOk+AaF1FdiMS+cZoLLo/t/vfXuuAWF59a4g9Xad2X9a7 aSyg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=gVWT8qiP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i1si1834155edn.445.2020.07.27.07.16.14; Mon, 27 Jul 2020 07:16:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=gVWT8qiP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729511AbgG0OOx (ORCPT + 99 others); Mon, 27 Jul 2020 10:14:53 -0400 Received: from mail.kernel.org ([198.145.29.99]:40504 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730582AbgG0OOl (ORCPT ); Mon, 27 Jul 2020 10:14:41 -0400 Received: from localhost (mobile-166-175-191-139.mycingular.net [166.175.191.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 82D1F2173E; Mon, 27 Jul 2020 14:14:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595859280; bh=hqGjzG7kcr/MsbjRxsV9hAB3/B1VJxy+zFkGz8jLWdc=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=gVWT8qiP8B2d3sTJWw8jQuwCKb3Ijd21gSw5+UBWrb5jM7RD83N2Xm6QSWdZUsPF4 eGVxErBhMwzWE7lKlM103qKgBzyjtjdGMAgnxaU3R+cp4PsPNU3lmozQjqz094GyZx 2MntVodiw2oVVzOD8/Rq62m6IKmhl5bzXm6+YpII= Date: Mon, 27 Jul 2020 09:14:38 -0500 From: Bjorn Helgaas To: James Ettle Cc: =?utf-8?B?5ZCz5piK5r6E?= Ricky , Rui Feng , Arnd Bergmann , Greg Kroah-Hartman , Len Brown , Puranjay Mohan , "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Jacopo De Simoi Subject: Re: rtsx_pci not restoring ASPM state after suspend/resume Message-ID: <20200727141438.GA1743062@bjorn-Precision-5520> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jul 25, 2020 at 09:27:11PM +0100, James Ettle wrote: > On Fri, 2020-07-24 at 18:13 -0500, Bjorn Helgaas wrote: > > > > Maybe we should simplify this a little bit more. James, if you don't > > touch ASPM config at all, either manually or via udev, does the ASPM > > configuration stay the same across suspend/resume? > > Yes, it stays the same. Explicitly: > > With the udev rule disabled, immediately following clean boot from > power-off (and no additional tinkering), ASPM is OFF to the best of my > knowledge: > > - link/l1_aspm in sysfs is 0 for PCI devices 0000:01:00.[01]; > - the processor sleeps no deeper than package C3. > > The situation above is the same following a suspend/resume cycle -- > both in terms of sysfs, and observed package C-state occupancy. > > [Tested on kernel 5.7.10, but the behaviour is the same as prior > kernels.] I don't know the connection between ASPM and package C-states, so I need to simplify this even more. All I want to do right now is verify that if we don't have any outside influences on the ASPM configuration (eg, no manual changes and no udev rules), it stays the same across suspend/resume. In https://bugzilla.kernel.org/show_bug.cgi?id=208117#c12, we saw that ASPM L0s was disabled before suspend but was enabled after resume. That should not happen. You're looking at the sysfs link/l1_aspm file, which tells us what the PCI core thinks the state is, but I'm not confident that's accurate, especially because the driver fiddles with the state behind the back of the PCI core. So let's read the ASPM state directly from the hardware like this: sudo lspci -vvs 00:1d.0 | egrep "^0|Lnk|L1|LTR|snoop" sudo lspci -vvs 01:00 | egrep "^0|Lnk|L1|LTR|snoop" Can you try that before and after suspend/resume?