- 06 12月, 2012 13 次提交
-
-
由 Daniel Vetter 提交于
Doesn't do anything yet than call dp_aux_irq_handler. Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
GMBUS_ACTIVE has inverted sense and so doesn't fit into the wait_hw_status helper, hence create a new gmbus_wait_idle functions. Also, we only care about the idle irq event and nothing else, which allows us to use the wait_event_timeout helper directly without jumping through hoops to catch NAKs. Since gen2/3 don't have gmbus interrupts, handle them separately with the old wait_for macro. This shaves another few ms off reading EDID from a hdmi screen on my testbox here. EDID reading with interrupt driven gmbus is now as fast as with busy-looping gmbus at 28 ms here (with negligible cpu overhead). Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
We need two special things to properly wire this up: - Add another argument to gmbus_wait_hw_status to pass in the correct interrupt bit in gmbus4. - Since we can only get an irq for one of the two events we want, hand-roll the wait_event_timeout code so that we wake up every jiffie and can check for NAKs. This way we also subsume gmbus support for platforms without interrupts (or where those are not yet enabled). The important bit really is to only enable one gmbus interrupt source at the same time - with that piece of lore figured out, this seems to work flawlessly. Ben Widawsky rightfully complained the lack of measurements for the claimed benefits (especially since the first version was actually broken and fell back to bit-banging). Previously reading the 256 byte hdmi EDID takes about 72 ms here. With this patch it's down to 33 ms. Given that transfering the 256 bytes over i2c at wire speed takes 20.5ms alone, the reduction in additional overhead is rather nice. v2: Chris Wilson wondered whether GMBUS4 might contain some set bits when booting up an hence result in some spurious interrupts. Since we clear GMBUS4 after every wait and we do gmbus transfer really early in the setup sequence to detect displays the window is small, but still be paranoid and clear it properly. v3: Clarify the comment that gmbus irq generation can only support one kind of event, why it bothers us and how we work around that limit. Cc: Daniel Kurtz <djkurtz@chromium.org> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
Only enables the interrupt and puts a irq handler into place, doesn't do anything yet. Unfortunately there's no gmbus interrupt support for gen2/3 (safe for pnv, but there the irq is marked as "Test mode"). v2: Wire up the irq handler for vlv and gen4 properly. v3: i915_enable_pipestat expects the mask bit, not the status bits ... and for added hilarity those are rather inconsistently named. Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
The gmbus interrupt generation is rather fiddly: We can only ever enable one interrupt source (but we always want to check for NAK in addition to the real bit). And the bits in the gmbus status register don't map at all to the bis in the irq register. To prepare for this mess, start by extracting the hw status wait loop into it's own function, consolidate the NAK error handling a bit. To keep things flexible, pass in the status bit we care about (in addition to any NAK signalling). v2: I've failed to notice that the sense of GMBUS_ACTIVE is inverted, Chris Wilson gladly pointed that out for me. To keep things simple, ignore that case for now (we only need to idle the gmbus controller at the end of an entire i2c transaction, not after every message). Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
Otherwise the new&shiny irq-driven gmbus and dp aux code won't work that well. Noticed since the dp aux code doesn't have an automatic fallback with a timeout (since the hw provides for that already). v2: Simple move drm_irq_install before intel_modeset_gem_init, as suggested by Ben Widawsky. v3: Now that interrupts are enabled before all connectors are fully set up, we might fall over serving a HPD interrupt while things are still being set up. Instead of jumping through massive hoops and complicating the code with a separate hpd irq enable step, simply block out the hotplug work item from doing anything until things are in place. v4: Actually, we can enable hotplug processing only after the fbdev is fully set up, since we call down into the fbdev from the hotplug work functions. So stick the hpd enabling right next to the poll helper initialization. v5: We need to enable irqs before intel_modeset_init, since that function sets up the outputs. v6: Fixup cleanup sequence, too. Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
... together with all the other irq related resources in intel_irq_init. I've managed to oops in the notify_ring function on my ilk, presumably because of the powerctx setup call to i915_gpu_idle. Note that this is only a problem with the reorder irq setup sequence for irq-driver gmbus/dp aux. Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
This is for legacy legacy stuff, and checking with the leftover pipe from the previous loop is propably not what we want. Since pipe == 2 after the loop ... Then we only assing a variable and do nothing with it. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
No need to have the exaxt same code twice. Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Mika Kuoppala 提交于
If there are pre-wrap values in semaphore-mbox registers after wrap, syncing against some after-wrap request will complete immediately. Fix this by emitting ring commands to set mbox registers to zero when the wrap happens. v2: Use __intel_ring_begin to emit ring commands, from Chris Wilson. Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> [danvet: Add a small comment to handle_seqno_wrap.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Mika Kuoppala 提交于
In preparation for handling ring seqno wrapping, split intel_ring_begin into helper part which doesn't allocate seqno. Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Mika Kuoppala 提交于
seqno's are u32 so print accordingly Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Mika Kuoppala 提交于
This is needed for testing seqno wrapping. Be careful to not bump next_seqno more than 0x7FFFFFFF at a time (between some handled requests) as i915_seqno_passed() can't handle bigger difference in between. v2: Address review comments from Chris Wilson. Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> Acked-by: NChris Wilson <chris@chris-wilson.co.uk> [danvet: Squash in fixup to properly remove the debugfs file on driver unload again.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 04 12月, 2012 4 次提交
-
-
由 Daniel Vetter 提交于
- __iomem where there is none (I love how we mix these things up). - Use gfp_t instead of an other plain type. - Unconfuse one place about enum pipe vs enum transcoder - for the pch transcoder we actually use the pipe enum. Fixup the other cases where we assign the pipe to the cpu transcoder with explicit casts. - Declare the mch_lock properly in a header. There is still a decent mess in intel_bios.c about __iomem, but heck, this is x86 and we're allowed to do that. Makes-sparse-happy: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Use a space after the cast consistently and fix up the newly-added cast in i915_irq.c to properly use __iomem.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
Simply use the last write-domain set for the object in the batch, trusting userspace to have correctly flushed the caches between usage as a write target. This check dates back from the golden age of having only a single operation per batch with the kernel repeating it for each cliprect, and conflicts both with userspace trying to efficiently batch multiple operations and with reducing the kernel overhead of relocation processing. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
Be specific for the GPU domains so that we can detect if userspace ever passed in an invalid combination, as well as accurately reflect the known GPU domains when printing state. Fixes i-g-t/gem_exec_bad_domains References: https://bugs.freedesktop.org/show_bug.cgi?id=57826Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 01 12月, 2012 13 次提交
-
-
由 Chris Wilson 提交于
The primary purpose of this was to debug some use-after-free memory corruption that was causing an OOPS inside drm/i915. As it turned out the corruption was being caused elsewhere and i915.ko as a major user of many objects was being hit hardest. Indeed as we do frequent the generic kmalloc caches, dedicating one to ourselves (or at least naming one for us depending upon the core) aids debugging our own slab usage. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Acked-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Acked-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Acked-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
Allow for the creation of GEM objects backed by stolen memory. As these are not backed by ordinary pages, we create a fake dma mapping and store the address in the scatterlist rather than obj->pages. v2: Mark _i915_gem_object_create_stolen() as static, as noticed by Jesse Barnes. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
In order to accommodate objects that are not backed by struct pages, but instead point into a contiguous region of stolen space, we need to make various changes to avoid dereferencing obj->pages or obj->base.filp. First introduce a marker for the stolen object, that specifies its offset into the stolen region and implies that it has no backing pages. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
As FBC is commonly disabled due to limitations of the chipset upon output configurations, on many systems FBC is never enabled. For those systems, it is advantageous to make use of the stolen memory for other objects and so we defer allocation of the FBC chunk until we actually require it. This increases the likelihood of that allocation failing, but that in turns means that we are already taking advantage of the stolen memory! As well as delaying the allocation from driver initialisation until the first use of FBC, we also return the stolen block after we finish using it - allowing greater flexibility in our usage of stolen space. A side effect of this is that we can then attempt to allocate only the required amount of space (with a little slack to reduce reallocation rate and avoid fragmentation). Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
As yet we do not do any preallocation (chicken-and-egg problem), but we may like to preserve anything already allocated by the BIOS or grub and reuse for own purposes after initialising the driver. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
The routine to query the base of stolen memory was using the wrong registers and the wrong encodings on virtually every platform. It was not until the G33 refresh, that a PCI config register was introduced that explicitly said where the stolen memory was. Prior to 865G there was not even a register that said where the end of usable low memory was and where the stolen memory began (or ended depending upon chipset). Before then, one has to look at the BIOS memory maps to find the Top of Memory. Alas that is not exported by arch/x86 and so we have to resort to disabling stolen memory on gen2 for the time being. Then SandyBridge enlarged the PCI register to a full 32-bits and change the encoding of the address, so even though we happened to be querying the right register, we read the wrong bits and ended up using address 0 for our stolen data, i.e. notably FBC. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
This will be used i915 in forthcoming patches in order to measure the largest contiguous chunk of memory available for enabling chipset features. v2: Try to make the macro marginally safer and more readable by not depending upon the drm_mm_hole_node_end() being non-zero. Note that we need to open code list_for_each() in order to update the hole_start, hole_end variable on each iteration and keep the macro sane. v3: Tidy up few BUG_ONs that fell foul of adding additional tests to drm_mm_hole_node_start(). Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Dave Airlie <airlied@redhat.com> Acked-by: NDave Airlie <airlied@redhat.com> Cc: dri-devel@lists.freedesktop.org Reviewed-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
To be used later by i915 to preallocate exact blocks of space from the range manager. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Dave Airlie <airlied@redhat.com> Acked-by: NDave Airlie <airlied@redhat.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
We only need to read/write the south interrupt register if the corresponding bit is set in the north master interrupt register. Noticed while reading our interrupt handling code. Same optimization has already been applied on ivb in commit 0e43406b Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed May 9 21:45:44 2012 +0100 drm/i915: Simplify interrupt processing for IvyBridge We can take advantage that the PCH_IIR is a subordinate register to reduce one of the required IIR reads, and that we only need to clear interrupts handled to reduce the writes. And by simply tidying the code we can reduce the line count and hopefully make it more readable. Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 30 11月, 2012 1 次提交
-
-
由 Luis R. Rodriguez 提交于
spinlock_t should always be used. LD drivers/gpu/drm/i915/built-in.o CHECK drivers/gpu/drm/i915/i915_drv.c CC [M] drivers/gpu/drm/i915/i915_drv.o CHECK drivers/gpu/drm/i915/i915_dma.c CC [M] drivers/gpu/drm/i915/i915_dma.o CHECK drivers/gpu/drm/i915/i915_irq.c CC [M] drivers/gpu/drm/i915/i915_irq.o CHECK drivers/gpu/drm/i915/i915_debugfs.c drivers/gpu/drm/i915/i915_debugfs.c:558:31: warning: dereference of noderef expression drivers/gpu/drm/i915/i915_debugfs.c:558:39: warning: dereference of noderef expression drivers/gpu/drm/i915/i915_debugfs.c:558:51: warning: dereference of noderef expression drivers/gpu/drm/i915/i915_debugfs.c:558:63: warning: dereference of noderef expression CC [M] drivers/gpu/drm/i915/i915_debugfs.o CHECK drivers/gpu/drm/i915/i915_suspend.c CC [M] drivers/gpu/drm/i915/i915_suspend.o CHECK drivers/gpu/drm/i915/i915_gem.c drivers/gpu/drm/i915/i915_gem.c:3703:14: warning: incorrect type in assignment (different base types) drivers/gpu/drm/i915/i915_gem.c:3703:14: expected unsigned int [unsigned] [usertype] mask drivers/gpu/drm/i915/i915_gem.c:3703:14: got restricted gfp_t drivers/gpu/drm/i915/i915_gem.c:3706:22: warning: invalid assignment: &= drivers/gpu/drm/i915/i915_gem.c:3706:22: left side has type unsigned int drivers/gpu/drm/i915/i915_gem.c:3706:22: right side has type restricted gfp_t drivers/gpu/drm/i915/i915_gem.c:3707:22: warning: invalid assignment: |= drivers/gpu/drm/i915/i915_gem.c:3707:22: left side has type unsigned int drivers/gpu/drm/i915/i915_gem.c:3707:22: right side has type restricted gfp_t drivers/gpu/drm/i915/i915_gem.c:3711:39: warning: incorrect type in argument 2 (different base types) drivers/gpu/drm/i915/i915_gem.c:3711:39: expected restricted gfp_t [usertype] mask drivers/gpu/drm/i915/i915_gem.c:3711:39: got unsigned int [unsigned] [usertype] mask CC [M] drivers/gpu/drm/i915/i915_gem.o CHECK drivers/gpu/drm/i915/i915_gem_context.c CC [M] drivers/gpu/drm/i915/i915_gem_context.o CHECK drivers/gpu/drm/i915/i915_gem_debug.c CC [M] drivers/gpu/drm/i915/i915_gem_debug.o CHECK drivers/gpu/drm/i915/i915_gem_evict.c CC [M] drivers/gpu/drm/i915/i915_gem_evict.o CHECK drivers/gpu/drm/i915/i915_gem_execbuffer.c CC [M] drivers/gpu/drm/i915/i915_gem_execbuffer.o CHECK drivers/gpu/drm/i915/i915_gem_gtt.c CC [M] drivers/gpu/drm/i915/i915_gem_gtt.o CHECK drivers/gpu/drm/i915/i915_gem_stolen.c CC [M] drivers/gpu/drm/i915/i915_gem_stolen.o CHECK drivers/gpu/drm/i915/i915_gem_tiling.c CC [M] drivers/gpu/drm/i915/i915_gem_tiling.o CHECK drivers/gpu/drm/i915/i915_sysfs.c CC [M] drivers/gpu/drm/i915/i915_sysfs.o CHECK drivers/gpu/drm/i915/i915_trace_points.c CC [M] drivers/gpu/drm/i915/i915_trace_points.o CHECK drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_display.c:1736:9: warning: mixing different enum types drivers/gpu/drm/i915/intel_display.c:1736:9: int enum transcoder versus drivers/gpu/drm/i915/intel_display.c:1736:9: int enum pipe drivers/gpu/drm/i915/intel_display.c:3659:48: warning: mixing different enum types drivers/gpu/drm/i915/intel_display.c:3659:48: int enum pipe versus drivers/gpu/drm/i915/intel_display.c:3659:48: int enum transcoder CC [M] drivers/gpu/drm/i915/intel_display.o CHECK drivers/gpu/drm/i915/intel_crt.c CC [M] drivers/gpu/drm/i915/intel_crt.o CHECK drivers/gpu/drm/i915/intel_lvds.c CC [M] drivers/gpu/drm/i915/intel_lvds.o CHECK drivers/gpu/drm/i915/intel_bios.c drivers/gpu/drm/i915/intel_bios.c:706:60: warning: incorrect type in initializer (different address spaces) drivers/gpu/drm/i915/intel_bios.c:706:60: expected struct vbt_header *vbt drivers/gpu/drm/i915/intel_bios.c:706:60: got void [noderef] <asn:2>*vbt drivers/gpu/drm/i915/intel_bios.c:726:42: warning: incorrect type in argument 1 (different address spaces) drivers/gpu/drm/i915/intel_bios.c:726:42: expected void const *<noident> drivers/gpu/drm/i915/intel_bios.c:726:42: got unsigned char [noderef] [usertype] <asn:2>* drivers/gpu/drm/i915/intel_bios.c:727:40: warning: cast removes address space of expression drivers/gpu/drm/i915/intel_bios.c:738:24: warning: cast removes address space of expression CC [M] drivers/gpu/drm/i915/intel_bios.o CHECK drivers/gpu/drm/i915/intel_ddi.c drivers/gpu/drm/i915/intel_ddi.c:87:6: warning: symbol 'intel_prepare_ddi_buffers' was not declared. Should it be static? drivers/gpu/drm/i915/intel_ddi.c:1036:34: warning: mixing different enum types drivers/gpu/drm/i915/intel_ddi.c:1036:34: int enum pipe versus drivers/gpu/drm/i915/intel_ddi.c:1036:34: int enum transcoder CC [M] drivers/gpu/drm/i915/intel_ddi.o drivers/gpu/drm/i915/intel_ddi.c: In function ‘intel_ddi_setup_hw_pll_state’: drivers/gpu/drm/i915/intel_ddi.c:1129:2: warning: ‘port’ may be used uninitialized in this function [-Wmaybe-uninitialized] drivers/gpu/drm/i915/intel_ddi.c:1111:12: note: ‘port’ was declared here CHECK drivers/gpu/drm/i915/intel_dp.c CC [M] drivers/gpu/drm/i915/intel_dp.o CHECK drivers/gpu/drm/i915/intel_hdmi.c CC [M] drivers/gpu/drm/i915/intel_hdmi.o CHECK drivers/gpu/drm/i915/intel_sdvo.c CC [M] drivers/gpu/drm/i915/intel_sdvo.o CHECK drivers/gpu/drm/i915/intel_modes.c CC [M] drivers/gpu/drm/i915/intel_modes.o CHECK drivers/gpu/drm/i915/intel_panel.c CC [M] drivers/gpu/drm/i915/intel_panel.o CHECK drivers/gpu/drm/i915/intel_pm.c drivers/gpu/drm/i915/intel_pm.c:2173:1: warning: symbol 'mchdev_lock' was not declared. Should it be static? CC [M] drivers/gpu/drm/i915/intel_pm.o CHECK drivers/gpu/drm/i915/intel_i2c.c CC [M] drivers/gpu/drm/i915/intel_i2c.o CHECK drivers/gpu/drm/i915/intel_fb.c CC [M] drivers/gpu/drm/i915/intel_fb.o CHECK drivers/gpu/drm/i915/intel_tv.c CC [M] drivers/gpu/drm/i915/intel_tv.o CHECK drivers/gpu/drm/i915/intel_dvo.c CC [M] drivers/gpu/drm/i915/intel_dvo.o CHECK drivers/gpu/drm/i915/intel_ringbuffer.c CC [M] drivers/gpu/drm/i915/intel_ringbuffer.o CHECK drivers/gpu/drm/i915/intel_overlay.c CC [M] drivers/gpu/drm/i915/intel_overlay.o CHECK drivers/gpu/drm/i915/intel_sprite.c CC [M] drivers/gpu/drm/i915/intel_sprite.o CHECK drivers/gpu/drm/i915/intel_opregion.c CC [M] drivers/gpu/drm/i915/intel_opregion.o CHECK drivers/gpu/drm/i915/dvo_ch7xxx.c CC [M] drivers/gpu/drm/i915/dvo_ch7xxx.o CHECK drivers/gpu/drm/i915/dvo_ch7017.c CC [M] drivers/gpu/drm/i915/dvo_ch7017.o CHECK drivers/gpu/drm/i915/dvo_ivch.c CC [M] drivers/gpu/drm/i915/dvo_ivch.o CHECK drivers/gpu/drm/i915/dvo_tfp410.c CC [M] drivers/gpu/drm/i915/dvo_tfp410.o CHECK drivers/gpu/drm/i915/dvo_sil164.c CC [M] drivers/gpu/drm/i915/dvo_sil164.o CHECK drivers/gpu/drm/i915/dvo_ns2501.c CC [M] drivers/gpu/drm/i915/dvo_ns2501.o CHECK drivers/gpu/drm/i915/i915_gem_dmabuf.c CC [M] drivers/gpu/drm/i915/i915_gem_dmabuf.o CHECK drivers/gpu/drm/i915/i915_ioc32.c CC [M] drivers/gpu/drm/i915/i915_ioc32.o CHECK drivers/gpu/drm/i915/intel_acpi.c CC [M] drivers/gpu/drm/i915/intel_acpi.o LD [M] drivers/gpu/drm/i915/i915.o Building modules, stage 2. MODPOST 1 modules CC drivers/gpu/drm/i915/i915.mod.o LD [M] drivers/gpu/drm/i915/i915.ko Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Reported-by: NHauke Mehrtens <hauke@hauke-m.de> Signed-off-by: NLuis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 29 11月, 2012 9 次提交
-
-
由 Paulo Zanoni 提交于
Use drm_dp_bw_code_to_link_rate insead. It's the same thing, but supports DP_LINK_BW_5_4 and is also used by the other drivers. Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Paulo Zanoni 提交于
Do an early return in case we don't have DDI instead of having the whole function inside an "if" statement. Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Paulo Zanoni 提交于
And use it whenever we call code that uses the DDIs. We already have intel_ddi.c and prefix every function with intel_ddi_something instead of haswell_something, so I think replacing the checks with HAS_DDI makes more sense. Just a cosmetical change, yes I know, but I have this OCD... Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Paulo Zanoni 提交于
This function is not called on Haswell anymore. Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Paulo Zanoni 提交于
It's not even declared on header files. Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
Since we drop dev->struct_mutex when going through the slowpath, the object might have been moved out of the cpu domain. Hence we need to clflush the entire object to ensure that after the ioctl returns, everything is coherent again (interwoven writes are ill-defined anyway). But we only need to do this if we start in the cpu domain and the object requires flushing for coherency. So don't do the flushing if the object is coherent anyway or if we've done in-line clfushing already. v2: i915_gem_clflush_object already checks whether the object is coherent and if so, drops the flushing. Hence we don't need to check that ourselves, simplifying the condition. v3: Reorder the checks for better clarity (and adjust the comment accordingly), suggested by Chris Wilson. Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
The shmem paths for pwrite/pread used a clever trick to hold onto a single page when dropping the big dev->struct_mutex for the slowpath. But this ran the risk of reinstating (or not completely purging) the backing storage when dropping purgeable objects. Hence the code needed to keep track of whether it ever dropped the lock, and if it did, manually check whether it needs to re-purge the backing storage. But thanks to the pages pin count introduced in commit a5570178 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Sep 4 21:02:54 2012 +0100 drm/i915: Pin backing pages whilst exporting through a dmabuf vmap which allowed us to pin the backing storage and remove that page reference trick from shmem_pwrite/read in commit f60d7f0c Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Sep 4 21:02:56 2012 +0100 drm/i915: Pin backing pages for pread and commit 755d2218 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Sep 4 21:02:55 2012 +0100 drm/i915: Pin backing pages for pwrite we can now abolish this check. The slowpath cleanup completely disappears from pread, and for pwrite we're only left with the domain fixup in case someone moved the object out of the cpu domain from under us. A follow-on patch will optimize that a notch more. Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
Only two things needed adjustment: - pipe select for PCH_CPT - There's no dithering bit on ilk+ in the lvds ctl reg Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
A few things needed to change: - HAS_PCH_SPLIT since ilk+ is not yet converted to this. - s/LVDS/intel_lvds->reg/ to prep for ilk conversion - replace the clock.p2 == 7 check with a is_dual_link check - s/adjusted_mode/intel_lvds->fixed_mode v2: Rebase on top of Jani Nikula's panel rework. I'm wondering whether we shouldn't add an attached_panel pointer to intel_encoder, to replace the encoder private ->attached_connector pointers, since that's essentially what we need. Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-