- 20 Apr, 2015 2 commits
-
-
Heiko Stuebner authored
platform_get_irq() can return negative error values and we already test for these. Therefore the variable holding this value should be signed to not loose possible error values. Reported-by:
David Binderman <dcb314@hotmail.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Reviewed-By:
Daniel Kurtz <djkurtz@chromium.org>
-
Heiko Stuebner authored
Mark Yao looks after the Rockchip drm drivers and should thus also get patches touching these. Signed-off-by:
-
- 15 Apr, 2015 5 commits
-
-
Dave Airlie authored
Merge tag 'drm-intel-next-fixes-2015-04-15' of git://anongit.freedesktop.org/drm-intel into drm-next Misc i915 fixes. * tag 'drm-intel-next-fixes-2015-04-15' of git://anongit.freedesktop.org/drm-intel: drm/i915: Dont enable CS_PARSER_ERROR interrupts at all drm/i915: Move drm_framebuffer_unreference out of struct_mutex for takeover drm/i915: Allocate connector state together with the connectors drm/i915/chv: Remove DPIO force latency causing interpair skew issue drm/i915: Don't cancel DRRS worker synchronously for flush/invalidate drm/i915: Fix locking in DRRS flush/invalidate hooks
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
One more drm-misch pull for 4.1 with mostly simple stuff and boring refactoring. Even the cursor fix from Matt is just to make a really anal igt happy. * tag 'topic/drm-misc-2015-04-15' of git://anongit.freedesktop.org/drm-intel: drm: fix trivial typo mistake drm: Make integer overflow checking cover universal cursor updates (v2) drm: make crtc/encoder/connector/plane helper_private a const pointer drm/armada: constify struct drm_encoder_helper_funcs pointer drm/radeon: constify more struct drm_*_helper funcs pointers drm/edid: add #defines for ELD versions drm/atomic: Add for_each_{connector,crtc,plane}_in_state helper macros drm: Use kref_put_mutex in drm_gem_object_unreference_unlocked drm/drm: constify all struct drm_*_helper funcs pointers drm/qxl: constify all struct drm_*_helper funcs pointers drm/nouveau: constify all struct drm_*_helper funcs pointers drm/radeon: constify all struct drm_*_helper funcs pointers drm/gma500: constify all struct drm_*_helper funcs pointers drm/mgag200: constify all struct drm_*_helper funcs pointers drm/exynos: constify all struct drm_*_helper funcs pointers drm: Fix some typos
-
git://ftp.arm.linux.org.uk/~rmk/linux-armDave Airlie authored
This set of patches adjust the setup of the HDMI CTS/N values for audio support to be compliant with the work-around given in the iMX6 errata documentation as part of the preparation for integrating audio support for this driver, and also update the HDMI phy configuration for Rockchip devices to improve the HDMI eye pattern. * 'drm-dwhdmi-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-arm: drm: rockchip/dw_hdmi-rockchip: improve for HDMI electrical test drm: bridge/dw_hdmi: separate VLEVCTRL settting into platform driver drm: bridge/dw_hdmi: fixed codec style drm: bridge/dw_hdmi: adjust n/cts setting order drm: bridge/dw_hdmi: protect n/cts setting with a mutex drm: bridge/dw_hdmi: combine hdmi_set_clock_regenerator_n() and hdmi_regenerate_cts() Conflicts: drivers/gpu/drm/imx/dw_hdmi-imx.c
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
Some final bits for 4.1. Some fixes for userptrs and allow a new packet for VCE to enable some new features in mesa. * 'drm-next-4.1' of git://people.freedesktop.org/~agd5f/linux: drm/radeon: allow creating overlapping userptrs drm/radeon: add userptr config option drm/radeon: add video usability info support for VCE
-
git://anongit.freedesktop.org/git/nouveau/linux-2.6Dave Airlie authored
- gk20a iommu support - gm107 graphics support without needing proprietary ucode - various random fixes - more gm20x bring-up, fifo/ce are ok, gr is mostly complete with the exception of ctxsw ucode.. nvidia aren't playing nice yet so there's not much more that can be done at this point... I spent a lot of time trying to find a viable way of doing gr ctxsw without signed firmware, but the "security" restrictions on the fecs/gpccs falcons are excessive and go beyond what'd be necessary to protect the host from malicious firmware. This newer nvidia hw is VERY open-source unfriendly. I have some experimental host-based ctxsw work that could be a viable (albeit unsatisfactory and slow) workaround in the meantime, but it needs some more work and i'd like to get the 3d driver working properly before i commit to pushing it. * 'linux-4.1' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (40 commits) drm/nouveau/bios: fix fetching from acpi on certain systems drm/nouveau/gr/gm206: initial init+ctx code drm/nouveau/ce/gm206: enable support via gm204 code drm/nouveau/fifo/gm206: enable support via gm204 code drm/nouveau/gr/gm204: initial init+ctx code drm/nouveau: support for buffer moves via MaxwellDmaCopyA drm/nouveau/ce/gm204: initial support drm/nouveau: add support for gm20x fifo channels drm/nouveau/fifo/gm204: initial support drm/nouveau/gr/gk104-: prevent reading non-existent regs in intr handler drm/nouveau/gr/gm107: very slightly demagic part of attrib cb setup drm/nouveau/gr/gk104-: correct crop/zrop num_active_fbps setting drm/nouveau/gr/gf100-: add symbolic names for classes drm/nouveau/gr/gm107: support tpc "strand" ctxsw in gpccs ucode drm/nouveau/gr/gf100-: support mmio access with gpc offset from gpccs ucode drm/nouveau/gr: fix engine name, cosmetic search+replace mistake drm/nouveau/pmu/gk20a: add some missing statics drm/nouveau/platform: fix probe error path drm/nouveau/platform: release IOMMU's mm upon exit drm/nouveau/gr/gk104-gk20a: call pmu to disable any power-gating before ctor() ...
-
- 14 Apr, 2015 33 commits
-
-
Daniel Vetter authored
We stopped handling them in commit aaecdf61 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Nov 4 15:52:22 2014 +0100 drm/i915: Stop gathering error states for CS error interrupts but just clearing is apparently not enough: A sufficiently dead gpu left behind by firmware (*cough* coreboot *cough*) can keep the gpu in an endless loop of such interrupts, eventually leading to the nmi firing. And definitely to what looks like a machine hang. Since we don't even enable these interrupts on gen5+ let's do the same on earlier platforms. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93171Tested-by:
Mono <mono-for-kernel-org@donderklumpen.de> Tested-by: info@gluglug.org.uk Cc: stable@vger.kernel.org Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Tvrtko Ursulin authored
intel_user_framebuffer_destroy() requires the struct_mutex for its object bookkeeping, so this means that all calls to drm_framebuffer_unreference must be held without that lock. This is a simplified version of the identically named patch by Chris Wilson. Regression from commit ab8d6675 Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Date: Mon Feb 2 15:44:15 2015 +0000 drm/i915: Track old framebuffer instead of object v2: Bikeshedding. References: https://bugs.freedesktop.org/show_bug.cgi?id=89166 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
John Hunter authored
Signed-off-by:
John Hunter <zhjwpku@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Matt Roper authored
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 ff42e093 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=84269Signed-off-by:Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Jan Vesely authored
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>
-
Ben Skeggs authored
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 authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
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 authored
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 authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Alexandre Courbot authored
Make static a few functions and structures that should be. Signed-off-by:
Alexandre Courbot <acourbot@nvidia.com> Signed-off-by:
-
Alexandre Courbot authored
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 authored
nvkm_mm_fini() was not called when exiting the driver, resulting in a memory leak. Fix this. Signed-off-by:
-
Ben Skeggs authored
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 authored
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 authored
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: -
Roy Spliet authored
So we can actually use the full 512 byte code space Signed-off-by:
Roy Spliet <rspliet@eclipso.eu> Signed-off-by:
-
Roy Spliet authored
Signed-off-by:
-
Alexandre Courbot authored
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:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Alexandre Courbot authored
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:
Lucas Stach <dev@lynxeye.de> Signed-off-by:
-
