summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2015-11-16ravb: Fix int mask value overwritten issueMasaru Nagai
When RX/TX interrupt for Network Control queue and Best Effort queue is issued at the same time, the interrupt mask of Network Control queue will be reset when the mask of Best Effort queue is set. This patch fixes this problem. Signed-off-by: Masaru Nagai <masaru.nagai.vx@renesas.com> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-11-16net: smsc911x: Reset PHY during initializationPavel Fedin
On certain hardware after software reboot the chip may get stuck and fail to reinitialize during reset. This can be fixed by ensuring that PHY is reset too. Old PHY resetting method required operational MDIO interface, therefore the chip should have been already set up. In order to be able to function during probe, it is changed to use PMT_CTRL register. The problem could be observed on SMDK5410 board. Signed-off-by: Pavel Fedin <p.fedin@samsung.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-11-16bpf, arm64: start flushing icache range from headerDaniel Borkmann
While recently going over ARM64's BPF code, I noticed that the icache range we're flushing should start at header already and not at ctx.image. Reason is that after b569c1c622c5 ("net: bpf: arm64: address randomize and write protect JIT code"), we also want to make sure to flush the random-sized trap in front of the start of the actual program (analogous to x86). No operational differences from user side. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Zi Shen Lim <zlim.lnx@gmail.com> Cc: Alexei Starovoitov <ast@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-11-16bpf, arm: start flushing icache range from headerDaniel Borkmann
During review I noticed that the icache range we're flushing should start at header already and not at ctx.image. Reason is that after 55309dd3d4cd ("net: bpf: arm: address randomize and write protect JIT code"), we also want to make sure to flush the random-sized trap in front of the start of the actual program (analogous to x86). No operational differences from user side. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Tested-by: Nicolas Schichan <nschichan@freebox.fr> Cc: Alexei Starovoitov <ast@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-11-16bpf: samples: exclude asm/sysreg.h for arm64Yang Shi
commit 338d4f49d6f7114a017d294ccf7374df4f998edc ("arm64: kernel: Add support for Privileged Access Never") includes sysreg.h into futex.h and uaccess.h. But, the inline assembly used by asm/sysreg.h is incompatible with llvm so it will cause BPF samples build failure for ARM64. Since sysreg.h is useless for BPF samples, just exclude it from Makefile via defining __ASM_SYSREG_H. Signed-off-by: Yang Shi <yang.shi@linaro.org> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-11-16arm64: bpf: fix JIT frame pointer setupYang Shi
BPF fp should point to the top of the BPF prog stack. The original implementation made it point to the bottom incorrectly. Move A64_SP to fp before reserve BPF prog stack space. CC: Zi Shen Lim <zlim.lnx@gmail.com> CC: Xi Wang <xi.wang@gmail.com> Signed-off-by: Yang Shi <yang.shi@linaro.org> Reviewed-by: Zi Shen Lim <zlim.lnx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-11-16net: phy: vitesse: add support for VSC8601Måns Rullgård
This adds support for the Vitesse VSC8601 PHY. Generic functions are used for everything except interrupt handling. Signed-off-by: Mans Rullgard <mans@mansr.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-11-16net: phy: at803x: support interrupt on 8030 and 8035Måns Rullgård
Commit 77a993942 "phy/at8031: enable at8031 to work on interrupt mode" added interrupt support for the 8031 PHY but left out the other two chips supported by this driver. This patch sets the .ack_interrupt and .config_intr functions for the 8030 and 8035 drivers as well. Signed-off-by: Mans Rullgard <mans@mansr.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-11-16ip_tunnel: disable preemption when updating per-cpu tstatsJason A. Donenfeld
Drivers like vxlan use the recently introduced udp_tunnel_xmit_skb/udp_tunnel6_xmit_skb APIs. udp_tunnel6_xmit_skb makes use of ip6tunnel_xmit, and ip6tunnel_xmit, after sending the packet, updates the struct stats using the usual u64_stats_update_begin/end calls on this_cpu_ptr(dev->tstats). udp_tunnel_xmit_skb makes use of iptunnel_xmit, which doesn't touch tstats, so drivers like vxlan, immediately after, call iptunnel_xmit_stats, which does the same thing - calls u64_stats_update_begin/end on this_cpu_ptr(dev->tstats). While vxlan is probably fine (I don't know?), calling a similar function from, say, an unbound workqueue, on a fully preemptable kernel causes real issues: [ 188.434537] BUG: using smp_processor_id() in preemptible [00000000] code: kworker/u8:0/6 [ 188.435579] caller is debug_smp_processor_id+0x17/0x20 [ 188.435583] CPU: 0 PID: 6 Comm: kworker/u8:0 Not tainted 4.2.6 #2 [ 188.435607] Call Trace: [ 188.435611] [<ffffffff8234e936>] dump_stack+0x4f/0x7b [ 188.435615] [<ffffffff81915f3d>] check_preemption_disabled+0x19d/0x1c0 [ 188.435619] [<ffffffff81915f77>] debug_smp_processor_id+0x17/0x20 The solution would be to protect the whole this_cpu_ptr(dev->tstats)/u64_stats_update_begin/end blocks with disabling preemption and then reenabling it. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2015-11-16mtd: nand: fix shutdown/reboot for multi-chip systemsBrian Norris
If multiple NAND chips are registered to the same controller, then when rebooting the system, the first one will grab the controller lock, while the second will wait forever for the first one to release it. i.e., a classic deadlock. This problem was solved for a similar case (suspend/resume) back in commit 6b0d9a841249 ("mtd: nand: fix multi-chip suspend problem"), and the shutdown state really isn't much different for us, so rather than adding a new special case to nand_get_device(), we can just overload the FL_PM_SUSPENDED state. Now, multiple chips can "get" the same controller lock (preventing further I/O), while we still allow other chips to pass through nand_shutdown(). Original report: http://thread.gmane.org/gmane.linux.drivers.mtd/59726 http://lists.infradead.org/pipermail/linux-mtd/2015-July/059992.html Fixes: 72ea403669c7 ("mtd: nand: added nand_shutdown") Reported-by: Andrew E. Mileski <andrewm@isoar.ca> Signed-off-by: Brian Norris <computersforpeace@gmail.com> Cc: Scott Branden <sbranden@broadcom.com> Cc: Andrew E. Mileski <andrewm@isoar.ca> Acked-by: Scott Branden <sbranden@broadcom.com> Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
2015-11-16mtd: jz4740_nand: fix build on jz4740 after removing gpio.hBrian Norris
Fallout from commit 832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h") We see errors like this: drivers/mtd/nand/jz4740_nand.c: In function 'jz_nand_detect_bank': drivers/mtd/nand/jz4740_nand.c:340:9: error: 'JZ_GPIO_MEM_CS0' undeclared (first use in this function) drivers/mtd/nand/jz4740_nand.c:340:9: note: each undeclared identifier is reported only once for each function it appears in drivers/mtd/nand/jz4740_nand.c:359:2: error: implicit declaration of function 'jz_gpio_set_function' [-Werror=implicit-function-declaration] drivers/mtd/nand/jz4740_nand.c:359:29: error: 'JZ_GPIO_FUNC_MEM_CS0' undeclared (first use in this function) drivers/mtd/nand/jz4740_nand.c:399:29: error: 'JZ_GPIO_FUNC_NONE' undeclared (first use in this function) drivers/mtd/nand/jz4740_nand.c: In function 'jz_nand_probe': drivers/mtd/nand/jz4740_nand.c:528:13: error: 'JZ_GPIO_MEM_CS0' undeclared (first use in this function) drivers/mtd/nand/jz4740_nand.c: In function 'jz_nand_remove': drivers/mtd/nand/jz4740_nand.c:555:14: error: 'JZ_GPIO_MEM_CS0' undeclared (first use in this function) Patched similarly to: https://patchwork.linux-mips.org/patch/11089/ Fixes: 832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h") Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2015-11-16clocksource: Disallow drivers for ARCH_USES_GETTIMEOFFSETArnd Bergmann
We can now select clocksource drivers like ti-32k and CONFIG_OF on ancient machines that still use gettimeoffset, and the combination results in a link error. arch/arm/kernel/built-in.o: In function `time_init': (.init.text+0xc28): undefined reference to `clocksource_probe' The reason for this is that the Makefile is hidden behind CONFIG_ARCH_USES_GETTIMEOFFSET, but the Kconfig file is not, and it has shown up just now because the ti-32k driver was added and can be selected using COMPILE_TEST on all platforms. This patch hides the Kconfig menu in CONFIG_ARCH_USES_GETTIMEOFFSET as well. Fixes: dfedaf105d60 "clocksource: ti-32k: make it depend on GENERIC_CLOCKSOURCE" Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: linux-arm-kernel@lists.infradead.org Cc: Felipe Balbi <balbi@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Link: http://lkml.kernel.org/r/7579471.4N90fYPQOK@wuerfel Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-11-16clocksource/fsl: Avoid harmless 64-bit warningsArnd Bergmann
The ftm_clockevent_init passes the value of "~0UL" into a function that takes a 32-bit argument, which drops the upper 32 bits, as gcc warns about on ARM64: clocksource/fsl_ftm_timer.c: In function 'ftm_clockevent_init': clocksource/fsl_ftm_timer.c:206:13: warning: large integer implicitly truncated to unsigned type [-Woverflow] This was obviously unintended behavior, and is easily avoided by using '~0u' as the integer literal, because that is 32-bit wide on all architectures. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: linux-arm-kernel@lists.infradead.org Cc: Xiubo Li <Li.Xiubo@freescale.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <kernel@pengutronix.de> Cc: Stefan Agner <stefan@agner.ch> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Link: http://lkml.kernel.org/r/3990834.xnjhm37Grs@wuerfel Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-11-16hwmon: (scpi) skip unsupported sensors properlySudeep Holla
Currently it's assumed that firmware exports only the class of sensors supported by the driver. However with newer firmware or SCPI protocol revision, support for newer classes of sensors can be present. The driver fails to probe with the following warning if an unsupported class of sensor is encountered in the firmware. sysfs: cannot create duplicate filename '/devices/platform/scpi/scpi:sensors/hwmon/hwmon0/' ------------[ cut here ]------------ WARNING: at fs/sysfs/dir.c:31 Modules linked in: CPU: 0 PID: 6 Comm: kworker/u12:0 Not tainted 4.3.0-rc7 #137 Hardware name: ARM Juno development board (r0) (DT) Workqueue: deferwq deferred_probe_work_func PC is at sysfs_warn_dup+0x54/0x78 LR is at sysfs_warn_dup+0x54/0x78 This patch fixes the above issue by skipping through the unsupported class of SCPI sensors. Fixes: 68acc77a2d51 ("hwmon: Support thermal zones registration for SCP temperature sensors") Fixes: ea98b29a05e9 ("hwmon: Support sensors exported via ARM SCP interface") Cc: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Punit Agrawal <punit.agrawal@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-11-16hwmon: (scpi) add thermal-of dependencyArnd Bergmann
The newly added scpi thermal support is broken when the scpi driver is built-in but the thermal driver is a loadable module: drivers/built-in.o: In function `scpi_hwmon_probe': (.text+0x444d70): undefined reference to `thermal_zone_of_sensor_unregister' (.text+0x444d94): undefined reference to `thermal_zone_of_sensor_register' drivers/built-in.o: In function `scpi_hwmon_remove': (text+0x444e6c): undefined reference to `thermal_zone_of_sensor_unregister' This uses the same Kconfig trick that we have in a couple of other drivers already to ensure we can only select the driver in valid configurations when either THERMAL_OF is disabled, or when with a dependency on CONFIG_THERMAL that can force SCPI to be a loadable module in the case I was hitting. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 68acc77a2d51 ("hwmon: Support thermal zones registration for SCP temperature sensors") Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2015-11-16ext2, ext4: warn when mounting with dax enabledDan Williams
Similar to XFS warn when mounting DAX while it is still considered under development. Also, aspects of the DAX implementation, for example synchronization against multiple faults and faults causing block allocation, depend on the correct implementation in the filesystem. The maturity of a given DAX implementation is filesystem specific. Cc: <stable@vger.kernel.org> Cc: "Theodore Ts'o" <tytso@mit.edu> Cc: Matthew Wilcox <willy@linux.intel.com> Cc: linux-ext4@vger.kernel.org Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reported-by: Dave Chinner <david@fromorbit.com> Acked-by: Jan Kara <jack@suse.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2015-11-16USB: qcserial: Fix support for HP lt4112 LTE/HSPA+ Gobi 4G ModemBjørn Mork
The DEVICE_HWI type was added under the faulty assumption that Huawei devices based on Qualcomm chipsets and firmware use the static USB interface numbering known from Gobi devices. But this model does not apply to Huawei devices like the HP branded lt4112 (Huawei me906e). Huawei firmwares will dynamically assign interface numbers. Functions are renumbered when the firmware is reconfigured. Fix by changing the DEVICE_HWI type to use a simplified version of Huawei's subclass + protocol scheme: Blacklisting known network interface combinations and assuming the rest are serial. Reported-and-tested-by: Muri Nicanor <muri+libqmi@immerda.ch> Tested-by: Martin Hauke <mardnh@gmx.de> Cc: <stable@vger.kernel.org> Fixes: e7181d005e84 ("USB: qcserial: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem") Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Johan Hovold <johan@kernel.org>
2015-11-17drivers: sh: Get rid of CONFIG_ARCH_SHMOBILE_MULTIGeert Uytterhoeven
Shmobile is all multiplatform these days, so get rid of the reference to CONFIG_ARCH_SHMOBILE_MULTI. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2015-11-16usb: phy: omap-otg: fix uninitialized pointerAaro Koskinen
otg_dev->extcon was referenced before otg_dev was initialized. Fix. Cc: <stable@vger.kernel.org> # v4.3 Fixes: a2fd2423240f ("usb: phy: omap-otg: Replace deprecated API of extcon") Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-11-16usb: musb: core: fix order of arguments to ulpi write callbackUwe Kleine-König
There is a bit of a mess in the order of arguments to the ulpi write callback. There is int ulpi_write(struct ulpi *ulpi, u8 addr, u8 val) in drivers/usb/common/ulpi.c; struct usb_phy_io_ops { ... int (*write)(struct usb_phy *x, u32 val, u32 reg); } in include/linux/usb/phy.h. The callback registered by the musb driver has to comply to the latter, but up to now had "offset" first which effectively made the function broken for correct users. So flip the order and while at it also switch to the parameter names of struct usb_phy_io_ops's write. Fixes: ffb865b1e460 ("usb: musb: add ulpi access operations") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-11-16usb: dwc3: pci: add support for Intel Broxton SOCHeikki Krogerus
PCI IDs for Broxton based platforms. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
2015-11-16drm/amdgpu: update pd while updating vm as wellChunming Zhou
Change-Id: I93a861cd6707f7d91672b9e19757cc50008cd7a2 Signed-off-by: Chunming Zhou <David1.Zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2015-11-16drm/amdgpu: fix handling order in scheduler CSChristian König
We need to clear parser.ibs and num_ibs before amd_sched_fence_create, otherwise the IB could be freed twice if fence creates fails. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
2015-11-16drm/amdgpu: fix incorrect mutex usage v3Christian König
Before this patch the scheduler fence was created when we push the job into the queue, so we could only get the fence after pushing it. The mutex now was necessary to prevent the thread pushing the jobs to the hardware from running faster than the thread pushing the jobs into the queue. Otherwise the thread pushing jobs into the queue would have accessed possible freed up memory when it tries to get a reference to the fence. So what you get in the end is thread A: mutex_lock(&job->lock); ... Kick of thread B. ... mutex_unlock(&job->lock); And thread B: mutex_lock(&job->lock); .... mutex_unlock(&job->lock); kfree(job); I'm actually not sure if I'm still up to date on this, but this usage pattern used to be not allowed with mutexes. See here as well https://lwn.net/Articles/575460/. v2: remove unrelated changes, fix missing owner v3: rebased, add more commit message Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2015-11-16drm/amdgpu: cleanup scheduler fence get/put danceChristian König
The code was correct, but getting two references when the ownership is linearly moved on is a bit awkward and just overhead. Signed: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2015-11-16drm/amdgpu: add command submission workflow tracepointChunming Zhou
OGL needs these tracepoints to investigate performance issue. Change-Id: I5e58187d061253f7d665dfce8e4e163ba91d3e2b Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
2015-11-16drm/amdgpu: update Fiji's tiling mode tableFlora Cui
Change-Id: I925c15015390113f7e27746ec5751eaa6a92c2a7 Signed-off-by: Flora Cui <Flora.Cui@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2015-11-16drm/amdgpu: fix bug that can't enter thermal interrupt for bonaire.Rex Zhu
Set reversed bit to enable/disable thermal interrupt. Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
2015-11-16drm/amdgpu: fix seq_printf format stringArnd Bergmann
The amdgpu driver has a debugfs interface that shows the amount of VRAM in use, but the newly added code causes a build error on all 32-bit architectures: drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:1076:17: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'long long int' [-Wformat=] This fixes the format string to use "%llu" for printing 64-bit numbers, which works everywhere, as long as we also cast to 'u64'. Unlike atomic64_t, u64 is defined as 'unsigned long long' on all architectures. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: a2ef8a974931 ("drm/amdgpu: add vram usage into debugfs") Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-11-16drm/radeon: fix quirk for MSI R7 370 Armor 2XMaxim Sheviakov
There was a typo in the original. bug: https://bugs.freedesktop.org/show_bug.cgi?id=92865 Signed-off-by: Maxim Sheviakov <mrader3940@yandex.ru> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-11-16drm/amdgpu: Fix default page access routingJay Cornwall
The VM default page (used when a VM translation fails) is allocated in system memory. The VM is misconfigured to interpret the physical address as referencing a VRAM physical page. Route default page accesses to system memory. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Jay Cornwall <jay@jcornwall.me> Cc: <stable@vger.kernel.org> # v4.2+ Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-11-16drm/radeon: unconditionally set sysfs_initializedAlex Deucher
Avoids spew on resume for systems where sysfs may fail even on init. bug: https://bugzilla.kernel.org/show_bug.cgi?id=106851 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-11-16drm/amdgpu: cleanup amdgpu_cs_parser handlingChristian König
No need any more to allocate that structure dynamically, just put it on the stack. This is a start to cleanup some of the scheduler fallouts. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2015-11-16drm/amdgpu: fix leaking the IBs on errorChristian König
Fixing a memory leak when the scheduler is enabled. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2015-11-16drm/amd: add kmem cache for sched fenceChunming Zhou
Change-Id: I45bb8ff10ef05dc3b15e31a77fbcf31117705f11 Signed-off-by: Chunming Zhou <David1.Zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2015-11-16drm/amdgpu: add kmem cache for amdgpu fenceChunming Zhou
Change-Id: I5ad8dd156ccf27a6f18004aa0a215a0925b6e67b Signed-off-by: Chunming Zhou <David1.Zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
2015-11-16drm/amdgpu: update fiji_mgcg_cgcg_init tableFlora Cui
Change-Id: If44b8057741c78208f1976f60f31b535c944d0bd Signed-off-by: Flora Cui <Flora.Cui@amd.com> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
2015-11-16drm/amdgpu: use common fence for amdgpu_vm_fenceChristian König
Just cleanup the function parameters. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2015-11-16drm/amdgpu: use fence_is_later() for vm_flush as well v2Christian König
v2: remove superfluous check Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1) Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
2015-11-16drm/amdgpu: use a timer for fence fallbackChristian König
Less overhead than a work item and also adds proper cleanup handling. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com>
2015-11-16drm/amdgpu: remove fence trace pointsChristian König
Mostly unused and replaced by the common trace points. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com>
2015-11-16drm/amdgpu: update Fiji's mmPA_SC_RASTER_CONFIG valueFlora Cui
Change-Id: I6d138306a878450e5bf8a77a2f1aacc380a39fe5 Signed-off-by: Flora Cui <Flora.Cui@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
2015-11-16drm/radeon: Only prompt for enabling PAT when we'd allow write-combiningMichel Dänzer
No use bothering users about this for whom we disable write-combining for other reasons anyway. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-11-16drm/radeon: Always disable RADEON_GEM_GTT_UC along with RADEON_GEM_GTT_WCMichel Dänzer
Write-combining is a CPU feature. From the GPU POV, these both simply mean no GPU<->CPU cache coherency. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-11-16drm/radeon: Disable uncacheable CPU mappings of GTT with RV6xxMichel Dänzer
They reportedly cause random GPU hangs. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91268 Reviewed-by: Christian König <christian.koenig@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-11-16drm/i915: get runtime PM reference around GEM set_caching IOCTLImre Deak
After Damien's D3 fix I started to get runtime suspend residency for the first time and that revealed a breakage on the set_caching IOCTL path that accesses the HW but doesn't take an RPM ref. Fix this up. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: stable@vger.kernel.org Link: http://patchwork.freedesktop.org/patch/msgid/1446665132-22491-1-git-send-email-imre.deak@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-11-16drm/i915: Fix GT frequency roundingMika Kuoppala
When we set and later readback a frequency value through sysfs interface, igt/pm_rpm assumes that we get same value back if it matches hw granularity. On bxt we have found out that this is not always the case. Currently frequency - hw ratio - frequency conversions round down, with few exceptions on platforms that have more specific conversions. On bxt the supported range can be for example from 100Mhz to 650Mhz. Midpoint is then calculated by test to be 375 which pm_rps uses to find a closest hw supported frequency. That is 366 (ratio 22), which it then writes back. But as the rounding down kicks in, driver actually sets 350 instead of 366, as 366 is 2/3 below 22 * 50/3. Fix this by rounding to closest instead of rounding down in freq-ratio-freq conversions. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92768 Testcase: igt/pm_rps/basic-api Tested-by: Bob Paauwe <bob.j.paauwe@intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447435781-23416-1-git-send-email-mika.kuoppala@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-11-16USB: ti_usb_3410_5052: Add Honeywell HGI80 IDDavid Woodhouse
The Honeywell HGI80 is a wireless interface to the evohome connected thermostat. It uses a TI 3410 USB-serial port. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan@kernel.org>
2015-11-16USB: serial: option: add support for Novatel MiFi USB620LAleksander Morgado
Also known as Verizon U620L. The device is modeswitched from 1410:9020 to 1410:9022 by selecting the 4th USB configuration: $ sudo usb_modeswitch –v 0x1410 –p 0x9020 –u 4 This configuration provides a ECM interface as well as TTYs ('Enterprise Mode' according to the U620 Linux integration guide). Signed-off-by: Aleksander Morgado <aleksander@aleksander.es> Cc: stable <stable@vger.kernel.org> Signed-off-by: Johan Hovold <johan@kernel.org>
2015-11-16USB: qcserial: Add support for Quectel EC20 Mini PCIe modulePetr Štetiar
It seems like this device has same vendor and product IDs as G2K devices, but it has different number of interfaces(4 vs 5) and also different interface layout which makes it currently unusable: usbcore: registered new interface driver qcserial usbserial: USB Serial support registered for Qualcomm USB modem usb 2-1.2: unknown number of interfaces: 5 lsusb output: Bus 002 Device 003: ID 05c6:9215 Qualcomm, Inc. Acer Gobi 2000 Wireless Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x05c6 Qualcomm, Inc. idProduct 0x9215 Acer Gobi 2000 Wireless Modem bcdDevice 2.32 iManufacturer 1 Quectel iProduct 2 Quectel LTE Module iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 209 bNumInterfaces 5 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Signed-off-by: Petr Štetiar <ynezz@true.cz> Cc: stable <stable@vger.kernel.org> [johan: rename define and add comment ] Signed-off-by: Johan Hovold <johan@kernel.org>