- 31 May, 2012 4 commits
-
-
Ben Widawsky authored
On IVB hardware we are given an interrupt whenever a L3 parity error occurs in the L3 cache. The L3 cache is used by internal GPU clients only. This is a very rare occurrence (in fact to test this I need to use specially instrumented silicon). When a row in the L3 cache detects a parity error the HW generates an interrupt. The interrupt is masked in GTIMR until we get a chance to read some registers and alert userspace via a uevent. With this information userspace can use a sysfs interface (follow-up patch) to remap those rows. Way above my level of understanding, but if a given row fails, it is statistically more likely to fail again than a row which has not failed. Therefore it is desirable for an operating system to maintain a lifelong list of failing rows and always remap any bad rows on driver load. Hardware limits the number of rows that are remappable per bank/subbank, and should more than that many rows detect parity errors, software should maintain a list of the most frequent errors, and remap those rows. V2: Drop WARN_ON(IS_GEN6) (Jesse) DRM_DEBUG row/bank/subbank on errror (Jesse) Comment updates (Jesse) Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
A 30 ms delay is simply way too big to waste cpu cycles on. Acked-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Daniel Vetter authored
Jesse extracted this nice helper in his i9xx_crtc_mode_set refactor, but we have the identical code in ironlake_ccrtc_mode_set. And that function is huge, so extracting some code full of magic numbers is always nice. Noticed while trying to get a handle on our dp clock code. Reviewed-by:
-
Daniel Vetter authored
Already discovered in commit 5a117db7 Author: Eugeni Dodonov <eugeni.dodonov@intel.com> Date: Thu Jan 5 09:34:29 2012 -0200 drm/i915: there is no pipe CxSR on ironlake but we've failed to rip out the code from the ironlake specific code. Reviewed-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by:
-
- 30 May, 2012 11 commits
-
-
Paulo Zanoni authored
On IVB and older, we basically have two registers: the control and the data register. We write a few consecutitve times to the control register, and we need these writes to arrive exactly in the specified order. Also, when we're changing the data register, we need to guarantee that anything written to the control register already arrived (since changing the control register can change where the data register points to). Also, we need to make sure all the writes to the data register happen exactly in the specified order, and we also *can't* read the data register during this process, since reading and/or writing it will change the place it points to. So invoke the "better safe than sorry" rule and just be careful and put barriers everywhere :) On HSW we still have a control register that we write many times, but we have many data registers. Demanded-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Paulo Zanoni authored
HSW support is now just like all the other generations: we send AVI and SPD InfoFrames. There are other DIPs for HSW, but there are other DIPs for the previous generations too. For each gen, we can see which DIPs are missing by looking at the 'set_infoframes' function: we explicitly disable the DIPs we're not using. Signed-off-by:
-
Paulo Zanoni authored
The register that controls the HDMI port can be used to control the sDVO port. Some bits are defined only for sDVO, and SDVO_BORDER_ENABLE is one of those: HDMI ports that can't be used in sDVO mode don't even have this bit defined in their specifications. Signed-off-by:
-
Paulo Zanoni authored
At this time, the HDMI port is enabled, and the DIP control register specification says we need to disable the port *before* disabling the DIPs. Also, while doing this we risk telling the HW to send the AVI DIPs once (not every VSync), which really seems to confuse the HW and trigger bugs where the DIPs are not sent. This code was here just to set the DIP register to a 'known state' before using it, but since now the set_infoframes functions already set the control registers to a known state, this code can go away. Also, the previous code disables *all* the DIP registers for *each* HDMI port, so we end disabling each DIP register more than once. This patch solves a problem I can reproduce on my IVB machine. When I boot it with just a single HDMI monitor, the AVI InfoFrames are not sent. With this patch, the InfoFrames are sent. Previously, I wrote a patch to 'touch the DIP registers after we enable the HDMI port' to solve this same problem, but that patch doesn't seem to be needed anymore after this patch. All this patch does is revert a chunk of the following commit: commit 64a8fc01 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Sep 22 11:16:00 2011 +0530 drm/i915: fix ILK+ infoframe support So bugs that can be bisected to that commit may be fixed now. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43256Acked-by: -
Paulo Zanoni authored
The register specification says we need to do this. V2: Only write the register if the port is enabled. Signed-off-by:
-
Paulo Zanoni authored
From this point on, the 'set_infoframe' functions always set the DIP registers to a known state, so anything done will always be undone at the modeset. Signed-off-by:
-
Paulo Zanoni authored
This function is called when the pipe is disabled, so it always gets the 50ms timeout. This function is called once for each InfoFrame, so we actually get a 100ms timeout. Will be more if we add more InfoFrames. Also, the spec says we need to "wait for a VSync to ensure completion of any pending DIP transmissions", not for a VBlank. OTOH, the register documentation suggests that the DIPs are sent *during* the VSync, so shouldn't we be waiting until *after* the VSync to ensure all DIPs are sent? So this wait_for_vblank seems, besides useless, totally wrong. If we ever want to change some specific InfoFrame on-the-fly (outside of the modeset code), the code that changes the InfoFrame will have to do the waiting itself, and properly. Signed-off-by:
-
Paulo Zanoni authored
So the write_infoframe function can assume the DIP is on. V2: Be more defensive and add WARN(). Signed-off-by:
-
Paulo Zanoni authored
Not once for each InfoFrame. Now we have a function that allows us to do this. [danvet: Paulo clarified on irc that a later bugfix patch needs this cleanup.] Signed-off-by:
-
Paulo Zanoni authored
This solves problems that happen when you alternate between HDMI and DVI on the same port. I can reproduce these problems using DP->HDMI and DP->DVI adapters on a DP port. When you first plug HDMI and then plug DVI, you need to stop sending DIPs, even if the port is in DVI mode (see the HDMI register spec). If you don't stop sending DIPs, you'll see a pink vertical line on the left side of the screen, some modes will give you a black screen, some modes won't work correctly. When you first plug DVI and then plug HDMI, you need to properly enable the DIPs, otherwise the HW won't send them. After spending a lot of time investigating this, I concluded that if the DIPs are disabled, we should not write to the DIP register again because when we do this, we also set the AVI InfoFrame frequency to "once", and this seems to really confuse our hardware. Since this problem was not exactly easy to debug, I'm adopting the defensive behavior and not just avoing the "disable twice" sequence, but also explicitly selecting the AVI InfoFrame and setting its frequency to a correct one. Also, move the "is_dvi" check from intel_set_infoframe to the set_infoframes functions since now they're going to be the first ones to deal with the DIP registers. This patch adds the code to fix the problem, but it depends on the removal of some code that can't be removed right now and will come later in the patch series. The patch that we need is: - drm/i915: don't write 0 to DIP control at HDMI init [danvet: Paulo clarified that this additional patch is only required to make the fix complete, this patch here alone doesn't introduce a regression but only partially solves the problem of randomly clearing the dip registers.] V2: Be even more defensive by selecting AVI and setting its frequency outside the "is_dvi" check. Signed-off-by:
-
Paulo Zanoni authored
We need a function that is able to fully 'set' the state of the DIP registers to a known state. Currently, we have the write_infoframe function that is called twice: once for AVI and once for SPD. The problem is that write_infoframe tries to keep the state of the DIP register as it is, changing only the minimum necessary bits. The second problem is that write_infoframe does twice (once for each time it is called) some work that should be done only once (like waiting for vblank and setting the port). If we add even more DIPs, it will do even more repeated work. This patch only adds the infrastructure keeping the code behavior the same as before. v2: add static keywords Signed-off-by:
-
- 25 May, 2012 5 commits
-
-
Chris Wilson authored
Paulo pointed out that gen4 re-used the SDVO registers for HDMI (the separate HDMI registers where introduced with the first PCH) and so g4x_hdmi_connected() never selected the right bit and always returned disconnected. Regression in commit 8ec22b21 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri May 11 18:01:34 2012 +0100 drm/i915/hdmi: Query the live connector status bit for G4x Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by:
-
Ben Widawsky authored
Wait request is poorly named IMO. After working with these functions for some time, I feel it's much clearer to name the functions more appropriately. Of course we must update the callers to use the new name as well. This leaves room within our namespace for a *real* wait request function at some point. Note to maintainer: this patch is optional. Signed-off-by:
-
Ben Widawsky authored
This helps implement GL_ARB_sync but stops short of allowing full blown sync objects. Finally we can use the new timed seqno waiting function to allow userspace to wait on a buffer object with a timeout. This implements that interface. The IOCTL will take as input a buffer object handle, and a timeout in nanoseconds (flags is currently optional but will likely be used for permutations of flush operations). Users may specify 0 nanoseconds to instantly check. The wait ioctl with a timeout of 0 reimplements the busy ioctl. With any non-zero timeout parameter the wait ioctl will wait for the given number of nanoseconds on an object becoming unbusy. Since the wait itself does so holding struct_mutex the object may become re-busied before this completes. A similar but shorter race condition exists in the busy ioctl. v2: ETIME/ERESTARTSYS instead of changing to EBUSY, and EGAIN (Chris) Flush the object from the gpu write domain (Chris + Daniel) Fix leaked refcount in good case (Chris) Naturally align ioctl struct (Chris) v3: Drop lock after getting seqno to avoid ugly dance (Chris) v4: check for 0 timeout after olr check to allow polling (Chris) v5: Updated the comment. (Chris) v6: Return -ETIME instead of -EBUSY when timeout_ns is 0 (Daniel) Fix the commit message comment to be less ugly (Ben) Add a warning to check the return timespec (Ben) v7: Use DRM_AUTH for the ioctl. (Eugeni) Signed-off-by:
-
Ben Widawsky authored
The trace events adds whether or not the wait was blocking. Blocking in this case means to hold struct_mutex (ie. no new work can be submitted during the wait). The information is inherently racy. The blocking information is racy since mutex_is_locked doesn't check that the current thread holds the lock. The only other option would be to pass the boolean information of whether or not the class was blocking down through the stack which is less desirable. v2: Don't do a trace event per loop. (Chris) Only get blocking/non-blocking info (Chris) v3: updated comment in code as well as commit msg (Daniel) Add "(NB)" to trace information to remind us in 6 months (Ben) Signed-off-by:
-
Ben Widawsky authored
Insert a wait parameter in the code so we can possibly timeout on a seqno wait if need be. The code should be functionally the same as before because all the callers will continue to retry if an arbitrary timeout elapses. We'd like to have nanosecond granularity, but the only way to do this is with hrtimer, and that doesn't fit well with the needs of this code. v2: Fix rebase error (Chris) Return proper time even in wedged + signal case (Chris + Ben) Use timespec constructs (Ben) Didn't take Daniel's advice regarding the Frankenstein-ness of the function. I did try his advice, but in the end I liked the way the original code looked, better. v3: Make wakeups far less frequent for infinite waits (Chris) v4: Remove dummy_wait variable (Daniel) Use raw monotonic time instead of jiffies (made the code a bit cleaner) (Ben) Added a couple of warnings (Ben) v5: Remove warnings (Daniel) Use more accurate time diff for default case (Daniel) Bikeshed for setting the return timespec in timeout case (Daniel) s/jiffies/time in one of the comments Signed-off-by:
-
- 22 May, 2012 2 commits
-
-
Daniel Vetter authored
Unfortunately we can't abort a mode_set, but at least tell the user that something might have gone wrong when setting the sdvo input or output timing fails. Reviewed-by:
-
Daniel Vetter authored
- kill intel_sdvo->input_dtd, it's only used as a temporary variable, we store the preferred input mode in the adjusted mode at mode_fixup time. - rename the function to make it clear what we want it to do (get the preferred mode) and say in a comment what it unfortunately does as a side-effect (set the new output timings). Reviewed-by:
-
- 21 May, 2012 6 commits
-
-
Chris Wilson authored
Signed-off-by:
-
Chris Wilson authored
Similar to g4x_dp_detect() we should probe the PORT_HOTPLUG_STATUS as to whether the connector is active prior to attempting to retrieve the EDID. Signed-off-by:
-
Chris Wilson authored
Note that gen3 is the only platform where we've got the bit definitions right, hence the workaround of disabling sdvo hotplug support on i945g/gm is not due to misdiagnosis of broken hotplug irq handling ... Signed-off-by:
-
Chris Wilson authored
The status bits corresponding to the interrupt enable bits are the "live" hotplug status bits, and reflect the current status of the port (high for a detected connection, low for a disconnect). The actual bits corresponding to the interrupt source are elsewhere. The actual event is then determined by a combination of the interrupt flag and the current live status (if the interrupt is active, but the current status is not, then we have detected a disconnect.) Signed-off-by:
-
Chris Wilson authored
Also as we set the HOTPLUG_EN to 0 during pre-install, we can simply set it during post-install, and nor do we wish to enable unwanted hotplug events. Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-intel-next-2012-05-20' of git://people.freedesktop.org/~danvet/drm-intel into drm-core-next Daniel wrote: The last pull I'd like to squeeze into 3.5, safe for the hsw stuff mostly bugfixes: - last few patches for basic hsw enabling (Eugeni, infoframe support by Paulo) - Fix up infoframe support, we've hopefully squashed all the cargo-culting in there (Paulo). Among all the issues, this finally fixes some of the infoframe regressions seen on g4x and snb systems. - Fixup sdvo infoframe support, this fixes a regression from 2.6.37. - Correctly enable semaphores on snb, we've enabled it already for 3.5, but the dmar check was slightly wrong. - gen6 irq fixlets from Chris. - disable gmbus on i830, the hw seems to be simply broken. - fix up the pch pll fallout (Chris & me). - for_each_ring macro from Chris - I've figured I'll merge this now to avoid backport pain. - complain when the rps state isn't what we expect (Chris). Note that this is shockingly easy to hit and hence pretty much will cause a regression report. But it only tells us that the gpu turbo state got out of whack, a problem we know off since a long time (it cause the gpu to get stuck a a fixed frequency, usually the lowest one). Chris is working on a fix, but we haven't yet found a magic formula that works perfectly (only patches that massively reduce the frequency of this happening). - MAINTAINERS patch, I'm now officially the guy to beat up." * tag 'drm-intel-next-2012-05-20' of git://people.freedesktop.org/~danvet/drm-intel: (57 commits) drm/i915: IBX has a fixed pch pll to pch pipe mapping drm/i915: implement hsw_write_infoframe drm/i915: small hdmi coding style cleanups drm/i915: fixup infoframe support for sdvo drm/i915: Enable the PCH PLL for all generations after link training drm/i915: Convert BUG_ON(!pll->active) and friends to a WARN drm/i915: don't clobber the pipe param in sanitize_modesetting drm/i915: disable gmbus on i830 drm/i915: Replace the feature tests for BLT/BSD with ring init checks drm/i915: Check whether the ring is initialised prior to dispatch drm/i915: Introduce for_each_ring() macro drm/i915: Assert that the transcoder is indeed off before modifying it drm/i915: hook Haswell devices in place drm/i915: prepare HDMI link for Haswell drm/i915: move HDMI structs to shared location drm/i915: add WR PLL programming table drm/i915: add support for DDI-controlled digital outputs drm/i915: detect digital outputs on Haswell drm/i915: program iCLKIP on Lynx Point drm/i915: program WM_LINETIME on Haswell ...
-
- 20 May, 2012 5 commits
-
-
Daniel Vetter authored
This should fix breakage introduced in commit ee7b9f93 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Apr 20 17:11:53 2012 +0100 drm/i915: manage PCH PLLs separately from pipes v2: Add a DRM_DEBUG_KMS message to explain why a given pll was selected, suggested by Chris Wilson. v3: Actually run git add. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Paulo Zanoni authored
Both the control and data registers are completely different now. Signed-off-by:
-
Paulo Zanoni authored
- Changed the coding style of auxiliary infoframe functions to make them smaller - Fixed the column alignment of some function definitions - Remove definition of "struct drm_crtc" in some places as they're used only to retrieve "struct intel_crtc" Signed-off-by:
-
Daniel Vetter authored
At least the worst offenders: - SDVO specifies that the encoder should compute the ecc. Testing also shows that we must not send the ecc field, so copy the dip_infoframe struct to a temporay place and avoid the ecc field. This way the avi infoframe is exactly 17 bytes long, which agrees with what the spec mandates as a minimal storage capacity (with the ecc field it would be 18 bytes). - Only 17 when sending the avi infoframe. The SDVO spec explicitly says that sending more data than what the device announces results in undefined behaviour. - Add __attribute__((packed)) to the avi and spd infoframes, for otherwise they're wrongly aligned. Noticed because the avi infoframe ended up being 18 bytes large instead of 17. We haven't noticed this yet because we don't use the uint16_t fields yet (which are the only ones that would be wrongly aligned). This regression has been introduce by 3c17fe4b is the first bad commit commit 3c17fe4b Author: David Härdeman <david@hardeman.nu> Date: Fri Sep 24 21:44:32 2010 +0200 i915: enable AVI infoframe for intel_hdmi.c [v4] Patch tested on my g33 with a sdvo hdmi adaptor. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732 Tested-by: Peter Ross <pross@xvid.org> (G35 SDVO-HDMI) Reviewed-by:
-
Dave Airlie authored
Reported-by:
Jiri Slaby <jslaby@suse.cz> Reported-by:
Jonathan Nieder <jrnieder@gmail.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
- 19 May, 2012 7 commits
-
-
Chris Wilson authored
Hidden away within one chipset specific path was the necessary logic to turn on the PLL. This needs to be done everywhere in order for us to drive any display! As such as soon as we tested on a non-CougarPoint chipset, we failed to bring up any DisplayPorts and generated a nice set of assertion failures in the process. At least one part of our logic is working, the part that assumes that we have no idea what we are doing. Reported-by: guang.a.yang@intel.com References: https://bugs.freedesktop.org/show_bug.cgi?id=49712Signed-off-by:
-
Chris Wilson authored
Turn a fatal lockup into a merely blank display with lots of shouty messages. v2: Whilst in the area, convert the other BUG_ON into less fatal errors. In particular, note that we may be called on a PCH platform not using PLLs, such as Haswell, and so we do not always want to BUG_ON(!pll) Signed-off-by:
-
Daniel Vetter authored
... we need it later on in the function to clean up pipe <-> plane associations. This regression has been introduced in commit f47166d2 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Mar 22 15:00:50 2012 +0000 drm/i915: Sanitize BIOS debugging bits from PIPECONF Spotted by staring at debug output of an (as it turns out) totally unrelated bug. v2: I've totally failed to do the s/pipe/i/ correctly, spotted by Chris Wilson. Reviewed-by:
-
Daniel Vetter authored
The hw just returns garbage. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49838Reported-and-tested-by:
Vladyslav <DFEW.Entwickler@googlemail.com> Acked-by:
-
Chris Wilson authored
When userspace asks whether the driver supports the BLT or BSD rings for this chip, simply report whether those particular rings are initialised v2: Use intel_ring_initialized() Signed-off-by:
-
Chris Wilson authored
Rather than use the magic feature tests HAS_BLT/HAS_BSD just check whether the ring we are about to dispatch the execbuffer on is initialised. v2: Use intel_ring_initialized() Signed-off-by:
-
Chris Wilson authored
In many places we wish to iterate over the rings associated with the GPU, so refactor them to use a common macro. Along the way, there are a few code removals that should be side-effect free and some rearrangement which should only have a cosmetic impact, such as error-state. Note that this slightly changes the semantics in the hangcheck code: We now always cycle through all enabled rings instead of short-circuiting the logic. v2: Pull in a couple of suggestions from Ben and Daniel for intel_ring_initialized() and not removing the warning (just moving them to a new home, closer to the error). Signed-off-by:
-
