[Nouveau] [PATCH] drm/nouveau: support for platform devices (original) (raw)
Thierry Reding thierry.reding at gmail.com
Mon Feb 10 03:50:56 PST 2014
- Previous message: [PATCH] drm/nouveau: support for platform devices
- Next message: [Nouveau] [PATCH] drm/nouveau: support for platform devices
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Mon, Feb 10, 2014 at 02:53:00PM +0900, Alexandre Courbot wrote: [...]
diff --git a/drivers/gpu/drm/nouveau/core/engine/device/base.c b/drivers/gpu/drm/nouveau/core/engine/device/base.c [...] +resourcesizet +nvdeviceresourcestart(struct nouveaudevice *device, unsigned int bar) +{ + if (nvdeviceispci(device)) { + return pciresourcestart(device->pdev, bar); + } else { + struct resource *res; + res = platformgetresource(device->platformdev, + IORESOURCEMEM, bar); + if (!res) + return 0; + return res->start; + } +} + +resourcesizet +nvdeviceresourcelen(struct nouveaudevice *device, unsigned int bar) +{ + if (nvdeviceispci(device)) { + return pciresourcelen(device->pdev, bar); + } else { + struct resource *res; + res = platformgetresource(device->platformdev, + IORESOURCEMEM, bar); + if (!res) + return 0; + return resourcesize(res); + } +}
Perhaps instead of these two, something like this could be done:
const struct resource *
nv_device_resource(struct nouveau_device *device, unsigned int bar)
{
if (nv_device_is_pci(device)
return &device->pdev->resource[bar];
else
return platform_get_resource(device->platformdev,
IORESOURCE_MEM, bar);
}
Then the more generic resource_size() can be used directly on the returned struct resource *. Doing so may come in handy if you ever need to display the resource for debugging purposes, since you could simply use the %pR format specifier. It could also be slightly more efficient, since the structure doesn't have to be looked up twice. But perhaps the compiler will be clever enough to optimize that away and it's not like this is called from a hot path.
I do see that pci_resource_len() does additional checking for BARs that have zero size (start == 0 && end == start), so it's not exactly the same, but I think there's another issue with that, see below.
+int +nouveaudeviceplatformcreate(struct platformdevice *pdev, u64 name, + const char *sname, const char *cfg, + const char *dbg, int length, void **pobject) +{ + struct nouveaudevice *device; + int ret = -EEXIST; + + mutexlock(&nvdevicesmutex); + listforeachentry(device, &nvdevices, head) { + if (device->handle == name) + goto done; + } + + ret = nouveauenginecreate(NULL, NULL, &nouveaudeviceoclass, true, + "DEVICE", "device", length, pobject); + device = *pobject; + if (ret) + goto done; + + device->platformdev = pdev; + device->handle = name; + device->cfgopt = cfg; + device->dbgopt = dbg; + device->name = sname; + + nvsubdev(device)->debug = nouveaudbgopt(device->dbgopt, "DEVICE"); + nvengine(device)->sclass = nouveaudevicesclass; + listadd(&device->head, &nvdevices); +done: + mutexunlock(&nvdevicesmutex); + return ret; +}
I think there's some potential for refactoring here, since the only difference that I can spot is in whether the pdev or the platformdev fields are assigned.
diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nv20.c b/drivers/gpu/drm/nouveau/core/engine/graph/nv20.c index b24559315903..d145e080899a 100644 --- a/drivers/gpu/drm/nouveau/core/engine/graph/nv20.c +++ b/drivers/gpu/drm/nouveau/core/engine/graph/nv20.c @@ -349,7 +349,7 @@ nv20graphinit(struct nouveauobject *object) nvwr32(priv, NV10PGRAPHSURFACE, tmp);
/* begin RAM config */ - vramsz = pciresourcelen(nvdevice(priv)->pdev, 0) - 1; + vramsz = nvdeviceresourcelen(nvdevice(priv), 0) - 1;
In case BAR0 is of size zero (start == 0, end == start), this will cause underflow in the case of a PCI device, because pci_resource_len() will return 0. I suspect that this never happens since that code's been there since the dawn of time.
diff --git a/drivers/gpu/drm/nouveau/core/include/core/device.h b/drivers/gpu/drm/nouveau/core/include/core/device.h index 7b8ea221b00d..2a3e24e1d392 100644 --- a/drivers/gpu/drm/nouveau/core/include/core/device.h +++ b/drivers/gpu/drm/nouveau/core/include/core/device.h @@ -65,6 +65,7 @@ struct nouveaudevice { struct listhead head;
struct pcidev *pdev; + struct platformdevice *platformdev;
I'm generally wondering if perhaps a better abstraction would be to store a struct device * here, perhaps with a struct nouveau_device_ops * or similar to abstract away the differences between PCI and platform devices.
nouveau_device_create_() could then take a struct device * and a struct nouveau_device_ops *, and upcasting can therefore be done within these operations, rather than sprinkling nv_device_is_pci() code everywhere.
diff --git a/drivers/gpu/drm/nouveau/nouveauabi16.c b/drivers/gpu/drm/nouveau/nouveauabi16.c [...] case NOUVEAUGETPARAMBUSTYPE: + if (!nvdeviceispci(device)) + getparam->value = 3; + else if (drmpcideviceisagp(dev)) getparam->value = 0; else
This is more of a general note since this patch doesn't introduce the parameter. Perhaps it would be good to expose a symbolic name for the various types of busses in a public header?
diff --git a/drivers/gpu/drm/nouveau/nouveauchan.c b/drivers/gpu/drm/nouveau/nouveauchan.c index cc5152be2cf1..19c6e6c9fc45 100644 --- a/drivers/gpu/drm/nouveau/nouveauchan.c +++ b/drivers/gpu/drm/nouveau/nouveauchan.c @@ -154,7 +154,7 @@ nouveauchannelprep(struct nouveaudrm *drm, struct nouveaucli *cli, * nfi why this exists, it came from the -nv ddx. */ args.flags = NVDMATARGETPCI | NVDMAACCESSRDWR; - args.start = pciresourcestart(device->pdev, 1); + args.start = nvdeviceresourcelen(device, 1);
Should this have been nv_device_resource_start()?
diff --git a/drivers/gpu/drm/nouveau/nouveaudrm.c b/drivers/gpu/drm/nouveau/nouveaudrm.c [...] @@ -345,7 +368,7 @@ nouveaudrmload(struct drmdevice *dev, unsigned long flags) /* make sure AGP controller is in a consistent state before we * (possibly) execute vbios init tables (see nouveauagp.h) */ - if (drmpcideviceisagp(dev) && dev->agp) { + if (pdev && drmpcideviceisagp(dev) && dev->agp) {
Perhaps move the check for valid PCI device into drm_pci_device_is_agp() rather than requiring callers to check explicitly?
@@ -384,8 +407,10 @@ nouveaudrmload(struct drmdevice *dev, unsigned long flags) if (nvdevice(drm->device)->chipset == 0xc1) nvmask(device, 0x00088080, 0x00000800, 0x00000000);
- nouveauvgainit(drm); - nouveauagpinit(drm); + if (pdev) { + nouveauvgainit(drm); + nouveauagpinit(drm); + }
Same here. And if you make the above change, then nouveau_agp_init() will do the right thing already.
if (device->cardtype >= NV50) { ret = nouveauvmnew(nvdevice(drm->device), 0, (1ULL << 40), @@ -398,9 +423,11 @@ nouveaudrmload(struct drmdevice *dev, unsigned long flags) if (ret) goto failttm;
- ret = nouveaubiosinit(dev); - if (ret) - goto failbios; + if (pdev) { + ret = nouveaubiosinit(dev); + if (ret) + goto failbios; + }
nouveau_bios_init() could also check internally and return 0 if the device isn't a PCI device. One less conditional in this function.
@@ -963,6 +991,25 @@ nouveaudrmpcidriver = { .driver.pm = &nouveaupmops, };
+
This adds a spurious newline.
+int nouveaudrmplatformprobe(struct platformdevice *pdev) +{ + struct nouveaudevice *device; + int ret; + + ret = nouveaudeviceplatformcreate(pdev, nouveauplatformname(pdev), + devname(&pdev->dev), nouveauconfig, + nouveaudebug, &device); + + ret = drmplatforminit(&driver, pdev); + if (ret) { + nouveauobjectref(NULL, (struct nouveauobject **)&device); + return ret; + } + + return ret; +}
I think we should move the whole of gk20a probing into nouveau. Keeping one part in tegra-drm and one part in nouveau is confusing, and I can't see a reason why we'd have to keep it that way.
Thierry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140210/089f341e/attachment.pgp>
- Previous message: [PATCH] drm/nouveau: support for platform devices
- Next message: [Nouveau] [PATCH] drm/nouveau: support for platform devices
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]