diff --git a/base b/base
index 5652189..13e09881 160000
--- a/base
+++ b/base
@@ -1 +1 @@
-Subproject commit 56521897e92a15158bb47dd33b1159e96c345875
+Subproject commit 13e0988140374123bead1dd27c287354cb95108e
diff --git a/cover b/cover
index cb5e86c..0f20adf 100644
--- a/cover
+++ b/cover
@@ -1,8 +1,5 @@
 vsp1 writeback prototype
 
-Resending this patch series to bring in dri-devel, and interested parties.
-Apologies for the resend to linux-media and linux-renesas-soc.
-
 This short series extends the VSP1 on the RCar platforms to allow creating a
 V4L2 video node on display pipelines where the hardware allows writing to
 memory simultaneously.
@@ -15,7 +12,7 @@
 
 Ideally swapping buffers would occur on every vsync such that the output rate
 of the video node would match the display rate, however the timing here proves
-more difficult to synchronise the updates from a vysnc and flush without adding
+more difficult to synchronise the updates from a vsync and flush without adding
 latency to the flush.
 
 Is there anything I can do to synchronise the v4l2 buffers with the DRM/KMS
@@ -26,6 +23,9 @@
 targets as well would be worth considering - though currently this
 implementation is very RCar/VSP1 specific.
 
+v2:
+ - Rebased to v4.12-rc1
+
 Kieran Bingham (2):
   Revert "[media] v4l: vsp1: Supply frames to the DU continuously"
   v4l: vsp1: Provide a writeback video device
diff --git a/series b/series
index efd1b3c2..5debeb0 160000
--- a/series
+++ b/series
@@ -1 +1 @@
-Subproject commit efd1b3c27bc55ac742d1c02bb78955c05ca70200
+Subproject commit 5debeb08338b520f52577ca6cf9be815a54c07ea