| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Nick Hoath <nicholas.hoath@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Commit 1e02ce4cccdc ("x86: Store a per-cpu shadow copy of CR4")
introduced CR4 shadows.
These shadows are initialized in early boot code. The commit missed
initialization for 64-bit PV(H) guests that this patch adds.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
|
|
A request in the ring buffer mustn't be read after it has been marked
as consumed. Otherwise it might already have been reused by the
frontend without violating the ring protocol.
To avoid inconsistencies in the backend only work on a private copy
of the request. This will ensure a malicious guest not being able to
bypass consistency checks of the backend by modifying an active
request.
Signed-off-by: Juergen Gross <jgross@suse.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
|
|
Hypercalls submitted by user space tools via the privcmd driver can
take a long time (potentially many 10s of seconds) if the hypercall
has many sub-operations.
A fully preemptible kernel may deschedule such as task in any upcall
called from a hypercall continuation.
However, in a kernel with voluntary or no preemption, hypercall
continuations in Xen allow event handlers to be run but the task
issuing the hypercall will not be descheduled until the hypercall is
complete and the ioctl returns to user space. These long running
tasks may also trigger the kernel's soft lockup detection.
Add xen_preemptible_hcall_begin() and xen_preemptible_hcall_end() to
bracket hypercalls that may be preempted. Use these in the privcmd
driver.
When returning from an upcall, call xen_maybe_preempt_hcall() which
adds a schedule point if if the current task was within a preemptible
hypercall.
Since _cond_resched() can move the task to a different CPU, clear and
set xen_in_preemptible_hcall around the call.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
|
|
Commit d524165cb8db ("x86/apic: Check x2apic early") tests X2APIC_ENABLE
bit of MSR_IA32_APICBASE when CONFIG_X86_X2APIC is off and panics
the kernel when this bit is set.
Xen's PV guests will pass this MSR read to the hypervisor which will
return its version of the MSR, where this bit might be set. Make sure
we clear it before returning MSR value to the caller.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
|
|
Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
Commit eb10d6355532 ("imx-drm: encoder prepare/mode_set must use adjusted mode")
broke the first LVDS modeset by using crtc->hwmode before crtc mode_set is
called. In fact, encoder prepare is not supposed to prepare the display clock
at all. Rather encoder mode_set should be used to set the DI clock rate, before
it is enabled by crtc commit.
Reported-by: Liu Ying <Ying.Liu@freescale.com>
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
The loop iterating over curr_ctrl in dw_hdmi terminates on mpixelclock == ~0UL,
so there needs to be an end of list element here in case a mode with a pixel
clock larger than 216 MHz is set.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
This patch limits the pixel clock to 13.4 MHz - 266 MHz for i.MX6Q
and 13.5 MHz - 270 MHz for i.MX6DL, which is the range documented
in the HDMI Transmitter chapter of the respective reference manuals.
Without this patch, when connected to a monitor capable of 2160p60
modes, dw_hdmi will happily report this mode and the IPU code will
cause a division by zero in ipu_di_config_clock when trying to figure
out how to divide the 264 MHz HSP clock down to ~600 MHz.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
Even if an unsupported mode with a pixel clock larger than two times the
264 MHz IPU HSP clock is set, don't divide by zero.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
As per the recommendation from PHY team, limit the max vco supported in CHV to 6.48 GHz
Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@linux.intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Added new PHY register definitions to control TDC buffer calibration and
digital lock threshold.
Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Currently, the command parser tries to create a secondary batch exactly
as large as the original, and vmap both. This is open to abuse by
userspace using extremely large batch objects, but only executing very
short batches. For example, this would be if userspace were to implement
a command submission ringbuffer. However, we only need to allocate pages
for just the contents of the command sequence in the batch - all
relocations copied to the secondary batch will reference the original
batch and so there can be no access to the secondary batch outside of
the explicit execution region.
Testcase: igt/gem_exec_big #ivb,byt,hsw
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88308
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
When a PCM draining is performed to an empty stream that has been
already in PREPARED state, the current code just ignores and leaves as
it is, although the drain is supposed to set all such streams to SETUP
state. This patch covers that overlooked case.
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
When querying the GTFIFOCTL register to check the FIFO space, the read value
must be masked. The operation is repeated explicitly in several places. This
change refactors the read-and-mask code into a function call.
v2: rebased on top of Mika's forcewake patch set, specifically:
[PATCH 8/8] drm/i915: Enum forcewake domains and domain identifiers
Change-Id: Id1a9f3785cb20b82d4caa330c37b31e4e384a3ef
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The manual recommends that we reset the DSP when we suspend so add that in
runtime suspend handler
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The IPC driver saved only IMR register, we need to save the CSR as well, so
add it
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The updated firmware expects the MMX ID to be used as 3, so update the
driver as well
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The "Extended Compat ID OS Feature Descriptor Specification" does not
require the (sub)compatible ids to be NUL-terminated, because they
are placed in a fixed-size buffer and only unused parts of it should
contain NULs. If the buffer is fully utilized, there is no place for NULs.
Consequently, the code which uses desc->ext_compat_id never expects the
data contained to be NUL terminated.
If the compatible id is stored after sub-compatible id, and the compatible
id is full length (8 bytes), the (useless) NUL terminator overwrites the
first byte of the sub-compatible id.
If the sub-compatible id is full length (8 bytes), the (useless) NUL
terminator ends up out of the buffer. The situation can happen in the RNDIS
function, where the buffer is a part of struct f_rndis_opts. The next
member of struct f_rndis_opts is a mutex, so its first byte gets
overwritten. The said byte is a part of a mutex'es member which contains
the information on whether the muext is locked or not. This can lead to a
deadlock, because, in a configfs-composed gadget when a function is linked
into a configuration with config_usb_cfg_link(), usb_get_function()
is called, which then calls rndis_alloc(), which tries locking the same
mutex and (wrongly) finds it already locked.
This patch eliminates NUL terminating of the (sub)compatible id.
Cc: <stable@vger.kernel.org> # v3.16+
Fixes: da4243145fb1: "usb: gadget: configfs: OS Extended Compatibility descriptors support"
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
In the wrapper the IRQ disable should be done by writing 1's to the
IRQ*_CLR register. Existing code is broken because it instead writes
zeros to IRQ*_SET register.
Fix this by adding functions dwc3_omap_write_irqmisc_clr() and
dwc3_omap_write_irq0_clr() which do the right thing.
Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver")
Cc: <stable@vger.kernel.org> # v3.2+
Signed-off-by: George Cherian <george.cherian@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
this patch fixes following sparse warnings:
uvc_v4l2.c:264:29: warning: symbol 'uvc_v4l2_ioctl_ops' was not declared. Should it be static?
uvc_v4l2.c:355:29: warning: symbol 'uvc_v4l2_fops' was not declared. Should it be static?
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
this patch fixes following sparse warnings:
g_ffs.c:136:3: warning: symbol 'gfs_configurations' was not declared. Should it be static?
g_ffs.c:281:16: warning: Using plain integer as NULL pointer
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
this patch fixes following sparse warnings:
uvc_video.c:283:5: warning: symbol 'uvcg_video_pump' was not declared. Should it be static?
uvc_video.c:342:5: warning: symbol 'uvcg_video_enable' was not declared. Should it be static?
uvc_video.c:381:5: warning: symbol 'uvcg_video_init' was not declared. Should it be static?
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
this patch fixes following sparse warnings:
f_sourcesink.c:347:34: warning: symbol 'ss_int_source_comp_desc' was not declared. Should it be static?
f_sourcesink.c:365:34: warning: symbol 'ss_int_sink_comp_desc' was not declared. Should it be static?
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
this patch fixes following sparse warnings:
f_uac2.c:57:12: warning: symbol 'uac2_name' was not declared. Should it be static?
f_uac2.c:637:36: warning: symbol 'in_clk_src_desc' was not declared. Should it be static?
f_uac2.c:649:36: warning: symbol 'out_clk_src_desc' was not declared. Should it be static?
f_uac2.c:661:39: warning: symbol 'usb_out_it_desc' was not declared. Should it be static?
f_uac2.c:675:39: warning: symbol 'io_in_it_desc' was not declared. Should it be static?
f_uac2.c:689:40: warning: symbol 'usb_in_ot_desc' was not declared. Should it be static?
f_uac2.c:703:40: warning: symbol 'io_out_ot_desc' was not declared. Should it be static?
f_uac2.c:716:34: warning: symbol 'ac_hdr_desc' was not declared. Should it be static?
f_uac2.c:754:34: warning: symbol 'as_out_hdr_desc' was not declared. Should it be static?
f_uac2.c:767:38: warning: symbol 'as_out_fmt1_desc' was not declared. Should it be static?
f_uac2.c:775:32: warning: symbol 'fs_epout_desc' was not declared. Should it be static?
f_uac2.c:785:32: warning: symbol 'hs_epout_desc' was not declared. Should it be static?
f_uac2.c:831:34: warning: symbol 'as_in_hdr_desc' was not declared. Should it be static?
f_uac2.c:844:38: warning: symbol 'as_in_fmt1_desc' was not declared. Should it be static?
f_uac2.c:852:32: warning: symbol 'fs_epin_desc' was not declared. Should it be static?
f_uac2.c:862:32: warning: symbol 'hs_epin_desc' was not declared. Should it be static?
f_uac2.c:1566:21: warning: symbol 'afunc_alloc' was not declared. Should it be static?
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
this patch fixes following sparse warning:
f_hid.c:572:30: warning: symbol 'f_hidg_fops' was not declared. Should it be static?
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
This is only an API consolidation and should make things more readable
it replaces var * HZ / 1000 by msecs_to_jiffies(var).
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
We still have a combination of legacy phys and generic phys in
use so we need to support both types of phy for musb_dsps.c.
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
The renesas usbhs driver calls extcon_get_edev_by_phandle(), which
is defined in drivers/extcon/extcon-class.c, and that can be a
loadable module. If the extcon-class support is disabled, usbhs
will work correctly for all devices that do not need extcon.
However, if extcon-class is a loadable module, and usbhs is
built-in, the kernel fails to link. In order to solve that,
we need a Kconfig dependency that allows extcon to be disabled
but does not allow usbhs built-in if extcon is a module.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
The value for the multipoint dts property is ignored when parsing with
of_property_read_bool, so we currently have multipoint always set as 1
even if value 0 is specified in the dts file.
Let's fix this to read the value too instead of just the property like
the binding documentation says as otherwise MUSB will fail to work
on devices with Mentor configuration that does not support multipoint.
Cc: Brian Hutchinson <b.hutchman@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
The gpio_chip operations receive a pointer the gpio_chip struct which is
contained in the driver's private struct, yet the container_of call in those
functions point to the mfd struct defined in include/linux/mfd/tps65912.h.
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: Nicolas Saenz Julienne <nicolassaenzj@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
node
The change:
7b8792bbdffdff3abda704f89c6a45ea97afdc62
gpiolib: of: Correct error handling in of_get_named_gpiod_flags
assumed that only one gpio-chip is registred per of-node.
Some drivers register more than one chip per of-node, so
adjust the matching function of_gpiochip_find_and_xlate to
not stop looking for chips if a node-match is found and
the translation fails.
Cc: Stable <stable@vger.kernel.org>
Fixes: 7b8792bbdffd ("gpiolib: of: Correct error handling in of_get_named_gpiod_flags")
Signed-off-by: Hans Holmberg <hans.holmberg@intel.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
Tested-by: Tyler Hall <tylerwhall@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Microsoft Natural Wireless Ergonomic Keyboard 7000 has special My
Favorites 1..5 keys which are handled through a vendor-defined usage
page (0xff05).
Apply MS_ERGONOMY quirks handling to USB PID 0x071d (Microsoft Microsoft
2.4GHz Transceiver V1.0) so that the My Favorites 1..5 keys are reported
as KEY_F14..18 events.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=52841
Signed-off-by: Jakub Sitnicki <jsitnicki@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
d1c7e29e8d27 (HID: i2c-hid: prevent buffer overflow in early IRQ)
changed hid_get_input() to read ihid->bufsize bytes, which can be
more than wMaxInputLength. This is the case with the Dell XPS 13
9343, and it is causing events to be missed. In some cases the
missed events are releases, which can cause the cursor to jump or
freeze, among other problems. Limit the number of bytes read to
min(wMaxInputLength, ihid->bufsize) to prevent such problems.
Fixes: d1c7e29e8d27 "HID: i2c-hid: prevent buffer overflow in early IRQ"
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Add quirk for Dell Chromebook 11 backlight.
Reported-and-tested-by: Owen Garland <garland.owen@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93451
Acked-by: Damien Lespiau <damien.lespiau@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
skylake_update_primary_plane() did not handle all pixel formats returned
by skl_format_to_fourcc(). Handle alpha similar to skl_update_plane().
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89052
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Per-controller spinlock needs to be properly initialized during device probe.
[jkosina@suse.cz: massage changelog]
[jkosina@suse.cz: drop hunk that has already been applied by previous
patch]
Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
A new fsync vs power fail test in xfstests indicated that XFS can
have unreliable data consistency when doing extending truncates that
require block zeroing. The blocks beyond EOF get zeroed in memory,
but we never force those changes to disk before we run the
transaction that extends the file size and exposes those blocks to
userspace. This can result in the blocks not being correctly zeroed
after a crash.
Because in-memory behaviour is correct, tools like fsx don't pick up
any coherency problems - it's not until the filesystem is shutdown
or the system crashes after writing the truncate transaction to the
journal but before the zeroed data in the page cache is flushed that
the issue is exposed.
Fix this by also flushing the dirty data in memory region between
the old size and new size when we've found blocks that need zeroing
in the truncate process.
Reported-by: Liu Bo <bo.li.liu@oracle.com>
cc: <stable@vger.kernel.org>
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
|
|
For filesystems without separate project quota inode field in the
superblock we just reuse project quota file for group quotas (and vice
versa) if project quota file is allocated and we need group quota file.
When we reuse the file, quota structures on disk suddenly have wrong
type stored in d_flags though. Nobody really cares about this (although
structure type reported to userspace was wrong as well) except
that after commit 14bf61ffe6ac (quota: Switch ->get_dqblk() and
->set_dqblk() to use bytes as space units) assertion in
xfs_qm_scall_getquota() started to trigger on xfs/106 test (apparently I
was testing without XFS_DEBUG so I didn't notice when submitting the
above commit).
Fix the problem by properly resetting ddq->d_flags when running quotacheck
for a quota file.
CC: stable@vger.kernel.org
Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
|
|
The argument contains a pointer to the old state, rename it to old_state
like in all other commit helper functions.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
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>
|
|
Atomic state handling adds a lot of indirection and complexity between
simple updates and drivers. For easier debugging the diagnostic output
is therefore rather chatty. Which is great for tracking down atomic
issues, but really annoying otherwise.
Add a new DRM_DEBUG_ATOMIC to be able to filter this out.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
The kerneldoc blocks for the drm_atomic_helper_*_set_property()
functions seem to have been copied from the plane disable handler
without being properly updated. Fix them.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The CRTC_STEREO_DOUBLE_ONLY define was introduced in commit:
commit ecb7e16bf187bc369cf6a5cd108582c01329980d
Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Date: Mon Dec 1 15:40:09 2014 -0800
drm: add helper to get crtc timings (v5)
but if we want the stereo h/v adjustments, we need to set the
CRTC_STEREO_DOUBLE flag. Otherwise, we'll get the wrong h/v for frame packing
stereo 3d modes.
Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
drm_crtc_vblank_get() is the new drm_vblank_get(), not the new
drm_vblank_off().
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
sony_dev_list_lock spinlock (which was introduced in d2d782fccee ("HID: sony:
Prevent duplicate controller connections") is not being initialized properly.
Fix that.
Reported-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
KMS drivers are in full control of their irq and vblank handling, if
they get a vblank interrupt before drm_vblank_init or after
drm_vblank_cleanup that's just a driver bug.
For ums driver there's only r128 and radeon which support vblank, and
they call drm_vblank_init in their driver load functions. Which again
means that userspace can do whatever it wants with interrupt, vblank
structures will always be there.
So this should never happen, let's catch driver issues with a WARN_ON.
Motivated by some discussions with Imre.
v2: Use WARN_ON_ONCE as suggested by Imre.
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
The pipe might already have been shut down, and then it's not a good
idea to call hw accessor functions. Instead use the same logic as
drm_vblank_off which has all the necessary checks to avoid troubles or
inconsistency.
Noticed by Imre while reviewing my patches to remove some sanity
checks from ->get_vblank_counter.
v2: Try harder. disable_and_save can still access the vblank stuff
when vblank->enabled isn't set. It has to, since vlbank irq could be
disable but the pipe is still on when being called from
drm_vblank_off. But we still want to use that code for more code
sharing. So add a check for vblank->enabled on top - if that's not set
we shouldn't have anyone waiting for the vblank. If we have that's a
pretty serious bug.
The other issue that Imre spotted is drm_vblank_cleanup. That code
again calls disable_and_save and so suffers from the same issues. But
really drm_irq_uninstall should have cleaned that all up, so replace
the code with WARN_ON. Note that we can't delete the timer cleanup
since drivers aren't required to use drm_irq_install/uninstall, but
can do their own irq handling.
v3: Make it clear that all that gunk in drm_irq_uninstall is really
just bandaids for UMS races between the irq/vblank code. In UMS
userspace is in control of enabling/disabling interrupts in general
and vblanks specifically.
v4: Imre observed that KMS drivers all call drm_vblank_cleanup before
drm_irq_uninstall (as they should), so again the code in there is dead
for KMS (due to dev->num_crtcs == 0 after drm_vblank_cleanup). Or
should be, so only WARN for KMS - with UMS userspace could try to do
evil things.
v5: After more discussion on irc we've gone back to v3: the
del_timer_sync is required in all cases in drm_vblank_cleanup, but
let's restrict the WARN_ON to kms drivers only. Imre was also
concerned that bad things could happen without the disable_and_save
call. But we immediately free vblank structures afterwards which makes
the save useless. And drm_handle_vblank has a check for dev->num_crtcs
to avoid surprises with ums.
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
Where possible right now. Just a small step towards nirvana ...
v2: git add. Uggh. Noticed by Imre.
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
UMS is no more!
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
