linux-kernel - Re: [RFC PATCH 0/4] mmc: sdhci: Support maximum DMA latency request via PM QoS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5512ABF7.5070303@intel.com>
Date:	Wed, 25 Mar 2015 14:37:11 +0200
From:	Adrian Hunter <adrian.hunter@...el.com>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>
CC:	Ulf Hansson <ulf.hansson@...aro.org>,
	linux-mmc <linux-mmc@...r.kernel.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
	Kevin Hilman <khilman@...aro.org>,
	Tomeu Vizoso <tomeu.vizoso@...labora.com>,
	linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/4] mmc: sdhci: Support maximum DMA latency request
 via PM QoS

On 24/03/15 22:13, Rafael J. Wysocki wrote:
> On Tuesday, March 24, 2015 03:40:36 PM Adrian Hunter wrote:
>> Hi
>>
>> Here are some patches to address an issue with SDHCI
>> in Intel Baytrail. Intel Baytrail has been observed
>> sometimes to hang if host controllers are using DMA
>> while deep C-states are used. Workaround that by
>> specifying a maximum DMA latency that will prevent
>> deep C-states.
>>
>> The first patch adds a new PM QOS function so that
>> the SDHCI driver can do a "lazy" cancel of the QoS
>> request from within its "finish" tasklet.
>>
>> The second patch adds support to SDHCI for specifying a
>> maximum DMA latency.
>>
>> The third and fourth patches take that facility into
>> use for Baytrail.
>>
>> Ad hoc testing with Lenovo Thinkpad 10 showed a stress
>> test could run for at least 24 hours with the patches,
>> compared to less than an hour without.
>>
>> These patches are on top of my driver strength patches
>> which are on top of my re-tuning patches.
>>
>>
>> Adrian Hunter (4):
>>       PM / QoS: Add pm_qos_cancel_request_lazy() that doesn't sleep
>>       mmc: sdhci: Support maximum DMA latency request via PM QOS
>>       mmc: sdhci-acpi: Fix device hang on Intel BayTrail
>>       mmc: sdhci-pci: Fix device hang on Intel BayTrail
> 
> I'm a bit concerned about the CPUID-based blacklisting of things and
> whether or not the SDHCI driver is the right place for doing that.
> 
> Maybe we should do it from within the LPSS driver instead?

+Mika

There are 2 minor difficulties with that:
1. The sdhci-acpi driver is not currently dependent on lpss
2. lpss does not currently export anything, so it is a bit of a new direction

If the ACPI HIDs used for SDHCI were unique to BayTrail (as the PCI device
ids are) then there would be no need to consult the cpuid. So it seems to be
a SDHCI problem, but I can't see a nice way to put it into lpss.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/