- 15 Apr, 2012 2 commits
-
-
Daniel Vetter authored
... we will botch up the bit17 swizzling. Furthermore tiled pwrite is a (now) unused slowpath, so no one really cares. This fixes the last swizzling issues I have with i-g-t on my bit17 swizzling i915G. No regression, it's been broken since the dawn of gem, but it's nice for regression tracking when really _all_ i-g-t tests work. Actually this is not true, Chris Wilson noticed while reviewing this patch that the commit commit d9e86c0e Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Nov 10 16:40:20 2010 +0000 drm/i915: Pipelined fencing [infrastructure] contained a functional change that broke things. Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
On the first instance we just wish to kick the waiters and see if that terminates the wait conditions. If it does not, then we do not want to keep retrying without ever making any forward progress and becoming stuck in a hangcheck loop. Reported-and-tested-by:
Lukas Hejtmanek <xhejtman@fi.muni.cz> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48209Reviewed-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
- 13 Apr, 2012 16 commits
-
-
Daniel Kurtz authored
Some of these messages can be hit when userspace tries to probe the i2c with nothing connected or if the driver code tries to do the same. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48248Signed-off-by:
Daniel Kurtz <djkurtz@chromium.org> Signed-Off-by:
-
Daniel Kurtz authored
A common method of probing an i2c bus is trying to do a zero-length read. Handle this case by checking the length first waiting for data to be read. This is actually important, since attempting a zero-length read is one of the ways that i2cdetect and i2c_new_probed_device detect whether there is device present on the bus with a given address. Reviewed-by:
-
Daniel Vetter authored
Now that these are properly refactored this additional indirection doesn't really buy us anything but confusion. Hence inline them. This duplicates the ironlake gt enable/disable code snippet, but we've already separate ilk from gen6+ gt irq in i915_irq.c, so I think this makes more sense. Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-Off-by:
-
Daniel Vetter authored
We already disallow initialition of gem in this case in the corresponding ioctl, so don't bother setting up the gem support ring functions in the legacy dri render ring init. Reviewed-by:
-
Daniel Vetter authored
They're indentical, so just kill one. Also give the other a prefix to distinguish it from the gen6+ functions - this add_request function is not really generic code. v2: Fixup commit message as noted by Ben Widawsky. Reviewed-by:
-
Daniel Vetter authored
Now that we can, we should split them up in a way that makes some sense and banishes the IS_ checks into init code. Reviewed-by:
-
Daniel Vetter authored
HW engineers have fixed this issue for ivb. Again, a nice cleanup possible thanks to the more flexible ring initialization. Reviewed-by:
-
Daniel Vetter authored
Now that we have sensibly split up, we can nicely get rid of that ugly is_gen5 check. Reviewed-by:
-
Daniel Vetter authored
Inspired by Ben Widawsky's patch for gen6+. Now after restructuring how we set up the ring vtables and parameters, we can do this right. This kills the bsd specific get/put_irq functions, they're now the same. Reviewed-by:
-
Daniel Vetter authored
The waiter is always the ring itself (otherwise we'd have a decent snafu in a callsite), so we can unify this easily. Also give it the usual gen6_ prefix, in case anyone is foolish enough to implement hw semaphores for gen5. Reviewed-by:
-
Daniel Vetter authored
It's not supported, and with the patch to refuse loading on gen6+ without kms enabled, there's also no way we can hit this. Reviewed-by:
-
Daniel Vetter authored
Just for consistency. Reviewed-by:
-
Daniel Vetter authored
The same treatment for the bsd ring. Again, this will be split up further by the irq rework. Reviewed-by:
-
Daniel Vetter authored
Our hw is simply not well-designed enough that it neatly fits into boxes. Everywhere else we set up vtables and similar things dynamically using switch statements - it's simply much more flexible. This is prep work to rework the pre-gen6 ring irq stuff - it'll add a few more differences. With the current const struct templates, that would be a mess. This leads to some unfortunate duplication with the old dri1 code, but we can reap that again because gen6 isn't actually supported there. But that's for a separate patch. Reviewed-by:
-
Daniel Vetter authored
Eventually we want to scale the ring size depending upon available gtt space. For now just consolidate this instead of replicating it over all ringbuffer templates. Reviewed-by:
-
Daniel Vetter authored
We only ever enable/disable one interrupt (namely user_interrupts and pipe_notify), so we don't need to track the interrupt masking state. Also rename irq_enable to irq_enable_mask, now that it won't collide - beforehand both a irq_mask and irq_enable_mask would have looked a bit strange. Reviewed-by:
-
- 12 Apr, 2012 22 commits
-
-
Ben Widawsky authored
Waiting for seqno-1 in our object synchronization code is an implementation detail given how we've decided to do the waits within the rest of our code. Requested-by:
Ben Widawsky <benjamin.widawsky@intel.com> Reviewed-by:
-
Ben Widawsky authored
This fixes a long standing issue where emitting the semaphore updates may have failed, but we've already updated our internal data structure. Reported-by:
-
Ben Widawsky authored
When I extracted the synchronization code for implementing semaphorified pageflips (74f5f6e0), I neglected the non pipelined case which also calls this code. The modesetting code wants to make sure the object has finished rendering to the frame before configuring the scanout (ie. non-pipelined case). As a result of a follow on discussion on IRC, I've decided to add a comment about the function itself which received much inspiration from Chris as well. So really, this patch was ghost-written by Chris :). Reported-by:
-
Jesse Barnes authored
On IVB, there are two sets of panel backlight regs: one in the CPU and one in the PCH. The CPU ones aren't generally used, so on IVB make sure we allow the PCH regs to actually control the backlight. v2: remove unused pwm variable (Daniel) move to init_hw function so we override on resume too Signed-off-by:Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Jesse Barnes authored
We'll probably need new init functions and will need to test it. v2: fix impossible GEN6 && GEN7 condition, move to Daniel's new init function Signed-off-by:
-
Jesse Barnes authored
If these regs don't have valid values, the panel won't come up, and may even cause a system hang. So do a basic sanity check when an eDP panel is detected. Signed-off-by:
-
Daniel Vetter authored
After a gpu reset we need to re-init some of the hw state we only initialize when modeset is enabled, like rc6, hw contexts or render/GT core clock gating and workaround register settings. Note that this patch has a small change in the resume code: - rc6 on gen6+ is only restored for the modeset case (for more consistency with other callsites). This is no problem because recent kernels refuse to load drm/i915 without kms on gen6+ - rc6/emon on ilk is only restored for the modeset case. This is no problem because rc6 is disabled by default on ilk, and ums on ilk has never really been a supported option outside of horrible rhel backports. v2: Chris Wilson noticed that we not only fail to restore the clock gating settings after gpu reset. v3: Move the call to modeset_init_hw in _reset out of the struct_mutext protected area - other callers don't hold it, too. Reviewed-by:
-
Chris Wilson authored
Similar to allowing a buffer to be simultaneously read by the GPU and through the GTT, we wish to allow readback of the pages through the CPU domain whilst they are also being read by the GPU. Domain coherency is managed by allowing multiple readers, but only a single writer. This is used by mesa for its program cache which it may search for every new program every frame and then renews should it need to add. During renewal, mesa copies the program bo currently executing through a CPU mapping onto the new bo. This patch allows the search and that copy to proceed without causing a stall on the current batch. Testcase: i-g-t/tests/gem_cpu_concurrent_blit Signed-off-by:
-
Daniel Vetter authored
We don't need the pt_addr for the !dmar case, so drop the else and move the if (dmar) condition out of the loop. v2: Fixup whitespace damage noticed by Chris Wilson. v3: Collapse the two identical if blocks. Chris Wilson makes me look like a moron right now ... Noticed-by:
Konstantin Belousov <kostikbel@gmail.com> Reviewed-by:
Chris Wilson <chris@chris-wislon.co.uk> Signed-Off-by:
-
Jesse Barnes authored
Both PCH and CPU eDP are DP, so set the is_dp flag to true. Add is_cpu_edp and is_pch_edp bools to make checking for each less verbose (rather than has_edp_encoder && !intel_encoder_is_pch_edp() sprinkled everywhere). And rename the "has_edp_encoder" variable to just "edp_encoder". With the above variables cleaned up, the rest of the code becomes a bit more readable and clear. Signed-off-by:
-
Ben Widawsky authored
Merge rc6 information into the power group for our device. Until now the i915 driver has not had any sysfs entries (aside from the connector stuff enabled by drm core). Since it seems like we're likely to have more in the future I created a new file for sysfs stubs, as well as the rc6 sysfs functions which don't really belong elsewhere (perhaps i915_suspend, but most of the stuff is in intel_display,c). displays rc6 modes enabled (as a hex mask): cat /sys/class/drm/card0/power/rc6_enable displays #ms GPU has been in rc6 since boot: cat /sys/class/drm/card0/power/rc6_residency_ms displays #ms GPU has been in deep rc6 since boot: cat /sys/class/drm/card0/power/rc6p_residency_ms displays #ms GPU has been in deepest rc6 since boot: cat /sys/class/drm/card0/power/rc6pp_residency_ms Important note: I've seen on SNB that even when RC6 is *not* enabled the rc6 register seems to have a random value in it. I can only guess at the reason reason for this. Those writing tools that utilize this value need to be careful and probably want to scrutinize the value very carefully. v2: use common rc6 residency units to milliseconds for the other RC6 types v3: don't create sysfs files for GEN <= 5 add a rc6_enable to show a mask of enabled rc6 types use unmerge instead of remove for sysfs group squash intel_enable_rc6() extraction into this patch v4: rename sysfs files (Chris) CC: Chris Wilson <chris@chris-wilson.co.uk> CC: Daniel Vetter <daniel.vetter@ffwll.ch>f CC: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
Well, almost. Just a couple of differences, Ironlake lacks a few of the RGB formats, only exposing x8r8g8b8, and lacks a couple of unused features. Given the similarities, we can then reuse the same routines as already written for Sandybridge to enable overlay support for Ironlake as well. Signed-off-by:
-
Daniel Kurtz authored
The POSTING_READ() calls were originally added to make sure the writes were flushed before any timing delays and across loops. Now that the code has settled a bit, let's remove them. Signed-off-by:
-
Daniel Kurtz authored
Save the GMBUS2 value read while polling for state changes, and then reuse this value when determining for which reason the loops were exited. This is a small optimization which saves a couple of bus accesses for memory mapped IO registers. To avoid "assigning in if clause" checkpatch errors", use a ret variable to store the wait_for macro return value. Signed-off-by:
-
Daniel Kurtz authored
It is very common for an i2c device to require a small 1 or 2 byte write followed by a read. For example, when reading from an i2c EEPROM it is common to write and address, offset or index followed by a reading some values. The i915 gmbus controller provides a special "INDEX" cycle for performing such a small write followed by a read. The INDEX can be either one or two bytes long. The advantage of using such a cycle is that the CPU has slightly less work to do once the read with INDEX cycle is started. Signed-off-by:
-
Daniel Kurtz authored
The i915 is only able to generate a STOP cycle (i.e. finalize an i2c transaction) during a DATA or WAIT phase. In other words, the controller rejects a STOP requested as part of the first transaction in a sequence. Thus, for the first transaction we must always use a WAIT cycle, detect when the device has finished (and is in a WAIT phase), and then either start the next transaction, or, if there are no more transactions, generate a STOP cycle. Note: Theoretically, the last transaction of a multi-transaction sequence could initiate a STOP cycle. However, this slight optimization is left for another patch. We return -ETIMEDOUT if the hardware doesn't deactivate after the STOP cycle. Signed-off-by:
-
Daniel Kurtz authored
The GMBUS controller can report a NAK condition while a transaction is still active. If the driver is fast enough, and the bus is slow enough, the driver may clear the NAK condition while the controller is still busy, resulting in a confused GMBUS controller. This will leave the controller in a bad state such that the next transaction may fail. Also, return -ENXIO if a device NAKs a transaction. Note: this patch also refactors gmbus_xfer to remove the "done" label. Signed-off-by:
-
Daniel Kurtz authored
The GMBUS controller GMBUS3 register is double-buffered. Take advantage of this by writing two 4-byte words before the first wait for HW_RDY. This helps keep the GMBUS controller from becoming idle during long writes. In fact, during experiments using the GMBUS interrupts, the HW_RDY interrupt would only trigger for transactions >4 bytes after 2 writes to GMBUS3. Signed-off-by:
-
Daniel Kurtz authored
A common method of probing an i2c bus is trying to do a zero-length write. Handle this case by checking the length first before decrementing it. This is actually important, since attempting a zero-length write is one of the ways that i2cdetect and i2c_new_probed_device detect whether there is device present on the bus with a given address. Signed-off-by:
-
Jesse Barnes authored
Just noticed this while verifying the VGA disable code. Signed-off-by:
-
Ben Widawsky authored
In theory this will have performance and power improvements. Performance because we don't need to stall when the scanout BO is busy, and power because we don't have to stall when the BO is busy (and the ring can even go to sleep if the HW supports it). v2: squash 2 patches into 1 (me) un-inline the enable_semaphores function (Daniel) remove comment about SNB hangs from i915_gem_object_sync (Chris) rename intel_enable_semaphores to i915_semaphore_is_enabled (me) removed page flip comment; "no why" (Chris) To address other comments from Daniel (irc): update the comment to say 'vt-d is crap, don't enable semaphores' - I think you misinterpreted Chris' comment, it already exists. checking out whether we can pageflip on the render ring on ivb (didn't work on early silicon) - We don't want to enable workarounds for early silicon unless we have to. - I can't find any references in the docs about this. optionally use it if the fb is already busy on the render ring - This should be how the code already worked, unless I am misunderstanding your meaning. Signed-off-by: -
Chris Wilson authored
By simplifying the rules to calling get_fence when writing to the through the GTT in a tiled manner, and calling put_fence before writing to the object through the GTT in a linear manner, the code becomes clearer and there is less chance of making a mistake. Signed-off-by:
-
