- 21 Sep, 2015 40 commits
-
-
Michael van der Westhuizen authored
commit c4fe57f7 upstream. The commit dd114443 ("spi: dw-spi: Convert 16bit accesses to 32bit accesses") changed all 16bit accesses in the DW_apb_ssi driver to 32bit. This, unfortunately, breaks data register access on picoXcell, where the DW IP needs data register accesses to be word accesses (all other accesses appear to be OK). This change introduces a new master variable to allow interface drivers to specify that 16bit data transfer I/O is required. This change also introduces the ability to set this variable via device tree bindings in the MMIO interface driver. Both the core and the MMIO interface driver default to the current 32bit behaviour. Before this change, on a picoXcell pc3x3: spi_master spi32766: interrupt_transfer: fifo overrun/underrun m25p80 spi32766.0: error -5 reading 9f m25p80: probe of spi32766.0 failed with error -5 After this change: m25p80 spi32766.0: m25p40 (512 Kbytes) Fixes: dd114443 ("spi: dw-spi: Convert 16bit accesses to 32bit accesses") Signed-off-by:
Michael van der Westhuizen <michael@smart-africa.com> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sifan Naeem authored
commit 9176c665 upstream. drivers/spi/spi-img-spfi.c: In function 'img_spfi_setup': drivers/spi/spi-img-spfi.c:446: warning: 'ret' may be used uninitialized in this function. Fixes: commit b03ba9e3 ("spi: img-spfi: fix multiple calls to request gpio") Signed-off-by:
Sifan Naeem <sifan.naeem@imgtec.com> Signed-off-by:
-
Sifan Naeem authored
commit b03ba9e3 upstream. spfi_setup may be called many times by the spi framework, but gpio_request_one can only be called once without freeing, repeatedly calling gpio_request_one will cause an error to be thrown, which causes the request to spi_setup to be marked as failed. We can have a per-spi_device flag that indicates whether or not the gpio has been requested. If the gpio has already been requested use gpio_direction_output to set the direction of the gpio. Fixes: 8c2c8c03 ("spi: img-spfi: Control CS lines with GPIO") Signed-off-by:
-
Sifan Naeem authored
commit 011710e2 upstream. Calling spfi_wait_all_done is not required if the transfer has timed out before all data is transferred. spfi_wait_all_done polls for Alldone interrupt which is triggered to mark the transfer as complete and to indicate it is now safe to issue a new transfer. Fixes: 8c2c8c03 ("spi: img-spfi: Control CS lines with GPIO") Signed-off-by:
Andrew Bresticker <abrestic@chromium.org> Signed-off-by:
-
Koji Matsuoka authored
commit fe78d0b7 upstream. The upper limit of Tx/Rx FIFO size is 64 word by the specification of H/W. This patch corrects to 64 word from 256 word. Signed-off-by:
Koji Matsuoka <koji.matsuoka.xm@renesas.com> Signed-off-by:
Yoshihiro Kaneko <ykaneko0929@gmail.com> Signed-off-by:
-
Lars Persson authored
commit 26a67ec4 upstream. This patch fixes a regression introduced by commit 232a5adc ("spi: bitbang: only toggle bitchanges"). The attempt to optimize writes of consecutive bit patterns broke most of the combinations of word size and SPI modes due to selecting the wrong bit as the MSB value. Fixes: 232a5adc (spi: bitbang: only toggle bitchanges) Signed-off-by:
Lars Persson <larper@axis.com> Signed-off-by:
-
Martin Sperl authored
commit acace73d upstream. When using reverse polarity for clock (spi-cpol) on a device the clock line gets altered after chip-select has been asserted resulting in an additional clock beat, which confuses hardware. This did not show when using native-CS, as the same register is used to control cs as well as polarity, so the changes came into effect at the same time. Unfortunately this is not true with gpio-cs. To avoid this situation this patch moves the setup of polarity (spi-cpol and spi-cpha) outside of the chip-select into prepare_message, which is run prior to asserting chip-select. Also fixes resetting 3-wire mode after use of rx-mode, so that a 3-Wire sequence TX, RX, TX works as well (right now it runs TX, RX, RX instead) Reported-by:
Noralf Tronnes <noralf@tronnes.org> Signed-off-by:
Martin Sperl <kernel@martin.sperl.org> Signed-off-by:
-
Zhang Rui authored
commit 91f15fb3 upstream. On multi-function JMicron SATA/PATA/AHCI devices, the PATA controller at function 1 doesn't work if it is powered on before the SATA controller at function 0. The result is that PATA doesn't work after resume, and we print messages like this: pata_jmicron 0000:02:00.1: Refused to change power state, currently in D3 irq 17: nobody cared (try booting with the "irqpoll" option) Async resume was introduced in v3.15 by 76569faa ("PM / sleep: Asynchronous threads for resume_noirq"). Prior to that, we powered on the functions in order, so this problem shouldn't happen. e6b7e41c ("ata: Disabling the async PM for JMicron chip 363/361") solved the problem for JMicron 361 and 363 devices. With async suspend disabled, we always power on function 0 before function 1. Barto then reported the same problem with a JMicron 368 (see comment #57 in the bugzilla). Rather than extending the blacklist piecemeal, disable async suspend for all JMicron multi-function SATA/PATA/AHCI devices. This quirk could stay in the ahci and pata_jmicron drivers, but it's likely the problem will occur even if pata_jmicron isn't loaded until after the suspend/resume. Making it a PCI quirk ensures that we'll preserve the power-on order even if the drivers aren't loaded. [bhelgaas: changelog, limit to multi-function, limit to IDE/ATA] Link: https://bugzilla.kernel.org/show_bug.cgi?id=81551Reported-and-tested-by:
Barto <mister.freeman@laposte.net> Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
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:
Alexander Duyck <alexander.h.duyck@redhat.com> Signed-off-by:
-
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:
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 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 <zdenko.pulitika@imgtec.com> Signed-off-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:
-
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:
-
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:
-
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:
Jonathan Cameron <jic23@kernel.org> 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:
-
Sebastian Ott authored
commit a313bdc5 upstream. Fix this error when compiling with CONFIG_SMP=n and CONFIG_DYNAMIC_DEBUG=y: drivers/s390/char/sclp_early.c: In function 'sclp_read_info_early': drivers/s390/char/sclp_early.c:87:19: error: 'EBUSY' undeclared (first use in this function) } while (rc == -EBUSY); ^ Signed-off-by:
Sebastian Ott <sebott@linux.vnet.ibm.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:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-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 86b7709d upstream. Support for output_csc is only available on DCE5 and newer so don't mess with the HDMI quantization_range on pre-DCE5 asics. bug: https://bugs.freedesktop.org/show_bug.cgi?id=83226Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Alex Deucher authored
commit 7040c399 upstream. AUX addresses are 20 bits long. Send out the entire address instead of just the low 16 bits. Port of: drm/radeon/atom: Send out the full AUX address to radeon non-atom aux path Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
