- 21 Sep, 2015 40 commits
-
-
Mark Rustad authored
commit 7aa6ca4d upstream. Set the PCI_DEV_FLAGS_VPD_REF_F0 flag on all Intel Ethernet device functions other than function 0, so that on multi-function devices, we will always read VPD from function 0 instead of from the other functions. [bhelgaas: changelog] Signed-off-by:
Mark Rustad <mark.d.rustad@intel.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Alexander Duyck <alexander.h.duyck@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Mark Rustad authored
commit 932c435c upstream. Add a dev_flags bit, PCI_DEV_FLAGS_VPD_REF_F0, to access VPD through function 0 to provide VPD access on other functions. This is for hardware devices that provide copies of the same VPD capability registers in multiple functions. Because the kernel expects that each function has its own registers, both the locking and the state tracking are affected by VPD accesses to different functions. On such devices for example, if a VPD write is performed on function 0, *any* later attempt to read VPD from any other function of that device will hang. This has to do with how the kernel tracks the expected value of the F bit per function. Concurrent accesses to different functions of the same device can not only hang but also corrupt both read and write VPD data. When hangs occur, typically the error message: vpd r/w failed. This is likely a firmware bug on this device. will be seen. Never set this bit on function 0 or there will be an infinite recursion. Signed-off-by:
-
Bjorn Helgaas authored
commit d1541dc9 upstream. In fixup_ti816x_class(), we assigned "class = PCI_CLASS_MULTIMEDIA_VIDEO". But PCI_CLASS_MULTIMEDIA_VIDEO is only the two-byte base class/sub-class and needs to be shifted to make space for the low-order interface byte. Shift PCI_CLASS_MULTIMEDIA_VIDEO to set the correct class code. Fixes: 63c44080 ("PCI: Add quirk for setting valid class for TI816X Endpoint") Signed-off-by:
-
Georgi Djakov authored
commit 1c4b4b0e upstream. Fix the enable bit of the pseudorandom number generator clock. Reported-by:
Stanimir Varbanov <stanimir.varbanov@linaro.org> Fixes: 3966fab8 "clk: qcom: Add MSM8916 Global Clock Controller support" Signed-off-by:
Georgi Djakov <georgi.djakov@linaro.org> Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Stephen Boyd authored
commit d7a304e9 upstream. The other ce clocks have the flag set, but ce1 doesn't, so clk_set_rate() doesn't propagate up the tree to the ce1_src_clk. Set the flag as this is supported. Reported-by:
Bjorn Andersson <bjorn.andersson@sonymobile.com> Tested-by:
-
Robert Jarzmik authored
commit 4b5fb7dc upstream. Legacy drivers which are not yet ported, such as cpufreq-pxa[23]xx, rely on pxaXXx_get_clk_frequency_khz() to find the CPU core frequency. This reporting was broken because the expected unit is kHz and not Hz. Fix the reporting for pxa25x, pxa27x and pxa3xx. Fixes: fe7710fa ("clk: add pxa25x clock drivers") Fixes: d40670dc ("clk: add pxa27x clock drivers") Fixes: 9bbb8a33 ("clk: pxa: add pxa3xx clock driver") Signed-off-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
-
Dan Carpenter authored
commit 3294bee8 upstream. The ">" should be ">=" or we end up reading beyond the end of the array. Fixes: 6e973d2c ('clk: vexpress: Add separate SP810 driver') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Pawel Moll <pawel.moll@arm.com> Signed-off-by:
-
Damien.Horsley authored
commit d31ff5f7 upstream. Current critical clock list for pistachio enables only mips and sys clocks by default but there are also other clocks that are not claimed by anyone and needs to be enabled by default. This patch updates the critical clocks that need to be enabled by default. Add a separate struct to distinguish the critical clocks as listed: 1.) core clocks: a.) mips clock 2.) peripheral system clocks: a.) sys clock b.) sys_bus clock c.) DDR clock d.) ROM clock Fixes: b35d7c33("CLK: Pistachio: Register core clocks") Reviewed-by:
Andrew Bresticker <abrestic@chromium.org> Signed-off-by:
Ezequiel Garcia <ezequiel.garcia@imgtec.com> Signed-off-by:
Damien.Horsley <Damien.Horsley@imgtec.com> Signed-off-by:
Govindraj Raja <govindraj.raja@imgtec.com> Signed-off-by:
-
Zdenko Pulitika authored
commit 7937c6c5 upstream. .recalc_rate callback for the fractional PLL doesn't take operating mode into account when calculating PLL rate. This results in the incorrect PLL rates when PLL is operating in integer mode. Operating mode of fractional PLL is based on the value of the fractional divider. Currently it assumes that the PLL will always be configured in fractional mode which may not be the case. This may result in the wrong output frequency. Also vco was calculated based on the current operating mode which makes no sense because .set_rate is setting operating mode. Instead, vco should be calculated using PLL settings that are about to be set. Fixes: 43049b0c("CLK: Pistachio: Add PLL driver") Reviewed-by:
Zdenko Pulitika <zdenko.pulitika@imgtec.com> Signed-off-by:
-
Zdenko Pulitika authored
commit e53f21c7 upstream. PLL enable callbacks are overriding PLL mode (int/frac) and Noise reduction (on/off) settings set by the boot loader which results in the incorrect clock rate. PLL mode and noise reduction are defined by the DSMPD and DACPD bits of the PLL control register. PLL .enable() callbacks enable PLL by deasserting all power-down bits of the PLL control register, including DSMPD and DACPD bits, which is not necessary since these bits don't actually enable/disable PLL. This commit fixes the problem by removing DSMPD and DACPD bits from the "PLL enable" mask. Fixes: 43049b0c("CLK: Pistachio: Add PLL driver") Reviewed-by:
-
Zdenko Pulitika authored
commit 093affb0 upstream. This commit fixes 32bit integer overflows throughout the pll driver (i.e. wherever the result of integer multiplication may exceed the range of u32). One of the functions affected by this problem is .recalc_rate. It returns incorrect rate for some pll settings (not for all though) which in turn results in the incorrect rate setup of pll's child clocks. Fixes: 43049b0c("CLK: Pistachio: Add PLL driver") Reviewed-by:
-
Marek Szyprowski authored
commit ba300115 upstream. Commit d5e136a2 ("clk: samsung: Register clk provider only after registering its all clocks", merged to v3.17-rc1) modified a way that driver registers registers to core framework. This change has not been applied to s5pv210 clocks driver, which has been merged in parallel to that commit. This patch adds a missing call to samsung_clk_of_add_provider(), so the driver is operational again. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Acked-by:
Tomasz Figa <tomasz.figa@gmail.com> Signed-off-by:
Michael Turquette <mturquette@baylibre.com> Signed-off-by:
-
Krzysztof Kozlowski authored
commit e323d56e upstream. The TSADC gate clock was used in Exynos4x12 DTSI for exynos-adc driver. However TSADC is present only on Exynos4210 so on Trats2 board (with Exynos4412 SoC) the exynos-adc driver could not be probed: ERROR: could not get clock /adc@126C0000:adc(0) exynos-adc 126c0000.adc: failed getting clock, err = -2 exynos-adc: probe of 126c0000.adc failed with error -2 Instead on Exynos4x12 SoCs the main clock used by Analog to Digital Converter is located in different register and it is named in datasheet as PCLK_ADC. Regardless of the name the purpose of this PCLK_ADC clock is the same as purpose of TSADC from Exynos4210. The patch adds gate clock for Exynos4x12 using the proper register so backward compatibility is preserved. This fixes the probe of exynos-adc driver on Exynos4x12 boards and allows accessing sensors connected to it on Trats2 board (ntc,ncp15wb473 AP and battery thermistors). Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Fixes: c63c5743 ("ARM: dts: Add ADC's dt data to read raw data for exynos4x12") Reviewed-by:
Javier Martinez Canillas <javier.martinez@collabora.co.uk> Acked-by:
-
Heiko Stuebner authored
commit 4791eb61 upstream. The dwmac ethernet controller on the rk3288 supports phys connected via rgmii and rmii. With rgmii phys it is expected that the mac clock is provided externally while with rmii phys the clock can be external but also generated from the plls. In the later case it of course needs be at 50MHz, which gets set from the dwmac_rk driver. As most devices use a rgmii phy it never surfaced so far that the mac clk mux, doesn't go up one lever to the pll clock in the rmii case with internal clock generation, as it is missing the CLK_SET_RATE_PARENT flag, and thus will not set the correct frequency in most cases. Fixes: b9e4ba54 ("clk: rockchip: add clock controller for rk3288") Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Colin Ian King authored
commit f4745a92 upstream. Static analysis by cppcheck found an issue that was recently introduced by commit 471f7707 ("PM / clock_ops: make __pm_clk_enable more generic") where a return status in ret was not being initialised and garbage being returned when ce->status >= PCE_STATUS_ERROR. The fact that ret is not being checked by the caller and that ret is only used internally __pm_clk_enable() to check if clk_enable() was OK means we can ignore returning it instead turn __pm_clk_enable() into function with a void return. Fixes: 471f7707 ("PM / clock_ops: make __pm_clk_enable more generic") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
David Kershner authored
commit 1fc07f99 upstream. We inadvertently remove the MODULE_DEVICE_TABLE line for visorbus, this patch adds it back in. Signed-off-by:
David Kershner <david.kershner@unisys.com> Signed-off-by:
Benjamin Romer <benjamin.romer@unisys.com> Fixes: d5b3f1dc ('staging: unisys: move timskmod.h functionality') Signed-off-by:
-
Ian Abbott authored
commit c04a1f17 upstream. `devpriv->ao_timer` is used while an asynchronous command is running on the AO subdevice. It also gets modified by the subdevice's `cmdtest` handler for checking new asynchronous commands, `usbduxsigma_ao_cmdtest()`, which is not correct as it's allowed to check new commands while an old command is still running. Fix it by moving the code which sets up `devpriv->ao_timer` into the subdevice's `cmd` handler, `usbduxsigma_ao_cmd()`. Note that the removed code in `usbduxsigma_ao_cmdtest()` checked that `devpriv->ao_timer` did not end up less that 1, but that could not happen due because `cmd->scan_begin_arg` or `cmd->convert_arg` had already been range-checked. Also note that we tested the `high_speed` variable in the old code, but that is currently always 0 and means that we always use "scan" timing (`cmd->scan_begin_src == TRIG_TIMER` and `cmd->convert_src == TRIG_NOW`) and never "convert" (individual sample) timing (`cmd->scan_begin_src == TRIG_FOLLOW` and `cmd->convert_src == TRIG_TIMER`). The moved code tests `cmd->convert_src` instead to decide whether "scan" or "convert" timing is being used, although currently only "scan" timing is supported. Fixes: fb1ef622 ("staging: comedi: usbduxsigma: tidy up analog output command support") Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Reviewed-by:
Bernd Porr <mail@berndporr.me.uk> Reviewed-by:
H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by:
-
Ian Abbott authored
commit 423b24c3 upstream. `devpriv->ai_timer` is used while an asynchronous command is running on the AI subdevice. It also gets modified by the subdevice's `cmdtest` handler for checking new asynchronous commands (`usbduxsigma_ai_cmdtest()`), which is not correct as it's allowed to check new commands while an old command is still running. Fix it by moving the code which sets up `devpriv->ai_timer` and `devpriv->ai_interval` into the subdevice's `cmd` handler, `usbduxsigma_ai_cmd()`. Note that the removed code in `usbduxsigma_ai_cmdtest()` checked that `devpriv->ai_timer` did not end up less than than 1, but that could not happen because `cmd->scan_begin_arg` had already been checked to be at least the minimum required value (at least when `cmd->scan_begin_src == TRIG_TIMER`, which had also been checked to be the case). Fixes: b986be85 ("staging: comedi: usbduxsigma: tidy up analog input command support) Signed-off-by:
-
Ian Abbott authored
commit ad83dbd9 upstream. The "adl_pci7x3x" driver replaced the "adl_pci7230" and "adl_pci7432" drivers in commits 8f567c37 ("staging: comedi: new adl_pci7x3x driver") and 657f77d1 ("staging: comedi: remove adl_pci7230 and adl_pci7432 drivers"). Although the new driver code agrees with the user manuals for the respective boards, digital outputs stopped working on the PCI-7230. This has 16 digital output channels and the previous adl_pci7230 driver shifted the 16 bit output state left by 16 bits before writing to the hardware register. The new adl_pci7x3x driver doesn't do that. Fix it in `adl_pci7x3x_do_insn_bits()` by checking for the special case of the subdevice having only 16 channels and duplicating the 16 bit output state into both halves of the 32-bit register. That should work both for what the board actually does and for what the user manual says it should do. Fixes: 8f567c37 ("staging: comedi: new adl_pci7x3x driver") Signed-off-by:
-
Mateusz Kulikowski authored
commit 435009bb upstream. This patch fixes issue generated by commit ca93dcba ("staging: rtl8192e: Remove assert() macro") One negation was missed in conversion, therefore asserted message was always printed. For 1MB file downloaded via http, ~500 messages were generated. Signed-off-by:
Mateusz Kulikowski <mateusz.kulikowski@gmail.com> Signed-off-by:
-
Jan H. Schönherr authored
commit dd9d3843 upstream. There is a race condition in SMP bootup code, which may result in WARNING: CPU: 0 PID: 1 at kernel/workqueue.c:4418 workqueue_cpu_up_callback() or kernel BUG at kernel/smpboot.c:135! It can be triggered with a bit of luck in Linux guests running on busy hosts. CPU0 CPUn ==== ==== _cpu_up() __cpu_up() start_secondary() set_cpu_online() cpumask_set_cpu(cpu, to_cpumask(cpu_online_bits)); cpu_notify(CPU_ONLINE) <do stuff, see below> cpumask_set_cpu(cpu, to_cpumask(cpu_active_bits)); During the various CPU_ONLINE callbacks CPUn is online but not active. Several things can go wrong at that point, depending on the scheduling of tasks on CPU0. Variant 1: cpu_notify(CPU_ONLINE) workqueue_cpu_up_callback() rebind_workers() set_cpus_allowed_ptr() This call fails because it requires an active CPU; rebind_workers() ends with a warning: WARNING: CPU: 0 PID: 1 at kernel/workqueue.c:4418 workqueue_cpu_up_callback() Variant 2: cpu_notify(CPU_ONLINE) smpboot_thread_call() smpboot_unpark_threads() .. __kthread_unpark() __kthread_bind() wake_up_state() .. select_task_rq() select_fallback_rq() The ->wake_cpu of the unparked thread is not allowed, making a call to select_fallback_rq() necessary. Then, select_fallback_rq() cannot find an allowed, active CPU and promptly resets the allowed CPUs, so that the task in question ends up on CPU0. When those unparked tasks are eventually executed, they run immediately into a BUG: kernel BUG at kernel/smpboot.c:135! Just changing the order in which the online/active bits are set (and adding some memory barriers), would solve the two issues above. However, it would change the order of operations back to the one before commit 6acbfb96 ("sched: Fix hotplug vs. set_cpus_allowed_ptr()"), thus, reintroducing that particular problem. Going further back into history, we have at least the following commits touching this topic: - commit 2baab4e9 ("sched: Fix select_fallback_rq() vs cpu_active/cpu_online") - commit 5fbd036b ("sched: Cleanup cpu_active madness") Together, these give us the following non-working solutions: - secondary CPU sets active before online, because active is assumed to be a subset of online; - secondary CPU sets online before active, because the primary CPU assumes that an online CPU is also active; - secondary CPU sets online and waits for primary CPU to set active, because it might deadlock. Commit 875ebe94 ("powerpc/smp: Wait until secondaries are active & online") introduces an arch-specific solution to this arch-independent problem. Now, go for a more general solution without explicit waiting and simply set active twice: once on the secondary CPU after online was set and once on the primary CPU after online was seen. set_cpus_allowed_ptr()") Signed-off-by:
Jan H. Schönherr <jschoenh@amazon.de> Acked-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Anton Blanchard <anton@samba.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Joerg Roedel <jroedel@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Wilson <msw@amazon.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: 6acbfb96 ("sched: Fix hotplug vs. set_cpus_allowed_ptr()") Link: http://lkml.kernel.org/r/1439408156-18840-1-git-send-email-jschoenh@amazon.deSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Hartmut Knaack authored
commit 001fceb9 upstream. To iterate through the available frequencies of mma8452_hp_filter_cutoff[], the array size of a row of that table needs to be provided to _get_int_plus_micros_index(). Fixes: 1e79841a ("iio: mma8452: Add highpass filter configuration.") Signed-off-by:
Hartmut Knaack <knaack.h@gmx.de> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Lars-Peter Clausen authored
commit 7abad106 upstream. The different devices support by the adis16480 driver have slightly different scales for the gyroscope and accelerometer channels. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
-
Lars-Peter Clausen authored
commit c689a923 upstream. Add inverse unit conversion macro to convert from standard IIO units to units that might be used by some devices. Those are useful in combination with scale factors that are specified as IIO_VAL_FRACTIONAL. Typically the denominator for those specifications will contain the maximum raw value the sensor will generate and the numerator the value it maps to in a specific unit. Sometimes datasheets specify those in different units than the standard IIO units (e.g. degree/s instead of rad/s) and so we need to do a unit conversion. From a mathematical point of view it does not make a difference whether we apply the unit conversion to the numerator or the inverse unit conversion to the denominator since (x / y) / z = x / (y * z). But as the denominator is typically a larger value and we are rounding both the numerator and denominator to integer values using the later method gives us a better precision (E.g. the relative error is smaller if we round 8000.3 to 8000 rather than rounding 8.3 to 8). This is where in inverse unit conversion macros will be used. Marked for stable as used by some upcoming fixes. Signed-off-by:
-
Lars-Peter Clausen authored
commit 81665372 upstream. Use the correct scale for the adis16448 gyroscope output. Signed-off-by:
-
Cristina Opriceana authored
commit 1bdc0293 upstream. Change return value to 0 if no device is bound since unsigned int cannot support negative error codes. Fixes: f18e7a06 ("iio: Return -ENODEV for file operations if the device has been unregistered") Signed-off-by:
Cristina Opriceana <cristina.opriceana@gmail.com> Signed-off-by:
-
Cristina Opriceana authored
commit 41d903c0 upstream. Negative return values are not supported by iio_event_poll since its return type is unsigned int. Fixes: f18e7a06 ("iio: Return -ENODEV for file operations if the device has been unregistered") Signed-off-by:
-
Markus Pargmann authored
commit 06d2f6ca upstream. This patch adds selects for IIO_BUFFER and IIO_TRIGGERED_BUFFER. Without IIO_BUFFER, the driver does not compile. Signed-off-by:
Markus Pargmann <mpa@pengutronix.de> Reviewed-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by:
-
Martin Schwidefsky authored
commit 89b1145e upstream. The novx parameter disables the vector facility but the HWCAP_S390_VXRS bit in the ELf hardware capabilies is always set if the machine has the vector facility. If the user space program uses the "vx" string in the features field of /proc/cpuinfo to utilize vector instruction it will crash if the novx kernel paramter is set. Convert setup_hwcaps to an arch_initcall and use MACHINE_HAS_VX to decide if the HWCAPS_S390_VXRS bit needs to be set. Reported-by:
Ulrich Weigand <uweigand@de.ibm.com> Reviewed-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Takashi Iwai authored
commit 982b0b2d upstream. Fix a wrong logical AND (&&) used for the range check of CSR MMIO. Spotted nicely by gcc -Wlogical-op flag: drivers/gpu/drm/i915/intel_csr.c: In function ‘finish_csr_load’: drivers/gpu/drm/i915/intel_csr.c:353:41: warning: logical ‘and’ of mutually exclusive tests is always false [-Wlogical-op] Fixes: eb805623 ('drm/i915/skl: Add support to load SKL CSR firmware.') Signed-off-by:
Takashi Iwai <tiwai@suse.de> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Animesh Manna <animesh.manna@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Chris Wilson authored
commit acd29f7b upstream. In I915_READ64_2x32 we attempt to read a 64bit register using 2 32bit reads. Due to the nature of the registers we try to read in this manner, they may increment between the two instruction (e.g. a timestamp counter). To keep the result accurate, we repeat the read if we detect an overflow (i.e. the upper value varies). However, some hardware is just plain flaky and may endless loop as the the upper 32bits are not stable. Just give up after a couple of tries and report whatever we read last. v2: Use the most recent values when erring out on an unstable register. Reported-by: russianneuromancer@ya.ru Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91906Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
-
Chris Wilson authored
commit 51bc1404 upstream. There have been many hard to track down bugs whereby userspace forgot to flag a write buffer and then cause graphics corruption or a hung GPU when that buffer was later purged under memory pressure (as the buffer appeared clean, its pages would have been evicted rather than preserved and any changes more recent than in the backing storage would be lost). In retrospect this is a rare optimisation against memory pressure, already the slow path. If we always mark the buffer as dirty when accessed by the GPU, anything not used can still be evicted cheaply (ideal behaviour for mark-and-sweep eviction) but we do not run the risk of corruption. For correct read serialisation, userspace still has to notify when the GPU writes to an object. However, there are certain situations under which userspace may wish to tell white lies to the kernel... Signed-off-by:
-
Gaurav K Singh authored
commit 82425785 upstream. Just like single link MIPI panels, similarly for dual link panels, pipe to be configured is based on the DVO port from VBT Block 2. In hardware, Port A is mapped with Pipe A and Port C is mapped with Pipe B. This issue got introduced in - commit 7e9804fd Author: Jani Nikula <jani.nikula@intel.com> Date: Fri Jan 16 14:27:23 2015 +0200 drm/i915/dsi: add drm mipi dsi host support Signed-off-by:
Gaurav K Singh <gaurav.k.singh@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jonathon Jongsma authored
commit bd3e1c7c upstream. Due to some recent changes in drm_helper_probe_single_connector_modes_merge_bits(), old custom modes were not being pruned properly. In current kernels, drm_mode_validate_basic() is called to sanity-check each mode in the list. If the sanity-check passes, the mode's status gets set to to MODE_OK. In older kernels this check was not done, so old custom modes would still have a status of MODE_UNVERIFIED at this point, and would therefore be pruned later in the function. As a result of this new behavior, the list of modes for a device always includes every custom mode ever configured for the device, with the largest one listed first. Since desktop environments usually choose the first preferred mode when a hotplug event is emitted, this had the result of making it very difficult for the user to reduce the size of the display. The qxl driver did implement the mode_valid connector function, but it was empty. In order to restore the old behavior where old custom modes are pruned, we implement a proper mode_valid function for the qxl driver. This function now checks each mode against the last configured custom mode and the list of standard modes. If the mode doesn't match any of these, its status is set to MODE_BAD so that it will be pruned as expected. Signed-off-by:
Jonathon Jongsma <jjongsma@redhat.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Lukas Wunner authored
commit 69f92f67 upstream. Commit 92122789 ("drm/i915: preserve SSC if previously set v3") added code to intel_modeset_gem_init to override the SSC status read from VBT with the SSC status set by BIOS. However, intel_modeset_gem_init is invoked *after* intel_modeset_init, which calls intel_setup_outputs, which *modifies* SSC status by way of intel_init_pch_refclk. So unlike advertised, intel_modeset_gem_init doesn't preserve the SSC status set by BIOS but whatever intel_init_pch_refclk decided on. This is a problem on dual gpu laptops such as the MacBook Pro which require either a handler to switch DDC lines, or the discrete gpu to proxy DDC/AUX communication: Both the handler and the discrete gpu may initialize after the i915 driver, and consequently, an LVDS connector may initially seem disconnected and the SSC therefore is disabled by intel_init_pch_refclk, but on reprobe the connector may turn out to be connected and the SSC must then be enabled. Due to 92122789 however, the SSC is not enabled on reprobe since it is assumed BIOS disabled it while in fact it was disabled by intel_init_pch_refclk. Also, because the SSC status is preserved so late, the preserved value only ever gets used on resume but not on panel initialization: intel_modeset_init calls intel_init_display which indirectly calls intel_panel_use_ssc via multiple subroutines, *before* the BIOS value overrides the VBT value in intel_modeset_gem_init (intel_panel_use_ssc is the sole user of dev_priv->vbt.lvds_use_ssc). Fix this by moving the code introduced by 92122789 from intel_modeset_gem_init to intel_modeset_init before the invocation of intel_setup_outputs and intel_init_display. Add a DRM_DEBUG_KMS as suggested way back by Jani: http://lists.freedesktop.org/archives/intel-gfx/2014-June/046666.html Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115Tested-by:
Paul Hordiienko <pvt.gord@gmail.com> [MBP 6,2 2010 intel ILK + nvidia GT216 pre-retina] Tested-by:
William Brown <william@blackhats.net.au> [MBP 8,2 2011 intel SNB + amd turks pre-retina] Tested-by:
Lukas Wunner <lukas@wunner.de> [MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina] Tested-by:
Bruno Bierbaumer <bruno@bierbaumer.net> [MBP 11,3 2013 intel HSW + nvidia GK107 retina -- work in progress] Fixes: 92122789 ("drm/i915: preserve SSC if previously set v3") Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Alex Deucher authored
commit be9fd2e9 upstream. Using the wrong watermwark value for the secondary watermark. Copy paste typo. Noticed by Mykola. Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Alex Deucher authored
commit 99a09238 upstream. Using the wrong watermwark value for the secondary watermark. Copy paste typo. Noticed by Mykola. Reviewed-by:
-
Alex Deucher authored
commit 52293c67 upstream. Use pci_alloc_consistent rather than kzalloc since we need 256 byte aligned memory for the ring buffer. v2: fix copy paste typo in free function noticed by Jammy. bug: https://bugs.freedesktop.org/show_bug.cgi?id=91749Reviewed-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Jammy Zhou <Jammy.Zhou@amd.com> Signed-off-by:
-
Alex Deucher authored
commit a887adad upstream. This is a port of: DRM - radeon: Don't link train DisplayPort on HPD until we get the dpcd to amdgpu. Signed-off-by:
-
Jammy Zhou authored
commit 21df89a5 upstream. In function 'amdgpu_uvd_cs_pass2': warning: 'min_ctx_size' may be used uninitialized in this function buf_sizes[0x4] = min_ctx_size; ^ note: 'min_ctx_size' was declared here unsigned image_size, tmp, min_dpb_size, num_dpb_buffer, min_ctx_size; ^ Signed-off-by:
-
