Age | Commit message (Collapse) | Author |
|
Let's be nice and interrupt the dpcd aux-dev reads/writes when there's
a signal pending. Much nicer if the user can hit ^C instead of having to
sit around waiting for the read/write to finish.
time dd if=/dev/drm_dp_aux0 bs=$((1024*1024))
^C
before:
real 0m34.681s
user 0m0.003s
sys 0m6.880s
after:
real 0m0.222s
user 0m0.006s
sys 0m0.057s
Cc: Rafael Antognolli <rafael.antognolli@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1461786225-7790-1-git-send-email-ville.syrjala@linux.intel.com
|
|
eMMC HS-DDR no longer works on the A80, despite it working when support
for this developed.
Disable it for now.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
The debug logging here can be very verbose in the kernel logs
and provides no information which userspace doesn't have the
access to already. Turn it off so kernel logs become more
manageable.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1461755507-30453-1-git-send-email-tvrtko.ursulin@linux.intel.com
|
|
Debug logging in this function does not provide any information
apart that the userspace is calling an ioctl on the connector.
There is not any info on the connector provided at all and
since there are other ioctls userspace typically calls which
do log useful things about the same connectors, remove this
one to make things a little bit more readable when KMS debugging
is turned on.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1461751622-26927-10-git-send-email-tvrtko.ursulin@linux.intel.com
|
|
Add the settings to support the NTSC standard.
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
|
|
Now that we have support for the composite output, we can start adding new
supported standards. Start with PAL, and we will add other eventually.
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
|
|
Some Allwinner SoCs have an IP called the TV encoder that is used to output
composite and VGA signals. In such a case, we need to use the second TCON
channel.
Add support for that TV encoder.
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
|
|
One of the A10 display pipeline possible output is an RGB interface to
drive LCD panels directly. This is done through the first channel of the
TCON that will output our video signals directly.
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
|
|
The Allwinner A10 and subsequent SoCs share the same display pipeline, with
variations in the number of controllers (1 or 2), or the presence or not of
some output (HDMI, TV, VGA) or not.
Add a driver with a limited set of features for now, and we will hopefully
support all of them eventually
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
|
|
... instead of just returning an error.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Josh Durgin <jdurgin@redhat.com>
|
|
A while ago, commit 9875201e1049 ("rbd: fix use-after free of
rbd_dev->disk") fixed rbd unmap vs notify race by introducing
an exported wrapper for flushing notifies and sticking it into
do_rbd_remove().
A similar problem exists on the rbd map path, though: the watch is
registered in rbd_dev_image_probe(), while the disk is set up quite
a few steps later, in rbd_dev_device_setup(). Nothing prevents
a notify from coming in and crashing on a NULL rbd_dev->disk:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
Call Trace:
[<ffffffffa0508344>] rbd_watch_cb+0x34/0x180 [rbd]
[<ffffffffa04bd290>] do_event_work+0x40/0xb0 [libceph]
[<ffffffff8109d5db>] process_one_work+0x17b/0x470
[<ffffffff8109e3ab>] worker_thread+0x11b/0x400
[<ffffffff8109e290>] ? rescuer_thread+0x400/0x400
[<ffffffff810a5acf>] kthread+0xcf/0xe0
[<ffffffff810b41b3>] ? finish_task_switch+0x53/0x170
[<ffffffff810a5a00>] ? kthread_create_on_node+0x140/0x140
[<ffffffff81645dd8>] ret_from_fork+0x58/0x90
[<ffffffff810a5a00>] ? kthread_create_on_node+0x140/0x140
RIP [<ffffffffa050828a>] rbd_dev_refresh+0xfa/0x180 [rbd]
If an error occurs during rbd map, we have to error out, potentially
tearing down a watch. Just like on rbd unmap, notifies have to be
flushed, otherwise rbd_watch_cb() may end up trying to read in the
image header after rbd_dev_image_release() has run:
Assertion failure in rbd_dev_header_info() at line 4722:
rbd_assert(rbd_image_format_valid(rbd_dev->image_format));
Call Trace:
[<ffffffff81cccee0>] ? rbd_parent_request_create+0x150/0x150
[<ffffffff81cd4e59>] rbd_dev_refresh+0x59/0x390
[<ffffffff81cd5229>] rbd_watch_cb+0x69/0x290
[<ffffffff81fde9bf>] do_event_work+0x10f/0x1c0
[<ffffffff81107799>] process_one_work+0x689/0x1a80
[<ffffffff811076f7>] ? process_one_work+0x5e7/0x1a80
[<ffffffff81132065>] ? finish_task_switch+0x225/0x640
[<ffffffff81107110>] ? pwq_dec_nr_in_flight+0x2b0/0x2b0
[<ffffffff81108c69>] worker_thread+0xd9/0x1320
[<ffffffff81108b90>] ? process_one_work+0x1a80/0x1a80
[<ffffffff8111b02d>] kthread+0x21d/0x2e0
[<ffffffff8111ae10>] ? kthread_stop+0x550/0x550
[<ffffffff82022802>] ret_from_fork+0x22/0x40
[<ffffffff8111ae10>] ? kthread_stop+0x550/0x550
RIP [<ffffffff81ccd8f9>] rbd_dev_header_info+0xa19/0x1e30
To fix this, a) check if RBD_DEV_FLAG_EXISTS is set before calling
revalidate_disk(), b) move ceph_osdc_flush_notifies() call into
rbd_dev_header_unwatch_sync() to cover rbd map error paths and c) turn
header read-in into a critical section. The latter also happens to
take care of rbd map foo@bar vs rbd snap rm foo@bar race.
Fixes: http://tracker.ceph.com/issues/15490
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: Josh Durgin <jdurgin@redhat.com>
|
|
Power allocator's parameters are S32 type, so use %d to print them.
Acked-by: Javi Merino <javi.merino@arm.com>
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
|
|
When calculate temperature, old code firstly do division and then
convert to "millicelsius" unit. This will lose resolution and only can
read back temperature with "Celsius" unit.
So firstly scale step value to "millicelsius" and then do division, so
finally we can increase resolution for temperature value. Also refine
the calculation from temperature value to step value.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
|
|
The MIC VOP driver does two successive reads from user space to read a
variable length data structure. Kernel memory corruption can result if
the data structure changes between the two reads. This patch disallows
the chance of this happening.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116651
Reported by: Pengfei Wang <wpengfeinudt@gmail.com>
Reviewed-by: Sudeep Dutt <sudeep.dutt@intel.com>
Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Since fwnode may hold ERR_PTR(-ENODEV) or it may be NULL,
the fwnode type checks is_of_node(), is_acpi_node() and is
is_pset_node() need to consider it. Using IS_ERR_OR_NULL()
to check it.
Fixes: 0d67e0fa1664 (device property: fix for a case of use-after-free)
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
[ rjw: Subject & changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
If PAGE_SIZE is bigger than BNXT_RX_PAGE_SIZE, that means the native CPU
page is bigger than the maximum length of the RX BD. Divide the page
into multiple 32K buffers for the aggregation ring.
Add an offset field in the bnxt_sw_rx_agg_bd struct to keep track of the
page offset of each buffer. Since each page can be referenced by multiple
buffer entries, call get_page() as needed to get the proper reference
count.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The RX BD length field of this device is 16-bit, so the largest buffer
size is 65535. For LRO and GRO, we allocate native CPU pages for the
aggregation ring buffers. It won't work if the native CPU page size is
64K or bigger.
We fix this by defining BNXT_RX_PAGE_SIZE to be native CPU page size
up to 32K. Replace PAGE_SIZE with BNXT_RX_PAGE_SIZE in all appropriate
places related to the rx aggregation ring logic.
The next patch will add additional logic to divide the page into 32K
chunks for aggrgation ring buffers if PAGE_SIZE is bigger than
BNXT_RX_PAGE_SIZE.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Only MSI-X can be used on a VF. The driver should fail initialization
if it cannot successfully enable MSI-X.
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux
Pull i2c fixes from Wolfram Sang:
"I2C has one buildfix, one ABBA deadlock fix, and three simple 'add ID'
patches"
* 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
i2c: exynos5: Fix possible ABBA deadlock by keeping I2C clock prepared
i2c: cpm: Fix build break due to incompatible pointer types
i2c: ismt: Add Intel DNV PCI ID
i2c: xlp9xx: add support for Broadcom Vulcan
i2c: rk3x: add support for rk3228
|
|
V2: disable all vm interrupts in late_init()
Signed-off-by: Flora Cui <Flora.Cui@amd.com>
Reviewed-by: Ken Wang <Qingqing.Wang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
It will help identify problematic boards.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
This reverts commit bedf2a65c1aa8fb29ba8527fd00c0f68ec1f55f1.
See the radeon revert for an extended description.
Cc: stable@vger.kernel.org
|
|
When crtc/timing is disabled on boot the dig block
should be stopped in order ignore timing from crtc,
reset the steering fifo otherwise we get display
corruption or hung in dp sst mode.
v2: agd: fix coding style
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Fixes the following scenario:
1. Page table bo allocated in vram and linked to man->lru.
tbo->list_kref.refcount=2
2. Page table bo is swapped out and removed from man->lru.
tbo->list_kref.refcount=1
3. Command submission from userspace. Page table bo is moved
to vram. ttm_bo_move_to_lru_tail() link it to man->lru and
don't increase the kref count.
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Flora Cui <Flora.Cui@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
git://git.infradead.org/users/dvhart/linux-platform-drivers-x86
Pull x86 platform driver fix from Darren Hart:
"Fix regression caused by hotkey enabling value in toshiba_acpi"
* tag 'platform-drivers-x86-v4.6-3' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86:
toshiba_acpi: Fix regression caused by hotkey enabling value
|
|
amdgpu gained dev->struct_mutex usage, and that's because it's walking
the dev->filelist list. Protect that list with it's own lock to take
one more step towards getting rid of struct_mutex usage in drivers
once and for all.
While doing the conversion I noticed that 2 debugfs files in i915
completely lacked appropriate locking. Fix that up too.
v2: don't forget to switch to drm_gem_object_unreference_unlocked.
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1461691808-12414-9-git-send-email-daniel.vetter@ffwll.ch
|
|
It's only used for legacy mmaping support now.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1461691808-12414-8-git-send-email-daniel.vetter@ffwll.ch
|
|
And again make sure it's a no-op for modern drivers. Another case of
dev->struct_mutex gone for modern drivers!
Note that the entirety of the legacy addmap interface is now protected
by DRIVER_MODESET. Note that just auditing kernel code is not enough,
since userspace loves to set up legacy maps on it's own for various
things - with ums userspace and kernel space share control over
resources.
v2: Also add a DRIVER_* check like for all other maps functions to
really short-circuit the code. And give drm_legacy_rmmap used by the
dev unregister code the same treatment.
v3:
- remove redundant return; (Alex, Chris)
- don't special case nouveau with DRIVER_KMS_LEGACY_CONTEXT.
v4: Again special case nouveau. The problem is not directly in the
ddx, but that it calls dri1 functions from the X server. And those do
call drmAddMap. Fixed only in
commit b1a630b48210d6a3c44994fce1b73273000ace5c
Author: Dave Airlie <airlied@redhat.com>
Date: Wed Nov 7 14:45:14 2012 +1000
nouveau: drop DRI1 device open interface.
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1461741618-12679-1-git-send-email-daniel.vetter@ffwll.ch
|
|
Like in
commit 0e975980d435d58df2d430d688b8c18778b42218
Author: Peter Antoine <peter.antoine@intel.com>
Date: Tue Jun 23 08:18:49 2015 +0100
drm: Turn off Legacy Context Functions
we need to again make an exception for nouveau, but everyone else
really doesn't need this.
Dave Airlie dug out again why we need this: The problem is the legacy
dri1 open function the nouveau ddx called, and the problematic code is
actually in the X server itself. It was only fixed in
commit b1a630b48210d6a3c44994fce1b73273000ace5c
Author: Dave Airlie <airlied@redhat.com>
Date: Wed Nov 7 14:45:14 2012 +1000
nouveau: drop DRI1 device open interface.
Cc: Peter Antoine <peter.antoine@intel.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1461691808-12414-5-git-send-email-daniel.vetter@ffwll.ch
Link: http://patchwork.freedesktop.org/patch/msgid/1461691808-12414-6-git-send-email-daniel.vetter@ffwll.ch
|
|
Somehow my SNB GT1 (Dell XPS 8300) gets very unhappy around
GPU hangs if the RPS EI/thresholds aren't suitably aligned.
It seems like scheduling/timer interupts stop working somehow
and things get stuck eg. in usleep_range().
I bisected the problem down to
commit 8a5864377b12 ("drm/i915/skl: Restructured the gen6_set_rps_thresholds function")
I observed that before all the values were at least multiples of 25,
but afterwards they are not. And rounding things up to the next multiple
of 25 does seem to help, so lets' do that. I also tried roundup(..., 5)
but that wasn't sufficient. Also I have no idea if we might need this sort of
thing on gen9+ as well.
These are the original EI/thresholds:
LOW_POWER
GEN6_RP_UP_EI 12500
GEN6_RP_UP_THRESHOLD 11800
GEN6_RP_DOWN_EI 25000
GEN6_RP_DOWN_THRESHOLD 21250
BETWEEN
GEN6_RP_UP_EI 10250
GEN6_RP_UP_THRESHOLD 9225
GEN6_RP_DOWN_EI 25000
GEN6_RP_DOWN_THRESHOLD 18750
HIGH_POWER
GEN6_RP_UP_EI 8000
GEN6_RP_UP_THRESHOLD 6800
GEN6_RP_DOWN_EI 25000
GEN6_RP_DOWN_THRESHOLD 15000
These are after 8a5864377b12:
LOW_POWER
GEN6_RP_UP_EI 12500
GEN6_RP_UP_THRESHOLD 11875
GEN6_RP_DOWN_EI 25000
GEN6_RP_DOWN_THRESHOLD 21250
BETWEEN
GEN6_RP_UP_EI 10156
GEN6_RP_UP_THRESHOLD 9140
GEN6_RP_DOWN_EI 25000
GEN6_RP_DOWN_THRESHOLD 18750
HIGH_POWER
GEN6_RP_UP_EI 7812
GEN6_RP_UP_THRESHOLD 6640
GEN6_RP_DOWN_EI 25000
GEN6_RP_DOWN_THRESHOLD 15000
And these are what we have after this patch:
LOW_POWER
GEN6_RP_UP_EI 12500
GEN6_RP_UP_THRESHOLD 11875
GEN6_RP_DOWN_EI 25000
GEN6_RP_DOWN_THRESHOLD 21250
BETWEEN
GEN6_RP_UP_EI 10175
GEN6_RP_UP_THRESHOLD 9150
GEN6_RP_DOWN_EI 25000
GEN6_RP_DOWN_THRESHOLD 18750
HIGH_POWER
GEN6_RP_UP_EI 7825
GEN6_RP_UP_THRESHOLD 6650
GEN6_RP_DOWN_EI 25000
GEN6_RP_DOWN_THRESHOLD 15000
Cc: stable@vger.kernel.org
Cc: Akash Goel <akash.goel@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Testcase: igt/kms_pipe_crc_basic/hang-read-crc-pipe-B
Fixes: 8a5864377b12 ("drm/i915/skl: Restructured the gen6_set_rps_thresholds function")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1461159836-9108-1-git-send-email-ville.syrjala@linux.intel.com
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
(cherry picked from commit 8a292d016d1cc4938ff14b4df25328230b08a408)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
This patch does the following:
- Fakes live status of HDMI as connected (even if that's not).
While testing certain (monitor + cable) combinations with
various intel platforms, it seems that live status register
doesn't work reliably on some older devices. So limit the
live_status check for HDMI detection, only for platforms
from gen7 onwards.
V2: restrict faking live_status to certain platforms
V3: (Ville)
- keep the debug message for !live_status case
- fix indentation of comment
- remove "warning" from the debug message
(Jani)
- Change format of fix details in the commit message
Fixes: 237ed86c693d ("drm/i915: Check live status before reading edid")
Cc: stable@vger.kernel.org # v4.4
Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1461237606-16491-1-git-send-email-shashank.sharma@intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
(cherry picked from commit 4f4a8185011773f7520d9916c6857db946e7f9d1)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
It was noticed on bug #94087 that module parameter
i915.edp_vswing=2 that should override the VBT setting
to use default voltage swing (400 mV) was not applied
for Broadwell.
This patch provides a fix for this by checking if default
i.e. higher voltage swing is requested to be used and
applies the DDI translations table for DP instead of eDP
(low vswing) table.
v2: Combine two if statements into one (Jani)
v3: Change dev_priv->edp_low_vswing to use dev_priv->vbt.edp.low_vswing
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94087
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1461155942-7749-1-git-send-email-mika.kahola@intel.com
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
(cherry picked from commit 00983519214b61c1b9371ec2ed55a4dde773e384)
[Jani: s/dev_priv->vbt.edp.low_vswing/dev_priv->edp_low_vswing/ to backport]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
The driver's VDD on/off logic assumes that whenever the VDD is on we
also hold an AUX power domain reference. Since BIOS can leave the VDD on
during booting and resuming and on DDI platforms we won't take a
corresponding power reference, the above assumption won't hold on those
platforms and an eventual delayed VDD off work will do an extraneous AUX
power domain put resulting in a refcount underflow. Fix this the same
way we did this for non-DDI DP encoders:
commit 6d93c0c41760c0 ("drm/i915: fix VDD state tracking after system
resume")
At the same time call the DP encoder suspend handler the same way as the
non-DDI DP encoders do to flush any pending VDD off work. Leaving the
work running may cause a HW access where we don't expect this (at a point
where power domains are suspended already).
While at it remove an unnecessary function call indirection.
This fixed for me AUX refcount underflow problems on BXT during
suspend/resume.
CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
CC: stable@vger.kernel.org
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1460963062-13211-4-git-send-email-imre.deak@intel.com
(cherry picked from commit bf93ba67e9c05882f05b7ca2d773cfc8bf462c2a)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
During system resume we depended on pci_enable_device() also putting the
device into PCI D0 state. This won't work if the PCI device was already
enabled but still in D3 state. This is because pci_enable_device() is
refcounted and will not change the HW state if called with a non-zero
refcount. Leaving the device in D3 will make all subsequent device
accesses fail.
This didn't cause a problem most of the time, since we resumed with an
enable refcount of 0. But it fails at least after module reload because
after that we also happen to leak a PCI device enable reference: During
probing we call drm_get_pci_dev() which will enable the PCI device, but
during device removal drm_put_dev() won't disable it. This is a bug of
its own in DRM core, but without much harm as it only leaves the PCI
device enabled. Fixing it is also a bit more involved, due to DRM
mid-layering and because it affects non-i915 drivers too. The fix in
this patch is valid regardless of the problem in DRM core.
v2:
- Add a code comment about the relation of this fix to the freeze/thaw
vs. the suspend/resume phases. (Ville)
- Add a code comment about the inconsistent ordering of set power state
and device enable calls. (Chris)
CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
CC: Chris Wilson <chris@chris-wilson.co.uk>
CC: stable@vger.kernel.org
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1460979954-14503-1-git-send-email-imre.deak@intel.com
(cherry picked from commit 44410cd0bfb26bde9288da34c190cc9267d42a20)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
The legacy cursor ioctl expects to be asynchronous with respect to other
screen updates, in particular page flips. As X updates the cursor from a
signal context, if the cursor blocks then it will stall both the input
and output chains causing bad stuttering and horrible UX.
Reported-and-tested-by: Rafael Ristovski <rafael.ristovski@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94980
Fixes: 5008e874edd34 ("drm/i915: Make wait_for_flips interruptible.")
Suggested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org
Link: http://patchwork.freedesktop.org/patch/msgid/1460922166-20292-1-git-send-email-chris@chris-wilson.co.uk
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
(cherry picked from commit acf4e84d6167317ff21be5c03e1ea76ea5783701)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
The sclp_ctl_ioctl_sccb function uses two copy_from_user calls to
retrieve the sclp request from user space. The first copy_from_user
fetches the length of the request which is stored in the first two
bytes of the request. The second copy_from_user gets the complete
sclp request, but this copies the length field a second time.
A malicious user may have changed the length in the meantime.
Reported-by: Pengfei Wang <wpengfeinudt@gmail.com>
Reviewed-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
|
|
Only two drivers implement this hook. vmwgfx (which doesn't need it
really) and legacy radeon (which since v1 has been nuked, yay).
v1: Rebase over radeon ums removal.
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1461691808-12414-6-git-send-email-daniel.vetter@ffwll.ch
|
|
It belongs right next to the addmap and rmmap functions really. And
for OCD consistency name it drm_legacy_getmap_ioctl.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1461691808-12414-4-git-send-email-daniel.vetter@ffwll.ch
|
|
Except for the ->lasclose driver callback evrything in drm_lastclose()
is all legacy cruft and can be hidden. Which means another
dev->struct_mutex site disappears entirely for modern drivers!
Also while at it change the return value of drm_lastclose to void
since it will always succeed. No one checks the return value of
close() anyway, ever.
v2: Move misplaced hunk, spotted by 0day.
Cc: Thierry Reding <thierry.reding@gmail.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1461691808-12414-3-git-send-email-daniel.vetter@ffwll.ch
|
|
It has a DRIVER_MODESET check to sure make it's not creating havoc
for drm drivers. Make that clear in the name too.
v2: Move misplaced hunk, spotted by 0day and Thierry.
Cc: Thierry Reding <thierry.reding@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1461691808-12414-2-git-send-email-daniel.vetter@ffwll.ch
|
|
When detaching contexts, we may still have interrupts in the system
which are yet to be delivered to any CPU and be acked in the PSL.
This can result in a subsequent unrelated process getting an spurious
IRQ or an interrupt for a non-existent context.
This polls the PSL to ensure that the PSL is clear of IRQs for the
detached context, before removing the context from the idr.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Tested-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Acked-by: Ian Munsie <imunsie@au1.ibm.com>
Tested-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
Keep IRQ mappings on context teardown. This won't leak IRQs as if we
allocate the mapping again, the generic code will give the same
mapping used last time.
Doing this works around a race in the generic code. Masking the
interrupt introduces a race which can crash the kernel or result in
IRQ that is never EOIed. The lost of EOI results in all subsequent
mappings to the same HW IRQ never receiving an interrupt.
We've seen this race with cxl test cases which are doing heavy context
startup and teardown at the same time as heavy interrupt load.
A fix to the generic code is being investigated also.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Cc: stable@vger.kernel.org # 3.8
Tested-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Acked-by: Ian Munsie <imunsie@au1.ibm.com>
Tested-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
Need to move the free function around a bit, but otherwise mostly
just removing code.
Specifically we can nuke all the _locked variants since the weak idr
reference is now protected by the idr_mutex, which we never hold
anywhere expect in the lookup/reg/unreg functions. And those never
call anything else.
Another benefit of this is that this patch switches the weak reference
logic from kref_put_mutex to kref_get_unless_zero. And the later is in
general more flexible wrt accomodating multiple weak references
protected by different locks, which might or might not come handy
eventually.
But one consequence of that switch is that we need to acquire the
blob_lock from the free function for the list_del calls. That's a bit
tricky to pull off, but works well if we pick the exact same scheme as
is already used for framebuffers. Most important changes:
- filp list is maintainer by create/destroy_blob ioctls directly
(already the case, so we can just remove the redundant list_del from
the free function).
- filp close handler walks the filp-private list lockless - works
because we know no one else can access it. I copied the same comment
from the fb code over to explain this.
- Otherwise we need to sufficiently restrict blob_lock critical
sections to avoid all the unreference calls. Easy to do once the
blob_lock only protects the list, and no longer the weak reference.
Cc: Dave Airlie <airlied@gmail.com>
Cc: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Random drive-by refactoring I spotted.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Dave Airlie had at least the refcount leak fixed in a later patch (but
that patch does other things which need a bit more work). But we still
have the trouble that silly userspace could hit the WARN_ON in
drm_mode_object_find.
Fix this all up to make sure we don't leak objects, and don't spew
into demsg.
Fixes: d0f37cf62979 ("drm/mode: move framebuffer reference into object.")
Testcase: igt/kms_addfb_basic/invalid-*-prop*
Cc: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Slipped through the cracks in my review. The one issue I spotted
is that drm_mode_object_find now acquires references and can be
used on FB objects, which caused follow-on bugs in get/set_prop ioctls.
Follow-up patches will fix that.
[airlied: fixup some incr fb/decr object mixups]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
https://github.com/foss-for-synopsys-dwc-arc-processors/linux into drm-next
This is DRM driver for ARC PGU - simple bitstreamer used on
Synopsys ARC SDP boards (both AXS101 and AXS103).
* 'topic-arcpgu-v6' of https://github.com/foss-for-synopsys-dwc-arc-processors/linux:
arc: axs10x - add support of ARC PGU
MAINTAINERS: Add maintainer for ARC PGU display controller
drm: Add DT bindings documentation for ARC PGU display controller
drm: Add support of ARC PGU display controller
|
|
virtio_gpu was failing to send vblank events when using the atomic IOCTL
with the DRM_MODE_PAGE_FLIP_EVENT flag set. This patch fixes each and
enables atomic pageflips updates.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Some hubs are forgetful, and end up forgetting whatever GUID we set
previously after we do a suspend/resume cycle. This can lead to
hotplugging breaking (along with probably other things) since the hub
will start sending connection notifications with the wrong GUID. As
such, we need to check on resume whether or not the GUID the hub is
giving us is valid.
Signed-off-by: Lyude <cpaul@redhat.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1460580618-7421-1-git-send-email-cpaul@redhat.com
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
We can thank KASAN for finding this, otherwise I probably would have spent
hours on it. This fixes a somewhat harder to trigger kernel panic, occuring
while enabling MST where the port we were currently updating the payload on
would have all of it's refs dropped before we finished what we were doing:
==================================================================
BUG: KASAN: use-after-free in drm_dp_update_payload_part1+0xb3f/0xdb0 [drm_kms_helper] at addr ffff8800d29de018
Read of size 4 by task Xorg/973
=============================================================================
BUG kmalloc-2048 (Tainted: G B W ): kasan: bad access detected
-----------------------------------------------------------------------------
INFO: Allocated in drm_dp_add_port+0x1aa/0x1ed0 [drm_kms_helper] age=16477 cpu=0 pid=2175
___slab_alloc+0x472/0x490
__slab_alloc+0x20/0x40
kmem_cache_alloc_trace+0x151/0x190
drm_dp_add_port+0x1aa/0x1ed0 [drm_kms_helper]
drm_dp_send_link_address+0x526/0x960 [drm_kms_helper]
drm_dp_check_and_send_link_address+0x1ac/0x210 [drm_kms_helper]
drm_dp_mst_link_probe_work+0x77/0xd0 [drm_kms_helper]
process_one_work+0x562/0x1350
worker_thread+0xd9/0x1390
kthread+0x1c5/0x260
ret_from_fork+0x22/0x40
INFO: Freed in drm_dp_free_mst_port+0x50/0x60 [drm_kms_helper] age=7521 cpu=0 pid=2175
__slab_free+0x17f/0x2d0
kfree+0x169/0x180
drm_dp_free_mst_port+0x50/0x60 [drm_kms_helper]
drm_dp_destroy_connector_work+0x2b8/0x490 [drm_kms_helper]
process_one_work+0x562/0x1350
worker_thread+0xd9/0x1390
kthread+0x1c5/0x260
ret_from_fork+0x22/0x40
which on this T460s, would eventually lead to kernel panics in somewhat
random places later in intel_mst_enable_dp() if we got lucky enough.
Signed-off-by: Lyude <cpaul@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
|