diff --git a/src/context.c b/src/context.c
index c2fa842..2eae439 100644
--- a/src/context.c
+++ b/src/context.c
@@ -131,7 +131,9 @@ VAStatus RequestCreateContext(VADriverContextP context, VAConfigID config_id,
 	 * device fd (request_fd=-1) before VIDIOC_STREAMON; per-request
 	 * controls (SPS/PPS/etc.) attached to a request_fd come later.
 	 *
-	 * hantro-vpu (RK3568) accepts only DECODE_MODE_FRAME_BASED.
+	 * hantro-vpu via rockchip,rk3568-vpu DT compatible (covers RK3568
+	 * and RK3566 — PineTab2 silicon — since they're close enough)
+	 * accepts only DECODE_MODE_FRAME_BASED.
 	 * START_CODE_ANNEX_B preserves leading 0x00000001 in the slice
 	 * payload that h264.c assembles. Errors here are not fatal: not
 	 * every backing driver supports both controls (e.g. cedrus may
diff --git a/src/h264.c b/src/h264.c
index f95bc10..6202001 100644
--- a/src/h264.c
+++ b/src/h264.c
@@ -294,7 +294,7 @@ static void h264_fill_dpb(struct request_data *data,
 		 * one consumer that fails on that. Hantro doesn't read
 		 * pic_num at all (uses reference_ts for ref resolution),
 		 * which is why fourier's wrong value never surfaced on
-		 * RK3568.
+		 * PineTab2 (RK3566 via hantro/rk3568-vpu).
 		 */
 		if (entry->pic.flags & VA_PICTURE_H264_LONG_TERM_REFERENCE) {
 			dpb->pic_num = entry->pic.frame_idx;