Linux kernel stable tree (mirror) https://git.radix-linux.su/kernel/linux.git/atom?h=linux-2.6.18.y 2006-07-10T04:04:29+00:00 2006-07-10T04:04:29+00:00 Arjan van de Ven arjan@infradead.org 2006-07-04T17:06:00+00:00 urn:sha1:d75080328affb4b268da430b7074cc8139cc662a Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Len Brown <len.brown@intel.com> 2006-06-30T07:19:10+00:00 Len Brown len.brown@intel.com 2006-06-30T07:19:10+00:00 urn:sha1:02438d8771ae6a4b215938959827692026380bf9 Signed-off-by: Len Brown <len.brown@intel.com> 2006-06-29T19:58:09+00:00 Len Brown len.brown@intel.com 2006-06-29T19:58:09+00:00 urn:sha1:f1b2ad5d2a8e1791d806ef244164d19c3d5c8b83 2006-06-28T07:34:19+00:00 Bartlomiej Swiercz swierczu@dmcs.p.lodz.pl 2006-05-29T11:16:00+00:00 urn:sha1:f831335d42a9aed26449a264266763fb542dbbe3 Signed-off-by: Len Brown <len.brown@intel.com> 2006-06-28T07:27:02+00:00 Andreas Mohr [andi@rhlx01.fht-esslingen.de] 2006-06-26T19:58:00+00:00 urn:sha1:b488f02156d3deb08f5ad7816d565c370a8cc6f1 While trying to look for superfluous I/O accesses that can be optimized away, I stumbled upon this ACPI sleep I/O access and couldn't figure out why the hell this dummy op was necessary. After more than one hour of internet research, I had collected a sufficient number of documents (among those very old kernel versions) that finally told me what this dummy read was about: STPCLK# doesn't get asserted in time on (some) chipsets, which is why we need to have a dummy I/O read to delay further instruction processing until the CPU is fully stopped. Signed-off-by: Andreas Mohr <andi@lisas.de> Signed-off-by: Len Brown <len.brown@intel.com> 2006-06-28T07:14:50+00:00 Dominik Brodowski linux@dominikbrodowski.net 2006-06-24T23:37:00+00:00 urn:sha1:c4a001b1ea32e09f7556178249b8885418858b5c Only if bus master activity is going on at the present, we should avoid entering C3-type sleep, as it might be a faulty transition. As long as the bm_activity bitmask was based on the number of calls to the ACPI idle function, looking at previous moments made sense. Now, with it being based on what happened this jiffy, looking at this jiffy should be sufficient. Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com> 2006-06-28T07:14:42+00:00 Dominik Brodowski linux@dominikbrodowski.net 2006-06-24T23:37:00+00:00 urn:sha1:c5ab81ca01ad4a8870b456f93dd2fb3d815f91d9 Do not assume there was bus mastering activity if the idle handler didn't get called, as there's only reason to not enter C3-type sleep if there is bus master activity going on. Only for the "promotion" into C3-type sleep bus mastering activity is taken into account, and there only current bus mastering activity, and not pure guessing should lead to the decision on whether to enter C3-type sleep or not. Also, as bm_activity is a jiffy-based bitmask (bit 0: bus mastering activity during this juffy, bit 31: bus mastering activity 31 jiffies ago), fix the setting of bit 0, as it might be called multiple times within one jiffy. Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com> 2006-06-28T07:14:31+00:00 Dominik Brodowski linux@dominikbrodowski.net 2006-06-24T23:37:00+00:00 urn:sha1:a3c6598f92cf27d3d201a2a5b052563148156837 Track the actual time spent in C-States (C2 upwards, we can't determine this for C1), not only the number of invocations. This is especially useful for dynamic ticks / "tickless systems", but is also of interest on normal systems, as any interrupt activity leads to C-States being exited, not only the timer interrupt. The time is being measured in PM timer ticks, so an increase by one equals 279 nanoseconds. Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Len Brown <len.brown@intel.com> 2006-06-27T04:41:40+00:00 Patrick Mochel mochel@linux.intel.com 2006-06-27T04:41:40+00:00 urn:sha1:d550d98d3317378d93a4869db204725d270ec812 Signed-off-by: Len Brown <len.brown@intel.com> 2006-06-27T04:01:06+00:00 Len Brown len.brown@intel.com 2006-06-27T03:41:38+00:00 urn:sha1:6468463abd7051fcc29f3ee7c931f9bbbb26f5a4 Signed-off-by: Len Brown <len.brown@intel.com>