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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux