[RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device

[Deepak Rawat]

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
>