VOP pitch register is word align, need align to word.
VOP_WIN0_VIR:
bit[31:16] win0_vir_stride_uv
Number of words of Win0 uv Virtual width
bit[15:0] win0_vir_width
Number of words of Win0 yrgb Virtual width
ARGB888 : win0_vir_width
RGB888 : (win0_vir_width*3/4) + (win0_vir_width%3)
RGB565 : ceil(win0_vir_width/2)
YUV : ceil(win0_vir_width/4)
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Reviewed-by: Sandy huang <sandy.huang@rock-chips.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1501494591-7034-1-git-send-email-mark.yao@rock-chips.com
Iommu would get page fault with following path:
vop_disable:
1, disable all windows and set vop config done
2, vop enter to standy, all windows not works, but their registers
are not clean, when you read window's enable bit, may found the
window is enable.
vop_enable:
1, memcpy(vop->regsbak, vop->regs, len)
save current vop registers to vop->regsbak, then you can found
window is enable on regsbak.
2, VOP_WIN_SET(vop, win, gate, 1);
force enable window gate, but gate and enable are on same
hardware register, then window enable bit rewrite to vop hardware.
3, vop power on, and vop might try to scan destroyed buffer,
then iommu get page fault.
Move windows disable after vop regsbak restore, then vop regsbak mechanism
would keep tracing the modify, everything would be safe.
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Reviewed-by: Sandy huang <sandy.huang@rock-chips.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1501494582-6934-1-git-send-email-mark.yao@rock-chips.com
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by <linux/pci.h> work with
const pci_device_id. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by <linux/pci.h> work with
const pci_device_id. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by <linux/pci.h> work with
const pci_device_id. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by <linux/pci.h> work with
const pci_device_id. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by <linux/pci.h> work with
const pci_device_id. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by <linux/pci.h> work with
const pci_device_id. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by <linux/pci.h> work with
const pci_device_id. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by <linux/pci.h> work with
const pci_device_id. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
pci_device_id are not supposed to change at runtime. All functions
working with pci_device_id provided by <linux/pci.h> work with
const pci_device_id. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If the decrementer wraps again and de-asserts the decrementer
exception while hard-disabled, __check_irq_replay() has a test to
notice the wrap when interrupts are re-enabled.
The decrementer check must be done when clearing the PACA_IRQ_HARD_DIS
flag, not when the PACA_IRQ_DEC flag is tested. Previously this worked
because the decrementer interrupt was always the first one checked
after clearing the hard disable flag, but HMI check was moved ahead of
that, which introduced this bug.
This can cause a missed decrementer interrupt if we soft-disable
interrupts then take an HMI which is recorded in irq_happened, then
hard-disable interrupts for > 4s to wrap the decrementer.
Fixes: e0e0d6b739 ("powerpc/64: Replay hypervisor maintenance interrupt first")
Cc: stable@vger.kernel.org # v4.9+
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
POWER9 DD2 PMU can stop after a state-loss idle in some conditions.
A solution is to set then clear MMCRA[60] after wake from state-loss
idle. MMCRA[60] is a non-architected bit, see the user manual for
details.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Acked-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Reviewed-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Acked-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Just a few small fixes for 4.13.
* 'drm-fixes-4.13' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu: Use list_del_init in amdgpu_mn_unregister
drm/amdgpu: Fix undue fallthroughs in golden registers initialization
drm/amdgpu: fix header on gfx9 clear state
rcar-du updates, contains vsp1 updates as well.
* tag 'drm-next-du-20170803' of git://linuxtv.org/pinchartl/media: (24 commits)
drm: rcar-du: Use new iterator macros
drm: rcar-du: Repair vblank for DRM page flips using the VSP
drm: rcar-du: Fix race condition when disabling planes at CRTC stop
drm: rcar-du: Wait for flip completion instead of vblank in commit tail
drm: rcar-du: Use the VBK interrupt for vblank events
drm: rcar-du: Add HDMI outputs to R8A7796 device description
drm: rcar-du: Remove an unneeded NULL check
drm: rcar-du: Setup planes before enabling CRTC to avoid flicker
drm: rcar-du: Configure DPAD0 routing through last group on Gen3
drm: rcar-du: Restrict DPLL duty cycle workaround to H3 ES1.x
drm: rcar-du: Support multiple sources from the same VSP
drm: rcar-du: Fix comments to comply with the kernel coding style
drm: rcar-du: Use of_graph_get_remote_endpoint()
v4l: vsp1: Add support for header display lists in continuous mode
v4l: vsp1: Add support for multiple DRM pipelines
v4l: vsp1: Add support for multiple LIF instances
v4l: vsp1: Add support for new VSP2-BS, VSP2-DL and VSP2-D instances
v4l: vsp1: Add support for the BRS entity
v4l: vsp1: Add pipe index argument to the VSP-DU API
v4l: vsp1: Don't create links for DRM pipeline
...
Neal Cardwell says:
====================
tcp: fix xmit timer rearming to avoid stalls
This patch series is a bug fix for a TCP loss recovery performance bug
reported independently in recent netdev threads:
(i) July 26, 2017: netdev thread "TCP fast retransmit issues"
(ii) July 26, 2017: netdev thread:
"[PATCH V2 net-next] TLP: Don't reschedule PTO when there's one
outstanding TLP retransmission"
Many thanks to Klavs Klavsen and Mao Wenan for the detailed reports,
traces, and packetdrill test cases, which enabled us to root-cause
this issue and verify the fix.
- v1 -> v2:
- In patch 2/3, changed an unclear comment in the pre-existing code
in tcp_schedule_loss_probe() to be more clear (thanks to Eric Dumazet
for suggesting we improve this).
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix a TCP loss recovery performance bug raised recently on the netdev
list, in two threads:
(i) July 26, 2017: netdev thread "TCP fast retransmit issues"
(ii) July 26, 2017: netdev thread:
"[PATCH V2 net-next] TLP: Don't reschedule PTO when there's one
outstanding TLP retransmission"
The basic problem is that incoming TCP packets that did not indicate
forward progress could cause the xmit timer (TLP or RTO) to be rearmed
and pushed back in time. In certain corner cases this could result in
the following problems noted in these threads:
- Repeated ACKs coming in with bogus SACKs corrupted by middleboxes
could cause TCP to repeatedly schedule TLPs forever. We kept
sending TLPs after every ~200ms, which elicited bogus SACKs, which
caused more TLPs, ad infinitum; we never fired an RTO to fill in
the holes.
- Incoming data segments could, in some cases, cause us to reschedule
our RTO or TLP timer further out in time, for no good reason. This
could cause repeated inbound data to result in stalls in outbound
data, in the presence of packet loss.
This commit fixes these bugs by changing the TLP and RTO ACK
processing to:
(a) Only reschedule the xmit timer once per ACK.
(b) Only reschedule the xmit timer if tcp_clean_rtx_queue() deems the
ACK indicates sufficient forward progress (a packet was
cumulatively ACKed, or we got a SACK for a packet that was sent
before the most recent retransmit of the write queue head).
This brings us back into closer compliance with the RFCs, since, as
the comment for tcp_rearm_rto() notes, we should only restart the RTO
timer after forward progress on the connection. Previously we were
restarting the xmit timer even in these cases where there was no
forward progress.
As a side benefit, this commit simplifies and speeds up the TCP timer
arming logic. We had been calling inet_csk_reset_xmit_timer() three
times on normal ACKs that cumulatively acknowledged some data:
1) Once near the top of tcp_ack() to switch from TLP timer to RTO:
if (icsk->icsk_pending == ICSK_TIME_LOSS_PROBE)
tcp_rearm_rto(sk);
2) Once in tcp_clean_rtx_queue(), to update the RTO:
if (flag & FLAG_ACKED) {
tcp_rearm_rto(sk);
3) Once in tcp_ack() after tcp_fastretrans_alert() to switch from RTO
to TLP:
if (icsk->icsk_pending == ICSK_TIME_RETRANS)
tcp_schedule_loss_probe(sk);
This commit, by only rescheduling the xmit timer once per ACK,
simplifies the code and reduces CPU overhead.
This commit was tested in an A/B test with Google web server
traffic. SNMP stats and request latency metrics were within noise
levels, substantiating that for normal web traffic patterns this is a
rare issue. This commit was also tested with packetdrill tests to
verify that it fixes the timer behavior in the corner cases discussed
in the netdev threads mentioned above.
This patch is a bug fix patch intended to be queued for -stable
relases.
Fixes: 6ba8a3b19e ("tcp: Tail loss probe (TLP)")
Reported-by: Klavs Klavsen <kl@vsen.dk>
Reported-by: Mao Wenan <maowenan@huawei.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Nandita Dukkipati <nanditad@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Have tcp_schedule_loss_probe() base the TLP scheduling decision based
on when the RTO *should* fire. This is to enable the upcoming xmit
timer fix in this series, where tcp_schedule_loss_probe() cannot
assume that the last timer installed was an RTO timer (because we are
no longer doing the "rearm RTO, rearm RTO, rearm TLP" dance on every
ACK). So tcp_schedule_loss_probe() must independently figure out when
an RTO would want to fire.
In the new TLP implementation following in this series, we cannot
assume that icsk_timeout was set based on an RTO; after processing a
cumulative ACK the icsk_timeout we see can be from a previous TLP or
RTO. So we need to independently recalculate the RTO time (instead of
reading it out of icsk_timeout). Removing this dependency on the
nature of icsk_timeout makes things a little easier to reason about
anyway.
Note that the old and new code should be equivalent, since they are
both saying: "if the RTO is in the future, but at an earlier time than
the normal TLP time, then set the TLP timer to fire when the RTO would
have fired".
Fixes: 6ba8a3b19e ("tcp: Tail loss probe (TLP)")
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Nandita Dukkipati <nanditad@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pure refactor. This helper will be required in the xmit timer fix
later in the patch series. (Because the TLP logic will want to make
this calculation.)
Fixes: 6ba8a3b19e ("tcp: Tail loss probe (TLP)")
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Nandita Dukkipati <nanditad@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
After commit c2ed1880fd ("net: ipv6: check route protocol when
deleting routes"), ipv6 route checks rt protocol when trying to
remove a rt entry.
It introduced a side effect causing 'ip -6 route flush cache' not
to work well. When flushing caches with iproute, all route caches
get dumped from kernel then removed one by one by sending DELROUTE
requests to kernel for each cache.
The thing is iproute sends the request with the cache whose proto
is set with RTPROT_REDIRECT by rt6_fill_node() when kernel dumps
it. But in kernel the rt_cache protocol is still 0, which causes
the cache not to be matched and removed.
So the real reason is rt6i_protocol in the route is not set when
it is allocated. As David Ahern's suggestion, this patch is to
set rt6i_protocol properly in the route when it is installed and
remove the codes setting rtm_protocol according to rt6i_flags in
rt6_fill_node.
This is also an improvement to keep rt6i_protocol consistent with
rtm_protocol.
Fixes: c2ed1880fd ("net: ipv6: check route protocol when deleting routes")
Reported-by: Jianlin Shi <jishi@redhat.com>
Suggested-by: David Ahern <dsahern@gmail.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Merge misc fixes from Andrew Morton:
"15 fixes"
[ This does not merge the "fortify: use WARN instead of BUG for now"
patch, which needs a bit of extra work to build cleanly with all
configurations. Arnd is on it. - Linus ]
* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
ocfs2: don't clear SGID when inheriting ACLs
mm: allow page_cache_get_speculative in interrupt context
userfaultfd: non-cooperative: flush event_wqh at release time
ipc: add missing container_of()s for randstruct
cpuset: fix a deadlock due to incomplete patching of cpusets_enabled()
userfaultfd_zeropage: return -ENOSPC in case mm has gone
mm: take memory hotplug lock within numa_zonelist_order_handler()
mm/page_io.c: fix oops during block io poll in swapin path
zram: do not free pool->size_class
kthread: fix documentation build warning
kasan: avoid -Wmaybe-uninitialized warning
userfaultfd: non-cooperative: notify about unmap of destination during mremap
mm, mprotect: flush TLB if potentially racing with a parallel reclaim leaving stale TLB entries
pid: kill pidhash_size in pidhash_init()
mm/hugetlb.c: __get_user_pages ignores certain follow_hugetlb_page errors
- Fix a device ID of Hisilicon Hip07/08 in the ACPI APD (AMD SoC)
driver (Hanjun Guo).
- Fix list corruption (introduced during the 4.11 cycle) in the ACPI
LPSS (Intel SoC) driver (Hans de Goede).
- Fix PCC mailbox handling code crash during initialization when
PCCT is not present and PCC channel 0 is requested (Hoan Tran).
- Fix a WDAT watchdog initialization issue causing platform device
creation to fail due to partially overlapping address ranges in
resources (Ryan Kennedy).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJZg3FsAAoJEILEb/54YlRxmowQAIjFSnojQPMu1Gd8qSvnO5j/
5XqE1ohkb/0sfkY6uLPX/mDU7fEZHr+rz3bLVgU7BPumcqQ9rxi8P+1M0zl3ccIe
KxGaRF0zL3TVnLzzxcQUprdCLBVJH+bu7uiNMvFq0pLrKCKMT1SdVwG9HsZeDsQD
IdpACI4UkdQ840KwOXePpvlmOI03ThHZAcJn9TrmupA90teF/j/pqdV25A8+yWo3
4Yxmh7Exd1wW5B6IFMMxmM8WhOB8Q0X50Wehsg2Yi16HddjI9IEwg+KnsgRRiodw
L+eDQgg6wUNJ2swVu7G/7KdvA4BDV5ZYbEo6gc0NZAhs0pTm4M6kMwa4i0OQ572r
WzhFrHfIuqyDMzSPJp9l5D38wgmIykMkX2dYKMi+sxnyi3ZgagAOlmYbmsPzhFWL
TrEhd7fJ687xtC991mLfNyWM7cr7mpFJL+eB9sOospBmF/xjFBlwvtNZI6dYhoDh
ON6E3QQ6/G/5XQQPF+SKBrMNllCs+N1hefvZiG9SD2i5u+m31Vd3WLDHoqHMcASu
oX7+PuvasBJNAVM/lMtbKtXcyHNfYRvzWBqkMkQPNIkmMfdXgI8g8ZNpj2R+onfd
RPJFp/IsF8FSjLA4Q/BMduLd/qjz7wZdIjuZZO/9eFOHVh8wBOt2ZfaFUjA00OmE
lKG8r1pui+P6e4o8OkO1
=ZD/q
-----END PGP SIGNATURE-----
Merge tag 'acpi-4.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI fixes from Rafael Wysocki:
"These fix two issues in the ACPI SoC drivers (Intel LPSS and AMD APD),
a crash in the PCC mailbox initialization code and a WDAT watchdog
initialization failure.
Specifics:
- Fix a device ID of Hisilicon Hip07/08 in the ACPI APD (AMD SoC)
driver (Hanjun Guo).
- Fix list corruption (introduced during the 4.11 cycle) in the ACPI
LPSS (Intel SoC) driver (Hans de Goede).
- Fix PCC mailbox handling code crash during initialization when PCCT
is not present and PCC channel 0 is requested (Hoan Tran).
- Fix a WDAT watchdog initialization issue causing platform device
creation to fail due to partially overlapping address ranges in
resources (Ryan Kennedy)"
* tag 'acpi-4.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: APD: Fix HID for Hisilicon Hip07/08
mailbox: pcc: Fix crash when request PCC channel 0
ACPI / watchdog: Fix init failure with overlapping register regions
ACPI / LPSS: Only call pwm_add_table() for the first PWM controller
- Fix the handling of the scaling_cur_freq cpufreq policy attribute
on x86 systems with the MPERF/APERF registers present to make it
behave more as expected after recent changes (Rafael Wysocki).
- Drop a leftover callback from the intel_pstate driver which also
prevents the cpuinfo_cur_freq cpufreq policy attribute from being
incorrectly exposed when intel_pstate works in the active mode
(Rafael Wysocki).
- Add a missing piece describing the cpuinfo_cur_freq policy
attribute to cpufreq documentation (Rafael Wysocki).
- Fix up a recently added part of the Thunderbolt driver to avoid
aborting system suspends if its mailbox commands time out (Rafael
Wysocki).
- Update device runtime PM framework documentation to reflect the
current behavior of the code (Johan Hovold).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJZg3DiAAoJEILEb/54YlRxvgkP/RV5djXAUeUpoMnzJCnP7jpB
bYvzqIXN2olcZPNP3hNLM7W1yRAWiwL9F1aFF2apJPyMQ8DW7iBqltAxQY+h2Ggc
lLvQcT5NRCFbIlsRadBL3TMZMFmtYqBD9Q8C+LLgQDWmm3mgG8o0kFJdGWkOMHg7
4FaqTuF1np8ARd1jX3E4QGCVaSqIEKN9xMo7jzsWIHXruag3tJb92ryROVcq3uO7
5WspJSbVMKS0E6jbK3RQkJ9T/3U453p8JMDJNQfOUFr1KQNfAikyV3U0ZoQA6Hjk
1tmJE9v7jq75BDj0Dtfskl8EBFA4Sk+Pegyb3/hB8MR/oRzCWRAe9rVW5LweckcC
Q1Q+SDKcVKVIEQa3GZOH1nBfHP/pIMQb0+WGMIq614rr1Ug9IuF4cCn2AnzkIFLE
lpkVch3mCfrCwAKmsvYug5isHdazlS93MY9dOZr4D1lewgFp1piShsBSK3RFBT8F
Cu3lYTzBi/MJ+8T0vZysHVEkCNu3emrXwccjzubW1rSNINGgRF5AV9F2HwGYzDHe
KD3Kw1KH2LZEWZAlR6W711pBJny4INENPH0XE85hZ4Ryi+2SN7zvsA/PM0rGjqBq
TcuFc3jN+DMwWoOJryY8701gE8SMz+8Vam/B191XFUkdZSHFk1WWILAu/OfTZCRo
bLYhORgyemWPluAzzcsx
=j2UJ
-----END PGP SIGNATURE-----
Merge tag 'pm-4.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management fixes from Rafael Wysocki:
"These fix two cpufreq issues, one introduced recently and one related
to recent changes, fix cpufreq documentation, fix up recently added
code in the Thunderbolt driver and update runtime PM framework
documentation.
Specifics:
- Fix the handling of the scaling_cur_freq cpufreq policy attribute
on x86 systems with the MPERF/APERF registers present to make it
behave more as expected after recent changes (Rafael Wysocki).
- Drop a leftover callback from the intel_pstate driver which also
prevents the cpuinfo_cur_freq cpufreq policy attribute from being
incorrectly exposed when intel_pstate works in the active mode
(Rafael Wysocki).
- Add a missing piece describing the cpuinfo_cur_freq policy
attribute to cpufreq documentation (Rafael Wysocki).
- Fix up a recently added part of the Thunderbolt driver to avoid
aborting system suspends if its mailbox commands time out (Rafael
Wysocki).
- Update device runtime PM framework documentation to reflect the
current behavior of the code (Johan Hovold)"
* tag 'pm-4.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
thunderbolt: icm: Ignore mailbox errors in icm_suspend()
cpufreq: x86: Make scaling_cur_freq behave more as expected
PM / runtime: Document new pm_runtime_set_suspended() constraint
cpufreq: docs: Add missing cpuinfo_cur_freq description
cpufreq: intel_pstate: Drop ->get from intel_pstate structure
This adds a new drm_setup_crtcs_fb() function to handle the parts of
drm_setup_crtcs() that touch fb_helper->fb and fb_helper->fbdev. When
drm_setup_crtcs() is called during initialization, these fields are NULL
because they have not been allocated yet.
There is currently a hack at the end of drm_fb_helper_single_fb_probe()
that sets fb_helper->fb, so it is moved to the new drm_setup_crtcs_fb()
function.
This is also done in preparation for addition setup that requires access
to fb_helper->fbdev.
Signed-off-by: David Lechner <david@lechnology.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1501777149-8310-2-git-send-email-david@lechnology.com
Here are some new device ids for v4.13-rc4.
All have been in linux-next with no reported issues.
Signed-off-by: Johan Hovold <johan@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEEHszNKQClByu0A+9RQQ3kT97htJUFAlmDSXARHGpvaGFuQGtl
cm5lbC5vcmcACgkQQQ3kT97htJWgoA/+LGO5SSJZTjGlqilC90idyoa1Ee1CtDCY
Vuc/95wTFGcTs5i2QPt94/Pma8uxRsKI2zu1rFxef6jJjiSoRUsUaSjyJwaDkuEj
YkeHUFcAzS8Gu+8U5Pz8DsB60Kw8pR+rS3VJsyOdBSUWLw/t6AVK3HagiejdqXXn
L3lYbc8rohDFsj7UjdNd9Sgv5vS3pBRO1+lyAu0OqX8UpOUmndPdwbsmuQbcFDSE
F/YI+oCxrbqLYma52buKBLNRmj5eF6QU0mjVJIfo1vFzx/zsGq64m7K7PVZ3F25H
j354jmdONuuStqbLgRz3RkPHQK3ootQ7NEcyxYdN/Rs7bfWlnkfbMPK7LC9BCYwt
w2Gx87nhBBiGLfP0GZ5qytwHCOYXVzxecwy4u1Byf4bt5w2J6CC1qYF1yUbK5Dxj
jZUXA9Hd0bLHtlEldm5IcMlUeahseGHyYvH7OaXZXk/Uq4YhFH6vcTkuAQSJ0cTD
KZgkfHymL/ukWORX5cZT6iU9M1pDdmDXpCz7h35FgaVEKNHmX62WX9SzgAyvCO3a
lOSoVS//QyjaOSIboTm6a2NFE9YL4+5OTbooAj0qcU7vf5P3Lj2t3pm6sn2tpcvs
YN6IzNbpWI8iGUUeRc88bT0ZSx6qf6B0kgmJQvnqn4z/fQOq1LfYgaPRxWVfXqGO
K9rBZPH6svU=
=bRO0
-----END PGP SIGNATURE-----
Merge tag 'usb-serial-4.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus
Johan writes:
USB-serial fixes for v4.13-rc4
Here are some new device ids for v4.13-rc4.
All have been in linux-next with no reported issues.
Signed-off-by: Johan Hovold <johan@kernel.org>
- fix TT sync flag inconsistency problems, which can lead to excess packets,
by Linus Luessing
-----BEGIN PGP SIGNATURE-----
iQJKBAABCgA0FiEE1ilQI7G+y+fdhnrfoSvjmEKSnqEFAlmB3ikWHHN3QHNpbW9u
d3VuZGVybGljaC5kZQAKCRChK+OYQpKeoUCUEADIvPfBxzon12xBV4JbBpTMnIwl
09heUwE1FxCj2UoTV2QJ+O9ZQb1yc7ARJksymP30T96q9bNlDiNFVquXcuQLA+ba
aoSowejLfTHLvOlP3Wrik5PVLBdKqeBpg7zYNtAuNI09DSryey1ipaC4Xemq9ZmC
8Hjam9RAQh5FV3RCeviTzpusXt31/xjkTx3vrf1WGx2uY/MSKNwwfPcRAyfG+Ye5
9kxpR8sBwRxJ+6+MEWRBjqi2Lk/BuD4urViAwGj88uDkKKByXT/pfULD3foTgx0d
smZWWMun9jQl4XDk321oOp5HOqg29IFcF/mwuWQIvBDO8AJBRndYHw07lx0cB5tD
I8PzTG5+kE3QXBeTBEUAuszaavDI9DKVdnr6h/8VbeEXIr73WHA0VixnTIv3zgI0
AiYHIrvUstDB7Cl5457blKbljgzXMN1ssBtD/UMNFhrEUKet9qIZskwlLyhPt2s3
qti70ZoURPz9ve57pNgZDZUR5lvvUhuSNUD4ZfGt5BC+YErX59jAswrRXHU5Zx/i
V5pSsRQ2BfxZUZrnmKONg3RW+hmsJJYOSzNXiO5/0zeVuorju7C+0L2goONX2bpr
fEzICfDJi+IXmYke0AAjiJq7KwobU703Nd3rT8eovjVlSSJj+mdyYSVYQF9dD2uE
DdtwpJh37PwbHOeQqg==
=a4HS
-----END PGP SIGNATURE-----
Merge tag 'batadv-net-for-davem-20170802' of git://git.open-mesh.org/linux-merge
Simon Wunderlich says:
====================
Here is a batman-adv bugfix:
- fix TT sync flag inconsistency problems, which can lead to excess packets,
by Linus Luessing
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Felipe writes:
usb: fixes for v4.13-rc4
Another fix for isochronous transfers on dwc3. This time around, we're
making sure that we use correct PIDs in all transfer sizes.
MSM PHY driver got a fix for the use of devm_regulator_bulk_get() API
which will avoid kernel crashes.
Renesas DRD driver got 3 fixes: a fix on giveback, a fix for proper
controller programming and the removal of set-but-never-used variable.
- Yet another race with VM destruction plugged
- A set of small vgic fixes
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEn9UcU+C1Yxj9lZw9I9DQutE9ekMFAlmDOZ4VHG1hcmMuenlu
Z2llckBhcm0uY29tAAoJECPQ0LrRPXpDnwQP/ji7d7bbWybmeuWKXm8TYt6CNPBr
JC57OQHytU1+ccagjeUPaAgUAqWSQWOwfbqPuS1afshJu1ZZsN851QNmcr5W6bXQ
EwjICGWcAdKSMLnhRDdf+uXQbFSkkcaxsXnJWjmD0EE8ylaXCCkdV278xhTx0hVO
yiov/xWNzLMa3O3W/l4SIKQ4UNyeQ7f+Od1Vkf7iUpaaFcz6s3RNsPAOwc7Thq7L
eLk4SgXMLDNHz5HwdLoOp3RwQsNe9A7uh05z9VOav0YAyLG5vf29JhMroCO/4P/x
1HgWvpGwzxAUqUcHbW4FSOsbydEltlWMdfSoAF7BtPCLudmmsxfMJJlK3FKLvV+P
MsO2FdXiz6/ZLI9/ds7YJDOfc1cGSVK07Efx+SLXD5FAnkFYq4SElmI4sK8BWc5U
Dugw3j8u9M6jTiVKBioFo7yRT5iHG9O0A+6DtsMQ0iREfLolC7EEzpfGB/vWpKk5
BbdwDUiu6JxXEBJJqyP948iGfuIrikAx2mcf3dmEHVKhEnKi+MN/H5c9BKGAJ3sf
Fm1xF99IG+m3L3zXiukQ11OqsCx32kqLiXaejVttscFg/C33OYmGOhsk066hHCzx
LtoxrHUl7rwF+ssnKHq4Az2mYzZtquEq13O5tgleQcVwH/2+6EgWDf3mDSy1em0h
5IXgqk+PsaQ5n0jL
=TMR9
-----END PGP SIGNATURE-----
Merge tag 'kvm-arm-for-v4.13-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm
KVM/ARM Fixes for v4.13-rc4
- Yet another race with VM destruction plugged
- A set of small vgic fixes
Commit 8fba54aebb ("fuse: direct-io: don't dirty ITER_BVEC pages") fixes
the ITER_BVEC page deadlock for direct io in fuse by checking in
fuse_direct_io(), whether the page is a bvec page or not, before locking
it. However, this check is missed when the "async_dio" mount option is
enabled. In this case, set_page_dirty_lock() is called from the req->end
callback in request_end(), when the fuse thread is returning from userspace
to respond to the read request. This will cause the same deadlock because
the bvec condition is not checked in this path.
Here is the stack of the deadlocked thread, while returning from userspace:
[13706.656686] INFO: task glusterfs:3006 blocked for more than 120 seconds.
[13706.657808] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message.
[13706.658788] glusterfs D ffffffff816c80f0 0 3006 1
0x00000080
[13706.658797] ffff8800d6713a58 0000000000000086 ffff8800d9ad7000
ffff8800d9ad5400
[13706.658799] ffff88011ffd5cc0 ffff8800d6710008 ffff88011fd176c0
7fffffffffffffff
[13706.658801] 0000000000000002 ffffffff816c80f0 ffff8800d6713a78
ffffffff816c790e
[13706.658803] Call Trace:
[13706.658809] [<ffffffff816c80f0>] ? bit_wait_io_timeout+0x80/0x80
[13706.658811] [<ffffffff816c790e>] schedule+0x3e/0x90
[13706.658813] [<ffffffff816ca7e5>] schedule_timeout+0x1b5/0x210
[13706.658816] [<ffffffff81073ffb>] ? gup_pud_range+0x1db/0x1f0
[13706.658817] [<ffffffff810668fe>] ? kvm_clock_read+0x1e/0x20
[13706.658819] [<ffffffff81066909>] ? kvm_clock_get_cycles+0x9/0x10
[13706.658822] [<ffffffff810f5792>] ? ktime_get+0x52/0xc0
[13706.658824] [<ffffffff816c6f04>] io_schedule_timeout+0xa4/0x110
[13706.658826] [<ffffffff816c8126>] bit_wait_io+0x36/0x50
[13706.658828] [<ffffffff816c7d06>] __wait_on_bit_lock+0x76/0xb0
[13706.658831] [<ffffffffa0545636>] ? lock_request+0x46/0x70 [fuse]
[13706.658834] [<ffffffff8118800a>] __lock_page+0xaa/0xb0
[13706.658836] [<ffffffff810c8500>] ? wake_atomic_t_function+0x40/0x40
[13706.658838] [<ffffffff81194d08>] set_page_dirty_lock+0x58/0x60
[13706.658841] [<ffffffffa054d968>] fuse_release_user_pages+0x58/0x70 [fuse]
[13706.658844] [<ffffffffa0551430>] ? fuse_aio_complete+0x190/0x190 [fuse]
[13706.658847] [<ffffffffa0551459>] fuse_aio_complete_req+0x29/0x90 [fuse]
[13706.658849] [<ffffffffa05471e9>] request_end+0xd9/0x190 [fuse]
[13706.658852] [<ffffffffa0549126>] fuse_dev_do_write+0x336/0x490 [fuse]
[13706.658854] [<ffffffffa054963e>] fuse_dev_write+0x6e/0xa0 [fuse]
[13706.658857] [<ffffffff812a9ef3>] ? security_file_permission+0x23/0x90
[13706.658859] [<ffffffff81205300>] do_iter_readv_writev+0x60/0x90
[13706.658862] [<ffffffffa05495d0>] ? fuse_dev_splice_write+0x350/0x350
[fuse]
[13706.658863] [<ffffffff812062a1>] do_readv_writev+0x171/0x1f0
[13706.658866] [<ffffffff810b3d00>] ? try_to_wake_up+0x210/0x210
[13706.658868] [<ffffffff81206361>] vfs_writev+0x41/0x50
[13706.658870] [<ffffffff81206496>] SyS_writev+0x56/0xf0
[13706.658872] [<ffffffff810257a1>] ? syscall_trace_leave+0xf1/0x160
[13706.658874] [<ffffffff816cbb2e>] system_call_fastpath+0x12/0x71
Fix this by making should_dirty a fuse_io_priv parameter that can be
checked in fuse_aio_complete_req().
Reported-by: Tiger Yang <tiger.yang@oracle.com>
Signed-off-by: Ashish Samant <ashish.samant@oracle.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
There is a small chance that the compiler could generate separate loads
for the dist->propbaser which could be modified from another CPU. As we
want to make sure we atomically update the entire value, and don't race
with other updates, guarantee that the cmpxchg operation compares
against the original value.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
drm_*_reference() and drm_*_unreference() functions are just
compatibility alias for drm_*_get() and drm_*_put() and should not be
used by new code. So convert all users of compatibility functions to use
the new APIs.
Signed-off-by: Cihangir Akturk <cakturk@gmail.com>
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1501761585-11757-6-git-send-email-cakturk@gmail.com
drm_plane_helper_funcs and drm_plane_funcsare not supposed to change
at runtime. All functions working with drm_plane_helper_funcs and
drm_plane_funcs work with const. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
6072 596 0 6668 1a0c atmel_hlcdc_plane.o
File size After adding 'const':
text data bss dec hex filename
6218 436 0 6654 19fe atmel_hlcdc_plane.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Link: https://patchwork.freedesktop.org/patch/msgid/646415a3b2e62182f85254115e8491e5caf4b2c7.1499098826.git.arvind.yadav.cs@gmail.com
------------[ cut here ]------------
WARNING: CPU: 5 PID: 2288 at arch/x86/kvm/vmx.c:11124 nested_vmx_vmexit+0xd64/0xd70 [kvm_intel]
CPU: 5 PID: 2288 Comm: qemu-system-x86 Not tainted 4.13.0-rc2+ #7
RIP: 0010:nested_vmx_vmexit+0xd64/0xd70 [kvm_intel]
Call Trace:
vmx_check_nested_events+0x131/0x1f0 [kvm_intel]
? vmx_check_nested_events+0x131/0x1f0 [kvm_intel]
kvm_arch_vcpu_ioctl_run+0x5dd/0x1be0 [kvm]
? vmx_vcpu_load+0x1be/0x220 [kvm_intel]
? kvm_arch_vcpu_load+0x62/0x230 [kvm]
kvm_vcpu_ioctl+0x340/0x700 [kvm]
? kvm_vcpu_ioctl+0x340/0x700 [kvm]
? __fget+0xfc/0x210
do_vfs_ioctl+0xa4/0x6a0
? __fget+0x11d/0x210
SyS_ioctl+0x79/0x90
do_syscall_64+0x8f/0x750
? trace_hardirqs_on_thunk+0x1a/0x1c
entry_SYSCALL64_slow_path+0x25/0x25
This can be reproduced by booting L1 guest w/ 'noapic' grub parameter, which
means that tells the kernel to not make use of any IOAPICs that may be present
in the system.
Actually external_intr variable in nested_vmx_vmexit() is the req_int_win
variable passed from vcpu_enter_guest() which means that the L0's userspace
requests an irq window. I observed the scenario (!kvm_cpu_has_interrupt(vcpu) &&
L0's userspace reqeusts an irq window) is true, so there is no interrupt which
L1 requires to inject to L2, we should not attempt to emualte "Acknowledge
interrupt on exit" for the irq window requirement in this scenario.
This patch fixes it by not attempt to emulate "Acknowledge interrupt on exit"
if there is no L1 requirement to inject an interrupt to L2.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
[Added code comment to make it obvious that the behavior is not correct.
We should do a userspace exit with open interrupt window instead of the
nested VM exit. This patch still improves the behavior, so it was
accepted as a (temporary) workaround.]
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
for_each_obj_in_state is about to be removed, so use the correct new
iterator macros.
Also look at new_plane_state instead of plane->state when looking up
the hw planes in use. They should be the same except when reallocating,
(in which case this code is skipped) and we should really stop looking
at obj->state whenever possible.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
The driver recently switched from handling page flip completion in the
DU vertical blanking handler to the VSP frame end handler to fix a race
condition. This unfortunately resulted in incorrect timestamps in the
vertical blanking events sent to userspace as vertical blanking is now
handled after sending the event.
To fix this we must reverse the order of the two operations. The easiest
way is to handle vertical blanking in the VSP frame end handler before
sending the event. The VSP frame end interrupt occurs approximately 50µs
earlier than the DU frame end interrupt, but this should not cause any
undue harm.
As we need to handle vertical blanking even when page flip completion is
delayed, the VSP driver now needs to call the frame end completion
callback unconditionally, with a new argument to report whether page
flip has completed.
With this new scheme the DU vertical blanking interrupt isn't needed
anymore, so we can stop enabling it.
Fixes: d503a43ac0 ("drm: rcar-du: Register a completion callback with VSP1")
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
When stopping the CRTC the driver must disable all planes and wait for
the change to take effect at the next vblank. Merely calling
drm_crtc_wait_one_vblank() is not enough, as the function doesn't
include any mechanism to handle the race with vblank interrupts.
Replace the drm_crtc_wait_one_vblank() call with a manual mechanism that
handles the vblank interrupt race.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Page flips can take more than one vertical blanking to complete if
arming the page flips races with the vertical blanking interrupt.
Waiting for one vblank to complete the atomic commit in the commit tail
handler is thus incorrect, and can lead to framebuffers being released
while still being scanned out.
Fix this by waiting for flip completion instead, using the
drm_atomic_helper_wait_for_flip_done() helper.
Fixes: 0d230422d256 ("drm: rcar-du: Register a completion callback with VSP1")
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
When implementing support for interlaced modes, the driver switched from
reporting vblank events on the vertical blanking (VBK) interrupt to the
frame end interrupt (FRM). This incorrectly divided the reported refresh
rate by two. Fix it by moving back to the VBK interrupt.
Fixes: 906eff7fca ("drm: rcar-du: Implement support for interlaced modes")
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
"params" can't be NULL here. The next lines assume that we either
hit the break statement of "params->mpixelclock == ~0UL". The
inconsistent NULL checking makes static checkers complain. I've just
removed the test.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Commit 52055bafa1 ("drm: rcar-du: Move plane commit code from CRTC
start to CRTC resume") changed the order of the plane commit and CRTC
enable operations to accommodate the runtime PM requirements. However,
this introduced corruption in the first displayed frame, as the CRTC is
now enabled without any plane configured. On Gen2 hardware the first
frame will be black and likely unnoticed, but on Gen3 hardware we end up
starting the display before the VSP compositor, which is more
noticeable.
To fix this, revert the order of the commit operations back, and handle
runtime PM requirements in the CRTC .atomic_begin() and .atomic_enable()
helper operation handlers.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
On Gen3 SoCs DPAD0 routing is configured through the last CRTC group,
unlike on Gen2 where it is configured through the first CRTC group. Fix
the driver accordingly.
Fixes: 2427b30377 ("drm: rcar-du: Add R8A7795 device support")
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
