- 13 Jun, 2012 2 commits
-
-
Chris Wilson authored
As we switch on/off the primary plane if it is completely obscured by an overlapping video sprite, we also nee to make sure that we update the FBC configuration at the same time. v2: Not all crtcs are intel_crtcs, as spotted by Daniel. v3: Boot testing rules. References: https://bugs.freedesktop.org/show_bug.cgi?id=50238Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Especially vesafb likes to map everything as uc- (yikes), and if that mapping hangs around still while we try to map the gtt as wc the kernel will downgrade our request to uc-, resulting in abyssal performance. Unfortunately we can't do this as early as readon does (i.e. as the first thing we do when initializing the hw) because our fb/mmio space region moves around on a per-gen basis. So I've had to move it below the gtt initialization, but that seems to work, too. The important thing is that we do this before we set up the gtt wc mapping. Now an altogether different question is why people compile their kernels with vesafb enabled, but I guess making things just work isn't bad per se ... v2: - s/radeondrmfb/inteldrmfb/ - fix up error handling v3: Kill #ifdef X86, this is Intel after all. Noticed by Ben Widawsky. v4: Jani Nikula complained about the pointless bool primary initialization. v5: Don't oops if we can't allocate, noticed by Chris Wilson. v6: Resolve conflicts with agp rework and fixup whitespace. Reported-and-tested-by:
"Kilarski, Bernard R" <bernard.r.kilarski@intel.com> Reviewed-by:
-
- 12 Jun, 2012 11 commits
-
-
Daniel Vetter authored
When drm/i915 is in control of the gtt, we need to call the enable function at all the relevant places ourselves. Reviewed-by:
-
Daniel Vetter authored
We need this thing much earlier, and it doesn't make sense in the hw enabling function intel_enable_gtt - this does not change over a suspend/resume cycle ... Reviewed-by:
-
Daniel Vetter authored
To be able to directly set up the intel-gtt code from drm/i915 and avoid setting up the fake-agp driver we need to prepare a few things: - pass both the bridge and gpu pci_dev to the probe function and add code to handle the gpu pdev both being present (for drm/i915) and not present (fake agp). - add refcounting to the remove function so that unloading drm/i915 doesn't kill the fake agp driver v2: Fix up the cleanup and refcount, noticed by Jani Nikula. Reviewed-by:
-
Daniel Vetter authored
We only need it to fake the agp interface and don't actually use it in the driver anywhere. Hence conditionalize that. This is just a prep patch to eventually disable the fake agp driver on gen6+. Reviewed-by:
-
Daniel Vetter authored
For that to work we need to export the base address of the gtt mmio window from intel-gtt. Also replace all other uses of dev->agp by values we already have at hand. Reviewed-by:
-
Daniel Vetter authored
This is a leftover from the conversion of the i81x fake agp driver over to the new intel-gtt code layoute. Reviewed-by:
-
Daniel Vetter authored
Given the havoc the missing backlight pipe select code might have caused, let's try to re-enabled pipe A support for lvds on gen4 hw. Just to see what all blows up ... Note though that commit 4add75c4 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sat Dec 4 17:49:46 2010 +0000 drm/i915: Allow LVDS to be on pipe A for Ironlake+ claims that this caused tons of spurious wakeups somehow. More details can be found in the old revert: commit 12e8ba25 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Sep 7 23:39:28 2010 +0100 Revert "drm/i915: Allow LVDS on pipe A on gen4+" Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16307Reviewed-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by:
-
Daniel Vetter authored
On gen4+ we have a bitfield to specify from which pipe the backlight controller should take it's clock. For PCH split platforms we've already set these up, but only at initialization time. And without taking into account the 3rd pipe added with ivb. For gen4, we've completely ignored these. Although we do restrict lvds to the 2nd pipe, so this is only a problem on machines where we boot up with the lvds on the first pipe. So restructure the code to enable the backlight on the right pipe at modeset time. v2: For odd reasons panel_enable_backlight gets called twice in a modeset, so we can't WARN_ON in there if the backlight controller is switched on already. v3: backlight enable can also be called through dpms on, so the check in there is legit. Update the comment to reflect that. Tested-By:
Kamal Mostafa <kamal@canonical.com> Bugzilla: https://bugs.launchpad.net/bugs/954661 Cc: Carsten Emde <C.Emde@osadl.org> Reviewed-by:
-
Daniel Vetter authored
- Regroup definitions for BLC_PWM_CTL so that they're all together and and ordered according to the bitfields. - Add all missing definitions for BLC_PWM_CTL2. - Use the BLM_ (for backlight modulation) prefix consistently. - Note that combination mode (i.e. also taking the legacy backlight control value from pci config space into account) is gen4 only. - Move the new registers for PCH-split machines up, they're an almost match for the gen4 defitions. Prefix the special PCH-only bits with BLM_PCH_. Also add the pipe C select bit for ivb. - Rip out the second pair of PCH polarity definitions - they're only valid on early (pre-production) ilk silicon. - Adapt the existing code to use the new definitions. This has the nice benefit of killing a magic (1 << 30) left behind be Jesse Barnes. No functional changes in this patch. Reviewed-by:
-
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:
-
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:
-
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:
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 13 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:
-
