- 12 Mar, 2014 30 commits
-
-
Thomas Gleixner authored
commit d689fe22 upstream. RCU and the fine grained idle time accounting functions check tick_nohz_enabled. But that variable is merily telling that NOHZ has been enabled in the config and not been disabled on the command line. But it does not tell anything about nohz being active. That's what all this should check for. Matthew reported, that the idle accounting on his old P1 machine showed bogus values, when he enabled NOHZ in the config and did not disable it on the kernel command line. The reason is that his machine uses (refined) jiffies as a clocksource which explains why the "fine" grained accounting went into lala land, because it depends on when the system goes and leaves idle relative to the jiffies increment. Provide a tick_nohz_active indicator and let RCU and the accounting code use this instead of tick_nohz_enable. Reported-and-tested-by:
Matthew Whitehead <tedheadster@gmail.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Reviewed-by:
Steven Rostedt <rostedt@goodmis.org> Reviewed-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: john.stultz@linaro.org Cc: mwhitehe@redhat.com Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1311132052240.30673@ionos.tec.linutronix.deSigned-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Thomas Gleixner authored
commit 0e576acb upstream. If CONFIG_NO_HZ=n tick_nohz_get_sleep_length() returns NSEC_PER_SEC/HZ. If CONFIG_NO_HZ=y and the nohz functionality is disabled via the command line option "nohz=off" or not enabled due to missing hardware support, then tick_nohz_get_sleep_length() returns 0. That happens because ts->sleep_length is never set in that case. Set it to NSEC_PER_SEC/HZ when the NOHZ mode is inactive. Reported-by:
Michal Hocko <mhocko@suse.cz> Reported-by:
Borislav Petkov <bp@alien8.de> Signed-off-by:
-
Linus Torvalds authored
commit 5cdec2d8 upstream. When debugging the read-only hugepage case, I was confused by the fact that get_futex_key() did an access_ok() only for the non-shared futex case, since the user address checking really isn't in any way specific to the private key handling. Now, it turns out that the shared key handling does effectively do the equivalent checks inside get_user_pages_fast() (it doesn't actually check the address range on x86, but does check the page protections for being a user page). So it wasn't actually a bug, but the fact that we treat the address differently for private and shared futexes threw me for a loop. Just move the check up, so that it gets done for both cases. Also, use the 'rw' parameter for the type, even if it doesn't actually matter any more (it's a historical artifact of the old racy i386 "page faults from kernel space don't check write protections"). Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
James Bates authored
commit 55aa42f2 upstream. The dmi_list array is initialized using gnu designated initializers, and therefore may contain fewer explicitly defined entries as there are elements in it. This is because the enum above with M_xyz constants contains more items than the designated initializer. Those elements not explicitly initialized are implicitly set to 0. Now efifb_setup() loops through all these array elements, and performs a strcmp on each item. For non explicitly initialized elements this will be a null pointer: This patch swaps the check order in the if statement, thus checks first whether dmi_list[i].base is null. Signed-off-by:
James Bates <james.h.bates@gmail.com> Signed-off-by:
David Herrmann <dh.herrmann@gmail.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Jan Kara authored
commit a404d557 upstream. Currently each task sends BLK_TN_PROCESS event to the first traced device it interacts with after a new trace is started. When there are several traced devices and the task accesses more devices, this logic can result in BLK_TN_PROCESS being sent several times to some devices while it is never sent to other devices. Thus blkparse doesn't display command name when parsing some blktrace files. Fix the problem by sending BLK_TN_PROCESS event to all traced devices when a task interacts with any of them. Signed-off-by:
Jan Kara <jack@suse.cz> Review-by:
Jeff Moyer <jmoyer@redhat.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Huang Rui authored
commit 02c123ee upstream. Commit "usb: pci-quirks: refactor AMD quirk to abstract AMD chipset types" introduced a new AMD chipset type to filter AMD platforms with different chipsets. According to a recent thread [1], this patch updates SB800 prefetch routine in AMD PLL quirk. And make it use the new chipset type to represent SB800 generation. [1] http://marc.info/?l=linux-usb&m=138012321616452&w=2Signed-off-by:
Huang Rui <ray.huang@amd.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Huang Rui authored
commit 3ad145b6 upstream. Commit "usb: pci-quirks: refactor AMD quirk to abstract AMD chipset types" introduced a new AMD chipset type to filter AMD platforms with different chipsets. According to a recent thread [1], this patch updates USB subsystem hang symptom quirk which is observed on AMD all SB600 and SB700 revision 0x3a/0x3b. And make it use the new chipset type to represent. [1] http://marc.info/?l=linux-usb&m=138012321616452&w=2Signed-off-by:
-
Huang Rui authored
commit 22b4f0cd upstream. This patch abstracts out a AMD chipset type which includes southbridge generation and its revision. When os excutes usb_amd_find_chipset_info routine to initialize AMD chipset type, driver will know which kind of chipset is used. This update has below benifits: - Driver is able to confirm which southbridge generations and their revision are used, with chipset detection once. - To describe chipset generations with enumeration types brings better readability. - It's flexible to filter AMD platforms to implement new quirks in future. Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by:
-
David Henningsson authored
commit da4a7a39 upstream. This should help us avoid the following mutex deadlock: [] mutex_lock+0x2a/0x50 [] hdmi_present_sense+0x53/0x3a0 [snd_hda_codec_hdmi] [] generic_hdmi_resume+0x5a/0x70 [snd_hda_codec_hdmi] [] hda_call_codec_resume+0xec/0x1d0 [snd_hda_codec] [] snd_hda_power_save+0x1e4/0x280 [snd_hda_codec] [] codec_exec_verb+0x5f/0x290 [snd_hda_codec] [] snd_hda_codec_read+0x5b/0x90 [snd_hda_codec] [] snd_hdmi_get_eld_size+0x1e/0x20 [snd_hda_codec_hdmi] [] snd_hdmi_get_eld+0x2c/0xd0 [snd_hda_codec_hdmi] [] hdmi_present_sense+0x9a/0x3a0 [snd_hda_codec_hdmi] [] hdmi_repoll_eld+0x34/0x50 [snd_hda_codec_hdmi] Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit efe47108 upstream. There is a small gap between the jack detection unsolicited event and the time the ELD is updated. When user-space queries the HDMI ELD immediately after receiving the notification, it might fail because of this gap. For avoiding such a problem, this patch tries to delay the HDMI jack detect notification until ELD information is fully updated. The workaround is imperfect, but good enough as a starting point. Signed-off-by:
-
Takashi Iwai authored
commit fab1285a upstream. "HDA Intel MID" is no correct name for Haswell HDMI controllers. Give them a better name, "HDA Intel HDMI". Signed-off-by:
-
Clemens Ladisch authored
commit bbaa0d66 upstream. The device IDs of the AMD Cypress/Juniper/Redwood/Cedar/Cayman/Antilles/ Barts/Turks/Caicos HDMI HDA controllers weren't added explicitly because the generic entry works, but it made the device appearing as "Generic", and people are confused as if it's no proper HDMI controller. Add them so that the name shows up properly as "ATI HDMI" instead of "Generic". According to Takashi's tests and the lack of complaints, these devices work fine without disabling snooping. Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
James Ralston authored
commit 4eeca499 upstream. This patch adds the HD Audio Device IDs for the Intel Wildcat Point-LP PCH. Signed-off-by:
James Ralston <james.d.ralston@intel.com> Signed-off-by:
-
Mengdong Lin authored
commit 300016b9 upstream. The function name not_share_unassigned_cvt() is opposite to what it does. This patch renames it to intel_not_share_assigned_cvt(), and addes comments to explain why some Intel display codecs need this workaround. Signed-off-by:
Mengdong Lin <mengdong.lin@intel.com> Signed-off-by:
-
Mengdong Lin authored
commit 02383854 upstream. For Valleyview display codec, if an unused pin chooses an assgined converter selected by a used pin, playback on the unused pin can also give sound to the output device of the used pin. It's because data flows from the same convertor to the display port of the used pin. This issue is same as Haswell. So this patch avoids using assinged convertors for unused pins. The related function haswell_config_cvts() is renamed for code reuse. Signed-off-by:
-
Takashi Iwai authored
commit b55447a7 upstream. ... which was introduced by the previous commit a4e9a38b, causing build errors without CONFIG_PROC_FS. Reported-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
-
Mengdong Lin authored
commit cc1a95d9 upstream. This patch adds codec ID (0x80862882) and module alias for Valleyview2 display codec. Signed-off-by:
-
Takashi Iwai authored
commit a4e9a38b upstream. Since the lock is used primarily in patch_hdmi.c, it's better to move it in the local struct instead of exporting in hda_eld. The only functions requiring the lock in hda_eld.c are proc accessors. So in this patch, the proc entry and its creation/deletion/accessors are moved into patch_hdmi.c, together with the mutex lock to pin_spec struct. The former proc info functions are exported so that they can be called from patch_hdmi.c. Signed-off-by:
-
Takashi Iwai authored
commit cbbaa603 upstream. Some per_pin fields and ELD contents might be changed dynamically in multiple ways where the concurrent accesses are still opened in the current code. This patch fixes such possible races by using eld->lock in appropriate places. Reported-by:
Anssi Hannula <anssi.hannula@iki.fi> Signed-off-by:
-
Anssi Hannula authored
commit 980b2495 upstream. Allow channel map debugging for both automatic and manual channel maps, and print CA always when updating infoframe. Signed-off-by:
-
Anssi Hannula authored
commit bb731f21 upstream. Currently the available channel maps TLV only contains channel maps that are limited to the traditional 7.1 speakers. Since the other HDMI channel mapping functions have been fixed to properly handle all CEA-861-E specified speakers, allow them to be listed. Signed-off-by:
-
Anssi Hannula authored
commit a5b7d510 upstream. For some speakers and slots the CEA slot <-> speaker assignment depends on the used CEA Channel Allocation value. Therefore the from_cea_slot() and to_cea_slot() helpers currently only work correctly for the regular 7.1 speakers. Fix them to work with all speakers, taking the re-ordered CA index as input and adapting use sites accordingly. This change allows manual channel mapping to actually work for all CEA allocated speakers. Additionally, this fixes incorrect channel map reporting in automatic channel mapping mode when an affected speaker position is used (e.g. 6.1 map which contains an RC speaker). Signed-off-by:
-
Anssi Hannula authored
commit 11f7c52d upstream. hdmi_manual_setup_channel_mapping() and hdmi_std_setup_channel_mapping try to assign ALSA channels to HDMI channel slots and disable (i.e. silence) other slots. However, they try to disable a slot by using AC_VERB_SET_CHAN_SLOT with parameter ((alsa_ch << 8) | 0xf), while the correct parameter is ((0xf << 8) | hdmi_slot), i.e. the slot should be unassigned, not the ALSA channel. Fix that by actually disabling the unused slots. Note that this bug did not cause any (reported) issues because slots incorrectly having audio are normally ignored by a receiver if the CEA channel allocation used does not map that slot to any speaker. Additionally, the converter channel count configuration limits the number of actually active channels in any case. Signed-off-by:
-
Anssi Hannula authored
commit 1df5a06a upstream. Currently the converter channel count is set to the number of actual input channels. The audio infoframe channel count field is set similarly. However, sometimes the used channel map does not map all input channels to outputs. Notably, 3 channel modes (e.g. 2.1) require a dummy input channel so there are 4 input channels. According to the HDA specification, converter channel count should be programmed according to the number of _active_ channels. On Intel HDMI codecs (but not on NVIDIA), setting the converter channel to a higher value than there are actually mapped channels to HDMI slots will cause no audio to be output at all. Note that the effects of this issue are currently partially masked by other bugs that prevent the driver from actually unmapping channels in certain cases. For example, if a 4 channel stream is first created and prepared, it gets a FL,FR,RL,RR mapping (ALSA->HDMI slot mapping 0->0, 1->1, 2->4, 3->5). If one thereafter assigns a FR,FL,FC mapping to it, the driver will remap 2->3 but fail to unmap 2->4 and 3->5, so there are still 4 active channels and the issue will not trigger in this case. These bugs will be fixed separately. Fix the channel counts in the converter channel count field and in the audio infoframe channel count field to match the actual number of active channels. Signed-off-by:
-
Anssi Hannula authored
commit 90f28002 upstream. hdmi_std_setup_channel_mapping() selects a Channel Allocation according to the sink reported speaker mask, preferring the ALSA standard layouts. If the channel allocation is not one of the ALSA standard layouts, the ALSA channels are mapped directly to HDMI channels in order. However, the function does not take into account that there a holes in the HDMI channel map. Additionally, the function tries to disable a slot by using AC_VERB_SET_CHAN_SLOT with parameter ((alsa_ch << 8) | 0xf), while the correct parameter is ((0xf << 8) | hdmi_slot), i.e. the slot should be unassigned, not the ALSA channel. Fix both of the issues for non-ALSA-default layouts. Tested on Intel HDMI with a speaker mask of FL | FR | FC | RC, which causes CA 0x06 to be selected for 4-channel audio, which causes incorrect output (sound destined to RC goes to FC and FC goes nowhere) without the patch. Signed-off-by:
-
Gerald Schaefer authored
commit b7c5b1aa upstream. Commit 27f6b416 "s390/vtimer: rework virtual timer interface" removed the call to init_virt_timer() by mistake, which is added again by this patch. Signed-off-by:
Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Martin Schwidefsky authored
commit 8adbf78e upstream. Git commit 4f37a68c "s390: Use direct ktime path for s390 clockevent device" makes use of the CLOCK_EVT_FEAT_KTIME clockevent option to avoid the delta calculation with ktime_get() in clockevents_program_event and the get_tod_clock() in s390_next_event. This is based on the assumption that the difference between the internal ktime and the hardware clock is reflected in the wall_to_monotonic delta. But this is not true, the ntp corrections are applied via changes to the tk->mult multiplier and this is not reflected in wall_to_monotonic. In theory this could be solved by using the raw monotonic clock but it is simpler to switch back to the standard clock delta calculation. Signed-off-by:
-
Martin Schwidefsky authored
commit 79c74ecb upstream. Switch to the improved update_vsyscall interface that provides sub-nanosecond precision for gettimeofday and clock_gettime. Signed-off-by:
-
Hendrik Brueckner authored
commit d1e61fe4 upstream. Unloading the fs3270 kernel module does not remove the created "3270/tub" device. Reloading the module then causes a sysfs warning: "sysfs: cannot create duplicate filename '/devices/virtual/3270/3270!tub'". Call device_destroy() in the module exit function to solve this issue. Signed-off-by:
Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Signed-off-by:
-
Felipe Contreras authored
commit b4cb9244 upstream. More people have reported they need this for their machines to work correctly. References: https://bugzilla.kernel.org/show_bug.cgi?id=60682Reported-by:
Stefan Hellermann <bugzilla.kernel.org@the2masters.de> Reported-by:
Benedikt Sauer <filmor@gmail.com> Reported-by:
Erno Kuusela <erno@iki.fi> Reported-by:
Jonathan Doman <jonathan.doman@gmail.com> Reported-by:
Christoph Klaffl <christophklaffl@gmail.com> Reported-by:
Jan Hendrik Nielsen <jan.hendrik.nielsen@informatik.hu-berlin.de> Signed-off-by:
Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
- 10 Mar, 2014 1 commit
-
-
Jiri Slaby authored
-
- 05 Mar, 2014 9 commits
-
-
Jani Nikula authored
commit f51a44b9 upstream. Retrying indefinitely places too much trust on the aux implementation of the sink devices. Reported-by:
Daniel Martin <consume.noise@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71267Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Tested-by:
Theodore Ts'o <tytso@mit.edu> Tested-by:
Sree Harsha Totakura <freedesktop@h.totakura.in> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Jani Nikula authored
commit 04eada25 upstream. Give more slack to sink devices before retrying on native aux defer. AFAICT the 100 us timeout was not based on the DP spec. Signed-off-by:
-
Jerome Glisse authored
commit d9654413 upstream. Need to free the uvd ring. Also reshuffle gart tear down to happen after uvd tear down. Signed-off-by:
Jérôme Glisse <jglisse@redhat.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Alex Deucher authored
commit 9ef4e1d0 upstream. Causes display problems. We had already disabled sharing for non-DP displays. Based on a patch from: Niels Ole Salscheider <niels_ole@salscheider-online.de> bug: https://bugzilla.kernel.org/show_bug.cgi?id=58121Signed-off-by:
-
Christian König authored
commit 5e386b57 upstream. Otherwise we might get a crash here. Signed-off-by:
-
Alex Deucher authored
commit 9f050c7f upstream. Print the supported functions mask in addition to the version. This is useful in debugging PX problems since we can see what functions are available. Signed-off-by:
-
Alex Deucher authored
commit d7eb0a09 upstream. Properly clear the enable bit when audio disable is requested. Signed-off-by:
-
Mike Snitzer authored
commit 1acacc07 upstream. dm_pool_close_thin_device() must be called if dm_set_target_max_io_len() fails in thin_ctr(). Otherwise __pool_destroy() will fail because the pool will still have an open thin device: device-mapper: thin metadata: attempt to close pmd when 1 device(s) are still open device-mapper: thin: __pool_destroy: dm_pool_metadata_close() failed. Also, must establish error code if failing thin_ctr() because the pool is in fail_io mode. Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Acked-by:
Joe Thornber <ejt@redhat.com> Signed-off-by:
-
Mike Snitzer authored
commit 4d1662a3 upstream. Commit 905e51b3 ("dm thin: commit outstanding data every second") introduced a periodic commit. This commit occurs regardless of whether any thin devices have made changes. Fix the periodic commit to check if any of a pool's thin devices have changed using dm_pool_changed_this_transaction(). Reported-by:
Alexander Larsson <alexl@redhat.com> Signed-off-by:
-
