Split the original LCDIF change into three patches and address review feedback:

- place the LCDIF device under hw/display and include/hw/display
- use registerfields.h FIELD() definitions for register bitfields
- simplify drawing to 32bpp host surfaces
- add vmstate migration support
- use SoC child device init/realize flow (object_initialize_child + sysbus_realize)
- add a dedicated CONFIG_IMX6UL_LCDIF symbol, selected by FSL_IMX6UL

Thanks for the review.

Yucai Liu (3):
  hw/display: Add i.MX6UL LCDIF device model
  hw/display: Build i.MX6UL LCDIF via its own config symbol
  hw/arm/fsl-imx6ul: Wire in the LCDIF device model

 MAINTAINERS                       |   2 +
 hw/arm/Kconfig                    |   1 +
 hw/arm/fsl-imx6ul.c               |  12 +-
 hw/arm/meson.build                |   4 +-
 hw/display/Kconfig                |   4 +
 hw/display/imx6ul_lcdif.c         | 435 ++++++++++++++++++++++++++++++
 hw/display/meson.build            |   1 +
 include/hw/arm/fsl-imx6ul.h       |   4 +-
 include/hw/display/imx6ul_lcdif.h |  36 +++
 9 files changed, 495 insertions(+), 4 deletions(-)
 create mode 100644 hw/display/imx6ul_lcdif.c
 create mode 100644 include/hw/display/imx6ul_lcdif.h


base-commit: a6ec632dca8c7d10743aff29345e5e9e5324228b
-- 
2.53.0

On Tue, 3 Mar 2026 at 14:32, Yucai Liu <1486344514@qq.com> wrote:
>
> Split the original LCDIF change into three patches and address review feedback:
>
> - place the LCDIF device under hw/display and include/hw/display
> - use registerfields.h FIELD() definitions for register bitfields
> - simplify drawing to 32bpp host surfaces
> - add vmstate migration support
> - use SoC child device init/realize flow (object_initialize_child + sysbus_realize)
> - add a dedicated CONFIG_IMX6UL_LCDIF symbol, selected by FSL_IMX6UL
>
> Thanks for the review.
>
> Yucai Liu (3):
>   hw/display: Add i.MX6UL LCDIF device model
>   hw/display: Build i.MX6UL LCDIF via its own config symbol
>   hw/arm/fsl-imx6ul: Wire in the LCDIF device mode

Hi; thanks for these patches. This is just a note to let
you know that I do have them on my to-review queue, but
since they've missed softfreeze for 11.0 it might take me
a little longer to get to them, as I'm going to be
prioritizing 11.0 work.

PS: something seems to have gone wrong with how these emails
got sent: the 3 patch emails have a header
"In-Reply-To: <20260303143157.80437-1-1486344514@qq.com>"
that ought to be pointing to the cover letter, but there's
no email on list with that ID, and instead the cover letter
got sent with
"Message-ID: <tencent_D3A83F7C6433B6B2D6C4513970FD0446D708@qq.com>"

The effect is that for instance patchew doesn't find the patches:
https://patchew.org/QEMU/tencent._5FD3A83F7C6433B6B2D6C4513970FD0446D708@qq.com/

It looks like something in the mail infrastructure you're
using is rewriting message-IDs (e.g. in the cover letter it
has added a note of the original ID as
"X-OQ-MSGID: <20260303143157.80437-1-1486344514@qq.com>")
which is breaking the patchset threading.

thanks
-- PMM

Hi Peter,

Thanks for the heads-up.

The problem with v2 was the SMTP path I used: I sent it via smtp.qq.com,
and that path rewrote the cover letter Message-ID while the patch mails
still kept the original ID in In-Reply-To. That broke the patchset
threading and patchew parsing.

I have now switched my git send-email setup away from smtp.qq.com and will
use Gmail SMTP for future revisions or resends, so the next version should
preserve the thread metadata correctly.

No problem on the review timing given the 11.0 softfreeze. Thanks for
keeping the series on your queue.

Thanks,
Yucai