dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Zack Rusin <zackr@vmware.com>
To: "dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"tzimmermann@suse.de" <tzimmermann@suse.de>
Cc: Martin Krastev <krastevm@vmware.com>,
	Michael Banack <banackm@vmware.com>,
	Maaz Mombasawala <mombasawalam@vmware.com>
Subject: Re: [PATCH v2 13/16] drm/vmwgfx: Port the framebuffer code to drm fb helpers
Date: Thu, 20 Oct 2022 18:37:29 +0000	[thread overview]
Message-ID: <737c5dd5e6593e43e5b6cd1aaf4d8a939756ec7c.camel@vmware.com> (raw)
In-Reply-To: <dce8c2de-0e2c-0b99-e30f-29411e8d6908@suse.de>

On Thu, 2022-10-20 at 11:06 +0200, Thomas Zimmermann wrote:
> Hi Zack
> 
> Am 20.10.22 um 05:41 schrieb Zack Rusin:
> > From: Zack Rusin <zackr@vmware.com>
> [...]
> > @@ -1670,6 +1640,10 @@ static int vmw_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> >   	if (ret)
> >   		goto out_unload;
> >   
> > +	vmw_fifo_resource_inc(vmw);
> > +	vmw_svga_enable(vmw);
> > +	drm_fbdev_generic_setup(&vmw->drm,  vmw->assume_16bpp ? 16 : 32);
> 
> The preferred way of setting the color depth is with struct 
> drm_mode_config.preferred_depth. [1] Note that it is the color depth; 
> not the pixel size. In your case:
> 
> if (vmw->assume_16bpp)
> 	dev->mode_config.preferred_depth = 16;
> else
> 	dev->mode_config.preferred_depth = 24;
> 
> It's also a hint to userspace. [2]
> 
> The prefer_bpp parameter of drm_fbdev_generic_setup() should be 0. It is 
> a fallback to force a certain pixel size, as preferred_depth fails.
> 

Ah, that makes sense. I'll fix that, btw, the dev->mode_config.preferred_depth = 24
part, we should probably have some check in drm_fbdev_generic_setup that it is not
24. 

That's because 24 will invoke the buggy code in drm fbdev helpers that confuses
depth and bpp and will endup invoking dumb create with args->bpp == 24 and that's
specifically disallowed for dumb_create. IGT's has explicit
(dumb_buffer::invalid_bpp) test that checks whether dumb_create with bpp == 24
fails. An earlier commit in this series actually fixes that specific test in vmwgfx.
A lot of drivers will work because even though they set preferred_depth to 24, they
call the  dev->mode_config.preferred_depth = 24 call drm_fbdev_generic_setup with 32
but it's definitely confusing.

> 
> > +
> >   	vmw_debugfs_gem_init(vmw);
> >   	vmw_debugfs_resource_managers_init(vmw);
> >   
> [...]
> > -
> > -/**
> > - * vmw_fb_dirty_flush - flush dirty regions to the kms framebuffer
> > - *
> > - * @work: The struct work_struct associated with this task.
> > - *
> > - * This function flushes the dirty regions of the vmalloc framebuffer to the
> > - * kms framebuffer, and if the kms framebuffer is visible, also updated the
> > - * corresponding displays. Note that this function runs even if the kms
> > - * framebuffer is not bound to a crtc and thus not visible, but it's turned
> > - * off during hibernation using the par->dirty.active bool.
> > - */
> > -static void vmw_fb_dirty_flush(struct work_struct *work)
> 
> This is the flush function for vmwgfx' deferred I/O. If you want to 
> implement deferred I/O with the generic fbdev emulation, you have to set 
> struct drm_mode_config.prefer_shadow_fbdev to true. [3]

Yea, we don't need it anymore. But it probably is a good idea to preserve the old
behaviour for systems that didn't have guest backed memory support. I'll adjust
that. Thanks for taking a look at this!

z

  reply	other threads:[~2022-10-20 18:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-20  3:41 [PATCH v2 00/16] drm/vmwgfx: fb, cursors and hashtable refactor Zack Rusin
2022-10-20  3:41 ` [PATCH v2 01/16] drm/vmwgfx: Write the driver id registers Zack Rusin
2022-10-20  3:41 ` [PATCH v2 02/16] drm/vmwgfx: Fix frame-size warning in vmw_mksstat_add_ioctl Zack Rusin
2022-10-20  3:41 ` [PATCH v2 03/16] drm/vmwgfx: Refactor resource manager's hashtable to use linux/hashtable implementation Zack Rusin
2022-10-20  3:41 ` [PATCH v2 04/16] drm/vmwgfx: Remove ttm object hashtable Zack Rusin
2022-10-20  3:41 ` [PATCH v2 05/16] drm/vmwgfx: Refactor resource validation hashtable to use linux/hashtable implementation Zack Rusin
2022-10-20  3:41 ` [PATCH v2 06/16] drm/vmwgfx: Clean up cursor mobs Zack Rusin
2022-10-20  3:41 ` [PATCH v2 07/16] drm/vmwgfx: Start diffing new mob cursors against old ones Zack Rusin
2022-10-20  3:41 ` [PATCH v2 08/16] drm/vmwgfx: Support cursor surfaces with mob cursor Zack Rusin
2022-10-20  3:41 ` [PATCH v2 09/16] drm/vmwgfx: Diff cursors when using cmds Zack Rusin
2022-10-20  3:41 ` [PATCH v2 10/16] drm/vmwgfx: Refactor ttm reference object hashtable to use linux/hashtable Zack Rusin
2022-10-20  3:41 ` [PATCH v2 11/16] drm/vmwgfx: Remove vmwgfx_hashtab Zack Rusin
2022-10-20  3:41 ` [PATCH v2 12/16] drm/vmwgfx: Do not allow invalid bpp's for dumb buffers Zack Rusin
2022-10-20  3:41 ` [PATCH v2 13/16] drm/vmwgfx: Port the framebuffer code to drm fb helpers Zack Rusin
2022-10-20  9:06   ` Thomas Zimmermann
2022-10-20 18:37     ` Zack Rusin [this message]
2022-10-21  7:06       ` Thomas Zimmermann
2022-10-20  3:41 ` [PATCH v2 14/16] drm/vmwgfx: Remove explicit and broken vblank handling Zack Rusin
2022-10-20  3:41 ` [PATCH v2 15/16] drm/vmwgfx: Add a mksstat counter for cotable resizes Zack Rusin
2022-10-20  3:41 ` [PATCH v2 16/16] drm/vmwgfx: Optimize initial sizes of cotables Zack Rusin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=737c5dd5e6593e43e5b6cd1aaf4d8a939756ec7c.camel@vmware.com \
    --to=zackr@vmware.com \
    --cc=banackm@vmware.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=krastevm@vmware.com \
    --cc=mombasawalam@vmware.com \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox