- 21 10月, 2011 19 次提交
-
-
由 Ben Widawsky 提交于
Add the addresses and definitions I care about for Panel Self Refresh, as documented in the eDP spec. I'm sending these out before some other patches because this should be a fairly simple one to get upstream and not require too much fuss (where the others may have some fuss). This file is a mess with white spacing. I tried to stay consistent with the surrounding code. v2: had some silly mistakes in v1 which Keith caught Cc: Dave Airlie <airlied@redhat.com> Cc: Keith Packard <keithp@keithp.com> Signed-off-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Ben Widawsky 提交于
Idle the GPU before doing any unmaps. We know if VT-d is in use through an exported variable from iommu code. This should avoid a known HW issue. Signed-off-by: NBen Widawsky <ben@bwidawsk.net> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Ben Widawsky 提交于
[Description from: Daniel Vetter] I've just discussed this quickly with Chris on irc and it's probably best to just kill the list_empty early bailout. gpu_idle isn't a fastpath, so who cares. One candidate where we emit commands to the ring without adding anything onto these lists is e.g. pageflip. There are probably more. Signed-off-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 David Woodhouse 提交于
We really don't want this to work in the general case; device drivers *shouldn't* care whether they are behind an IOMMU or not. But the integrated graphics is a special case, because the IOMMU and the GTT are all kind of smashed into one and generally horrifically buggy, so it's reasonable for the graphics driver to want to know when the IOMMU is active for the graphics hardware. Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com> Signed-off-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 David Woodhouse 提交于
To work around a hardware issue, we have to submit IOTLB flushes while the graphics engine is idle. The graphics driver will (we hope) go to great lengths to ensure that it gets that right on the affected chipset(s)... so let's not screw it over by deferring the unmap and doing it later. That wouldn't be very helpful. Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com> Signed-off-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Daniel Vetter 提交于
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Daniel Vetter 提交于
For the !HAVE_ATOMIC_IOMAP case the stub functions did not call pagefault_disable/_enable. The i915 driver relies on the map actually being atomic, otherwise it can deadlock with it's own pagefault handler in the gtt pwrite fastpath. This is exercised by gem_mmap_gtt from the intel-gpu-toosl gem testsuite. v2: Chris Wilson noted the lack of an include. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38115 Cc: stable@kernel.org Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Chris Wilson 提交于
We currently only round up the userspace size to the next page. We assume that userspace hasn't made a mistake and requested a zero-length gem object and all through our internal code we then presume that every object is backed by at least a single page. Fix that oversight and report EINVAL back to userspace if they try to create a zero length object. [danvet: This fixes tests/gem_bad_length] Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Daniel Vetter 提交于
Use the helper function already employed by the pwrite/pread functions. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Daniel Vetter 提交于
Fixes tests/gem_tiled_pread on my snb. I know, mesa doesn't use this on gen6+, but I also hate failing testcases. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Daniel Vetter 提交于
The rps disabling code wasn't properly cancelling outstanding work items. Also add a comment that explains why we're not racing with the work item that could unmask interrupts - that piece of code confused me quite a bit. v2: Ben Widawsky pointed out that the first patch would deadlock (and a few lesser problems). All corrected. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NBen Widawsky <ben@bwidawsk.net> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Daniel Vetter 提交于
This patch closes the following race: We get a PM interrupt A, mask it, set dev_priv->iir = PM_A and kick of the work item. Scheduler isn't grumpy, so the work queue takes rps_lock, grabs pm_iir = dev_priv->pm_iir and pm_imr = READ(PMIMR). Note that pm_imr == pm_iir because we've just masked the interrupt we've got. Now hw sends out PM interrupt B (not masked), we process it and mask it. Later on the irq handler also clears PMIIR. Then the work item proceeds and at the end clears PMIMR. Because (local) pm_imr == pm_iir we have pm_imr & ~pm_iir == 0 so all interrupts are enabled. Hardware is still interrupt-happy, and sends out a new PM interrupt B. PMIMR doesn't mask B (it does not mask anything), PMIIR is cleared, so we get it and hit the WARN in the interrupt handler (because dev_priv->pm_iir == PM_B). That's why I've moved the WRITE(PMIMR, 0) up under the protection of the rps_lock. And write an uncoditional 0 to PMIMR, because that's what we'll do anyway. This races looks much more likely because we can arbitrarily extend the window by grabing dev->struct mutex right after the irq handler has processed the first PM_B interrupt. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Daniel Vetter 提交于
Quoting Chris Wilson's more concise description: "Ah I think I see the problem. As you point out we only mask the current interrupt received, so that if we have a task pending (and so IMR != 0) we actually unmask the pending interrupt and so could receive it again before the tasklet is finally kicked off by the grumpy scheduler." We need the hw to issue PM interrupts A, B, A while the scheduler is hating us and refuses to run the rps work item. On receiving PM interrupt A we hit the WARN because dev_priv->pm_iir == PM_A | PM_B Also add a posting read as suggested by Chris to ensure proper ordering of the writes to PMIMR and PMIIR. Just in case somebody weakens write ordering. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NBen Widawsky <ben@bwidawsk.net> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Adam Jackson 提交于
Signed-off-by: NAdam Jackson <ajax@redhat.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Adam Jackson 提交于
This is general TMDS detect, not HDMI specifically. Signed-off-by: NAdam Jackson <ajax@redhat.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Adam Jackson 提交于
I can't think of any sensible reason to limit this to a mask of 0x0f, ie, SDVO_OUTPUT_{TMDS,RGB,CVBS,SVID}0. Signed-off-by: NAdam Jackson <ajax@redhat.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Adam Jackson 提交于
I have no evidence for this byte being used this way, and lots of counterexamples. Restore the struct to its empirical definition and patch up gmbus setup to match. Signed-off-by: NAdam Jackson <ajax@redhat.com> Acked-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Keith Packard 提交于
-
由 Keith Packard 提交于
Conflicts: drivers/gpu/drm/i915/intel_dp.c Just whitespace change conflicts
-
- 13 10月, 2011 2 次提交
-
-
由 Keith Packard 提交于
If the panel is powered up, there's no need to delay for the 'off' interval when turning the panel on. Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Keith Packard 提交于
This eliminates a fairly long delay when power sequencing newer hardware Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 06 10月, 2011 10 次提交
-
-
由 Keith Packard 提交于
There's no good reason to turn off the eDP force VDD bit synchronously while probing devices; that just sticks a huge delay into all mode setting paths. Instead, queue a delayed work proc to disable the VDD force bit and then remember when that fires to ensure that the appropriate delay is respected before trying to turn it back on. Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Keith Packard 提交于
We need to check eDP VDD force and panel on in several places, so create some simple helper functions to avoid duplicating code. Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Keith Packard 提交于
The return value was unused, so just stop doing that. Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Keith Packard 提交于
This value doesn't come directly from the VBT, and so is rather specific to the particular DP output. Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Keith Packard 提交于
Store the panel power sequencing delays in the dp private structure, rather than the global device structure. Who knows, maybe we'll get more than one eDP device in the future. From the eDP spec, we need the following numbers: T1 + T3 Power on to Aux Channel operation (panel_power_up_delay) This marks how long it takes the panel to boot up and get ready to receive aux channel communications. T8 Video signal to backlight on (backlight_on_delay) Once a valid video signal is being sent to the device, it can take a while before the panel is actuall showing useful data. This delay allows the panel to get something reasonable up before the backlight is turned on. T9 Backlight off to video off (backlight_off_delay) Turning the backlight off can take a moment, so this delay makes sure there is still valid video data on the screen. T10 Video off to power off (panel_power_down_delay) Presumably this delay allows the panel to perform an orderly shutdown of the display. T11 + T12 Power off to power on (panel_power_cycle_delay) So, once you turn the panel off, you have to wait a while before you can turn it back on. This delay is usually the longest in the entire sequence. Neither the VBIOS source code nor the hardware documentation has a clear mapping between the delay values they provide and those required by the eDP spec. The VBIOS code actually uses two different labels for the delay values in the five words of the relevant VBT table. **** MORE LATER *** Look at both the current hardware register settings and the VBT specified panel power sequencing timings. Use the maximum of the two delays, to make sure things work reliably. If there is no VBT data, then those values will be initialized to zero, so we'll just use the values as programmed in the hardware. Note that the BIOS just fetches delays from the VBT table to place in the hardware registers, so we should get the same values from both places, except for rounding. VBT doesn't provide any values for T1 or T2, so we'll always just use the hardware value for that. The panel power up delay is thus T1 + T2 + T3, which should be sufficient in all cases. The panel power down delay is T1 + T2 + T12, using T1+T2 as a proxy for T11, which isn't available anywhere. For the backlight delays, the eDP spec says T6 + T8 is the delay from the end of link training to backlight on and T9 is the delay from backlight off until video off. The hardware provides a 'backlight on' delay, which I'm taking to be T6 + T8 while the VBT provides something called 'T7', which I'm assuming is s On the macbook air I'm testing with, this yields a power-up delay of over 200ms and a power-down delay of over 600ms. It all works now, but we're frobbing these power controls several times during mode setting, making the whole process take an awfully long time. Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Keith Packard 提交于
Any call to intel_dp_sink_dpms must ensure that the panel has power so that the DP_SET_POWER operation will be correctly received. The only one missing this was in intel_dp_prepare. Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Keith Packard 提交于
The DP i2c initialization code does a couple of i2c transactions, which means that an eDP panel must be powered up. Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Keith Packard 提交于
Talking to the eDP DDC channel requires that the panel be powered up. Wrap both the EDID and modes fetch code with calls to turn the vdd power on and back off. Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Keith Packard 提交于
On eDP, DDC requires panel power, but turning that on uses the panel power sequencing timing values fetch from the DPCD data. Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Keith Packard 提交于
If the panel is already off, we'll need to turn VDD on to execute the (useless) DPMS off code. Yes, it would be better to just not do any of this, but correctness, and *then* performance. Signed-off-by: NKeith Packard <keithp@keithp.com>
-
- 01 10月, 2011 7 次提交
-
-
由 Keith Packard 提交于
The VDD force bit is turned on before touching the panel, but if it was enabled, there was no call to turn it back off. Add a call. Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Keith Packard 提交于
Cleans up code dealing with eDP a bit. Remove redundant checks in callers Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Keith Packard 提交于
Avoid any question about locked registers by just writing the unlock pattern with every write to the register. Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Keith Packard 提交于
Verify that the eDP VDD is on, either with the panel being on or with the VDD force-on bit being set. This demonstrates that in many instances, VDD is not on when needed, which leads to failed EDID communications. Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Keith Packard 提交于
We're going to assume that EDID is more reliable than the VBT tables for eDP panels, which is notably true on MacBook machines where the VBT contains completely bogus data. Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Keith Packard 提交于
This masks out all interrupts and ack's any pending ones at IRQ uninstall time to make sure we don't receive any unexpected interrupts later on. Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Keith Packard 提交于
We were relying on the BIOS to set these bits, which doesn't always happen. Signed-off-by: NKeith Packard <keithp@keithp.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 29 9月, 2011 2 次提交
-
-
由 Keith Packard 提交于
-
由 Keith Packard 提交于
The reference clock configuration must be done before any mode setting can occur as all outputs must be disabled to change anything. Initialize the clocks after turning everything off during the initialization process. Also, re-initialize the refclk at resume time. Signed-off-by: NKeith Packard <keithp@keithp.com>
-