The drbg_state_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>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
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>
Here are the patchset to add get_eld op to audio component for
communicating more directly between i915 and HD-audio.
Currently, the HDMI/DP audio status and ELD are notified and obtained
via the hardware-level communication over HD-audio unsolicited event
and verbs although the graphics driver holds the exactly same
information. As we already have a notification via audio component,
this is another step forward; namely, the audio driver may fetch
directly the audio status and ELD via the new component op.
The commits are based on Dave's latest drm-next branch.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJWaXTVAAoJEGwxgFQ9KSmkdZIQAKg2NQN1CGOIb+ce80UmJ9ap
myZH42aZXytPrMAhHQCw2mvf8aL18EKyQcGv+anLdFM+AqlzZvH/exfOblkr88lg
ZMGr0bXVNa2Lfyrgt9blUwH58uETQZC4P3BrI0cPqIJBdPagDxnxoaV1e/21g/9p
0a2bhiz0gn4OFb83vpi5pL4hGv+BQwwlmkOujcVg7yxR7ylnYI419NM9Z+Lbmfq7
p5jId6Q3EwBw6vpWryOI2TElM3VDThoOGCOtkfmZx6o4fDZ0bdl8CYVCgRFwZZCe
kk01Caa+5+CW88MlJ1VX6gLy0WRlPY0AFreCWKgy5HCUNqew9ruhUeMj4+C1oHpj
ui/79ULLRN2hmu2rvU8lZb0ClihXkDCBN8p89j6o2I+y1aIcUtxvY9Srg5w2tVBe
Ue+OSB3lA4rdnuSjxZiaPf+V4rozIyNJHRjo6xNdY0zuScB4lw9Bh7IYXmj8B8OW
k3LklToj4ZGeyCgfcTQwztAh7fFEXUb1wN+lLqCt3b9688zvMYTQlJ8ZdtK+t188
3DNz9QjjPd4DcxLypl1VpM2Xv3AhuFfugq0oEuQq9bXs7qtj+iLmSWWdmhUNaVWb
Qot21vJEHDii6jtoLdbVMTEZTWyr2nXUfUNFJpUgitif2UhqqgecnR16Fi05pjTv
+Th/GvjddrQ0oe9DwVGY
=NShN
-----END PGP SIGNATURE-----
Merge tag 'drm-i915-get-eld' into topic/hdmi-jack
Merge the latest i915 audio component changes for HDMI/DP get_eld ops.
This is actually used in HD-audio side in this branch.
The recent commit [e90247f9fc: 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: e90247f9fc ('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>
Based on Chris Wilson's patch from 6 months ago, rebased and adapted.
The current implementation of intel_ring_initialized() is too heavyweight;
it's a non-inlined function that chases several levels of pointers. This
wouldn't matter too much if it were rarely called, but it's used inside
the iterator test of for_each_ring() and is therefore called quite
frequently. So let's make it simple and inline ...
The idea here is to use ring->dev as an indicator showing which engines
have been initialised and are therefore to be included in iterations that
use for_each_ring(). This allows us to avoid multiple memory references
and a (non-inlined) function call on each iteration of each such loop.
Fixes regression from
commit 48d823878d
Author: Oscar Mateo <oscar.mateo@intel.com>
Date: Thu Jul 24 17:04:23 2014 +0100
drm/i915/bdw: Generic logical ring init and cleanup
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449586956-32360-2-git-send-email-david.s.gordon@intel.com
Pass the net pointer to the call_batch callback functions so we can skip
recurrent lookups.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Tested-by: Arturo Borrero Gonzalez <arturo.borrero.glez@gmail.com>
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>
On entry from el0, we save all the registers on the kernel stack, and
restore them before returning. x29 remains unchanged when we call out
to C code, which will store x29 as the frame-pointer on the stack.
Instead, write 0 into x29 after entry from el0, to avoid any risk of
tracing into user space.
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
When unwind_frame() reaches the bottom of the irq_stack, the last fp
points to the original task stack. unwind_frame() uses
IRQ_STACK_TO_TASK_STACK() to find the sp value. If either values is
wrong, we may end up walking a corrupt stack.
Check these values are sane by testing if they are both on the stack
pointed to by current->stack.
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
irq_stack is a per_cpu variable, that needs to be access from entry.S.
Use an assembler macro instead of the unreadable details.
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
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>
This patch adds a static inline function ipv6_addr_prefix_copy which
copies a ipv6 address prefix(argument pfx) into the ipv6 address prefix.
The prefix len is given by plen as bits. This function mainly based on
ipv6_addr_prefix which copies one address prefix from address into a new
ipv6 address destination and zero all other address bits.
The difference is that ipv6_addr_prefix_copy don't get a prefix from an
ipv6 address, it sets a prefix to an ipv6 address with keeping other
address bits. The use case is for context based address compression
inside 6LoWPAN IPHC header which keeping ipv6 prefixes inside a context
table to lookup address-bits without sending them.
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: James Morris <jmorris@namei.org>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Patrick McHardy <kaber@trash.net>
Acked-by: Łukasz Duda <lukasz.duda@nordicsemi.no>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Acked-by: David S. Miller <davem@davemloft.net>
Reviewed-by: Stefan Schmidt <stefan@osg.samsung.com>
Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When an inconsistent space cache is detected during loading we log a
warning that users frequently mistake as instruction to invalidate the
cache manually, even though this is not required. Fix the message to
indicate that the cache will be rebuilt automatically.
Signed-off-by: Holger Hoffstätte <holger.hoffstaette@googlemail.com>
Acked-by: Filipe Manana <fdmanana@suse.com>
When disable_noatomic is called plane_mask is not correct yet, and
plane_state->visible = true is left as true after disabling the primary
plane.
Other planes are already disabled as part of crtc sanitization, only the
primary is left active. But the plane_mask is not updated here. It gets
updated during fb takeover in modeset_gem_init, or set to the new value
on resume.
This means that to disable the primary plane 1 << drm_plane_index(primary)
needs to be used.
Afterwards because the crtc is no longer active it's forbidden to keep
plane_state->visible set, or a WARN_ON in
intel_plane_atomic_calc_changes triggers. There are other code points
that rely on accurate plane_state->visible too, so make sure the bool is
cleared.
The other planes are already disabled in intel_sanitize_crtc, so they
don't have to be handled here.
Cc: stable@vger.kernel.org #v4.3, v4.2?
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92655
Tested-by: Tomas Mezzadra <tmezzadra@gmail.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/5652DB88.9070208@linux.intel.com
(cherry picked from commit 54a4196188)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Using `#include "drm.h"` instead of `#include <drm/drm.h>` allow drm
headers to be moved in another directory without changes, like for the
libdrm imports.
Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
CC: Emil Velikov <emil.l.velikov@gmail.com>
CC: Mikko Rapeli <mikko.rapeli@iki.fi>
Using `#include "drm.h"` instead of `#include <drm/drm.h>` allow drm
headers to be moved in another directory without changes, like for the
libdrm imports.
Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
CC: Emil Velikov <emil.l.velikov@gmail.com>
CC: Mikko Rapeli <mikko.rapeli@iki.fi>
Using `#include "drm.h"` instead of `#include <drm/drm.h>` allow drm
headers to be moved in another directory without changes, like for the
libdrm imports.
Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
CC: Emil Velikov <emil.l.velikov@gmail.com>
CC: Mikko Rapeli <mikko.rapeli@iki.fi>
Using `#include "drm.h"` instead of `#include <drm/drm.h>` allow drm
headers to be moved in another directory without changes, like for the
libdrm imports.
Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
CC: Emil Velikov <emil.l.velikov@gmail.com>
CC: Mikko Rapeli <mikko.rapeli@iki.fi>
Using `#include "drm.h"` instead of `#include <drm/drm.h>` allow drm
headers to be moved in another directory without changes, like for the
libdrm imports.
Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
CC: Emil Velikov <emil.l.velikov@gmail.com>
CC: Mikko Rapeli <mikko.rapeli@iki.fi>
Using `#include "drm.h"` instead of `#include <drm/drm.h>` allow drm
headers to be moved in another directory without changes, like for the
libdrm imports.
Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
CC: Emil Velikov <emil.l.velikov@gmail.com>
CC: Mikko Rapeli <mikko.rapeli@iki.fi>
Using `#include "drm.h"` instead of `#include <drm/drm.h>` allow drm
headers to be moved in another directory without changes, like for the
libdrm imports.
Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
CC: Emil Velikov <emil.l.velikov@gmail.com>
CC: Mikko Rapeli <mikko.rapeli@iki.fi>
Using `#include "drm.h"` instead of `#include <drm/drm.h>` allow drm
headers to be moved in another directory without changes, like for the
libdrm imports.
Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
CC: Emil Velikov <emil.l.velikov@gmail.com>
CC: Mikko Rapeli <mikko.rapeli@iki.fi>
Using `#include "drm.h"` instead of `#include <drm/drm.h>` allow drm
headers to be moved in another directory without changes, like for the
libdrm imports.
Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
CC: Emil Velikov <emil.l.velikov@gmail.com>
CC: Mikko Rapeli <mikko.rapeli@iki.fi>
Using `#include "drm.h"` instead of `#include <drm/drm.h>` allow drm
headers to be moved in another directory without changes, like for the
libdrm imports.
Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
CC: Emil Velikov <emil.l.velikov@gmail.com>
CC: Mikko Rapeli <mikko.rapeli@iki.fi>
Using `#include "drm.h"` instead of `#include <drm/drm.h>` allow drm
headers to be moved in another directory without changes, like for the
libdrm imports.
Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
CC: Emil Velikov <emil.l.velikov@gmail.com>
CC: Mikko Rapeli <mikko.rapeli@iki.fi>
Using `#include "drm.h"` instead of `#include <drm/drm.h>` allow drm
headers to be moved in another directory without changes, like for
the libdrm imports.
Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
CC: Emil Velikov <emil.l.velikov@gmail.com>
CC: Mikko Rapeli <mikko.rapeli@iki.fi>
Using `#include "drm.h"` instead of `#include <drm/drm.h>` allow drm
headers to be moved in another directory without changes, like for the
libdrm imports.
Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
CC: Emil Velikov <emil.l.velikov@gmail.com>
CC: Mikko Rapeli <mikko.rapeli@iki.fi>
Using `#include "drm.h"` instead of `#include <drm/drm.h>` allow drm
headers to be moved in another directory without changes, like for the
libdrm imports.
Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
CC: Emil Velikov <emil.l.velikov@gmail.com>
CC: Mikko Rapeli <mikko.rapeli@iki.fi>
Instead of using linux/types.h, drm headers should use drm.h, in order
to handle the portability issues in only one place.
Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
CC: Emil Velikov <emil.l.velikov@gmail.com>
CC: Mikko Rapeli <mikko.rapeli@iki.fi>
Instead of using linux/types.h, drm headers should use drm.h, in order
to handle the portability issues in only one place.
Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
CC: Emil Velikov <emil.l.velikov@gmail.com>
CC: Mikko Rapeli <mikko.rapeli@iki.fi>
Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
CC: Emil Velikov <emil.l.velikov@gmail.com>
CC: Mikko Rapeli <mikko.rapeli@iki.fi>
Kernel headers exported to userspace are supposed to use these.
Fixes compilation errors in userspace:
error: unknown type name ‘uint64_t’
error: unknown type name ‘uint32_t’
Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
CC: Emil Velikov <emil.l.velikov@gmail.com>
CC: Mikko Rapeli <mikko.rapeli@iki.fi>
Signed-off-by: Gabriel Laskar <gabriel@lse.epita.fr>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
CC: Emil Velikov <emil.l.velikov@gmail.com>
CC: Mikko Rapeli <mikko.rapeli@iki.fi>
Kernel headers exported to userspace are should these types.
Fixes userspace compilation error:
error: unknown type name ‘uint8_t’
Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
Fall back to size_t for non Linux platforms.
Fixes userspace compilation error:
drm/drm.h:132:2: error: unknown type name ‘size_t’
Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
If we fail to allocate a new data chunk, we were jumping to the error path
without release the transaction handle we got before. Fix this by always
releasing it before doing the jump.
Fixes: 2c9fe83552 ("btrfs: Fix lost-data-profile caused by balance bg")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
As of my previous change titled "Btrfs: fix scrub preventing unused block
groups from being deleted", the following warning at
extent-tree.c:btrfs_delete_unused_bgs() can be hit when we mount the a
filesysten with "-o discard":
10263 void btrfs_delete_unused_bgs(struct btrfs_fs_info *fs_info)
10264 {
(...)
10405 if (trimming) {
10406 WARN_ON(!list_empty(&block_group->bg_list));
10407 spin_lock(&trans->transaction->deleted_bgs_lock);
10408 list_move(&block_group->bg_list,
10409 &trans->transaction->deleted_bgs);
10410 spin_unlock(&trans->transaction->deleted_bgs_lock);
10411 btrfs_get_block_group(block_group);
10412 }
(...)
This happens because scrub can now add back the block group to the list of
unused block groups (fs_info->unused_bgs). This is dangerous because we
are moving the block group from the unused block groups list to the list
of deleted block groups without holding the lock that protects the source
list (fs_info->unused_bgs_lock).
The following diagram illustrates how this happens:
CPU 1 CPU 2
cleaner_kthread()
btrfs_delete_unused_bgs()
sees bg X in list
fs_info->unused_bgs
deletes bg X from list
fs_info->unused_bgs
scrub_enumerate_chunks()
searches device tree using
its commit root
finds device extent for
block group X
gets block group X from the tree
fs_info->block_group_cache_tree
(via btrfs_lookup_block_group())
sets bg X to RO (again)
scrub_chunk(bg X)
sets bg X back to RW mode
adds bg X to the list
fs_info->unused_bgs again,
since it's still unused and
currently not in that list
sets bg X to RO mode
btrfs_remove_chunk(bg X)
--> discard is enabled and bg X
is in the fs_info->unused_bgs
list again so the warning is
triggered
--> we move it from that list into
the transaction's delete_bgs
list, but we can have another
task currently manipulating
the first list (fs_info->unused_bgs)
Fix this by using the same lock (fs_info->unused_bgs_lock) to protect both
the list of unused block groups and the list of deleted block groups. This
makes it safe and there's not much worry for more lock contention, as this
lock is seldom used and only the cleaner kthread adds elements to the list
of deleted block groups. The warning goes away too, as this was previously
an impossible case (and would have been better a BUG_ON/ASSERT) but it's
not impossible anymore.
Reproduced with fstest btrfs/073 (using MOUNT_OPTIONS="-o discard").
Signed-off-by: Filipe Manana <fdmanana@suse.com>
When disable_noatomic is called plane_mask is not correct yet, and
plane_state->visible = true is left as true after disabling the primary
plane.
Other planes are already disabled as part of crtc sanitization, only the
primary is left active. But the plane_mask is not updated here. It gets
updated during fb takeover in modeset_gem_init, or set to the new value
on resume.
This means that to disable the primary plane 1 << drm_plane_index(primary)
needs to be used.
Afterwards because the crtc is no longer active it's forbidden to keep
plane_state->visible set, or a WARN_ON in
intel_plane_atomic_calc_changes triggers. There are other code points
that rely on accurate plane_state->visible too, so make sure the bool is
cleared.
The other planes are already disabled in intel_sanitize_crtc, so they
don't have to be handled here.
Cc: stable@vger.kernel.org #v4.3, v4.2?
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92655
Tested-by: Tomas Mezzadra <tmezzadra@gmail.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/5652DB88.9070208@linux.intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
