- 02 3月, 2016 1 次提交
-
-
由 Haggai Eran 提交于
In order to create multiple GSI QPs, we need to set the source QP number to one on all these QPs. Add the necessary definitions and infrastructure to do that. Reviewed-by: NLeon Romanovsky <leonro@mellanox.com> Signed-off-by: NHaggai Eran <haggaie@mellanox.com> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
- 01 3月, 2016 5 次提交
-
-
由 Erez Shitrit 提交于
The driver checks the csum from the HW when completion arrived and marks it in the wc->wc_flags field for the ulp drivers. These is for packets from type IB_WC_RECV only. Signed-off-by: NErez Shitrit <erezsh@mellanox.com> Signed-off-by: NEran Ben Elisha <eranbe@mellanox.com> Reviewed-by: NLeon Romanovsky <leonro@mellanox.com> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
由 Erez Shitrit 提交于
In order to support LSO and CSUM in the TX flow the driver does the following: * LSO bit for the enum mlx5_ib_qp_flags was added, indicates QP that supports LSO offloads. * Enables the special offload when the QP is created, and enable the special work request id (IB_WR_LSO) when comes. * Calculates the size of the WQE according to the new WQE format that support these offloads. * Handles the new WQE format when arrived, sets the relevant fields, and copies the needed data. Signed-off-by: NErez Shitrit <erezsh@mellanox.com> Signed-off-by: NEran Ben Elisha <eranbe@mellanox.com> Reviewed-by: NLeon Romanovsky <leonro@mellanox.com> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
由 Meny Yossefi 提交于
Modify mlx5_ib_process_mad to use PPCNT and query_vport commands instead of MAD_IFC, as MAD_IFC is deprecated on new firmware versions (and doesn't support RoCE anyway). Traffic counters exist in both 32-bit and 64-bit forms. Declaring support of extended coutners results in traffic counters to be read in their 64-bit form only via the query_vport command. Error counters exist only in 32-bit form and read via PPCNT command. This commit also adds counters support in RoCE. Signed-off-by: NMeny Yossefi <menyy@mellanox.com> Signed-off-by: NMajd Dibbiny <majd@mellanox.com> Reviewed-by: NMatan Barak <matanb@mellanox.com> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
由 Meny Yossefi 提交于
Added helper function to read IB standard error counters via the PPCNT register. The PPCNT register read command provides the 32-bit error counters of both IB/RoCE link layer and transport layer. Signed-off-by: NMeny Yossefi <menyy@mellanox.com> Signed-off-by: NMajd Dibbiny <majd@mellanox.com> Reviewed-by: NMatan Barak <matanb@mellanox.com> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
由 Meny Yossefi 提交于
Added helper function to read 64bit virtual port Infiniband traffic counters. Signed-off-by: NMeny Yossefi <menyy@mellanox.com> Signed-off-by: NMajd Dibbiny <majd@mellanox.com> Reviewed-by: NMatan Barak <matanb@mellanox.com> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
- 28 2月, 2016 1 次提交
-
-
由 Daniel Cashman 提交于
Commit d07e2259 ("mm: mmap: add new /proc tunable for mmap_base ASLR") added the ability to choose from a range of values to use for entropy count in generating the random offset to the mmap_base address. The maximum value on this range was set to 32 bits for 64-bit x86 systems, but this value could be increased further, requiring more than the 32 bits of randomness provided by get_random_int(), as is already possible for arm64. Add a new function: get_random_long() which more naturally fits with the mmap usage of get_random_int() but operates exactly the same as get_random_int(). Also, fix the shifting constant in mmap_rnd() to be an unsigned long so that values greater than 31 bits generate an appropriate mask without overflow. This is especially important on x86, as its shift instruction uses a 5-bit mask for the shift operand, which meant that any value for mmap_rnd_bits over 31 acts as a no-op and effectively disables mmap_base randomization. Finally, replace calls to get_random_int() with get_random_long() where appropriate. This patch (of 2): Add get_random_long(). Signed-off-by: NDaniel Cashman <dcashman@android.com> Acked-by: NKees Cook <keescook@chromium.org> Cc: "Theodore Ts'o" <tytso@mit.edu> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: David S. Miller <davem@davemloft.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Nick Kralevich <nnk@google.com> Cc: Jeff Vander Stoep <jeffv@google.com> Cc: Mark Salyzyn <salyzyn@android.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 27 2月, 2016 2 次提交
-
-
由 Thierry Reding 提交于
This driver uses PCI glue that is only available on 32-bit ARM. This used to work fine as long as ARCH_MVEBU and ARCH_DOVE were exclusively 32-bit, but there's a patch in the pipe to make ARCH_MVEBU also available on 64-bit ARM. [bhelgaas: changelog; patch is coming but not merged yet] Signed-off-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
由 Bjorn Helgaas 提交于
991de2e5 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()") appeared in v4.3 and helps support IOAPIC hotplug. Олег reported that the Elcus-1553 TA1-PCI driver worked in v4.2 but not v4.3 and bisected it to 991de2e5. Sunjin reported that the RocketRAID 272x driver worked in v4.2 but not v4.3. In both cases booting with "pci=routirq" is a workaround. I think the problem is that after 991de2e5, we no longer call pcibios_enable_irq() for upstream bridges. Prior to 991de2e5, when a driver called pci_enable_device(), we recursively called pcibios_enable_irq() for upstream bridges via pci_enable_bridge(). After 991de2e5, we call pcibios_enable_irq() from pci_device_probe() instead of the pci_enable_device() path, which does *not* call pcibios_enable_irq() for upstream bridges. Revert 991de2e5 to fix these driver regressions. Link: https://bugzilla.kernel.org/show_bug.cgi?id=111211 Fixes: 991de2e5 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()") Reported-and-tested-by: NОлег Мороз <oleg.moroz@mcc.vniiem.ru> Reported-by: NSunjin Yang <fan4326@gmail.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NRafael J. Wysocki <rafael@kernel.org> CC: Jiang Liu <jiang.liu@linux.intel.com>
-
- 25 2月, 2016 5 次提交
-
-
由 Ben Skeggs 提交于
This can happen under some annoying circumstances, and is a quick fix until more substantial changes can be made. Fixed eDP mode changes on (at least) the Lenovo P50. Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
-
由 Thierry Reding 提交于
The error cleanup paths aren't quite correct and will crash upon deferred probe. Cc: stable@vger.kernel.org # v4.3+ Reviewed-by: NBen Skeggs <bskeggs@redhat.com> Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Geert Uytterhoeven 提交于
CONFIG_ARCH_SHMOBILE is not only enabled for Renesas ARM platforms (which are DT based and multi-platform), but also on a select set of Renesas SuperH platforms (SH7722/SH7723/SH7724/SH7343/SH7366). Hence since commit 0ba58de2 ("drivers: sh: Get rid of CONFIG_ARCH_SHMOBILE_MULTI"), the legacy clock domain is no longer installed on these SuperH platforms, and module clocks may not be enabled when needed, leading to driver failures. To fix this, add an additional check for CONFIG_OF. Fixes: 0ba58de2 ("drivers: sh: Get rid of CONFIG_ARCH_SHMOBILE_MULTI"). Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
-
由 Christian König 提交于
That should make user space bugs more obvious. Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Bradley Pankow 提交于
The event_data passed from pem_fini was not cleared upon initialization. This caused NULL checks to pass and cast_const_phw_tonga_power_state to attempt to dereference an invalid pointer. Clear the event_data in pem_init and pem_fini before calling pem_handle_event. Reviewed-by: NRex Zhu <Rex.Zhu@amd.com> Signed-off-by: NBradley Pankow <btpankow@gmail.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 24 2月, 2016 4 次提交
-
-
由 Rafael J. Wysocki 提交于
Revert commit b5bd0269 (ACPI, PCI, irq: remove interrupt count restriction) that introduced a boot regression on some systems where it caused kmalloc() to be used too early. Link: http://marc.info/?l=linux-acpi&m=145580159209240&w=2Reported-by: NNalla, Ravikanth <ravikanth.nalla@hpe.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Rafael J. Wysocki 提交于
Revert commit 09716869 "ACPI / PCI: Simplify acpi_penalize_isa_irq()" that depends on commit b5bd0269 (ACPI, PCI, irq: remove interrupt count restriction) which introduced a regression and needs to be reverted for this reason. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Arnd Bergmann 提交于
A recent bugfix changed pfn_t to always be 64-bit wide, but did not change the code in pmem.c, which is now broken on 32-bit architectures as reported by gcc: In file included from ../drivers/nvdimm/pmem.c:28:0: drivers/nvdimm/pmem.c: In function 'pmem_alloc': include/linux/pfn_t.h:15:17: error: large integer implicitly truncated to unsigned type [-Werror=overflow] #define PFN_DEV (1ULL << (BITS_PER_LONG_LONG - 3)) This changes the intermediate pfn_flags in struct pmem_device to be 64 bit wide as well, so they can store the flags correctly. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Fixes: db78c222 ("mm: fix pfn_t vs highmem") Signed-off-by: NDan Williams <dan.j.williams@intel.com>
-
由 Dan Williams 提交于
The original format of these commands from the "NVDIMM DSM Interface Example" [1] are superseded by the ACPI 6.1 definition of the "NVDIMM Root Device _DSMs" [2]. [1]: http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf [2]: http://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf "9.20.7 NVDIMM Root Device _DSMs" Changes include: 1/ New 'restart' fields in ars_status, unfortunately these are implemented in the middle of the existing definition so this change is not backwards compatible. The expectation is that shipping platforms will only ever support the ACPI 6.1 definition. 2/ New status values for ars_start ('busy') and ars_status ('overflow'). Cc: Vishal Verma <vishal.l.verma@intel.com> Cc: Linda Knippers <linda.knippers@hpe.com> Cc: <stable@vger.kernel.org> Signed-off-by: NDan Williams <dan.j.williams@intel.com>
-
- 23 2月, 2016 14 次提交
-
-
由 Cristian Birsan 提交于
Commit ac33cdb1 ("usb: musb: Remove ifdefs for musb_host_rx in musb_host.c part5") introduces a problem setting DMA host mode. The musb_advance_schedule() is called immediately after receiving an endpoint RX interrupt without waiting for the DMA transfer to complete. As a consequence when the dma complete interrupt arrives the in_qh member of hw_ep is already null an the musb_host_rx() exits on !urb error case. Fix the done condition that advances the musb schedule. Signed-off-by: NCristian Birsan <cristian.birsan@microchip.com> Signed-off-by: NJoshua Henderson <joshua.henderson@microchip.com> Tested-by: NLadislav Michl <ladis@linux-mips.org> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 Ivan T. Ivanov 提交于
When working in Dual Role Device mode, USB state machine is not kicked, when host or gadget drivers are loaded. Fix this be explicitly triggering state detection on client driver load. Issue is that if the board is booted without micro usb cable and usb device attached, kernel fails to populate the usb host and device. The reason for this is that the state machine worker logic only checks for USB_DR_MODE_PERIPHERAL and USB_DR_MODE_HOST modes to run worker thread. However if the phy is configured in OTG mode it would fail to run the state machine, resulting in failure to detect for very first time. This patch fixes the issue by removing the explicit checks. Issue is noticed on Qualcomm Dragon board DB410C. [srinivas.kandagatla@linaro.org: Added more details to log] Signed-off-by: NIvan T. Ivanov <ivan.ivanov@linaro.org> Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 Simon Appleby 提交于
This patch fixes the register offset used for super-speed connection's max packet size. Without it using the 338x series of devices in enhanced mode will only allow full or high speed operation to function correctly. Signed-off-by: NSimon Appleby <simon.appleby@pickeringtest.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 Marek Szyprowski 提交于
Gadgetfs driver called usb_gadget_unregister_driver unconditionally, even if it didn't register it earlier due to other failures. This patch fixes this. Reported-by: NVegard Nossum <vegard.nossum@oracle.com> Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com> Tested-by: NVegard Nossum <vegard.nossum@oracle.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 Marek Szyprowski 提交于
Retry gadget probe only if the probe result is -EPROBE_DEFER, not on every probe error. Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: NFelipe Balbi <balbi@kernel.org>
-
由 Tomeu Vizoso 提交于
As per the documentation of the devfreq_dev_profile.target callback, set the freq argument to the new frequency before returning. This caused endless messages like this after recent changes in the core: devfreq 6000c800.actmon: Couldn't update frequency transition information. Signed-off-by: NTomeu Vizoso <tomeu.vizoso@collabora.com> Reported-by: NTyler Baker <tyler.baker@linaro.org> Tested-by: NThierry Reding <treding@nvidia.com> Acked-by: NThierry Reding <treding@nvidia.com> Signed-off-by: NMyungJoo Ham <myungjoo.ham@samsung.com>
-
由 Tero Kristo 提交于
As the code in this file is being executed within irq context in some cases, we must avoid the clk_get_rate which uses mutex internally. Switch the code to use clk_hw_get_rate instead which is non-locking. This fixes an issue where PM runtime will hang the system if enabled with a serial console before a suspend-resume cycle. Signed-off-by: NTero Kristo <t-kristo@ti.com> Tested-by: NTony Lindgren <tony@atomide.com> Fixes: a53ad8ef ("clk: ti: Convert to clk_hw based provider APIs") Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
-
由 Mika Kuoppala 提交于
It has been observed that sometimes disabling the dc6 fails and dc6 state pops back up, brief moment after disabling. This has to be dmc save/restore timing issue or other bug in the way dc states are handled. Try to work around this issue as we don't have firmware fix yet available. Verify that the value we wrote for the dmc sticks, and also enforce it by rewriting it, if it didn't. v2: Zero rereads on rewrite for extra paranoia (Imre) Testcase: kms_flip/basic-flip-vs-dpms References: https://bugs.freedesktop.org/show_bug.cgi?id=93768 Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455811089-27884-1-git-send-email-mika.kuoppala@intel.com (cherry picked from commit 779cb5d3) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Patrik Jakobsson 提交于
The DMC can incorrectly run off and allow DC states on it's own. We don't know the root-cause for this yet but this patch makes it more visible. Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: NPatrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455808874-22089-2-git-send-email-mika.kuoppala@intel.com (cherry picked from commit 832dba88) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Alex Deucher 提交于
set_power_state defaults to no displays, so we need to update the display configuration after setting up the powerstate on the first call. In most cases this is not an issue since ends up getting called multiple times at any given modeset and the proper order is achieved in the display changed handling at the top of the function. Reviewed-by: NChristian König <christian.koenig@amd.com> Acked-by: NJordan Lazare <Jordan.Lazare@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
set_power_state defaults to no displays, so we need to update the display configuration after setting up the powerstate on the first call. In most cases this is not an issue since ends up getting called multiple times at any given modeset and the proper order is achieved in the display changed handling at the top of the function. Reviewed-by: NChristian König <christian.koenig@amd.com> Acked-by: NJordan Lazare <Jordan.Lazare@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
I.e., doesn't make sense to change power states or check the temperature when the asic is powered off. Reviewed-by: NChristian König <christian.koenig@amd.com> Acked-by: NHarry Wentland <harry.wentland@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Looks like a copy paste typo when we added powerplay support. Reviewed-by: NChristian König <christian.koenig@amd.com> Acked-by: NHarry Wentland <harry.wentland@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Looks like a copy/paste typo. Reviewed-by: NChristian König <christian.koenig@amd.com> Noticed-by: NDavid Panariti <David.Panariti@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 22 2月, 2016 8 次提交
-
-
由 Imre Deak 提交于
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Spotted-by: NMika Kuoppala <mika.kuoppala@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93441 CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455719489-3008-1-git-send-email-imre.deak@intel.com (cherry picked from commit 4d800030) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Imre Deak 提交于
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-13-git-send-email-imre.deak@intel.com (cherry picked from commit ecb24482) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Imre Deak 提交于
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-12-git-send-email-imre.deak@intel.com (cherry picked from commit 5b092174) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Imre Deak 提交于
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-11-git-send-email-imre.deak@intel.com (cherry picked from commit 3f3f42b8) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Imre Deak 提交于
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-10-git-send-email-imre.deak@intel.com (cherry picked from commit 6fa9a5ec) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Imre Deak 提交于
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. While at it also add the missing reference around the HW access in i915_interrupt_info(). v2: - update the commit message mentioning that this also fixes the HW access in the interrupt info debugfs entry (Daniel) Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-9-git-send-email-imre.deak@intel.com (cherry picked from commit e129649b) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Imre Deak 提交于
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-8-git-send-email-imre.deak@intel.com (cherry picked from commit e27daab4) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Imre Deak 提交于
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93439 CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-7-git-send-email-imre.deak@intel.com (cherry picked from commit 1c8fdda1) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-