search for: qxl_num_crtc

qdev->monitors_config->max_allowed is effectively set by the qxl.num_heads module parameter, stored in the qxl_num_crtc variable. Lets get rid of the indirection and use the variable qxl_num_crtc directly. The kernel doesn't need to dereference pointers each time it needs the value, and when reading the code you don't have to trace where and why qdev->monitors_config->max_allowed is set. Signed-off-b...

Skip the pointless and slightly confusing indirection via qdev->monitors_config->max_allowed. Just use qxl_num_crtc instead. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/qxl/qxl_display.c | 25 +++++++++++-------------- 1 file changed, 11 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c index a6110ec5ba..731a17ba...

qdev->monitors_config->max_allowed is effectively set by the qxl.num_heads module parameter, stored in the qxl_num_crtc variable. Lets get rid of the indirection and use the variable qxl_num_crtc directly. The kernel doesn't need to dereference pointers each time it needs the value, and when reading the code you don't have to trace where and why qdev->monitors_config->max_allowed is set. Signed-off-b...

Just use qxl_num_crtc directly everywhere instead of using qdev->monitors_config->max_allowed. Drops pointless indirection and also is less confusing. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/qxl/qxl_display.c | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 d...

On Thu, Dec 06, 2018 at 07:53:10AM -0500, Frediano Ziglio wrote: > > > > On Thu, Dec 06, 2018 at 05:59:25AM -0500, Frediano Ziglio wrote: > > > > > > > > Just use qxl_num_crtc directly everywhere instead of using > > > > qdev->monitors_config->max_allowed. Drops pointless indirection > > > > and also is less confusing. > > > > > > > > > > To me is MORE confusing, why comparing number of something with > &g...

On Thu, Dec 06, 2018 at 05:59:25AM -0500, Frediano Ziglio wrote: > > > > Just use qxl_num_crtc directly everywhere instead of using > > qdev->monitors_config->max_allowed. Drops pointless indirection > > and also is less confusing. > > > > To me is MORE confusing, why comparing number of something with > another number? Previously code was comparing number...

> > qdev->monitors_config->max_allowed is effectively set by a module > > parameter. So using the module parameter variable qxl_num_crtc > > directly is better IMO. The kernel doesn't need to dereference pointers > > each time it needs the value, and when reading the code you don't have > > to trace where and why qdev->monitors_config->max_allowed is set. > > That should go to the commit messa...

...++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c index b57a37543613..fcb48ac60598 100644 --- a/drivers/gpu/drm/qxl/qxl_drv.c +++ b/drivers/gpu/drm/qxl/qxl_drv.c @@ -63,6 +63,11 @@ module_param_named(num_heads, qxl_num_crtc, int, 0400); static struct drm_driver qxl_driver; static struct pci_driver qxl_pci_driver; +static bool is_vga(struct pci_dev *pdev) +{ + return pdev->class == PCI_CLASS_DISPLAY_VGA << 8; +} + static int qxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent) { @@ -87,9...

...user_map.vaddr, size); qxl_bo_kunmap(cursor_bo); qxl_bo_kunmap(user_bo); @@ -1138,6 +1140,7 @@ int qxl_create_monitors_object(struct qxl_device *qdev) { int ret; struct drm_gem_object *gobj; + struct dma_buf_map map; int monitors_config_size = sizeof(struct qxl_monitors_config) + qxl_num_crtc * sizeof(struct qxl_head); @@ -1154,7 +1157,7 @@ int qxl_create_monitors_object(struct qxl_device *qdev) if (ret) return ret; - qxl_bo_kmap(qdev->monitors_config_bo, NULL); + qxl_bo_kmap(qdev->monitors_config_bo, &map); qdev->monitors_config = qdev->monitors_config_bo-&...

...et = qxl_bo_kmap(cursor_bo, &cursor_map); if (ret) goto out_backoff; @@ -1133,6 +1137,7 @@ int qxl_create_monitors_object(struct qxl_device *qdev) { int ret; struct drm_gem_object *gobj; + struct dma_buf_map map; int monitors_config_size = sizeof(struct qxl_monitors_config) + qxl_num_crtc * sizeof(struct qxl_head); @@ -1149,7 +1154,7 @@ int qxl_create_monitors_object(struct qxl_device *qdev) if (ret) return ret; - qxl_bo_kmap(qdev->monitors_config_bo, NULL); + qxl_bo_kmap(qdev->monitors_config_bo, &map); qdev->monitors_config = qdev->monitors_config_bo-&...

...(ret) > goto out_backoff; > > @@ -1133,6 +1137,7 @@ int qxl_create_monitors_object(struct qxl_device *qdev) > { > int ret; > struct drm_gem_object *gobj; > + struct dma_buf_map map; > int monitors_config_size = sizeof(struct qxl_monitors_config) + > qxl_num_crtc * sizeof(struct qxl_head); > > @@ -1149,7 +1154,7 @@ int qxl_create_monitors_object(struct qxl_device *qdev) > if (ret) > return ret; > > - qxl_bo_kmap(qdev->monitors_config_bo, NULL); > + qxl_bo_kmap(qdev->monitors_config_bo, &map); > > qdev-...

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use