- 28 Jun, 2013 40 commits
-
-
Tomasz Figa authored
Some platforms that can be supported this driver has additional clock source selection bits in VIDCON0 register that allows to select which clock should be used to drive the pixel clock: bus clock or special clock. Since this driver assumes that special clock always drives the pixel clock, this patch sets the selection bitfield to use the special clock. Signed-off-by:
Tomasz Figa <tomasz.figa@gmail.com> Acked-by:
Joonyoung Shim <jy0922.shim@samsung.com> Signed-off-by:
Inki Dae <inki.dae@samsung.com>
-
Tomasz Figa authored
Some platforms that can be supported with this driver have PRTCON register instead of SHADOWCON, which requires slightly different handling. This patch factors out all register shadow control code from the driver and adds a function to control register shadowing appropriately, depending on driver data. Signed-off-by:
-
Tomasz Figa authored
This patch adds pointer to driver data to fimd_context structure, to remove the need to call drm_fimd_get_driver_data() each time access to driver data is necessary. Signed-off-by:
-
Inki Dae authored
This patch adds exynos_drm_crtc_mode_set_commit function to update mode data and it makes page flip call this function instead of calling exynos_drm_crtc_mode_set_base function directly. exynos_drm_crtc_mode_set_base function is called by drm subsystem as a callback so we don't have to call this function directly. Signed-off-by:
Kyungmin Park <kyungmin.park@samsung.com>
-
Sachin Kamat authored
'mixer_match_types' is always compiled in. Hence of_match_ptr is not necessary. Signed-off-by:
Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by:
-
Seung-Woo Kim authored
The definition of regulator_bulk_enable is fixed with __must_check and this causes following build warning. warning: ignoring return value of 'regulator_bulk_enable', declared with attribute warn_unused_result This patch fixes to check return value of the function. Signed-off-by:
Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by:
-
Inki Dae authored
This patch just checks if win_data array range is valid or not correctly. Signed-off-by:
-
Krzysztof Kozlowski authored
Valid values for FIMD windows are from 0 to WINDOWS_NR-1 inclusive (5 windows in total). The WINDOWS_NR is also a size of fimd_context.win_data array. However, early-return tests for wrong values of windows accepted a value of WINDOWS_NR which is out of bound for fimd_context.win_data. Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by:
-
Krzysztof Kozlowski authored
Valid values for mixer window are from 0 to MIXER_WIN_NR-1 inclusive. Arrays in structures (e.g. mixer_context.win_data) have size of MIXER_WIN_NR so checks for wrong mixer window must be greater-equal. Signed-off-by:
Hyunhee Kim <hyunhee.kim@samsung.com> 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:
Daniel Vetter <daniel.vetter@ffwll.ch> 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 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:
-
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:
-
Maarten Lankhorst authored
Having nouveau builtin would still allow ACPI_VIDEO to be used as external module if some of the deps for acpi_video have not been met, which would result in a linking failure. Solve this by selecting all dependencies as well. Signed-off-by:
-
Maarten Lankhorst authored
Shouldn't happen, and we invert the struct_mutex with reservation here, potentially leading to deadlocks. Once reservations become lockdep annotated, lockdep will go splat on this. Signed-off-by:
-
