aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2013-11-08drm/nouveau/fb: remove ram oclass argument from base fb constructorBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nv50-nvaf/fb: split the class definitions up a bitBen Skeggs
These will diverge further in the future. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nouveau/fb: make external class definitions pointersBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nvaa/mc: blacklist msi to off by defaultBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nv50-nv86,nv92/mc: rearm msi via pci config space, rather than mmio mirrorBen Skeggs
This is what NVIDIA do on these chipsets, let's hope it works around the reported MSI failures for us on NV86. v2: updated to include G92, as per information provided by NVIDIA. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nvc0,nvc4/mc: handle 0xc0's "special" msi rearmBen Skeggs
v2. updated to cover GF104, as per information provided by NVIDIA. Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nouveau/mc: store static data in nouveau_mc class definitionBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nouveau/mc: fetch NV_PMC_INTR again after re-arming MSIBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nouveau/mc: bracket interrupt handler with NV_PMC_INTR_EN disable/re-enableBen Skeggs
This looks to be what NVIDIA do pretty much everywhere, since forever. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nouveau/mc: have single entry and exit points to the interrupt handlerBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nouveau/mc: msi rearm write via subdev, not deviceBen Skeggs
This way we can catch it with debugging on for PMC subdev. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nouveau/device: use an additional bit from NV_PMC_BOOT_0 to identify chipsetBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nouveau/bios/init: return failure condition on invalid opcodesBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nv31/mpeg: remove need for separate refcnt on engine useBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nouveau/therm: ack any pending IRQ at initMartin Peres
This is safe because ptherm hasn't been configured yet and will be a little further down the initialization path. Ptherm should be safe regarding to runtime reconfiguration. v2: - do not limit this patch to nv84-a3 and make it nv84+ v3: - move the ack to fini() - disable IRQs on fini() - silently ignore un-requested IRQs Signed-off-by: Martin Peres <martin.peres@labri.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nv31/mpeg: split the nv31 and nv40 dma setting implementationsIlia Mirkin
NV31 has different config bits than NV40+ do. Also fix the DMA_IMAGE VRAM-only setting to check the right bits. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nv31/mpeg: store chan singleton in engine, use it for dispatchIlia Mirkin
This makes nv31+ able to actually perform the nv_call, since previously the inst was not available. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nv40/mpeg: use the nv31-provided classesIlia Mirkin
Since nv40 only covers pre-nv44 now, it can use the nv31-provided functions. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nv44/mpeg: create a copy of the nv31/nv40 implsIlia Mirkin
The nv31/nv40 impls are actually fairly nv44-specific, since they assume the presence of the instance register/context switching. Create a copy before nv31/nv40 get fixed. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nv31/mpeg: no need to set compat mode differently for nv44 grIlia Mirkin
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nv10/kms: add plane support for nv10-nv40Ilia Mirkin
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nv10: fix chipset checks, mostly for the benefit of nv1aIlia Mirkin
NV1A is numerically higher than NV17 but generationally lower. Use the new card type to help disambiguate. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nv10: introduce a new NV_11 card typeIlia Mirkin
NV11/17/1F/18 come after NV10/15/16/1A. In order to facilitate using numerical comparisons, split up the two sets into different card types. This change should be a no-op except that the relevant cards will see NV11 printed instead of NV10 for the family. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nouveau: fix backlight mask on ppc powerbookIlia Mirkin
This code was originally moved to using nv_mask by d31e078d84. This should not have any actual effect since the mask isn't applied to the value. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nouveau: remove prototype for non-existent nouveau_connector_bppIlia Mirkin
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nouveau/vic: rename PUNK1C1 to PVICBen Skeggs
NVIDIA's name for what rnndb calls PVCOMP. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nouveau/therm: kill some over-zealous debuggingBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nouveau/core: split lock into list+exec and enable refcount locksBen Skeggs
This fixes a reported locking inversion when interacting with the DRM core's vblank routines. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nouveau/core: convert event handler apis to split create/enable semanticsBen Skeggs
This is a necessary step towards being able to work with the insane locking requirements of the DRM core's vblank routines, and a nice cleanup as a side-effect. This is similar in spirit to the interfaces that Peter Hurley arrived at with his nouveau_event rcu conversion series. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nv50-/sw: share engine/channel constructor between implementationsBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nouveau/sw: prepare for the sharing of constructors between implementationsBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nv50-/sw: make vblank tracking data private to the implementationsBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nv50-/sw: share engine/channel struct definitions between implementationsBen Skeggs
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nouveau/core: Allow asymmetric nouveau_event_get/_putPeter Hurley
Most nouveau event handlers have storage in 'static' containers (structures with lifetimes nearly equivalent to the drm_device), but are dangerously reused via nouveau_event_get/_put. For example, if nouveau_event_get is called more than once for a given handler, the event handler list will be corrupted. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nouveau/core: Move event index check from critical sectionPeter Hurley
The index_nr field is constant for the lifetime of the event, so serialized access is unnecessary. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nouveau/core: Add priv field for event handlersPeter Hurley
Provide private field for event handlers exclusive use. Convert nouveau_fence_wait_uevent() and nouveau_fence_wait_uevent_handler(); drop struct nouveau_fence_uevent. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nouveau: off by one in nouveau_drm_vblank_enable()Dan Carpenter
The test here should be ">= ARRAY_SIZE()" instead of "> ARRAY_SIZE()". Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-08drm/nouveau: remove pointless assignmentDave Jones
self-assignment of a variable doesn't make a lot of sense. Signed-off-by: Dave Jones <davej@fedoraproject.org> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2013-11-07drm/i915/bdw: Handle forcewake for writes on gen8Ben Widawsky
GEN8 removes the GT FIFO which we've all come to know and love. Instead it offers a wider range of optimized registers which always keep a shadowed copy, and are fed to the GPU when it wakes. How this is implemented in hardware is still somewhat of a mystery. As far as I can tell, the basic design is as follows: If the register is not optimized, you must use the old forcewake mechanism to bring the GT out of sleep. [1] If register is in the optimized list the write will signal that the GT should begin to come out of whatever sleep state it is in. While the GT is coming out of sleep, the requested write will be stored in an intermediate shadow register. Do to the fact that the implementation details are not clear, I see several risks: 1. Order is not preserved as it is with GT FIFO. If we issue multiple writes to optimized registers, where order matters, we may need to serialize it with forcewake. 2. The optimized registers have only 1 shadowed slot, meaning if we issue multiple writes to the same register, and those values need to reach the GPU in order, forcewake will be required. [1] We could implement a SW queue the way the GT FIFO used to work if desired. NOTE: Compile tested only until we get real silicon. v2: - Use a default case to make future platforms also work. - Get rid of IS_BROADWELL since that's not yet defined, but we want to MMIO as soon as possible. v3: Apply suggestions from Mika's review: - s/optimized/shadowed/ - invert the logic of the helper so that it does what it says (the code itself was correct, just confusing to read). v4: - Squash in lost break. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> (v1) Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-07drm/i915: Use clamp_t() when limiting cur_delayVille Syrjälä
Make the cur_delay limiting code a bit less prone to typo errors by using clamp_t(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-07drm/i915: Kill vlv_update_rps_cur_delay()Ville Syrjälä
Polling to make sure the current GPU frequency matches the last requested frequency should not be necessay, and if there's some throttling involved, the two might not match anyway. Since we're still seeing this trigger occasionally, and it just introduces a rather pointless 10 ms delay, it seems like better to kill it off. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-07drm/i915: Initialise min/max frequencies before updating RPS registersChris Wilson
The RPS register writing routines use the current value of min/max to set certain limits and interrupt gating. If we set those afterwards, we risk setting up the hw incorrectly and losing power management events, and worse, trigger some internal assertions. Reorder the calling sequences to be correct, and remove the then unrequired clamping from inside set_rps(). And for a bonus, fix the bug of calling gen6_set_rps() from Valleyview. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-07drm/i915/vlv: For i915_cur_delayinfo, the max frequency reporting wrong value.Chon Ming Lee
The max frequency reporting is not correct. But there is already an existing valleyview_rps_max_freq and valleyview_rps_min_freq to get the frequency. Use that for i915_cur_delayinfo. Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-07drm/i915: Use frame counter for intel_wait_for_vblank() on CTGVille Syrjälä
Use the same wait_for_vblank code for CTG that we use for ILK+. Also fix the name of the frame counter register while at it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-07drm/i915: Fix gen3/4 vblank counter wraparoundVille Syrjälä
When the hardware frame counter reads 0xffffff and we're already past vblank start, we'd return 0x1000000 as the vblank counter value. Once we'd cross into the next frame's active portion, the vblank counter would wrap to 0. So we're reporting two different vblank counter values for the same frame. Fix the problem by masking the cooked value by 0xffffff to make sure the counter wraps already after vblank start. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-07drm/i915/vlv: Workaround a punit issue in DDR data rate for 1333.Chon Ming Lee
For DDR data rate reporting by Punit in PUNIT_GPU_FREQ_STS, the actual data encoding is 00b=800, 01b=1066, 10b=1333, 11b=1333. Some premium VLV sku will get the DDR_DATA_RATE set as 11. As a result, the turbo frequency reporting will be incorrect without this workaround. Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-07drm/i915: Require HW contexts (when possible)Ben Widawsky
v2: Fixed the botched locking on init_hw failure in i915_reset (Ville) Call cleanup_ringbuffer on failed context create in init_hw (Ville) v3: Add dev argument ti clean_ringbuffer Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-07Merge branch 'ttm-next-3.13' of git://people.freedesktop.org/~thomash/linux ↵Dave Airlie
into drm-next - A couple of fixes that never made it into fixes-3.12 - Make NO_EVICT bo's available for shrinkers when on delayed-delete list - Allow retrying page-faults that need to wait for GPU. * 'ttm-next-3.13' of git://people.freedesktop.org/~thomash/linux: drm/ttm: Fix memory type compatibility check drm/ttm: Fix ttm_bo_move_memcpy drm/ttm: Handle in-memory region copies drm/ttm: Make NO_EVICT bos available to shrinkers pending destruction drm/ttm: Allow vm fault retries
2013-11-06drm/i915/vlv: use per-pipe backlight controls v2Jesse Barnes
With the connector and pipe passed around, we can now set the backlight on the right pipe on VLV/BYT. v2: drop combination mode check for VLV (Jani) add save/restore code for VLV backlight regs (Jani) check for existing modulation freq when initializing backlight regs (Jani) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67245 Tested-by: Joe Konno <joe.konno@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-06drm/i915: Pass dev_priv to vlv_gpu_freq() and vlv_freq_opcode()Ville Syrjälä
We'll be looking at more than just mem_freq from dev_priv, so just pass the whole thing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2026-04-10 07:58:06 +0000