[RFC PATCH 1/2] drm/hyperv: Add DRM driver for hyperv synthetic video device
Daniel Vetter
daniel at ffwll.ch
Tue Jun 23 09:42:25 UTC 2020
On Mon, Jun 22, 2020 at 03:20:34PM -0700, Deepak Rawat wrote:
> 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.
I think that needs a very big comment. Maybe even enforce that with a
"vram_gpa_set" boolean in the device structure, and complain if we try to
do that twice.
Also I guess congrats to microsoft for defining things like that :-/
-Daniel
>
> >
> > 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the dri-devel
mailing list