Age | Commit message (Collapse) | Author |
|
After improving setsockopt() coverage in trinity, I started triggering
vmalloc failures pretty reliably from this code path:
warn_alloc_failed+0xe9/0x140
__vmalloc_node_range+0x1be/0x270
vzalloc+0x4b/0x50
__do_replace+0x52/0x260 [ip_tables]
do_ipt_set_ctl+0x15d/0x1d0 [ip_tables]
nf_setsockopt+0x65/0x90
ip_setsockopt+0x61/0xa0
raw_setsockopt+0x16/0x60
sock_common_setsockopt+0x14/0x20
SyS_setsockopt+0x71/0xd0
It turns out we don't validate that the num_counters field in the
struct we pass in from userspace is initialized.
The same problem also exists in ebtables, arptables, ipv6, and the
compat variants.
Signed-off-by: Dave Jones <davej@codemonkey.org.uk>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
nfnetlink_{log,queue}_init() register the netlink callback nf*_rcv_nl_event
before registering the pernet_subsys, but the callback relies on data
structures allocated by pernet init functions.
When nfnetlink_{log,queue} is loaded, if a netlink message is received after
the netlink callback is registered but before the pernet_subsys is registered,
the kernel will panic in the sequence
nfulnl_rcv_nl_event
nfnl_log_pernet
net_generic
BUG_ON(id == 0) where id is nfnl_log_net_id.
The panic can be easily reproduced in 4.0.3 by:
while true ;do modprobe nfnetlink_log ; rmmod nfnetlink_log ; done &
while true ;do ip netns add dummy ; ip netns del dummy ; done &
This patch moves register_pernet_subsys to earlier in nfnetlink_log_init.
Notice that the BUG_ON hit in 4.0.3 was recently removed in 2591ffd308
["netns: remove BUG_ONs from net_generic()"].
Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
The MPX feature requires eager KVM FPU restore support. We have verified
that MPX cannot work correctly with the current lazy KVM FPU restore
mechanism. Eager KVM FPU restore should be enabled if the MPX feature is
exposed to VM.
Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>
Signed-off-by: Liang Li <liang.z.li@intel.com>
[Also activate the FPU on AMD processors. - Paolo]
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This reverts commit 4473b570a7ebb502f63f292ccfba7df622e5fdd3. We'll
use the hook again.
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
memslot->userfault_addr is set by the kernel with a mmap executed
from the kernel but the userland can still munmap it and lead to the
below oops after memslot->userfault_addr points to a host virtual
address that has no vma or mapping.
[ 327.538306] BUG: unable to handle kernel paging request at fffffffffffffffe
[ 327.538407] IP: [<ffffffff811a7b55>] put_page+0x5/0x50
[ 327.538474] PGD 1a01067 PUD 1a03067 PMD 0
[ 327.538529] Oops: 0000 [#1] SMP
[ 327.538574] Modules linked in: macvtap macvlan xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT iptable_filter ip_tables tun bridge stp llc rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache xprtrdma ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp scsi_transport_srp scsi_tgt ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ipmi_devintf iTCO_wdt iTCO_vendor_support intel_powerclamp coretemp dcdbas intel_rapl kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd pcspkr sb_edac edac_core ipmi_si ipmi_msghandler acpi_pad wmi acpi_power_meter lpc_ich mfd_core mei_me
[ 327.539488] mei shpchp nfsd auth_rpcgss nfs_acl lockd grace sunrpc mlx4_ib ib_sa ib_mad ib_core mlx4_en vxlan ib_addr ip_tunnel xfs libcrc32c sd_mod crc_t10dif crct10dif_common crc32c_intel mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit drm_kms_helper ttm drm ahci i2c_core libahci mlx4_core libata tg3 ptp pps_core megaraid_sas ntb dm_mirror dm_region_hash dm_log dm_mod
[ 327.539956] CPU: 3 PID: 3161 Comm: qemu-kvm Not tainted 3.10.0-240.el7.userfault19.4ca4011.x86_64.debug #1
[ 327.540045] Hardware name: Dell Inc. PowerEdge R420/0CN7CM, BIOS 2.1.2 01/20/2014
[ 327.540115] task: ffff8803280ccf00 ti: ffff880317c58000 task.ti: ffff880317c58000
[ 327.540184] RIP: 0010:[<ffffffff811a7b55>] [<ffffffff811a7b55>] put_page+0x5/0x50
[ 327.540261] RSP: 0018:ffff880317c5bcf8 EFLAGS: 00010246
[ 327.540313] RAX: 00057ffffffff000 RBX: ffff880616a20000 RCX: 0000000000000000
[ 327.540379] RDX: 0000000000002014 RSI: 00057ffffffff000 RDI: fffffffffffffffe
[ 327.540445] RBP: ffff880317c5bd10 R08: 0000000000000103 R09: 0000000000000000
[ 327.540511] R10: 0000000000000000 R11: 0000000000000000 R12: fffffffffffffffe
[ 327.540576] R13: 0000000000000000 R14: ffff880317c5bd70 R15: ffff880317c5bd50
[ 327.540643] FS: 00007fd230b7f700(0000) GS:ffff880630800000(0000) knlGS:0000000000000000
[ 327.540717] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 327.540771] CR2: fffffffffffffffe CR3: 000000062a2c3000 CR4: 00000000000427e0
[ 327.540837] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 327.540904] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 327.540974] Stack:
[ 327.541008] ffffffffa05d6d0c ffff880616a20000 0000000000000000 ffff880317c5bdc0
[ 327.541093] ffffffffa05ddaa2 0000000000000000 00000000002191bf 00000042f3feab2d
[ 327.541177] 00000042f3feab2d 0000000000000002 0000000000000001 0321000000000000
[ 327.541261] Call Trace:
[ 327.541321] [<ffffffffa05d6d0c>] ? kvm_vcpu_reload_apic_access_page+0x6c/0x80 [kvm]
[ 327.543615] [<ffffffffa05ddaa2>] vcpu_enter_guest+0x3f2/0x10f0 [kvm]
[ 327.545918] [<ffffffffa05e2f10>] kvm_arch_vcpu_ioctl_run+0x2b0/0x5a0 [kvm]
[ 327.548211] [<ffffffffa05e2d02>] ? kvm_arch_vcpu_ioctl_run+0xa2/0x5a0 [kvm]
[ 327.550500] [<ffffffffa05ca845>] kvm_vcpu_ioctl+0x2b5/0x680 [kvm]
[ 327.552768] [<ffffffff810b8d12>] ? creds_are_invalid.part.1+0x12/0x50
[ 327.555069] [<ffffffff810b8d71>] ? creds_are_invalid+0x21/0x30
[ 327.557373] [<ffffffff812d6066>] ? inode_has_perm.isra.49.constprop.65+0x26/0x80
[ 327.559663] [<ffffffff8122d985>] do_vfs_ioctl+0x305/0x530
[ 327.561917] [<ffffffff8122dc51>] SyS_ioctl+0xa1/0xc0
[ 327.564185] [<ffffffff816de829>] system_call_fastpath+0x16/0x1b
[ 327.566480] Code: 0b 31 f6 4c 89 e7 e8 4b 7f ff ff 0f 0b e8 24 fd ff ff e9 a9 fd ff ff 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 <48> f7 07 00 c0 00 00 55 48 89 e5 75 2a 8b 47 1c 85 c0 74 1e f0
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
We assumed all touch interfaces report touch data. But, Bamboo
and Intuos non-touch devices report express keys on touch
interface. We need to check touch_max before counting touches.
Reported-by: Tasos Sahanidis <tasos@tasossah.com>
Signed-off-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
We've got reports that ALC3226 (a Dell variant of ALC292) gives click
noises at transition from D3 to D0 when the widget power-saving is
enabled. Further debugging session showed that avoiding it isn't
trivial, unfortunately, since paths are basically activated
dynamically while the pins have been already enabled.
This patch disables the widget power-saving for such codecs.
Reported-by: Jonathan McDowell <noodles@earth.li>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The widget (node) power-saves restore the widget states at each
transition from D3 to D0 on each node. This was added in the commit
[d545a57c5f84:ALSA: hda - Sync node attributes at resume from widget
power saving]. However, the test was rater false-positive; this
wasn't needed for any codecs.
Since the resync may take significant number of additional verbs to be
executed, it's better to reduce it. Let's disable it for now again.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The recently added DT support for the ac97 driver is causing
a gcc warning:
sound/atmel/ac97c.c: In function 'atmel_ac97c_probe_dt':
sound/atmel/ac97c.c:919:29: warning: unused variable 'match' [-Wunused-variable]
const struct of_device_id *match;
The variable is clearly unused, so we can remove it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Alexander Stein <alexanders83@web.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
If while setting a block group read-only we end up allocating a system
chunk, through check_system_chunk(), we were not doing it while holding
the chunk mutex which is a problem if a concurrent chunk allocation is
happening, through do_chunk_alloc(), as it means both block groups can
end up using the same logical addresses and physical regions in the
device(s). So make sure we hold the chunk mutex.
Cc: stable@vger.kernel.org # 4.0+
Fixes: 2f0810880f08 ("btrfs: delete chunk allocation attemp when
setting block group ro")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
|
|
btrfs_check_shared() is leaking a return value of '1' from
find_parent_nodes(). As a result, callers (in this case, extent_fiemap())
are told extents are shared when they are not. This in turn broke fiemap on
btrfs for kernels v3.18 and up.
The fix is simple - we just have to clear 'ret' after we are done processing
the results of find_parent_nodes().
It wasn't clear to me at first what was happening with return values in
btrfs_check_shared() and find_parent_nodes() - thanks to Josef for the help
on irc. I added documentation to both functions to make things more clear
for the next hacker who might come across them.
If we could queue this up for -stable too that would be great.
Signed-off-by: Mark Fasheh <mfasheh@suse.de>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes
Summary:
- Use generic function to get buffer count instead of specific one.
In case of Exynos DRM, There was a special case which decides pixel
format of a given buffer according to planer types, which is NV12M and NV12.
However, NV12M doesn't exist in drm fourcc so it removes
exynos_drm_format_num_buffers() specific to Exynos DRM and use a generic function,
drm_format_num_planes() instead.
- Allow mixer driver to support NV21 format for Video processor.
This format was already supported but we just missed DRM_FORMAT_NV21 case
so this patch considers the case so that Mixer driver can handle it correctly.
- Add regression fix and some code cleanups.
* 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
drm/exynos: dp: Lower level of EDID read success message
drm/exynos: cleanup exynos_drm_plane
drm/exynos: 'win' is always unsigned
drm/exynos: mixer: don't dump registers under spinlock
drm/exynos: Consolidate return statements in fimd_bind()
drm/exynos: Constify exynos_drm_crtc_ops
drm/exynos: Fix build breakage on !DRM_EXYNOS_FIMD
drm/exynos: mixer: Constify platform_device_id
drm/exynos: mixer: cleanup pixelformat handling
drm/exynos: mixer: also allow NV21 for the video processor
drm/exynos: mixer: remove buffer count handling in vp_video_buffer()
drm/exynos: plane: honor buffer offset for dma_addr
drm/exynos: fb: use drm_format_num_planes to get buffer count
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
Johannes Berg says:
====================
This has just a single fix, for a WEP tailroom check
problem that leads to dropped frames.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
After sending the new data packets to probe (step 2), F-RTO may
incorrectly send more probes if the next ACK advances SND_UNA and
does not sack new packet. However F-RTO RFC 5682 probes at most
once. This bug may cause sender to always send new data instead of
repairing holes, inducing longer HoL blocking on the receiver for
the application.
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Undo based on TCP timestamps should only happen on ACKs that advance
SND_UNA, according to the Eifel algorithm in RFC 3522:
Section 3.2:
(4) If the value of the Timestamp Echo Reply field of the
acceptable ACK's Timestamps option is smaller than the
value of RetransmitTS, then proceed to step (5),
Section Terminology:
We use the term 'acceptable ACK' as defined in [RFC793]. That is an
ACK that acknowledges previously unacknowledged data.
This is because upon receiving an out-of-order packet, the receiver
returns the last timestamp that advances RCV_NXT, not the current
timestamp of the packet in the DUPACK. Without checking the flag,
the DUPACK will cause tcp_packet_delayed() to return true and
tcp_try_undo_loss() will revert cwnd reduction.
Note that we check the condition in CA_Recovery already by only
calling tcp_try_undo_partial() if FLAG_SND_UNA_ADVANCED is set or
tcp_try_undo_recovery() if snd_una crosses high_seq.
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Commit <5cf3d46192fc> ("udp: Simplify__udp*_lib_mcast_deliver")
simplified the filter for incoming IPv6 multicast but removed
the check of the local socket address and the UDP destination
address.
This patch restores the filter to prevent sockets bound to a IPv6
multicast IP to receive other UDP traffic link unicast.
Signed-off-by: Henning Rogge <hrogge@gmail.com>
Fixes: 5cf3d46192fc ("udp: Simplify__udp*_lib_mcast_deliver")
Cc: "David S. Miller" <davem@davemloft.net>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
A non-percpu VIRQ (e.g., VIRQ_CONSOLE) may be freed on a different
VCPU than it is bound to. This can result in a race between
handle_percpu_irq() and removing the action in __free_irq() because
handle_percpu_irq() does not take desc->lock. The interrupt handler
sees a NULL action and oopses.
Only use the percpu chip/handler for per-CPU VIRQs (like VIRQ_TIMER).
# cat /proc/interrupts | grep virq
40: 87246 0 xen-percpu-virq timer0
44: 0 0 xen-percpu-virq debug0
47: 0 20995 xen-percpu-virq timer1
51: 0 0 xen-percpu-virq debug1
69: 0 0 xen-dyn-virq xen-pcpu
74: 0 0 xen-dyn-virq mce
75: 29 0 xen-dyn-virq hvc_console
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Cc: <stable@vger.kernel.org>
|
|
Pull two NFS client bugfixes from Trond Myklebust:
"Highlights include:
- fix a Linux-4.1 regression affecting stat()
- take an extra reference to fl->fl_file when running a setlk"
* tag 'nfs-for-4.1-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
nfs: take extra reference to fl->fl_file when running a setlk
nfs: stat(2) fails during cthon04 basic test5 on NFSv4.0
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux
Pull powerpc fixes from Michael Ellerman:
- THP/hugetlb fixes from Aneesh.
- MCE fix from Daniel.
- TOC fix from Anton.
* tag 'powerpc-4.1-4' of git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux:
powerpc: Align TOC to 256 bytes
powerpc/mce: fix off by one errors in mce event handling
powerpc/mm: Return NULL for not present hugetlb page
powerpc/thp: Serialize pmd clear against a linux page table walk.
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
Pull pwm fix from Thierry Reding:
"A single fix to make the Pistachio driver respect the limits imposed
by hardware"
* tag 'pwm/for-4.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm:
pwm: img: Impose upper and lower timebase steps value
|
|
Commit ab992dc38f9a ("watchdog: Fix merge 'conflict'") has introduced an
obvious deadlock because of a typo. watchdog_proc_mutex should be
unlocked on exit.
Thanks to Miroslav Benes who was staring at the code with me and noticed
this.
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Duh-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
tcp_illinois and upcoming tcp_cdg require 64bit alignment of
icsk_ca_priv
x86 does not care, but other architectures might.
Fixes: 05cbc0db03e82 ("ipv4: Create probe timer for tcp PMTU as per RFC4821")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Fan Du <fan.du@intel.com>
Acked-by: Fan Du <fan.du@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The PWM hardware on Pistachio platform has a maximum timebase steps
value to 255. To fix it, let's introduce a compatible-specific
data structure to contain the SoC-specific details and use it to
specify a maximum timebase.
Also, let's limit the minimum timebase to 16 steps, to allow a sane
range of duty cycle steps.
Fixes: 277bb6a29e00 ("pwm: Imagination Technologies PWM DAC driver")
Signed-off-by: Naidu Tellapati <naidu.tellapati@imgtec.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@imgtec.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
|
|
Don't pollute the dmesg with EDID read success message as an error.
Printing as debug should be fine.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
Remove the unused fields of struct exynos_drm_plane.
v2: Remove index_color as well, also unused (thanks Joonyoung).
Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
The index for the hardware layer is always >=0. Previous
code that also used -1 as special index is now gone.
Also apply this to 'ch_enabled' (decon/fimd), since the
variable is on the same line (and is again always unsigned).
Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
mixer_regs_dump() was called in mixer_run(), which was called
under the register spinlock in mixer_graph_buffer() and
vp_video_buffer().
This would trigger a sysmmu pagefault with drm.debug=0xff because
of the large delay caused by the register dumping.
To keep consistency also move register dumping out of mixer_stop(),
which is the counterpart to mixer_run().
Kernel dump:
[ 131.296529] [drm:mixer_win_commit] win: 2
[ 131.300693] [drm:mixer_regs_dump] MXR_STATUS = 00000081
[ 131.305888] [drm:mixer_regs_dump] MXR_CFG = 000007d5
[ 131.310835] [drm:mixer_regs_dump] MXR_INT_EN = 00000000
[ 131.316043] [drm:mixer_regs_dump] MXR_INT_STATUS = 00000900
[ 131.321598] [drm:mixer_regs_dump] MXR_LAYER_CFG = 00000321
[ 131.327066] [drm:mixer_regs_dump] MXR_VIDEO_CFG = 00000000
[ 131.332535] [drm:mixer_regs_dump] MXR_GRAPHIC0_CFG = 00310700
[ 131.338263] [drm:mixer_regs_dump] MXR_GRAPHIC0_BASE = 20c00000
[ 131.344079] [drm:mixer_regs_dump] MXR_GRAPHIC0_SPAN = 00000780
[ 131.349895] [drm:mixer_regs_dump] MXR_GRAPHIC0_WH = 07800438
[ 131.355537] [drm:mixer_regs_dump] MXR_GRAPHIC0_SXY = 00000000
[ 131.361265] [drm:mixer_regs_dump] MXR_GRAPHIC0_DXY = 00000000
[ 131.366994] [drm:mixer_regs_dump] MXR_GRAPHIC1_CFG = 00000000
[ 131.372723] [drm:mixer_regs_dump] MXR_GRAPHIC1_BASE = 00000000
[ 131.378539] [drm:mixer_regs_dump] MXR_GRAPHIC1_SPAN = 00000000
[ 131.384354] [drm:mixer_regs_dump] MXR_GRAPHIC1_WH = 00000000
[ 131.389996] [drm:mixer_regs_dump] MXR_GRAPHIC1_SXY = 00000000
[ 131.395725] [drm:mixer_regs_dump] MXR_GRAPHIC1_DXY = 00000000
[ 131.401486] PAGE FAULT occurred at 0x0 by 12e20000.sysmmu(Page table base: 0x6d990000)
[ 131.409353] Lv1 entry: 0x6e0f2401
[ 131.412753] ------------[ cut here ]------------
[ 131.417339] kernel BUG at drivers/iommu/exynos-iommu.c:358!
[ 131.422894] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[ 131.428709] Modules linked in: ecb bridge stp llc bnep btrfs xor xor_neon zlib_inflate zlib_deflate raid6_pq btusb bluetooth usb_storage s5p_jpeg
videobuf2_dma_contig videobuf2_memops v4l2_mem2mem videobuf2_core
[ 131.447461] CPU: 0 PID: 2418 Comm: lt-modetest Tainted: G W 4.0.1-debug+ #3
[ 131.455530] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 131.461607] task: ee194100 ti: ec4fe000 task.ti: ec4fe000
[ 131.466995] PC is at exynos_sysmmu_irq+0x2a0/0x2a8
[ 131.471766] LR is at vprintk_emit+0x268/0x594
[ 131.476103] pc : [<c02781a4>] lr : [<c00650d0>] psr: a00001d3
[ 131.476103] sp : ec4ff9d8 ip : 00000000 fp : ec4ffa14
[ 131.487559] r10: ffffffda r9 : ee206e28 r8 : ee2d1a10
[ 131.492767] r7 : 00000000 r6 : 00000000 r5 : 00000000 r4 : ee206e10
[ 131.499277] r3 : c06fca20 r2 : 00000000 r1 : 00000000 r0 : ee28be00
[ 131.505788] Flags: NzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment user
[ 131.513079] Control: 10c5387d Table: 6c72404a DAC: 00000015
[ 131.518808] Process lt-modetest (pid: 2418, stack limit = 0xec4fe218)
[ 131.525231] Stack: (0xec4ff9d8 to 0xec500000)
[ 131.529571] f9c0: ec4ff9e4 c03a0c40
[ 131.537732] f9e0: bbfa6e35 6d990000 6d161c3d ee20a900 ee04a7e0 00000028 ee007000 00000000
[ 131.545891] fa00: 00000000 c06fb1fc ec4ffa5c ec4ffa18 c0066a34 c0277f10 ee257664 0000000b
[ 131.554050] fa20: ec4ffa5c c06fafbb ee04a780 c06fb1e8 00000000 ee04a780 ee04a7e0 ee20a900
[ 131.562209] fa40: ee007000 00000015 ec4ffb48 ee008000 ec4ffa7c ec4ffa60 c0066c90 c00669e0
[ 131.570369] fa60: 00020000 ee04a780 ee04a7e0 00001000 ec4ffa94 ec4ffa80 c0069c6c c0066c58
[ 131.578528] fa80: 00000028 ee004450 ec4ffaac ec4ffa98 c0066028 c0069bac 000000a0 c06e19b4
[ 131.586687] faa0: ec4ffad4 ec4ffab0 c0223678 c0066000 c02235dc 00000015 00000000 00000015
[ 131.594846] fac0: ec4ffc80 00000001 ec4ffaec ec4ffad8 c0066028 c02235e8 00000089 c06bfc54
[ 131.603005] fae0: ec4ffb1c ec4ffaf0 c006633c c0066000 ec4ffb48 f002000c 00000025 00000015
[ 131.611165] fb00: c06c680c ec4ffb48 f0020000 ee008000 ec4ffb44 ec4ffb20 c000867c c00662c4
[ 131.619324] fb20: c02046ac 60000153 ffffffff ec4ffb7c 00000000 00000101 ec4ffbb4 ec4ffb48
[ 131.627483] fb40: c0013240 c0008650 00000001 ee257508 00000002 00000001 ee257504 ee257508
[ 131.635642] fb60: 00000000 c06bf27c 00000000 00000101 ee008000 ec4ffbb4 00000000 ec4ffb90
[ 131.643802] fb80: c002e124 c02046ac 60000153 ffffffff c002e09c 00000000 c06c6080 00000283
[ 131.651960] fba0: 00000001 c06fb1ac ec4ffc0c ec4ffbb8 c002d690 c002e0a8 ee78d080 ee008000
[ 131.660120] fbc0: 00400000 c04eb3b0 ffff7c44 c06c6100 c06fdac0 0000000a c06bf2f0 c06c6080
[ 131.668279] fbe0: c06bfc54 c06bfc54 00000000 00000025 00000000 00000001 ec4ffc80 ee008000
[ 131.676438] fc00: ec4ffc24 ec4ffc10 c002dbb8 c002d564 00000089 c06bfc54 ec4ffc54 ec4ffc28
[ 131.684597] fc20: c0066340 c002dafc ec4ffc80 f002000c 0000001c 0000000c c06c680c ec4ffc80
[ 131.692757] fc40: f0020000 00000080 ec4ffc7c ec4ffc58 c000867c c00662c4 c04e6624 60000053
[ 131.700916] fc60: ffffffff ec4ffcb4 c072df54 ee22d010 ec4ffcdc ec4ffc80 c0013240 c0008650
[ 131.709075] fc80: ee22d664 ee194100 00000000 ec4fe000 60000053 00000400 00000002 ee22d420
[ 131.717234] fca0: c072df54 ee22d010 00000080 ec4ffcdc ec4ffcc8 ec4ffcc8 c04e6620 c04e6624
[ 131.725393] fcc0: 60000053 ffffffff ec4fe000 c072df54 ec4ffd34 ec4ffce0 c02b64d0 c04e6618
[ 131.733552] fce0: ec4ffcf8 00000000 00000000 60000053 00010000 00010000 00000000 200cb000
[ 131.741712] fd00: 20080000 ee22d664 00000001 ee256000 ee261400 ee22d420 00000080 00000080
[ 131.749871] fd20: ee256000 00000280 ec4ffd74 ec4ffd38 c02a8844 c02b5fec 00000080 00000280
[ 131.758030] fd40: 000001e0 00000000 00000000 00000280 000001e0 ee22d220 01e00000 00000002
[ 131.766189] fd60: ee22d420 ee261400 ec4ffdbc ec4ffd78 c0293cbc c02a87a4 00000080 00000280
[ 131.774348] fd80: 000001e0 00000000 00000000 02800000 01e00000 ee261400 ee22d460 ee261400
[ 131.782508] fda0: ee22d420 00000000 01e00000 000001e0 ec4ffe24 ec4ffdc0 c0297800 c0293b24
[ 131.790667] fdc0: 00000080 00000280 000001e0 00000000 00000000 02800000 01e00000 ec4ffdf8
[ 131.798826] fde0: c028db00 00000080 00000080 ee256000 02800000 00000000 ec4ffe24 c06c6448
[ 131.806985] fe00: c072df54 000000b7 ee013800 ec4ffe54 edbf7300 ec4ffe54 ec4fff04 ec4ffe28
[ 131.815145] fe20: c028a848 c029768c 00000001 c06195d8 ec4ffe5c ec4ffe40 c0297680 c0521f6c
[ 131.823304] fe40: 00000030 bed45d38 00000030 c03064b7 ec4ffe8c 00000011 00000015 00000022
[ 131.831463] fe60: 00000000 00000080 00000080 00000280 000001e0 00000000 00000000 01e00000
[ 131.839622] fe80: 02800000 00000000 00000000 0004b000 00000000 00000000 c00121e4 c0011080
[ 131.847781] fea0: c00110a4 00000000 00000000 00000000 ec4ffeec ec4ffec0 c00110f0 c00121cc
[ 131.855940] fec0: 00000000 c00e7fec ec4ffeec ec4ffed8 c004af2c dc8ba201 edae4fc0 edbf7000
[ 131.864100] fee0: edbf7000 00000003 bed45d38 00000003 bed45d38 ee3f2040 ec4fff7c ec4fff08
[ 131.872259] ff00: c010b62c c028a684 edae4fc0 00000000 00000000 b6666000 ec40d108 edae4fc4
[ 131.880418] ff20: ec4fff6c ec4fff30 c00e7fec c02207b0 000001f9 00000000 edae5008 ec40d110
[ 131.888577] ff40: 00070800 edae5008 edae4fc0 00070800 b6666000 edbf7000 edbf7000 c03064b7
[ 131.896736] ff60: bed45d38 00000003 ec4fe000 00000000 ec4fffa4 ec4fff80 c010b84c c010b208
[ 131.904896] ff80: 00000022 00000000 bed45d38 c03064b7 00000036 c000ede4 00000000 ec4fffa8
[ 131.913055] ffa0: c000ec40 c010b81c 00000000 bed45d38 00000003 c03064b7 bed45d38 00000022
[ 131.921214] ffc0: 00000000 bed45d38 c03064b7 00000036 00000080 00000080 00000000 000001e0
[ 131.929373] ffe0: b6da4064 bed45d1c b6d98968 b6e8082c 60000050 00000003 00000000 00000000
[ 131.937529] Backtrace:
[ 131.939967] [<c0277f04>] (exynos_sysmmu_irq) from [<c0066a34>] (handle_irq_event_percpu+0x60/0x278)
[ 131.948988] r10:c06fb1fc r9:00000000 r8:00000000 r7:ee007000 r6:00000028 r5:ee04a7e0
[ 131.956799] r4:ee20a900
[ 131.959320] [<c00669d4>] (handle_irq_event_percpu) from [<c0066c90>] (handle_irq_event+0x44/0x64)
[ 131.968170] r10:ee008000 r9:ec4ffb48 r8:00000015 r7:ee007000 r6:ee20a900 r5:ee04a7e0
[ 131.975982] r4:ee04a780
[ 131.978504] [<c0066c4c>] (handle_irq_event) from [<c0069c6c>] (handle_level_irq+0xcc/0x144)
[ 131.986832] r6:00001000 r5:ee04a7e0 r4:ee04a780 r3:00020000
[ 131.992478] [<c0069ba0>] (handle_level_irq) from [<c0066028>] (generic_handle_irq+0x34/0x44)
[ 132.000894] r5:ee004450 r4:00000028
[ 132.004459] [<c0065ff4>] (generic_handle_irq) from [<c0223678>] (combiner_handle_cascade_irq+0x9c/0x108)
[ 132.013914] r4:c06e19b4 r3:000000a0
[ 132.017476] [<c02235dc>] (combiner_handle_cascade_irq) from [<c0066028>] (generic_handle_irq+0x34/0x44)
[ 132.026847] r8:00000001 r7:ec4ffc80 r6:00000015 r5:00000000 r4:00000015 r3:c02235dc
[ 132.034576] [<c0065ff4>] (generic_handle_irq) from [<c006633c>] (__handle_domain_irq+0x84/0xf0)
[ 132.043252] r4:c06bfc54 r3:00000089
[ 132.046815] [<c00662b8>] (__handle_domain_irq) from [<c000867c>] (gic_handle_irq+0x38/0x70)
[ 132.055144] r10:ee008000 r9:f0020000 r8:ec4ffb48 r7:c06c680c r6:00000015 r5:00000025
[ 132.062956] r4:f002000c r3:ec4ffb48
[ 132.066520] [<c0008644>] (gic_handle_irq) from [<c0013240>] (__irq_svc+0x40/0x74)
[ 132.073980] Exception stack(0xec4ffb48 to 0xec4ffb90)
[ 132.079016] fb40: 00000001 ee257508 00000002 00000001 ee257504 ee257508
[ 132.087176] fb60: 00000000 c06bf27c 00000000 00000101 ee008000 ec4ffbb4 00000000 ec4ffb90
[ 132.095333] fb80: c002e124 c02046ac 60000153 ffffffff
[ 132.100367] r9:00000101 r8:00000000 r7:ec4ffb7c r6:ffffffff r5:60000153 r4:c02046ac
[ 132.108098] [<c002e09c>] (tasklet_hi_action) from [<c002d690>] (__do_softirq+0x138/0x38c)
[ 132.116251] r8:c06fb1ac r7:00000001 r6:00000283 r5:c06c6080 r4:00000000 r3:c002e09c
[ 132.123980] [<c002d558>] (__do_softirq) from [<c002dbb8>] (irq_exit+0xc8/0x104)
[ 132.131268] r10:ee008000 r9:ec4ffc80 r8:00000001 r7:00000000 r6:00000025 r5:00000000
[ 132.139080] r4:c06bfc54
[ 132.141600] [<c002daf0>] (irq_exit) from [<c0066340>] (__handle_domain_irq+0x88/0xf0)
[ 132.149409] r4:c06bfc54 r3:00000089
[ 132.152971] [<c00662b8>] (__handle_domain_irq) from [<c000867c>] (gic_handle_irq+0x38/0x70)
[ 132.161300] r10:00000080 r9:f0020000 r8:ec4ffc80 r7:c06c680c r6:0000000c r5:0000001c
[ 132.169112] r4:f002000c r3:ec4ffc80
[ 132.172675] [<c0008644>] (gic_handle_irq) from [<c0013240>] (__irq_svc+0x40/0x74)
[ 132.180137] Exception stack(0xec4ffc80 to 0xec4ffcc8)
[ 132.185173] fc80: ee22d664 ee194100 00000000 ec4fe000 60000053 00000400 00000002 ee22d420
[ 132.193332] fca0: c072df54 ee22d010 00000080 ec4ffcdc ec4ffcc8 ec4ffcc8 c04e6620 c04e6624
[ 132.201489] fcc0: 60000053 ffffffff
[ 132.204961] r9:ee22d010 r8:c072df54 r7:ec4ffcb4 r6:ffffffff r5:60000053 r4:c04e6624
[ 132.212694] [<c04e660c>] (_raw_spin_unlock_irqrestore) from [<c02b64d0>] (mixer_win_commit+0x4f0/0xcc8)
[ 132.222060] r4:c072df54 r3:ec4fe000
[ 132.225625] [<c02b5fe0>] (mixer_win_commit) from [<c02a8844>] (exynos_update_plane+0xac/0xb8)
[ 132.234126] r10:00000280 r9:ee256000 r8:00000080 r7:00000080 r6:ee22d420 r5:ee261400
[ 132.241937] r4:ee256000
[ 132.244461] [<c02a8798>] (exynos_update_plane) from [<c0293cbc>] (__setplane_internal+0x1a4/0x2c0)
[ 132.253395] r7:ee261400 r6:ee22d420 r5:00000002 r4:01e00000
[ 132.259041] [<c0293b18>] (__setplane_internal) from [<c0297800>] (drm_mode_setplane+0x180/0x244)
[ 132.267804] r9:000001e0 r8:01e00000 r7:00000000 r6:ee22d420 r5:ee261400 r4:ee22d460
[ 132.275535] [<c0297680>] (drm_mode_setplane) from [<c028a848>] (drm_ioctl+0x1d0/0x58c)
[ 132.283428] r10:ec4ffe54 r9:edbf7300 r8:ec4ffe54 r7:ee013800 r6:000000b7 r5:c072df54
[ 132.291240] r4:c06c6448
[ 132.293763] [<c028a678>] (drm_ioctl) from [<c010b62c>] (do_vfs_ioctl+0x430/0x614)
[ 132.301222] r10:ee3f2040 r9:bed45d38 r8:00000003 r7:bed45d38 r6:00000003 r5:edbf7000
[ 132.309034] r4:edbf7000
[ 132.311555] [<c010b1fc>] (do_vfs_ioctl) from [<c010b84c>] (SyS_ioctl+0x3c/0x64)
[ 132.318842] r10:00000000 r9:ec4fe000 r8:00000003 r7:bed45d38 r6:c03064b7 r5:edbf7000
[ 132.326654] r4:edbf7000
[ 132.329176] [<c010b810>] (SyS_ioctl) from [<c000ec40>] (ret_fast_syscall+0x0/0x34)
[ 132.336723] r8:c000ede4 r7:00000036 r6:c03064b7 r5:bed45d38 r4:00000000 r3:00000022
[ 132.344451] Code: e3130002 0affffaf eb09a67d eaffffad (e7f001f2)
[ 132.350528] ---[ end trace d428689b94df895c ]---
[ 132.355126] Kernel panic - not syncing: Fatal exception in interrupt
[ 132.361465] CPU2: stopping
[ 132.364155] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G D W 4.0.1-debug+ #3
[ 132.371791] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 132.377866] Backtrace:
[ 132.380304] [<c0012484>] (dump_backtrace) from [<c001269c>] (show_stack+0x18/0x1c)
[ 132.387849] r6:c06e158c r5:ffffffff r4:00000000 r3:dc8ba201
[ 132.393497] [<c0012684>] (show_stack) from [<c04dfb94>] (dump_stack+0x88/0xc8)
[ 132.400698] [<c04dfb0c>] (dump_stack) from [<c0014894>] (handle_IPI+0x1c8/0x2c4)
[ 132.408073] r6:c06bfc54 r5:c06bfc54 r4:00000005 r3:ee0b0000
[ 132.413718] [<c00146cc>] (handle_IPI) from [<c00086b0>] (gic_handle_irq+0x6c/0x70)
[ 132.421267] r9:f0028000 r8:ee0b1f48 r7:c06c680c r6:fffffff5 r5:00000005 r4:f002800c
[ 132.428995] [<c0008644>] (gic_handle_irq) from [<c0013240>] (__irq_svc+0x40/0x74)
[ 132.436457] Exception stack(0xee0b1f48 to 0xee0b1f90)
[ 132.441493] 1f40: 00000001 00000000 00000000 c00206c0 c06c6518 c04eb3a4
[ 132.449653] 1f60: 00000000 00000000 c06c0dc0 00000001 c06fb774 ee0b1f9c ee0b1fa0 ee0b1f90
[ 132.457811] 1f80: c000f82c c000f830 600f0053 ffffffff
[ 132.462844] r9:00000001 r8:c06c0dc0 r7:ee0b1f7c r6:ffffffff r5:600f0053 r4:c000f830
[ 132.470575] [<c000f7f0>] (arch_cpu_idle) from [<c005b6e8>] (cpu_startup_entry+0x318/0x4ec)
[ 132.478818] [<c005b3d0>] (cpu_startup_entry) from [<c00144d0>] (secondary_start_kernel+0xf4/0x100)
[ 132.487755] r7:c06fd440
[ 132.490279] [<c00143dc>] (secondary_start_kernel) from [<40008744>] (0x40008744)
[ 132.497651] r4:6e09006a r3:c000872c
[ 132.501210] CPU3: stopping
[ 132.503904] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G D W 4.0.1-debug+ #3
[ 132.511539] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 132.517614] Backtrace:
[ 132.520051] [<c0012484>] (dump_backtrace) from [<c001269c>] (show_stack+0x18/0x1c)
[ 132.527597] r6:c06e158c r5:ffffffff r4:00000000 r3:dc8ba201
[ 132.533243] [<c0012684>] (show_stack) from [<c04dfb94>] (dump_stack+0x88/0xc8)
[ 132.540446] [<c04dfb0c>] (dump_stack) from [<c0014894>] (handle_IPI+0x1c8/0x2c4)
[ 132.547820] r6:c06bfc54 r5:c06bfc54 r4:00000005 r3:ee0b2000
[ 132.553466] [<c00146cc>] (handle_IPI) from [<c00086b0>] (gic_handle_irq+0x6c/0x70)
[ 132.561014] r9:f002c000 r8:ee0b3f48 r7:c06c680c r6:fffffff5 r5:00000005 r4:f002c00c
[ 132.568743] [<c0008644>] (gic_handle_irq) from [<c0013240>] (__irq_svc+0x40/0x74)
[ 132.576205] Exception stack(0xee0b3f48 to 0xee0b3f90)
[ 132.581241] 3f40: 00000001 00000000 00000000 c00206c0 c06c6518 c04eb3a4
[ 132.589401] 3f60: 00000000 00000000 c06c0dc0 00000001 c06fb774 ee0b3f9c ee0b3fa0 ee0b3f90
[ 132.597558] 3f80: c000f82c c000f830 600f0053 ffffffff
[ 132.602591] r9:00000001 r8:c06c0dc0 r7:ee0b3f7c r6:ffffffff r5:600f0053 r4:c000f830
[ 132.610321] [<c000f7f0>] (arch_cpu_idle) from [<c005b6e8>] (cpu_startup_entry+0x318/0x4ec)
[ 132.618566] [<c005b3d0>] (cpu_startup_entry) from [<c00144d0>] (secondary_start_kernel+0xf4/0x100)
[ 132.627503] r7:c06fd440
[ 132.630023] [<c00143dc>] (secondary_start_kernel) from [<40008744>] (0x40008744)
[ 132.637399] r4:6e09006a r3:c000872c
[ 132.640958] CPU1: stopping
[ 132.643651] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D W 4.0.1-debug+ #3
[ 132.651287] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 132.657362] Backtrace:
[ 132.659799] [<c0012484>] (dump_backtrace) from [<c001269c>] (show_stack+0x18/0x1c)
[ 132.667344] r6:c06e158c r5:ffffffff r4:00000000 r3:dc8ba201
[ 132.672991] [<c0012684>] (show_stack) from [<c04dfb94>] (dump_stack+0x88/0xc8)
[ 132.680194] [<c04dfb0c>] (dump_stack) from [<c0014894>] (handle_IPI+0x1c8/0x2c4)
[ 132.687569] r6:c06bfc54 r5:c06bfc54 r4:00000005 r3:ee0ae000
[ 132.693214] [<c00146cc>] (handle_IPI) from [<c00086b0>] (gic_handle_irq+0x6c/0x70)
[ 132.700762] r9:f0024000 r8:ee0aff48 r7:c06c680c r6:fffffff5 r5:00000005 r4:f002400c
[ 132.708491] [<c0008644>] (gic_handle_irq) from [<c0013240>] (__irq_svc+0x40/0x74)
[ 132.715953] Exception stack(0xee0aff48 to 0xee0aff90)
[ 132.720989] ff40: 00000001 00000000 00000000 c00206c0 c06c6518 c04eb3a4
[ 132.729149] ff60: 00000000 00000000 c06c0dc0 00000001 c06fb774 ee0aff9c ee0affa0 ee0aff90
[ 132.737306] ff80: c000f82c c000f830 60070053 ffffffff
[ 132.742339] r9:00000001 r8:c06c0dc0 r7:ee0aff7c r6:ffffffff r5:60070053 r4:c000f830
[ 132.750069] [<c000f7f0>] (arch_cpu_idle) from [<c005b6e8>] (cpu_startup_entry+0x318/0x4ec)
[ 132.758314] [<c005b3d0>] (cpu_startup_entry) from [<c00144d0>] (secondary_start_kernel+0xf4/0x100)
[ 132.767251] r7:c06fd440
[ 132.769772] [<c00143dc>] (secondary_start_kernel) from [<40008744>] (0x40008744)
[ 132.777146] r4:6e09006a r3:c000872c
[ 132.780709] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
Simplify the code and remove superfluous return statement. Just return
the result of fimd_iommu_attach_devices().
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Reviewed-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
The Exynos DRM code does not modify the ops provided by CRTC driver in
exynos_drm_crtc_create() call.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Reviewed-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
Disabling the CONFIG_DRM_EXYNOS_FIMD (e.g. by enabling of CONFIG_FB_S3C)
leads to build error:
drivers/built-in.o: In function `exynos_dp_dpms':
binder.c:(.text+0xd6a840): undefined reference to `fimd_dp_clock_enable'
binder.c:(.text+0xd6ab54): undefined reference to `fimd_dp_clock_enable'
Fix this by changing direct call to fimd_dp_clock_enable() into optional
call to exynos_drm_crtc_ops->clock_enable(). Only the DRM_EXYNOS_FIMD
implements this op.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Reviewed-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
The platform_device_id is not modified by the driver and core uses it as
const.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
Move the defines for the pixelformats that the mixer supports out
of mixer_graph_buffer() to the top of the source.
Then select the mixer pixelformat (pf) in mixer_graph_buffer() based on
the plane's pf (and not bpp).
Also add handling of RGB565 and XRGB1555 to the switch statement and
exit early if the plane has an unsupported pf.
Partially based on 'drm/exynos: enable/disable blend based on pixel
format' by Gustavo Padovan <gustavo.padovan@collabora.co.uk>.
v2: Use the shorter MXR_FORMAT as prefix.
v3: Re-add ARGB8888 because of compatibility reasons
(suggested by Joonyoung Shim).
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Acked-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
All the necessary code is already there, just need to
handle the format in the switch statement.
Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Acked-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
The video processor (VP) supports four formats: NV12, NV21 and its
tiled variants. All these formats are bi-planar, so the buffer
count in vp_video_buffer() is always 2.
Also properly exit if we're called with an invalid (non-VP) pixelformat.
Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Acked-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
Previously we were ignoring the buffer offsets that are
passed through the addfb2 ioctl. This didn't cause any
major issues, since for uni-planar formats (like XRGB8888)
userspace would most of the time just use offsets[0]=0.
However with NV12 offsets[1] is very likely non-zero.
So properly apply the offsets to our dma addresses.
Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Acked-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
The previous code had some special case handling for the buffer
count in exynos_drm_format_num_buffers().
This code was incorrect though, since this special case doesn't
exist for DRM. It stemmed from the existence of the special NV12M
V4L2 format. NV12 is a bi-planar format (separate planes for luma
and chroma) and V4L2 differentiates between a NV12 buffer where
luma and chroma is contiguous in memory (so no data between
luma/chroma), and a NV12 buffer where luma and chroma have two
explicit memory locations (which is then called NV12M).
This distinction doesn't exist for DRM. A bi-planar format always
explicitly comes with the information about its two planes (even
if these planes should be contiguous).
Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Acked-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
Microsoft LifeCam Studio (045e:0772) needs a similar quirk for
suppressing the wrong sample rate inquiry.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=98481
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Git commit 152125b7a882df36a55a8eadbea6d0edf1461ee7
"s390/mm: implement dirty bits for large segment table entries"
broke the pmd_pfn function, it changed the return value from
'unsigned long' to 'int'. This breaks all machine configurations
with memory above the 8TB line.
Cc: stable@vger.kernel.org # 3.17+
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
|
|
Currently in snd_pcm_update_hw_ptr0 during interrupt,
we consider there were double acknowledged interrupts when:
1. HW reported pointer is smaller than expected, and
2. Time from last update time (hdelta) is over half a buffer time.
However, when HW reported pointer is only a few bytes smaller than
expected, and when hdelta is just a little larger than half a buffer time
(e.g. ping-pong buffer), it wrongly treats this IRQ as double acknowledged.
The condition #2 uses jiffies, but jiffies is not high resolution
since it is integer. We should consider jiffies inaccuracy.
Signed-off-by: Koro Chen <koro.chen@mediatek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Commit c9f038a1a592 ("drm/i915: Don't assume primary & cursor are
always on for wm calculation (v4)") fixes a null pointer dereference.
Setting the primary and cursor panes to false in
ilk_compute_wm_parameters to false does however give the following
errors in the kernel log and causes the screen to flicker.
[ 101.133716] [drm:intel_set_cpu_fifo_underrun_reporting [i915]]
*ERROR* uncleared fifo underrun on pipe A
[ 101.133725] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
*ERROR* CPU pipe A FIFO underrun
Always setting the panes to enabled fixes this error.
Helped-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
This new location was supposed to be temporary, but a couple years
have elapsed and it's still there, so apparently it's there to stay.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
into drm-fixes
msm fixes, pretty scattered.
* 'msm-fixes-4.1' of git://people.freedesktop.org/~robclark/linux:
drm/msm: fix locking inconsistencies in gpu->destroy()
drm/msm/dsi: Simplify the code to get the number of read byte
drm/msm: Attach assigned encoder to eDP and DSI connectors
drm/msm: setup vram after component_bind_all()
drm/msm/dsi: use pr_err_ratelimited
drm/msm: fix unbalanced DRM framebuffer init/destroy
drm/msm/mdp5: Fix iteration on INTF config array
drm/msm/dsi: Fixup missing *break* statement during cmd rx
drm/msm/dp: fix error return code
drm: msm: Fix build when legacy fbdev support isn't set
drm/msm/dsi: Fix a couple more 64-bit build warnings
drm/msm: Fix a couple of 64-bit build warnings
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal into for-rc
|
|
block plug callback could sleep, so we introduce a parameter
'from_schedule' and corresponding drivers can use it to destinguish a
schedule plug flush or a plug finish. Unfortunately io_schedule_out
still uses blk_flush_plug(). This causes below output (Note, I added a
might_sleep() in raid1_unplug to make it trigger faster, but the whole
thing doesn't matter if I add might_sleep). In raid1/10, this can cause
deadlock.
This patch makes io_schedule_out always uses blk_schedule_flush_plug.
This should only impact drivers (as far as I know, raid 1/10) which are
sensitive to the 'from_schedule' parameter.
[ 370.817949] ------------[ cut here ]------------
[ 370.817960] WARNING: CPU: 7 PID: 145 at ../kernel/sched/core.c:7306 __might_sleep+0x7f/0x90()
[ 370.817969] do not call blocking ops when !TASK_RUNNING; state=2 set at [<ffffffff81092fcf>] prepare_to_wait+0x2f/0x90
[ 370.817971] Modules linked in: raid1
[ 370.817976] CPU: 7 PID: 145 Comm: kworker/u16:9 Tainted: G W 4.0.0+ #361
[ 370.817977] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140709_153802- 04/01/2014
[ 370.817983] Workqueue: writeback bdi_writeback_workfn (flush-9:1)
[ 370.817985] ffffffff81cd83be ffff8800ba8cb298 ffffffff819dd7af 0000000000000001
[ 370.817988] ffff8800ba8cb2e8 ffff8800ba8cb2d8 ffffffff81051afc ffff8800ba8cb2c8
[ 370.817990] ffffffffa00061a8 000000000000041e 0000000000000000 ffff8800ba8cba28
[ 370.817993] Call Trace:
[ 370.817999] [<ffffffff819dd7af>] dump_stack+0x4f/0x7b
[ 370.818002] [<ffffffff81051afc>] warn_slowpath_common+0x8c/0xd0
[ 370.818004] [<ffffffff81051b86>] warn_slowpath_fmt+0x46/0x50
[ 370.818006] [<ffffffff81092fcf>] ? prepare_to_wait+0x2f/0x90
[ 370.818008] [<ffffffff81092fcf>] ? prepare_to_wait+0x2f/0x90
[ 370.818010] [<ffffffff810776ef>] __might_sleep+0x7f/0x90
[ 370.818014] [<ffffffffa0000c03>] raid1_unplug+0xd3/0x170 [raid1]
[ 370.818024] [<ffffffff81421d9a>] blk_flush_plug_list+0x8a/0x1e0
[ 370.818028] [<ffffffff819e3550>] ? bit_wait+0x50/0x50
[ 370.818031] [<ffffffff819e21b0>] io_schedule_timeout+0x130/0x140
[ 370.818033] [<ffffffff819e3586>] bit_wait_io+0x36/0x50
[ 370.818034] [<ffffffff819e31b5>] __wait_on_bit+0x65/0x90
[ 370.818041] [<ffffffff8125b67c>] ? ext4_read_block_bitmap_nowait+0xbc/0x630
[ 370.818043] [<ffffffff819e3550>] ? bit_wait+0x50/0x50
[ 370.818045] [<ffffffff819e3302>] out_of_line_wait_on_bit+0x72/0x80
[ 370.818047] [<ffffffff810935e0>] ? autoremove_wake_function+0x40/0x40
[ 370.818050] [<ffffffff811de744>] __wait_on_buffer+0x44/0x50
[ 370.818053] [<ffffffff8125ae80>] ext4_wait_block_bitmap+0xe0/0xf0
[ 370.818058] [<ffffffff812975d6>] ext4_mb_init_cache+0x206/0x790
[ 370.818062] [<ffffffff8114bc6c>] ? lru_cache_add+0x1c/0x50
[ 370.818064] [<ffffffff81297c7e>] ext4_mb_init_group+0x11e/0x200
[ 370.818066] [<ffffffff81298231>] ext4_mb_load_buddy+0x341/0x360
[ 370.818068] [<ffffffff8129a1a3>] ext4_mb_find_by_goal+0x93/0x2f0
[ 370.818070] [<ffffffff81295b54>] ? ext4_mb_normalize_request+0x1e4/0x5b0
[ 370.818072] [<ffffffff8129ab67>] ext4_mb_regular_allocator+0x67/0x460
[ 370.818074] [<ffffffff81295b54>] ? ext4_mb_normalize_request+0x1e4/0x5b0
[ 370.818076] [<ffffffff8129ca4b>] ext4_mb_new_blocks+0x4cb/0x620
[ 370.818079] [<ffffffff81290956>] ext4_ext_map_blocks+0x4c6/0x14d0
[ 370.818081] [<ffffffff812a4d4e>] ? ext4_es_lookup_extent+0x4e/0x290
[ 370.818085] [<ffffffff8126399d>] ext4_map_blocks+0x14d/0x4f0
[ 370.818088] [<ffffffff81266fbd>] ext4_writepages+0x76d/0xe50
[ 370.818094] [<ffffffff81149691>] do_writepages+0x21/0x50
[ 370.818097] [<ffffffff811d5c00>] __writeback_single_inode+0x60/0x490
[ 370.818099] [<ffffffff811d630a>] writeback_sb_inodes+0x2da/0x590
[ 370.818103] [<ffffffff811abf4b>] ? trylock_super+0x1b/0x50
[ 370.818105] [<ffffffff811abf4b>] ? trylock_super+0x1b/0x50
[ 370.818107] [<ffffffff811d665f>] __writeback_inodes_wb+0x9f/0xd0
[ 370.818109] [<ffffffff811d69db>] wb_writeback+0x34b/0x3c0
[ 370.818111] [<ffffffff811d70df>] bdi_writeback_workfn+0x23f/0x550
[ 370.818116] [<ffffffff8106bbd8>] process_one_work+0x1c8/0x570
[ 370.818117] [<ffffffff8106bb5b>] ? process_one_work+0x14b/0x570
[ 370.818119] [<ffffffff8106c09b>] worker_thread+0x11b/0x470
[ 370.818121] [<ffffffff8106bf80>] ? process_one_work+0x570/0x570
[ 370.818124] [<ffffffff81071868>] kthread+0xf8/0x110
[ 370.818126] [<ffffffff81071770>] ? kthread_create_on_node+0x210/0x210
[ 370.818129] [<ffffffff819e9322>] ret_from_fork+0x42/0x70
[ 370.818131] [<ffffffff81071770>] ? kthread_create_on_node+0x210/0x210
[ 370.818132] ---[ end trace 7b4deb71e68b6605 ]---
V2: don't change ->in_iowait
Cc: NeilBrown <neilb@suse.de>
Signed-off-by: Shaohua Li <shli@fb.com>
Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
|
|
By inspection, this appears to be a typo. The gating comparison
involves vxlan->dev rather than dev. In fact, dev is the iterator in
the preceding loop above but it is actually constant in the 2nd loop.
Use of dev seems to be a bad cut-n-paste from the prior call to
unregister_netdevice_queue. Change dev to vxlan->dev, since that is
what is actually being checked.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth
Johan Hedberg says:
====================
pull request: bluetooth 2015-05-17
A couple more Bluetooth updates for 4.1:
- New USB IDs for ath3k & btusb
- Fix for remote name resolving during device discovery
Please let me know if there are any issues pulling. Thanks.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The old email addresses will go away very soon. Revising with new addresses.
Signed-off-by: Dick Kennedy <dick.kennedy@avagotech.com>
Signed-off-by: James Smart <james.smart@avagotech.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
|
|
be2iscsi change of ownership from Emulex to Avago Technologies recently. We
like to get the following updates in: changed "Emulex" to "Avago
Technologies", changed email addresses from "emulex.com" to "avagotech.com",
updated MAINTAINER list for be2iscsi driver.
Signed-off-by: Minh Tran <minh.tran@avagotech.com>
Signed-off-by: Jayamohan Kallickal <jayamohan.kallickal@avagotech.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
|
|
256 bytes per sector support has been broken since 2.6.X,
and no-one stepped up to fix this.
So disable support for it.
Signed-off-by: Mark Hounschell <dmarkh@cfl.rr.com>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Cc: stable@vger.kernel.org
Signed-off-by: James Bottomley <JBottomley@Odin.com>
|
|
|