- 12 Jun, 2012 2 commits
-
-
Daniel Vetter authored
We already correctly ignore bit0 on gen < 4, now we also know why ;-) I've decided that losing that single bit of precision isn't worth the trouble to sprinkle IS_PINEVIEW checks all over the backlight control code - that code is way too fragile imo. Reviewed-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
This function is supposed to be used at mode set time, so prevent against future mistakes by adding a WARN(). Based on a patch by Paulo Zanoni, with the check extracted into a little assert_hdmi_port_disabled helper added to make things self documenting and move the assert stuff out of line. [fixed up spelling goof-up while applying.] Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-Off-by:
-
- 06 Jun, 2012 4 commits
-
-
Ben Widawsky authored
Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Ben Widawsky authored
Change the ns_timeout parameter of the wait ioctl to a signed value. Doing this allows the kernel to provide an infinite wait when a timeout of less than 0 is provided. This mimics select/poll. Initially the parameter was meant to match up with the GL spec 1:1, but after being made aware of how much 2^64 - 1 nanoseconds actually is, I do not think anyone will ever notice the loss of 1 bit. The infinite timeout on waiting is similar to the existing i915 userspace interface with the exception that struct_mutex is dropped while doing the wait in this ioctl. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Daniel Vetter authored
Let's be a bit more paranoid here. Reviewed-by:
-
Daniel Vetter authored
Bspec Vol 3, Part 3, Section 3.8.1.1, bit 30: "[DevIBX] Writing to this bit only takes effect when port is enabled. Due to hardware issue it is required that this bit be cleared when port is disabled. To clear this bit software must temporarily enable this port on transcoder A." Unfortunately the public Bspec misses totally out on the same language for HDMIB. Internal Bspec also mentions that one of the bad side-effects is that DPx can fail to light up on transcoder A if HDMIx is disabled but using transcoder B. I've found this while reviewing Bsepc. We already implement the same workaround for the DP ports. Also replace a magic 1 with PIPE_B I've found while looking through the code. v2: Implement suggestions from Chris Wilson: - add pipe variable to cut down on code noise - write the reg value twice to w/a hw issues (Bspec is unclear on which bit actually require the write twice stuff, but better be paranoid about it) - untangle the if logic Reviewed-by:
-
- 04 Jun, 2012 4 commits
-
-
Jesse Barnes authored
This makes for easier benchmarking and testing. One can set a fixed frequency by setting min and max to the same value. v2: fix whitespace & comment (Eugeni) Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
Eugeni Dodonov <eugeni@dodonov.net> Signed-off-by:
-
Daniel Vetter authored
We should only frob adjusted_mode. This is in preparation of a massive patch by Laurent Pinchart to make the mode argument const. After the previous two prep patches the only thing left is to clean up things a bit. I've opted to pass in an adjust_mode param to dp_adjust_dithering because that way we can be sure to avoid duplicating this logic between mode_valid and mode_fixup - which was the cause behind a dp link bw calculation bug in the past. Also mark the mode argument of pch_panel_fitting const. v2: Split up the mode->clock => adjusted_mode->clock change, as suggested by Chris Wilson. Reported-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Daniel Vetter authored
... instead of changing mode->clock, which we should leave as-is. After the previous patch we only touch that if it's a panel, and then adjusted mode->clock equals adjusted_mode->clock. Outside of intel_dp.c we only use ajusted_mode->clock in the mode_set functions. Within intel_dp.c we only use it to calculate the dp dithering and link bw parameters, so that's the only thing we need to fix up. As a temporary ugliness (until the cleanup in the next patch) we pass the adjusted_mode into dp_dither for both parameters (because that one still looks at mode->clock). Note that we do overwrite adjusted_mode->clock with the selected dp link clock, but that only happens after we've calculated everything we need based on the dotclock of the adjusted output configuration. Outside of intel_dp.c only intel_display.c uses adjusted_mode->clock, and that stays the same after this patch (still equals the selected dp link clock). intel_display.c also needs the actual dotclock (as target_clock), but that has been fixed up in the previous patch. v2: Adjust the debug message to also use adjusted_mode->clock. Reviewed-by:
-
Daniel Vetter authored
... instead of abusing mode->clock by storing it in there - we shouldn't touch that one at all. This patch is the first prep step to constify the mode argument of the intel_dp_mode_fixup function. The next patch will stop us from modifying mode->clock. Reviewed-by:
-
- 02 Jun, 2012 1 commit
-
-
Daniel Vetter authored
Both busy_ioctl and the new wait_ioct need to do the same dance (or at least should). Some slight changes: - busy_ioctl now unconditionally checks for olr. Before emitting a require flush would have prevent the olr check and hence required a second call to the busy ioctl to really emit the request. - the timeout wait now also retires request. Not really required for abi-reasons, but makes a notch more sense imo. I've tested this by pimping the i-g-t test some more and also checking the polling behviour of the wait_rendering_timeout ioctl versus what busy_ioctl returns. v2: Too many people complained about unplug, new color is flush_active. v3: Kill the comment about the unplug moniker. v4: s/un-active/inactive/ Reviewed-by:
-
- 01 Jun, 2012 5 commits
-
-
Daniel Vetter authored
Instead of checking for !CPT, check for IBX to make it clearer that this is a IBX-specific workaround. No functional change because we smash the PPT PCH into the HAS_PCH_CPT check and atm DP isn't enabled on the haswell LPT PCH yet. See Bspec Vol 3, Part 3, Section 4.[3-5].1 about DP[BCD], bit 30 for details of this workaround. Reviewed-by:
-
Daniel Vetter authored
We need the latest dma-buf code from Dave Airlie so that we can pimp the backing storage handling code in drm/i915 with Chris Wilson's unbound tracking and stolen mem backed gem object code. Signed-Off-by: -
Daniel Vetter authored
Positively checking for the required feature/gen is simpler than build a cascade of negative "we need to bail" checks. And the later won't scale if we add more stuff that doesn't fit in nicely. Reviewed-by:
-
Daniel Vetter authored
This fixes an (albeit really hard to hit) race resulting in an oops: - The parity work get scheduled. - We re-init the irq state and call INIT_WORK again. - The workqueue code tries to run the work item and stumbles over a work item that should be on it's runlist. Also initiliaze the work item unconditionally like all the others, it's simpler. Reviewed-by:
-
Daniel Vetter authored
Notice by Fengguang Wu's automatic sparse checker. Reported-by:
Fengguang Wu <wfg@linux.intel.com> Reviewed-by:
-
- 31 May, 2012 14 commits
-
-
Dave Airlie authored
This is the same as the nouveau code pretty much. Signed-off-by:Dave Airlie <airlied@redhat.com>
-
Dave Airlie authored
Tested sharing to udl. Signed-off-by: -
Dave Airlie authored
This allows udl to get a vmapping of an imported buffer for scanout. Signed-off-by: -
Dave Airlie authored
This is used to export a vmapping to the udl driver so that i915 and udl can share the udl scanout. Signed-off-by: -
Dave Airlie authored
This just adds a stub until we have pieces in place to test a correct one. Signed-off-by: -
Dave Airlie authored
This just adds a stub until we have some users in place to test this with. Signed-off-by: -
Dave Airlie authored
This just adds a stub for now, until we have some users in place to test this functionality properly. Signed-off-by: -
Ben Widawsky authored
Dumb binary interfaces which allow root-only updates of the cache remapping registers. As mentioned in a previous patch, software using this interface needs to know about HW limits, and other programming considerations as the kernel interface does no checking for these things on the root-only interface. v1: Drop extra posting reads (Chris) Return negative values in the sysfs interfaces on errors (Chris) v2: Return -EINVAL for offset % 4 (Jesse) Move schizo userspace check out (Jesse) Cleaner sysfs item initializers (Daniel) Signed-off-by:
-
Ben Widawsky authored
If any l3 rows have been previously remapped, we must remap them after GPU reset/resume too. v2: Just return (no warn) on remapping init if not IVB (Jesse) Move the check of schizo userspace to i915_gem_l3_remap (Jesse) Signed-off-by:
-
Ben Widawsky authored
The previous patch put all the code, and handlers in place. It should now be safe to enable the parity error interrupt. The parity error must be unmasked in both the GTIMR, and the CS IMR. Unfortunately, the docs aren't clear about this; nevertheless it's the truth. Reviewed-by:
-
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:
-
Daniel Vetter authored
A 30 ms delay is simply way too big to waste cpu cycles on. Acked-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:
-
- 30 May, 2012 10 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 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:
-
