On Mon, 2020-06-22 at 14:46 +0200, Gerd Hoffmann wrote:
> Hi,
>
> > +/* Should be done only once during init and resume */
> > +static int synthvid_update_vram_location(struct hv_device *hdev,
> > + phys_addr_t vram_pp)
> > +{
> > + struct hyperv_device *hv = hv_get_drvdata(hdev);
> > + struct synthvid_msg *msg = (struct synthvid_msg *)hv->init_buf;
> > + unsigned long t;
> > + int ret = 0;
> > +
> > + memset(msg, 0, sizeof(struct synthvid_msg));
> > + msg->vid_hdr.type = SYNTHVID_VRAM_LOCATION;
> > + msg->vid_hdr.size = sizeof(struct synthvid_msg_hdr) +
> > + sizeof(struct synthvid_vram_location);
> > + msg->vram.user_ctx = msg->vram.vram_gpa = vram_pp;
> > + msg->vram.is_vram_gpa_specified = 1;
> > + synthvid_send(hdev, msg);
>
> That suggests it is possible to define multiple framebuffers in vram,
> then pageflip by setting vram.vram_gpa. If that is the case I'm
> wondering whenever vram helpers are a better fit maybe? You don't
> have
> to blit each and every display update then.
Thanks for the review. Unfortunately only the first vmbus message take
effect and subsequent calls are ignored. I originally implemented using
vram helpers but I figured out calling this vmbus message again won't
change the vram location.
>
> FYI: cirrus goes the blit route because (a) the amount of vram is
> very
> small so trying to store multiple framebuffers there is out of
> question,
> and (b) cirrus converts formats on the fly to hide some hardware
> oddities.
>
> take care,
> Gerd
>
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
