Age | Commit message (Collapse) | Author |
|
Patch 2f896d586610 ("arm64: use fixmap for text patching") changed
the way we patch the kernel text, using a fixmap when the kernel or
modules are flagged as read only.
Unfortunately, a flaw in the logic makes it fall over when patching
modules without CONFIG_DEBUG_SET_MODULE_RONX enabled:
[...]
[ 32.032636] Call trace:
[ 32.032716] [<fffffe00003da0dc>] __copy_to_user+0x2c/0x60
[ 32.032837] [<fffffe0000099f08>] __aarch64_insn_write+0x94/0xf8
[ 32.033027] [<fffffe000009a0a0>] aarch64_insn_patch_text_nosync+0x18/0x58
[ 32.033200] [<fffffe000009c3ec>] ftrace_modify_code+0x58/0x84
[ 32.033363] [<fffffe000009c4e4>] ftrace_make_nop+0x3c/0x58
[ 32.033532] [<fffffe0000164420>] ftrace_process_locs+0x3d0/0x5c8
[ 32.033709] [<fffffe00001661cc>] ftrace_module_init+0x28/0x34
[ 32.033882] [<fffffe0000135148>] load_module+0xbb8/0xfc4
[ 32.034044] [<fffffe0000135714>] SyS_finit_module+0x94/0xc4
[...]
This is triggered by the use of virt_to_page() on a module address,
which ends to pointing to Nowhereland if you're lucky, or corrupt
your precious data if not.
This patch fixes the logic by mimicking what is done on arm:
- If we're patching a module and CONFIG_DEBUG_SET_MODULE_RONX is set,
use vmalloc_to_page().
- If we're patching the kernel and CONFIG_DEBUG_RODATA is set,
use virt_to_page().
- Otherwise, use the provided address, as we can write to it directly.
Tested on 4.0-rc1 as a KVM guest.
Reported-by: Richard W.M. Jones <rjones@redhat.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Laura Abbott <lauraa@codeaurora.org>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs
Pull btrfs fix from Chris Mason:
"I'm still testing more fixes, but I wanted to get out the fix for the
btrfs raid5/6 memory corruption I mentioned in my merge window pull"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
Btrfs: fix allocation size calculations in alloc_btrfs_bio
|
|
This patch increases the interleave factor for parallel AES modes
to 4x. This improves performance on Cortex-A57 by ~35%. This is
due to the 3-cycle latency of AES instructions on the A57's
relatively deep pipeline (compared to Cortex-A53 where the AES
instruction latency is only 2 cycles).
At the same time, disable inline expansion of the core AES functions,
as the performance benefit of this feature is negligible.
Measured on AMD Seattle (using tcrypt.ko mode=500 sec=1):
Baseline (2x interleave, inline expansion)
------------------------------------------
testing speed of async cbc(aes) (cbc-aes-ce) decryption
test 4 (128 bit key, 8192 byte blocks): 95545 operations in 1 seconds
test 14 (256 bit key, 8192 byte blocks): 68496 operations in 1 seconds
This patch (4x interleave, no inline expansion)
-----------------------------------------------
testing speed of async cbc(aes) (cbc-aes-ce) decryption
test 4 (128 bit key, 8192 byte blocks): 124735 operations in 1 seconds
test 14 (256 bit key, 8192 byte blocks): 92328 operations in 1 seconds
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
Caught during Trinity testing. The pte_modify does not allow
modification for PTE type bit. This cause the test to hang
the system. It is found that the PTE can't transit from an
inaccessible page (b00) to a valid page (b11) because the mask
does not allow it. This happens when a big block of mmaped
memory is set the PROT_NONE, then the a small piece is broken
off and set to PROT_WRITE | PROT_READ cause a huge page split.
Signed-off-by: Feng Kan <fkan@apm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
The functions __cpu_flush_user_tlb_range and __cpu_flush_kern_tlb_range
were removed in commit fa48e6f780 'arm64: mm: Optimise tlb flush logic
where we have >4K granule'. Global variable cpu_tlb was never used in
arm64.
Remove them.
Signed-off-by: Yingjoe Chen <yingjoe.chen@mediatek.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
An arm64 allmodconfig fails to build with GCC 5 due to __asmeq
assertions in the PSCI firmware calling code firing due to mcount
preambles breaking our assumptions about register allocation of function
arguments:
/tmp/ccDqJsJ6.s: Assembler messages:
/tmp/ccDqJsJ6.s:60: Error: .err encountered
/tmp/ccDqJsJ6.s:61: Error: .err encountered
/tmp/ccDqJsJ6.s:62: Error: .err encountered
/tmp/ccDqJsJ6.s:99: Error: .err encountered
/tmp/ccDqJsJ6.s:100: Error: .err encountered
/tmp/ccDqJsJ6.s:101: Error: .err encountered
This patch fixes the issue by moving the PSCI calls out-of-line into
their own assembly files, which are safe from the compiler's meddling
fingers.
Reported-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
The vdso implementation of clock_getres currently returns 0 (success)
whenever a null timespec is provided by the caller, regardless of the
clock id supplied.
This behavior is incorrect. It should fall back to syscall when an
unrecognized clock id is passed, even when the timespec argument is
null. This ensures that clock_getres always returns an error for
invalid clock ids.
Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
On VLV/CHV the media well rc6 residency gets reported separately
from the render well, so add another file to sysfs so that we can
report the residency to the user.
Testcase: igt/pm_rc6_residency --run-subtest media-rc6-accuracy
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Currently an enabled break state is not disabled on final close nor on
re-open and has to be disabled manually.
Fix this by disabling break on port shutdown.
Reported-by: Jari Ruusu <jariruusu@users.sourceforge.net>
Tested-by: Jari Ruusu <jariruusu@users.sourceforge.net>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Fix null-pointer dereference at probe when the device is used as a
console, in which case the tty argument to open will be NULL.
Fixes: ee467a1f2066 ("USB: serial: add Moxa UPORT 12XX/14XX/16XX
driver")
Cc: stable <stable@vger.kernel.org> # v3.14
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Greg Kroah-Hartman <greg@kroah.com>
|
|
Clean up bus probe error handling by separating success and error paths.
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Fix attribute-creation race with userspace by using the port device
groups field to create the port attributes.
Also use %u when printing the port number, which is unsigned, even
though we do not currently support more than 128 ports per device.
Reported-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Greg Kroah-Hartman <greg@kroah.com>
|
|
Add missing error handling when registering the tty device at port
probe. This avoids trying to remove an uninitialised character device
when the port device is removed.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: Takashi Iwai <tiwai@suse.de>
Cc: stable <stable@vger.kernel.org> # v2.6.12
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Greg Kroah-Hartman <greg@kroah.com>
|
|
Fix return value in probe error path, which could end up returning
success (0) on errors. This could in turn lead to use-after-free or
double free (e.g. in port_remove) when the port device is removed.
Fixes: c706ebdfc895 ("USB: usb-serial: call port_probe and port_remove
at the right times")
Cc: stable <stable@vger.kernel.org> # v2.6.31
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Greg Kroah-Hartman <greg@kroah.com>
|
|
Add call to __module_get when initialising the fake tty in
usb_console_setup to match the module_put in release_one_tty.
Note that the tty-driver (i.e. usb-serial core) must be compiled-in to
enable the usb console so the __module_get is essentially a noop as
driver->owner will be null.
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
These product identifiers (PID) all deal with marine NMEA format data
used on motor boats and yachts. We supply the programmed devices to
Chetco, for use inside their equipment. The PIDs are a direct copy of
our Windows device drivers (FTDI drivers with altered PIDs).
Signed-off-by: Mark Glover <mark@actisense.com>
Cc: stable <stable@vger.kernel.org>
[johan: edit commit message slightly ]
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
This reverts commit 5083fd7bdfe6760577235a724cf6dccae13652c2.
A bulk-out size smaller than the end-point size is indeed valid. The
offending commit broke the usb-debug driver for EHCI debug devices,
which use 8-byte buffers.
Fixes: 5083fd7bdfe6 ("USB: serial: make bulk_out_size a lower limit")
Reported-by: "Li, Elvin" <elvin.li@intel.com>
Cc: stable <stable@vger.kernel.org> # v3.15
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Enable support for shmobile platforms that became multi-platform aware.
Several non-critical drivers and subsystems are built as modules, to keep
kernel size reasonable.
Tested on:
- r8a73a4/ape6evm:
- U-Boot fails with "Error: unrecognized/unsupported machine ID",
- kexec works.
- r8a7740/armadillo:
- Hermit boot loader fails (larger image, more memory corruption),
- kexec works.
- r8a7791/koelsch,
- sh73a0/kzm9g:
- zImage+DTB from U-Boot needs CONFIG_ARM_ATAG_DTB_COMPAT=n,
- kexec works.
- am335x/boneblack.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
The patch "drm/i915: Plumb drm_device through page tables operations"
added an extra parameter, but it didn't update the function description.
Also remove unnecessary blank line added by the same patch.
Found by kbuild test robot.
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The frequency values(Rp0, Rp1, Rpn) reported by RP_STATE_CAP register
are stored, initially by the Driver, inside the dev_priv->rps structure.
Since these values are expected to remain same throughout, there is no real
need to read this register, on dynamic basis, from certain debugfs/sysfs
functions and the values can be instead retrieved from the dev_priv->rps
structure when needed.
For the i915_frequency_info debugfs interface, the frequency values from the
RP_STATE_CAP register only should be used, to indicate the actual Hw state,
since it is principally used for the debugging purpose.
v2: Reverted the changes in i915_frequency_info function, to continue report
back the frequency values, as per the actual Hw state (Chris)
Signed-off-by: Akash Goel <akash.goel@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The code in function intel_crtc_compute_config() that evens pipe_src_w
if necessary would look at the current config instead of the staged one
when deciding if there is an LVDS encoder in use. This could potentially
lead to the value not being updated, if during the modeset a crtc wasn't
driving an LVDS encoder.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Remove this configuration bit in crtc driver as the rising edge clock is widely
used.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
|
|
Make sure we don't try to dereference NULL pointers when returning values
from the AdminQ calls.
Change-ID: Ia6694f2f415d50acf0aba063c863568742799aff
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Tested-by: Jim Young <james.m.young@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
In some circumstances, a multi-write transaction takes longer than the
default 3 minute timeout on the write semaphore. If the write failed with
an EBUSY status, this is likely the problem, so here we try to reacquire
the semaphore then retry the write. We only do one retry, then give up.
Change-ID: I1c8be60688acc2f39573839579baf601207c4a36
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Tested-by: Jim Young <james.m.young@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
In some cases, the hardware would continue to try to access the FDIR
ring after entering D3Hot state, which would cause either PCIe errors or
NMIs, depending upon system configuration.
Explicitly stop FDIR in our shutdown routine to eliminate this
possibility.
Change-ID: I1bd9fc7fd8f151fe24cad132ac9adddab923e3af
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Tested-by: Jim Young <james.m.young@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
Combine the ICR0 shutdown with the standard interrupt shutdown, and
add the interrupt clearing to the PCI shutdown path.
This prevents the driver from allowing stray interrupts or causing
system logs from un-handled interrupts.
Change-ID: I48f6ab95cad7f8ca77c1f26c92a51cc1034ced43
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Tested-by: Jim Young <james.m.young@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
We were checking the outer Protocol flags and deciding the flow for
inner header. This patch fixes that.
This fixes the Tx checksum offload for TCP/IPv6 over vxlan.
Change-ID: I837aaea921d34f71b24c2bc32aaadea5001ddf78
Signed-off-by: Anjali Singhai Jain <anjali.singhai@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
As part of DCB reconfiguration flow if the Tx queue disable times out
then issue a PF reset to do some level of recovery.
Change-ID: I7550021c55bff355351c0365e61e1f05fcaff46d
Signed-off-by: Neerav Parikh <neerav.parikh@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
When DCB is reconfigured to single TC the driver did not reset the
Tx ring Qset handle to the correct mapping; which caused Tx queue
disable timeouts.
Change-ID: I4da5915ec92a83c281b478d653fae6ef1b72edfe
Signed-off-by: Neerav Parikh <neerav.parikh@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
When the driver or hardware gets less interrupt vectors than the actual
number of CPU cores, limit the queue count for the priority queue
traffic class (TC) queues.
This will fix a warning with multiple function mode where systems
regularly have more cores than vectors.
Also add extra comment for readability.
Change-ID: I4f02226263aa3995e1f5ee5503eac0cd6ee12fbd
Signed-off-by: Anjali Singhai Jain <anjali.singhai@intel.com>
Tested-by: Jim Young <james.m.young@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
The driver was having some issues with false Tx hang detection. This
makes the driver a little more direct with the checks for progress
forward by directly checking the head write back address and tail register
when determining progress. This avoids Tx hangs where the software
gets behind, because we are directly checking hardware state when
determining hang state.
Change-ID: I774f0e861c9e8ab5ccb213634100fe15440ae24a
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Jim Young <james.m.young@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
The hardware has some limitations the driver needs to adhere to,
that we found in extended testing.
1) no more than 8 descriptors per packet on the wire
2) no header can span more than 3 descriptors
If one of these events occurs, the hardware will generate an internal
error and freeze the Tx queue.
This patch linearizes the skb to avoid these situations.
Change-ID: I37dab7d3966e14895a9663ec4d0aaa8eb0d9e115
Signed-off-by: Anjali Singhai Jain <anjali.singhai@intel.com>
Tested-by: Jim Young <james.m.young@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
This patch adds check to bail out if device is already down when checking
for Tx hang subtask.
Change-ID: I3853fb7a6d11cb9a4c349b687cb25c15b19977a0
Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
Tested-by: Jim Young <james.m.young@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
Add parens to make sure the shift and bitwise precedences don't work backwards
for us.
Change-ID: I60c10ef4fad6bc654522b9d8a53da2e270a0f268
Reported-by: Joe Perches <joe@perches.com>
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Tested-by: Jim Young <james.m.young@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
The patch fixes a leak of 'cmd_buf' when copy_from_user() failed
in i40e_dbg_command_write().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Tested-by: Jim Young <james.m.young@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
|
|
This patch fixes faulty behaviour in a setup where the input clock for the
SRG is fed through the CLKR/CLKX pin but the McBSP is configured to be
master (SND_SOC_DAIFMT_CBS_CFS). In that case of course CLKR/CLKX must
not be configured as output pin. Otherwise the input clock is messed up
horribly.
This patch makes it possible to use the CLKR/CLKX pin rather than CLKS to
inject a reference clock in setups where McBSP is master and not both
rx and tx are used. However for this to work it has to be ensured that
set_dai_sysclk() is called after set_dai_fmt().
This was tested on a beagleboard-xm using McBSP1 to drive a i2s DAC through
the tx lines (CLKX,FSX,DX). Using this patch the CLKR pin is used to inject
an external reference clock.
Signed-off-by: Thomas Niederprüm <niederp@physik.uni-kl.de>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The patch corrects the routing paths of that after IF1/2 DACx Mux
Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
git://anongit.freedesktop.org/drm-intel into drm-next
misc atomic and dp macros
* tag 'topic/drm-misc-2015-02-25' of git://anongit.freedesktop.org/drm-intel:
drm: Adding edp1.4 specific dpcd macros
drm/atomic-helpers: make mode_set hooks optional
drm/atomic-helper: Rename commmit_post/pre_planes
drm/atomic: Rename drm_atomic_helper_commit_pre_planes() state argument
drm: If available use atomic state in getcrtc ioctl
drm: Add DRM_DEBUG_ATOMIC
drm/atomic-helpers: Fix documentation typos and wrong copy&paste
drm: Fix the CRTC_STEREO_DOUBLE_ONLY define to include stero modes
drm: Fix drm_crtc_vblank_get() documentation
|
|
The IRQF_NO_SUSPEND flag is intended to be used for interrupts required
to be enabled during the suspend-resume cycle. This mostly consists of
IPIs and timer interrupts, potentially including chained irqchip
interrupts if these are necessary to handle timers or IPIs. If an
interrupt does not fall into one of the aforementioned categories,
requesting it with IRQF_NO_SUSPEND is likely incorrect.
Using IRQF_NO_SUSPEND does not guarantee that the interrupt can wake the
system from a suspended state. For an interrupt to be able to trigger a
wakeup, it may be necessary to program various components of the system.
In these cases it is necessary to use {enable,disabled}_irq_wake.
Unfortunately, several drivers assume that IRQF_NO_SUSPEND ensures that
an IRQ can wake up the system, and the documentation can be read
ambiguously w.r.t. this property.
This patch updates the documentation regarding IRQF_NO_SUSPEND to make
this caveat explicit, hopefully making future misuse rarer. Cleanup of
existing misuse will occur as part of later patch series.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
As we transition to full atomic modesetting, we want to be able to pass
intel_crtc_state around in various places that we pass intel_crtc
directly today. Ensure that the ->crtc backpointer is properly
initialized in case we need to get back to the associated CRTC.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
As vendors transition their drivers from legacy to atomic there's some
duplication of data between drm_crtc and drm_crtc_state (since
unconverted drivers likely won't have a state structure).
i915 is partially converted and does have a crtc->state structure, but
still uses direct crtc fields internally in many places, which causes
the two sets of data to get out of sync. As of commit
commit 31c946e85ce6b48ce0f25e3cdca8362e4fe8b300
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun Feb 22 12:24:17 2015 +0100
drm: If available use atomic state in getcrtc ioctl
This way drivers fully converted to atomic don't need to update these
legacy state variables in their modeset code any more.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
the DRM core starts assuming that the presence of a ->state structure
implies that it should make use of the values stored there which, on
i915, leads to the core code using stale values for CRTC 'enabled'
status.
Let's switch over to using the state value of 'enable' internally rather
than using the drm_crtc field. This ensures that our driver internals
are working from the same data that the DRM core is, avoiding
mismatches.
This patch was generated with Coccinelle using the following semantic
patch:
<smpl>
@@
struct drm_crtc C;
struct drm_crtc *CP;
@@
(
- C.enabled
+ C.state->enable
|
- CP->enabled
+ CP->state->enable
)
// For assignments, we still update the legacy value as well as the state value
// so add an extra assignment statement for that.
@@
struct drm_crtc C;
struct drm_crtc *CP;
expression E;
@@
(
C.state->enable = E;
+ C.enabled = E;
|
CP->state->enable = E;
+ CP->enabled = E;
)
</smpl>
The crtc->mode and crtc->hwmode fields should probably be transitioned
over as well eventually, but we seem to do an okay job of keeping those
up-to-date already so I want to minimize the changes that will clash
with Ander's in-progress atomic work.
v2: Don't remove the assignments to the legacy value when we assign to
the state value. A second cocci stanza takes care of adding the
legacy assignment back where appropriate. (Daniel)
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
I have been signing off on patches with this address so I'll change it.
Signed-off-by: Andy Gospodarek <gospo@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The PHY requires different settings for the Decision Feedback Analyzer
(DFE) when running in KX mode vs. KR mode. Update the code to change
these settings when changing modes in order to provide a more stable
link.
Additionally, adjust the 10GbE PQ skew default setting to a more sane
value.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
In execlist mode, the ringbuf is a function of the ring and context whereas in
legacy mode, it is derived from the ring alone. Thus the calculation required to
determine the ringbuf pointer from the ring (and context) also needs to test
execlist mode or not. This is messy.
Further, the request structure holds a pointer to both the ring and the context
for which it was created. Thus, given a request, it is possible to derive the
ringbuf in either legacy or execlist mode. Hence it is necessary to pass just
the request in to all the low level functions rather than some combination of
request, ring, context and ringbuf. However, rather than recalculating it each
time, it is much simpler to just cache the ringbuf pointer in the request
structure itself.
Caching the pointer means the calculation is done once at request creation time
and all further code and simply read it directly from the request structure.
OTC-Jira: VIZ-5115
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
[danvet: Drop contentless comment in lrc alloc request entirely. And
spelling fix in the commit message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
There is a trace point in the legacy execbuffer execution path that is missing
from the execlist path. Trace points are extremely useful for debugging and are
used by various automated validation tests. Hence, this patch adds the missing
trace point back in.
OTC-Jira: VIZ-5115
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
There is a flags word that is passed through the execbuffer code path all the
way from initial decoding of the user parameters down to the very final dispatch
buffer call. It is simply called 'flags'. Unfortuantely, there are many other
flags words floating around in the same blocks of code. Even more once the GPU
scheduler arrives.
This patch makes it more obvious exactly which flags word is which by renaming
'flags' to 'dispatch_flags'. Note that the bit definitions for this flags word
already have an 'I915_DISPATCH_' prefix on them and so are not quite so
ambiguous.
OTC-Jira: VIZ-1587
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
[danvet: Resolve conflict with Chris' rework of the bb parsing.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
We were enabling DP secondary streams even if the monitor
didn't support them. Fixes display problems on some DP
monitors.
Tested-by: Jim Boz <jim876@xs4all.nl>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The atom aux param interface only supports 4 bits for
the total write transfer size (header + payload). This
limits us to 12 bytes of payload rather than 16. Add a
check for this. Reads are not affected.
v2: switch to WARN_ON_ONCE
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
The logic was reversed from what the hw actually exposed.
Fixes graphics corruption in certain harvest configurations.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|