summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_sprite.c
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915: Shuffle sprite register writes into a tighter groupVille Syrjälä2014-01-241-9/+9
| | | | | | | | | | | Group the sprite register writes a bit tighter. We want to write the registers atomically, and so doing the base address/offset artihmetic within the critical section is pointless when it can all be done beforehand. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Revert "drm/i915: Mask reserved bits in display/sprite address registers"Daniel Vetter2014-01-241-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 446f254566ea8911c9e19c7bc8a162fc0e53cf31. I've left the masking in the pageflip code since that seems to be some useful piece of preemptive robustness. Iirc I've merged this patch under the assumption that the BIOS leaves some random gunk in the lower bits and gets unhappy if we trample on them. We have quite a few case like this, so this made sense. Now I've just learned that there's actual hardware features bits in the low 12 bits, and the kernel needs to preserve them to allow a userspace blob to do its job. Given Dave Airlie's clear stance on userspace blob drivers I've quickly chatted with him and he doesn't seem too happy. So let's revert this. If there are indeed bits that we must preserve in this range then we can ressurrect this patch, but with proper documentation for those bits supplied. And we probably also need to think a bit about interactions with our driver. Cc: Armin Reese <armin.c.reese@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Dave Airlie <airlied@linux.ie> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Revert "drm/i915/sprite: Always enable the scaler on IronLake"Ville Syrjälä2013-12-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Apparently always enabling the sprite scaler magically made sprites work on ILK in the past. I think the real reason for the failure was missing sprite watermark programming, and enabling the scaler effectively disabled LP1+ watermarks, which was enough to keep things going. Or it might be that the hardware more or less ignores watermarks for scaled sprites since things seem to work even if I leave sprite watermarks at 0 and disable all other planes except the sprite. In any case, we left the scaler always on but then failed to check whether we might be exceeding the scaler's source size limits. That caused the sprite to fail when a sufficiently large unscaled image was being displayed. Now that we're getting proper watermark programming for ILK, we can keep the scaler disabled unless we need to do actual scaling. This reverts commit 8aaa81a166d80ac9bf2813984e5b4c2503d0fe08. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Avoid underruns when disabling spritesVille Syrjälä2013-12-171-0/+12
| | | | | | | | | | | | | | As the watermark registers aren't double bufferd, clearing the watermarks immediately after writing the sprite registers can be hazardous. Until we have something better, add a wait for vblank between the two steps to make sure the sprite no longer needs the watermark levels before we clear them. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Don't disable primary when color keying is usedVille Syrjälä2013-12-171-1/+10
| | | | | | | | | | When color keying is used, the primary may not be invisible even though the sprite fully covers it. So check for color keying before deciding to disable the primary plane. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Try to fix the messy IVB sprite scaling workaroundVille Syrjälä2013-12-171-26/+1Star
| | | | | | | | | | | | | | | | | | We now have a very clear method of disabling LP1+ wartermarks, and we can actually detect if we actually did disable them, or if they were already disabled. Use that to clean up the WaCxSRDisabledForSpriteScaling:ivb handling. I was hoping to apply the workaround in a way that wouldn't require a blocking wait, but sadly IVB really does appear to require LP1+ watermarks to be off for an entire frame before enabling sprite scaling. Simply disabling LP1+ watermarks during the previous frame is not enough, no matter how early in the frame we do it :( Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Enable pipe gamma for spritesVille Syrjälä2013-11-211-0/+18
| | | | | | | | | | | | | | | We send the primary and cursor plane data through the gamma unit. In order to get matching output from sprites, also send the sprite data through the gamma unit. In the future we should add some properties to control this explicitly, and also add properties for the per-sprite gamma ramps what have you, but for now this seems like a reasonable thing to do. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge tag 'bdw-stage1-2013-11-08-v2' of ↵Dave Airlie2013-11-101-3/+4
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-next So here's the Broadwell pull request. From a kernel driver pov there's two areas with big changes in Broadwell: - Completely new enumerated interrupt bits. On the plus side it now looks fairly unform and sane. - Completely new pagetable layout. To ensure minimal impact on existing platforms we've refactored both the irq and low-level gtt handling code a lot in anticipation of the bdw push. So now bdw enabling in these areas just plugs in a bunch of vfuncs. Otherwise it's all fairly harmless adjusting of switch cases and if-ladders to shovel bdw into the right blocks. So minimized impact on existing platforms. I've also merged the bdw-stage1 branch into our -nightly integration branch for the past week to make sure we don't break anything. Note that there's still quite a flurry or patches floating around, but I've figured I'll push this out. I plan to keep the bdw fixes separate from my usual -fixes stream so that you can reject them easily in case it still looks like too much churn. Also, bdw is for now hidden behind the preliminary hw enabling module option. So there's no real pressure to get follow-up patches all into 3.13. * tag 'bdw-stage1-2013-11-08-v2' of git://people.freedesktop.org/~danvet/drm-intel: (75 commits) drm/i915: Mask the vblank interrupt on bdw by default drm/i915: Wire up cpu fifo underrun reporting support for bdw drm/i915: Optimize gen8_enable|disable_vblank functions drm/i915: Wire up pipe CRC support for bdw drm/i915: Wire up PCH interrupts for bdw drm/i915: Wire up port A aux channel drm/i915: Fix up the bdw pipe interrupt enable lists drm/i915: Optimize pipe irq handling on bdw drm/i915/bdw: Take render error interrupt out of the mask drm/i915/bdw: Add BDW PCH check first drm/i915: Use hsw_crt_get_config on BDW drm/i915/bdw: Change dp aux timeout to 600us on DDIA drm/i915/bdw: Enable trickle feed on Broadwell drm/i915/bdw: WaSingleSubspanDispatchOnAALinesAndPoints drm/i915/bdw: conservative SBE VUE cache mode drm/i915/bdw: Limit SDE poly depth FIFO to 2 drm/i915/bdw: Sampler power bypass disable ddrm/i915/bdw: Disable centroid pixel perf optimization drm/i915/bdw: BWGTLB clock gate disable drm/i915/bdw: Implement edp PSR workarounds ...
| * drm/i915/bdw: Enable trickle feed on BroadwellVille Syrjälä2013-11-081-1/+1
| | | | | | | | | | | | | | Like on HSW, trickle feed should always be enabled on BDW. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/bdw: Use pipe CSC on BroadwellVille Syrjälä2013-11-081-1/+1
| | | | | | | | | | | | | | | | | | Route cursor and sprite data through the pipe CSC unit on BDW. Primary plane data is already sent through the pipe CSC. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/bdw: add Broadwell sprite/plane/cursor checksPaulo Zanoni2013-11-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | Just make Broadwell follow the same code paths as Haswell here, instead of running code for the even-older platforms. v2: Shuffle around Ben's vma prep work. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/bdw: display stuffBen Widawsky2013-11-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Just enough to make the code not barf... Init BDW display to look like HSW. For the simulator this should be fine, but this will probably require more work. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Add a FIXME comment about RCS flips being untested on bdw. Also add a note that hblank events are reserved on bdw+ in DERRMR.] Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Return -ENOENT when a mode object can't be foundVille Syrjälä2013-11-061-2/+2
|/ | | | | | | Let's be a bit more consistent with our error values. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/i915: Rename primary_disabled to primary_enabledVille Syrjälä2013-10-101-4/+4
| | | | | | | | Let's try to avoid these confusing negated booleans. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Flush primary plane changes in sprite codeVille Syrjälä2013-10-101-0/+2
| | | | | | | | | Flush the primary plane changes when enabling/disabling the primary plane in response to sprite visibility. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Enable/disable IPS when primary is enabled/disabledVille Syrjälä2013-10-101-0/+19
| | | | | | | | | | | | | IPS should be OK as long as one plane is enabled on the pipe, but it does seem to cause problems when going between primary only and sprite only. This needs more investigations, but for now just disable IPS whenever the primary plane is disabled. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Do the fbc vs. primary plane enable/disable in the right orderVille Syrjälä2013-10-101-5/+6
| | | | | | | | | | | | | Disable fbc before disabling the primary plane, and enable fbc after the primary plane has been enabled again. Also use intel_disable_fbc() to disable FBC to avoid the pointless overhead of intel_update_fbc(), and especially avoid having to clean up and set up the stolen mem compressed buffer again. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Save user requested plane coordinates only on successVille Syrjälä2013-10-101-9/+22
| | | | | | | | | | | If the setplane operation fails, we shouldn't save the user's requested plane coordinates. Since we adjust the coordinates during the clipping process, make a copy of the originals, and once the operation has succeeded save them for later reuse when the plane gets re-enabled. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Do a bit of cleanup in the sprite codeVille Syrjälä2013-10-101-9/+5Star
| | | | | | | | | | Move the variable initialization to where the variables are declared, and kill a pointless to_intel_crtc() cast when we already have the casted pointer. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Kill a goto from sprite disable codeVille Syrjälä2013-10-101-12/+9Star
| | | | | | | | | Let's not use goto when a simple if suffices. This is not error handling code or anything, so the goto looks out of place. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Reduce the time we hold struct mutex in sprite update_plane codeVille Syrjälä2013-10-101-11/+18
| | | | | | | | | | | | | | | | | | | | | We used to call the entire intel specific update_plane hook while holding struct_mutex. Actually we only need to hold struct_mutex while pinning/unpinning the obj. The plane state itself is protected by the kms locks, and as the object is pinned we can dig out the offset and tiling information from it without fearing that it would change underneath us. So now we don't need to drop and reacquire the lock around the wait_for_vblank. Also we will need another wait_for_vblank in the IVB specific update_plane hook, and this way we don't need to worry about struct_mutex there either. Also move the intel_plane->obj=NULL assignment outside strut_mutex in disable_plane to make it clear that it's not protected by struct_mutex. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Allow sprites to be configured on a disabled pipeVille Syrjälä2013-10-101-33/+32Star
| | | | | | | | | | | | | | | We allow cursors to be set up when the pipe is disabled. Do the same for sprites as well. We need to be somewhat careful with the primary disable logic as we don't want to accidentally enable the primary plane on a disabled pipe. v2: Skip primary enable/disable and plane registers writes on disabled pipe Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: use pointer = k[cmz...]alloc(sizeof(*pointer), ...) patternDaniel Vetter2013-10-011-1/+1
| | | | | | | | | | | Done while reviewing all our allocations for fubar. Also a few errant cases of lacking () for the sizeof operator - just a bit of OCD. I've left out all the conversions that also should use kcalloc from this patch (it's only 2). Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Add explicit pipe src size to pipe configVille Syrjälä2013-09-161-2/+2
| | | | | | | | | | | | | | | | | | | | | | Rather that mess about with hdisplay/vdisplay from requested_mode, add explicit pipe src size information to pipe config. Now requested_mode is only really relevant for dvo/sdvo output timings. For everything else either adjusted_mode or pipe src size should be used. In many places where we end up using pipe source size, we should actually use the primary plane size, but we don't currently store that information explicitly. As long as we treat primaries as full screen only, we can get away with this. Eventually when we move primaries over to drm_plane, we need to fix it all up. v2: Add a comment to explain what pipe_src_{w,h} are Add a note about primary planes to commit message Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Use pipe config in sprite codeVille Syrjälä2013-09-161-2/+2
| | | | | | | | | Rather than dig up the pipe source size from crtc->mode, use intel_crtc->config.requested_mode. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Pass crtc to intel_update_watermarks()Ville Syrjälä2013-09-101-3/+3
| | | | | | | | | | | Passing the appropriate crtc to intel_update_watermarks() should help in avoiding needless work in the future. v2: Avoid clash with internal 'crtc' variable in some wm functions Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: enable trickle feed on HaswellPaulo Zanoni2013-09-031-2/+5
| | | | | | | | | | | | | We shouldn't disable the trickle feed bits on Haswell. Our documentation explicitly says the trickle feed bits of PRI_CTL and CUR_CTL should not be programmed to 1, and the hardware engineer also asked us to not program the SPR_CTL field to 1. Leaving the bits as 1 could cause underflows. Reported-by: Arthur Runyan <arthur.j.runyan@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Always call intel_update_sprite_watermarks() when disabling a planeVille Syrjälä2013-08-081-0/+4
| | | | | | | | | ILK and VLV codepaths didn't update sprite watermarks when disabling a sprite. Make them do that. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Pass plane and crtc to intel_update_sprite_watermarksVille Syrjälä2013-08-081-4/+4
| | | | | | | | | | | We're going to want to know the crtc in the watermark code to avoid doing more work than we have to. We should also pass the plane we're disabling so that we know where to stick our watermark parameters without having to go look the plane up. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Don't try to disable plane if it's already disabledVille Syrjälä2013-08-081-2/+7
| | | | | | | | | | | | | Check plane->fb in intel_disable_plane() to determine if the plane is already disabled. If the plane has an fb, then it must also have a crtc, so we can drop the plane->crtc check and just call intel_enable_primary() directly. v2: WARN and bail if the plane doesn't have a crtc when it should Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Pass crtc to our update/disable_plane hooksVille Syrjälä2013-08-081-9/+12
| | | | | | | | | We're going to want to know which CRTC we're dealing with, so pass it down to the update/disable_plane hooks. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Calculate the sprite WM based on the source width instead of the ↵Ville Syrjälä2013-08-051-3/+3
| | | | | | | | | | | | | | | destination width Using the destination width in the sprite WM calculations isn't correct. We should be using the source width. Note: This doesn't affect hsw since it does not support sprite scaling. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Add review note from Paulo to the commit message.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Pass the actual sprite width to watermarks functionsVille Syrjälä2013-08-051-9/+9
| | | | | | | | Don't subtract one from the sprite width before watermark calculations. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Add scaled paramater to update_sprite_watermarks()Ville Syrjälä2013-08-051-4/+7
| | | | | | | | | | For calculating watermarks we want to know whether sprites are scaled. Pass that information to update_sprite_watermarks() so that eventually we may do some watermark pre-computing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Getter/setter for object attributesBen Widawsky2013-07-081-3/+5
| | | | | | | | | | | | | | | | | | | | | | | Soon we want to gut a lot of our existing assumptions how many address spaces an object can live in, and in doing so, embed the drm_mm_node in the object (and later the VMA). It's possible in the future we'll want to add more getter/setter methods, but for now this is enough to enable the VMAs. v2: Reworked commit message (Ben) Added comments to the main functions (Ben) sed -i "s/i915_gem_obj_set_color/i915_gem_obj_ggtt_set_color/" drivers/gpu/drm/i915/*.[ch] sed -i "s/i915_gem_obj_bound/i915_gem_obj_ggtt_bound/" drivers/gpu/drm/i915/*.[ch] sed -i "s/i915_gem_obj_size/i915_gem_obj_ggtt_size/" drivers/gpu/drm/i915/*.[ch] sed -i "s/i915_gem_obj_offset/i915_gem_obj_ggtt_offset/" drivers/gpu/drm/i915/*.[ch] (Daniel) v3: Rebased on new reserve_node patch Changed DRM_DEBUG_KMS to actually work (will need fixing later) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Disable/restore all sprite planes around modesetVille Syrjälä2013-06-061-0/+8
| | | | | | | | | | | | | | | | | Disable/restore sprite planes around mode-set just like we do for the primary and cursor planes. Now that we have working sprite clipping, this actually works quite decently. Previosuly we didn't even bother to disable sprites when changing mode, which could lead to a corrupted sprite appearing on the screen after a modeset (at least on my IVB). Not sure if all hardware generations would be so forgiving when enabled sprites end up outside the pipe dimensons. v2: Disable rather than enable sprites in ironlake_crtc_disable() Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add "enable" argument to intel_update_sprite_watermarksPaulo Zanoni2013-05-311-3/+5
| | | | | | | | | | | | | | | | | Because we want to call it from the "sprite disable" paths, since on Haswell we need to update the sprite watermarks when we disable sprites. For now, all this patch does is to add the "enable" argument and call intel_update_sprite_watermarks from inside ivb_disable_plane. This shouldn't change how the code behaves because on sandybridge_update_sprite_wm we just ignore the "!enable" case. The patches that implement Haswell watermarks will make use of the changes introduced by this patch. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Relax the sprite scaling limits checksVille Syrjälä2013-04-301-20/+28
| | | | | | | | | | | Reduce the size of the the src/dst viewport to keep the scalign ratios in check. v2: Below min size sprite handling squashed to previous patch Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Implement proper clipping for video spritesVille Syrjälä2013-04-301-47/+149
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Properly clip the source when the destination gets clipped by the pipe dimensions. Sadly the video sprite hardware is rather limited so it can't do proper sub-pixel postitioning. Resort to truncating the source coordinates to (macro)pixel boundary. The scaling checks are done using the strict drm_region functions. Which means that an error is returned when the min/max scaling ratios are exceeded. Also do some additional checking against various hardware limits. v2: Truncate src coords instead of rounding to avoid increasing src viewport size, and adapt to changes in drm_calc_{h,v}scale(). v3: Adapt to drm_region->drm_rect rename. Fix misaligned crtc_w for packed YUV formats when scaling isn't supported. v4: Use stricter scaling checks, use drm_rect_equals() v5: If sprite is below min size, make it invisible instead returning an error. Use WARN_ON() instead if BUG_ON(), and add one to sanity check the src viewport size. v6: Add comments to remind about src and dst coordinate types Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Ivybridge is the odd one when it comes to pipe scalersDamien Lespiau2013-04-251-5/+6
| | | | | | | | | | | | | Between ivb, hsw and vlv, only Ivybridge has sprites with scaling capabilities. Also make max_downscale coherent with that. v2: Rebase on top of the recent ivb/vlv/hsw sprite scaling fixes. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (v1) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: sprite support for ValleyView v4Jesse Barnes2013-04-021-9/+204
| | | | | | | | | | | | | | | | | | | No constant alpha yet though, that needs a new ioctl and/or property to get/set. v2: use drm_plane_format_cpp (Ville) fix up vlv_disable_plane, remove IVB bits (Ville) remove error path rework (Ville) fix component order confusion (Ville) clean up platform init (Ville) use compute_offset_xtiled (Ville) v3: fix up more format confusion (Ville) update to new page offset function (Ville) v4: remove incorrect formats from framebuffer_init (Ville) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Wait for vblank between disabling a sprite and unpinning the fbVille Syrjälä2013-03-271-0/+2
| | | | | | | | | When disabling a sprite, wait for the sprite to stop fetching data from memory before unpinning the fb. 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>
* drm/i915: Apply alignment restrictions on scanout surfaces for VT-dChris Wilson2013-03-271-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From the w/a database: 'To prevent false VT-d type 6 error: The primary display plane must be 256KiB aligned, and require an extra 128 PTEs of padding afterward; The sprites planes must be 128KiB aligned, and require an extra 64 PTEs of padding afterward; The cursors must be 64KiB aligned, and require an extra 2 PTEs of padding afterward.' As we use the same function to pin the primary and sprite planes, we can simply use the more strict requirements for scanouts for both. Instead of using explicit padding PTEs following the scanout objects, we should be able to use the scratch page that is always mapped into the unused PTEs to avoid the VT-d error. References: https://bugs.freedesktop.org/show_bug.cgi?id=59626 References: https://bugs.freedesktop.org/show_bug.cgi?id=59627 References: https://bugs.freedesktop.org/show_bug.cgi?id=59631 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: Apply s/vtd_wa/vtd_scanout_wa/ bikeshed since Damien likes it, too.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add sprite restore function v3Jesse Barnes2013-03-261-0/+23
| | | | | | | | | | | To be used to restore sprite state on resume. v2: move sprite tracking bits up so we don't track modified sprite state v3: use src_x/y in sprite suspend/resume code (Ville) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Handle untiled planes when computing their offsetsChris Wilson2013-02-211-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | We trim the fb to fit the CRTC by computing the offset of that CRTC to its nearest tile_row origin. This allows us to use framebuffers that are larger than the CRTC limits without additional work. However, we failed to compute the offset for a linear framebuffer correctly as we treated its x-advance in whole tiles (instead of the linear increment expected), leaving the CRTC misaligned with its contents. Fixes regression from commit c2c75131244507c93f812862fdbd4f3a37139401 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Jul 5 12:17:30 2012 +0200 drm/i915: adjust framebuffer base address on gen4+ v2: Adjust relative x-coordinate after linear alignment (vsyrjala) v3: Repaint with pokadots (vsyrjala) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61152 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Implement pipe CSC based limited range RGB outputVille Syrjälä2013-02-201-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | HSW no longer has the PIPECONF bit for limited range RGB output. Instead the pipe CSC unit must be used to perform that task. The CSC pre offset are set to 0, since the incoming data is full [0:255] range RGB, the coefficients are programmed to compress the data into [0:219] range, and then we use either the CSC_MODE black screen offset bit, or the CSC post offsets to shift the data to the correct [16:235] range. Also have to change the confiuration of all planes so that the data is sent through the pipe CSC unit. For simplicity send the plane data through the pipe CSC unit always, and in case full range output is requested, the pipe CSC unit is set up with an identity transform to pass the plane data through unchanged. I've been told by some hardware people that the use of the pipe CSC unit shouldn't result in any measurable increase in power consumption numbers. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix sprite_scaling_enabled for multiple spritesVille Syrjälä2013-02-151-11/+16
| | | | | | | | | | | | | | We have more than one sprite, so a boolean simply won't cut it. Turn sprite_scaling_enabled into a bitmask and track the state of sprite scaler for each sprite independently. Also don't re-enable LP watermarks until the sprite registers have actually been written, and thus sprite scaling has really been disabled. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: use drm_modeset_lock_allDaniel Vetter2013-01-201-4/+4
| | | | | | | | | | | Two exceptions: - debugfs files only read information which is not related to crtc, so can stay on the modeset_config lock. - Same holds for the edp vdd work in intel_dp.c. Add a corresponding WARN_ON and a comment next to the intel_dp struct fields for documentation. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Use pixel size for computing linear offsets into a spriteChris Wilson2013-01-091-6/+4Star
| | | | | | | | | | | | | | | | | | | This fixes an original bug in the sprite code that miscomputed the source offset into a linear YUV packed framebuffer, that was magnified into an oops with commit 5a35e99e8162d6820013a56ad15ea8bf937af5a6 Author: Damien Lespiau <damien.lespiau@intel.com> Date: Fri Oct 26 18:20:12 2012 +0100 drm/i915: adjust sprite base address Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Bad pixel formats can't reach the sprite codeVille Syrjälä2012-11-111-6/+2Star
| | | | | | | | | | The framebuffer pixel format is already checked by the common code. So there's no way an invalid format could reach the driver. So instead of falling back to a default format, call BUG(). 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-55-g7522 (git 2.39.0) at 2024-07-12 01:35:44 +0200