Re: [PATCH v2] hw/display/tcx: Mark the VRAM dirty upon reset

[Peter Maydell <peter.maydell@linaro.org>]

On Sun, 6 Feb 2022 at 09:30, Mark Cave-Ayland
<mark.cave-ayland@ilande.co.uk> wrote:
>
> On 05/02/2022 15:39, Peter Maydell wrote:
> > The handling of the vram buffer seems weird in this device overall,
> > though -- the memory block is divided into three parts
> >   * main vram, one byte per pixel
> >   * vram24, four bytes per pixel
> >   * cplane, four bytes per pixel
> >
> > As far as I can see, only if depth=24 (fixed at device creation
> > time) do we use the vram24 and cplane parts. But we create the
> > memory block at the same size regardless of depth and we expose
> > the vram24 and cplane parts to the guest as sysbus MMIO regions
> > that are mapped into guest memory regardless of depth...
>
> (goes and looks)
>
> It does look a bit odd certainly. Without Blue Swirl being around all I can only
> guess as to why everything is configured to use an alias onto a single VRAM memory
> region :/
>
> As for exposing the vram24 and cplane parts, I don't think it matters since 24-bit
> mode is clearly designed to be backwards compatible with 8-bit mode. During
> initialisation OpenBIOS reads the colour depth using the fw_cfg interface and adds
> the registers for that mode into the DT as required so the correct information is
> exposed to the guest.

A guest won't notice if we expose stuff to it that it doesn't expect
to be there -- but if the 8-bit-only device is not supposed to have
those memory regions we shouldn't be creating them...

-- PMM