litmus-rt.git/drivers/gpu/drm/nouveau/nvkm/subdev, branch master The LITMUS^RT kernel. drm/nouveau/devinit/gm100-: force devinit table execution on boards without PDISP 2015-05-29T00:59:32+00:00 Ben Skeggs bskeggs@redhat.com 2015-05-21T05:47:16+00:00 4d4d6f7520b6fce065a8b8303ace9ec48b9e96e9 Should fix fdo#89558 Signed-off-by: Ben Skeggs <bskeggs@redhat.com> 
Should fix fdo#89558

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm/nouveau/devinit/gf100: make the force-post condition more obvious 2015-05-29T00:59:32+00:00 Ben Skeggs bskeggs@redhat.com 2015-05-21T05:44:15+00:00 c9ab50d21032ca8c5013f4d57e9aa866da78d7c7 And also more generic, so it can be used on newer chipsets. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> 
And also more generic, so it can be used on newer chipsets.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm/nouveau/bios: fix fetching from acpi on certain systems 2015-04-14T07:00:59+00:00 Jan Vesely jano.vesely@gmail.com 2015-04-09T01:34:36+00:00 4195f40685a5f2783b4decece13ed740b61ee038 nvbios_extend() returns 1 to indicate "extended the array" and 0 to indicate the array is already big enough. This is used by the core shadowing code to prevent re-fetching chunks of the image that have already been shadowed. The ACPI fetching code may possibly need to extend this further due to requiring fetches to happen in 4KiB chunks. Under certain circumstances (that happen if the total image size is a multiple of 4KiB), the memory allocated to store the shadow will already be big enough, causing the ACPI code's nvbios_extend() call to return 0, which is misinterpreted as a failure. The fix is simple, accept >= 0 as a successful condition here. The core will have already made sure that we're not re-fetching data we already have. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89047 v2 (Ben Skeggs): - dropped hunk which would cause unnecessary re-fetching - more descriptive explanation Signed-off-by: Jan Vesely <jano.vesely@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> 
nvbios_extend() returns 1 to indicate "extended the array" and 0 to
indicate the array is already big enough.  This is used by the core
shadowing code to prevent re-fetching chunks of the image that have
already been shadowed.

The ACPI fetching code may possibly need to extend this further due
to requiring fetches to happen in 4KiB chunks.

Under certain circumstances (that happen if the total image size is
a multiple of 4KiB), the memory allocated to store the shadow will
already be big enough, causing the ACPI code's nvbios_extend() call
to return 0, which is misinterpreted as a failure.

The fix is simple, accept >= 0 as a successful condition here.  The
core will have already made sure that we're not re-fetching data we
already have.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89047

v2 (Ben Skeggs):
- dropped hunk which would cause unnecessary re-fetching
- more descriptive explanation

Signed-off-by: Jan Vesely <jano.vesely@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm/nouveau/pmu/gk20a: add some missing statics 2015-04-14T07:00:52+00:00 Alexandre Courbot acourbot@nvidia.com 2015-03-20T10:41:06+00:00 7120908d12db5d2d1ba136ee014fee4e95513fc0 Make static a few functions and structures that should be. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> 
Make static a few functions and structures that should be.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm/nouveau/pmu/gk208: implement gr power-up magic with gk110_pmu_pgob() 2015-04-14T07:00:50+00:00 Ben Skeggs bskeggs@redhat.com 2015-03-20T05:28:52+00:00 f02a0e849dbd16541a1e75ef8c8719bc5f611219 Before we moved gk110's implementation of this to pmu, the functions were identical. This commit just switches GK208 to use the new (more complete) implementation of the power-up sequence. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> 
Before we moved gk110's implementation of this to pmu, the functions were
identical.  This commit just switches GK208 to use the new (more complete)
implementation of the power-up sequence.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm/nouveau/pmu/gk110: implement gr power-up magic like PGOB on earlier chips 2015-04-14T07:00:50+00:00 Ben Skeggs bskeggs@redhat.com 2015-03-20T05:20:17+00:00 e1fc44fb9dbec4ff4e63c888d206a0bc4ca93f4f Turns out the PTHERM part of this dance is bracketed by the same PMU fiddling that occurs on GK104/6, let's assume it's also PGOB. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> 
Turns out the PTHERM part of this dance is bracketed by the same PMU
fiddling that occurs on GK104/6, let's assume it's also PGOB.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm/nouveau/pbus/hwsq: Make code size u16 2015-04-14T07:00:49+00:00 Roy Spliet rspliet@eclipso.eu 2015-03-12T19:43:23+00:00 d9da545e101312f52706c8b05afbd8f1f875ff81 So we can actually use the full 512 byte code space Signed-off-by: Roy Spliet <rspliet@eclipso.eu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> 
So we can actually use the full 512 byte code space

Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm/nouveau/pbus/hwsq: Support strided register writes 2015-04-14T07:00:49+00:00 Roy Spliet rspliet@eclipso.eu 2015-03-12T19:43:22+00:00 3834b632b2e3f8586692e80b936c52b9dc987144 Signed-off-by: Roy Spliet <rspliet@eclipso.eu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> 
Signed-off-by: Roy Spliet <rspliet@eclipso.eu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm/nouveau/instmem/gk20a: fix crash during error path 2015-04-14T07:00:49+00:00 Alexandre Courbot acourbot@nvidia.com 2015-03-10T06:46:08+00:00 df16896b866a056da3c275cf416f6f4cc47934bd If a memory allocation fails when using the DMA allocator, gk20a_instobj_dtor_dma() will be called on the failed instmem object. At this time, node->handle might not be NULL despite the call to dma_alloc_attrs() having failed. node->cpuaddr is the right member to check for such a failure, so use it instead. Reported-by: Vince Hsu <vinceh@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> 
If a memory allocation fails when using the DMA allocator,
gk20a_instobj_dtor_dma() will be called on the failed instmem object.
At this time, node->handle might not be NULL despite the call to
dma_alloc_attrs() having failed. node->cpuaddr is the right member to
check for such a failure, so use it instead.

Reported-by: Vince Hsu <vinceh@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm/nouveau/instmem/gk20a: add IOMMU support 2015-04-14T07:00:45+00:00 Alexandre Courbot acourbot@nvidia.com 2015-02-20T09:23:04+00:00 a7f6da6e758cd99fcae918b63549273893983189 Let GK20A's instmem take advantage of the IOMMU if it is present. Having an IOMMU means that instmem is no longer allocated using the DMA API, but instead obtained through page_alloc and made contiguous to the GPU by IOMMU mappings. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> 
Let GK20A's instmem take advantage of the IOMMU if it is present. Having
an IOMMU means that instmem is no longer allocated using the DMA API,
but instead obtained through page_alloc and made contiguous to the GPU
by IOMMU mappings.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>