- 20 10月, 2017 8 次提交
-
-
由 Stefan Roese 提交于
The patch edf10919 [dmaengine: altera: fix spinlock usage] missed to change 2 occurrences of spin_unlock_bh() to spin_unlock_irqrestore(). This patch fixes this by moving to the IRQ-safe call in the error paths as well. Fixes: edf10919 (dmaengine: altera: fix spinlock usage) Signed-off-by: NStefan Roese <sr@denx.de> Reviewed-by: NSylvain Lesne <lesne@alse-fr.com> [add fixes tag and fix typo in log] Signed-off-by: NVinod Koul <vinod.koul@intel.com>
-
由 Dmitry Torokhov 提交于
Before trying to use CDC union descriptor, try to validate whether that it is sane by checking that intf->altsetting->extra is big enough and that descriptor bLength is not too big and not too small. Reported-by: NAndrey Konovalov <andreyknvl@google.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Roderick Colenbrander 提交于
Introduce a device table used for blacklisting devices. We currently blacklist the motion sensor subdevice of THQ Udraw and Sony ds3/ds4. Signed-off-by: NRoderick Colenbrander <roderick.colenbrander@sony.com> [dtor: siwtched to blacklist built on input_device_id and using input_match_device_id()] Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Dmitry Torokhov 提交于
Let's allow matching input devices on their property bits, both in-kernel and when generating module aliases. Tested-by: NRoderick Colenbrander <roderick.colenbrander@sony.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Dmitry Torokhov 提交于
Factor out and export input_match_device_id() so that modules may use it. It will be needed by joydev to blacklist accelerometers in composite devices. Tested-by: NRoderick Colenbrander <roderick.colenbrander@sony.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Paul Cercueil 提交于
The Goodix panel triggers an interrupt on touch events. However, its registers will contain the valid values a short time after the interrupt, and not when it's raised. At that moment, the 'buffer status' bit is set. Previously, if the 'buffer status' bit was not set when the registers were read, the data was discarded and no input event was emitted, causing "finger down" or "finger up" events to be missed sometimes. This went unnoticed until v4.9, as the DesignWare I2C driver commonly used with this driver had enough latency for that bug to never trigger until commit 2702ea7d ("i2c: designware: wait for disable/enable only if necessary"). Now, in the IRQ handler we will poll (with a timeout) the 'buffer status' bit and process the data of the panel as soon as this bit gets set. Note that the Goodix panel will send a few spurious interrupts after the 'finger up' event, in which the 'buffer status' bit will never be set. Cc: Bastien Nocera <hadess@hadess.net> Cc: russianneuromancer@ya.ru Signed-off-by: NPaul Cercueil <paul@crapouillou.net> [hdegoede@redhat.com: Change poll loop to use jiffies, add comment about typical poll time] Signed-off-by: NHans de Goede <hdegoede@redhat.com> [dtor: rearranged control flow a bit to avoid explicit goto and double check] Reviewed-by: NBastien Nocera <hadess@hadess.net> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Hans de Goede 提交于
Now that we have a platform_device_id table and multiple supported ids we should be using MODULE_DEVICE_TABLE instead of MODULE_ALIAS. This fixes a regression on Bay and Cherry Trail devices, where the power button is now enumerated as an "axp221-pek" and it was impossible to wakeup these devices from suspend since the module did not load. Fixes: c3cc9447 ("Input: axp20x-pek - add support for AXP221 PEK") Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Damien Riegel 提交于
Currently, enabling keypad interrupts is one of the first operations done on the keypad, even before the interrupt is requested, so there is a small time window where the keypad can fire interrupts but the driver is not yet ready to handle them. It's fine for level interrupts because they will be handled anyway, but not so much for edge ones. This commit modifies and moves the function in charge of configuring the keypad. Enabling interrupts is now the last thing done on the keypad, and after the interrupt has been requested by the driver. Writing to the config register was also used to determine if the device was indeed present on the bus or not, this has been replaced by reading the lock/event count register to keep the same functionality. Signed-off-by: NDamien Riegel <damien.riegel@savoirfairelinux.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
- 19 10月, 2017 4 次提交
-
-
由 Chanwoo Choi 提交于
The commit 78bcac7b ("Input: add support for the STMicroelectronics FingerTip touchscreen) used the 'touchscreen_parse_properties()' helper function in order to get the value of common properties. But, commit 78bcac7b didn't set the capability of ABS_MT_POSITION_* before calling touchscreen_parse_properties(). In result, the max_x and max_y of 'struct touchscreen_properties' were not set. Fixes: 78bcac7b ("Input: add support for the STMicroelectronics FingerTip touchscreen") Cc: stable@vger.kernel.org Signed-off-by: NChanwoo Choi <cw00.choi@samsung.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Jeff Lance 提交于
Step config setting for 5 wire touchscreen is incorrect for Y coordinates. It was broken while we moved to DT. If you look close at the offending commit bb76dc09 ("input: ti_am33x_tsc: Order of TSC wires, made configurable"), the change was: - STEPCONFIG_XNP | STEPCONFIG_YPN; + ts_dev->bit_xn | ts_dev->bit_yp; while bit_xn = STEPCONFIG_XNN and bit_yp = STEPCONFIG_YNN. Not quite the same. Fixes: bb76dc09 ("input: ti_am33x_tsc: Order of TSC wires, made configurable") Signed-off-by: NJeff Lance <j-lance1@ti.com> [vigneshr@ti.com: Rebase to v4.14-rc1] Signed-off-by: NVignesh R <vigneshr@ti.com> Reviewed-by: NMichael Nazzareno Trimarchi <michael@amarulasolutions.com> Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
-
由 Pavel Roskin 提交于
This is similar to an earlier commit 52dfcc5c ("drm/nouveau: fix for disabled fbdev emulation"), but protects all occurrences of helper.fbdev in the source. I see oops in nouveau_fbcon_accel_save_disable() called from nouveau_fbcon_set_suspend_work() on Linux 3.13 when CONFIG_DRM_FBDEV_EMULATION option is disabled. Signed-off-by: NPavel Roskin <plroskin@gmail.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Alex Deucher 提交于
This causes instability in piglit. It's fixed in drm-next with: 515c6faf 1650c14b 214a91e6 29d25355 79867462 This reverts commit 6af0883e. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 18 10月, 2017 3 次提交
-
-
由 Oscar Mateo 提交于
Otherwise we are blasting other bits in GEN8_L3SQCREG1 that might be important (although we probably aren't at the moment because 0 seems to be the default for all the other bits). v2: Extra parentheses (Michel) Fixes: 050fc465 ("drm/i915:bxt: implement WaProgramL3SqcReg1DefaultForPerf") Fixes: 450174fe ("drm/i915/chv: Tune L3 SQC credits based on actual latencies") Signed-off-by: NOscar Mateo <oscar.mateo@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: NMichel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1508271945-14961-1-git-send-email-oscar.mateo@intel.comSigned-off-by: NChris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit 930a784d) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Chris Wilson 提交于
When pwriting into shmemfs, the fast path pagecache_write does not notice when it is writing to beyond the end of the truncated shmemfs inode. Report -EFAULT directly when we try to use pwrite into the !I915_MADV_WILLNEED object. Fixes: 7c55e2c5 ("drm/i915: Use pagecache write to prepopulate shmemfs from pwrite-ioctl") Testcase: igt/gem_madvise/dontneed-before-pwrite Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.william.auld@gmail.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171016202732.25459-1-chris@chris-wilson.co.uk (cherry picked from commit a6d65e45) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Tony Lindgren 提交于
Otherwise we can get the following if the fck alias is missing: Unable to handle kernel paging request at virtual address fffffffe ... PC is at clk_get_rate+0x8/0x10 LR is at omap_i2c_probe+0x278/0x6ec ... [<c056eb08>] (clk_get_rate) from [<c06f4f08>] (omap_i2c_probe+0x278/0x6ec) [<c06f4f08>] (omap_i2c_probe) from [<c0610944>] (platform_drv_probe+0x50/0xb0) [<c0610944>] (platform_drv_probe) from [<c060e900>] (driver_probe_device+0x264/0x2ec) [<c060e900>] (driver_probe_device) from [<c060cda0>] (bus_for_each_drv+0x70/0xb8) [<c060cda0>] (bus_for_each_drv) from [<c060e5b0>] (__device_attach+0xcc/0x13c) [<c060e5b0>] (__device_attach) from [<c060db10>] (bus_probe_device+0x88/0x90) [<c060db10>] (bus_probe_device) from [<c060df68>] (deferred_probe_work_func+0x4c/0x14c) Signed-off-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 17 10月, 2017 6 次提交
-
-
由 Rodrigo Vivi 提交于
HDMI Mode selection on CNL is on CFGCR0 for that PLL, not on in a global CTRL1 as it was on SKL. The original patch addressed this difference, but leaving behind this single entry here. So we were checking the wrong bits during the PLL initialization and consequently avoiding the CFGCR1 setup during HDMI initialization. Luckly when only HDMI was in use BIOS had already setup this for us. But the dual display with hot plug were messed up. Fixes: a927c927 ("drm/i915/cnl: Initialize PLLs") Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Kahola, Mika <mika.kahola@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NJames Ausmus <james.ausmus@intel.com> Reviewed-by: NManasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171003220859.21352-3-rodrigo.vivi@intel.com (cherry picked from commit 614ee07a) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Rodrigo Vivi 提交于
On PLL Enable sequence we need to "Configure DPCLKA_CFGCR0 to turn on the clock for the DDI and map the DPLL to the DDI" So we first do the map and then we unset DDI_CLK_OFF to turn the clock on. We do this in 2 separated steps. However, on this second step where we should only unset the off bit we are also unmapping the ddi from the pll. So we end up using the pll 0 for almost everything. Consequently breaking cases with more than one display. Fixes: 555e38d2 ("drm/i915/cnl: DDI - PLL mapping") Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Kahola, Mika <mika.kahola@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NJames Ausmus <james.ausmus@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171003220859.21352-2-rodrigo.vivi@intel.com (cherry picked from commit 87145d95) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Chris Wilson 提交于
The compiler warns: drivers/gpu/drm/i915/intel_ddi.c:118:35: warning: ‘bdw_ddi_translations_fdi’ defined but not used Lo and behold, if we look at intel_ddi_get_buf_trans_fdi(), it uses hsw_ddi_translations_fdi[] for both Haswell and *Broadwell* Fixes: 7d1c42e6 ("drm/i915: Refactor code to select the DDI buf translation table") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: David Weinehall <david.weinehall@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.12+ Link: https://patchwork.freedesktop.org/patch/msgid/20171013154735.27163-1-chris@chris-wilson.co.ukReviewed-by: NJani Nikula <jani.nikula@linux.intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> (cherry picked from commit 1210d388) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Chris Wilson 提交于
In the full-ppgtt world, we can fill the GGTT full of context objects. These context objects are currently implicitly tracked by the requests that pin them i.e. they are only unpinned when the request is completed and retired, but we do not have the link from the vma to the request (anymore). In order to unpin those contexts, we have to issue another request and wait upon the switch to the kernel context. The bug during eviction was that we assumed that a full GGTT meant we would have requests on the GGTT timeline, and so we missed situations where those requests where merely in flight (and when even they have not yet been submitted to hw yet). The fix employed here is to change the already-is-idle test to no look at the execution timeline, but count the outstanding requests and then check that we have switched to the kernel context. Erring on the side of overkill here just means that we stall a little longer than may be strictly required, but we only expect to hit this path in extreme corner cases where returning an erroneous error is worse than the delay. v2: Logical inversion when swapping over branches. Fixes: 80b204bc ("drm/i915: Enable multiple timelines") Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171012125726.14736-1-chris@chris-wilson.co.uk (cherry picked from commit 55b4f1ce) Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
-
由 Mohammed Gamal 提交于
RFC791 specifies the minimum MTU to be 68, while xen-net{front|back} drivers use a minimum value of 0. When set MTU to 0~67 with xen_net{front|back} driver, the network will become unreachable immediately, the guest can no longer be pinged. xen_net{front|back} should not allow the user to set this value which causes network problems. Reported-by: NChen Shi <cheshi@redhat.com> Signed-off-by: NMohammed Gamal <mgamal@redhat.com> Acked-by: NWei Liu <wei.liu2@citrix.com> Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
-
由 Changbin Du 提交于
We have implemented delayed ring mmio switch mechanism to reduce unnecessary mmio switch. While the vGPU is being destroyed or detached from VM, we need to force the ring switch to host context. The later deadline is missed. Then it got a chance that word load from VM2 might execute under the ring context of VM1 which was attached to a same vGPU instance. Finally, the GPU is hang. This patch guarantee the two deadline are performed. v2: Remove unused variable 'scheduler' Signed-off-by: NChangbin Du <changbin.du@intel.com> Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
-
- 16 10月, 2017 2 次提交
-
-
由 Marek Szyprowski 提交于
When components are unbound, DRM driver is unregistered and freed, so clear drvdata to avoid potential use-after-free issue in suspend/resume paths. Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Marek Szyprowski 提交于
The patch 6e8edf8a: "drm/exynos: Fix suspend/resume support" introduced a new code in suspend/resume paths. However it unconditionally dereference drm_dev pointer, which might be NULL if suspend/resume happens before Exynos DRM driver components bind. This patch fixes this issue. Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Fixes: 6e8edf8a "drm/exynos: Fix suspend/resume support" Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
- 14 10月, 2017 7 次提交
-
-
由 Johannes Weiner 提交于
We have seen NULL-pointer dereference crashes in tty->disc_data when the N_TTY fallback driver failed to open during hangup. The immediate cause of this open to fail has been addressed in the preceding patch to vmalloc(), but this code could be more robust. As Alan pointed out in commit 8a8dabf2 ("tty: handle the case where we cannot restore a line discipline"), the N_TTY driver, historically the safe fallback that could never fail, can indeed fail, but the surrounding code is not prepared to handle this. To avoid crashes he added a new N_NULL driver to take N_TTY's place as the last resort. Hook that fallback up to the hangup path. Update tty_ldisc_reinit() to reflect the reality that n_tty_open can indeed fail. Link: http://lkml.kernel.org/r/20171004185959.GC2136@cmpxchg.orgSigned-off-by: NJohannes Weiner <hannes@cmpxchg.org> Cc: Alan Cox <alan@llwyncelyn.cymru> Cc: Christoph Hellwig <hch@lst.de> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Michal Hocko <mhocko@suse.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Zhen Lei 提交于
When I execute numactl -H (which reads /sys/devices/system/node/nodeX/cpumap and displays cpumask_of_node for each node), I get different result on X86 and arm64. For each numa node, the former only displayed online CPUs, and the latter displayed all possible CPUs. Unfortunately, both Linux documentation and numactl manual have not described it clear. I sent a mail to ask for help, and Michal Hocko replied that he preferred to print online cpus because it doesn't really make much sense to bind anything on offline nodes. Will said: "I suspect the vast majority (if not all) code that reads this file was developed for x86, so having the same behaviour for arm64 sounds like something we should do ASAP before people try to special case with things like #ifdef __aarch64__. I'd rather have this in 4.14 if possible." Link: http://lkml.kernel.org/r/1506678805-15392-2-git-send-email-thunder.leizhen@huawei.comSigned-off-by: NZhen Lei <thunder.leizhen@huawei.com> Acked-by: NMichal Hocko <mhocko@suse.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Tianhong Ding <dingtianhong@huawei.com> Cc: Hanjun Guo <guohanjun@huawei.com> Cc: Libin <huawei.libin@huawei.com> Cc: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Ricardo Ribalda Delgado 提交于
SMBUS_BLOCK_DATA transactions might fail due to a race condition with the IMC (Integrated Micro Controller), even when the IMC semaphore is used. This bug has been reported and confirmed by AMD, who suggested as a solution an IMC firmware upgrade (obtained via BIOS update) and disabling the IMC during SMBUS_BLOCK_DATA transactions. Even without the IMC upgrade, the SMBUS is much more stable with this patch. Tested on a Bettong-alike board. Signed-off-by: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com> Reviewed-by: NJean Delvare <jdelvare@suse.de> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Guenter Roeck 提交于
AMD Family 17h uses the KERNCZ SMBus controller. While its documentation is not publicly available, it is documented in the BIOS and Kernel Developer’s Guide for AMD Family 15h Models 60h-6Fh Processors. On this SMBus controller, the port select register is at PMx register 0x02, bit 4:3 (PMx00 register bit 20:19). Without this patch, the 4 SMBus channels on AMD Family 17h chips are mirrored and report the same chips on all channels. Signed-off-by: NGuenter Roeck <linux@roeck-us.net> Reviewed-by: NJean Delvare <jdelvare@suse.de> Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
-
由 Clemens Gruber 提交于
The arguments for SDA and SCL were swapped. Fix it. Signed-off-by: NClemens Gruber <clemens.gruber@pqgruber.com> Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Wei Jinhua 提交于
Some SoC share one irq number between I2C controllers. For example, on the LS2088 board, I2C 1 and I2C 2 share one irq number. In this case, only one I2C controller can register successfully, and others will fail. Signed-off-by: NWei Jinhua <wei.jinhua1@zte.com.cn> Reviewed-by: NJiang Biao <jiang.biao2@zte.com.cn> Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Pontus Andersson 提交于
Commit b6c159a9 ("i2c: ismt: Don't duplicate the receive length for block reads") broke I2C block reads. It aimed to fix normal SMBus block read, but changed the correct behavior of I2C block read in the process. According to Documentation/i2c/smbus-protocol, one vital difference between normal SMBus block read and I2C block read is that there is no byte count prefixed in the data sent on the wire: SMBus Block Read: i2c_smbus_read_block_data() S Addr Wr [A] Comm [A] S Addr Rd [A] [Count] A [Data] A [Data] A ... A [Data] NA P I2C Block Read: i2c_smbus_read_i2c_block_data() S Addr Wr [A] Comm [A] S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P Therefore the two transaction types need to be processed differently in the driver by copying of the dma_buffer as done previously for the I2C_SMBUS_I2C_BLOCK_DATA case. Fixes: b6c159a9 ("i2c: ismt: Don't duplicate the receive length for block reads") Signed-off-by: NPontus Andersson <epontan@gmail.com> Tested-by: NStephen Douthit <stephend@adiengineering.com> Cc: stable@vger.kernel.org Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
- 13 10月, 2017 8 次提交
-
-
由 Joerg Roedel 提交于
The function only sends the flush command to the IOMMU(s), but does not wait for its completion when it returns. Fix that. Fixes: 601367d7 ('x86/amd-iommu: Remove iommu_flush_domain function') Cc: stable@vger.kernel.org # >= 2.6.33 Signed-off-by: NJoerg Roedel <jroedel@suse.de>
-
由 Rob Clark 提交于
We need to call reservation_object_reserve_shared() in both cases, but this wasn't happening in the _NO_IMPLICIT submit case. Fixes: f0a42bb5 ("drm/msm: submit support for in-fences") Reported-by: NJordan Crouse <jcrouse@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
If we fail to attach iommu, gpu->aspace could be IS_ERR().. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Niklas Söderlund 提交于
Using CONFIG_OF_DYNAMIC=y uncovered an imbalance in the usecount of the node being passed to of_fwnode_graph_get_port_parent(). Preserve the usecount by using of_get_parent() instead of of_get_next_parent() which don't decrement the usecount of the node passed to it. Fixes: 3b27d00e ("device property: Move fwnode graph ops to firmware specific locations") Signed-off-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Acked-by: NSakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: NRob Herring <robh@kernel.org>
-
由 Stewart Smith 提交于
There are two types of memory reservations firmware can ask the kernel to make in the device tree: static and dynamic. See Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt If you have greater than 16 entries in /reserved-memory (as we do on POWER9 systems) you would get this scary looking error message: [ 0.000000] OF: reserved mem: not enough space all defined regions. This is harmless if all your reservations are static (which with OPAL on POWER9, they are). It is not harmless if you have any dynamic reservations after the 16th. In the first pass over the fdt to find reservations, the child nodes of /reserved-memory are added to a static array in of_reserved_mem.c so that memory can be reserved in a 2nd pass. The array has 16 entries. This is why, on my dual socket POWER9 system, I get that error 4 times with 20 static reservations. We don't have a problem on ppc though, as in arch/powerpc/kernel/prom.c we look at the new style /reserved-ranges property to do reservations, and this logic was introduced in 0962e800 (well before any powernv system shipped). A Google search shows up no occurances of that exact error message, so we're probably safe in that no machine that people use has memory not being reserved when it should be. The simple fix is to bump the length of the array to 32 which "should be enough for everyone(TM)". The simple fix of not recording static allocations in the array would cause problems for devices with "memory-region" properties. A more future-proof fix is likely possible, although more invasive and this simple fix is perfectly suitable in the meantime while a more future-proof fix is developed. Signed-off-by: NStewart Smith <stewart@linux.vnet.ibm.com> Tested-by: NMauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com> Signed-off-by: NRob Herring <robh@kernel.org>
-
由 Sergey Senozhatsky 提交于
Do not strdup() console options. It seems that the only reason for it to be strdup()-ed was a compilation warning: printk, UART and console drivers, for some reason, expect char pointer instead of const char pointer. So we can just pass `of_stdout_options', but need to cast it to char pointer. A better fix would be to change printk, console drivers and UART to accept const char `options'; but that will take time - there are lots of drivers to update. The patch also fixes a possible memory leak: add_preferred_console() can fail, but we don't kfree() options. Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com> Reviewed-by: NPetr Mladek <pmladek@suse.com> Signed-off-by: NRob Herring <robh@kernel.org>
-
由 Archit Taneja 提交于
While converting mdp5_enable/disable() calls to pm_runtime_get/put() API, an extra call to pm_runtime_put_autosuspend() crept in mdp5_crtc_cursor_set(). This results in calling the suspend handler twice, and therefore clk_disables twice, which isn't a nice thing to do. Fixes: d68fe15b (drm/msm/mdp5: Use runtime PM get/put API instead ...) Reported-by: NStanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Archit Taneja 提交于
The DSI runtime PM suspend/resume callbacks check whether msm_host->cfg_hnd is non-NULL before trying to enable the bus clocks. This is done to accommodate early calls to these functions that may happen before the bus clocks are even initialized. Calling pm_runtime_put_autosuspend() in dsi_host_init() can result in racy behaviour since msm_host->cfg_hnd is set very soon after. If the suspend callback happens too late, we end up trying to disable clocks that were never enabled, resulting in a bunch of WARN_ON splats. Use pm_runtime_put_sync() so that the suspend callback is called immediately. Reported-by: NNicolas Dechesne <nicolas.dechesne@linaro.org> Signed-off-by: NArchit Taneja <architt@codeaurora.org> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 12 10月, 2017 2 次提交
-
-
由 Wei Yongjun 提交于
In case of error, the function msm_gem_get_vaddr() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Fixes: 8223286d ("drm/msm: Add a helper function for in-kernel buffer allocations") Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
Fixes intermittent corruption of cmdstream dump. Signed-off-by: NRob Clark <robdclark@gmail.com>
-