Hi Thomas, > One remark on future updates: I assume that you want to further update > or extend the HW design. One thing you should certainly add is a > version/feature identifier, so that the driver can distinguish among > different hardware generations. We also cannot merge support for > everyone's hobbyist hardware and you got the benefit of being the > first. So for future submitters of similar drivers, it might be better > for them to build upon your work instead of coming up within something > entirely new. A distinct identifier will be helpful with that.
I'm planning to add a hardware register in a future revision that exposes a version number that the driver can read. > Is there a reason to no use drm_crtc_vblank_atomic_flush() ? It's the > same code. I will use drm_crtc_vblank_atomic_flush() in v6. On the QEMU device ID: it's currently a placeholder from the experimental range, since I haven't submitted the QEMU patch to get an official one yet. Is that fine to merge as is, with a follow-up kernel patch once the official ID is assigned? Best regards, Leander
