summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2015-04-14ACPICA: Unix: Cleanup to use ACPI_TO_INTEGER() to calc page offset.Lv Zheng
ACPICA commit 9e2d8180f4d5e61949b17513bae8aff6412f62dd The offset calculation needn't convert a pointer to a special integer type. So this patch uses ACPI_TO_INTEGER() instead. This patch only affects acpidump tool. Link: https://github.com/acpica/acpica/commit/9e2d8180 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-04-14ACPICA: Tables: Change acpi_find_root_pointer() to use acpi_physical_address.Lv Zheng
ACPICA commit 7d9fd64397d7c38899d3dc497525f6e6b044e0e3 OSPMs like Linux expect an acpi_physical_address returning value from acpi_find_root_pointer(). This triggers warnings if sizeof (acpi_size) doesn't equal to sizeof (acpi_physical_address): drivers/acpi/osl.c:275:3: warning: passing argument 1 of 'acpi_find_root_pointer' from incompatible pointer type [enabled by default] In file included from include/acpi/acpi.h:64:0, from include/linux/acpi.h:36, from drivers/acpi/osl.c:41: include/acpi/acpixf.h:433:1: note: expected 'acpi_size *' but argument is of type 'acpi_physical_address *' This patch corrects acpi_find_root_pointer(). Link: https://github.com/acpica/acpica/commit/7d9fd643 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-04-14ACPICA: Linuxize: Reduce divergences for 20150410 release.Lv Zheng
This patch reduces source code differences between the Linux kernel and the ACPICA upstream so that the linuxized ACPICA 20150410 release can be applied with reduced human intervention. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-04-14Merge tag 'perf-core-for-mingo-2' of ↵Ingo Molnar
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo: New features: - Analyze page allocator events in 'perf kmem' (Namhyung Kim) User visible changes: - Fix retprobe 'perf probe' handling when failing to find needed debuginfo (He Kuang) - lazy_line probe fixes in 'perf probe' (Naohiro Aota, He Kuang) Infrastructure changes: - Record pfn instead of pointer to struct page in tracepoints (Namhyung Kim) Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-04-14Merge branches 'powercap' and 'pm-devfreq'Rafael J. Wysocki
* powercap: powercap / RAPL: mark rapl_ids array as __initconst powercap / RAPL: add ID for Broadwell server * pm-devfreq: PM / devfreq: tegra: Register governor on module init PM / devfreq: tegra: Enable interrupts after resuming the devfreq monitor PM / devfreq: tegra: Set drvdata before enabling the irq PM / devfreq: tegra: remove operating-points PM / devfreq: tegra: Use clock rate constraints PM / devfreq: tegra: Update to v5 of the submitted patches PM / devfreq: correct misleading comment PM / devfreq: event: Add const keyword for devfreq_event_ops structure
2015-04-14Merge branch 'acpi-scan'Rafael J. Wysocki
* acpi-scan: ACPI / scan: Fix NULL pointer dereference in acpi_companion_match()
2015-04-14drm: fix trivial typo mistakeJohn Hunter
Signed-off-by: John Hunter <zhjwpku@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-14powerpc: Remove PPC32 code from pseries specific find_and_init_phbs()Daniel Axtens
In bdc728a849a7 ("powerpc: move find_and_init_phbs() to pSeries specific code"), find_and_init_phbs() was moved into a pseries specific file, but PPC32 code wasn't removed. Remove it. See https://lkml.kernel.org/r/552C0AA6.4010403@fau.de Reported-by: Andreas Ruprecht <andreas.ruprecht@fau.de> Fixes: bdc728a849a7 Signed-off-by: Daniel Axtens <dja@axtens.net> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-04-14powerpc/cell: Fix iommu breakage caused by controller_ops changeMichael Ellerman
The recent patch to convert cell to use pci_controller_ops had a small bug which broke machines using an iommu. The set of phb->controller_ops was added after the check for name != "pci", meaning pcix/pcie PHBs weren't getting their ops set correctly. Fixes: 9c1368fc50e7 ("powerpc/cell: Move controller ops from ppc_md to controller_ops") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-04-14powerpc/eeh: Fix crash in eeh_add_device_early() on CellMichael Ellerman
The recent change to the EEH probing causes a crash on Cell because eeh_ops is NULL. Check if EEH is enabled and if not bail out. Fixes: ff57b454ddb9 ("powerpc/eeh: Do probe on pci_dn") Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2015-04-14drm: Make integer overflow checking cover universal cursor updates (v2)Matt Roper
Our legacy SetPlane updates perform integer overflow checking on a plane's destination rectangle in drm_mode_setplane(), and atomic updates handled as part of a drm_atomic_state transaction do the same checking in drm_atomic_plane_check(). However legacy cursor updates that get routed through universal plane interfaces may bypass this overflow checking if the driver's .update_plane is serviced by the transitional plane helpers rather than the full atomic plane helpers. Move the check for destination rectangle integer overflow from the drm_mode_setplane() to __setplane_internal() so that it also covers cursor operations. This fixes an issue first noticed with i915 commit: commit ff42e093e9c9c17a6e1d6aab24875a36795f926e Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Mar 2 16:35:20 2015 +0100 Revert "drm/i915: Switch planes from transitional helpers to full atomic helpers" The above revert switched us from full atomic helpers back to the transitional helpers, and in doing so we lost the overflow checking here for universal cursor updates. Even though such extreme cursor positions are unlikely to actually happen in the wild, we still don't want there to be a change of behavior when drivers switch from transitional helpers to full helpers. v2: Move check from setplane ioctl to setplane_internal rather than adding an additional copy of the checks to the transitional plane helpers. (Daniel) Cc: Daniel Vetter <daniel@ffwll.ch> Testcase: igt/kms_cursor_crc Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84269 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-14drm/nouveau/bios: fix fetching from acpi on certain systemsJan Vesely
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>
2015-04-14drm/nouveau/gr/gm206: initial init+ctx codeBen Skeggs
Uncertain whether the GPC pack change is due to a newer driver version, or a legitimate difference from GM204. My GM204 has broken vram, so can't currently try a newer binary driver on it to confirm. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/ce/gm206: enable support via gm204 codeBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/fifo/gm206: enable support via gm204 codeBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/gr/gm204: initial init+ctx codeBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau: support for buffer moves via MaxwellDmaCopyABen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/ce/gm204: initial supportBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau: add support for gm20x fifo channelsBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/fifo/gm204: initial supportBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/gr/gk104-: prevent reading non-existent regs in intr handlerBen Skeggs
Under certain circumstances the trapped address will contain subc 7, which GK104 GR doesn't have anymore. Notice this case to avoid causing additional priv ring faults. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/gr/gm107: very slightly demagic part of attrib cb setupBen Skeggs
No idea if "3" is a constant or derived from something else, but the value is unchanged in the limited traces of gm107/gm204 I have here. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/gr/gk104-: correct crop/zrop num_active_fbps settingBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/gr/gf100-: add symbolic names for classesBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/gr/gm107: support tpc "strand" ctxsw in gpccs ucodeBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/gr/gf100-: support mmio access with gpc offset from gpccs ucodeBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/gr: fix engine name, cosmetic search+replace mistakeBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/pmu/gk20a: add some missing staticsAlexandre Courbot
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>
2015-04-14drm/nouveau/platform: fix probe error pathAlexandre Courbot
A "return 0" found its way in the middle of the error path of nouveau_platform_probe(), remove it as it will make the kernel crash if we try to unload the module afterwards. While we are at it, also remove the IOMMU domain if it has been created, as we should. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/platform: release IOMMU's mm upon exitAlexandre Courbot
nvkm_mm_fini() was not called when exiting the driver, resulting in a memory leak. Fix this. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/gr/gk104-gk20a: call pmu to disable any power-gating before ctor()Ben Skeggs
On some of these chipsets, reading NV_PGRAPH_GPC_GPM_PD_PES_TPC_ID_MASK can trigger a PRI fault and return an error code instead of a TPC mask, unless PGOB has been disabled first. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/pmu/gk208: implement gr power-up magic with gk110_pmu_pgob()Ben Skeggs
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>
2015-04-14drm/nouveau/pmu/gk110: implement gr power-up magic like PGOB on earlier chipsBen Skeggs
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>
2015-04-14drm/nouveau/pbus/hwsq: Make code size u16Roy Spliet
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>
2015-04-14drm/nouveau/pbus/hwsq: Support strided register writesRoy Spliet
Signed-off-by: Roy Spliet <rspliet@eclipso.eu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/instmem/gk20a: fix crash during error pathAlexandre Courbot
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>
2015-04-14drm/nouveau/disp/gf110-: fix base channel update debug/error outputBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/disp/nv50-: fix push buffers in vramBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau: bump driver patchlevel for coherent flagBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/gem: allow user-space to specify an object should be coherentAlexandre Courbot
User-space use mappable BOs notably for fences, and expects that a value update by the GPU will be immediatly visible through the user-space mapping. ARM has a property that may prevent this from happening though: memory can be mapped multiple times only if the different mappings share the same caching properties. However all the lowmem memory is already identity-mapped into the kernel with cache enabled, so when user-space requests an uncached mapping, we actually get an "undefined caching policy" one and this has strange side-effects described on Freedesktop bug 86690. To prevent this from happening, allow user-space to explicitly specify which objects should be coherent, and create such objects with the TTM_PL_FLAG_UNCACHED flag. This will make TTM allocate memory using the DMA API, which will fix the identify mapping and allow us to safely map the objects to user-space uncached. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Lucas Stach <dev@lynxeye.de> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/instmem/gk20a: add IOMMU supportAlexandre Courbot
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>
2015-04-14drm/nouveau/platform: probe IOMMU if presentAlexandre Courbot
Tegra SoCs have an IOMMU that can be used to present non-contiguous physical memory as contiguous to the GPU and maximize the use of large pages in the GPU MMU, leading to performance gains. This patch adds support for probing such a IOMMU if present and make its properties available in the nouveau_platform_gpu structure so subsystems can take advantage of it. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/instmem/gk20a: use DMA attributesAlexandre Courbot
instmem for GK20A is allocated using dma_alloc_coherent(), which provides us with a coherent CPU mapping that we never use because instmem objects are accessed through PRAMIN. Switch to dma_alloc_attrs() which gives us the option to dismiss that CPU mapping and free up some CPU virtual space. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/gk20a: remove RAM deviceAlexandre Courbot
Now that Nouveau can operate even when there is no RAM device, remove the dummy one used by GK20A. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/instmem/gk20a: move memory allocation to instmemAlexandre Courbot
GK20A does not have dedicated RAM, thus having a RAM device for it does not make sense. Move the contiguous physical memory allocation to instmem. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14make RAM device optionalAlexandre Courbot
Having a RAM device does not make sense for chips like GK20A which have no dedicated video memory. The dummy RAM device that we used so far works as a temporary band-aid, but in the longer term it is desirable for the driver to be able to work without any kind of VRAM. This patch adds a few conditionals in places where a RAM device was assumed to be present and allows some more objects to be allocated from the TT domain, allowing Nouveau to handle GPUs for which pfb->ram == NULL. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/gr/gf100: Clear notify interruptLauri Peltonen
Notify interrupt is only used for cyclestats. We can just clear it and avoid an "unknown stat" error that gets printed to dmesg otherwise. Signed-off-by: Lauri Peltonen <lpeltonen@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/graph/nvc0: Fix engine pointer retrievalLauri Peltonen
Other methods in this file suggest this is the correct way to retrieve the engine pointer. Signed-off-by: Lauri Peltonen <lpeltonen@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/devinit/nv04: change owner to intBen Skeggs
We use -1 to mean "not read from hw yet" Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2015-04-14drm/nouveau/mxm: indent an if statementDan Carpenter
This if statement is correct but it wasn't indented, so it looked like some code was missing. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
generated by cgit (git 2.34.1) at 2025-09-14 02:57:55 +0000