- 01 Jul, 2013 5 commits
-
-
Jani Nikula authored
drivers/gpu/drm/i915/i915_gem.c: In function ‘i915_gem_object_bind_to_gtt’: drivers/gpu/drm/i915/i915_gem.c:3002:3: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 5 has type ‘size_t’ [-Wformat] v2: Use %zu instead of %d. Two char patch, and 100% wrong. (Ville) Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Nothing the user (nor we) really can do about this, but upsets a nice quiet boot. Note that this happens mostly on SDVs where OEMs obviously haven't had a chance yet to appropriately trim the output list. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65988Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> [danvet: Amend commit message a bit to clarify a question from Paulo.] Signed-off-by:
-
Konrad Rzeszutek Wilk authored
Git commit 90797e6d ("drm/i915: create compact dma scatter lists for gem objects") makes certain assumptions about the under laying DMA API that are not always correct. On a ThinkPad X230 with an Intel HD 4000 with Xen during the bootup I see: [drm:intel_pipe_set_base] *ERROR* pin & fence failed [drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:3], err = -28 Bit of debugging traced it down to dma_map_sg failing (in i915_gem_gtt_prepare_object) as some of the SG entries were huge (3MB). That unfortunately are sizes that the SWIOTLB is incapable of handling - the maximum it can handle is a an entry of 512KB of virtual contiguous memory for its bounce buffer. (See IO_TLB_SEGSIZE). Previous to the above mention git commit the SG entries were of 4KB, and the code introduced by above git commit squashed the CPU contiguous PFNs in one big virtual address provided to DMA API. This patch is a simple semi-revert - were we emulate the old behavior if we detect that SWIOTLB is online. If it is not online then we continue on with the new compact scatter gather mechanism. An alternative solution would be for the the '.get_pages' and the i915_gem_gtt_prepare_object to retry with smaller max gap of the amount of PFNs that can be combined together - but with this issue discovered during rc7 that might be too risky. Reported-and-Tested-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> CC: Chris Wilson <chris@chris-wilson.co.uk> CC: Imre Deak <imre.deak@intel.com> CC: Daniel Vetter <daniel.vetter@ffwll.ch> CC: David Airlie <airlied@linux.ie> CC: <dri-devel@lists.freedesktop.org> Signed-off-by:
-
Rui Guo authored
In some virtualized environments (e.g. XEN), there is irrelevant ISA bridge in the system. To work reliably, we should scan trhough all the ISA bridge devices and check for the first match, instead of only checking the first one. Signed-off-by:
Rui Guo <firemeteor@users.sourceforge.net> [danvet: Fixup conflict with the num_pch_pll removal. And add subsystem header to the commit message headline.] Signed-off-by:
-
Paulo Zanoni authored
Because it's the function that destroys the connector, not the encoder. And we already have intel_dp_encoder_destroy. This has annoyed me for a long time. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Zoltan Nyul <zoltan.nyul@intel.com> Signed-off-by:
-
- 28 Jun, 2013 35 commits
-
-
Paulo Zanoni authored
We've been ignoring this return value, so print a nice backtrace in case it's not what we expected. Signed-off-by:
-
Paulo Zanoni authored
Because calling intel_dp_encoder_destroy inside intel_edp_init_connector is just wrong. This is the initialization path, so we should properly unwind all the initialization through the whole caller stack. On the intel_dp_encoder_destroy function we do the following: 1 - Call i2c_del_adapter 2 - Call drm_encoder_cleanup 3 - If edp: 3.1 - Cancel panel_vdd_work 3.2 - Call ironlake_panel_vdd_of_sync 4 - Free the encoder And here is how we unwind each specific step: 1 - We have intel_dp_init_connector -> intel_dp_i2c_init -> i2c_dp_aux_add_bus -> i2c_add_adapter, so we call i2c_del_dapter at intel_dp_init_connector 2 - Call it in the same function that called drm_encoder_init 3 - Call it in the same function that called INIT_DELAYED_WORK 4 - Free it in the same function that allocated it Signed-off-by: -
Paulo Zanoni authored
Because calling intel_dp_destroy inside intel_edp_init_connector is just wrong. This is the initialization path, so we should properly unwind all the initialization through the whole caller stack. On the intel_dp_destroy function we do the following: 1 - Free edid if it exists 2 - Call intel_panel_fini in case it's eDP 3 - Call drm_sysfs_connector_remove 4 - Call drm_connector_cleanup 5 - Free the connector And here is how we unwind each specific step: 1 - No need as we still didn't assign anything 2 - No need as we still didn't call intel_panel_init 3 - Call it in the same function that called drm_sysfs_connector_add 4 - Call it in the same function that called drm_connector_init 5 - Free it in the same function that allocated it Signed-off-by:
-
Paulo Zanoni authored
In case we detect a "ghost eDP", intel_edp_init_connector frees both the connector and encoder and then returns. On Haswell, intel_ddi_init then tries to use the freed encoder on the HDMI initialization path since the following commit: commit 21a8e6a4 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Apr 10 23:28:35 2013 +0200 drm/i915: don't setup hdmi for port D edp in ddi_init So now on intel_ddi_init we check for the "ghost eDP" case and return without trying to initialize HDMI. This way we won't try to read the freed "intel_encoder" struct in the next "if" statement. Signed-off-by:
-
Paulo Zanoni authored
Because intel_dp_init_connector is too big for my poor little brain. No functional changes. Signed-off-by:
-
Paulo Zanoni authored
By the time we call intel_dp_destroy (which destroys the connector) the encoder may have been destroyed already, so if we use it we may be reading some free memory. That happens in drm_mode_config_cleanup() and also inside intel_dp_init_connector() when we detect a ghost eDP. I also hope this may solve some random memory bugs. Reported by kmemcheck. Signed-off-by:
-
Dave Airlie authored
This reverts commit 160954b7. This was rearming the workqueue with a 0 timeout, causing a WARN_ON, and possible loop. Daniel writes: "I've looked a bit into this and I think we need to have a separate work struct for recovering these lost hotplug events since the continuous self-rearming case is a real risk (e.g. if a connector flip-flops all the time). At least I don't see a sane way to block out re-arming with the current code in a simple way. So reverting the offender seems like the right thing and I'll go back to the drawing board for 3.12." Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
Laurent Pinchart authored
Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Laurent Pinchart authored
The i915 driver has been fixed not to modify the mode argument of the encoder mode_fixup operation. Remove the related comment from the documentation. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Laurent Pinchart authored
Define the rules for using irqs from drm drivers. Signed-off-by:
-
YoungJun Cho authored
The dma_buf_fd() can return error when it fails to prepare fd, so the dma_buf needs to be put. Signed-off-by:
YoungJun Cho <yj44.cho@samsung.com> Signed-off-by:
Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by:
Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by:
-
Seung-Woo Kim authored
Signed-off-by:
-
YoungJun Cho authored
When drm_prime_add_buf_handle() returns failure for an exported dma_buf, the dma_buf was already allocated and its refcount was increased, so it needs to be put. Signed-off-by:
-
Joonyoung Shim authored
The drm prime also can support it like GEM CMA supports to cache mapping. It doesn't allow multiple mappings for one attachment. [airlied: rebased on top of other prime changes] Signed-off-by:
Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by:
-
YoungJun Cho authored
Instead of NULL, error value is casted with ERR_PTR() for drm_prime_pages_to_sg() and IS_ERR_OR_NULL() macro is replaced with IS_ERR() macro for drm_gem_map_dma_buf(). Signed-off-by:
-
YoungJun Cho authored
The dma_map_sg(), in map_dma_buf callback operation of prime helper, can return 0 when it fails to map, so it needs to release related resources. Signed-off-by:
-
YoungJun Cho authored
If idr_alloc() is failed, obj->name can be error value. Also it cleans up duplicated flink processing code. This regression has been introduced in commit 2e928815 Author: Tejun Heo <tj@kernel.org> Date: Wed Feb 27 17:04:08 2013 -0800 drm: convert to idr_alloc() Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
YoungJun Cho authored
The drm_gem_mmap_obj() has to be protected with dev->struct_mutex, but some caller functions do not. So it adds mutex lock to missing callers and adds assertion to check whether drm_gem_mmap_obj() is called with mutex lock or not. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@canonical.com> Reviewed-by:
Rob Clark <robdclark@gmail.com> Reviewed-by:
-
Dave Airlie authored
This ends up causing circularity and really let people shoot themselves in the foot. Acked-by:
-
Maarten Lankhorst authored
Signed-off-by:
-
Maarten Lankhorst authored
Use lockdep_assert_held instead. Signed-off-by:
-
Maarten Lankhorst authored
Try to use lockdep_assert_held or other alternatives where possible. Signed-off-by:
Jerome Glisse <jglisse@redhat.com> Signed-off-by:
-
Maarten Lankhorst authored
Use lockdep_assert_held instead. Signed-off-by:
-
Maarten Lankhorst authored
Makes lockdep a lot more useful. Signed-off-by:
-
Maarten Lankhorst authored
Signed-off-by:
-
Maarten Lankhorst authored
Signed-off-by:
-
Maarten Lankhorst authored
Signed-off-by:
-
Maarten Lankhorst authored
Signed-off-by:
-
Maarten Lankhorst authored
Now that the code is compatible in semantics, flip the switch. Use ww_mutex instead of the homegrown implementation. ww_mutex uses -EDEADLK to signal that the caller has to back off, and -EALREADY to indicate this buffer is already held by the caller. ttm used -EAGAIN and -EDEADLK for those, respectively. So some changes were needed to handle this correctly. Signed-off-by:
-
Maarten Lankhorst authored
cli->mutex was inverted with reservations, and multiple reservations were used without a ticket, fix both. This commit had to be done after the previous commit, because otherwise ttm_eu_* calls would use a different seqno counter.. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Maarten Lankhorst authored
This commit converts the source of the val_seq counter to the ww_mutex api. The reservation objects are converted later, because there is still a lockdep splat in nouveau that has to resolved first. Signed-off-by:
-
Maarten Lankhorst authored
This adds support for a generic reservations framework that can be hooked up to ttm and dma-buf and allows easy sharing of reservations across devices. The idea is that a dma-buf and ttm object both will get a pointer to a struct reservation_object, which has to be reserved before anything is done with the contents of the dma-buf. Changes since v1: - Fix locking issue in ticket_reserve, which could cause mutex_unlock to be called too many times. Changes since v2: - All fence related calls and members have been taken out for now, what's left is the bare minimum to be useful for ttm locking conversion. Changes since v3: - Removed helper functions too. The documentation has an example implementation for locking. With the move to ww_mutex there is no need to have much logic any more. Signed-off-by:
-
Maarten Lankhorst authored
Mutexes should not be acquired in interrupt context. While the trylock fastpath is arguably safe on all implementations, the slowpath unlock path definitely isn't. Signed-off-by:
-
Maarten Lankhorst authored
Mutexes should not be acquired in interrupt context. While the trylock fastpath is arguably safe on all implementations, the slowpath unlock path definitely isn't. Signed-off-by:
-
Maarten Lankhorst authored
Mutexes should not be acquired in interrupt context. While the trylock fastpath is arguably safe on all implementations, the slowpath unlock path definitely isn't. This fixes the following lockdep splat: [ 13.044313] ------------[ cut here ]------------ [ 13.044367] WARNING: at /c/kernel-tests/src/tip/kernel/mutex.c:858 mutex_trylock+0x87/0x220() [ 13.044378] DEBUG_LOCKS_WARN_ON(in_interrupt()) [ 13.044378] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.10.0-rc4-00296-ga2963dd #20 [ 13.044379] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007 [ 13.044390] 0000000000000009 ffff88000de039f8 ffffffff81fc86d5 ffff88000de03a38 [ 13.044395] ffffffff810d511b ffff880000000018 ffff88000f33c690 0000000000000001 [ 13.044398] 00000000000003f0 ffff88000f4677c8 0000000000000000 ffff88000de03a98 [ 13.044400] Call Trace: [ 13.044412] <IRQ> [<ffffffff81fc86d5>] dump_stack+0x19/0x1b [ 13.044441] [<ffffffff810d511b>] warn_slowpath_common+0x6b/0x90 [ 13.044445] [<ffffffff810d51a6>] warn_slowpath_fmt+0x46/0x50 [ 13.044448] [<ffffffff81fd34d7>] mutex_trylock+0x87/0x220 [ 13.044482] [<ffffffff8186484d>] cirrus_dirty_update+0x1cd/0x330 [ 13.044486] [<ffffffff818649e8>] cirrus_imageblit+0x38/0x50 [ 13.044506] [<ffffffff8165782e>] soft_cursor+0x22e/0x240 [ 13.044510] [<ffffffff81656c31>] bit_cursor+0x581/0x5b0 [ 13.044525] [<ffffffff815de9f4>] ? vsnprintf+0x124/0x670 [ 13.044529] [<ffffffff81651333>] ? get_color.isra.16+0x43/0x130 [ 13.044532] [<ffffffff81653fca>] fbcon_cursor+0x18a/0x1d0 [ 13.044535] [<ffffffff816566b0>] ? update_attr.isra.2+0xa0/0xa0 [ 13.044556] [<ffffffff81754b82>] hide_cursor+0x32/0xa0 [ 13.044565] [<ffffffff81755bd3>] vt_console_print+0x103/0x3b0 [ 13.044569] [<ffffffff810d58ac>] ? print_time+0x9c/0xb0 [ 13.044576] [<ffffffff810d5960>] ? print_prefix+0xa0/0xc0 [ 13.044580] [<ffffffff810d63f6>] call_console_drivers.constprop.6+0x146/0x1f0 [ 13.044593] [<ffffffff815f9b38>] ? do_raw_spin_unlock+0xc8/0x100 [ 13.044597] [<ffffffff810d6f27>] console_unlock+0x2f7/0x460 [ 13.044600] [<ffffffff810d787a>] vprintk_emit+0x59a/0x5e0 [ 13.044615] [<ffffffff81fb676c>] printk+0x4d/0x4f [ 13.044650] [<ffffffff82ba5511>] print_local_APIC+0x28/0x41c [ 13.044672] [<ffffffff8114db55>] generic_smp_call_function_single_interrupt+0x145/0x2b0 [ 13.044688] [<ffffffff8106f9e7>] smp_call_function_single_interrupt+0x27/0x40 [ 13.044697] [<ffffffff81fd8f72>] call_function_single_interrupt+0x72/0x80 [ 13.044707] <EOI> [<ffffffff81078166>] ? native_safe_halt+0x6/0x10 [ 13.044717] [<ffffffff811425cd>] ? trace_hardirqs_on+0xd/0x10 [ 13.044738] [<ffffffff8104f669>] default_idle+0x59/0x120 [ 13.044742] [<ffffffff810501e8>] arch_cpu_idle+0x18/0x40 [ 13.044754] [<ffffffff811320c5>] cpu_startup_entry+0x235/0x410 [ 13.044763] [<ffffffff81f9e781>] rest_init+0xd1/0xe0 [ 13.044766] [<ffffffff81f9e6b5>] ? rest_init+0x5/0xe0 [ 13.044778] [<ffffffff82b93ec2>] start_kernel+0x425/0x493 [ 13.044781] [<ffffffff82b93810>] ? repair_env_string+0x5e/0x5e [ 13.044786] [<ffffffff82b93595>] x86_64_start_reservations+0x2a/0x2c [ 13.044789] [<ffffffff82b93688>] x86_64_start_kernel+0xf1/0x100 [ 13.044799] ---[ end trace 113ad28772af4058 ]--- Reported-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
-
