| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
In symmetry we save context first before suspend and restore it last after
resume.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
In case of tuner only card there is no need to take care of the codec which is
anyway absent.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
If user does not supply tea575x_tuner parameter the driver tries to detect the
tuner type. The failed codec initialization is considered as FM-only card
present, however the driver still registers an IRQ handler for it.
Move codec detection earlier to set tea575x_tuner parameter before check.
Here the following functions are introduced
reset_coded() resets AC97 codec
snd_fm801_chip_multichannel_init() initializes cards with multichannel support
Fixes: 5618955c4269 (ALSA: fm801: move to pcim_* and devm_* functions)
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The commit d7ba858a7f7a (ALSA: fm801: implement TEA575x tuner autodetection)
brings autodetection to the driver. However the autodetection algorithm misses
the TUNER_ONLY bit if it is supplied by the user.
Thus, user gets weird messages and no card registered.
snd_fm801 0000:0d:01.0: detected TEA575x radio type SF64-PCR
snd_fm801 0000:0d:01.0: AC'97 interface is busy (1)
snd_fm801 0000:0d:01.0: AC'97 interface is busy (1)
...
snd_fm801 0000:0d:01.0: AC'97 0 does not respond - RESET
snd_fm801 0000:0d:01.0: AC'97 interface is busy (1)
snd_fm801 0000:0d:01.0: AC'97 interface is busy (1)
snd_fm801 0000:0d:01.0: AC'97 0 access is not valid [0x0], removing mixer.
snd_fm801: probe of 0000:0d:01.0 failed with error -5
Do a copy of TUNER_ONLY bit to be applied after autodetection is done.
Fixes: d7ba858a7f7a (ALSA: fm801: implement TEA575x tuner autodetection)
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
There is no need to store struct pci_dev in struct fm801. Generic struct device
can be easily translated to struct pci_dev whenever it's needed, in particular
for one user for now.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The compiler complains on unused condition as follows
sound/pci/fm801.c: In function ‘snd_fm801_interrupt’:
sound/pci/fm801.c:585:3: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]
Put the curly braces around empty body as suggested.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The patch introduces two new helpers fm801_iowrite16() and fm801_ioread16() to
write and read the registers by offset. Previously similar was done to access
the hardware registers by their names.
Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Otherwise we will have a warning on ->remove() since device is a PCI one.
WARNING: CPU: 4 PID: 1411 at /home/andy/prj/linux/fs/proc/generic.c:575 remove_proc_entry+0x137/0x160()
remove_proc_entry: removing non-empty directory 'irq/21', leaking at least 'snd_fm801'
Fixes: 5618955c4269 (ALSA: fm801: move to pcim_* and devm_* functions)
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
This is an API consolidation only. The use of kmalloc + memset to 0
is equivalent to kzalloc.
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
AZX_DCAPS_REVERSE_ASSIGN is no longer referred by any code.
Let's drop it.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
AZX_DCAPS_POSFIX_VIA is coupled always with AZX_DRIVER_VIA type, so we
don't have to keep this bit in dcaps. Save one more!
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
AZX_DCAPS_RIRB_DELAY is dedicated only for Nvidia and its purpose is
just to set a flag in bus. So it's better to be set in the toplevel
driver, either hda_intel.c or hda_tegra.c, instead of the common
hda_controller.c. This also allows us to strip this flag from dcaps,
so save one more bit there.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
AZX_DCAPS_RIRB_PRE_DELAY is always tied with AZX_DCAPS_CTX_WORKAROUND,
which is Creative's XFi specific. So, we can replace it and reduce
one more bit free for DCAPS.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Adding control elements is just for models supported by old
firewire-speakers modules. The processing should be in a function to add
model-dependent quirk.
This commit moves the codes to the function. As a result, the function
should handle error state, thus this commit also changes prototype of
the function.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Currently, assignment to model-dependent quirk is corresponding to
asynchronous transactions on IEEE 1394 bus. This is also achieved with
device entry.
This commit changes the processing of model-dependent quirk with the
entry. As a result, the transactions are sent only for Loud models.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
ALSA OXFW driver uses AV/C Audio Subunit commands to control some models.
The commands get/set the state of Feature function block of the subunit.
The commands are not specific to OXFW, thus there's a possibility to use
them in the other drivers.
Currently, helper functions for the commands require 'struct snd_oxfw',
although, it's not necessarily required. It's better to change prototype
of the functions without the structure for future use.
This commit changes the prototype.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
This commit renames local functions with prefix 'spkr_', so that they're
for firewire-speakers.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
In ALSA firewire stack, drivers basically has no control elements. This
is due to the fact that each model has own functionality even if they use
the same communication chipset. Implementing all of the functionalities in
kernel space unreasonably increases our efforts to maintain the stack. In
most case, these functionalities can be implemented in userspace via Linux
fw character devices.
However, ALSA OXFW driver has control elements comes from old
firewire-speakers driver. Adding the elements is in a file names as
'oxfw-control.c', while the elements are really model-specific. The
name is confusing because it gives an idea to handle control elements
for all of OXFW-based models.
This commit renames the file so that it's just for models supported by
old firewire-speakers driver.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Intel Atom processors seem to have a problem at recording when
bdl_pos_adj is set to an odd value. When a value like 1 is used, it
may drop the samples unexpectedly. Actually, for the old Atoms, we
used to set AZX_DRIVER_SCH type, and this assigns 32 as default.
Meanwhile the newer chips, Baytrail and Braswell, are set as
AZX_DRIVER_PCH, and the lower default value, 1, is assigned.
This patch changes the default values for these chipsets to a safer
default, 32, again. Since changing the driver type (AZX_DRIVER_XXX)
leads to the rename of the driver string, it would result in a
possible regression. So, we can't change the type. Instead, in this
patch, manual (ugly) PCI ID checks are added on top.
A drawback by this increase is the slight increase of the latency, but
it's a sub-ms order in normal situations, so mostly negligible.
Reported-and-tested-by: Jochen Henneberg <jh@henneberg-systemdesign.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Just a minor cleanup; instead of passing an array, pass the assigned
bdl_pos_adj option value directory in struct azx. Also split the code
to get the default bdl_pos_adj value for the change that will follow
after this.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The usb_protocol_ops structures are never modified, so declare them as
const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
A couple of i915_audio_component ops have been added and accessed
directly from patch_hdmi.c. Ideally all these should be factored out
into hdac_i915.c.
This patch does it, adds two new helper functions for setting N/CTS
and fetching ELD bytes. One bonus is that the hackish widget vs port
mapping is also moved to hdac_i915.c, so that it can be fixed /
enhanced more cleanly.
Reviewed-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Since we have a new audio component ops to fetch the current ELD and
state now, we can reduce the usage of unsol event of HDMI/DP pins.
The unsol event isn't only unreliable, but it also needs the power
up/down of the codec and link at each time, which is a significant
power and time loss.
In this patch, the jack creation and unsol/jack event handling are
modified to use the audio component for the dedicated Intel chips.
The jack handling got slightly more codes than a simple usage of
hda_jack layer since we need to deal directly with snd_jack object;
the hda_jack layer is basically designed for the pin sense read and
unsol events, both of which aren't used any longer in our case.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The recent commit [e90247f9fcee: ALSA: hda - Split ELD update code
from hdmi_present_sense()] rewrote the HDMI jack handling code, but a
slight behavior change sneaked in unexpectedly. When the jack isn't
connected, it tries repoll unnecessarily.
This patch addresses the flaw, to the right behavior as before.
Fixes: e90247f9fcee ('ALSA: hda - Split ELD update code from hdmi_present_sense()')
Reported-and-tested-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
This patch adds a reverse mapping from a digital port number to
intel_encoder object containing the corresponding intel_digital_port.
It simplifies the query of the encoder a lot.
Note that, even if it's a valid digital port, the dig_port_map[] might
point still to NULL -- usually it implies a DP MST port. Due to this
fact, the NULL check in each place has no WARN_ON() and just skips the
port. Once when the situation changes in future, we might introduce
WARN_ON() for a more strict check.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Implement a new i915_audio_component_ops, get_eld(). It's called by
the audio driver to fetch the current audio status and ELD of the
given HDMI/DP port. It returns the size of expected ELD bytes if it's
valid, zero if no valid ELD is found, or a negative error code. The
current state of audio on/off is stored in the given pointer, too.
Note that the returned size isn't limited to the given max bytes. If
the size is greater than the max bytes, it means that only a part of
ELD has been copied back.
For achieving this implementation, a new field audio_connector is
added to struct intel_digital_port. It points to the connector
assigned to the given digital port. It's set/reset at each audio
enable/disable call in intel_audio.c, and protected with av_mutex.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Due to the recent change, HDA controller driver for Intel PCH tries to
bind i915 audio component always at the probe time no matter whether
HDMI/DP codec is found. This is, however, superflulous for old
chipsets (e.g. on IVB) where they don't have always the HDMI/DP codecs
but often have only a discrete GPU instead.
For the newer chipsets, we need already the i915 binding from the
beginning due to power well control. Meanwhile, for older chipsets
where we don't need power well, we don't need the i915 binding at the
controller level.
This patch removes again the i915 binding in the HDA controller driver
for old Intel PCHs, but adds the binding in HDMI/DP codec driver
instead. This allows still the use of the direct notification from
the graphics driver while we can avoid the unnecessary load of i915
driver for machines only with another GPU.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The audio component is enabled only when CONFIG_SND_HDA_I915 is set.
Give a dummy macro for allowing the compiler optimize out the relevant
codes when this Kconfig isn't set.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The OSS sound drivers used to rely on virt_to_bus(), but don't any more,
so we can remove the Kconfig dependency.
As a lot of architectures don't provide VIRT_TO_BUS any more, removing
the dependency in sounds/oss/ would make the deprecated drivers appear
there, which we probably don't want. Instead I'm replacing the
simple dependency with 'VIRT_TO_BUS || RPC || NETWINDER' so we can
still build these sound drivers for the platforms that need them,
but don't change anything on other architectures.
As a follow-up, we can remove the virt_to_bus() implementation
and Kconfig symbol in the ARM architecture.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
snd-hda-intel driver tries to bind with i915 audio component always
when AZX_DCAPS_I915_POWERWELL is set in the driver caps. This was
mostly OK in the past, as the flag was applied only to a limited set
of devices, namely, Haswell and Broadwell. On these machines, i915
graphics is almost mandatory as long as HDMI/DP is concerned.
Recently the application of i915 binding was widened to more Intel
chips. On these chips, the chance of a kernel without i915 graphics
is much higher, and such user would hit an error like:
snd_hda_intel 0000:00:1b.0: failed to add i915 component master (-19)
Although the error itself is harmless, it's certainly superfluous even
to try binding with i915, if we already know that there isn't any.
This patch fixes it by simply defining AZX_DCAPS_I915_POWERWELL as 0
in the case without i915. Then all codes referring to this flag will
be optimized out by the compiler.
Fixes: 6603249dcdbb ('ALSA: hda - Enable audio component for old Intel PCH devices')
Reported-by: kernel test robot <ying.huang@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The recent commit [6603249dcdbb: ALSA: hda - Enable audio component
for old Intel PCH devices] enabled the i915 binding for HDMI/DP on old
Intel PCHs. But many boards are without HDMI/DP, and they actually
don't need i915 binding, and yet the driver has a check of i915
binding and complains like
Haswell must be built with CONFIG_SND_HDA_I915
This error is false-positive, and it should be put only for HSW/BDW,
instead of all devices that may be bound with i915.
This patch fixes the condition to check, as well as rephrasing the
message specific to HSW/BDW HDMI/DP.
Fixes: 6603249dcdbb ('ALSA: hda - Enable audio component for old Intel PCH devices')
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Many codecs, typically found on Realtek codecs, have the analog
loopback path merged to the secondary input of the middle of the
output paths. Currently, we don't offer the dynamic switching in such
configuration but let each loopback path mute by itself.
This should work well in theory, but in reality, we often see that
such a dead loopback path causes some background noises even if all
the elements get muted. Such a problem has been fixed by adding the
quirk accordingly to disable aamix, and it's the right fix, per se.
The only problem is that it's not so trivial to achieve it; user needs
to pass a hint string via patch module option or sysfs.
This patch gives a bit improvement on the situation: it adds "Loopback
Mixing" control element for such codecs like other codecs (e.g. IDT or
VIA codecs) with the individual loopback paths. User can turn on/off
the loopback path simply via a mixer app.
For keeping the compatibility, the loopback is still enabled on these
codecs. But user can try to turn it off if experiencing a suspicious
background or click noise on the fly, then build a static fixup later
once after the problem is addressed.
Other than the addition of the loopback enable/disablement control,
there should be no changes.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
An exported function snd_hda_parse_nid_path() is used only inside
hda_generic.c. Let's make it a static local function for a better
code optimization.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
An exported helper function snd_hda_get_nid_path() is nowhere used.
Let's remove it.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Compress offload does not support ioctl calls from a 32bit userspace
in a 64 bit kernel. This patch adds support for ioctls from a 32bit
userspace in a 64bit kernel
Signed-off-by: Ravindra Lokhande <rlokhande@nvidia.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
|
|
The ioctl IOC_LIBCFS_PING_TEST has not been used in ages. The recent
nidstring changes which moved all the nidstring operations from libcfs
to the LNet layer but this ioctl code was still using an nidstring
operation that was causing a circular dependency loop between libcfs and
LNet.
Signed-off-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
we already zero it on outermost set_nameidata(), so initialization in
path_init() is pointless and wrong. The same DoS exists on pre-4.2
kernels, but there a slightly different fix will be needed.
Cc: stable@vger.kernel.org # v4.2
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
[Al Viro] The bug is in being too enthusiastic about optimizing ->setattr()
away - instead of "copy verbatim with metadata" + "chmod/chown/utimes"
(with the former being always safe and the latter failing in case of
insufficient permissions) it tries to combine these two. Note that copyup
itself will have to do ->setattr() anyway; _that_ is where the elevated
capabilities are right. Having these two ->setattr() (one to set verbatim
copy of metadata, another to do what overlayfs ->setattr() had been asked
to do in the first place) combined is where it breaks.
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Cc: <stable@vger.kernel.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
When restarting a syscall with regs->ax == -ERESTART_RESTARTBLOCK,
regs->ax is assigned to a restart_syscall number. For x32 tasks, this
syscall number must have __X32_SYSCALL_BIT set, otherwise it will be
an x86_64 syscall number instead of a valid x32 syscall number. This
issue has been there since the introduction of x32.
Reported-by: strace/tests/restart_syscall.test
Reported-and-tested-by: Elvira Khabirova <lineprinter0@gmail.com>
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Cc: Elvira Khabirova <lineprinter0@gmail.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20151130215436.GA25996@altlinux.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
MPX decodes instructions in order to tell which bounds register
was violated. Part of this decoding involves looking at the "REX
prefix" which is a special instrucion prefix used to retrofit
support for new registers in to old instructions.
The X86_REX_*() macros are defined to return actual bit values:
#define X86_REX_R(rex) ((rex) & 4)
*not* boolean values. However, the MPX code was checking for
them like they were booleans. This might have led to us
mis-decoding the "REX prefix" and giving false information out to
userspace about bounds violations. X86_REX_B() actually is bit 1,
so this is really only broken for the X86_REX_X() case.
Fix the conditionals up to tolerate the non-boolean values.
Fixes: fcc7ffd67991 "x86, mpx: Decode MPX instruction to get bound violation information"
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: x86@kernel.org
Cc: Dave Hansen <dave@sr71.net>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20151201003113.D800C1E0@viggo.jf.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
commit 4dfd6486 "drm: Use vblank timestamps to guesstimate how many
vblanks were missed" introduced in Linux 4.4-rc1 makes the drm core
more fragile to drivers which don't update hw vblank counters and
vblank timestamps in sync with firing of the vblank irq and
essentially at leading edge of vblank.
This exposed a problem with radeon-kms/amdgpu-kms which do not
satisfy above requirements:
The vblank irq fires a few scanlines before start of vblank, but
programmed pageflips complete at start of vblank and
vblank timestamps update at start of vblank, whereas the
hw vblank counter increments only later, at start of vsync.
This leads to problems like off by one errors for vblank counter
updates, vblank counters apparently going backwards or vblank
timestamps apparently having time going backwards. The net result
is stuttering of graphics in games, or little hangs, as well as
total failure of timing sensitive applications.
See bug #93147 for an example of the regression on Linux 4.4-rc:
https://bugs.freedesktop.org/show_bug.cgi?id=93147
This patch tries to align all above events better from the
viewpoint of the drm core / of external callers to fix the problem:
1. The apparent start of vblank is shifted a few scanlines earlier,
so the vblank irq now always happens after start of this extended
vblank interval and thereby drm_update_vblank_count() always samples
the updated vblank count and timestamp of the new vblank interval.
To achieve this, the reporting of scanout positions by
radeon_get_crtc_scanoutpos() now operates as if the vblank starts
radeon_crtc->lb_vblank_lead_lines before the real start of the hw
vblank interval. This means that the vblank timestamps which are based
on these scanout positions will now update at this earlier start of
vblank.
2. The driver->get_vblank_counter() function will bump the returned
vblank count as read from the hw by +1 if the query happens after
the shifted earlier start of the vblank, but before the real hw increment
at start of vsync, so the counter appears to increment at start of vblank
in sync with the timestamp update.
3. Calls from vblank irq-context and regular non-irq calls are now
treated identical, always simulating the shifted vblank start, to
avoid inconsistent results for queries happening from vblank irq vs.
happening from drm_vblank_enable() or vblank_disable_fn().
4. The radeon_flip_work_func will delay mmio programming a pageflip until
the start of the real vblank iff it happens to execute inside the shifted
earlier start of the vblank, so pageflips now also appear to execute at
start of the shifted vblank, in sync with vblank counter and timestamp
updates. This to avoid some races between updates of vblank count and
timestamps that are used for swap scheduling and pageflip execution which
could cause pageflips to execute before the scheduled target vblank.
The lb_vblank_lead_lines "fudge" value is calculated as the size of
the display controllers line buffer in scanlines for the given video
mode: Vblank irq's are triggered by the line buffer logic when the line
buffer refill for a video frame ends, ie. when the line buffer source read
position enters the hw vblank. This means that a vblank irq could fire at
most as many scanlines before the current reported scanout position of the
crtc timing generator as the number of scanlines the line buffer can
maximally hold for a given video mode.
This patch has been successfully tested on a RV730 card with DCE-3 display
engine and on a evergreen card with DCE-4 display engine, in single-display
and dual-display configuration, with different video modes.
A similar patch is needed for amdgpu-kms to fix the same problem.
Limitations:
- Maybe replace the udelay() in the flip_work_func() by a suitable
usleep_range() for a bit better efficiency? Will try that.
- Line buffer sizes in pixels are hard-coded on < DCE-4 to a value
i just guessed to be high enough to work ok, lacking info on the true
sizes atm.
Probably fixes: fdo#93147
Port of Mario's radeon fix to amdgpu.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(v1) Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>
(v2) Refine amdgpu_flip_work_func() for better efficiency.
In amdgpu_flip_work_func, replace the busy waiting udelay(5)
with event lock held by a more performance and energy efficient
usleep_range() until at least predicted true start of hw vblank,
with some slack for scheduler happiness. Release the event lock
during waits to not delay other outputs in doing their stuff, as
the waiting can last up to 200 usecs in some cases.
Also small fix to code comment and formatting in that function.
(v2) Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
(v3) Fix crash in crtc disabled case
|
|
commit 4dfd6486 "drm: Use vblank timestamps to guesstimate how many
vblanks were missed" introduced in Linux 4.4-rc1 makes the drm core
more fragile to drivers which don't update hw vblank counters and
vblank timestamps in sync with firing of the vblank irq and
essentially at leading edge of vblank.
This exposed a problem with radeon-kms/amdgpu-kms which do not
satisfy above requirements:
The vblank irq fires a few scanlines before start of vblank, but
programmed pageflips complete at start of vblank and
vblank timestamps update at start of vblank, whereas the
hw vblank counter increments only later, at start of vsync.
This leads to problems like off by one errors for vblank counter
updates, vblank counters apparently going backwards or vblank
timestamps apparently having time going backwards. The net result
is stuttering of graphics in games, or little hangs, as well as
total failure of timing sensitive applications.
See bug #93147 for an example of the regression on Linux 4.4-rc:
https://bugs.freedesktop.org/show_bug.cgi?id=93147
This patch tries to align all above events better from the
viewpoint of the drm core / of external callers to fix the problem:
1. The apparent start of vblank is shifted a few scanlines earlier,
so the vblank irq now always happens after start of this extended
vblank interval and thereby drm_update_vblank_count() always samples
the updated vblank count and timestamp of the new vblank interval.
To achieve this, the reporting of scanout positions by
radeon_get_crtc_scanoutpos() now operates as if the vblank starts
radeon_crtc->lb_vblank_lead_lines before the real start of the hw
vblank interval. This means that the vblank timestamps which are based
on these scanout positions will now update at this earlier start of
vblank.
2. The driver->get_vblank_counter() function will bump the returned
vblank count as read from the hw by +1 if the query happens after
the shifted earlier start of the vblank, but before the real hw increment
at start of vsync, so the counter appears to increment at start of vblank
in sync with the timestamp update.
3. Calls from vblank irq-context and regular non-irq calls are now
treated identical, always simulating the shifted vblank start, to
avoid inconsistent results for queries happening from vblank irq vs.
happening from drm_vblank_enable() or vblank_disable_fn().
4. The radeon_flip_work_func will delay mmio programming a pageflip until
the start of the real vblank iff it happens to execute inside the shifted
earlier start of the vblank, so pageflips now also appear to execute at
start of the shifted vblank, in sync with vblank counter and timestamp
updates. This to avoid some races between updates of vblank count and
timestamps that are used for swap scheduling and pageflip execution which
could cause pageflips to execute before the scheduled target vblank.
The lb_vblank_lead_lines "fudge" value is calculated as the size of
the display controllers line buffer in scanlines for the given video
mode: Vblank irq's are triggered by the line buffer logic when the line
buffer refill for a video frame ends, ie. when the line buffer source read
position enters the hw vblank. This means that a vblank irq could fire at
most as many scanlines before the current reported scanout position of the
crtc timing generator as the number of scanlines the line buffer can
maximally hold for a given video mode.
This patch has been successfully tested on a RV730 card with DCE-3 display
engine and on a evergreen card with DCE-4 display engine, in single-display
and dual-display configuration, with different video modes.
A similar patch is needed for amdgpu-kms to fix the same problem.
Limitations:
- Line buffer sizes in pixels are hard-coded on < DCE-4 to a value
i just guessed to be high enough to work ok, lacking info on the true
sizes atm.
Fixes: fdo#93147
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Michel Dänzer <michel.daenzer@amd.com>
Cc: Harry Wentland <Harry.Wentland@amd.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
(v1) Tested-by: Dave Witbrodt <dawitbro@sbcglobal.net>
(v2) Refine radeon_flip_work_func() for better efficiency:
In radeon_flip_work_func, replace the busy waiting udelay(5)
with event lock held by a more performance and energy efficient
usleep_range() until at least predicted true start of hw vblank,
with some slack for scheduler happiness. Release the event lock
during waits to not delay other outputs in doing their stuff, as
the waiting can last up to 200 usecs in some cases.
Retested on DCE-3 and DCE-4 to verify it still works nicely.
(v2) Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
HPD signals on DVI ports can be fired off before the pins required for
DDC probing actually make contact, due to the pins for HPD making
contact first. This results in a HPD signal being asserted but DDC
probing failing, resulting in hotplugging occasionally failing.
This is somewhat rare on most cards (depending on what angle you plug
the DVI connector in), but on some cards it happens constantly. The
Radeon R5 on the machine used for testing this patch for instance, runs
into this issue just about every time I try to hotplug a DVI monitor and
as a result hotplugging almost never works.
Rescheduling the hotplug work for a second when we run into an HPD
signal with a failing DDC probe usually gives enough time for the rest
of the connector's pins to make contact, and fixes this issue.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Lyude <cpaul@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
there is a protection fault about freed list when OCL test.
add a spin lock to protect it.
v2: drop changes in vm_fini
Signed-off-by: JimQu <jim.qu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
|
|
The gtt_end is already inclusive, we don't need to subtract one here.
v2 (chk): keep the fix for the VM code, cause here it really applies.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Anatoli Antonovitch <anatoli.antonovitch@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
No need for a GEM reference here.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
No need for the GEM reference here.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Not necessary for VRAM.
v2: no need to check if ttm is NULL.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
Andy Shevchenko
Andy Shevchenko
Nicholas Mc Guire
Takashi Iwai
Takashi Sakamoto
Julia Lawall
Arnd Bergmann
Ravindra Lokhande
Linus Torvalds
James Simmons
Al Viro
Miklos Szeredi
Dmitry V. Levin
Dave Hansen
Alex Deucher
Mario Kleiner
Lyude
jimqu
Christian König