search for: nv_devices

Since the original merge of nouveau to upstream kernel, we were assuming that nv90 (and later) cards have 32 lines. Based on mmio traces of the binary driver, as well as PBUS error messages during read/write of the e070/e074 registers, we can conclude that nv92 has only 16 lines whereas nv94 (and later) cards have 32. Reported-and-tested-by: David M. Lloyd <david.lloyd at redhat.com>

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drivers/gpu/drm/nouveau/nouveau_connector.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.h b/drivers/gpu/drm/nouveau/nouveau_connector.h index 6e399aa..4cefce3 100644 --- a/drivers/gpu/drm/nouveau/nouveau_connector.h +++ b/drivers/gpu/drm/nouveau/nouveau_connector.h @@ -107,7 +107,4

Op 15-07-13 08:05, Ben Skeggs schreef: > On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst > <maarten.lankhorst at canonical.com> wrote: >> I have no idea what this bogus restriction on placement is, but it breaks decoding 1080p >> VDPAU at boot speed. With this patch applied I only need to bump the vdec clock to >> get real-time 1080p decoding. It prevents a lot of

...gt;pdev->irq; + } else { + return platform_get_irq_byname(device->platformdev, + stall ? "stall" : "nonstall"); + } +} + static struct nouveau_oclass nouveau_device_oclass = { .handle = NV_ENGINE(DEVICE, 0x00), @@ -489,3 +555,37 @@ done: mutex_unlock(&nv_devices_mutex); return ret; } + +int +nouveau_device_platform_create_(struct platform_device *pdev, u64 name, + const char *sname, const char *cfg, + const char *dbg, int length, void **pobject) +{ + struct nouveau_device *device; + int ret = -EEXIST; + + mutex_lock(&nv_devices_mutex); + list_...

The values are already stored on chipset specific basis in the ctor. Make the most of them and simplify the code further by using a temporary variable to avoid code duplication. Signed-off-by: Emil Velikov <emil.l.velikov at gmail.com> --- Found this patch laying around in a local branch. While the it does not reduce the number of lines, I believe that it makes the code is alot more

I have no idea what this bogus restriction on placement is, but it breaks decoding 1080p VDPAU at boot speed. With this patch applied I only need to bump the vdec clock to get real-time 1080p decoding. It prevents a lot of VRAM <-> VRAM buffer moves. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c

Some registers were not initialized in init, this causes them to be uninitialized after suspend. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c b/drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c index bcca883..7288940 100644 --- a/drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c +++

Upcoming mobile Kepler GPUs (such as GK20A) use the platform bus instead of PCI to which Nouveau is tightly dependent. This patch allows Nouveau to handle platform devices by: - abstracting PCI-dependent functions that were typically used for resource querying and page mapping, - introducing a nv_device_is_pci() function that allows to make PCI-dependent code conditional, - providing a

...name, >> + const char *sname, const char *cfg, >> + const char *dbg, int length, void **pobject) >> +{ >> + struct nouveau_device *device; >> + int ret = -EEXIST; >> + >> + mutex_lock(&nv_devices_mutex); >> + list_for_each_entry(device, &nv_devices, head) { >> + if (device->handle == name) >> + goto done; >> + } >> + >> + ret = nouveau_engine_create_(NULL, NULL, &nouveau_device_oclass, true, >>...

Op 04-09-13 03:24, Ben Skeggs schreef: > On Mon, Jul 15, 2013 at 6:39 PM, Maarten Lankhorst > <maarten.lankhorst at canonical.com> wrote: >> Op 15-07-13 08:05, Ben Skeggs schreef: >>> On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst >>> <maarten.lankhorst at canonical.com> wrote: >>>> I have no idea what this bogus restriction on placement

On 12/02/14 05:38, Alexandre Courbot wrote: > Upcoming mobile Kepler GPUs (such as GK20A) use the platform bus instead > of PCI to which Nouveau is tightly dependent. This patch allows Nouveau > to handle platform devices by: > > - abstracting PCI-dependent functions that were typically used for > resource querying and page mapping, > - introducing a nv_device_is_pci()

...below. > +int > +nouveau_device_platform_create_(struct platform_device *pdev, u64 name, > + const char *sname, const char *cfg, > + const char *dbg, int length, void **pobject) > +{ > + struct nouveau_device *device; > + int ret = -EEXIST; > + > + mutex_lock(&nv_devices_mutex); > + list_for_each_entry(device, &nv_devices, head) { > + if (device->handle == name) > + goto done; > + } > + > + ret = nouveau_engine_create_(NULL, NULL, &nouveau_device_oclass, true, > + "DEVICE", "device", length, pobject); &...

The T124 generation of Tegra GPUs uses the Kepler architecture and can thus be driven by Nouveau. However, they are declared as platform devices using the Device Tree, and Nouveau has a very strong dependency on PCI. This patch makes Nouveau core able to handle platform devices as well as PCI devices. Commonly-used PCI functions include resource range query and page mapping. These functions are

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76319 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- It's unclear to me whether GF11x devices actually support this, but the disp "split" is at nvd0, so I went with that. The marketing docs are fairly unclear. However most of them don't actually have DP in the first place, so it may not be a huge issue. I

From: Maarten Lankhorst <maarten.lankhorst at canonical.com> Map the GART to the bar and use that mapping, to hide all the tiling details from users. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/core/subdev/bar/nv50.c | 5 ++++- drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c | 5 ++++- drivers/gpu/drm/nouveau/nouveau_bo.c

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drivers/gpu/drm/nouveau/core/engine/graph/nv40.h | 3 +++ drivers/gpu/drm/nouveau/core/subdev/instmem/nv40.c | 10 ++-------- 2 files changed, 5 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nv40.h b/drivers/gpu/drm/nouveau/core/engine/graph/nv40.h index 7da35a4..ad82093 100644 ---

The blob does not seem to write at that place for my NVAC, though it does for my NV96, agreeing with what is done in the if/else structure below. I guess someone forgot to remove the line when the if/else was put in place. Signed-off-by: Pierre Moreau <pierre.morrow at free.fr> --- drivers/gpu/drm/nouveau/core/engine/graph/nv50.c | 1 - 1 file changed, 1 deletion(-) diff --git

On Sat, Feb 1, 2014 at 1:16 PM, Alexandre Courbot <acourbot at nvidia.com> wrote: > Adapt the NVC0 BAR driver to make it able to support chips that do not > expose a BAR3. When this happens, BAR1 is then used for USERD mapping > and the BAR alloc() functions is disabled, making GPU objects unable > to rely on BAR for data access and falling back to PRAMIN. > >

On Mon, Aug 12, 2013 at 6:43 AM, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: > Some registers were not initialized in init, this causes them to be > uninitialized after suspend. > > Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> > --- > diff --git a/drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c

On Mon, Jul 15, 2013 at 6:39 PM, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: > Op 15-07-13 08:05, Ben Skeggs schreef: >> On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst >> <maarten.lankhorst at canonical.com> wrote: >>> I have no idea what this bogus restriction on placement is, but it breaks decoding 1080p >>> VDPAU at boot speed.