[PATCH] cpufreq: Fix RCU reboot regression on x86 PIC machines

From: Ville Syrjälä Since 4.20-rc1 my PIC machines no longer reboot/shutdown. I bisected this down to commit 45975c7d21a1 ("rcu: Define RCU-sched API in terms of RCU for Tree RCU PREEMPT builds"). I traced the hang into -> cpufreq_suspend() -> cpufreq_stop_governor() ->

[PATCH] Revert "x86/tsc: Consolidate init code"

From: Ville Syrjälä This reverts commit 608008a45798fe9e2aee04f99b5270ea57c1376f. It breaks wifi on my pentium 3 Fujitsu-Siemens Lifebook S6010 laptop. Scanning for APs doesn't seem to work most of the time, and, even when it manages to find some APs it never manages to authenticate

[PATCH] Revert "x86/tsc: Consolidate init code"

From: Ville Syrjälä This reverts commit 608008a45798fe9e2aee04f99b5270ea57c1376f. It breaks wifi on my pentium 3 Fujitsu-Siemens Lifebook S6010 laptop. Scanning for APs doesn't seem to work most of the time, and, even when it manages to find some APs it never manages to authenticate

[RFC][PATCH] kconfig: Add "m or y" and "y or m" answers for oldconfig

From: Ville Syrjälä Make it possible to answer "m or y" or "y or m" to oldconfig so that scripted kernel builds can easily enable new features not present in the existing .config. The particular use case I have in mind is continuous integration where you probably want to test build any new

[RFC][PATCH] kconfig: Add "m or y" and "y or m" answers for oldconfig

From: Ville Syrjälä Make it possible to answer "m or y" or "y or m" to oldconfig so that scripted kernel builds can easily enable new features not present in the existing .config. The particular use case I have in mind is continuous integration where you probably want to test build any new

[PATCH] x86/apm: Don't access __preempt_count with zeroed fs

From: Ville Syrjälä APM_DO_POP_SEGS does not restore fs/gs which were zeroed by APM_DO_ZERO_SEGS. Trying to access __preempt_count with zeroed fs doesn't really work. Move the ibrs stuff outside the APM_DO_SAVE_SEGS/APM_DO_RESTORE_SEGS invocations so that fs is actually restored before we call

[PATCH] x86/apm: Don't access __preempt_count with zeroed fs

From: Ville Syrjälä APM_DO_POP_SEGS does not restore fs/gs which were zeroed by APM_DO_ZERO_SEGS. Trying to access __preempt_count with zeroed fs doesn't really work. Move the ibrs stuff outside the APM_DO_SAVE_SEGS/APM_DO_RESTORE_SEGS invocations so that fs is actually restored before we call

[PATCH] Revert "mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE"

From: Ville Syrjälä This reverts commit bad8c6c0b1144694ecb0bc5629ede9b8b578b86e. Make x86 with HIGHMEM=y and CMA=y boot again. Cc: Joonsoo Kim Cc: Aneesh Kumar K.V Cc: Tony Lindgren

[PATCH] Revert "mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE"

From: Ville Syrjälä This reverts commit bad8c6c0b1144694ecb0bc5629ede9b8b578b86e. Make x86 with HIGHMEM=y and CMA=y boot again. Cc: Joonsoo Kim Cc: Aneesh Kumar K.V Cc: Tony Lindgren Cc: Vlastimil Babka Cc: Johannes Weiner Cc: Laura Abbott Cc: Marek Szyprowski Cc: Mel Gorman Cc: Michal

[PATCH bluez] hid2hci: Fix udev rules for linux-4.14+

From: Ville Syrjälä Since commit 1455cf8dbfd0 ("driver core: emit uevents when device is bound to a driver") the kernel started emitting "bound" and "unbound" uevents which confuse the hid2hci udev rules. The symptoms on an affected machine (Dell E5400 in my case)

[PATCH bluez] hid2hci: Fix udev rules for linux-4.14+

From: Ville Syrjälä Since commit 1455cf8dbfd0 ("driver core: emit uevents when device is bound to a driver") the kernel started emitting "bound" and "unbound" uevents which confuse the hid2hci udev rules. The symptoms on an affected machine (Dell E5400 in my case) include bluetooth devices not

[PATCH] Revert "cpuidle: Make drivers initialize polling state"

From: Ville Syrjälä This reverts commit 1b39e3f813b4685c7a30ae964d5529a1b0e3a286. Makes my P3 machine oops somewhere in cpuidle. I suspect CONFIG_ACPI=n may have something to do with this. Cc: Rafael J. Wysocki Cc: Sudeep Holla

[PATCH] Revert "cpuidle: Make drivers initialize polling state"

From: Ville Syrjälä This reverts commit 1b39e3f813b4685c7a30ae964d5529a1b0e3a286. Makes my P3 machine oops somewhere in cpuidle. I suspect CONFIG_ACPI=n may have something to do with this. Cc: Rafael J. Wysocki Cc: Sudeep Holla Cc: Daniel Lezcano Signed-off-by: Ville Syrjälä ---

[PATCH] Revert "x86/apic: Remove init_bsp_APIC()"

From: Ville Syrjälä This reverts commit b371ae0d4a194b178817b0edfb6a7395c7aec37a. Causes my P3 UP machine to hang at boot with "lapic". Cc: Dou Liyang Cc: Thomas Gleixner Cc: ying...@kernel.org Cc: b...@redhat.com

[PATCH] Revert "x86/apic: Remove init_bsp_APIC()"

From: Ville Syrjälä This reverts commit b371ae0d4a194b178817b0edfb6a7395c7aec37a. Causes my P3 UP machine to hang at boot with "lapic". Cc: Dou Liyang Cc: Thomas Gleixner Cc: ying...@kernel.org Cc: b...@redhat.com Cc: Ingo Molnar Cc: "H. Peter Anvin" Signed-off-by: Ville Syrjälä ---

[PATCH] x86: Don't cast away the __user in __get_user_asm_u64()

From: Ville Syrjälä Don't cast away the __user in __get_user_asm_u64() on x86-32. Avoids sparse getting upset. Cc: Benjamin LaHaise Cc: Linus Torvalds Cc: Thomas Gleixner Cc: Ingo Molnar

[PATCH] x86: Don't cast away the __user in __get_user_asm_u64()

From: Ville Syrjälä Don't cast away the __user in __get_user_asm_u64() on x86-32. Avoids sparse getting upset. Cc: Benjamin LaHaise Cc: Linus Torvalds Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Signed-off-by: Ville Syrjälä --- arch/x86/include/asm/uaccess.h | 2 +- 1 file

[PATCH] drm/i915: Make vblank evade warnings optional

From: Ville Syrjälä Add a new Kconfig option to enable/disable the extra warnings from the vblank evade code. For now we'll keep the warning about an actually missed vblank always enabled as that can have an actual user visible impact. But if we miss the deadline

[PATCH] drm/i915: Make vblank evade warnings optional

From: Ville Syrjälä Add a new Kconfig option to enable/disable the extra warnings from the vblank evade code. For now we'll keep the warning about an actually missed vblank always enabled as that can have an actual user visible impact. But if we miss the deadline othrwise there's no real need to

[PATCH] Revert "cpuidle: Replace ktime_get() with local_clock()"

From: Ville Syrjälä This reverts commit e93e59ce5b85e6c2b444f09fd1f707274ec066dc. The TSC stops in deeper C states, so using local_clock() in cpuidle to track the C state residency seems like a bad idea. With local_clock() powertop is reporting mostly 0% residency

[PATCH] Revert "cpuidle: Replace ktime_get() with local_clock()"

From: Ville Syrjälä This reverts commit e93e59ce5b85e6c2b444f09fd1f707274ec066dc. The TSC stops in deeper C states, so using local_clock() in cpuidle to track the C state residency seems like a bad idea. With local_clock() powertop is reporting mostly 0% residency for C states here. Presumably

[PATCH] intel_idle: Don't use on Lenovo Ideapad S10-3t

From: Ville Syrjälä Lenovo Ideapad S10-3t hangs coming out of S3 with intel_idle. The two workaround that seem to help are "intel_idle.max_cstate=0" or "nohz=off highres=off". At a first glance quirk_tigerpoint_bm_sts() seemed promising, but even when moved to

[PATCH] intel_idle: Don't use on Lenovo Ideapad S10-3t

From: Ville Syrjälä Lenovo Ideapad S10-3t hangs coming out of S3 with intel_idle. The two workaround that seem to help are "intel_idle.max_cstate=0" or "nohz=off highres=off". At a first glance quirk_tigerpoint_bm_sts() seemed promising, but even when moved to early_resume it didn't do

[PATCH] arch/x86: Don't try to poke disabled/non-existent APIC

From: Ville Syrjälä Apparently trying to poke a disabled or non-existent APIC leads to a box that doesn't even boot. Let's not do that. No real clue if this is the right fix, but at least my P3 machine boots again. Cc: sta...@vger.kernel.org Cc: Ingo Molnar

[PATCH] arch/x86: Don't try to poke disabled/non-existent APIC

From: Ville Syrjälä Apparently trying to poke a disabled or non-existent APIC leads to a box that doesn't even boot. Let's not do that. No real clue if this is the right fix, but at least my P3 machine boots again. Cc: sta...@vger.kernel.org Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc:

[PATCH] rtc: cmos: Don't enable interrupts in the middle of the interrupt handler

From: Ville Syrjälä Using spin_lock_irq()/spin_unlock_irq() from within the interrupt handler is a no-no. Let's save/restore the flags to avoid turning on interrupts prematurely. We hit this in a bunch of our CI systems, but for whatever reason I wasn't able to

[PATCH] rtc: cmos: Don't enable interrupts in the middle of the interrupt handler

From: Ville Syrjälä Using spin_lock_irq()/spin_unlock_irq() from within the interrupt handler is a no-no. Let's save/restore the flags to avoid turning on interrupts prematurely. We hit this in a bunch of our CI systems, but for whatever reason I wasn't able to reproduce on my own machine, so

[PATCH] timer: Make msleep(0) a nop

From: Ville Syrjälä Thanks to the msecs_to_jiffies()+1 msleep(0) may actually sleep for up to one jiffy. Presumably the caller should be satisfied if we "sleep" for 0 jiffies instead of 0-1 jiffies, so let's just turn msleep(0) into a nop. This can simplify some

[PATCH] timer: Make msleep(0) a nop

From: Ville Syrjälä Thanks to the msecs_to_jiffies()+1 msleep(0) may actually sleep for up to one jiffy. Presumably the caller should be satisfied if we "sleep" for 0 jiffies instead of 0-1 jiffies, so let's just turn msleep(0) into a nop. This can simplify some callers as they don't have to

[PATCH] x86/hweight: Don't clobber %rdi

From: Ville Syrjälä The caller expects %rdi to remain intact, push+pop it make that happen. Fixes the following kind of explosions on my core2duo machine when trying to reboot or shut down: general protection fault: [#1] PREEMPT SMP Modules linked in: i915

[PATCH] x86/hweight: Don't clobber %rdi

From: Ville Syrjälä The caller expects %rdi to remain intact, push+pop it make that happen. Fixes the following kind of explosions on my core2duo machine when trying to reboot or shut down: general protection fault: [#1] PREEMPT SMP Modules linked in: i915 i2c_algo_bit drm_kms_helper

[PATCH] x86/perf/intel/rapl: Fix module name collision with powercap intel-rapl

From: Ville Syrjälä Since commit 4b6e2571bf00 ("x86/perf/intel/rapl: Make the Intel RAPL PMU driver modular") the rapl perf module calls itself intel-rapl. That name was already in use by the rapl powercap driver, which now fails to load if the perf module is

[PATCH] x86/perf/intel/rapl: Fix module name collision with powercap intel-rapl

From: Ville Syrjälä Since commit 4b6e2571bf00 ("x86/perf/intel/rapl: Make the Intel RAPL PMU driver modular") the rapl perf module calls itself intel-rapl. That name was already in use by the rapl powercap driver, which now fails to load if the perf module is loaded. Fix the problem by renaming

[PATCH] dma-debug: Avoid spinlock recursion when disabling dma-debug

From: Ville Syrjälä With netconsole (at least) the pr_err("... disabling\n") call can recurse back into the dma-debug code, where it'll try to grab free_entries_lock again. Avoid the problem by doing the printk after dropping the lock. Cc: sta...@vger.kernel.org

[PATCH] dma-debug: Avoid spinlock recursion when disabling dma-debug

From: Ville Syrjälä With netconsole (at least) the pr_err("... disabling\n") call can recurse back into the dma-debug code, where it'll try to grab free_entries_lock again. Avoid the problem by doing the printk after dropping the lock. Cc: sta...@vger.kernel.org Cc: Andrew Morton

[PATCH 01/29] pci: Decouple quirks.c from i915_reg.h

From: Ville Syrjälä i915 register defines are going to become type safe, so going forward the register defines can't be used as straight numbers. Since quirks.c needs just a few extra register defines from i915_reg.h, decouple the two by defining the required registers locally in quirks.c. This

[PATCH 01/29] pci: Decouple quirks.c from i915_reg.h

From: Ville Syrjälä i915 register defines are going to become type safe, so going forward the register defines can't be used as straight numbers. Since quirks.c needs just a few extra register defines from i915_reg.h, decouple the two by defining the required

[PATCH] intel_idle: Don't use on Lenovo Ideapad S10-3t

From: Ville Syrjälä Lenovo Ideapad S10-3t hangs coming out of S3 with intel_idle. The two workaround that seem to help are "intel_idle.max_cstate=0" or "nohz=off highres=off". At a first glance quirk_tigerpoint_bm_sts() seemed promising, but even when moved to early_resume it didn't do

[PATCH] intel_idle: Don't use on Lenovo Ideapad S10-3t

From: Ville Syrjälä Lenovo Ideapad S10-3t hangs coming out of S3 with intel_idle. The two workaround that seem to help are "intel_idle.max_cstate=0" or "nohz=off highres=off". At a first glance quirk_tigerpoint_bm_sts() seemed promising, but even when moved to

[PATCH] x86: dma-mapping: Fix arch_dma_alloc_attrs() oops with NULL dev

From: Ville Syrjälä Commit 6894258eda2f ("dma-mapping: consolidate dma_{alloc,free}_{attrs,coherent}") broke drivers that pass NULL as the device for dma_alloc. Fix things by moving the ISA DMA fallback dev assignment earlier. A quick search suggest that Meelis Roos has hit this with sb16, and

[PATCH] x86: dma-mapping: Fix arch_dma_alloc_attrs() oops with NULL dev

From: Ville Syrjälä Commit 6894258eda2f ("dma-mapping: consolidate dma_{alloc,free}_{attrs,coherent}") broke drivers that pass NULL as the device for dma_alloc. Fix things by moving the ISA DMA fallback dev assignment earlier. A quick search suggest that Meelis

[PATCH v3] drm/i915: Fix lock dropping in intel_tv_detect()

From: Ville Syrjälä When intel_tv_detect() fails to do load detection it would forget to drop the locks and clean up the acquire context. Fix it up. This is a regression from: commit 208bf9fdcd3575aa4a5d48b3e0295f7cdaf6fc44 Author: Ville Syrjälä Date: Mon Aug 11 13:15:35 2014 +0300

[PATCH v3] drm/i915: Fix lock dropping in intel_tv_detect()

From: Ville Syrjälä ville.syrj...@linux.intel.com When intel_tv_detect() fails to do load detection it would forget to drop the locks and clean up the acquire context. Fix it up. This is a regression from: commit 208bf9fdcd3575aa4a5d48b3e0295f7cdaf6fc44 Author: Ville Syrjälä

[PATCH v2] drm/i915: Fix lock dropping in intel_tv_detect()

From: Ville Syrjälä When intel_tv_detect() fails to do load detection it would forget to drop the locks and clean up the acquire context. Fix it up. This is a regression from: commit 208bf9fdcd3575aa4a5d48b3e0295f7cdaf6fc44 Author: Ville Syrjälä Date: Mon Aug 11 13:15:35 2014 +0300

[PATCH] drm/i915: Fix lock dropping in intel_tv_detect()

From: Ville Syrjälä When intel_tv_detect() fails to do load detection it would forget to drop the locks and clean up the acquire context. Fix it up. This is a regression from: commit 208bf9fdcd3575aa4a5d48b3e0295f7cdaf6fc44 Author: Ville Syrjälä Date: Mon Aug 11 13:15:35 2014 +0300

[PATCH] drm/i915: Fix lock dropping in intel_tv_detect()

From: Ville Syrjälä ville.syrj...@linux.intel.com When intel_tv_detect() fails to do load detection it would forget to drop the locks and clean up the acquire context. Fix it up. This is a regression from: commit 208bf9fdcd3575aa4a5d48b3e0295f7cdaf6fc44 Author: Ville Syrjälä

[PATCH v2] drm/i915: Fix lock dropping in intel_tv_detect()

From: Ville Syrjälä ville.syrj...@linux.intel.com When intel_tv_detect() fails to do load detection it would forget to drop the locks and clean up the acquire context. Fix it up. This is a regression from: commit 208bf9fdcd3575aa4a5d48b3e0295f7cdaf6fc44 Author: Ville Syrjälä

[PATCH] x86/gpu: Fix sign extension issue in Intel graphics stolen memory quirks

From: Ville Syrjälä Have the KB(),MB(),GB() macros produce unsigned longs to avoid uninteded sign extension issues with the gen2 memory size detection. What happens is first the uint8_t returned by read_pci_config_byte() gets promoted to an int which gets multiplied by another int from the MB()

[PATCH] x86/gpu: Fix sign extension issue in Intel graphics stolen memory quirks

From: Ville Syrjälä ville.syrj...@linux.intel.com Have the KB(),MB(),GB() macros produce unsigned longs to avoid uninteded sign extension issues with the gen2 memory size detection. What happens is first the uint8_t returned by read_pci_config_byte() gets promoted to an int which gets multiplied

[PATCH v2 02/11] drm: Add support_bits parameter to drm_property_create_bitmask()

From: Ville Syrjälä Make drm_property_create_bitmask() a bit more generic by allowing the caller to specify which bits are in fact supported. This allows multiple callers to use the same enum list, but still create different versions of the same property with different list of supported bits.

[PATCH v2 02/11] drm: Add support_bits parameter to drm_property_create_bitmask()

From: Ville Syrjälä ville.syrjala at linux.intel.com Make drm_property_create_bitmask() a bit more generic by allowing the caller to specify which bits are in fact supported. This allows multiple callers to use the same enum list, but still create different versions of the same property with

[PATCH 1/3] x86: Add vfunc for Intel graphics stolen memory base address

From: Ville Syrjälä For gen2 devices we're going to need another way to determine the stolen memory base address. Make that into a vfunc as well. Also drop the bogus inline keyword from gen8_stolen_size(). Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Cc:

[PATCH v3 2/3] x86: Add Intel graphics stolen memory quirk for gen2 platforms

From: Ville Syrjälä There isn't an explicit stolen memory base register on gen2. Some old comment in the i915 code suggests we should get it via max_low_pfn_mapped, but that's clearly a bad idea on my MGM. The e820 map in said machine looks like this: [0.00] BIOS-e820: [mem

[PATCH 0/3] x86: Intel gen2 graphics stolen memory quirks

From: Ville Syrjälä Ingo asked me to post the x86 bits as a standalone series. So here it is. So the series adds the Intel gen2 graphics stolen memory reservation quirks to arch/x86. These are not unlike the quirks we have for later gens, except it's a bit more work to dig out the correct range

[PATCH 3/3] x86: Print the Intel graphics stolen memory range

From: Ville Syrjälä Print an informative message when reserving the graphics stolen memory region in the early quirk. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Ville Syrjälä ---

[PATCH 3/3] x86: Print the Intel graphics stolen memory range

From: Ville Syrjälä ville.syrj...@linux.intel.com Print an informative message when reserving the graphics stolen memory region in the early quirk. Cc: Thomas Gleixner t...@linutronix.de Cc: Ingo Molnar mi...@redhat.com Cc: H. Peter Anvin h...@zytor.com Cc: x...@kernel.org Cc:

[PATCH 0/3] x86: Intel gen2 graphics stolen memory quirks

From: Ville Syrjälä ville.syrj...@linux.intel.com Ingo asked me to post the x86 bits as a standalone series. So here it is. So the series adds the Intel gen2 graphics stolen memory reservation quirks to arch/x86. These are not unlike the quirks we have for later gens, except it's a bit more work

[PATCH v3 2/3] x86: Add Intel graphics stolen memory quirk for gen2 platforms

From: Ville Syrjälä ville.syrj...@linux.intel.com There isn't an explicit stolen memory base register on gen2. Some old comment in the i915 code suggests we should get it via max_low_pfn_mapped, but that's clearly a bad idea on my MGM. The e820 map in said machine looks like this: [0.00]

[PATCH 1/3] x86: Add vfunc for Intel graphics stolen memory base address

From: Ville Syrjälä ville.syrj...@linux.intel.com For gen2 devices we're going to need another way to determine the stolen memory base address. Make that into a vfunc as well. Also drop the bogus inline keyword from gen8_stolen_size(). Cc: Thomas Gleixner t...@linutronix.de Cc: Ingo Molnar

[PATCH] x86: Drop casts from __copy_{from,to}_user_inatomic

From: Ville Syrjälä The casts in __copy_{from,to}_user_inatomic lead to sparse warnings. Drop the casts to get rid of the warnings. Example: CHECK drivers/gpu/drm/i915/i915_gem.c arch/x86/include/asm/uaccess_64.h:213:40: warning: incorrect type in argument 1 (different address spaces)

[PATCH v3 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms

From: Ville Syrjälä There isn't an explicit stolen memory base register on gen2. Some old comment in the i915 code suggests we should get it via max_low_pfn_mapped, but that's clearly a bad idea on my MGM. The e820 map in said machine looks like this: [0.00] BIOS-e820: [mem

[PATCH v3 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms

From: Ville Syrjälä ville.syrj...@linux.intel.com There isn't an explicit stolen memory base register on gen2. Some old comment in the i915 code suggests we should get it via max_low_pfn_mapped, but that's clearly a bad idea on my MGM. The e820 map in said machine looks like this: [0.00]

[PATCH] x86: Drop casts from __copy_{from,to}_user_inatomic

From: Ville Syrjälä ville.syrj...@linux.intel.com The casts in __copy_{from,to}_user_inatomic lead to sparse warnings. Drop the casts to get rid of the warnings. Example: CHECK drivers/gpu/drm/i915/i915_gem.c arch/x86/include/asm/uaccess_64.h:213:40: warning: incorrect type in argument 1

[PATCH v2 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms

From: Ville Syrjälä There isn't an explicit stolen memory base register on gen2. Some old comment in the i915 code suggests we should get it via max_low_pfn_mapped, but that's clearly a bad idea on my MGM. The e820 map in said machine looks like this: [0.00] BIOS-e820: [mem

[PATCH 1/6] x86: Add vfunc for Intel graphics stolen memory base address

From: Ville Syrjälä For gen2 devices we're going to need another way to determine the stolen memory base address. Make that into a vfunc as well. Also drop the bogus inline keyword from gen8_stolen_size(). Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Cc:

[PATCH 3/6] x86: Print the Intel graphcis stolen memory range

From: Ville Syrjälä Print an informative message when reserving the graphics stolen memory region in the early quirk. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Ville Syrjälä ---

[PATCH 3/6] x86: Print the Intel graphcis stolen memory range

From: Ville Syrjälä ville.syrj...@linux.intel.com Print an informative message when reserving the graphics stolen memory region in the early quirk. Cc: Thomas Gleixner t...@linutronix.de Cc: Ingo Molnar mi...@redhat.com Cc: H. Peter Anvin h...@zytor.com Cc: x...@kernel.org Cc:

[PATCH 1/6] x86: Add vfunc for Intel graphics stolen memory base address

From: Ville Syrjälä ville.syrj...@linux.intel.com For gen2 devices we're going to need another way to determine the stolen memory base address. Make that into a vfunc as well. Also drop the bogus inline keyword from gen8_stolen_size(). Cc: Thomas Gleixner t...@linutronix.de Cc: Ingo Molnar

[PATCH v2 2/6] x86: Add Intel graphics stolen memory quirk for gen2 platforms

From: Ville Syrjälä ville.syrj...@linux.intel.com There isn't an explicit stolen memory base register on gen2. Some old comment in the i915 code suggests we should get it via max_low_pfn_mapped, but that's clearly a bad idea on my MGM. The e820 map in said machine looks like this: [0.00]

[PATCH] drm/i915: Take modeset locks around intel_modeset_setup_hw_state()

From: Ville Syrjälä Some lower level things get angry if we don't have modeset locks during intel_modeset_setup_hw_state(). Actually the resume and lid_notify codepaths alreday hold the locks, but the init codepath doesn't, so fix that. Signed-off-by: Ville Syrjälä --- Totally untested, but

[PATCH] drm/i915: Take modeset locks around intel_modeset_setup_hw_state()

From: Ville Syrjälä ville.syrj...@linux.intel.com Some lower level things get angry if we don't have modeset locks during intel_modeset_setup_hw_state(). Actually the resume and lid_notify codepaths alreday hold the locks, but the init codepath doesn't, so fix that. Signed-off-by: Ville Syrjälä

[PATCH] x86: Add reboot quirk for Dell Latitude E5410

From: Ville Syrjälä Dell Latitude E5410 needs reboot=pci to actually reboot. Signed-off-by: Ville Syrjälä --- arch/x86/kernel/reboot.c | 8 1 file changed, 8 insertions(+) diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c index e643e74..7e920bf 100644 ---

[PATCH] x86: Add reboot quirk for Dell Latitude E5410

From: Ville Syrjälä ville.syrj...@linux.intel.com Dell Latitude E5410 needs reboot=pci to actually reboot. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- arch/x86/kernel/reboot.c | 8 1 file changed, 8 insertions(+) diff --git a/arch/x86/kernel/reboot.c

[RFC][PATCH] drm/i915: Fix VGA handling using stop_machine() or mmio

From: Ville Syrjälä We have several problems with out VGA handling: - We try to use the GMCH control VGA disable bit even though it may be locked - If we manage to disable VGA throuh GMCH control, we're no longer able to correctly disable the VGA plane - Taking part in the VGA arbitration is

[RFC][PATCH] drm/i915: Fix VGA handling using stop_machine() or mmio

From: Ville Syrjälä ville.syrj...@linux.intel.com We have several problems with out VGA handling: - We try to use the GMCH control VGA disable bit even though it may be locked - If we manage to disable VGA throuh GMCH control, we're no longer able to correctly disable the VGA plane - Taking

Re: regression in linux 3.7 - fan speed at 100% after suspend/resume at 100%

Roberto Oppedisano gmail.com> writes: > > Hello, > with recent kernels after a suspend/resume cycle on my laptop (HP > 6730b) the fans stays at full speed. I too have been hit by this regression w/ a HP Compaq NC6000 laptop. >From what I can tell 3.7.x gets confused about trip points

Re: regression in linux 3.7 - fan speed at 100% after suspend/resume at 100%

Roberto Oppedisano roberto.oppedisano at gmail.com writes: Hello, with recent kernels after a suspend/resume cycle on my laptop (HP 6730b) the fans stays at full speed. I too have been hit by this regression w/ a HP Compaq NC6000 laptop. From what I can tell 3.7.x gets confused about

[PATCH] x86: Add support for 64bit get_user() on x86-32

From: Ville Syrjälä Implement __get_user_8() for x86-32. It will return the 64bit result in edx:eax register pair, and ecx is used to pass in the address and return the error value. For consistency, change the register assignment for all other __get_user_x() variants, so that address is passed

[PATCH] x86: Add support for 64bit get_user() on x86-32

From: Ville Syrjälä ville.syrj...@linux.intel.com Implement __get_user_8() for x86-32. It will return the 64bit result in edx:eax register pair, and ecx is used to pass in the address and return the error value. For consistency, change the register assignment for all other __get_user_x()

[PATCH] w1-gpio: Add GPIO w1 bus master driver (v3)

Add a GPIO 1-wire bus master driver. The driver used the GPIO API to control the wire and the GPIO pin can be specified using platform data similar to i2c-gpio. The driver was tested with AT91SAM9260 + DS2401. Signed-off-by: Ville Syrjala <[EMAIL PROTECTED]> --- Changes from version 2 to v

[PATCH] w1-gpio: Add GPIO w1 bus master driver (v3)

Add a GPIO 1-wire bus master driver. The driver used the GPIO API to control the wire and the GPIO pin can be specified using platform data similar to i2c-gpio. The driver was tested with AT91SAM9260 + DS2401. Signed-off-by: Ville Syrjala [EMAIL PROTECTED] --- Changes from version 2 to version 3

[PATCH] w1-gpio: Add GPIO w1 bus master driver (v2)

Add a GPIO 1-wire bus master driver. The driver used the GPIO API to control the wire and the GPIO pin can be specified using platform data similar to i2c-gpio. The driver was tested with AT91SAM9260 + DS2401. Signed-off-by: Ville Syrjala <[EMAIL PROTECTED]> --- Version 2 of the patch c

[PATCH] w1-gpio: Add GPIO w1 bus master driver (v2)

Add a GPIO 1-wire bus master driver. The driver used the GPIO API to control the wire and the GPIO pin can be specified using platform data similar to i2c-gpio. The driver was tested with AT91SAM9260 + DS2401. Signed-off-by: Ville Syrjala [EMAIL PROTECTED] --- Version 2 of the patch changes

[PATCH] w1-gpio: Add GPIO w1 bus master driver

Add a GPIO 1-wire bus master driver. The driver used the GPIO API to control the wire and the GPIO pin can be specified using platform data similar to i2c-gpio. The driver was tested with AT91SAM9260 + DS2401. Signed-off-by: Ville Syrjala <[EMAIL PROTECTED]> --- Documentation/w1/masters/00

[PATCH] w1-gpio: Add GPIO w1 bus master driver

Add a GPIO 1-wire bus master driver. The driver used the GPIO API to control the wire and the GPIO pin can be specified using platform data similar to i2c-gpio. The driver was tested with AT91SAM9260 + DS2401. Signed-off-by: Ville Syrjala [EMAIL PROTECTED] --- Documentation/w1/masters/00-INDEX