| Message ID | 20201124113824.19994-15-tzimmermann@suse.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm: Move struct drm_device.pdev to legacy | expand |
> On Nov 24, 2020, at 06:38, Thomas Zimmermann <tzimmermann@suse.de> wrote: > > Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct > drm_device.dev. No functional changes. > > Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> > Cc: Roland Scheidegger <sroland@vmware.com> > --- > drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 8 ++++---- > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 27 +++++++++++++------------- > drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 2 +- Reviewed-by: Zack Rusin <zackr@vmware.com> z
Hi Am 30.11.20 um 21:59 schrieb Zack Rusin: > > >> On Nov 24, 2020, at 06:38, Thomas Zimmermann <tzimmermann@suse.de> wrote: >> >> Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct >> drm_device.dev. No functional changes. >> >> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> >> Cc: Roland Scheidegger <sroland@vmware.com> >> --- >> drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 8 ++++---- >> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 27 +++++++++++++------------- >> drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 2 +- > > Reviewed-by: Zack Rusin <zackr@vmware.com> Could you add this patch to the vmwgfx tree? Best regards Thomas > > z >
Hi Am 02.12.20 um 09:01 schrieb Thomas Zimmermann: > Hi > > Am 30.11.20 um 21:59 schrieb Zack Rusin: >> >> >>> On Nov 24, 2020, at 06:38, Thomas Zimmermann <tzimmermann@suse.de> >>> wrote: >>> >>> Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct >>> drm_device.dev. No functional changes. >>> >>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> >>> Cc: Roland Scheidegger <sroland@vmware.com> >>> --- >>> drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 8 ++++---- >>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 27 +++++++++++++------------- >>> drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 2 +- >> >> Reviewed-by: Zack Rusin <zackr@vmware.com> > > Could you add this patch to the vmwgfx tree? AMD devs indicated that they'd prefer to merge the patchset trough drm-misc-next. If you're OK with that, I'd merge the vmwgfx patch through drm-misc-next as well. Best regards Thomas > > Best regards > Thomas > >> >> z >> > > > _______________________________________________ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau >
> On Dec 2, 2020, at 09:27, Thomas Zimmermann <tzimmermann@suse.de> wrote: > > Hi > > Am 02.12.20 um 09:01 schrieb Thomas Zimmermann: >> Hi >> Am 30.11.20 um 21:59 schrieb Zack Rusin: >>> >>> >>>> On Nov 24, 2020, at 06:38, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>>> >>>> Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct >>>> drm_device.dev. No functional changes. >>>> >>>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> >>>> Cc: Roland Scheidegger <sroland@vmware.com> >>>> --- >>>> drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 8 ++++---- >>>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 27 +++++++++++++------------- >>>> drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 2 +- >>> >>> Reviewed-by: Zack Rusin <zackr@vmware.com> >> Could you add this patch to the vmwgfx tree? > > AMD devs indicated that they'd prefer to merge the patchset trough drm-misc-next. If you're OK with that, I'd merge the vmwgfx patch through drm-misc-next as well. Sounds good. I’ll make sure to rebase our latest patch set on top of it when it’s in. Thanks! z
On Wed, Dec 2, 2020 at 4:37 PM Zack Rusin <zackr@vmware.com> wrote: > > > > > On Dec 2, 2020, at 09:27, Thomas Zimmermann <tzimmermann@suse.de> wrote: > > > > Hi > > > > Am 02.12.20 um 09:01 schrieb Thomas Zimmermann: > >> Hi > >> Am 30.11.20 um 21:59 schrieb Zack Rusin: > >>> > >>> > >>>> On Nov 24, 2020, at 06:38, Thomas Zimmermann <tzimmermann@suse.de> wrote: > >>>> > >>>> Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct > >>>> drm_device.dev. No functional changes. > >>>> > >>>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> > >>>> Cc: Roland Scheidegger <sroland@vmware.com> > >>>> --- > >>>> drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 8 ++++---- > >>>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 27 +++++++++++++------------- > >>>> drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 2 +- > >>> > >>> Reviewed-by: Zack Rusin <zackr@vmware.com> > >> Could you add this patch to the vmwgfx tree? > > > > AMD devs indicated that they'd prefer to merge the patchset trough drm-misc-next. If you're OK with that, I'd merge the vmwgfx patch through drm-misc-next as well. > > Sounds good. I’ll make sure to rebase our latest patch set on top of it when it’s in. Thanks! btw if you want to avoid multi-tree coordination headaches, we can also manage vmwgfx in drm-misc and give you & Roland commit rights there. Up to you. There is some scripting involved for now (but I hope whenever we move to gitlab we could do the checks server-side): https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html Cheers, Daniel
> On Dec 2, 2020, at 11:03, Daniel Vetter <daniel@ffwll.ch> wrote: > > On Wed, Dec 2, 2020 at 4:37 PM Zack Rusin <zackr@vmware.com> wrote: >> >> >> >>> On Dec 2, 2020, at 09:27, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>> >>> Hi >>> >>> Am 02.12.20 um 09:01 schrieb Thomas Zimmermann: >>>> Hi >>>> Am 30.11.20 um 21:59 schrieb Zack Rusin: >>>>> >>>>> >>>>>> On Nov 24, 2020, at 06:38, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>>>>> >>>>>> Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct >>>>>> drm_device.dev. No functional changes. >>>>>> >>>>>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> >>>>>> Cc: Roland Scheidegger <sroland@vmware.com> >>>>>> --- >>>>>> drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 8 ++++---- >>>>>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 27 +++++++++++++------------- >>>>>> drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 2 +- >>>>> >>>>> Reviewed-by: Zack Rusin <zackr@vmware.com> >>>> Could you add this patch to the vmwgfx tree? >>> >>> AMD devs indicated that they'd prefer to merge the patchset trough drm-misc-next. If you're OK with that, I'd merge the vmwgfx patch through drm-misc-next as well. >> >> Sounds good. I’ll make sure to rebase our latest patch set on top of it when it’s in. Thanks! > > btw if you want to avoid multi-tree coordination headaches, we can > also manage vmwgfx in drm-misc and give you & Roland commit rights > there. Up to you. There is some scripting involved for now (but I hope > whenever we move to gitlab we could do the checks server-side): I’d be happy to take you up on that. I would like to move a lot more of our development into public repos and reducing the burden of maintaining multiple trees would help. Is there a lot of changes to drm core that doesn’t go through drm-misc? Or alternatively is drm-misc often pulling from Linus’ master? I’m trying to figure out how much would our need to rebase/merge be reduced if we just used drm-misc-next/drm-misc-fixes because that would also allow me to point some internal testing infrastructure at it as well. z
On Thu, Dec 03, 2020 at 03:06:20AM +0000, Zack Rusin wrote: > > > > On Dec 2, 2020, at 11:03, Daniel Vetter <daniel@ffwll.ch> wrote: > > > > On Wed, Dec 2, 2020 at 4:37 PM Zack Rusin <zackr@vmware.com> wrote: > >> > >> > >> > >>> On Dec 2, 2020, at 09:27, Thomas Zimmermann <tzimmermann@suse.de> wrote: > >>> > >>> Hi > >>> > >>> Am 02.12.20 um 09:01 schrieb Thomas Zimmermann: > >>>> Hi > >>>> Am 30.11.20 um 21:59 schrieb Zack Rusin: > >>>>> > >>>>> > >>>>>> On Nov 24, 2020, at 06:38, Thomas Zimmermann <tzimmermann@suse.de> wrote: > >>>>>> > >>>>>> Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct > >>>>>> drm_device.dev. No functional changes. > >>>>>> > >>>>>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> > >>>>>> Cc: Roland Scheidegger <sroland@vmware.com> > >>>>>> --- > >>>>>> drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 8 ++++---- > >>>>>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 27 +++++++++++++------------- > >>>>>> drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 2 +- > >>>>> > >>>>> Reviewed-by: Zack Rusin <zackr@vmware.com> > >>>> Could you add this patch to the vmwgfx tree? > >>> > >>> AMD devs indicated that they'd prefer to merge the patchset trough drm-misc-next. If you're OK with that, I'd merge the vmwgfx patch through drm-misc-next as well. > >> > >> Sounds good. I’ll make sure to rebase our latest patch set on top of it when it’s in. Thanks! > > > > btw if you want to avoid multi-tree coordination headaches, we can > > also manage vmwgfx in drm-misc and give you & Roland commit rights > > there. Up to you. There is some scripting involved for now (but I hope > > whenever we move to gitlab we could do the checks server-side): > > I’d be happy to take you up on that. I would like to move a lot more of > our development into public repos and reducing the burden of maintaining > multiple trees would help. Is there a lot of changes to drm core that > doesn’t go through drm-misc? Or alternatively is drm-misc often pulling > from Linus’ master? I’m trying to figure out how much would our need to > rebase/merge be reduced if we just used drm-misc-next/drm-misc-fixes > because that would also allow me to point some internal testing > infrastructure at it as well. I think nowadays pretty much all the cross-driver work lands through drm-misc. Exception is just new stuff that's only used by a single driver. For testing there's also drm-tip, which tries to pull it all together (but you might still want to point your CI at branches). Also note that drm-misc-next doesn't have a merge window freeze period (with have the drm-misc-next-fixes branch during that time for merge window fixes), so you can treat it like a main development branch like e.g. in mesa, with the -fixes branches as the release branches. Only difference is that we don't cherry pick patches from the main branch to the release branches (at least not as the normal flow). If you do need a backmerge for patches from Linus to drm-misc-next because of some feature work (or conflicts with other stuff in general) drm-misc maintainers do that. Usually happens every few weeks. -Daniel
> On Dec 3, 2020, at 10:12, Daniel Vetter <daniel@ffwll.ch> wrote: > > On Thu, Dec 03, 2020 at 03:06:20AM +0000, Zack Rusin wrote: >> >> >>> On Dec 2, 2020, at 11:03, Daniel Vetter <daniel@ffwll.ch> wrote: >>> >>> On Wed, Dec 2, 2020 at 4:37 PM Zack Rusin <zackr@vmware.com> wrote: >>>> >>>> >>>> >>>>> On Dec 2, 2020, at 09:27, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>>>> >>>>> Hi >>>>> >>>>> Am 02.12.20 um 09:01 schrieb Thomas Zimmermann: >>>>>> Hi >>>>>> Am 30.11.20 um 21:59 schrieb Zack Rusin: >>>>>>> >>>>>>> >>>>>>>> On Nov 24, 2020, at 06:38, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>>>>>>> >>>>>>>> Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct >>>>>>>> drm_device.dev. No functional changes. >>>>>>>> >>>>>>>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> >>>>>>>> Cc: Roland Scheidegger <sroland@vmware.com> >>>>>>>> --- >>>>>>>> drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 8 ++++---- >>>>>>>> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 27 +++++++++++++------------- >>>>>>>> drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 2 +- >>>>>>> >>>>>>> Reviewed-by: Zack Rusin <zackr@vmware.com> >>>>>> Could you add this patch to the vmwgfx tree? >>>>> >>>>> AMD devs indicated that they'd prefer to merge the patchset trough drm-misc-next. If you're OK with that, I'd merge the vmwgfx patch through drm-misc-next as well. >>>> >>>> Sounds good. I’ll make sure to rebase our latest patch set on top of it when it’s in. Thanks! >>> >>> btw if you want to avoid multi-tree coordination headaches, we can >>> also manage vmwgfx in drm-misc and give you & Roland commit rights >>> there. Up to you. There is some scripting involved for now (but I hope >>> whenever we move to gitlab we could do the checks server-side): >> >> I’d be happy to take you up on that. I would like to move a lot more of >> our development into public repos and reducing the burden of maintaining >> multiple trees would help. Is there a lot of changes to drm core that >> doesn’t go through drm-misc? Or alternatively is drm-misc often pulling >> from Linus’ master? I’m trying to figure out how much would our need to >> rebase/merge be reduced if we just used drm-misc-next/drm-misc-fixes >> because that would also allow me to point some internal testing >> infrastructure at it as well. > > I think nowadays pretty much all the cross-driver work lands through > drm-misc. Exception is just new stuff that's only used by a single driver. > > For testing there's also drm-tip, which tries to pull it all together (but > you might still want to point your CI at branches). > > Also note that drm-misc-next doesn't have a merge window freeze period > (with have the drm-misc-next-fixes branch during that time for merge > window fixes), so you can treat it like a main development branch like > e.g. in mesa, with the -fixes branches as the release branches. Only > difference is that we don't cherry pick patches from the main branch to > the release branches (at least not as the normal flow). > > If you do need a backmerge for patches from Linus to drm-misc-next because > of some feature work (or conflicts with other stuff in general) drm-misc > maintainers do that. Usually happens every few weeks. Perfect, thanks a lot! This has been something I wanted our driver to do for a while, I’ll go ahead and switch our internal dev to drm-misc. z
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c index 9a9fe10d829b..83a8d34704ea 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c @@ -1230,7 +1230,7 @@ int vmw_cmdbuf_set_pool_size(struct vmw_cmdbuf_man *man, /* First, try to allocate a huge chunk of DMA memory */ size = PAGE_ALIGN(size); - man->map = dma_alloc_coherent(&dev_priv->dev->pdev->dev, size, + man->map = dma_alloc_coherent(dev_priv->dev->dev, size, &man->handle, GFP_KERNEL); if (man->map) { man->using_mob = false; @@ -1313,7 +1313,7 @@ struct vmw_cmdbuf_man *vmw_cmdbuf_man_create(struct vmw_private *dev_priv) man->num_contexts = (dev_priv->capabilities & SVGA_CAP_HP_CMD_QUEUE) ? 2 : 1; man->headers = dma_pool_create("vmwgfx cmdbuf", - &dev_priv->dev->pdev->dev, + dev_priv->dev->dev, sizeof(SVGACBHeader), 64, PAGE_SIZE); if (!man->headers) { @@ -1322,7 +1322,7 @@ struct vmw_cmdbuf_man *vmw_cmdbuf_man_create(struct vmw_private *dev_priv) } man->dheaders = dma_pool_create("vmwgfx inline cmdbuf", - &dev_priv->dev->pdev->dev, + dev_priv->dev->dev, sizeof(struct vmw_cmdbuf_dheader), 64, PAGE_SIZE); if (!man->dheaders) { @@ -1387,7 +1387,7 @@ void vmw_cmdbuf_remove_pool(struct vmw_cmdbuf_man *man) ttm_bo_put(man->cmd_space); man->cmd_space = NULL; } else { - dma_free_coherent(&man->dev_priv->dev->pdev->dev, + dma_free_coherent(man->dev_priv->dev->dev, man->size, man->map, man->handle); } } diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c index 216daf93022c..e63e08f5b14f 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c @@ -652,6 +652,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned long chipset) enum vmw_res_type i; bool refuse_dma = false; char host_log[100] = {0}; + struct pci_dev *pdev = to_pci_dev(dev->dev); dev_priv = kzalloc(sizeof(*dev_priv), GFP_KERNEL); if (unlikely(!dev_priv)) { @@ -659,7 +660,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned long chipset) return -ENOMEM; } - pci_set_master(dev->pdev); + pci_set_master(pdev); dev_priv->dev = dev; dev_priv->vmw_chipset = chipset; @@ -688,9 +689,9 @@ static int vmw_driver_load(struct drm_device *dev, unsigned long chipset) dev_priv->used_memory_size = 0; - dev_priv->io_start = pci_resource_start(dev->pdev, 0); - dev_priv->vram_start = pci_resource_start(dev->pdev, 1); - dev_priv->mmio_start = pci_resource_start(dev->pdev, 2); + dev_priv->io_start = pci_resource_start(pdev, 0); + dev_priv->vram_start = pci_resource_start(pdev, 1); + dev_priv->mmio_start = pci_resource_start(pdev, 2); dev_priv->assume_16bpp = !!vmw_assume_16bpp; @@ -840,7 +841,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned long chipset) dev->dev_private = dev_priv; - ret = pci_request_regions(dev->pdev, "vmwgfx probe"); + ret = pci_request_regions(pdev, "vmwgfx probe"); dev_priv->stealth = (ret != 0); if (dev_priv->stealth) { /** @@ -849,7 +850,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned long chipset) DRM_INFO("It appears like vesafb is loaded. " "Ignore above error if any.\n"); - ret = pci_request_region(dev->pdev, 2, "vmwgfx stealth probe"); + ret = pci_request_region(pdev, 2, "vmwgfx stealth probe"); if (unlikely(ret != 0)) { DRM_ERROR("Failed reserving the SVGA MMIO resource.\n"); goto out_no_device; @@ -857,7 +858,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned long chipset) } if (dev_priv->capabilities & SVGA_CAP_IRQMASK) { - ret = vmw_irq_install(dev, dev->pdev->irq); + ret = vmw_irq_install(dev, pdev->irq); if (ret != 0) { DRM_ERROR("Failed installing irq: %d\n", ret); goto out_no_irq; @@ -1003,9 +1004,9 @@ static int vmw_driver_load(struct drm_device *dev, unsigned long chipset) vmw_irq_uninstall(dev_priv->dev); out_no_irq: if (dev_priv->stealth) - pci_release_region(dev->pdev, 2); + pci_release_region(pdev, 2); else - pci_release_regions(dev->pdev); + pci_release_regions(pdev); out_no_device: ttm_object_device_release(&dev_priv->tdev); out_err4: @@ -1023,6 +1024,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned long chipset) static void vmw_driver_unload(struct drm_device *dev) { struct vmw_private *dev_priv = vmw_priv(dev); + struct pci_dev *pdev = to_pci_dev(dev->dev); enum vmw_res_type i; unregister_pm_notifier(&dev_priv->pm_nb); @@ -1054,9 +1056,9 @@ static void vmw_driver_unload(struct drm_device *dev) if (dev_priv->capabilities & SVGA_CAP_IRQMASK) vmw_irq_uninstall(dev_priv->dev); if (dev_priv->stealth) - pci_release_region(dev->pdev, 2); + pci_release_region(pdev, 2); else - pci_release_regions(dev->pdev); + pci_release_regions(pdev); ttm_object_device_release(&dev_priv->tdev); memunmap(dev_priv->mmio_virt); @@ -1409,7 +1411,7 @@ static int vmw_pm_freeze(struct device *kdev) vmw_fence_fifo_down(dev_priv->fman); __vmw_svga_disable(dev_priv); - + vmw_release_device_late(dev_priv); return 0; } @@ -1520,7 +1522,6 @@ static int vmw_probe(struct pci_dev *pdev, const struct pci_device_id *ent) goto err_pci_disable_device; } - dev->pdev = pdev; pci_set_drvdata(pdev, dev); ret = vmw_driver_load(dev, ent->driver_data); diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c index 4d60201037d1..a244b6c3e5a1 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c @@ -638,7 +638,7 @@ static const struct fb_ops vmw_fb_ops = { int vmw_fb_init(struct vmw_private *vmw_priv) { - struct device *device = &vmw_priv->dev->pdev->dev; + struct device *device = vmw_priv->dev->dev; struct vmw_fb_par *par; struct fb_info *info; unsigned fb_width, fb_height;
Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct drm_device.dev. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Roland Scheidegger <sroland@vmware.com> --- drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 8 ++++---- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 27 +++++++++++++------------- drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 2 +- 3 files changed, 19 insertions(+), 18 deletions(-)